It is 4:40 on a Thursday and a customer-success manager has a complaint email open in one window and the sanctioned AI assistant open in another. The email carries a customer's name, their order history, and a sentence about a hospital stay explaining why the delivery was refused. She wants a draft reply. She pauses, because somewhere in the onboarding portal there is an AI acceptable-use policy she attested to in March, and she vaguely remembers it saying something about personal data. She types "AI policy" into the intranet search. First result: a town hall slide deck. Second: the IT service-desk category page. Third: an eleven-page PDF titled "Group Policy 114: Artificial Intelligence Acceptable Use (v2.1)", which she opens, reading two paragraphs of scope and definitions before hitting a numbered list of prohibited activities beginning with "the unauthorized processing of personal data through third-party inference services." She closes it and decides the way every human being decides at 4:40 on a Thursday. She deletes the hospital sentence, pastes the rest, and sends the draft. She was, as it happens, exactly right. She has no idea she was right, and next Thursday she may be wrong.

The Only Moment That Matters

That thirty seconds is the subject of this lesson. Not the policy's drafting, not its approval by the governance committee you chartered in the previous lesson, not its legal sufficiency: the thirty seconds in which a competent employee with a deadline tries to find out whether she is allowed to do the thing in front of her, and either finds an answer she can act on or improvises one.

The acceptable-use policy (AUP: the document saying which uses of a technology are permitted, restricted, or forbidden) is the most-written and least-read artifact in enterprise AI. The standard specimen runs eight to fourteen pages, drafted by legal with input from security and risk, revised across four committee cycles, and written, if we are honest about the audience, for a future auditor rather than the person holding the customer email. It is acknowledged by 94 percent of employees in a compliance platform, and consulted at the moment of decision by approximately nobody.

Here is the reframe. The problem is not non-compliance. The overwhelming majority want to do the right thing and would do it instantly if they knew what it was. The problem is that the policy was never designed to be used: it does not answer the questions people actually have, in the words they would use, at the place they would look. Asking it to change behavior is like asking a terms-of-service agreement to teach someone to drive.

So set a design standard, and defend it in committee every time someone proposes adding a section:

A policy is working when a person with a real question finds the answer in under a minute and acts on it with confidence, and when the compliant path is the path of least resistance. Everything else is a record of having told people.

The corollary is uncomfortable for anyone who has spent a quarter drafting: in the page people read, length is not a virtue but the failure mode. That is not an argument against precision, only for putting precision somewhere it does not have to be read under time pressure. This lesson is policy design craft, not legal advice: your counsel owns legal sufficiency, and you own whether it changes what happens on Thursday afternoon.

The Artifact: The Two-Layer Policy

The named artifact resolves the conflict rather than compromising it. Most policies are bad because they serve two audiences with one document and serve neither: too long for the operator, too informal for the auditor. Stop trying. Write two things, publish them as one policy with two layers, and be explicit about which is which.

Layer one: the Rules of the Road. One page. What anyone may do, must not do, and must ask about, written in scenarios, in second person, in the words people actually use. This is the layer that gets read, linked, searched, and quoted in team meetings. It carries no defined-terms section, because a rule you cannot parse without a glossary is a rule you will not parse at 4:40.

Layer two: the reference policy. The complete document: scope, definitions, roles, regulatory mapping, data classifications, retention, breach handling, disciplinary framework, version history. This is what your auditor, your legal team, and your customer's security questionnaire need. It should be thorough, and nearly nobody should ever have to read it, which is a design success rather than a waste.

The discipline is the relationship between them: layer one must be a true and complete summary of the decisions an ordinary employee will face, and layer two must never contradict it. When they conflict, layer one is the bug report. Publish them with one owner, one version number, and a link each way.

Writing Layer One: Four Design Principles

Layer two is a drafting job your legal colleagues already know. Layer one is the craft, and it has four principles, none of them about being friendly. Each changes whether the document is used.

Principle one: scenarios, not categories

Nobody has ever stood at their desk and thought "am I processing personal data through a third-party inference service?" They think: "can I paste this customer's email into the assistant to draft a reply?" Same question, two languages, and the policy is written in the wrong one. A document indexed by risk taxonomy asks the reader to first classify their situation into a category they have never used, and that translation step is where readers give up.

So index layer one by situation. And here is the move that beats any amount of careful drafting: the questions are already sitting in a log somewhere. Three sources hold them in your organization right now.

• The request log from your Governance Service Catalog (Chapter 4.3). Every fast-path request is a person telling you in their own words what they were unsure about, and the high-frequency ones are your policy's table of contents.
• Champion signals. Your champion network hears the questions people will not put in a ticket because they are embarrassed to ask, and those are disproportionately the ones driving quiet workarounds.
• The help desk queue. Search six months of tickets for "AI", "assistant", "allowed", and "can I". You will find the same twenty questions phrased twenty ways.

Harvest the twenty real questions, deduplicate, rank by frequency, and write layer one as answers to them using the questioners' nouns. If people say "customer emails," do not write "personal data in unstructured correspondence." A policy written from the twenty real questions beats one written from a risk taxonomy every time, for a reason unrelated to tone: it is indexed the way the reader's problem is indexed. The harvest also stings. Some questions have no answer anywhere, because the policy never anticipated the situation, and those are the most valuable items on the list: each marks people improvising today, which is what a shadow-AI census measures.

Principle two: permissions first, prohibitions second

An ordering rule with real behavioral consequences. A document that opens with what you may do gets read to the end. One that opens with prohibitions is silently reclassified as "a legal thing" and skipped, and every subsequent sentence, including the important ones, is skipped with it. You have perhaps twelve seconds to establish that this page is a tool rather than a shield, and the first heading spends most of them.

Permission-first is also, in a well-designed program, more accurate. In most enterprises with a sanctioned tool and a boundary map, the great majority of daily AI uses are permitted without asking anyone: summarizing an internal document, drafting a memo, rewriting for clarity, turning notes into a checklist. A document whose first page is prohibitions misrepresents its own program as more restrictive than it is, and you pay for that in the shadow census: people who assume the answer is probably no stop asking, and those with a deadline route around you.

So reframe the job: the policy's primary work is making the sanctioned path obvious, its secondary work is naming the boundary, and in that order the boundary lands better, because a reader told yes six times reads the seventh item, the no, as information rather than suspicion.

Principle three: the three-bucket structure

Layer one has exactly three buckets. Not five, not a maturity scale, not a matrix. Three, because the reader needs to land in one of three places: go, go with a condition, stop.

GREEN: do it, no permission needed. Named scenarios using the sanctioned tools on the sanctioned tenant. Green should be the longest section and embarrassingly specific: "drafting a reply to a customer email, with account numbers removed", "summarizing a supplier contract you already have access to", "turning meeting notes into actions." Vague permissions do not get used, because a person who cannot see their exact situation in the green list assumes they are not in it.

AMBER: do it with the named control, or ask via the fast path. Amber is where most policies fail, because they say "seek approval" without saying from whom, how, or by when. Every amber item carries the control that makes it permissible (redaction, the sanctioned tenant rather than a personal account, a named human review gate before anything leaves the building) and, where judgment is genuinely required, the route and its promise. Name the fast path and state its service-level agreement (SLA: a published turnaround promise with a measured actual beside it). "Ask via the AI fast path, answer within 2 business days" is a rule someone can plan around. "Consult the relevant function" is a rule someone routes around.

RED: do not, with the reason in one clause. The smallest section and the most carefully written. Every red item gives its reason in the same sentence: not "prohibited under clause 7.3" but "do not put unredacted patient records into any AI tool, because we cannot show a regulator where that data went." A prohibition with a reason survives contact with a deadline. One without a reason invites improvisation, because a person facing a deadline and an unexplained rule constructs a theory of what the rule was for and decides their situation falls outside it. They are not defiant. They are filling in a blank you left.

One more red rule, the one most often skipped: every red item names the alternative that meets the underlying need. If people paste patient records into a chatbot, they have a need: they are drowning in documentation. A red line offering no route to the same outcome will be violated by people who still have the need, and you will hear about it eighteen months later. "Do not do X" plus "here is how to get that result safely" is a control. "Do not do X" alone is a wish.

Principle four: written for the moment of decision, and placed there

Two halves, and the second is the one people skip. The writing half is mechanical. Short sentences. Second person. Present tense. No defined term required to parse a rule, so if a rule needs the phrase "personal data" it also needs three inline examples of what that means in your business. No cross-references, because a cross-reference asks the reader to open a second document and they will not. Read every rule aloud and ask whether a new joiner in week two could act on it unaided. If not, it is not a rule yet. It is a topic.

The placement half is where policies quietly die. The best-written page in the world, filed on a portal under Group Policies, is unfindable at the moment of decision. Place it where the decision happens:

• Inside the tool. A permanent link in the assistant's interface, labeled the way a worried person thinks of it: "What am I allowed to put in here?" rather than "Acceptable Use Policy."
• In the workflow's SOP. Your standard operating procedures (SOP: the documented step-by-step for a process) already govern the work, so where an AI step sits in a redesigned workflow, the green or amber rule belongs in the step itself, not a distant portal.
• At the top of intranet search for the words people actually type, which are not "acceptable use" but "AI policy", "can I use AI", and the name of your tool.

Then run the placement audit, ten minutes and the most clarifying exercise in this lesson. Open your intranet search as a colleague would and type "can I use AI for". Then "AI policy". Then your tool's name. If the first result is a town hall deck, a service-desk category, or a 2024 announcement, your policy does not exist as far as the organization is concerned, however carefully drafted and however widely acknowledged. Findability is not a communications task delegated after publication. It is a design requirement.

Enforcement by Workflow, Not by Memo

Now the structural core, the principle that separates a strategist from a policy author. The strongest policy is one the environment enforces. A rule living only in a document depends on two fragile things: that the person remembers it, and that they choose compliance under deadline pressure. A rule moved into the architecture depends on neither. This is an inventory exercise you can run this month, and it has a name in engineering: make the right thing the easy thing and the wrong thing hard to reach.

Take your rule list and ask of each: could the environment do this instead of the reader? The chapter has already handed you most of the mechanisms.

• The AI Data Boundary Map becomes tenancy configuration. The boundary map (Chapter 4.3: data classes against destinations, every cell marked permitted, permitted with control, or prohibited) is a document until someone implements it. Configured as enterprise tenancy with the right retention and training-data settings, "your work is not used to train the vendor's model" stops being a sentence people must trust and becomes a setting you can evidence.
• Redaction becomes a supplied service, not an instruction. "Remove personal identifiers before pasting" fails at volume because it is tedious and invisible when skipped. A redaction step built into the tool converts a compliance ask into a default.
• Permission-aware retrieval becomes a procurement requirement. If the assistant can only surface documents the user could already open, an entire category of policy text about not asking the tool for what you are not entitled to see becomes unnecessary. Put it in the requirements document, not the policy.
• Sanctioned tools are made genuinely better than the alternatives. The most underrated control in enterprise AI. The shadow-AI census in Chapter 4.3 fell from 38 percent weekly unsanctioned use to 21 percent with no enforcement action at all: no blocked domains, no disciplinary cases, no signature campaign. The only intervention was a faster sanctioned route. Convenience is a control.
• Prohibited paths are made technically unavailable where proportionate. The qualifier carries weight: over-blocking pushes work onto personal phones where you have no visibility at all. Block the small list you can defend, and be honest that blocking moves behavior rather than eliminating it.

Run this against a real policy and the result is startling. A third to a half of the rules in a typical AI acceptable-use policy are not judgment calls. They are configurations written as instructions because writing was faster than implementing, and every one you move stops depending on someone remembering a page they read in March.

Documents rely on memory and goodwill. Architecture relies on neither. Move every rule you can from the document into the environment, and let the residual text cover only what the environment cannot: judgment, purpose, and disclosure.

The residual is real, so this is not an argument that policy is obsolete. Architecture cannot decide whether it is appropriate to use AI to draft a redundancy letter, whether a client should be told a deliverable was AI-assisted, or whether an analysis needs a second human reader. Those are questions of judgment, purpose, and disclosure, and they belong to people. Architecture clears away the mechanical rules so the page people read holds only the questions that need a human to think.

Keeping It Alive: Versioning, Exceptions, and Honest Measurement

A policy is a product, not a monument. Three maintenance disciplines keep it one.

Versioning and change communication

Announce every change to layer one with what changed and why, in one paragraph, through the channel people actually read. Not a portal notice, not a new acknowledgment campaign. One short message: "Change to the AI Rules of the Road, effective Monday: pasting customer emails into the assistant moves from amber to green now that redaction is built into the tool. Here is the page." Attach a version number and keep a visible change history at the foot.

State the rule underneath plainly: an unannounced policy change is indistinguishable from no policy change. If people learn a new rule by violating it, you have not tightened control, you have taught the workforce that the page is unreliable and must be re-checked every time, which means it will be checked none of the time. Batch minor edits and announce meaningfully rather than silently editing a live page.

The exception log as product feedback

Your Governance Service Catalog already logs exceptions with expiry dates, and most organizations treat that log as a risk register of deviations to track and close. It is also, more usefully, a product feedback channel.

Read it with one question: which rule is generating repeated exceptions? A rule producing one exception has met an edge case. A rule producing eleven exceptions from four teams is wrong, or its underlying need has no sanctioned route. The committee reviews the log quarterly and does one of three things with each pattern: amend the rule, build the capability that removes the need, or leave it and record why the friction is deliberate. All three are legitimate. Doing nothing, quarter after quarter, while the same exception is granted repeatedly, teaches requesters that the rule is theater with a paperwork tax.

Measuring whether it works

Here is where most governance dashboards lie to their owners. The metric on the slide is acknowledgment rate: 94 percent, green, on track. That number measures the function of a compliance system, namely that the platform sent the document and recorded the click. It is evidence you told people, not evidence the policy works, and treating it as the latter is the beginning of the failure story below.

Replace it with four honest measures.

• The shadow-AI census trend. The share of employees using an unsanctioned tool for work in a typical week, measured the same way each time, anonymously. This is the only real compliance measure you have, because it counts behavior rather than attestation. Track the trend, not the level, and never punish a bad reading or you will never get another honest one.
• Fast-path request volume. Rising volume means people know where to go and believe it is worth going, so read a rise as success. A committee that reads rising requests as rising risk starts discouraging them, and discouraged requests do not become fewer decisions, only unlogged ones.
• Time-to-answer for a policy question. Do not model this. Test it. Take a real question, ask three colleagues who did not write the policy to find the answer, and time them. Under a minute is the standard. Over five minutes, or "I would just ask my manager," means the policy failed the test that matters, and the fix is usually placement, sometimes wording, occasionally that the answer is not written anywhere.
• Exception volume by rule. Not total exceptions, which tells you little, but exceptions per rule, which points at the two or three rules needing amendment.

Report all four on one page, and let acknowledgment rate appear, if at all, as a footnote labeled for what it is: a legal record.

Two Storylines: The Rewrite and the Acknowledged Policy

The rewrite, with illustrative numbers

Return to the enterprise storyline of this chapter, with all figures hypothetical and used to show the shape of the work rather than to promise a result.

The starting position: an eleven-page AI acceptable-use policy, approved fourteen months earlier, 94 percent acknowledged, and a shadow-AI census showing 21 percent weekly unsanctioned use after the fast path cut it from 38 percent. When the transformation lead asked four managers where an employee would find the answer to a real question, she got four different answers and one shrug. The rewrite ran six weeks and had four moves.

One: retain layer two. The eleven-page document survived with light edits, removing three rules overtaken by tenancy configuration and fixing two places where it contradicted the boundary map. Relabeled the reference policy, it stayed where auditors and the security-questionnaire team expect it. Effort: about two days, because rewriting it was never the point.

Two: harvest and write layer one. The team pulled 140 fast-path requests from the catalog log, six months of help-desk tickets, and recurring questions from the champion network. Deduplicated, that produced 23 real questions, four of which had no answer anywhere in the existing policy. Layer one answered all 23: green (13 items), amber (7 items, each with its named control or the fast path and its 2 business day SLA stated on the page), red (3 items, each with a one-clause reason and a named alternative). Length: one page, 620 words.

Three: place it. Linked from inside both sanctioned AI tools under the label "What can I put in here?", pinned to the top of intranet search for "AI policy", "can I use AI", and both tool names, and embedded as a step reference in the four SOPs where AI now sits inside a workflow.

Four: move enforcement into architecture. The team listed the policy's 14 operative rules and asked the configuration question of each. Six of the 14 became configuration: tenancy defaults with training opt-out, 30-day retention, a blocked-destination list of four consumer services with documented rationale, redaction supplied inside the assistant, permission-aware retrieval written into the next procurement, and default-off upload for one high-risk repository. Those six left layer one entirely, which is why 14 rules fit on one page as 23 answers.

Results at 90 days, all illustrative:

• Time-to-answer: 40 seconds median across nine colleagues tested with three real questions, against a pre-rewrite baseline best described as "nobody could find it."
• Fast-path request volume up about 60 percent. The committee's instinct was alarm. The correct reading, argued and won in that meeting, was that the page had told people the lane existed, so decisions previously made silently were now made visibly.
• Weekly unsanctioned use down from 21 percent to 12 percent on the same census instrument.
• Two rules amended after the exception log showed a pattern: a marketing use case involving customer imagery that the policy had never anticipated, five exceptions from two teams in one quarter. The rule moved from red to amber with a named control, and the exceptions stopped.

Note what did not happen: no new training module, no re-attestation campaign, no enforcement action. Acknowledgment stayed at 94 percent, because it never meant anything.

The failure story: the acknowledged policy

A professional-services firm does everything the conventional playbook asks, and does it well. Legal and risk draft a thorough 14-page AI acceptable-use policy: organized, accurate, defensible, mapped to the firm's obligations and client confidentiality commitments. It enters the compliance platform with a mandatory attestation, acknowledgment reaches 97 percent in three weeks, and the general counsel reports full coverage against a green dashboard.

Nine months later an internal review, prompted by an unrelated client question, finds three teams routinely doing something the policy prohibits on page 9. Not occasionally: routinely, as standard practice, documented in their own team procedures.

The uncomfortable finding is not the violation but the explanation. None of the three teams was defiant, and none had weighed the rule and decided to break it. None had read past page 2, where scope and definitions ended and where most readers, having found nothing telling them what to do, stopped. Worse, the prohibited practice had been introduced by their own department's process improvement work eight months earlier and approved by their own director, who had also not read page 9. Policy and approved workflow contradicted each other, undetected for a year, because no mechanism existed that would ever have surfaced it. The policy was not connected to anything. It was a file.

The recommendation is the one always made here: mandatory retraining with a fresh attestation. It is delivered, acknowledgment rises to 99 percent, and nothing else changes, because nothing else was addressed. The rule is still on page 9, the workflow contradicting it is still in the SOP, the intranet still returns a town hall deck, and the practice continues in two of the three teams because the need it served was never given a sanctioned route. What the firm built, with real diligence and expense, was an excellent record of having told people. That is a legal artifact, not a control, and mistaking one for the other is how compliance theater gets expensive: it consumes drafting cycles, attestation infrastructure, retraining hours, and committee attention, and buys a dashboard.

Hold this against the program's failure record. MIT's finding that 95 percent of enterprise generative AI pilots produce no measurable return reads as a story about pilots, but its most quoted secondary finding was the shadow economy: employees using personal AI tools for real work while the official deployment stalled. Gartner's 63 percent of organizations lacking or unsure of AI-ready data practices, and its forecast that over 40 percent of agentic AI projects will be canceled by end 2027, describe the same drift between formal position and actual practice. An acknowledged, unread policy is that drift in documentary form: the stated position, filed and signed, while the real behavior happens where the document cannot see it.

What to Do Monday Morning

1. Harvest the twenty real questions. Pull your fast-path request log, six months of help-desk tickets matching "AI" and your tool names, and a list from three champions. Deduplicate, rank by frequency, and mark the ones your policy does not answer: those are the highest-value items, because they mark where people improvise today.
2. Write layer one in green, amber, red. One page, permissions first, in the questioners' own words. Every amber item names its control or names the fast path and states its SLA. Every red item gives its reason in one clause and names the alternative. Keep the existing policy intact as layer two.
3. Run the placement audit. Search your own intranet the way a colleague would: "can I use AI for", "AI policy", your tool's name. Fix what you find, and add a link inside the tool itself labeled as a worried person would phrase it.
4. Move at least three rules into configuration. Walk the rule list with whoever administers the tenancy, asking of each: could the environment do this instead of the reader? Retention, training opt-out, blocked destinations, and supplied redaction are the usual first three. Delete them from the page once live.
5. Replace acknowledgment rate with the shadow-use trend on the committee's page, alongside fast-path volume, tested time-to-answer, and exceptions by rule. Then test time-to-answer yourself: three colleagues, one real question, a stopwatch. Report the number even if it is embarrassing, especially if it is embarrassing.

Key Takeaways

• Design for the moment of decision, not the auditor: a policy works when a person with a real question finds the answer in under a minute, and when the compliant path is the path of least resistance.
• Build the Two-Layer Policy: a one-page Rules of the Road in scenarios for everyone, plus the complete reference document for legal, audit, and edge cases, with layer one the bug report whenever they conflict.
• Harvest the twenty real questions from your fast-path log, help-desk tickets, and champion signals, then answer them in the questioners' own words, because a policy indexed by situation beats one indexed by risk taxonomy.
• Lead with permissions and close with prohibitions: a document opening with what you may do gets read, one opening with prohibitions gets filed under legal, and permission-first is also more accurate.
• Structure layer one as green, amber, red, with amber naming its control or the fast path and its SLA, and every red item giving its reason in one clause plus the alternative that meets the need.
• Move every rule you can into the architecture: boundary map as tenancy configuration, redaction as a supplied service, permission-aware retrieval as a procurement requirement, sanctioned tools made better, prohibited paths blocked only where proportionate.
• Maintain the policy as a product: announce each change with what changed and why in one paragraph, and read the exception log as feedback, because a rule generating repeated exceptions from multiple teams is a wrong rule.
• Measure the shadow-AI census trend, fast-path volume (rising is success), tested time-to-answer, and exceptions by rule, treating acknowledgment rate as what it is: a record that you told people, not evidence of control.

Policy and governance are internal instruments: you write them, you own them, and you can amend them on a Tuesday if the exception log tells you to. The next lesson turns to obligations you cannot amend, negotiate, or route around. The EU AI Act's calendar is external, dated, and already running: general-purpose AI obligations live since August 2, 2025, AI-content transparency from December 2, 2026, high-risk Annex III systems from December 2, 2027, embedded Annex I systems from August 2, 2028. Your policy is one input to that compliance program. The calendar is the part that does not wait, and it is where this chapter and this level close.