On a Tuesday in March, a pricing analyst needs eighteen months of order history to test one idea: could a summarizer turn the weekly quote-exception review, four hours of reading, into a twenty-minute scan? She does the correct thing, opening the intranet form, selecting "data access request," writing her purpose, submitting it. The form thanks her. Then she checks her calendar, because her steering-committee update is Thursday and the last three colleagues who filed that form waited two weeks. So she also does the other thing, the one that takes fourteen seconds: she exports what she can already reach into a spreadsheet, opens a personal chatbot account on her phone, and pastes. The analysis is good. Thursday goes well. And eighteen months of order history, the asset the access process existed to protect, now sits in a consumer account your organization does not own, cannot audit, and can never delete. Nothing in that story required a bad actor. It required a queue.

Fourteen Days Versus Fourteen Seconds

Your enterprise readiness audit produced two numbers that most organizations file in separate folders. The first was operational: across six functions, the median time from data access request to granted access was 14 days. The second was cultural: 71 percent of survey respondents had used an unsanctioned AI tool for work at least once, and 38 percent used one in a typical week. Governance read the second number as a compliance problem, security read it as a training problem, and both were wrong. The first number is the reason.

Put the two numbers in one sentence and the diagnosis writes itself. When the sanctioned path takes 14 days and the unsanctioned path takes 14 seconds, people take the unsanctioned path. Not the reckless people: everyone with a deadline, which is everyone. That is not a values failure but an arithmetic result, and arithmetic does not respond to a policy reminder in the all-hands deck.

This is where data governance stops being merely annoying and becomes dangerous. A slow access process does not prevent data from being used, it only prevents data from being used inside your perimeter. Every day of latency in the sanctioned lane subsidizes the unsanctioned one, and the resulting exposure is worse than the one governance was guarding against: instead of order history in an enterprise tenant with retention controls, audit logging, and a contract forbidding training on your content, it sits in a personal account with none of those things. Governance protected the data right up until it pushed the data somewhere it could not follow.

You met this pattern at Level 1 as a readiness signal: shadow AI use is not evidence of an undisciplined workforce so much as a map of unmet demand drawn by the people who do the work. What you could not do then was explain the mechanism. Shadow AI is largely a governance-latency phenomenon: demand exists, sanctioned supply is slow, and the gap fills with personal accounts. MIT's 2025 GenAI Divide research found the same shape from the other end. While roughly 95 percent of enterprise generative AI pilots produced no measurable profit-and-loss return, employees inside those same organizations were running real work through consumer chatbots. The official channel was slow; the unofficial one was instant.

The cost lands twice. The first is that exposure; the second is portfolio delay, which your chief financial officer feels. Every item in the roadmap you sequenced in Chapter 4.2 carries a data dependency arrow through an access decision, so at a 14-day median a use case touching three datasets in three functions loses six weeks before design work starts. Your wave-0 fast path, the emergency lane opened for the funded pilots, cut that to a 2.8-day median and proved the decisive point: the 14 days were never a technical or legal necessity, only a queue with no service level attached. What worked for four pilots now has to work for a company.

Gartner's finding that 63 percent of organizations lack or are unsure of AI-ready data practices, and its forecast that through 2026 some 60 percent of AI projects without AI-ready data will be abandoned, reads as a claim about data quality. Read it again with latency inside the definition of "ready." A dataset that is clean, documented, owned, and unreachable for two weeks is not AI-ready. Readiness has a clock in it.

Governance Is a Service, and Services Have Service Levels

There are two mental models for a data governance function, and the choice between them determines almost everything else. The first is a committee with a queue: requests arrive, qualified people weigh each on its merits, decisions emerge at whatever rate the group manages. Its quality metric is the soundness of its judgments, and it assumes every request deserves individual deliberation. The second is a product with a menu: most of what customers want is already decided and instantly available, a smaller set gets a short review with a published turnaround, a rare set gets deep work. Its quality metric is the behavior it produces across the population it serves, and it treats deliberation as an expensive resource, spent only where it changes an outcome.

The strategist's reframe moves governance from the first model to the second, and the design goal that follows fits on a slide: make the safe path the fast path. Enforcement becomes a backstop rather than a strategy, because enforcement is what you need when the compliant option is worse than the noncompliant one.

If compliance is faster than circumvention, compliance wins without enforcement.

The artifact that carries this reframe is the Governance Service Catalog: short, published, and built in three parts.

• The standing rules. Decisions already made and published as rules, so the most common requests need no decision at all. This part does the heavy lifting, and almost no organization has it.
• The request lanes and their SLAs. An SLA (service-level agreement) is a published promise about turnaround with a measured actual beside it. Three lanes, three promises, one named decider each.
• The exception route. How to get a time-boxed yes when the rules say no, who grants it, how long it lasts, where it is logged.

Notice what the catalog is not. A policy tells people what is forbidden and leaves them to guess the route to a yes; a catalog tells them what is available, how to get it, and when. It lives not in a governance folder but on the request form itself and the sanctioned tool's landing page, because a catalog nobody can find recreates the queue it was built to eliminate.

The Four Design Principles of Enabling Governance

Principle 1: Pre-decide the common cases

This is the highest-leverage move available to you, and it rests on an observation that survives contact with almost every request log: request volume is high, but request variety is low. Pull your last forty requests, strip the names, sort by shape. You will not find forty distinct problems. You will find five or six patterns repeating: operational data into the sanctioned assistant, contract summarization, customer records for a personalization idea, code into a coding assistant, survey free text that may contain personal data.

Each pattern decided once and published as a rule eliminates every future decision of that shape. A rule is simply a decision with the waiting removed, made in advance and in public: forty requests become five decisions, and next quarter's hundred become zero. The format is a table of data class, destination tier, purpose, and standing decision:

Three things deserve a pause. First, the table holds exactly one absolute prohibition, the last row, and it is credible precisely because the other eight rows offer a fast legitimate alternative: one hard no inside a permissive catalog is enforceable, while a catalog of hard noes is theatre. Second, the destination column names tiers, not products, so "sanctioned enterprise tenant" is a category with defined properties (no-training term, retention controls, audit logging, single sign-on) and the rules survive a change of vendor.

Third, and most underrated, look at the contract row. Somebody in legal reviewed the confidentiality clauses of the twenty standard templates once, determined which permit disclosure to a processor under an enterprise agreement, and published the answer. One afternoon of counsel time retired a question six functions would have asked separately for years. Centralizing a repeated review and publishing the result beats any policy document, because a policy tells people to consult legal and a published answer means they need not.

Principle 2: Tier the paths by risk, not by uniformity

Uniform process is the enemy. Committees treat a request to summarize the cafeteria menu with the same ceremony as a request to push customer records through an unvetted vendor, and that egalitarianism is what makes the system slow enough to route around. Three lanes, sized to risk:

The mechanism that makes this design compound sits in the last column, and it deserves its own name. The precedent ratchet: every fast-review and full-review outcome is converted, by default, into a new standing rule. The review template's final field is not "decision" but "generalized rule," and the reviewer must either write the rule this decision implies or record explicitly why the case cannot be generalized. Default on, exception documented. That inversion is the mechanism: the same question is never asked twice, and each quarter a larger share of requests falls into the self-serve lane.

Consider the two-year trajectory. A committee gets slower as adoption spreads, because volume rises and deliberation capacity does not; a ratcheted catalog gets faster, because rising volume lands mostly in lanes that consume no human time while the reviewed residue shrinks into rules. That divergence is your argument to an executive committee: you are not asking them to trade risk for speed, you are asking them to invest deliberation once instead of repeatedly. One guardrail keeps it honest: every rule carries a named owner and an annual review date, revocable by the full-review panel when the landscape changes.

Principle 3: Publish the SLA and measure it

Governance with a measured service level is a service. Governance without one is a mood. An unmeasured turnaround is invisible to everyone except the person waiting, so the queue's cost falls entirely on people with no power to fix it. The access-grant latency from the audit therefore becomes governance's own KPI (key performance indicator), reported on the quarterly readiness page beside the data program's coverage metric, to the same executives. Four figures:

• Self-serve share. Requests resolved with no human involvement. The headline number, because the ratchet moves it.
• Median time to decision, per lane. Medians hide the tail, so pair each with the next figure.
• 90th-percentile time to decision, per lane. The tail shapes behavior: a 2-day median with a 19-day tail still teaches people to route around you.
• Rules added this quarter. The ratchet's output, and evidence that reviews are being generalized rather than merely consumed.

The cultural effect outruns the measurement: a function that publishes its own latency has accepted that slowness is a defect rather than thoroughness, and that acceptance reorganizes a hundred daily choices no policy could reach.

Principle 4: Make the fast path the compliant path by design

Principles 1 through 3 make governance decisions fast. This one makes the compliant action fast, a different problem and the one organizations skip. Three commitments:

The sanctioned tenant is pre-approved for the common cases, provisioned to every employee on day one rather than "available for approved use cases." If using the safe tool requires a request and using the unsafe tool requires a browser, the design has already failed.

Required capabilities are supplied, not demanded. The sharpest of the three. If policy requires customer data to be redacted before it reaches a model, the organization must provide redaction as a service: a button, a script, something a marketing analyst can run on a Tuesday. Otherwise the policy is a wish dressed as a control. You have the seed already: the Level 2 privacy pre-flight included a redaction script one team wrote for one pilot, and promoting it to a maintained enterprise service turns a policy requirement into a two-minute task. The rule of thumb: every "must" in a policy needs a matching "here is how," provided centrally, or the must is fiction.

Certified data is access-ready by default. The golden datasets the data program certifies come with read access pre-provisioned for the roles named in the standing rules, so "AI-ready" and "usable right now" mean the same thing.

Each of these costs money, and each is funded with the same sentence, your argument to the chief information officer: every hour of governance latency is an hour of shadow-AI incentive. The fast path is not a convenience line item; it is the control that makes every other control effective, because controls only apply to traffic that stays inside the perimeter.

The Quality Side: Enforce Where the Work Already Happens

Everything so far concerns access governance: who may use what data, for what, and how fast that is decided. The other half of the mandate is quality governance: whether the data is fit to be used at all. Conflating the two is how governance functions end up with one enormous process that serves neither.

Quality standards need no inventing, because you wrote them last lesson. The five-test definition of AI-ready data (whose tests require, among other things, a named owner and a documented statement of permitted use) is the published standard, and the data program certifies against it. Governance's job is to decide where the standard is enforced, and there are two useful places.

Enforce at creation where you can

The cheapest defect is the one never created. Enforcement at creation means validated fields instead of free text, a pick list instead of a naming convention nobody remembers, a required customer identifier instead of an optional one, and a published codebook (the plain-language document defining each field and its permitted values) kept by the domain steward. A field holding 400 spellings of six real values became a quality problem when the form permitted free text, not when someone tried to analyze it. Every hour spent fixing capture retires many hours of downstream remediation, and your audit's backlog is the map of which forms to fix first.

Enforce at consumption where you must

Some data always arrives from systems you do not control: acquired companies, supplier portals, legacy platforms with a 2029 decommission date. There the enforcement point moves to consumption, and the crucial design choice is this: use the gates that already exist. Gate 1 of your stage-gate charter already demands evidence that the use case can be built. Add one line to its entry criteria: every dataset this use case depends on carries a current certification, or a named remediation with a date. That line does more enforcement work than a review board, because it sits in a forum that already meets and already tells project teams no.

State the principle plainly, because well-intentioned programs violate it constantly: embed governance in the workflow that already exists; never build a second approval chain. A parallel chain is by construction a second queue, and queues are the disease this lesson treats.

Roles kept deliberately small

The staffing model follows. Three roles, no more:

• A data governance lead, often part-time, who owns the catalog, runs the duty roster, writes the rules reviews generate, and reports the four numbers.
• The domain stewards from the data program, already named, budgeted, and accountable for their datasets. They take fast-review duty for their own domains, which is also the fastest route to good decisions, because they know the data.
• Privacy, legal, and security partners on call: named individuals with a scheduled slot for full reviews and an obligation to help generalize outcomes into rules.

One rule about growth keeps the function honest: governance headcount increases only when the published SLA slips. Not when adoption rises, not when a new tool arrives, not when the function feels busy. If demand grows and the ratchet works, self-serve share rises and the same team absorbs it; if the SLA slips two quarters running, that measured signal justifies a hire. Tying headcount to latency rather than ambition stops governance functions growing into the bureaucracy they were created to prevent.

The exception culture

Exceptions are inevitable and useful, on two conditions: every one carries an expiry date (90 days is a reasonable default) and every one is logged with requester, rationale, and expiry. Never grant a permanent exception, which is an unwritten rule with no owner and no review date, and how governance systems rot.

Then read the log as product feedback, because that is what it is. One exception is a special case. Five in the same category in one quarter is not five people bending the rules, it is one rule that does not match how the business works, and the response is to write the missing rule rather than tighten enforcement on the people who kept asking. When exceptions cluster, the first hypothesis is that the catalog is wrong.

The Catalog in Its First Quarter: A Worked Example

Here is the industrial company's first quarter with the catalog. The numbers are hypothetical, used to show the shape of the arithmetic.

The build. The governance lead pulled 62 requests from three quarters of ticket logs and found seven patterns covering 51 of them. She drafted rules for those seven, added two the audit had flagged but nobody had yet requested (personal AI accounts, redacted customer data), and took all nine into one two-hour session with privacy counsel, the security architect, and two stewards. Nine rules ratified in a single sitting, covering an estimated 80 percent of anticipated volume, eleven days from first draft to published catalog.

The quarter. One hundred and forty requests arrived, up from an average of 21 per quarter under the old form, because a fast path surfaces demand a slow path suppresses. Their disposition:

• 112 self-serve (80 percent), no human involved, each logging requester, data class, destination, and the rule invoked.
• 22 fast review, resolved at a 1.6-day median against the 2-day SLA, 90th percentile 2 days.
• 6 full review, resolved at an 8-day median against the 10-day SLA.
• 4 of those 6 outcomes became new standing rules, taking the catalog from 9 to 13. The other two were documented as genuinely case-specific (one customer's contractual restriction, one pending vendor negotiation).

That last line is the ratchet made visible: four questions that used to take ten days each will never be asked again, so next quarter's self-serve share rises without anyone working harder.

The behavior change. The follow-up shadow-AI survey used the audit's instrument. Weekly unsanctioned tool use fell from 38 percent to 21 percent, and no enforcement action was taken during the quarter: no blocked domains, no disciplinary cases, no mandatory retraining, no policy signature campaign. The only intervention was the fast path. Say that to your executive committee in exactly these terms: the largest single reduction in shadow AI came from making the sanctioned route faster, not the unsanctioned route harder.

The exception log. Nine exceptions were granted, all with 90-day expiries, and five were the same shape: marketing wanting customer attributes for content personalization, a use the rules did not cover and the privacy row appeared to forbid. The lead read the cluster correctly. Not five compliance problems, one missing rule. Rule 14 was written: pseudonymized segment attributes processed through the redaction service are permitted in the sanctioned tenant for personalization, while raw customer records remain prohibited.

The cost. Roughly 0.5 full-time equivalent (FTE) of the governance lead, about two hours a week of duty time across six stewards, and eleven hours of counsel time. Set that against a baseline of 140 requests each waiting a 14-day median while blocking work whose delay cost nobody measured. This is one of the rare governance investments cheaper than the process it replaces.

The quarterly page. One line reads: certified coverage of pipeline-critical datasets 34 percent, target 60 percent by Q4. The line beneath: self-serve share 80 percent, fast-review median 1.6 days, full-review median 8 days, rules added 5. Together they say what no adjective could: the data is getting better and the path to it is getting shorter.

The Tollbooth: How Good Judgment Produced More Risk

Now the failure story, and its discomfort is the point. A financial services firm of about 5,000 people responded to a near-miss (an employee had pasted a client portfolio summary into a consumer chatbot) by doing what responsible organizations do: it stood up AI data governance. A cross-functional committee was chartered with senior representation from privacy, legal, information security, risk, and the data office. A request form was built. The committee met on Thursdays.

Everyone on it was competent and the questions asked were the right questions. This story contains no villain, which is what makes it instructive.

Within two quarters the median decision time reached 19 days, peaking at 31 over the summer when quorum was hard to reach. The causes were mundane: the Thursday cadence alone put three to four days between submission and first consideration, agendas ran long, items were deferred for more information, and any request needing clarification lost a week.

Two things then happened in parallel, and the committee could see only one. The visible one was portfolio damage. Nine funded initiatives were in flight and every one had a data dependency that passed through Thursday. Items lost three to six weeks each; at the annual review three were flagged as behind schedule and one was descoped. No postmortem named the committee, because case by case each delay looked like a normal wait for a normal approval.

The invisible one was behavioral. Denied a fast route, the business improvised: work moved to datasets people already held even when those were the wrong datasets, projects were reframed to avoid triggering a submission, and increasingly people used their own accounts. A shadow census a year on found weekly unsanctioned use had risen from 29 percent to 44 percent, and the composition had changed: client information, the exact category the committee existed to protect, now appeared in personal accounts, because the sanctioned route for client data was the slowest of all.

The postmortem produced a finding nobody wanted to write down. Across the year the committee reviewed 97 requests and approved 96, never approving a risky one. Its judgment, decision by decision, was essentially flawless. And the firm's actual risk exposure had roughly doubled.

Sit with that, because it overturns the instinct that governance quality equals decision quality. The committee optimized what it could see, the soundness of each ruling, and was blind to the behavior its latency produced in 5,000 people. Every approval was right and the system was wrong.

Governance is judged by the behavior it produces, not by the decisions it makes.

The remedy was not to abolish the committee, and never argue for that in your own organization, because it sounds like a request to remove controls. The remedy was conversion: the committee became lane 3, meeting on a 10-day SLA for genuinely novel cases, and its most valuable output became rules rather than rulings. It kept its expertise and lost its monopoly.

There is a clock on that conversion, worth naming when you make the case. The EU AI Act calendar is fixed: obligations for GPAI (general-purpose AI models, the foundation models most assistants are built on) since August 2, 2025, transparency for AI-generated content December 2, 2026, high-risk Annex III December 2, 2027, embedded high-risk Annex I August 2, 2028. Classifying a portfolio against those categories and keeping the documentation current is a workload with a deadline attached. A function running a 19-day median on routine access will not absorb it; a function at 80 percent self-serve has the capacity free. Speed on the routine buys rigor on the serious.

What to Do Monday Morning

Five moves, in order. The first three fit inside two weeks.

1. Pull your last 40 requests and cluster them into patterns. Strip names, sort by shape (data class, destination, purpose), count. You want the handful of patterns covering most of the volume. If there is no request log, that is itself the finding: an unmeasured queue, and your first task is counting.
2. Pre-decide the top five patterns as published standing rules. Draft them, then get privacy, legal, security, and the relevant stewards into one two-hour session to ratify all five at once. Pre-deciding is a batch operation, so do not run five consultations. Publish the result on the request form, not in a policy folder.
3. Set and publish the three lane SLAs (self-serve instant, fast review 2 business days, full review 10 business days), name this month's duty reviewer, and post the roster where requesters can see it. A named human with a date beside them is the smallest unit of service.
4. Wire the precedent ratchet in by default. Make the review template's final required field "generalized standing rule," with an opt-out that must state why the case cannot be generalized, and hold a 30-minute session monthly to publish the new rules.
5. Report governance latency beside your readiness metrics. Self-serve share, median and 90th percentile per lane, rules added: same page as the coverage metric, same audience, every quarter. The first time those numbers face an executive committee, governance stops being a mood and becomes a service.

Your governance now covers the data: who may use it, how fast they get it, whether it is fit. It says nothing yet about the machinery underneath, the platforms, integrations, and vendor architecture that decide whether any of it can be delivered. That layer has its own failure modes and its own questions a non-engineer must ask with authority, and it is where the next lesson goes.

Key Takeaways

• Diagnose shadow AI as a latency problem before treating it as a compliance problem: when the sanctioned path takes 14 days and the unsanctioned one takes 14 seconds, the queue produces the exposure governance exists to prevent.
• Reframe governance from a committee with a queue to a product with a menu, and adopt one design goal above all: make the safe path the fast path, because compliance faster than circumvention needs almost no enforcement.
• Build the Governance Service Catalog in three parts: standing rules that pre-decide the common cases, three request lanes with published SLAs, and an exception route with expiry dates and a log.
• Pre-decide the handful of patterns covering most request volume, because a rule is a decision with the waiting removed, and one central legal review published as an answer retires years of repeated questions.
• Install the precedent ratchet: make "generalize this into a standing rule" the default output of every review, so self-serve share rises each quarter and the same question is never asked twice.
• Report governance's own latency (self-serve share, median and 90th percentile per lane, rules added) beside the coverage metric, and let SLA slippage, not ambition, be the only trigger for headcount.
• Supply every capability your policy demands (redaction as a service, pre-approved tenant access, access-ready certified datasets) because an unsupported "must" is a wish, and enforce quality through gates that already exist rather than a second approval chain.
• Judge governance by the behavior it produces, not the decisions it makes: the committee that approved 96 of 97 requests flawlessly and doubled its firm's shadow exposure was right in every case and wrong as a system.