ADAM PULSE Knowledge Base
AI Governance · Policy · Acceptable Use

How to create a corporate AI acceptable use policy

Short answer

A usable AI acceptable-use policy is a short operating document, not a manifesto and not a certificate. It names who it applies to, which tools are approved, which data classes may never go into an unapproved tool, when a human must check the output, how agents are allowed to act, and what to do when someone has already been using a tool you did not know about.

Map prohibited data to the classification you already have. Do not invent a parallel AI taxonomy. Publish a living approved-tool list next to the policy so you can add Copilot without rewriting the PDF.

This is risk-management content. Publishing a policy does not make the organization CMMC Level 2 certified or FedRAMP authorized, and it is not EU AI Act conformity. If you handle Controlled Unclassified Information, existing contract rules still follow that data into the tool.

The twelve sections below are the ones we see missing when a first draft is just “don’t paste customer data into ChatGPT.” That sentence is true and insufficient. A sample policy block is at the end; it is a starting template, not legal advice.

Why a generic internet policy fails

People already use AI. A policy that only bans it is ignored, or it pushes the same work onto a personal phone you cannot see. NIST CSF 2.0 Govern is “strategy, expectations and policy are established, communicated and monitored.” NIST AI 600-1 puts the same idea in the AI RMF Govern function. The job of this document is to make those expectations specific enough to follow on a Tuesday.

Three failure modes we see:

The twelve sections

1. Purpose

One paragraph. Why the company is allowing AI at all (speed, quality, coverage) and what the policy is for (protect customers, IP, and the company’s ability to prove who did what). State that it is an internal control, not a certification claim.

2. Scope

Who: employees, contractors, temps, and anyone operating an AI system on the company’s behalf. What: company devices, company accounts, and work done on personal devices when the work is company work. Where: every location and remote worker. If you have a separate contractor DPA, point at it rather than duplicating it.

3. Approved AI

A named list, or a link to a living list owned by IT/security: product, account type (company SSO only), data classes allowed, whether it may act (send, write, pay), and the reviewer. “Microsoft 365 Copilot on the tenant” is a different approval from “the Copilot consumer app on a personal Microsoft account.” Put that distinction in writing. Consumer ChatGPT with a personal mailbox is not the same control as ChatGPT Enterprise with SSO, even if the model looks the same in the window.

4. Prohibited data, mapped to existing classification

Do not create “AI data classes.” Reuse Public, Internal, Confidential, and CUI if you use them. Then a table: which class may go into which approved tool, and which class may never go into an unapproved tool.

Concrete examples that stay off health records: customer lists, contracts, credentials and API keys, source code, unpublished pricing, and CUI. If you are a covered entity, your HIPAA program already owns that mapping — point at it; do not paste clinical examples into a general AI policy.

The operational sentence worth keeping: a prompt is a data transfer. File upload, meeting recording, and repo indexing are the same event. That is the argument in what AI data governance actually requires in 2026.

5. Human verification

AI may draft. A human approves anything that commits the company: customer-facing numbers, legal positions, payments, access changes, public posts. Internal brainstorming does not need a second signature. If the rule is “a human checks everything,” people will stop reading the policy. Grade by consequence, the same way Microsoft grades human-in-the-loop for agents.

6. AI-generated content labeling

Internal drafts: usually no label required, or a light “AI-assisted” in the document properties if your records process needs it. External content: say when a customer or the public is talking to a system rather than a person, unless it is already obvious.

EU AI Act Article 50 transparency obligations have applied since 2 August 2026 (European Commission FAQ; Regulation (EU) 2024/1689). They include informing people they are interacting with an AI system unless that is obvious, and marking certain synthetic content. A limited grace period to 2 December 2026 applies only to provider-side machine-readable marking for generative systems already on the market before 2 August 2026. This does not automatically bind a US company with no EU nexus. If you place systems on the Union market or your output is used there, get counsel. For everyone else, labeling customer-facing AI is still good practice and belongs in the policy so marketing does not invent a claim.

7. Agents and automated actions

Define an agent: a system that plans and calls tools, not a chatbot that only returns text. Require: a named owner, a distinct identity (not a shared mailbox), an allowlist of tools, human approval for send/write/pay/delete, logging of tool calls, and a tested way to stop it. OWASP’s AI Agent Security Cheat Sheet and Microsoft’s secure-agentic guidance are the control language; the policy only has to require them, not restate the engineering.

8. Integrations

OAuth apps, browser extensions, meeting bots, MCP servers, and “summarize my inbox” add-ins are in scope. No new integration without the same data-class review as a new tool. Standing “always allow” send on a desktop plugin is a policy violation unless a named owner has accepted that risk — the ChatGPT Apple Messages case is the worked example in ChatGPT can now read and send your Apple Messages.

9. Shadow AI definition and intake

Shadow AI is work use of an AI tool that is not on the approved list, including a personal account of an otherwise approved product. It is usually not malice. The policy should:

A blanket “we will fire you” line without an approved path produces hidden use. How to find it, and the block-versus-govern tradeoff, is What is Shadow AI and how do you find it?

10. Intellectual property

Who owns output produced on company time and systems (the company, unless a contract says otherwise). Do not paste third-party licensed code, customer deliverables, or unpublished creative work into an unapproved model. Do not publish model output as original work when the vendor terms or the use case require attribution. This is not a substitute for counsel on copyright in your jurisdiction.

11. Security

Company SSO and MFA where the product supports it. No shared AI logins. No credentials in prompts. Report suspected misuse through the existing incident process. Point at the 40-control AI security checklist for the operational list; the policy should not try to be that list.

12. Training

Who must complete it (everyone in scope, plus extra for people who operate agents). What it covers: the approved list, the paste rule, how to request a tool, and how to report Shadow AI.

EU AI Act Article 4 (AI literacy) has applied since 2 February 2025 to in-scope providers and deployers. It was not the 2 August 2026 date. Regulation (EU) 2026/1744, in force 27 July 2026, restated the duty as measures that support the development of AI literacy — not a guaranteed individual proficiency level, and not a named certificate. US employers are not automatically in scope. Training is still how you make the paste rule survive contact with a deadline.

Sample policy block

Adapt the bracketed fields. This is a starting template for an internal policy, not legal advice and not a certification.

Sample — Corporate AI Acceptable Use Policy (short form)

Purpose. [Company] permits AI tools to draft, summarize and research so people can do their jobs faster. This policy exists so customer data, company IP and CUI (if we hold it) do not leave approved channels, and so we can say who did what. It is an internal control. It is not a CMMC, FedRAMP or EU AI Act certificate.

Scope. All employees, contractors and anyone operating AI on our behalf, on company or personal devices, whenever the work is company work.

Approved tools. Only tools on the living list at [intranet URL], used with a company account and SSO. A personal account of the same product is not approved. The list names data classes allowed and whether the tool may send, write or pay.

Data. Classify as we already classify: Public, Internal, Confidential, [CUI if applicable]. Confidential, credentials, source code, customer lists, contracts and CUI do not go into unapproved tools. A prompt, upload, recording or repo index is a data transfer. Health records, if we hold them, follow the existing [HIPAA / privacy] program — not a separate AI exception.

Human verification. AI may draft. A person approves anything that commits the company or goes to a customer. Internal scratch work does not need a second signature.

Labeling. Customer-facing systems that people might think are human must say they are AI, unless that is already obvious. [If we are an EU provider or deployer: we follow Article 50 as it applies to us. If we are not, this is still our customer-facing rule.]

Agents. No agent goes live without a named owner, its own identity, an allowlist of tools, human approval for send/write/pay/delete, tool-call logging, and a stop that has been tested. A chatbot that cannot act is not an agent.

Integrations. Browser extensions, OAuth apps, meeting bots and MCP connections are tools. They need the same approval. Do not grant standing send approval.

Shadow AI. Work use of an AI tool not on the approved list, including a personal account. Report it to [intake]. First honest report is an intake, not a gotcha. We will allow, restrict or block, and we will name a sanctioned alternative when we block.

IP. Output produced for [Company] on company time or systems is [Company] property unless a contract says otherwise. Do not paste third-party licensed material into unapproved tools.

Security. No shared logins. No secrets in prompts. Report incidents through [existing IR process].

Training. Complete [course] within [N] days of hire and after material policy changes. People who operate agents complete the agent module before the agent is enabled.

Owner. [Name, title]. Review date: [quarterly].

How to roll it out without a dead PDF

  1. Inventory first. You cannot approve tools you have not found. Use department interviews plus DNS/OAuth; the Shadow AI Assessment is a private way to see which questions you cannot answer yet.
  2. Write the prohibited-data table against the classification you already use. Fight anyone who wants a new taxonomy.
  3. Stand up the living approved list before you send the all-hands. A policy with an empty list is a ban.
  4. Give people one sanctioned path for the job they were doing in Shadow AI. Block without a path recreates Shadow AI on personal phones.
  5. Put the policy in onboarding and in the same place as the existing acceptable-use policy for email and internet. One more portal that nobody bookmarks will not be read.

Frequently asked questions

Does an AI acceptable use policy certify us for CMMC or FedRAMP?

No. A policy is a control artifact, not a certificate. Publishing one does not make the organization CMMC Level 2 certified or FedRAMP authorized. If you handle CUI, existing contract obligations still follow the data into the tool.

Should the AI policy invent a new data classification scheme?

No. Map approved and prohibited AI use to the classification you already use — typically Public, Internal, Confidential, and CUI if you have it. A parallel AI taxonomy is how the policy diverges from how people already label files.

Does the EU AI Act require US companies to have an AI acceptable use policy?

The Act does not name an “acceptable use policy” as a US filing. Article 4 literacy has applied to in-scope providers and deployers since 2 February 2025. Article 50 transparency has applied since 2 August 2026. Those duties apply in the Union market, not automatically to every US employer. This article treats literacy and labeling as policy content; it does not invent a US legal obligation.

What is the difference between approved AI and Shadow AI in the policy?

Approved AI is named, owned, and allowed to receive specified data classes. Shadow AI is work use of a tool that is not on that list — including a personal account of an otherwise approved product. The policy should define both, require an intake path, and not pretend a blanket ban is the whole program.

Do employees have to disclose every use of AI?

For internal drafts, usually no — that rule gets ignored. For anything that leaves the company, commits the company, or is used as a decision, yes: a human verifies it and, where the policy requires, labels it. Make the rule specific enough to follow.

Should agents be in the same policy as chatbots?

Yes, as a separate section, because agents take actions. The policy should name which actions require human approval, that agents need their own identity, and that an untested stop is not a control.

How long should the policy be?

Short enough that a new hire will read it. The twelve sections above fit in a few pages if you keep examples concrete and point at the living approved-tool list rather than embedding the whole inventory in the policy PDF.

Where do we start if we have no policy today?

Find what is already in use, then write the prohibited-data and approved-tool sections. The Shadow AI Assessment is a private first pass; the 40-control checklist is the program this policy sits inside.

References

Where EU dates are stated, they are taken from the regulation and the Commission FAQ, not from secondary blogs. This sample policy is not legal advice.

  1. NIST AI 600-1 — Generative Artificial Intelligence Profile (July 2024)— Govern function and suggested actions for generative AI. Voluntary profile; not a certificate.
  2. NIST CSF 2.0 (NIST CSWP 29) (26 February 2024)— Govern: policy established, communicated and monitored.
  3. OWASP — AI Agent Security Cheat Sheet— human approval for high-impact actions, tool least privilege, untrusted content.
  4. Microsoft Learn — Secure autonomous agentic AI systems— deterministic human-in-the-loop; disclosure; least privilege.
  5. Regulation (EU) 2024/1689— Article 3(56) AI literacy definition; Article 4; Article 50; Article 113 dates. Article 4 applied 2 February 2025.
  6. European Commission — Article 50 FAQ— Article 50 applies from 2 August 2026; limited Article 50(2) grace to 2 December 2026 for certain generative systems already on the market.
Prepared by ADAM Pulse (USA Telecom Consulting LLC)

Managed network and communications services, SDVOSB. We will help you turn this framework into a policy and an approved-tool list that match how your people actually work — still not a CMMC or FedRAMP certificate. Start with the Shadow AI Assessment if you do not yet know what is in use. Support: (888) 989-4872 · support@adampulse.us