Do I need this policy if I already have an acceptable-use policy?

The acceptable-use policy covers workstation and network behavior. The AI usage policy covers a request pattern the acceptable-use policy typically does not address: the AI request layer, the model provider, the prompt classification, and the audit record for AI decisions. Regulators under the EU AI Act, NIST AI RMF, and ISO 42001 expect an AI-specific policy artifact.

What retention period should apply to AI request logs?

Retention has to match the regulatory obligation of the deployed AI system's data classes. HIPAA-covered workloads carry 6-year retention on required records; the EU AI Act Article 12 log has no explicit retention but the record has to survive the lifetime of the system. SOX-covered workloads carry 7-year retention on records material to financial statements. Set retention to the maximum of the applicable regulatory floor across the record classes.

Who should own the AI usage policy?

The Head of Security or the CISO typically owns the policy. Ownership includes the periodic review of policy events, the annual review of the policy content, the exception approvals, and the incident response coordination. Ownership sits with a single role because the enforcement layer has to have a single authoritative approver for policy changes.

How do I handle personal-account use by employees who paid for personal ChatGPT Plus?

The policy has to prohibit personal-account use for business purposes. The enforcement layer detects personal-account use through the identity binding at the gateway: a request from an [Organization]-managed device to chat.openai.com that lacks the enterprise identity token flags as an unsanctioned personal-account request. The gateway denies the request and logs the event.

What happens when a new AI service launches and employees start using it before the policy team can review?

The policy has to include a default-deny provision on new AI services. The enforcement layer denies traffic to any AI service that has not been explicitly added to the sanctioned providers list. The default-deny closes the gap the policy review process cannot cover in real time.

AI Usage Policy Template: The Clauses That Actually Get Enforced at the Gateway

Most AI usage policies get drafted as a two-page document, circulated for legal review, signed by the CISO, and stored in the compliance drive. The document sits alongside the acceptable-use policy and the remote-access policy. The document alone changes no request that leaves the employee's browser and reaches ChatGPT, Claude, or a shadow copilot. According to IBM's Cost of Data Breach Report, one in five breached organizations experienced breaches linked to shadow AI, and those breaches cost $670,000 more on average than standard breaches. Only 37% of organizations have any detection or governance policies in place for AI usage per Netwrix. The policy document without the enforcement mechanism is what produces that gap.

I want to walk through the clauses that translate into enforcement decisions at the AI request layer, the roles that draft and review the policy, and the operational records the enforcement layer produces so the policy owner can sample compliance at quarterly review.

The scope clause

The scope clause defines which employees, contractors, partners, and systems the policy covers. Scope should name each population explicitly, because the enforcement layer treats each population as a distinct identity class.

This AI Usage Policy applies to:
- All full-time and part-time employees of [Organization]
- All contractors and consultants engaged by [Organization]
- All service accounts and automated agents operating on behalf of [Organization]
- All third-party workforce (staff augmentation, agency workforce) accessing [Organization] systems

Scope covers use of AI systems for [Organization] business purposes, whether the AI service is accessed via [Organization]-managed devices, personal devices during business use, or third-party workforce environments.

The scope clause has to include automated agents. Agentic AI systems that authenticate as service accounts and call LLM providers are the fastest-growing category of AI request traffic in enterprises. The policy that excludes agents from scope leaves the agent traffic ungoverned.

The sanctioned providers clause

The sanctioned providers clause lists the AI services approved for use. The clause has to specify the provider, the models within the provider, and the account context (enterprise account, team account, personal account).

Sanctioned AI providers for [Organization] business use:

Tier 1 (approved for all use cases including regulated data):
- OpenAI Enterprise (ChatGPT Enterprise, GPT-5 API via [Organization] account)
- Anthropic (Claude for Enterprise, Claude 4 API via [Organization] account)
- [Cloud AI]: AWS Bedrock, Azure OpenAI, or Google Vertex AI via [Organization] tenant

Tier 2 (approved for non-regulated data only):
- GitHub Copilot for Business
- Cursor for Enterprise
- [Additional coding assistants approved for engineering teams]

Prohibited (not approved for any [Organization] use):
- Personal accounts on any AI service (Free ChatGPT, personal Claude.ai, etc.)
- Consumer AI assistants embedded in personal devices without enterprise controls
- Chinese-origin AI services (Qwen, DeepSeek, Doubao, Kimi) unless expressly approved for a specific project by [Organization] Security

The Tier 1 / Tier 2 / Prohibited structure gives the enforcement layer three decision paths per request. Requests to Tier 1 endpoints run under the standard policy. Requests to Tier 2 endpoints run under a restricted data policy that blocks regulated data classes. Requests to Prohibited endpoints get denied at the gateway.

The prohibited data classes clause

The prohibited data classes clause enumerates the data types that must never appear in AI prompts. The classes have to match the organization's data classification taxonomy so the enforcement layer can apply the classifier to each request.

The following data classes are prohibited from inclusion in any AI prompt:

- Customer PII (names, addresses, dates of birth, government identifiers)
- Customer PCI data (payment card numbers, CVVs, cardholder data)
- Customer PHI (medical records, diagnostic notes, insurance identifiers) for HIPAA-covered entities
- Employee PII beyond the employee's own record
- Financial forecast or pre-earnings data prior to public disclosure
- Trade secrets, source code marked "Restricted," and intellectual property under embargo
- Legal privilege materials and pending litigation content

For customer PII, the DeepInspect gateway runs the pattern-based classifier on the prompt at request time, redacts the matched classes, and logs the redaction. The policy owner sees the redaction event in the audit record. The employee sees a warning that the prompt was modified.

The allowed use cases per role clause

The role clause maps each role to the AI use cases the role is allowed to perform. The role has to match the identity the enforcement layer resolves at request time.

Marketing (marketing.*):
- Copy generation for public marketing materials
- Content ideation for public blog and social
- Competitive research using publicly available sources
- Not allowed: campaign attribution data, customer contact lists

Engineering (engineering.*):
- Code assistance via GitHub Copilot for Business or Cursor for Enterprise
- Debugging and refactoring using non-restricted source code
- Not allowed: source code marked "Restricted," secrets, production credentials

HR (hr.*):
- Job description drafting from role templates
- Candidate pipeline reporting from aggregate metrics
- Not allowed: candidate PII in prompts, protected characteristic data, biometric identifiers

Finance (finance.*):
- Modeling exercises on synthetic or public data
- Board deck drafting from publicly disclosed figures
- Not allowed: pre-earnings data, customer financial records, tax records

The role-to-use-case mapping runs at the identity layer of the gateway. The gateway resolves the employee's role from the identity token, matches the target endpoint and prompt classification against the allowed list, and permits or denies the request based on the mapping.

The monitoring and audit clause

The monitoring clause commits the organization to logging AI request traffic and reviewing the logs at defined intervals. The clause has to name the record class, the retention period, the review cadence, and the review owner.

All AI request traffic in scope of this policy is subject to monitoring. The AI gateway produces a per-decision audit record for every request that includes the requester identity, timestamp, target AI service, model version, prompt classification, applied policy, and decision (permit or deny).

Records retain for 7 years for HIPAA-covered workloads, 6 years for SOX-covered workloads, and 24 months for other workloads.

The AI Policy Owner (currently the Head of Security) reviews aggregate policy events weekly and audits a random sample of 50 records monthly. The AI Policy Owner reports policy exceptions and gross-scope events to the Executive Risk Committee quarterly.

The incident reporting clause

The incident reporting clause commits the organization to reporting AI-related incidents through the standard incident channel. The clause has to define what counts as an AI incident.

AI incidents subject to this reporting obligation include:

- A confirmed disclosure of prohibited data classes to a sanctioned or unsanctioned AI provider
- A confirmed AI-generated output that materially misled a customer, employee, or regulator
- A confirmed prompt injection or model output manipulation that caused an unauthorized action
- A confirmed access to a sanctioned AI provider from an unsanctioned account (personal account used for business)

Report AI incidents to the Security Operations Center via [reporting channel] within 24 hours of discovery. The SOC follows the standard incident response process with the AI Policy Owner in the response cell.

The enforcement mechanism clause

The enforcement mechanism clause names the technical control that binds the policy to the traffic. Without an enforcement mechanism named in the policy, the policy is aspirational. Regulators, auditors, and internal risk committees increasingly ask for the enforcement mechanism at policy review.

This policy is enforced at the AI request layer via [Organization]'s AI gateway ([enforcement platform name]). The gateway intercepts all AI request traffic from [Organization]-managed devices, applies the policy at the request level, and produces the audit records described in the monitoring clause.

The AI gateway configuration is versioned in [source control system]. Changes to the AI gateway configuration follow the standard change management process. The AI Policy Owner reviews and approves configuration changes affecting policy scope, sanctioned providers, prohibited data classes, and role-to-use-case mappings.

DeepInspect

The DeepInspect gateway is the enforcement mechanism the policy names. The gateway intercepts AI request traffic between [Organization]-managed endpoints and the sanctioned and unsanctioned AI providers. The gateway resolves the requester identity, applies the policy on the request, and produces the per-decision audit record the monitoring clause references.

The gateway's policy engine runs the sanctioned-providers rule, the prohibited-data-classes rule, and the role-to-use-case rule on each request in sequence. The policy engine reaches a permit-or-deny decision on the request in under 50 milliseconds. The audit record captures the identity, timestamp, target, prompt classification, applied rule, and decision.

If your organization is drafting an AI usage policy and wants to align the clauses to a specific enforcement layer, take the AI readiness self-assessment at deepinspect.ai/ai-readiness.