Do we need a separate AI usage policy or can we update the existing acceptable use policy?

A separate AI usage policy is the cleaner pattern. The acceptable use policy covers general computing resources and is written at a level of abstraction that does not address prompt content, model authorization, or audit retention specific to AI. A dedicated AI usage policy can reference the acceptable use policy for the general rules and add the AI-specific requirements. Some organizations have integrated the AI rules into the AUP as a chapter. Either pattern works; the failure mode is having no specific AI rules at all.

How often should the sanctioned tool list be re-validated?

Quarterly is the minimum cadence the regulated organizations I have seen end up at. The vendor release cycle for major AI-bearing SaaS tools is roughly quarterly, and new AI features inside an already-approved tool change the data path. Annual re-validation is too slow; monthly is rarely feasible for the procurement bandwidth. Quarterly re-validation with a fast-track process for high-impact new features is a workable rhythm. The policy should state the re-validation cadence explicitly so auditors can verify the program is operating.

What is the minimum audit retention period for AI usage records?

Under EU AI Act Article 19, the floor is six months. Under HIPAA, the audit retention for PHI access is six years from the date of the record. Under SEC books-and-records rules, financial firms face retention obligations of three to seven years depending on the record class. The practical answer for most regulated organizations is that six months is the EU AI Act floor and the operational retention has to match the longest applicable retention requirement across the organization's regimes. Architectures designed to support seven years of retention are within the right ballpark.

How do we enforce the policy against employees using personal AI accounts on personal devices?

The policy can prohibit it and the corporate IdP can be required for sanctioned access. The technical enforcement on the personal-device side is partial. Network-level controls on the corporate network catch some of it. The deeper answer is that an employee who exfiltrates regulated data through a personal AI account on a personal device is committing a policy violation that the organization needs to detect through other channels: data movement signals on the corporate network, employee monitoring on managed devices, and the disciplinary process for confirmed violations. The AI usage policy is one layer; the data movement program is another.

What evidence do we produce if a regulator asks how an AI system handled a specific request?

Under an audit-ready policy with an enforcement layer in place, the evidence is the per-decision audit record for that request: the identified user, the timestamp, the tool, the data classification applied, the policy version in effect, and the decision outcome. The record is tamper-evident. Without that record, the deployer is unable to produce primary evidence and falls back to inference from application logs. Application logs are not primary evidence under most evidentiary regimes because the application that made the decision also wrote the log. The self-attestation problem applies.

How to Write an AI Usage Policy That Holds Up Under Audit

Cloud Radix found that 78% of employees use unauthorized AI tools and 86% of IT leaders are blind to those interactions. Netwrix found that 37% of organizations have any AI-related governance policies in place. Of the organizations that suffer an AI-related breach, 97% lacked proper access controls. The reason the breach number is that high is that most of the policies that do exist are HR-distribution documents the security team cannot demonstrate compliance with.

An AI usage policy that holds up under audit covers data classification, identity binding, sanctioned tools, prompt content rules, audit retention, and incident handling, and is enforceable at the request layer.

I want to walk through the eight sections the policy needs, the enforcement layer it depends on, and the audit evidence the policy has to produce when a regulator asks.

The pattern that fails

Most AI usage policies I see in the field follow an acceptable-use-policy template borrowed from the early-2010s SaaS handbook. The policy lists tools the employee is allowed to use, prohibits pasting "sensitive" data into AI, and asks employees to acknowledge a one-page document during onboarding. The policy sits in the employee handbook and never produces an audit record.

Three failure modes follow. The classification of "sensitive" depends on individual judgment that is calibrated to legacy data, not prompt content. The acknowledged document does not produce evidence that any specific request complied with the policy. The procurement-approved tool list grows stale every quarter as vendors add LLM features.

A policy that fails any one of those produces a paper trail of acknowledgment without a per-request record of compliance.

The eight sections an audit-ready policy needs

1. Scope and definitions

State which AI tools, models, and features the policy covers. Cover externally hosted LLMs, vendor SaaS tools with embedded AI, internal models, agentic workflows, and any model-backed automation that touches enterprise data. Define what counts as an AI request for the purposes of audit (an HTTPS POST to a model API qualifies; an offline batch inference job also qualifies).

2. Data classification matrix

Map the organization's data classification scheme to AI usage. For each class (public, internal, confidential, regulated), state which AI tools may receive that data. PHI under HIPAA, MNPI under SEC rules, PII under GDPR, and PCI cardholder data are the most common regulated classes that need explicit treatment.

3. Sanctioned tool list with versioning

List the AI tools the organization has approved. For each, name the contractual tier (enterprise plan, BAA status, data retention terms). Date the list. Require quarterly re-validation of every tool whose vendor has shipped new AI features in the period. The list is a living artifact, not a one-time acknowledgment.

4. Identity binding requirements

State that every AI request must be authenticated against the corporate IdP. Personal accounts on otherwise-approved tools are not sanctioned. Static service credentials shared across applications are not identity-bound. Where an agent acts on behalf of a user, the policy has to state how the user's identity propagates to the AI request.

5. Prompt content rules

State what employees may not paste into any AI model prompt. Source code with intellectual property indicators, customer PII, internal financial figures, M&A material, employment records, and access credentials are the standard restricted classes. The rule is not "use judgment." The rule is specific data types that the enforcement layer can classify.

6. Output handling rules

State how AI output may be used. Model output cannot be treated as authoritative for legal, financial, medical, or hiring decisions without human review. Output that is reused inside customer-facing artifacts has to be attributed. Output that is used to train or fine-tune internal models has to clear an additional review.

7. Audit and retention requirements

State that every AI request produces a record containing the user identity, the timestamp, the tool used, the data classification applied, the policy version in effect, and the decision outcome. State the retention period (six months minimum under EU AI Act Article 19, longer under sector-specific obligations). State that the audit log is independent of the application generating the request.

8. Incident handling

State the process when an AI-related incident occurs: data exposure to an unauthorized model, prompt injection that altered output, policy violation by an employee. Reference the existing incident response process and the disclosure obligations under EU AI Act, HIPAA, GDPR, and sector regulators. Name the role accountable for the determination.

The enforcement layer the policy depends on

A policy that lists prohibited data classes without an enforcement mechanism is unenforceable. The enforcement layer has three components.

Identity binding at the request layer. The corporate IdP authenticates the user. The user identity travels with the AI request. The audit record includes the identified user. Static service credentials and shared API keys fail this property.

Prompt-level classification. The data classes named in the policy (PHI, PII, source code, MNPI) are detected in the prompt content. The detection is deterministic, runs in line with the request, and produces a classification result attached to the decision.

Per-decision audit record. The decision (allow, redact, block) is recorded with identity, classification, policy version, and timestamp. The record is committed before the model response returns to the application. The record is signed and tamper-evident.

Without all three, the policy is aspirational. The standard application logs the SaaS vendor produces are not the same as an independent audit record under the deployer's control.

What an audit-ready policy produces under review

When a regulator under the EU AI Act asks for the records of how the AI system handled a specific request, the deployer with an audit-ready policy can produce: the identity of the user, the time of the request, the tool used, the classification applied to the prompt, the policy version in effect at that moment, and the decision outcome. The record is tamper-evident.

When an internal auditor asks for the percentage of AI requests in a period that contained restricted data and the outcome of each, the deployer can produce the count from the audit log.

When a customer questionnaire asks how the organization governs the use of AI on customer data, the deployer can produce the policy document and the per-request enforcement evidence that the policy is operational.

These are the three artifacts the policy has to produce. A policy that produces none of them is not audit-ready regardless of how well-written it reads.

DeepInspect

This is the gap DeepInspect closes. DeepInspect sits inline between users and agents and any LLM API as a stateless proxy. Every request is evaluated against the data classification matrix in the policy, the sanctioned tool list, and the identity context. The decision is recorded as a per-decision audit record the application calling the AI does not control.

For the policy to be enforceable in the operational sense, the request-layer evaluation has to actually happen for every request, at machine speed, with an audit trail. The proxy produces all three properties: identity binding from the corporate IdP, prompt-level classification against the policy's data classes, and a signed per-decision record that the application cannot modify.

For Article 12 readiness, the same record satisfies the automatic-recording requirement and the disclosure obligation. For HIPAA, the same record provides the audit evidence the BAA obligations turn on. For SOC 2, the same record demonstrates that the policy is operating as designed.

If you are writing a policy your security team cannot demonstrate compliance with at the request layer, the policy is decoration. Book a demo today.