Preparing for the EU AI Act and the Regulatory Wave
The email arrives on a Thursday at 4:40pm, and it is not from a regulator. It is from your second-largest customer, forwarded by the account director with three words on top: "this is urgent." Attached is a procurement questionnaire, forty-one questions, a renewal condition, most of it the usual security material your team can answer in an afternoon. Then, on page four: "List all AI systems used in the delivery of services to our account, with the classification of each, the human oversight arrangements in place, the date of the most recent documented risk assessment, and confirmation that AI-generated content delivered to us is identifiable as such." Ten business days. An account worth roughly $3.1 million a year. And the strategist reading it realizes two things at once: no such list exists anywhere in the company, and the regulator everyone has been vaguely worrying about was never going to ask first.
The Memo That Arrives Too Late
Most organizations are preparing for AI regulation the way they prepared for early privacy regulation, which is to say they are not preparing at all. They are waiting. The mental model is that regulation is a legal department problem that will arrive as a memo from counsel explaining what must now be done, after which the operating side will do it. This model has one fatal property: it produces a scramble roughly twelve weeks before a deadline for artifacts that take nine months to assemble honestly. You have watched this movie before: modern privacy rules did not create the work of writing down what data you held and who owned it, they made a years-old gap visible on a date.
Here is the reframe this lesson exists to deliver. Nearly everything a regulator, an auditor, or an enterprise customer will ask you for is something a well-run AI program already produces as a byproduct of running well: an inventory of systems, a record of what each does and who owns it, evidence that each was tested and is watched in production, documentation of where human judgment sits, logs that reconstruct why a decision came out as it did, a documented assessment of what could go wrong, and change control.
Not one item is a legal artifact. Every one is an operating artifact you have been building since Level 1 for non-regulatory reasons, because each makes the work better, cheaper, and less likely to produce the stalled pilot MIT found in 95 percent of enterprise generative AI deployments. The compliance program is therefore not a burden bolted onto a working program. It is a naming and indexing of work already underway, plus a finite list of gaps.
Compliance readiness is not a build. For an organization that already operates well, it is an index of evidence it already has, plus the short list of gaps it can now finally see.
That is also the honest argument for doing the Level 1 through Level 4 work properly regardless of jurisdiction. If you sell nothing into Europe, the discipline still pays: the questionnaire is coming either way, and the practices that satisfy a regulator keep a program out of the 42 percent of companies S&P Global found scrapping most of their AI initiatives in 2025. Regulation is not the reason to be disciplined. It is the deadline that makes indiscipline expensive on a date.
One boundary holds for the whole lesson: you are not counsel and this is not legal advice. Whether an obligation applies, how a system should be classified, and what your legal role is depend on facts about the system and the organization, and those calls belong to lawyers. Your job is harder to delegate: assemble the facts that let counsel decide, and build the operating evidence that makes the answer defensible. Counsel cannot classify a system nobody told them exists.
The Calendar as a Planning Instrument
Start with the dates, because dates are the only part of this subject that behaves like a project plan. The EU AI Act, under the post-Digital-Omnibus calendar agreed in May 2026 and still pending formal adoption, phases its obligations across four moments:
- August 2, 2025: obligations for general-purpose AI (GPAI, broadly capable foundation models rather than a single narrow application) have applied since this date.
- December 2, 2026: transparency obligations for AI-generated content.
- December 2, 2027: obligations for high-risk systems in the Annex III category.
- August 2, 2028: obligations for high-risk systems in the Annex I category, the ones embedded in regulated products.
State those four dates accurately, once, and then stop. Two caveats travel with them. First, the calendar remains subject to formal adoption, so it is directionally reliable but not frozen; your register should carry a "calendar last verified" date. Second, and far more important operationally: whether these obligations apply to you at all, and which systems fall into which category, depends on facts about each system and your role with respect to it. Two companies using the identical tool can carry different obligations, and that call is counsel's.
Working backward is the whole move
Most organizations make a planning error here rather than a legal one. They read December 2, 2027 as "the day the documentation is due" and plan to produce documentation in late 2027, which is as sensible as producing a year of financial statements in the last week of December. The strategist asks instead: when must the artifacts exist, be current, and be credible?
For anything involving evidence of testing and oversight, the answer sits far earlier than the deadline, for one reason. Evidence of proper operation cannot be written. It has to be generated by operating properly. A risk assessment can be drafted in a week; a record of six months of monitoring cannot. A gate design fits on one page, but evidence that reviewers overturned outputs and that overturn rates were tracked exists only if the gate was really running. Logs that reconstruct decisions from eight months ago exist only if you were logging then. A binder assembled retrospectively reads like one.
So adopt a planning heuristic and write it down: the nine-month rule. For any system needing evidence of testing, oversight, and monitoring, the practice generating that evidence must be running at least nine months before the evidence is needed. No regulator published that number. It is an operator's estimate of how long it takes to accumulate a monitoring record with real seasonal variation, run one incident through the playbook, and exercise a change-control cycle, so the whole thing is true rather than assembled.
Run that backward and the calendar becomes a schedule. If a system might land in the Annex III category, the practice needs to be live by roughly the first quarter of 2027, which means the classification conversation happens in 2026, which means the inventory has to exist now. The dates do not tell you what to do. Backing off from them tells you when to start, which is the only planning question that ever mattered.
The Inventory Almost Nobody Has
Everything downstream depends on one deliverable that almost no organization possesses on the day it is first asked for: a complete inventory of every AI system in use anywhere in the organization, including the majority nobody thinks of as AI at all. It matters long before any regulator cares, because the questionnaire on page four asks for exactly this, and because you cannot govern, classify, or defend a system you have not written down.
The embedded systems are the surprise
Your known AI use cases, the ones with sponsors and gate reviews and a line in the roadmap, are already documented. The compliance surprise lives in the AI features embedded inside software you bought for other reasons, switched on by a release note nobody read: the candidate-ranking feature in the human resources suite, the forecasting module in the enterprise resource planning system (ERP, the platform running finance, inventory, and orders), the fraud-scoring engine in the payments platform, the summarization feature that appeared in the service desk last spring. None were procured as AI, some are on by default, and several touch exactly the categories that draw the heaviest obligations, because they influence decisions about people.
Finding them is a real exercise, not a survey you email out and forget. Four sources, run together:
- Procurement and expense records. Every software contract and recurring card charge, read for what the product does now rather than what it was bought to do three years ago. Renewal documents help most, because vendors advertise new AI capabilities in them.
- The vendor register from your third-party risk work. You tiered your AI vendors by exposure already. Now walk the whole list, asking which non-AI vendors shipped AI features into products you already run.
- The shadow-AI census. Browser extensions, personal subscriptions expensed as "software," the tool bought on a manager's card. Ask amnestied, not accusatory: you want systems, not culprits, and a punitive census returns an empty inventory, which is worse than none.
- A direct question to every function head. Phrase it carefully, because "do you use AI?" reliably returns "no" from people who use three AI features daily. Ask: "what in your function produces a recommendation, a score, a ranking, a draft, a prediction, or a match that a person then acts on?"
What each entry records
Keep it short enough that people will complete it and complete enough that counsel can work from it. Six fields:
- Purpose. One sentence of operator language: "ranks inbound applications by predicted fit," not "leverages machine learning for talent acquisition."
- Data. What goes in, including whether it holds personal data (PII, personally identifiable information), and where it comes from.
- Decisions affected. What happens downstream, and whether a person is affected. Systems touching employment, credit, access to services, or safety sit in a different world from ones that summarize meeting notes.
- Human involvement. Whether a human reviews, can override, or is even aware, and where that is recorded.
- Owner. One named person, not a department. An entry with a department in the owner field is one nobody updates.
- Our role. How you stand in relation to the system: built, bought, configured, embedded in something you sell, or resold. Record the facts, not the legal characterization. Roles matter enormously for what obligations attach, and that determination is counsel's to make from the facts you supply.
Expect four to six weeks in a mid-sized organization, and at least one uncomfortable discovery. Found by you in a quiet week, it costs a fraction of the same discovery found by a customer's auditor in a loud one.
Provisional Classification and the Artifact Map
With an inventory in hand, sit down with counsel and walk it. What comes out is a provisional classification for each entry: a working view of which obligation category it is likely to fall into, dated and flagged as provisional. Provisional is honesty, not weakness. What matters operationally is that every system has a working classification so planning can proceed, and that the heaviest obligations surface early enough to act on.
Now the move that makes this lesson worth the hour. For each classification, ask what evidence it would require, and map that against what your program already produces.
| Evidence a reviewer, auditor, or customer asks for | The artifact your program already produces |
|---|---|
| Documented risk assessment before deployment | The AI-FMEA Worksheet (failure mode and effects analysis for AI) |
| Human oversight design and evidence of use | The Gate Spec: entry criteria, review standard, authority to overturn, escalation target |
| Testing before and after deployment | The four test suites and golden sets, with re-test triggers in the SOP (standard operating procedure) |
| Ability to reconstruct why a decision came out as it did | The Decision Record standard and the workflow audit trail |
| Data governance, provenance, and permitted use | Data program certification records, the Critical Dataset Register, the AI Data Boundary Map |
| Change control, so the tested system is the running system | SOP change triggers plus canary regression on model or prompt change |
| Ongoing monitoring in production | The Quality Watch Regime: your one-page production monitoring stack |
| Incident detection, response, and remediation | The AI Incident Playbook, with severity tiers and named roles |
| Fairness testing on people-affecting systems | The Fairness Check Sheets and their segment tables |
For every row, indexing means three checks: the artifact exists, it is dated, and it covers the version actually running. Nine evidence types, nine artifacts you already build. There is a tenth your program cannot produce for itself: documentation from the vendors of embedded and purchased systems. Your vendor dossiers hold what you have; what is missing must be requested in writing, with a date. Start there, because the response clock is not yours.
The argument you make to the board, in exactly these terms
Notice what the table proves. An organization that has done Levels 1 through 4 properly walks into a compliance conversation holding nine of the ten things it will be asked for, and its work is largely to index. An organization that has not done that work must build the practice and generate the evidence simultaneously, under a deadline, while the business keeps running. The first is an administrative exercise measured in weeks; the second is a transformation program measured in quarters, attempted in weeks.
This is the most persuasive argument you will ever have for the program's discipline, and it should reach the board in exactly these words: "the discipline we funded for quality and adoption reasons has already produced nine of the ten evidence categories a regulator or enterprise customer will ask for. Here is the index. Here is the one category we must source from vendors. Here is what the same conversation looks like for the systems that never went through the program." Executives who nodded politely at process discipline sit forward when it turns out to have pre-paid a liability.
The artifact: the Regulatory Readiness Register
It all lands in one document, the artifact you take away: the Regulatory Readiness Register. One row per AI system, six columns:
- System and purpose, in operator language, with the facts about your role.
- Provisional classification, with the date it was set and who at counsel set it.
- Owner: one named human, accountable for this row being true.
- Artifact set with currency dates: which of the nine evidence types exist, and when each was last refreshed. A missing date equals a missing artifact.
- Applicable milestone: the calendar date this system plans against, and the start date the nine-month rule implies.
- Gap list: what is missing, who closes it, and by when.
It answers one question for any regime, auditor, or customer on any day: are we ready, and if not, exactly where, and who is fixing it? Every organization has people who can offer an opinion on that. Very few can produce a document.
The Register in Practice, and the Scramble Next Door
Here is the enterprise storyline this level has followed. Norvik Group is a 2,400-person business-to-business services and distribution company with six functions. Every figure below is illustrative, showing the shape of the work rather than predicting yours.
Weeks one to six: the hunt
The program believes it has eleven AI systems, because eleven is what the roadmap and the tools register say. The hunt across procurement records, the vendor register, a no-blame shadow-AI census, and a direct question to all six function heads finds nineteen. The eight surprises: five are features embedded in software already owned, including a candidate-screening capability in the HR suite, enabled by default in a platform release, that nobody decided to turn on and that has shaped which applications get seen for seven months. Two are departmental tools bought outside policy. One is a forecasting model built in-house in 2019 by an analyst who has since left, running in production, feeding a purchasing decision weekly, documented nowhere.
Weeks six to nine: classification, and the cheapest remediation available
Counsel walks the nineteen rows over two sessions. Three route provisionally into the people-decision category needing specialist review: the candidate screener, a workforce-scheduling optimizer, and a customer credit-terms recommender. Twelve route into lower-obligation categories. Four cannot be classified until vendors document what their embedded features do, and those four become letters sent that week.
The screener is switched off pending review in week one, before the analysis finishes. This is the cheapest remediation in the lesson: a system you have disabled is a system you are no longer accumulating exposure from. The HR director's objection ("we will lose screening throughput") survives four minutes against the alternative, running an untested people-ranking system for the eighteen months it takes to review, test, document, and defend it. Screening reverts to the manual process at roughly 22 extra hours a month, a bargain.
Weeks nine to twelve: the map, and the finding that goes to the board
Six of the nineteen went through the full program: gated, tested, instrumented, monitored. For those six the artifact map shows seven of the nine evidence types already produced and dated. The two thin ones are fairness evidence, done properly for only one of the six, and change-control records, where the SOP triggers exist but canary regression runs were never kept as dated records, only as pass or fail calls in a chat thread. Both gaps are weeks of work, not quarters.
The other thirteen have almost nothing: no risk assessment, no oversight design, no test record, no monitoring, no incident path, no retained logs. That contrast is the shape of the gap program, and it goes on the slide as two columns. Six systems: index, confirm, refresh, roughly nine person-weeks. Thirteen systems: build the practice and generate the evidence, four to seven quarters. Same company, same date, one variable, which is whether the discipline was already running. Gartner's finding that 63 percent of organizations lack or are unsure of their AI-ready data practices tells you which column most companies stand in.
The dates, the owner, and the unexpected dividend
Working backward from the December 2, 2026 transparency milestone, Norvik finds two customer-facing outputs needing a disclosure change: an automated account summary and a set of AI-drafted service responses. Note what kind of work that is. Not a technical problem: a template change, decisions about wording, a small translation queue. It is scoped as a product and communications task with a product owner rather than filed under legal, and it starts nine months out, not nine weeks.
The register gets a named owner, the AI program manager, with a standing slot on the governance committee's quarterly calendar. And one process change matters more than any remediation: provisional classification becomes a gate 1 requirement. No new use case passes the first stage gate without a classification and a register row. That is how the register stays current without heroics, because the alternative, an annual re-inventory, leaves it wrong for eleven months of every twelve.
Then the dividend nobody planned. In the same quarter the first enterprise customer questionnaire arrives, the one from the opening of this lesson. Norvik answers it in four days, mostly by exporting rows and attaching artifacts, rather than the three weeks a from-scratch assembly would have taken. Two quarters later the sales team is using the register in competitive deals, because the competitor's answer to question 27 is a paragraph of reassurance and Norvik's is a document. Readiness turned out to carry a commercial return, which is the reason the budget survives.
The scramble next door
Now the failure case, because the contrast is the lesson. A mid-sized manufacturer's legal team flags an approaching obligation with one quarter to go. Three weeks disappear into finding out what AI systems the company runs, because no inventory exists: three of thirteen weeks spent on a task Norvik did calmly in six, under no deadline at all.
When the list settles at four significant systems plus a long tail, the assessment is brutal. Two of the four have no documented risk assessment, no designed human oversight (a supervisor who "checks it sometimes" is not an oversight design), and logs that show an output was produced but cannot reconstruct why a particular decision came out as it did. The Level 3 disciplines were never adopted, so the evidence they generate does not exist and cannot be conjured.
Two honest options remain. Build nine months of evidence in nine weeks, which cannot be done credibly, because a monitoring record, an overturn history, and a change log are records of things you did, not documents you write. Or suspend the two systems, which the business refuses because both are load-bearing. So the organization does the third thing, the one nobody chooses out loud: it assembles a rushed documentation package its own counsel will not warrant, and everyone involved knows it.
The real cost is not a fine, which may never come. It is a standing anxiety that resurfaces every time a customer questionnaire arrives, every time an auditor asks a follow-up, every time someone proposes a new use case and the room remembers the last one. The deadline was never the problem. The absence of an operating practice that generates evidence as a byproduct was the problem, and the deadline merely published it.
The Gap Program and the Standing Capability
After the mapping, what remains is a finite list, worth saying plainly to a nervous executive: the output is not an open-ended obligation, it is a backlog with a bottom. Three gap types dominate.
- Embedded third-party systems whose vendors must supply documentation. The largest category and the slowest, because the clock is not yours. Write to every vendor whose product contains AI functionality: what the feature does, what data it uses, whether it can be disabled, what documentation they provide, how they notify you of material changes. Put it in the contract at renewal, track responses by date, and treat a non-response as a finding with an owner.
- Transparency and disclosure for AI-generated content. Consistently mis-filed. Teams see "transparency obligation," assume a watermarking project, route it to engineering, and it stalls. In most organizations it is a communications and product change: which outputs go to people outside the company, what wording tells them an AI system was involved, and who signs off.
- Legacy systems that predate the program. The 2019 forecasting model with no owner, no documentation, no instrumentation. These need a decision rather than a project: retire, replace, or bring into the program with a named owner and the full artifact set. What kills organizations is the fourth option, leaving it running and hoping nobody asks, which the register makes impossible to take quietly.
Every gap gets an owner by name and a date backed off from its milestone by the nine-month rule. A gap list without dates is a worry list, and worry lists never close.
From project to standing capability
The scramble is what happens when readiness is a project. The alternative is a capability with four unglamorous properties.
- Someone owns the register by name, and it sits in their objectives, because a document owned by a committee is owned by nobody.
- It is reviewed quarterly on the governance committee's calendar: rows added, classifications changed, artifacts expired, gaps closed and opened.
- New use cases enter at gate 1, which keeps the register true without a yearly re-inventory.
- The regulatory-monitoring duty is assigned by name: one person who reads the developments quarterly, works with counsel on what changed, and brings the calendar update to the committee. Not "legal watches this." A person, in a role description.
That duty matters because the wave extends beyond any single regime. Other jurisdictions are legislating on their own schedules, and sector regulators in financial services, healthcare, employment, and safety-critical products are issuing expectations that sit on top of general AI law rather than instead of it. But the fastest-moving source of requirements is not a regulator at all.
Customers ask first, and that is your real forcing function
Enterprise customers are already asking these questions in procurement questionnaires, years before any regulator would have, because they are managing their own supply-chain exposure and you are in their supply chain. Their questions arrive with less notice and carry a more immediate consequence: the penalty for a bad answer is not a proceeding, it is a lost renewal. Say that to your executive sponsor in exactly that form. The first entity to demand your AI documentation will almost certainly be a customer, the deadline will be ten business days, and the register is the difference between a four-day answer and a three-week fire drill during a renewal.
Closing Level 4
This lesson closes the chapter and the level. The Level 4 capstone is one board-ready deliverable: the Organizational AI-Readiness Strategy, assembled from the whole level. It contains the enterprise readiness heat map, the use-case portfolio and sequenced roadmap, the AI-ready data program, the sourcing and platform policy, the change plan for the 70 percent that is people and process, the governance charter with its stage gates, the value scorecard, and, from this lesson, the regulatory calendar and the Regulatory Readiness Register. Eight components, one document, one story: what we are ready for, what we will do, in what order, with what evidence, under whose accountability.
That document is what an AI Readiness Strategist produces. Level 5 asks a larger question. The strategist runs the program; the enterprise transformation leader owns the operating model itself, the funding across years, the org design that decides where AI capability lives, and the culture that determines whether any of it survives a leadership change. Gartner's forecast that over 40 percent of agentic AI projects will be canceled by the end of 2027 is not a prediction about technology. It is a prediction about operating models never built to carry the work. Level 5 opens with the transformation playbook: how a portfolio of pilots becomes an operating model.
What to Do Monday Morning
Six moves, in order. The first two matter most, and both are free.
- Start the inventory with the embedded-systems hunt. Pull procurement and expense records, walk the full vendor register, and send every function head one question: "what in your function produces a recommendation, a score, a ranking, a draft, a prediction, or a match that a person then acts on?" Give them ten days and a template with the six fields.
- Get provisional classifications from counsel for your top five. Take the five entries most likely to affect people or safety and book one hour. Ask for a dated working classification plus a note on what facts would change it. Your job is supplying facts, not proposing answers.
- Map your existing artifacts against what each classification would require. Use the nine evidence types, recording whether each artifact exists, when it was last refreshed, and where it is stored. You will likely find you own more than you thought, which is the point.
- Disable anything you cannot defend and do not need. If the hunt surfaces a people-affecting feature nobody deliberately enabled, switch it off pending review this week. It stops exposure compounding while you think.
- Back every gap's date off from its milestone by nine months. Find the milestone each gap plans against, subtract nine months, and put that start date and an owner's name in the register. A gap without a start date is a worry, not a plan.
- Add classification to your stage-gate 1 requirements. One line in the gate criteria: no use case passes gate 1 without a provisional classification and a register row. That is what keeps the register current for years without anyone being a hero about it.
Key Takeaways
- Reject the memo model of AI regulation: waiting for legal to send instructions produces a twelve-week scramble for artifacts that need nine months to assemble honestly.
- Recognize that nearly every compliance artifact is an operating artifact you already build, so readiness for a well-run program is an indexing job plus a finite gap list.
- Use the four EU AI Act dates as a planning instrument: GPAI since August 2, 2025, AI-content transparency from December 2, 2026, high-risk Annex III from December 2, 2027, and Annex I embedded systems from August 2, 2028, under the post-Digital-Omnibus calendar agreed in May 2026 and pending formal adoption.
- Apply the nine-month rule by working backward from every milestone, because evidence of testing, oversight, and monitoring is generated by operating properly and cannot be written retrospectively without reading exactly like it was.
- Build the inventory first and hunt embedded systems hardest, using procurement records, the vendor register, a no-blame shadow-AI census, and a function-head question about scores, rankings, drafts, and predictions rather than the word "AI."
- Record facts and route interpretation: capture purpose, data, decisions affected, human involvement, owner, and your role, then let counsel set a dated provisional classification from those facts.
- Maintain the Regulatory Readiness Register as the one document that answers "are we ready" for any regime on any date, with a row per system covering classification, owner, artifact set with currency dates, applicable milestone, and gap list.
- Make readiness a standing capability by naming the register's owner, reviewing it quarterly at the governance committee, requiring classification at stage gate 1, and assigning regulatory monitoring to a person, because customer questionnaires will demand these answers long before any regulator does.
Skill.re