Quick Answer: An AI acceptable use policy governs how employees use AI tools, while an AI governance policy governs how the company approves and oversees AI systems. The first is a rulebook for staff; the second assigns decision rights, risk reviews and accountability, as in the NIST AI RMF Govern function. Most companies need both.
The AI acceptable use policy vs AI governance policy split trips up many first drafts. One document ends up lecturing employees about model risk reviews or leaving the risk owner with only a list of approved tools.
What is the difference between an AI acceptable use policy and an AI governance policy?
An AI acceptable use policy is written for every employee and answers: what may I do with AI at work? An AI governance policy is written for leadership and system owners and answers: which AI systems do we build or buy, and who is accountable for them?
| AI acceptable use policy | AI governance policy | |
|---|---|---|
| Audience | Every employee and contractor | Leadership, legal, security and system owners |
| Owner | IT or security, with HR | An executive sponsor or AI governance committee |
| Scope | Tools, data, prompts, outputs | Inventory, risk tiers, approvals, vendors, incidents |
| Typical sections | Approved tools, data classes, prohibited uses, reporting | Roles, risk assessment, testing, monitoring, retirement |
| Enforcement | Training, SSO, gateway allowlists, DLP | Approval workflows, audit logs, periodic reviews |
| Review cadence | Every six months and when a tool is added | Yearly, and when a law or system changes |
The two are layers: a use policy is one control inside an AI governance program, not a substitute for it.
What should an AI acceptable use policy include?
A workable AI acceptable use policy fits on two pages and covers approved tools, allowed data classes, prohibited uses, disclosure, ownership of output, and incident reporting. Here is an AI acceptable use policy template you can copy.
AI ACCEPTABLE USE POLICY
1. Approved tools: use only listed AI tools, signed in with your company account.
2. Data: public data in any approved tool; internal data only in tools approved for it;
customer personal data, credentials and regulated data only where explicitly approved.
3. Prohibited: hiring, credit, pay or discipline decisions without human review;
impersonating a real person.
4. Review: check AI output before it is sent, published or merged.
5. Disclosure: say when AI produced substantial customer-facing content, where required.
6. IP: work created with AI belongs to the company; flag output that may copy licensed material.
7. Reporting: report data exposure or harmful output to security the same day.
8. New tools: request them through [approval form]; no personal-account sign-ups.
Owner: [name] | Effective: [date] | Reviewed every six months
List customer-facing assistants too: a support chatbot embedded in your product is an AI tool, and staff need to know which one is sanctioned.
What does an AI governance policy cover that a use policy does not?
It covers decisions no individual employee makes: which AI systems exist, how risky each is, who approves them and who answers for failures.
A common backbone is the NIST AI Risk Management Framework, a voluntary framework from January 2023 built on four functions: Govern, Map, Measure and Manage. NIST calls Govern a cross-cutting function and says it is revising the framework.
- Inventory: a register of every AI system in use (GOVERN 1.6).
- Risk tiers and approval: low for drafting help, high for decisions about jobs, credit or health, which need executive or committee sign-off.
- Testing and monitoring: bias, accuracy and security checks before launch; drift monitoring after.
- Vendor review: data use, retention and training terms.
- Accountability and retirement: a named owner per system, executive responsibility for AI risk decisions (GOVERN 2.3) and a decommissioning process (GOVERN 1.7).
Consider an applicant-screening tool. The use policy tells recruiters to review every rejection; the governance policy asks who approved it, how it was bias-tested and what notice candidates get.
ISO/IEC 42001:2023, published in December 2023, sets requirements for an AI management system: the policies, roles and processes that govern how an organization builds or uses AI.
How do you write rules for AI coding assistants?
Add a short annex to the use policy: approved assistants, no secrets in prompts, human review before merge, and least-privilege agents.
- Approved tools: name approved assistants, IDE plugins and CLI agents, used on company accounts through one endpoint.
- No secrets in prompts: keys, credentials, customer data and connection strings stay out of prompts and agent context.
- Review and licensing: AI-written code gets the same pull-request review, tests and license scanning as any other code.
- Agent permissions: agents that run commands get least-privilege credentials and no production access by default.
How do you enforce both policies with technical controls?
Enforce the use policy with identity and network controls, and the governance policy with inventories, approvals and auditable logs. One tool tests these controls often, and whether ChatGPT is safe for confidential business data explains how personal and business plans treat what staff type.
| Control | Enforces | What it does |
|---|---|---|
| SSO on every AI tool | Use policy | Ties each prompt to a company identity |
| Gateway allowlist | Both | Only approved models and endpoints receive traffic |
| DLP and secrets filtering | Use policy | Redacts credentials and personal data from prompts |
| Request logging | Both | Records who sent what to which model |
| Blocked consumer accounts | Use policy | Stops personal sign-ups to unapproved tools |
| Approval workflow | Governance policy | New tools enter the inventory only after sign-off |
Teams using an enterprise LLM gateway to manage internal AI coding tools can enforce much of the use policy in one place: one endpoint, one allowlist, one log.
Which US AI laws should your policies reflect in 2026?
Five US laws and rules matter most, mainly on the governance side, because they regulate AI in consequential decisions such as hiring. This is general information, not legal advice.
| Law | Key dates | Core requirement |
|---|---|---|
| Colorado SB 26-189 | Signed May 14, 2026; applies from January 1, 2027 | Notice before automated tools materially influence consequential decisions; explanation and human review after adverse outcomes |
| NYC Local Law 144 | Enforced since July 5, 2023 | Annual bias audit of automated employment decision tools, public summary, notice |
| Illinois HB 3773 | In effect since January 1, 2026 | No AI in employment decisions with a discriminatory effect; notice to employees |
| Texas TRAIGA (HB 149) | In effect since January 1, 2026 | No AI developed or deployed with intent to unlawfully discriminate |
| California ADMT rules | Compliance due January 1, 2027 | Notice, opt-out and access rights for automated hiring, pay and promotion decisions |
Colorado's SB 26-189 replaced the state's 2024 AI Act, SB 24-205, before it was ever enforced. The law says that from January 1, 2027, deployers must explain the tool's role within 30 days of an adverse outcome and offer data correction and meaningful human review. The Attorney General enforces it, with no new private right of action. Its proposed rules were filed on August 11, 2026; check that page for their adoption status.
Illinois tests for discriminatory effect; Texas requires intent. No federal law currently preempts these state laws, and a December 2025 executive order (EO 14365) cannot by itself override a state statute. For EU users, Regulation (EU) 2026/1744 moved high-risk rules for uses such as hiring to December 2, 2027.
What mistakes should you avoid when writing AI policies?
- No enforcement. Without SSO, an allowlist and logs, people sign the policy and forget it.
- Banning AI with no approved alternative. Usage moves to personal accounts, which is how shadow AI starts.
- One document for two audiences. Each skips the half written for the other.
- Never reviewing it. Colorado replaced its 2024 AI law in 2026; last year's policy may cite rules that changed.
- Treating a framework as a certificate. The NIST AI RMF is voluntary guidance, not an audit stamp.
How Origins AI enforces AI policy in the stack
Origins AI (originshq.com) is an AI-augmented engineering company that deploys self-hosted AI products inside a customer's environment, with its own team doing the rollout.
The Origins AI Coding Tool puts a self-hosted LLM gateway in front of engineering tools. According to its product page, the gateway restricts which models each team may call, sets quotas, filters secrets and personal data before content reaches a model, and logs every request and response in your environment. An AI code audit server in CI/CD reviews pull requests against the team's own security rules. In on-premise and air-gapped modes, source code is not sent to any external service; in hybrid mode, submitted code context goes to the hosted model.
Origins AI Chat AI is a privately deployed ChatGPT-style assistant for employees that can also be embedded in your product as a customer support widget. Per its product page, it offers single sign-on through SAML 2.0 or OIDC, access scoped by department and document, PII redaction configurable by data category and role, and an audit trail with a user ID on every message. Retention and deletion controls stay with your deployment. Neither product writes your policy or meets a legal requirement for you; they give it an enforcement point. The product catalogue lists the deployment modes.
Talk to an engineer
To see how these controls would sit inside your environment, book a call with an Origins AI engineer.
Written by Apoorva Kumar, Co-Founder & CEO, Origins AI.


