AI Policy Templates for Mid-Market US Companies

Every mid-market US company I work with eventually realizes they need written AI policies. Usually it surfaces during a customer security questionnaire, a vendor due diligence request, or — more painfully — after an incident where an employee pasted customer data into a public LLM. The good news is that you don't need a 60-page policy framework to be in a defensible position. You need three concrete policies that cover the three things that go wrong: people misusing AI tools, vendors mishandling your data, and incidents not being detected or escalated. This is what each one needs to include, with the clauses I draft for clients.

Policy 1 — AI Acceptable Use Policy

The acceptable use policy is the employee-facing document. It tells your people which AI tools they can use, what data they can put into them, what they can do with the outputs, and what happens if they violate the policy. The core clauses:

**Approved tools list.** Maintain an explicit list of approved AI tools (with versions and tiers — ChatGPT Enterprise is different from ChatGPT Free), and require an exception process for anything not on the list. 'Employees may only use AI tools listed in Appendix A of this Policy. Use of any AI tool not on the approved list requires prior written approval from the IT Security team.'

**Data classification gates.** Tie acceptable use to your existing data classification scheme. 'Confidential and Restricted data may only be entered into AI tools that appear in Appendix A under tier "Confidential-Approved." Public and Internal data may be entered into any approved tool.' If you don't have a classification scheme, this policy forces you to create one — which is a feature, not a bug.

**Output review requirements.** AI outputs need human review before being relied upon for any decision with legal, financial, or safety implications. 'Outputs generated by AI tools may not be used as the sole basis for any decision affecting an individual's employment, credit, healthcare, education, or housing without documented human review and approval.' This clause maps directly to the Colorado AI Act requirements and to general best practice under the NIST AI Risk Management Framework.

**Prohibited uses.** Spell out what's forbidden. Generating content for use in deceptive practices. Creating synthetic media of real people without consent. Generating code that will be deployed without security review. Bypassing safety controls. Using AI to evaluate job applicants, employees, or customers without HR/Legal review.

**Disclosure obligations.** When AI is used to produce customer-facing content, internal communications above a defined threshold, or any artifact going into the public domain, the policy should require disclosure or labeling consistent with your brand standards.

Policy 2 — AI Vendor Policy

The vendor policy is the procurement-facing document. It defines what due diligence is required before signing an AI vendor, what contractual terms are required, and what ongoing monitoring is needed. The core clauses:

**Tier classification.** Not every AI vendor needs the same level of scrutiny. Tier vendors by risk: Tier 1 (touches regulated data, makes consequential decisions, deeply integrated), Tier 2 (touches confidential business data, automates internal workflows), Tier 3 (productivity tools, no regulated data). Due diligence depth scales with tier.

**Required artifacts before signature.** For Tier 1 and 2 vendors: completed AI Vendor Risk Scorecard, SOC 2 Type II report, ISO 27001 certificate (or ISO 42001 once mature), model cards for any model touching your data, sub-processor list, completed DPA with training carve-out, evidence of bias testing, and an incident response commitment with a 72-hour notification SLA.

**Approval authority.** Define who can approve each tier. Tier 3 can usually be approved by IT. Tier 2 requires Security + Legal. Tier 1 should require Security + Legal + the business owner + a named executive sponsor. The approval should be documented and retained.

**Ongoing monitoring.** Vendors don't stay static. The policy should require annual reassessment for Tier 1 and 2, model-change notification with mandatory review, and immediate review of any vendor that has a public incident.

Policy 3 — AI Incident Response Policy

The incident response policy is the operations-facing document. It defines what counts as an AI incident, who responds, and what gets escalated to whom. Most AI incidents don't look like traditional security incidents, which is why a standalone policy matters. Our broader Security Incident Response practice covers the cyber-incident overlap.

**Definition of AI incident.** Be explicit. AI incidents include: prompt injection that resulted in unauthorized data access; hallucinated outputs that were acted upon in a way that caused harm or could have; bias-driven outputs that materially affected a person; data leakage to or from an AI tool; model jailbreaks producing policy-violating content from a company account; vendor-side incidents implicating Customer Data; and any AI-driven automated decision that produced a materially wrong result.

**Reporting channels.** A single mailbox or ticket queue, monitored 24/7, with escalation rules. Employees must be able to report suspected AI incidents without going through their manager — most AI incidents involve employee misuse, and bypassing the chain of command is the only way to surface them honestly.

**Triage and severity tiering.** Classify incidents by impact: Sev-1 (regulated data exposure, decision affecting a person's rights), Sev-2 (confidential business data exposure, no individual harm), Sev-3 (policy violation, no data exposure). Tie response timelines and notification obligations to severity.

**Notification matrix.** Who gets told, in what timeframe, by whom. Internal stakeholders (Legal, Security, the business owner, executive sponsor). External stakeholders (affected individuals, regulators, customers under contract, vendors implicated). Map this to your existing breach notification obligations — HIPAA, state privacy laws, sector regulators — and to AI-specific obligations under any frameworks you're aligned to.

**Post-incident review.** Every Sev-1 and Sev-2 gets a written post-incident review within 30 days, with root cause analysis, contributing factors, and remediation actions. This is where the program actually improves.

How to Roll These Out

Don't roll out three policies in a single all-hands. Sequence them: AI acceptable use first (because that's what employees actually need), AI vendor policy second (because that gates new tools coming in), incident response policy third (because by then you have something to respond to). Train each rollout. Tie violations to the existing disciplinary framework. Review annually. The biggest mistake I see is publishing policies that nobody knows exist, which produces compliance paper without any actual behavior change. The full AI Governance & Compliance program puts these three policies inside a larger operating model — but if you only do these three, you're already ahead of most of the mid-market.