An AI policy is operationally real when runtime controls back it: governed AI requests are attributed to identifiable users, sensitive workflows are routed through sanctioned providers where possible, and policy enforcement events are logged in an audit trail your auditor can read.
The audit question that exposes paperwork policies
Every modern AI-aware SOC 2 audit, customer DDQ, and bank-partner questionnaire eventually asks the same question in different words: "How do you know your employees are following the AI policy you wrote?" The question is deceptively simple, and the usual artifacts don't answer it. A Notion policy doc, a signed acknowledgment form, and an all-hands where someone read out the rules all describe what employees were told, not what they actually did. Auditors are increasingly trained to dig past the policy doc and ask for the operational evidence behind it.
What they're looking for is whether the policy is enforced by something that runs continuously without human intervention. There are three such controls that, when present, turn a paper policy into a real one. When any of the three is missing, the policy fails its first serious audit — not because the policy is poorly written, but because there's no evidence the rules are being followed.
Control 1: Identity attribution on every AI request
The first control sounds obvious but is missing from most mid-market AI stacks: governed model requests should be attributable to a specific employee at the moment they happen, and provider telemetry should be mapped to employees where the provider supports it.
Why this matters: when an auditor asks "who accessed which AI tool with what data?", you should be able to answer with timestamp-level precision for governed paths and clear coverage labels for everything else. A workspace-level invoice from OpenAI says "50K requests this month from your org" but doesn't say who made them. Without attribution, your policy's user-specific rules ("only members of the Engineering team may use Claude API") are unenforceable in practice — you can write the rule but you can't verify compliance after the fact.
The operational pattern that makes this work is to route governed AI traffic through a managed gateway that injects identity into outbound requests, and to ingest provider telemetry that includes user-level attribution where the provider supports it (ChatGPT Enterprise Workspace Analytics, Anthropic Usage API, GitHub Copilot reports all do). Together these produce a per-user audit log that survives a forensic question.
Control 2: Provider restriction at the gateway
The second control is harder and more important: sensitive workflows should be restricted to sanctioned providers at request time, automatically, without requiring employees to remember the rule.
Most AI policies include language like "do not send confidential customer data to non-enterprise AI tools" or "PII may only be processed through sanctioned providers with signed DPAs." These rules are honest and reasonable. They're also impossible to follow consistently in practice, because employees handling many tasks per day can't reliably remember which provider is approved for which kind of work before pasting into a prompt box.
The runtime control that closes most of this gap is per-actor provider restriction enforced by the gateway. Each actor — human, app, or agent — gets an approved provider and model scope, and a request to anything outside that scope is blocked at the gateway, or logged in shadow mode while you tune. A workflow that must stay on a provider with a signed DPA can be pinned to it, and an attempt to route the same work to an unapproved tool is stopped at the point of use instead of discovered in an audit. Classifying the prompt content itself — detecting a specific SSN or customer record inside a request — is a harder, separate problem: Tallin governs which provider and model an actor may use and reports what runs outside Tallin as not covered, rather than claiming to inspect every prompt.
This control is what turns the provider-routing language in your policy from aspirational to operational. Without it, the policy is asking employees to make routing decisions at the pace of their daily work — which is the failure mode auditors are now specifically looking for.
Control 3: Policy enforcement audit log
The third control is the evidence layer. Every time a policy rule is checked at the gateway — whether the request was allowed, blocked, throttled, or flagged — that event needs to be logged in an immutable audit trail with enough context to reconstruct the decision.
Why this matters: when an auditor asks "show me a sample of policy enforcement events from the last 30 days," you need to be able to produce a query result, not a screenshot. A real audit log has: timestamp, user, provider, model, approved-scope match, policy rule applied, decision, reason. Multiply that across thousands of requests per month and you have the operational evidence base that turns "we have a policy" into "here's what the policy did last Tuesday at 3:47 PM."
This is also the layer that closes customer DDQs. Sponsor banks and enterprise customers are increasingly asking not just "do you have an AI policy?" but "can you produce evidence that it's been continuously enforced over the audit period?" The audit log is the answer. Without it, the DDQ response is a confident-sounding paragraph that doesn't survive a follow-up call.
Why the three controls have to ship together
Each of the three controls is incomplete on its own. Identity attribution without provider restriction tells you who did the thing but not whether the thing used an approved provider. Provider restriction without an audit log tells you the gateway blocked something but you can't prove it across time. An audit log without identity attribution is just a stream of anonymous events.
Together, they form what auditors recognize as a real AI governance control set: who, what was attempted, what rule applied, what happened. Each of the three controls produces evidence the others can reference, and the combination is what turns the policy document from paperwork into something a customer security team will accept as a real answer.
The practical implication for mid-market companies is that you probably shouldn't write an AI policy in isolation. Write the policy with the three runtime controls in mind, so each rule in the policy maps to specific evidence the controls will produce when enforced. Otherwise you end up with a policy document and a year of audits to come where auditors keep asking the same operational question and you keep answering with the document.
Key takeaways
- A policy without runtime controls is paperwork. Auditors and customer security teams are now trained to dig past the document.
- Three controls turn a paper policy into a real one: identity attribution per request, provider restriction at the gateway, immutable audit log of policy decisions.
- Each control on its own is incomplete. Together they answer the audit question 'who did what, against which rule, when?'
- Write the policy WITH the three controls in mind — so each rule in the doc maps to evidence the controls will produce when enforced.
- Tallin packages all three as one platform — gateway-level enforcement plus per-tenant audit log plus the board pack export that surfaces it.
Keep reading