←
AI Readiness & Process Transformation
Visionary · M6 · lesson 6 of 25 · queued
Preview — browse every lesson free. Enroll to mark lessons complete, open partner links and save your progress. Login & enroll →
📖
in this lesson

Enterprise AI Policy Across Functions and Borders

15 min

The question arrives on a Tuesday, inside a spreadsheet, as item 14 of a 62-item procurement questionnaire from a customer worth 11 million a year. "Describe how artificial intelligence is used in the processing of our data, including any AI-generated content in communications sent to us." One question. The account director forwards it to legal, legal forwards it to group risk, and group risk starts calling the regions. Over six weeks it discovers something that ends up compressed into one careful paragraph and one very bad meeting: the enterprise has no answer. It has eleven answers, one per region, and three of them contradict each other. Nobody was negligent. Everybody wrote a policy. That is exactly the problem.

Two Ways Enterprises Fail At This

Earlier in this program you built a policy that people actually follow: a one-page Rules of the Road in green, amber, and red, a reference document behind it for legal and audit, and enforcement wired into workflow rather than into memos. That artifact works, because a single organization has one legal environment, one risk appetite, one set of managers you can train in an afternoon, and one answer to any question a customer asks.

An enterprise has none of those things, and the difference is not one of degree. Four multipliers arrive at once. Functions carry genuinely different risk profiles: what human resources does with AI touches employment law, what customer operations does with it touches contracts and reputation, what internal analytics does with it touches almost nothing. Jurisdictions impose different and occasionally incompatible requirements on the same activity. Subsidiaries and joint ventures (a JV being an entity you co-own and do not unilaterally control) have their own boards and their own policies. And vendors arrive with policies governing what happens to your data inside their systems.

So this lesson is not about policy writing. You have that craft. This is policy architecture: what must be identical everywhere, what may legitimately differ, who decides which is which, and what happens when the answers collide. One boundary first, because it protects you. You are not giving legal advice and must never appear to. The strategist builds the structure and routes interpretation to counsel in the relevant jurisdiction. Your deliverable is the frame, the routing, and the discipline; theirs is what the law requires. Confusing the two is how a transformation leader ends up personally named in a finding.

Enterprises facing this reliably choose one of two shapes, and both fail in ways you can predict from the shape alone.

Failure one: unified maximalism

The first instinct is administrative tidiness: one policy for the whole group, every rule set to the strictest requirement that applies anywhere in it. If the most regulated market requires two-person review of AI-assisted customer correspondence, everyone does two-person review. If the most sensitive function forbids uploading any document containing a person's name, that becomes the group rule. Clean, defensible on a slide, and legal will sign it.

Then it meets the enterprise. A maintenance planner drafting a shift handover note is now subject to a control built for a regulated market she does not operate in and a data type she never touches. She does not read the rationale. She experiences the policy as absurd, and absurd policies do not produce compliance, they produce theatre: the checkbox gets ticked, the second reviewer signs without reading, and the real work moves to a personal account on an unmanaged device. The control level has not risen. The cost of sanctioned work has, while unsanctioned work sits exactly where it was.

The economics are the tell. A core rule is paid for by every entity in the group, including the ones for whom it is pointless, so unified maximalism spends the compliance cost of the most-regulated jurisdiction and the most-sensitive function on the entire population. S&P Global found 42 percent of companies scrapped most of their AI initiatives in 2025, and a meaningful share of that is not technical failure but legitimate use suffocated under controls built for a risk it never carried.

Failure two: federated drift

The second instinct is respect for local reality: let each entity write its own, because the people closest to the market understand it best. This is not stupid, and it is usually right about the facts. Local leaders do know their regulators, works councils, and customers better than any group function ever will, and the policies they write tend to be usable because they were written for the people who will use them.

What it destroys is the enterprise's ability to speak. Two years of federated authorship produces a group that cannot answer a basic question from a regulator, a customer, an auditor, or its own board. "What is our position on AI-generated content in customer communications?" has no answer, because there are eleven positions and no register listing them. Worse, nobody discovers this in a calm moment: it surfaces mid-procurement, mid-incident, or mid-due-diligence, when discovery is most expensive and least defensible.

Drift is not the absence of governance. Every one of those eleven regions has a policy, an owner, and probably a training deck. Drift is the absence of an interface between them.

DimensionUnified maximalismFederated drift
Where it is rightEnterprise answers as one voiceRules match local law and reality
What it costsStrictest-market cost on everyoneNo group answer to any question
How it failsTheatre, then routing aroundSilent divergence, found under pressure
Who notices firstLowest-risk teams, within weeksNobody, for about two years
The remediationException backlog nobody clearsEmergency unification under duress

The failure story: the eleven positions

Return to the questionnaire. That multinational had strong local autonomy by design, and when generative AI arrived each region was told to develop its own approach with legal support. Eleven regions, eleven approaches, all reasonable in isolation.

Item 14 required one group answer. Producing it took six weeks of archaeology and yielded three findings in ascending order of pain. Practice differed materially in three regions: one disclosed AI assistance in customer correspondence, one disclosed nothing, one used AI in correspondence but had told its own staff it did not. The group had no register, so the six weeks went on discovering its own policies rather than reading them. And, the reason the general counsel stopped sleeping, one region's honest answer described a practice that would have breached a clause in that customer's existing master agreement, undiscovered, for roughly eighteen months.

The remediation was an emergency group AI policy written to the strictest standard found anywhere, mandated in ninety days, with no local layer because there was no time to build one. The enterprise answered federated drift by inflicting unified maximalism on itself under duress, and every region that had been doing something sensible experienced it as punishment. Two years later the exception backlog stood at over sixty open requests.

The enterprise paid twice: once for the drift, once for the overcorrection. The architecture that would have prevented both would have taken one quarter of deliberate design, done calmly, before anyone was asking.

The Artifact: The Policy Architecture Map

The shape that works is neither pole: a small non-negotiable global core, a defined local layer with bounded discretion, a function overlay indexed by risk rather than geography, and an explicit interface between all three. If that sounds familiar, it should. It is the same core-and-variable logic the scaling lesson applied to workflows, now applied to rules: fix what the enterprise measures or answers for, bound what varies, write the boundary down before anyone tests it.

Your artifact is the Policy Architecture Map, one document in five parts: the three tiers and their contents, the allocation test that assigns any rule to a tier, the amendment path for each tier, the conflict-resolution rule with a named owner, and the register of every local and overlay variation in force. It is not the policy. It is the map of how the policy is built, the thing nobody writes and everybody later needs.

Tier one: the global core

The core is what must be identical in every entity, function, and market. Membership is decided by a question, asked out loud about every proposed rule: would a difference here embarrass the enterprise, break a group-level commitment, or make an enterprise-wide answer impossible? Call it the embarrassment test. If a rule can differ between two subsidiaries without any of those three consequences, it does not belong in the core, however sensible it is. A typical core runs seven to ten rules across one or two pages:

  • The prohibition list. The uses no entity may make of AI under any circumstances, short and absolute. A prohibition that varies by region is not a prohibition, it is a preference.
  • The classification scheme itself. Not the classifications, the scheme: the risk tiers, their definitions, and the questions that assign a system to one. The highest-value core item, because it lets the group speak one language about risk even where local answers differ. Gartner found 63 percent of organizations lack or are unsure of AI-ready data practices, so most groups cannot assume a shared vocabulary exists; the core supplies it.
  • The incident reporting obligation and its timelines. What counts as an AI incident, who it goes to, within how many hours. Divergent timelines make group-level incident response impossible.
  • Reconstructability. Every AI-touched decision must be reconstructable afterwards: what was proposed, what was decided, by whom, on what basis. The method may vary locally; the requirement may not.
  • The customer-facing disclosure position. Where the group stands on telling customers when AI has touched what they receive. This is item 14, answered in advance.
  • Human accountability. Every AI-touched decision has a named human owner, and no entity may deploy a system whose outputs nobody is accountable for.
  • The vendor commitment floor. What any vendor touching group data must contractually commit to, covered below.

Keep it short, and defend the shortness like a budget. During drafting the pressure is always additive: every function and region has a rule it feels strongly about, each individually reasonable. The embarrassment test is the only thing standing between a two-page core and a forty-page one nobody reads, and a forty-page core is unified maximalism arriving through the back door.

Tier two: the local layer

The local layer is jurisdiction-driven and legitimately different. It typically carries data residency and cross-border transfer constraints, employment-related uses where local law diverges sharply, works-council requirements that make deployment a consultation matter rather than a management decision, sector regulators with their own AI expectations, and market-specific disclosure requirements.

Here is the framing that matters most, and it is worth saying to your steering committee in these words: local variation is not weakness or fragmentation, it is accuracy. A group policy that flattens a genuine legal difference is not stricter than one that respects it. It is wrong, and it will either be quietly ignored or followed into a breach of a law the group function never read.

One drafting rule keeps the local layer governable rather than drift in a costume: local counsel drafts against the global core's section structure. Same sections, same order, same headings, different content. When Jurisdiction A's section 4 and Jurisdiction B's section 4 both address employee-related uses, the group compares them in a table, briefs a board in ten minutes, and answers item 14 by reading down a column. Comparable shape makes differing content a register entry; incomparable shape makes it archaeology.

Tier three: the function overlay

The third tier is the one most enterprises forget, and forgetting it generates the exception backlog. The function overlay is driven by risk profile rather than geography. Human resources, legal, finance, and customer-facing functions carry obligations that manufacturing and internal analytics simply do not: an AI-assisted screening decision in recruitment is a different animal from an AI-assisted throughput forecast, in every jurisdiction.

A policy indexed only by geography has nowhere to put those differences, so they arrive as exceptions: one at a time, through a committee, each argued from first principles, each producing a precedent nobody writes down. Twenty requests later you have an undocumented second policy, assembled by accident.

Making the overlays explicit converts that stream into a designed structure. Instead of "HR keeps asking for exceptions," you have an HR overlay: three to six rules for anyone doing AI-assisted work touching employment decisions anywhere in the group, owned by the function head, reviewed with governance. The queue shortens because the common cases are now rules. And the EU AI Act's high-risk regime for Annex III systems, applying from December 2, 2027 under the post-Digital-Omnibus calendar, lands on exactly these functions, so the overlay you build for internal coherence is also what a regulatory program attaches to.

Interface Mechanics: How The Tiers Actually Work Together

Three tiers on a slide is a diagram. What makes it an architecture is four mechanics, each written into the map rather than decided case by case in meetings.

The allocation test, applied consistently

Every proposed rule gets the same treatment: apply the embarrassment test, and if it fails, push it to the local layer or a function overlay. The subtlety that trips people up is that one subject often splits across tiers:

Proposed ruleTierWhy
"AI interaction records are retained for 24 months."LocalRetention periods are set by local law and regulators. A group number is either wrong somewhere or maximal everywhere.
"Every entity must have a defined, documented retention period for AI interaction records."CoreAn entity with no retention position at all is an answerability failure. The requirement passes the embarrassment test; the number does not.
"Systems are classified using the group's four-tier risk scheme."CoreShared language about risk is the precondition for group reporting, even though the same vendor tool may classify differently in two markets.

That third row is the one to internalize. The scheme belongs to the core; the classification outcome may legitimately differ locally. Enterprises that miss this either force identical classifications onto different legal realities or abandon the scheme entirely at the first divergence.

The strictest-applicable rule

When core, local, and overlay all speak to the same activity, which governs? Decide once, in the architecture, so nobody negotiates it per case: the most restrictive applicable rule governs. An HR manager in the second jurisdiction using an AI-assisted screening tool is subject to all three at once, and at every point of difference the tightest constraint applies.

The corollary makes it survivable politically, so state it in the same breath: entities may always be stricter locally, and must never be looser than core. That sentence gives local leaders genuine authority in the one direction that carries no group risk. They are not administering someone else's policy; they own real decisions about their market. It is the difference between an architecture local leadership defends and one it endures.

Never looser than the core, free to be stricter, and never silently different.

Amendment paths, distinguished by tier

Undefined amendment paths are how a global core silently becomes advisory. Somebody adjusts a core rule locally for a good reason, nobody objects, and eighteen months later the core is a suggestion of historical interest. Each tier gets its own path:

  • Core changes: group governance committee decision, rare, announced to every entity with an effective date and a version number. A core that changes more than a couple of times a year contains things that should have been pushed down.
  • Local changes: local counsel approves, and a notification goes to the group so the register stays current. Notification is not approval, and saying so keeps local authority real, but an unregistered local change is exactly the drift you built the architecture to prevent.
  • Overlay changes: function head plus governance, because an overlay crosses every geography and one function cannot unilaterally bind all of them.

Rate of change matters more than most expect. Gartner projects over 40 percent of agentic AI projects canceled by the end of 2027, a forecast about churn as much as failure: systems will enter and leave your estate faster than an annual policy review can track, and amendment paths built on a yearly cycle will always describe an estate that no longer exists.

The conflict-resolution rule, with a named owner

Sometimes a local legal requirement and a core rule genuinely conflict. Not "is inconvenient": following one means breaking the other. This is rare and it is real, and the architecture must anticipate it rather than treat each instance as a crisis.

Three components. Immediate escalation: the entity neither resolves it locally nor sits on it. A named person, not a committee: one individual, in the map by role and name, who owns the resolution and can convene counsel from both sides. A committee owner means a four-week wait for a meeting slot, and four-week waits are how entities learn to resolve conflicts quietly by themselves. Resolution published as precedent: answer, reasoning, date, filed where the next person will find it. This is the Level 4 precedent ratchet at group scale: each resolved conflict permanently shrinks the space of open questions, but only if it is written down.

Two Problems That Only Exist At Group Level

Subsidiaries, joint ventures, and the acquisition you just closed

A wholly owned subsidiary inherits group policy by ordinary governance. A joint venture does not: it has its own board and directors' duties, and your core reaches it only through what the shareholder agreement and the JV board adopt. Define the core rules that must appear in any JV's own policy as a shareholder position, negotiated at formation rather than discovered during an incident.

Acquisitions are the real and neglected case. A company you buy arrives with its own AI estate, its own shadow usage, its own vendor contracts, and zero alignment to your core. Nobody's integration checklist has an AI section, because it was written when the risks were systems, people, and premises. The first ninety days decide everything: an estate inventoried and aligned inside that window converges, while one left alone becomes a permanent exception defended on the grounds that this is how the business has always worked.

Add five lines to the integration checklist. This is the acquisition AI due-diligence list, short enough that no integration lead can refuse it:

  1. Inventory. Every AI-touched system in use, including those embedded in software nobody thinks of as AI.
  2. Classification. Run each through the group's risk scheme. This is the first real use of the core's shared vocabulary and it surfaces the prohibitions immediately.
  3. Contracts and data-use terms. What the acquired entity's vendor agreements permit the vendor to do with data, especially training on it. Note renewal dates: renewal is your leverage.
  4. Incidents. Any AI-related incident, complaint, or near miss in the last 24 months, and whether anything was disclosed to a customer or regulator.
  5. The shadow census. What people actually use, asked without threat of consequence, which is the only way to get a true answer.

That last line deserves its emphasis. MIT's GenAI Divide research documented a shadow AI economy: employees using personal AI tools for real work while official deployments stalled. In an acquired company mid-integration, where tooling is frozen and everyone is anxious, that shadow economy is reliably larger than in the parent. Meeting it with enforcement drives it underground on day one of a relationship you need to work for a decade. Use the fast path instead: bring us what you use, we will sanction what is safe, replace what is not, and prohibit only what must be prohibited.

Vendor policy interaction

Your policy binds your people. It has no reach at all over what happens to your data once it is inside a vendor's system: that is governed by the vendor's own policy and by your contract, and only one of the two is negotiable by you.

The architecture's answer is a core rule with contractual teeth: state once, in the global core, what any vendor touching group data must contractually commit to. The clauses came from the Level 4 vendor work (no training on your data without explicit consent, defined data location and retention, notification of material model changes, incident notification within a stated window, audit or evidence rights, exit with data return and deletion). The move is to elevate them from procurement preference to policy requirement, so procurement becomes an enforcement mechanism for the policy rather than a parallel process that occasionally disagrees with it. An entity that cannot obtain the floor now has a policy exception rather than a purchasing decision, and existing contracts get worked at renewal in a dated queue rather than in one doomed renegotiation program. A vendor that refuses has told you something useful about a risk you were carrying unknowingly.

Worked Example: Norvik Group Builds Its Map

Norvik Group is the 2,400-person business-to-business services and distribution company this level has followed: a scrapped year, then a governed rebuild, now several quarters into a funded program. Two things have changed: it operates in a second jurisdiction, and it has acquired a 260-person regional distributor. Every figure below is illustrative and rounded, a shape rather than a benchmark.

The core. Drafting ran one quarter, eleven working sessions, roughly 140 hours of internal effort plus counsel time in both jurisdictions. Twelve rules were proposed; nine survived the embarrassment test and became a two-page core. The three rejections are the more instructive half: a 24-month retention period (pushed local, since the number is a local matter while the requirement to have one stayed core), a mandatory second reviewer for all customer correspondence (pushed to the customer operations overlay, a function risk wearing a group costume), and a ban on AI-assisted candidate screening (pushed to HR overlay and local layer, since one jurisdiction's works-council process already governed it more precisely than a blanket ban). Three rejections in twelve is the discipline working, not the drafting failing.

The local layer. Two jurisdictions, both drafted by local counsel into the core's seven-section structure, differing in exactly three places: cross-border data transfer constraints, employee-related uses (the second jurisdiction requires employee-representative consultation before deploying anything touching individual performance), and one market-specific disclosure requirement. Because the structure is identical, the group register renders those differences as a three-row comparison table. Item 14 is now a document lookup, not an investigation.

The overlays. Three: human resources, customer operations, and finance, four to six rules each. In the two quarters after publication, exception requests to the governance committee fell from an average of nine per quarter to three, and those three were genuinely novel rather than repeats of a case already decided twice.

The acquisition, first 90 days. The inventory found 6 AI-touched systems, two of them under the core's prohibition list. One was stopped outright; the other was remediated with a human gate and re-classified, which took five weeks and kept a working capability alive rather than destroying it, a distinction the acquired team noticed. Three vendor contracts lacked the core's data-use terms and were queued to renewal: two vendors accepted the clauses, one refused and was replaced. The shadow census found unsanctioned tool use at roughly twice the parent's rate, handled with the fast path: 23 tools declared, 15 sanctioned within six weeks, 5 replaced, 3 prohibited with the reason explained in person. Zero disciplinary actions, deliberately, which is why the census was honest enough to be worth running.

The conflict, and how it resolved. Nine weeks in, a real one. The second jurisdiction's employment-law position on retaining individual-level employee records collided with the core's reconstructability rule: following the core meant keeping records the local position discouraged, following the local position meant an unreconstructable decision. The entity escalated the same week to the named owner in the map (the group general counsel, with the transformation director as convener). It resolved in nine days in favour of the stricter combination: the decision record keeps reasoning, system, date, and reviewing role, while the individual identifier sits separately under restricted access with a shorter retention window. The method was published to the register as precedent. When the same question surfaced in the acquired entity four months later, it took two days and one email.

Cost and return. One quarter of design, roughly 140 internal hours, counsel time in two jurisdictions. Against that: a six-week questionnaire response reduced to a lookup, an exception queue cut by two thirds, an acquisition integrated rather than exempted, conflict resolution down to two days. Compare the eleven-positions enterprise, which paid for the drift, paid again for the emergency unification, and still carries sixty open exceptions.

One note on sequencing. Norvik built the architecture ahead of the EU AI Act's AI-content transparency requirement from December 2, 2026 and its high-risk Annex III obligations from December 2, 2027, with general-purpose AI (GPAI) obligations already in force since August 2, 2025. That ordering was not luck: the architecture is the frame a specific regulatory program attaches to, and building the frame under deadline pressure is exactly the eleven-positions mistake. That program, for the regime with the hardest dates, is the next lesson.

What to Do Monday Morning

This is a one-quarter piece of work that starts with a single session and a whiteboard.

  1. Draft your global core, capped at two pages. Write every rule you believe must be identical everywhere, unfiltered. Expect fifteen to twenty candidates.
  2. Apply the embarrassment test to each one, out loud. Would a difference here embarrass the enterprise, break a group-level commitment, or make an enterprise-wide answer impossible? Push every failure to the local layer or a function overlay, and record where it went. The rejections are evidence the test is working.
  3. Write the strictest-applicable rule and its corollary into the architecture. Most restrictive applicable rule governs; entities may always be stricter, never looser than core. One sentence each, before the first dispute.
  4. Define the three amendment paths. Core to the governance committee with a version and an effective date, local to local counsel plus notification to the register, overlay to the function head plus governance.
  5. Name the conflict-resolution owner. A person, by name and role, in the document, with an escalation route that works inside a week. Not a committee.
  6. Add the five-line AI section to your acquisition integration checklist. Inventory, classification, contracts and data-use terms, incidents, shadow census. Send it to whoever owns the checklist this week, while no deal is live and the request costs nothing.
  7. Open the register. One table: every local and overlay variation in force, its owner, its date, its precedent entries. Embarrassingly incomplete on day one, and the document you will be most grateful for in eighteen months.

Key Takeaways

  • Recognize that one organization can run on one policy while an enterprise cannot, because functions, jurisdictions, subsidiaries and joint ventures, and vendor policies each multiply the problem in a different direction.
  • Reject both standard failures: unified maximalism imposes the strictest market's cost on everyone and buys theatrical compliance, while federated drift leaves an enterprise with eleven positions and no answer to one customer question.
  • Build the Policy Architecture Map instead: a short global core, a bounded local layer, an explicit function overlay, the allocation test, the amendment paths, the conflict-resolution owner, and the register of variations.
  • Apply the embarrassment test to every proposed core rule, because core rules are paid for by every entity including the ones for whom they are pointless, and hold the core to two pages of prohibitions, classification scheme, incident timelines, reconstructability, disclosure position, human accountability, and vendor floor.
  • Treat local variation as accuracy rather than fragmentation, and have local counsel draft into the core's section structure so the shape stays comparable where the content differs, which is what makes group reporting possible.
  • Make function overlays explicit for HR, finance, legal, and customer-facing work, converting a permanent stream of exception requests into a designed structure that the EU AI Act's high-risk obligations from December 2, 2027 attach to cleanly.
  • Write the strictest-applicable rule with its corollary (free to be stricter, never looser than core), give each tier a distinct amendment path, and name one person who owns genuine core-versus-local conflicts and publishes each resolution as precedent.
  • Run AI due diligence on every acquisition inside ninety days (inventory, classification, contracts and data-use terms, incidents, shadow census), meet the acquired shadow economy with a fast path rather than enforcement, and enforce the vendor floor through procurement at renewal.