Writing an AI Use Policy That Survives a Real Incident

Most post-incident policy reviews land on the same short list. Naming the failure mode makes it easier to find in your own draft.

Take the escalation gap seriously. When an incident involves personal data, the clock that matters is often a legal one, not an internal one. Public companies face a four-business-day disclosure window under Item 1.05 of Form 8-K that begins at the materiality determination, not at detection, a point made explicit in analysis of a bank incident triggered by unauthorized AI use rather than an external attack (Wilson Sonsini). A policy that routes reports through a manager who is on vacation has effectively removed days from that window.

The core technique is mechanical. For each behavior you care about, write one sentence with three parts: the trigger, the required action, and the reviewer or evidence. Then check whether two reasonable people would reach the same verdict on a given log entry.

Compare these:

• Weak: "AI output should be reviewed before external use."
• Testable: "Any model output included in a customer-facing email must be reviewed and approved by a second person before sending; the approval is recorded in the ticket."

The second version tells you who counts (a second person, not the author), what counts (inclusion in the outbound message, not drafting it), and where the evidence lives.

Several published policies already lean this direction. A legal sample policy instructs employees to treat every input to a generative tool as if it will be published on the internet, and to inform a supervisor when a tool was used to perform a task (Fisher Phillips sample policy). Both of those are checkable: the disclosure requirement produces a record, and the "assume it goes viral" framing gives employees a decision rule they can apply without a classification table in front of them.

A useful discipline is to write each rule as a short script you could hand to an auditor. If the auditor cannot complete the sentence "I verified compliance by looking at ___," the rule needs rewriting.

Rule ID:      DL-03
Trigger:      Any prompt, upload, or paste that includes customer records
Required:     Data must be anonymized before submission; records removed
              unless the tool is on the approved list for that data class
Evidence:     Tool audit log plus the anonymization step in the request ticket
Owner:        Data steward for the business unit
Check:        Monthly sample of 20 tool sessions per unit

Rules written this way survive handoffs. When the person who wrote the policy leaves, the rule still explains itself.

Every workable policy needs an exception route, because the alternative is employees who route around the policy entirely. The risk is that exceptions accumulate into a parallel rulebook nobody audits.

Four properties keep exceptions contained. First, a named approver, ideally a role rather than a person, so the route survives a resignation. Second, a stated business justification in writing. Third, an expiry date, because an exception granted without one is a permanent amendment. Fourth, a periodic review of the exception register itself, so patterns become visible.

Published templates converge on this structure. One legal policy requires express written consent from a supervisor or HR designee before an employee uses a tool that is not on the approved list, or that is not approved for the specific task, and asks the requester to explain purpose, scope, and business justification (LexisNexis annotated policy). That is an exception process with a justification requirement built in. What it still needs is a clock.

Here is the decision rule: if the same exception is requested three times for the same team and use case, stop granting it and either approve the use case formally or change the underlying process so the request disappears. Repeat exceptions are a signal that the policy is wrong, not that the team is reckless. Vendor review processes, security reviews, and tool approval workflows all generate this kind of data, and a policy that ignores it will grow a shadow rulebook next to the official one.

Shadow AI is the strongest evidence that this matters. Analysis of a regulatory filing triggered by unauthorized AI use describes the pattern plainly: employees adopt tools with good intentions, outside governance and procurement controls, creating data flows that security teams cannot see (Wilson Sonsini). A fast, predictable exception route is cheaper than discovering the tool in a disclosure filing.

"Leadership is responsible for AI governance" is not ownership. Ownership means a named role that answers a specific question within a specific time.

Split the ownership into three layers and give each a concrete question:

• Policy owner (usually legal or risk): Is this conduct covered by the policy, and does the policy need to change? Answers within five business days.
• Tool owner (usually IT or security): Is this tool approved for this data class, and what does its audit log show? Answers within one business day.
• Use-case owner (the business unit): Who reviews outputs, and who signs off on the exception? Answers immediately, because it is usually the person asking.

The third layer is the one most policies omit, and it is the one that decides most routine cases. Research on AI incident response plans frames this as a set of questions every organization should be able to answer before an incident: what counts as an incident, which policies apply, who is notified, and who holds the authority to pause operations (IAPP analysis). Those are ownership questions. If the answer is a committee, the practical answer is nobody.

One more habit: write the ownership table into the policy itself, with role names and response times, and review it whenever the organization chart changes. Governance documents rot fastest at the seams between teams.

Most AI policies contain a sentence like "do not upload confidential information." It fails for a simple reason: employees do not hold a mental map of what is confidential, and the tool does not help them build one.

The fix is to attach the AI rule to the data classification scheme the organization already uses, and then to write examples for the three or four categories people actually handle. One university policy does exactly this, requiring that data entered into an AI tool be evaluated against its information classification policy and restricting public tools to low-risk, public data (St. John's University Policy 1038). That works because the classification scheme already exists and employees have been trained on it.

Two additions make the boundary enforceable. First, name the formats, since employees often do not think of a dictated note or a screenshot as a paste. Guidance for smaller organizations makes the point that copying, pasting, dictating, and uploading all count as disclosure, and that all company information is confidential regardless of format (Cri Advantage). Second, state the reason, because a rule with a reason travels better than a rule without one. Consumer tools may retain and reuse inputs, which is the mechanism by which an input becomes someone else's search result (Cri Advantage).

For vendor tools, the boundary has a second half: what the vendor does with the data. A third-party risk program should ask, before contracting, how sensitive data is used as training input, how long inputs are retained, and whether deletion is available (Mitratech). Put the answers in the tool register next to the approval, so the boundary is documented at the point of use rather than buried in a contract.

The single highest-return activity in policy design is a tabletop exercise. Gather the people who would actually be in the room, hand them a scenario, and watch where the policy fails to tell them what to do. Four scenarios cover most real failures.

Scenario one: the agent reaches outward. A workflow agent with a service credential calls an external API that nobody documented. The questions to test: who can halt the agent, how fast, and what log proves what it sent? Published incident response playbooks treat "unauthorized AI agent action" as its own incident type, with indicators such as unexpected API calls from agent credentials and access to systems outside the agent's permission boundary (Aona AI incident response playbook). If your policy does not name a halt authority, the exercise will surface it in ten minutes.

Scenario two: the paste. An employee drops a spreadsheet with customer records into a consumer chatbot. The questions: who detects it, what is the notification sequence, and does the four-business-day disclosure clock apply? Playbooks classify this as data leakage and prescribe isolating the tool, preserving prompt and response logs before revoking access, and assessing retention on the vendor side (Aona). The policy should tell people to preserve logs before they revoke keys, because the instinct to shut everything down destroys the evidence.

Scenario three: the model repeats something it should not. Output contains text that looks like it came from internal documents. Traditional incident response has no category for this. Analysts writing on AI incident plans note that standard plans are oriented toward hacking and data breaches, while AI systems bring additional failure modes including model extraction, data poisoning, and membership inference (IAPP). The policy needs a route for "the model behaved strangely" that does not require the reporter to name the attack.

Scenario four: the tool nobody approved. Someone finds a popular assistant wired into a team's workflow, handling customer data, with no review. The first question is whether to block it. Guidance on shadow IT argues for identity-first discovery and owner validation before blocking, with each discovered application assigned a named owner, a risk score, and one remediation decision backed by closure evidence (Adaptive Security). Blocking first teaches teams to hide.

Run each scenario for 45 minutes, capture the moments where someone says "I don't know who decides that," and turn each one into a policy edit. Two rounds a year is enough to keep the document honest.

The last failure mode is the quiet one: an incident happens, everyone is tired, and the policy is unchanged. The remedy is procedural. Require a written review within a fixed window after any incident above a defined severity, name the owner, and require the output to be a specific change or an explicit decision not to change, recorded with a reason.

Make the review answer three questions. Was this a policy gap, a control failure, or a user error? If it was a gap, which rule was missing or ambiguous? If it was a control failure, which check failed to produce evidence? That framing separates the document from the tooling, which matters because the two get fixed by different people.

Keep a change log with dates and reasons. It does two things during the next incident: it shows a regulator or auditor that the organization learns, and it stops the same debate from being relitigated. Employment counsel makes a related point about cadence, noting that regular audits, training, and policy updates are what keep AI use responsible as the legal landscape shifts (Littler). The audit is not paperwork; it is the mechanism by which the policy stays true.

If your organization is standing up agents and putting models behind a single interface, one practical step is to standardize how those models are called, so that logs, keys, and revocation are consistent across use cases rather than reinvented per team. Quanta Inference puts text, image, video, audio, and embedding models behind one OpenAI-compatible API key (Quanta Inference), which simplifies the question "what did this credential have access to" that every tabletop exercise eventually asks.