Norvik Group's general counsel has been in the room eleven minutes and has said exactly one sentence that matters. On the screen is the Regulatory Readiness Register the transformation office built last year: nineteen AI-touched systems, each with a provisional classification and a note on what evidence might be needed. She studies it, then says: "This is good work. I can tell you what most of these systems are, and I will tell you formally once I have the last four vendor documents. What I cannot tell you is whether this company can produce the evidence those classifications imply before the dates arrive. That is not a legal question. That is a program question, and it is yours." The room goes quiet in the way rooms do when a large piece of work has just moved from one desk to another, correctly. She is right, and the second half of what she said is this lesson: the register was preparation, and preparation is not a program.

From a Register to a Program

You already did the preparation work. You hunted the inventory, including systems nobody thought of as AI because they arrived inside a product someone bought. You wrote provisional classifications and a gap list. You built the artifact map that showed the encouraging truth: a well-run transformation program already produces most of the evidence a regulator would want, because risk assessment, human gates, testing, monitoring, and audit trails were built for operational reasons long before anyone mentioned a statute. That is the Regulatory Readiness Register, and it is genuinely valuable.

It is also, on its own, a document. What separates a ready organization from one that merely has a register is the thing every transformation leader knows how to build and strangely often does not build here: a program, with named workstreams and owners, deliverables with dates, and a status view a board can read without translation.

And here is why it matters more here than elsewhere. In a transformation portfolio, every date is negotiable if the sponsor decides it is. The deployment slips a quarter. The migration moves to next year. The efficiency target gets rebaselined with an apologetic slide about market conditions. Regulatory deadlines are the only dates your sponsor cannot renegotiate: the steering committee has no vote, the chief executive has no vote, no escalation produces more time. Everything else is scheduled forward from capacity; this is scheduled backward from a date that does not move.

The calendar you plan against

The EU AI Act's obligations phase in on a published calendar. Under the post-Digital-Omnibus package agreed in May 2026 and pending formal adoption, four milestones structure most enterprise programs.

Treat that table like a customer's contractual delivery schedule: fixed input to planning, not a topic. And treat those dates as the only regulatory specifics you carry in your head. Everything else about the Act, which category a system falls into, whether an obligation applies to you at all, what role you occupy, and what each obligation actually requires, is a determination, and determinations belong to counsel.

The two ways this gets run badly

Almost every failed AI compliance effort takes one of two shapes, both made of competent people working in the wrong structure.

The legal project. The obligation lands with legal, who do what legal do well: a thorough analysis, a careful reading, a defensible classification. The work is correct. It is also produced at a distance from the systems it governs, by people who cannot see whether the evidence it assumes actually exists. Operational impossibility gets discovered late, usually when someone finally asks an engineer a question and gets an answer nobody wanted.

The engineering checklist. The obligation lands with a technical team, who convert it into tickets, close them, and report a percentage. It is fast and feels productive. It also quietly makes a dozen judgment calls that were never theirs: whether a system falls in a category, whether the organization acts in one role or another, whether a disclosure suffices. Those calls end up in a ticket comment, a terrible place for a legal position to live.

The structure that works pairs them, with an interface written down before it is needed. Counsel owns determinations: applicability, classification, role, interpretation. The transformation leader owns the program: workstreams, evidence, schedule, operational readiness. Neither does the other's job, and the boundary is an artifact rather than a habit. Say it out loud in the kickoff and every time someone asks a question beginning "do you think this counts as": you are not counsel, this is not legal advice, and nothing in your program determines what the law requires. Your program determines only whether, on the day counsel needs evidence and a regulator or customer asks for it, the evidence exists, is current, and can be found.

Compliance analysis is a deliverable. Compliance is a schedule.

The Artifact: The Compliance Program Plan

The deliverable is deliberately unexotic: a Compliance Program Plan with five workstreams, each with one named owner, its deliverables, and a schedule backed off from the milestone dates, plus a RACI (the responsibility chart naming who is Responsible, Accountable, Consulted, and Informed for each decision) that keeps the counsel and operations boundary clean. Five is the smallest set that covers the work without a deliverable falling between two owners.

Workstream 1: Inventory and classification

Owner: the register's owner, with counsel. Deliverables: a complete and, more importantly, maintained inventory of AI-touched systems including embedded and acquired ones, each carrying counsel's determination of applicability and role, plus the mechanism keeping it current.

The preparation lesson taught the hunt. This one teaches maintenance, because a stale inventory is worse than none: it creates documented confidence in a picture that no longer matches reality. The enterprise question is not "did we find everything in March." It is "who notices when a vendor adds an AI feature to a product we already own." That is now routine, and nobody raises a procurement request because nobody procures anything: the capability arrives inside a product you already pay for, in a release note seen by a system administrator and no one else.

You already built the detector, for a different reason. Vendor monitoring exists to answer "what happens to us when this vendor changes, and how quickly will we know." Repurpose it: add a standing question to the vendor review calendar asking whether the vendor has added, enabled, or materially changed an AI capability in your instance since the last review, and route any yes to the register owner. That costs a line in an existing process and closes the largest source of inventory drift in a modern enterprise. The other half is your intake gate, where the first stage gate of any initiative asks the classification question. Detection at the front door plus detection in the installed base is the maintenance program.

Workstream 2: Documentation and evidence

Owner: the transformation leader. Deliverables: for each in-scope system, the evidence set its classification implies, assembled where possible from what the program already produces.

This is the workstream with the best news and the most work. The good news: a governed transformation program already generates most of the raw material. Risk assessment comes from the AI-FMEA (Failure Modes and Effects Analysis, adapted for AI steps). Oversight design comes from your human gate specifications, which record who reviews what and with what authority to reject. Testing comes from the four test suites (golden transcripts, failure injection, edges and boundaries, the hostile day). Monitoring comes from the weekly quality regime and drift watch. Decision reconstruction comes from the audit trail. Data governance comes from the data program you built to fix the 63 percent problem, Gartner's finding that most organizations lack or are unsure of AI-ready data practices.

So the work is not mostly authorship. It is mapping: taking each evidence category counsel identifies, pointing it at the artifact that already satisfies it, finding the small number of places where nothing exists yet, then closing those gaps on a schedule. What matters most here is not any single document but the per-system evidence index: one page per in-scope system listing each required evidence category, where that item physically lives (system, repository, folder, owner), the date it was last confirmed current, and who maintains it. That page turns a pile of artifacts into a defensible position, and a two-week fire drill into a two-hour retrieval when a customer's audit team or a regulator's questionnaire arrives. Later in this chapter, the auditability lesson builds this evidence layer properly, as a standing capability rather than a compliance byproduct. For now, build the index and accept that it is imperfect: an index saying "we do not have this, here is the owner and the date to close it" beats silence.

Workstream 3: Transparency and disclosure

Owner: shared between product and communications on one side and the transformation leader on the other. Deliverables: identification of every place AI-generated or AI-assisted content reaches a person outside the organization, and a decided disclosure approach for each, dated against the December 2, 2026 transparency milestone.

Enterprises consistently underestimate this workstream, and the reason is instructive: it is not technical, so it does not get technical attention, and the people who would notice its surface area do not sit in the governance meeting. AI-assisted content reaching customers is not confined to the product. It is in marketing copy, in service replies drafted by an assistant and lightly edited, in reports and proposals going out under a person's name, in translated documentation, in website chat. Much of it was somebody discovering a feature and using it, the shadow adoption pattern described since Level 1.

Find it with a communications-side sweep, not a technical one. Ask by channel rather than by system: what leaves this organization and reaches a customer, a candidate, a supplier, or the public, and is any of it produced or materially assisted by AI? The people who can answer own the channels and rarely sit in your governance forum. Then decide, for each place found, what is disclosed, where, in what words, and who keeps it accurate.

Plan for the long pole to be decision-making, not engineering. Putting a line of text on a page is a day of work. Agreeing what it says, how it sounds in the brand voice, whether it undermines a sales narrative, and who signs off, is where the calendar goes. Six weeks of debate over one sentence is normal. Start early: the transparency date arrives first.

Workstream 4: Third party and supply chain

Owner: procurement, with the transformation leader. Deliverables: the documentation the organization needs from vendors, secured contractually rather than requested politely, plus an assessment of what it owes its own customers who are asking the same questions.

The first half is familiar from vendor risk work: you cannot produce evidence about a system you did not build unless the party who built it gives you what you need, and goodwill is not a control. Put the documentation obligation, the notification obligation when a vendor materially changes an AI capability, and the evidence-support obligation into the contract at renewal, the one moment you have real leverage.

The second half is the insight that makes this workstream efficient, and most enterprises miss it for a year. You are simultaneously downstream of your vendors and upstream of your customers. The same week procurement drafts questions for a software supplier, your sales team is handed a fourteen-page AI questionnaire by a customer wanting exactly that information about you. Those are, in substance, the same document pointed in opposite directions, so stop building them separately. Take the questionnaire your largest customer sent, almost certainly drafted by a well-resourced risk function and therefore a free view of what sophisticated buyers consider material, and use it as the template for what you send vendors. Then use your answers as the specification for your evidence index: every question you struggled with is a gap with a name.

Workstream 5: Operating readiness

Owner: the transformation leader. Deliverables: the people and processes that must exist and be working when obligations apply.

This workstream converts documentation into compliance, and it is most likely to be skipped because it produces no impressive artifact. Four questions define it. Who monitors the in-scope systems, on what cadence, with what authority to stop one? Who coordinates the response when an authority or customer asks a question, and how fast? How does the organization recognize that an incident has crossed a threshold triggering an obligation, and how does that escalate? And who is trained for the roles that carry obligations, as opposed to the awareness training everyone received?

The third question already has an answer you built. Your incident playbook's most serious severity tier is defined by money moving wrongly, safety being implicated, or a regulatory obligation being touched, with counsel joining the response. That regulatory-touch branch is the recognition mechanism; this workstream adds specificity. For the systems counsel places in scope: what conditions plausibly reach that branch, who is empowered to call it, and how fast escalation moves at 4pm on a Friday. A ninety-minute tabletop finds more real gaps than a month of drafting.

Hold on to the sentence that justifies this workstream: a documented control that nobody operates is a finding waiting to happen. It is worse than an acknowledged gap, because the organization has written a claim its own operation contradicts, and every auditor goes looking for exactly that difference.

The Program Mechanics: Dates, RACI, and a Status a Board Can Read

Date-backed scheduling and the nine-month rule

Take each milestone, list the deliverables due by it, and back each one off by its honest lead time: what you would defend to a skeptical peer, including review cycles, stakeholder disagreement, the holiday period, and the two weeks that always disappear.

Then do the thing that reshapes most plans. Sort your evidence into two kinds. Some can be written: a design document, a risk assessment, a procedure, an oversight specification. Written evidence has a lead time in weeks and is largely under your control. Other evidence can only be generated, by operating the system over time and capturing what happens: monitoring records, sampled quality results, drift observations, near-miss history, logs holding the inputs a decision rested on and not only the outcome. Generated evidence cannot be compressed. You cannot write four quarters of monitoring history in March. If the instrumentation was off, the record does not exist and no budget conjures it.

That gives the program its central scheduling insight. The critical path is almost never documentation. It is evidence generation. As a rule of thumb, treat evidence that must be generated by operating a system as needing roughly nine months of live operation before it is dense enough to show: the nine-month rule. It is a planning heuristic drawn from how long a monitoring regime takes to build a defensible record, not a legal standard. The consequence is what matters: instrumentation and sampling changes belong nine to twelve months before a milestone, when the date still feels distant and the work feels premature. Leaders who discover this at the three-month mark, as drafting begins, cannot recover it. Their options are to run the system without the record, suspend it, or disclose the gap.

The RACI that keeps the boundary clean

Write this before the first determination is needed, not after the first argument.

The failure this prevents is common, feels harmless, and hurts. Counsel is slow, because counsel is careful and busy. A question comes up in a Thursday program meeting: does this system count. Everyone looks at the transformation leader, who has read more about this than anyone present and has a program to keep moving. The leader says "I think we are fine there, treat it as out of scope and move on." That sentence enters the minutes and becomes a documented organizational position, taken by an unqualified party, that the company may be unable to defend and will certainly have to explain. The RACI exists to produce a different sentence: "that is a determination, it goes on counsel's list this week, and until then the plan carries it as in scope."

Status the board can read

Report readiness per milestone, not per task. Four columns are enough: systems in scope, evidence complete (a count, not a percentage of effort), open gaps with a named owner and date, and the honest ambers. A non-specialist director should absorb it in ninety seconds and ask a good question, which is the whole test.

The disclosure discipline this level teaches applies here with more force than anywhere else, because the temptation to report green peaks: nobody wants to tell a board that a regulatory workstream has an amber. Adopt the rule before you need it: every amber is named, owned, and dated, and an amber standing for two consecutive reports is escalated as a decision, not repeated as a status. A board that hears two specific ambers with owners and dates has been told the truth and can help. A board that hears "on track" for four quarters and then hears about a problem has been handled, and will remember it. Given that 42 percent of companies scrapped most of their AI work in a single year according to S&P Global, your credibility is a limited resource. Spend it on the truth.

Norvik's Program, and the Analysis That Arrived Too Late

Norvik Group is the 2,400-person business-to-business industrial distributor this level has followed: six functions, a scrap year behind it, a governed operating model in year two. The numbers are illustrative; reuse the shape, not the figures.

The starting position. Nineteen systems in the register. Counsel's determinations place three in categories requiring the fullest evidence sets, twelve outside those categories with a documented rationale, and four pending because the vendor documentation has not arrived. The program carries the pending four at the higher assumption until determined, which costs preparation effort and removes the chance of a late surprise. Five workstreams get five named owners and a plan backed off from the two nearest milestones.

The finding that reshaped the plan. In week three, the evidence workstream maps required categories against existing artifacts for the three heaviest systems and finds two that need operating evidence the program is not generating: one logs outcomes but not the inputs behind them, the other has a human review gate that operates reliably and leaves no record of what was reviewed or why. Both gaps are small in engineering terms, a few weeks of instrumentation and a change to how the gate is recorded, and fatal in scheduling terms, since the record cannot be backfilled. The old plan started drafting three months before the date. The new plan makes the instrumentation and sampling changes eleven months ahead, the nine-month rule in action, and it feels to everyone involved absurdly early. That feeling is the point.

The transparency surprise. The communications-side sweep, run by asking channel owners rather than system owners, finds fourteen distinct places where AI-assisted content reaches customers. Nine were on nobody's list: two email templates, a translated datasheet, meeting summaries sent to clients, a chat widget's canned responses, and four others of the same modest kind. None is dramatic. Collectively they are the workstream. The technical sweep, run first, had found five.

The symmetry paying off. In the second quarter a large customer sends Norvik a fourteen-page AI governance questionnaire as a condition of renewal, and Norvik answers it badly in four places. In the third quarter procurement sends its vendors a lightly edited version of that same questionnaire, and those four questions become the four it asks first.

Status and cost. The board sees a one-page readiness view per milestone with two ambers named, owned, and dated: the four pending vendor determinations, and one system's evidence index still incomplete. Running cost is roughly 0.6 of a full-time equivalent across the five owners, plus counsel time. On its own that sounds like overhead. Against the alternative, a final-quarter scramble competing for the same scarce engineering capacity as everything else in the portfolio, with suspending a production system as a live option, it is one of the cheapest lines in the plan.

The failure story: an excellent analysis, nine months late

Now the other version, drawn from a pattern that repeats across the market. A mid-sized manufacturer assigns AI Act readiness to its legal team. The team is good. Nine months before a milestone they deliver a 60-page analysis: a careful reading of the obligations, a classification of every system the company knows about, and a mapping of the evidence each classification implies.

The analysis assumes evidence that does not exist. It assumes testing records for a system never systematically tested, because it went into production during the enthusiasm phase and worked well enough that nobody revisited it. It assumes oversight documentation for a human review gate that operates diligently and leaves no trace, living in a supervisor's judgment and a verbal handoff. It assumes decision logs for a system that records outcomes but not the inputs behind them, a choice an engineer made three years ago for sensible storage reasons.

None of that surfaces during the writing, because the analysis is built from documentation and from interviews with system owners who answer "yes, we review those" in good faith, meaning something different by it than the document means. It surfaces in month ten, when operational teams are asked to gather evidence and start asking what exactly is wanted. Then the arithmetic runs: the honest lead time to instrument the logging, run the tests, formalize the gate, and accumulate a monitoring record of any density is longer than the calendar remaining. The options narrow to suspending two systems, or a documented gap accepted at board level and disclosed to the customers asking.

Notice what did not go wrong. The legal work was correct. The classification was sound. The people were competent and not late by their own measure: nine months sounds generous for a document. What went wrong is that nobody ran it as a program with operational lead times, so a correct answer arrived past the point of action. This is the failure this certification keeps documenting in other clothes: MIT found 95 percent of enterprise generative AI pilots delivering no measurable return not because the technology failed but because the organization around it never changed, and Gartner expects over 40 percent of agentic AI projects canceled by the end of 2027 for mostly organizational reasons. Compliance fails the same way. The analysis is not the compliance. The schedule is.

One Program, Many Regimes, and the Customer Who Arrives First

Everything above is framed around one statute because it has the clearest published dates. Do not build for one statute. AI obligations are proliferating across jurisdictions and sectors, and any enterprise in more than one market or a regulated industry will answer to several regimes with overlapping but non-identical demands. A separate program for each doubles cost and halves accuracy.

The design that survives is simple to state and hard to hold: keep the evidence layer regime-agnostic, and map it per regime. Your risk assessments, gate specifications, test records, monitoring data, audit trails, and data lineage are facts about how your systems are built and run, not artifacts of any law. Maintain them once, in your own structure, at the quality your operation needs. Then keep a thin mapping layer per regime: this requirement is satisfied by that evidence, here is where it lives, here is what is missing. A new regime means a new map, not a new program.

There is also a practical point most enterprises feel before any regulator contacts them: the forcing function that arrives first is commercial. Customers are writing AI governance requirements into contracts and renewals now, ahead of enforcement, because their own risk functions told them to. The questionnaire lands with a procurement deadline and a deal on the other side of it. An organization that answers fourteen pages in two days from a current evidence index has turned a compliance program into a sales asset, and for many that, not the statutory deadline, is what pays for the work.

One last framing before Monday. Everything here is the floor: the minimum an organization must demonstrate about how it builds and runs AI. Clearing a floor is not a virtue, and a program built only to clear it stays reactive, waiting to be told what to do next. The next lesson is what sits above the floor: responsible AI as an operating discipline that produces its own standards rather than importing them, which is the difference between an organization that complies and one that can be trusted.

What to Do Monday Morning

1. Convert your register into five workstreams with named owners. Split its contents across inventory and classification, documentation and evidence, transparency and disclosure, third party and supply chain, and operating readiness. One name per workstream, a person not a function. If you cannot name someone today, that is the workstream that will fail: appoint a provisional owner and put the permanent naming on the governance agenda.
2. Back each milestone's deliverables off by honest lead times and find your evidence critical path. For the nearest two milestones, list what must exist, sort each item into written evidence and evidence that must be generated by operating a system, and apply the nine-month rule to the second list. Whatever comes out earliest is your critical path, almost certainly instrumentation rather than authorship. Start it this month even though it feels premature.
3. Write the counsel and operations RACI before the first determination is needed. One page, four rows, one sentence to the program team: determinations go to counsel, and until counsel answers, the plan carries the item at the higher assumption. Agree it while nothing is urgent, because its value is in what it stops someone saying three months from now.
4. Run a communications-side sweep for AI-assisted content reaching customers. Not a technical inventory: go channel by channel and ask the channel owners what leaves the organization and whether any of it is produced or assisted by AI. Expect roughly twice what a technical sweep finds, most of it unremarkable, and expect the wording debate to outlast the change itself.
5. Send your vendors the questionnaire your customers sent you. Find the most recent AI governance questionnaire your organization received, use it as the template for what procurement sends your own AI-touched vendors, and treat the questions you struggled with as the specification for your evidence index. Highest-value hour here, and it needs no new document.

Key Takeaways

• Treat regulatory deadlines as the only dates a sponsor cannot renegotiate, and plan backward from them, not forward from capacity.
• Plan against the published calendar: GPAI obligations since August 2, 2025, AI-content transparency December 2, 2026, high-risk Annex III systems December 2, 2027, Annex I embedded systems August 2, 2028, under the post-Digital-Omnibus package agreed May 2026 and pending formal adoption.
• Refuse both default shapes: the legal project, correct but disconnected from the systems it governs, and the engineering checklist, fast but quietly making calls that belong to counsel.
• Build the Compliance Program Plan as five owned workstreams: inventory and classification, documentation and evidence, transparency and disclosure, third party and supply chain, operating readiness.
• Separate written evidence from evidence generated by operating a system, and apply the nine-month rule: instrumentation belongs nine to twelve months before a milestone, because a monitoring record cannot be backfilled.
• Write the counsel and operations RACI before the first determination is needed, so nobody turns a meeting opinion into a documented position the company cannot defend.
• Exploit the supply chain's symmetry: the AI questionnaire a customer sends you is roughly the one you should send your vendors, and the questions you answer badly are your evidence gaps.
• Keep the evidence layer regime-agnostic and map it per regime, expecting customer contracts, not regulators, to be the forcing function that arrives first.