Skip to content

Large enterprise (500+)

Audience. CIO, CISO, Chief Risk Officer, Head of Engineering, BU engineering leaders, board audit-committee chair. Constraints. Regulators are watching. The board is asking quarterly. At least three business units have already started independent AI rollouts, and at least one of them did not tell the others. Every artifact has to survive a leadership change.

The enterprise tier is not "mid-size with more people." It is a fundamentally different problem: how to land a single coherent program across multiple business units, jurisdictions, and risk profiles, when parts of the organization have already started without you. The framework treats enterprise adoption as a multi-BU coordination problem with a governance backbone, not a single rollout with a bigger headcount.

Sizing guide for this page

Enterprise in this framework is roughly 500+ engineering-adjacent headcount, with multiple business lines and at least one of: multi-jurisdiction operation, public-market reporting obligations, or a board with outside directors. If a sector regulator can write to you tomorrow, read Public sector & regulated in parallel; the regulated tier supersedes this one for affected workloads.

The multi-BU coordination problem

A single global policy that satisfies a high-volume retail BU, a regulated banking BU, and a research BU does not exist. Every enterprise program that has tried to ship one has either produced something so restrictive that engineers route around it, or so permissive that the strictest BU cannot adopt it.

The framework's stance: a single charter, multiple per-BU policies.

Layer Owned by Examples
Group AI charter CIO + CISO + Chief Risk Officer Principles, stop conditions, what the company will and will not commit to publicly, decision-rights model.
Group AI standards Group governance forum Vendor standards, AUP framework, audit-trail expectations, regulatory crosswalk.
BU AI policy BU engineering + BU Legal/Risk The AUP applied to the BU's data classes, regulatory exposure, and customer commitments.
System-level controls Engineering teams within the BU Tier-specific controls, prompt patterns, review gates.

The charter is short (1–2 pages) and is the only thing that requires group-level sign-off. Everything below it is delegated. The charter's single most important sentence is the delegation clause: which decisions live where, and who can override.

A workable delegation pattern

The Group charter sets stop conditions, the public-commitment policy, and the principle that every BU must classify systems before permitting AI tooling. It does not name approved tools, prescribe a specific verification level, or set per-BU adoption targets. Those decisions are delegated to the BU AI policy, which is reviewed by the Group governance forum but signed by the BU.

The risk in centralising too much: a six-month decision queue at Group level. The risk in centralising too little: every BU re-litigates first principles and the company has nothing coherent to tell a regulator. The charter draws the line.

Governance depth

At enterprise tier, governance depth is non-negotiable. The artifacts in the Governance overview are all in scope, in their full form.

Full RACI

A board-grade RACI covers at minimum:

  • Tool additions and removals (group + per-BU concurrence).
  • AUP changes (Group standards; BU adoption).
  • Vendor contract reviews and DPA refreshes.
  • Incident response (AI-adjacent severities aligned to the company's IR framework).
  • Program pause / stop authority.
  • Board reporting (who briefs, what cadence, what content).
  • Regulator engagement (when to engage, who signs).

The Group AUP is a versioned policy with a numbered review cycle (typical: quarterly minor, annual major). Legal sign-off is mandatory for major revisions. BU adoption is documented; opt-outs are documented and expire.

Vendor standards expecting attestations

Approved vendors satisfy a published set of attestations. Common expectations at this tier:

  • SOC 2 Type II: current report, no material exceptions in AI-relevant controls.
  • ISO/IEC 27001: current certificate covering the relevant scope1.
  • ISO/IEC 42001: increasingly expected for AI-system providers as the AI management standard matures2.
  • Signed DPA with current sub-processor list and a notice clause for changes.
  • EU AI Act alignment (where relevant): provider documentation, log retention, transparency obligations3.
  • Region of inference documented per workload class.

Board reporting cadence

Quarterly is the default. The board pack contains:

  • Program status against charter success criteria.
  • Material incidents (AI-adjacent) and root causes.
  • Adoption and quality metrics by BU (SPACE + DORA + DevEx).
  • Regulatory developments and the company's response.
  • Vendor changes (entries, removals, contract events).
  • Forward decisions requiring board awareness or input.

Frameworks at enterprise: S.H.I.E.L.D. is platform-enforced

All eight named frameworks are in scope. The single biggest difference from mid-size is that S.H.I.E.L.D. is enforced at the platform layer, not at the policy layer. Policy enforcement at this scale leaks; platform enforcement does not.

Control Mid-size posture Enterprise posture
Agent execution environment Local or vendor-hosted, ad hoc. Sandboxed environments, isolated network, no production write access by default.
Model endpoints Per-tool, per-team. Allow-listed at the network layer; calls to non-approved endpoints fail closed.
Egress Trust-and-monitor. Controlled egress, DLP rules on prompt content, regulated-class data classes blocked at proxy.
Prompt logs Per-tool. Centrally aggregated, indexed, retained per audit-trail policy.
Identity SSO. SSO + SCIM + per-tool conditional-access policies.

This control set requires platform-team investment. The right time to fund it is before the first incident; the trigger is most often the first board question that begins "what would happen if…"

The shadow rollout problem

By the time enterprise leadership formally launches an AI-coding program, 30% or more of engineers are typically already using AI tools: sometimes on personal accounts, sometimes via a forgotten free-tier sign-up, sometimes through a BU that piloted independently a year ago.

Pretending the shadow rollout did not happen is the worst available move. It guarantees that the formal program lands in a culture that treats it as theatre, and it guarantees that the first incident comes from a tool nobody knew was in use.

The framework's recommended sequence:

  1. Acknowledge. State publicly (internally) that the company knows AI tools are already in use and that the goal is not to punish prior use, but to bring it under a coherent program.
  2. Survey. Run an anonymous survey, cross-reference against SSO logs and network egress data, and produce a real picture of current use. Do not rely on self-disclosure alone.
  3. Amnesty window. Define a fixed-duration window (typically 30–60 days) during which engineers can declare prior AI tool use and migrate to the approved tool set without disciplinary consequence.
  4. Migrate. Provide a clear path: approved tools provisioned, prompt libraries portable, AUP training delivered, removal of the prior tool with a deadline.
  5. Enforce after the window. Once the window closes, use of non-approved tools is treated as an AUP violation. The amnesty was the chance; the enforcement is the program.

The amnesty conversation has a script

Engineers will ask: "what about the code I already merged that was AI-generated?" The honest answer: nothing happens to it retroactively. What changes is the next merge. The framework's audit-trail policy applies forward; historical reconstruction is best-effort.

The shadow-rollout move that almost always fails is a quiet crackdown: a sudden, unannounced enforcement against a tool the company has tolerated for a year. It produces an internal-trust crisis that lasts longer than the rollout itself.

Measurement maturity

At enterprise tier, measurement is structured, multi-source, and baselined per BU.

What gets measured

  • DORA four key metrics (deployment frequency, lead time, change failure rate, MTTR) per BU, monthly4.
  • SPACE dimensions (satisfaction, performance, activity, collaboration, efficiency) quarterly, role-disaggregated5.
  • DevEx signals (feedback loops, cognitive load, flow state) per team, quarterly6.
  • AI-program-specific: adoption depth (sessions per developer per week, not just yes/no), revert-within-14-days, AI-adjacent incident count, prompt-class distribution if logged.

What does not get reported up

  • Acceptance rate of suggestions (a vanity metric; a tool that suggests obvious imports has a higher acceptance rate than one that suggests real implementations).
  • "Lines of AI-generated code" (a proxy for how generative the tool is, not how useful it is).
  • Self-reported productivity uplift (typical inflation of 30–50% relative to measured outcomes; see DORA 2024).

The anti-patterns page covers this in depth.

Per-BU baselining

Each BU baselines its own metrics before the AI program lands, so the program's effect is measurable. Baselining must use the BU's normal work, not a curated sample. This sometimes delays a BU's onboarding by a quarter; the delay is worth it.

Agentic cost governance

Agentic coding tools bill on consumption, not seats. A single active agent session can consume in hours what a seat licence costs in a month. Budget assumptions made for seat-licensed AI tooling will be wrong for agentic tooling. Uber's 2026 AI tooling budget ran out within four months before the company implemented per-tool monthly caps — usage patterns bearing no relationship to delivery outcomes drove the overshoot [secondary]7.

Three controls prevent the spiral before it starts:

Per-tool monthly caps per engineer. Set a spending limit for each approved tool independently, not as a combined pool. A combined pool allows one high-consumption tool to crowd out others before the overrun is visible. Caps require annual calibration; set conservatively and relax on evidence, not generously and tighten in crisis.

Pre-approved budgets for long-running agent sessions. For agent-mode tasks — multi-step, multi-turn sessions that run autonomously for minutes or hours — require a brief pre-session estimate above a defined threshold. This is a speed bump for the session types most likely to produce surprise invoices, not a bottleneck on routine inline completion.

No consumption-based leaderboards. Ranking engineers or teams by tool spend, token consumption, or raw usage volume rewards model input, not delivery outcomes. The developer who spends $800 re-prompting an agent to produce reverted code ranks higher than one who spends $200 on precise, high-leverage prompts. See anti-pattern #9 in the measurement anti-patterns catalog.

Audit trails and evidence

Audit-trail expectations at enterprise tier are documented in Audit trail and summarised here.

Evidence class What is captured Retention Reviewer
Prompt and response logs Per session, per user, per tool. ≥ 1 year (regulated tier may extend). Sample-reviewed quarterly by AppSec.
Tool access logs SSO + tool-side logins, model selection, agent invocations. ≥ 1 year. Reviewed monthly by IAM.
Diff provenance PR-level annotation: AI-assisted (yes/no), tool, primary prompt class. Forever (with the repo). Engineering.
Incident records Every AI-adjacent defect, near-miss, leak attempt. Forever. IR + Risk.
Vendor evidence DPAs, sub-processor lists, attestations, contract events. Per Legal retention policy. Legal + Privacy.
Regulatory correspondence Inquiries, responses, voluntary disclosures. Per regulator. Legal + Risk Committee.

The retention values above are floors. Specific regulators or contractual obligations push them higher; see Regulated.

Common failure modes

Enterprise patterns to avoid

  • Trying to ship one global policy. A single global AUP that tries to satisfy retail, banking, and research BUs ends up satisfying none of them. Use a charter + per-BU policies.
  • Lock-down before pilot. Building the full S.H.I.E.L.D. platform, the full RACI, and the full audit pipeline before a single squad has piloted produces a year of platform work whose requirements are guessed, not learned. Pilot first, build the platform around what the pilot proved necessary.
  • Ignoring the shadow rollout. Every quarter the formal program delays is a quarter the shadow rollout grows. The amnesty window is the cheapest move available; refusing to run one is more expensive than running one.
  • Single-vendor lock-in without an exit plan. Most enterprises will end up with 2–3 standard tools, not one. A program that depends on a single vendor's roadmap, pricing, or model choice becomes a procurement crisis the day that vendor changes terms. Build prompts and pipelines for portability from day one.
  • Self-reported metrics in the board pack. "82% of engineers report feeling more productive" is not a board-grade claim. Pair every sentiment metric with an outcome metric (DORA, change failure rate, escape defects). Klarna's reversal in 2025 is a cautionary example of acting on sentiment-shaped narratives without the outcome data to support them8.
  • Treating the program as a one-time launch. The frameworks and governance are not a launch; they are a steady-state with a review cadence. Programs without a review cadence drift back to shadow-rollout conditions in 18–24 months.
  • Confusing "vendor enterprise tier" with "your governance." A vendor's enterprise tier offers a contract; it does not offer your AUP, your audit trail, or your incident process. Mid-size organizations sometimes blur this; enterprises cannot afford to.
  • Setting a flat annual budget for consumption-based tools. Agentic tools bill on token consumption, not seats. A flat annual envelope that worked for seat-licensed AI tools will be exhausted within months as agentic adoption grows. Set per-tool monthly caps per engineer from day one and calibrate them annually.

A 12-month enterprise rollout sequence

Quarter Move Output
Q1 Charter, group governance forum stood up, shadow-rollout survey, amnesty window opens. Signed charter, BU policy templates, survey results, amnesty starts.
Q2 Per-BU pilots launched (2–3 BUs in parallel, deliberately heterogeneous). Pilot scopes, baselines per BU, S.H.I.E.L.D. platform requirements drafted.
Q3 Pilot retrospectives, S.H.I.E.L.D. platform v1, vendor consolidation, AUP v2. Go/no-go per BU, platform deployed, consolidated tool list, AUP refresh.
Q4 Scale program for "go" BUs, board reporting cadence formalized, audit trail v1 in production, regulatory mapping refreshed. First board pack, audit pipeline live, regulatory mapping signed.

A 12-month sequence is aggressive for an enterprise; 18 months is more typical, and 24 months is normal in regulated enterprises. The cadence above is a target, not a deadline. The exit criteria from Phase 0 and Phase 1 gate the transition between quarters.

Cross-references

Next

  • If a regulator could write to your firm tomorrow, read Public sector & regulated.
  • If you are pre-charter, run the Leadership charter worksheet at Group level first, then per BU.
  • If your shadow rollout is already a year old, the amnesty window is the next thing on your calendar; schedule it before the next incident decides for you.

  1. ISO, ISO/IEC 27001:2022 [primary]. ↩

  2. ISO, ISO/IEC 42001:2023 [primary]. ↩

  3. European Union, Regulation (EU) 2024/1689 (AI Act), Jul 2024 [primary]. ↩

  4. Google Cloud / DORA, "2024 Accelerate State of DevOps Report", Oct 2024 [primary]. ↩

  5. Forsgren et al., "The SPACE of Developer Productivity", ACM Queue, 2021 [primary]. ↩

  6. Noda et al., "DevEx: What Actually Drives Productivity", ACM Queue, 2023 [primary]. ↩

  7. Simon Willison, "Uber caps usage of AI coding tools at $1,500 per month", Jun 2026 [secondary]. ↩

  8. Coverage of Klarna's 2024 launch and 2025 partial reversal: see Evidence: enterprise rollouts. The launch press release9 is primary; the reversal coverage is [secondary] and aggregated in the evidence pack. ↩

  9. Klarna press release, "Klarna AI assistant handles two-thirds of customer service chats in its first month", Feb 2024 [primary]. ↩