Can a single policy cover an organization with multiple regulated business lines?

A single policy with regime-specific annexes works for many organizations. A healthcare-and-life-sciences parent with a separate financial services subsidiary needs HIPAA rules for one division and SR 11-7 rules for another. The main policy document covers the shared elements (identity binding, sanctioned tools list, audit retention principles). The annexes cover the regime-specific data classes and the regime-specific retention floors. The enforcement layer can configure per-division policies on the same architectural foundation.

What if our sanctioned tool list is too restrictive and employees go to shadow tools?

That is the failure mode most policies fall into. The fix is to make the sanctioned list cover the actual workflows employees need to do their jobs with AI. If the sanctioned list is two tools and employees need six categories of AI capability, employees go to shadow tools to get the work done. The policy and the enforcement layer have to be in sync with what the business actually needs. The right cadence is to review the sanctioned list quarterly against the use cases that have emerged and the new vendor capabilities.

How do we handle vendor SaaS tools that add new AI features mid-contract?

The vendor's release of new AI features inside an already-approved SaaS tool changes the data path. The policy should require that any new AI feature in a sanctioned SaaS tool triggers a fast-track review of the data path: where the prompt goes, who hosts the model, what retention applies, whether the existing BAA or DPA covers the new processing. The enforcement layer can block or proxy the new feature's endpoints until the review completes.

Does the policy need to cover AI-generated content produced by employees?

Yes. The output handling section of the policy has to cover what employees can do with model output: which decisions cannot rely on AI output without human review, what attribution is required for customer-facing artifacts, how output is treated for IP purposes. The standard pattern is that AI-generated text used in customer-facing artifacts requires attribution and human review; AI-generated decisions in regulated workflows require human accountability. Output handling is a section most early policies skip and most mature policies have to add later.

What audit evidence does the policy need to produce on demand?

Under EU AI Act Article 12 and most sector regulators, the deployer needs to produce the per-request record for any specific AI decision under review: identified user, timestamp, tool, classification, policy version, outcome. Under HIPAA, the audit log of PHI access under the policy. Under SOC 2, the evidence that the controls described in the policy operated as designed during the audit period. The enforcement layer is what produces all three. A policy without the enforcement layer produces only the policy document itself, which is not the same as the per-request evidence.

AI Usage Policy Examples: Six Working Templates by Industry

The AI usage policies that survive a regulatory review do not come from a generic SaaS template. They are calibrated to the specific data the employees handle and the specific compliance regime the organization sits under. The healthcare policy turns on PHI and the BAA chain. The financial services policy turns on MNPI and DORA Article 28. The SaaS policy turns on customer data and the EU AI Act deployer obligations. The legal policy turns on privilege under ABA Opinion 512. The federal contractor policy turns on CUI and the OMB AI memo. The manufacturing policy turns on operational technology data and trade secrets.

I want to walk through six industry-calibrated policy examples, the specific clauses each one needs, and the enforcement layer that operates underneath all of them.

Healthcare AI usage policy

The healthcare policy starts from PHI. Under HIPAA, any disclosure of PHI to an entity without a Business Associate Agreement is a violation regardless of intent. Cloud Radix found that 57% of healthcare professionals process PHI through unauthorized AI tools. That figure is the operational gap.

The policy's specific clauses cover the BAA chain (only AI vendors with executed BAAs are sanctioned), the SOAP-note and diagnostic-plan classes (these are PHI by default), the prior-authorization summary workflow (often where PHI moves into AI), and the audit retention floor (six years for HIPAA, longer for state law in some jurisdictions). The Office for Civil Rights treats the disclosure as the violation; intent is not a defense.

Sanctioned tools in healthcare are narrow. AWS Bedrock with a BAA, Azure OpenAI Service with the healthcare addendum, an internally hosted model on infrastructure under the covered entity's control. Consumer ChatGPT, consumer Claude, and most embedded AI features in non-BAA SaaS are not sanctioned for PHI.

The enforcement requirement is that PHI in prompts is detected at the wire, before the request reaches a model. The policy without the enforcement layer cannot demonstrate compliance per request.

Financial services AI usage policy

The financial services policy starts from material non-public information. Under SEC rules and existing books-and-records obligations, MNPI moving into an external model is a control failure. DORA Article 28 specifically requires governance of third-party AI providers. SR 11-7 model risk management applies to AI-assisted decisions in credit, trading, and compliance.

The specific clauses cover the MNPI class (earnings figures pre-release, M&A material, trading positions), the research and analyst workflows (often the highest-risk surface for shadow AI), the customer financial information class (PII plus account data), and the audit retention (seven years for SEC books-and-records, longer for some classes). The DORA Article 28 requirements apply to the vendor chain.

Sanctioned tools include the major LLM providers under enterprise contract with negotiated data handling terms. Personal-account access is shadow regardless of which tool. The compliance team's tools (surveillance, communications monitoring) need to cover AI-prompt content the same way they cover email and chat.

For Annex III, point 5 of the EU AI Act, credit scoring AI is high-risk and the Article 12 logging obligation applies. The financial services policy has to produce per-request records.

SaaS company AI usage policy

The SaaS policy turns on customer data and the company's own EU AI Act exposure. If the SaaS product processes customer data through AI features, the company is an EU AI Act deployer for that processing. Customers of the SaaS who run the AI features in high-risk uses (HR, credit scoring, hiring) inherit Article 12 obligations that the SaaS vendor's architecture either supports or does not.

The specific clauses cover the customer-data class (anything sent through the SaaS product on behalf of a customer), the internal-data class (employee handbooks, internal financial figures, source code), the model output reuse policy (output that goes into customer-facing artifacts), and the audit retention (six months minimum under Article 19, longer if the SaaS contract requires).

Sanctioned tools are typically the model providers the SaaS has under enterprise contract. Embedded AI features in productivity SaaS (Notion AI, Slack AI, GitHub Copilot) require a per-tool review because the data path runs through the productivity vendor's contract.

The customer-disclosure clause is unique to SaaS: the policy has to state how the company discloses AI usage on customer data in the product documentation, the privacy policy, and the trust portal.

Legal services AI usage policy

The legal services policy turns on the duty of confidentiality, the privilege doctrine, and ABA Formal Opinion 512. Pasting client confidences into a model without an enterprise contract that protects confidentiality can break privilege under the inadvertent disclosure doctrine.

The specific clauses cover the client-confidence class (any work product, any communication on behalf of a client, any factual information learned in representation), the privilege boundary (consumer AI tools sit outside it; enterprise tools under specific contractual terms can sit inside it), the document review workflow (where AI is increasingly used and where exposure is concentrated), and the supervision duty under Opinion 512.

Sanctioned tools are limited to those with contractual terms that the firm has reviewed for privilege preservation: enterprise plans of major LLM providers with appropriate data handling clauses, internally hosted models. Personal accounts, even on otherwise-approved tools, are not sanctioned for client confidences.

The audit record produced under the policy is the evidence the firm produces in a privilege challenge.

Federal contractor AI usage policy

The federal contractor policy turns on controlled unclassified information and the OMB M-24-10 AI governance memo. Pasting CUI into a non-FedRAMP-authorized model violates the boundary by definition. CUI handling rules under NIST SP 800-171 apply.

The specific clauses cover the CUI class (the categories of CUI the contractor handles), the FedRAMP boundary (only FedRAMP-authorized AI services are sanctioned for CUI), the M-24-10 governance requirements (the agency's AI use case inventory, the impact assessment, the risk management plan), and the audit retention (per contract; typically three years minimum, longer for some agencies).

Sanctioned tools for CUI are narrow: Azure Government with the FedRAMP High authorization on the GCC-High tenant, AWS GovCloud with appropriate authorizations, agency-internal models. Most commercial AI tools, including the standard enterprise plans, are outside the FedRAMP boundary for CUI.

The disclosure obligation runs to the contracting officer. The audit evidence is what the contractor produces in an agency review.

Manufacturing AI usage policy

The manufacturing policy turns on operational technology data, trade secrets, and the cross-border data movement rules. OT telemetry, process recipes, supplier specifications, and quality data are categories that often move into AI workflows during process optimization.

The specific clauses cover the OT-data class (telemetry, process state, control parameters), the trade-secret class (process recipes, design specifications, supplier data), the export-control class (technical data subject to ITAR or EAR), and the cross-border data movement rules (CBPR, China's PIPL, EU adequacy).

Sanctioned tools for OT-adjacent AI are typically internally hosted or on infrastructure with verified geographic and contractual control. Cloud LLM providers under enterprise contract can be sanctioned for non-trade-secret workflows. Trade secrets and export-controlled data are shadow for almost any external model regardless of contract.

The audit record covers the OT and engineering workflows where AI augments human decisions on quality, safety, and process control.

The shared enforcement layer

All six policies depend on the same enforcement layer at the request boundary. Identity binding from the corporate IdP. Prompt-level classification against the specific data classes each policy names. Per-decision audit record under the deployer's control.

The classification rules differ. Healthcare detects PHI. Financial services detects MNPI. SaaS detects customer data. Legal detects client confidences. Federal contractors detect CUI. Manufacturing detects OT data and trade secrets. The architectural pattern that lets each policy name its own classes and have them enforced at the request layer is the same.

The audit records produced under the six policies look similar from a structure standpoint. Identity, timestamp, tool, classification, policy version, outcome. The retention and disclosure obligations differ.

DeepInspect

This is the architecture the six policies depend on. DeepInspect sits at the AI request boundary as a stateless proxy between users and agents and any LLM. The policy is configured per data class: PHI for healthcare, MNPI for finance, customer data for SaaS, client confidences for legal, CUI for federal contractors, OT data for manufacturing. The classification runs in line. The decision is recorded as a per-decision audit record the application calling the AI does not control.

The policy document becomes the operational control once the enforcement layer can produce the per-request evidence that the document describes. Without the enforcement layer, six well-written policies sit on the shelf while the data moves on a different path.

If you are working through which template fits your organization, the policy is the straightforward part. The enforcement layer is the harder part. Let's talk today.