AI Acceptable Use Policy Template
An AI acceptable use policy is the written rule set that defines which artificial intelligence tools your employees may use, what company data may be entered into them, and who approves a new tool before it touches your systems. Every organization already has an AI policy. The only question is whether leadership wrote it, or whether each employee wrote their own version privately, in whatever free chatbot they found last week.
Serving Raleigh, Durham & the Triangle / Since 2002 / CyberAB RPO #1449 / BBB A+ Since 2003
Key Takeaways
- An AI acceptable use policy is a governance control, not an HR memo. Auditors under ISO/IEC 42001 and assessors applying the NIST AI Risk Management Framework look for a documented, approved, and communicated policy as evidence that AI use is managed rather than tolerated.
- The data classification clause is the highest-risk paragraph in the document. It is the sentence that decides whether an employee may paste a patient record, a contract, or Controlled Unclassified Information into a public model. Most templates leave it vague.
- Shadow AI is the default state, not the exception. Employees adopt AI tools faster than any approval process moves, so a policy that only says no becomes a policy that is only ignored. Workable policies pair prohibitions with an approved-tool path.
- A downloadable AI policy template is a starting structure, never a finished policy. A template cannot know your data classification scheme, your regulated obligations, your approved tool list, or which of your systems already send data to a model.
- Your AI policy must inherit from obligations you already carry. A defense contractor under CMMC, a medical practice under HIPAA, and a SaaS company pursuing SOC 2 each need a materially different document, because each one already restricts where data may travel.
What Is an AI Acceptable Use Policy?
A short definition, then the reason the document exists at all.
An AI acceptable use policy, sometimes called an AI usage policy or corporate AI policy, is a formal internal document that governs how members of an organization may use artificial intelligence systems in the course of their work. It answers four questions in writing: which AI tools are approved, what categories of company and customer data may be entered into them, what outputs may be relied upon or published, and who reviews and approves a new tool before anyone uses it.
That is the definition. The reason the document exists is more specific, and it is worth being blunt about it. When an employee pastes text into a public chatbot, that text leaves your control. Depending on the vendor and the plan, it may be retained, reviewed by human annotators, or used to train a future model. Nothing about that transaction is visible on your network as a security event. There is no file transfer to block, no attachment to scan, and no obvious alert. It looks exactly like ordinary web browsing.
This is why AI use became a governance problem rather than a technical one. The traditional controls that Petronella Technology Group deploys for clients, including endpoint detection, email security, and data loss prevention, were built around files and messages moving between systems. A person retyping a paragraph of a contract into a browser tab defeats most of that architecture by design. The control that works is a written rule, communicated and acknowledged, backed by an approved tool that is safe to use, so that the compliant path is also the convenient one.
Organizations reach for an AI policy at one of three moments. The first is discovery, when someone notices that a department has been running client work through a consumer tool for months. The second is a contract, when a customer, insurer, or prime contractor sends a questionnaire asking whether the organization has a documented AI governance policy. The third is an audit, when an assessor asks the same question with consequences attached. The first moment is the cheapest one to act on.
The Twelve Sections Every AI Policy Needs
Most sample AI policies circulating online contain four or five of these. The gaps are where the risk sits.
1. Purpose and Scope
States what the policy governs and who it binds. Scope must explicitly name contractors, temporary staff, and third-party developers, because these are the people most likely to bring an unapproved tool with them.
→2. Definitions
Defines generative AI, agentic AI, embedded AI features, and the difference between a public model and a private deployment. Without definitions, a staff member will argue that the transcription feature inside a meeting tool was never covered.
→3. Approved Tool List
Names the specific tools sanctioned for use, at which subscription tier, and for which departments. Tier matters enormously, because consumer and enterprise plans of the same product often carry opposite data retention terms.
→4. Data Classification Rules
The core clause. Maps each data class in your organization to a permitted destination. Public marketing copy, internal documents, customer records, regulated data, and Controlled Unclassified Information each need a distinct answer.
→5. Prohibited Uses
Enumerates uses that are never permitted regardless of tool, such as generating code that will run in production without review, making employment decisions, or producing content that impersonates a real person.
→6. Human Review Requirements
Defines where a person must verify AI output before it is relied upon. Legal filings, medical guidance, financial figures, security configurations, and anything sent to a customer belong in this list.
→7. Tool Approval Process
The intake path for requesting a new AI tool, including who evaluates it, what the review covers, and the expected turnaround. A process with no stated turnaround is a process employees will route around.
→8. Vendor and Model Requirements
Sets the bar a vendor must clear: contractual commitment not to train on your data, defined retention periods, regional data residency where required, and a security posture your team has actually reviewed.
→9. Disclosure and Attribution
Says when AI involvement must be disclosed, to customers, in deliverables, in published content, and in code contributions. Increasingly this appears as a contractual requirement flowing down from clients.
→10. Intellectual Property Terms
Addresses ownership of AI-assisted work product and the risk of generated code or text carrying licensing obligations. This clause protects the organization in both directions.
→11. Monitoring and Enforcement
Describes how compliance is observed and what happens when the policy is broken. A policy with no stated consequence is guidance, and guidance does not satisfy an auditor asking for a control.
→12. Review Cadence and Ownership
Names an accountable owner and a review interval. The AI tool landscape shifts faster than any other category of business software, so an annual review is the outer limit of usefulness.
→Approved Use vs Prohibited Use
The practical shape of a data classification clause that employees can actually follow.
Generally Approved
- Drafting and editing public-facing marketing copy that contains no customer identifiers
- Summarizing published research, vendor documentation, and other already-public material
- Brainstorming, outlining, and rewriting text the employee authored and that contains no confidential facts
- Explaining a general technical concept, or generating sample code that will be reviewed before use
- Any of the above within an approved private deployment, where data does not leave your environment
Prohibited in Public Models
- Protected health information, including anything that identifies a patient or an encounter
- Controlled Unclassified Information and any material covered by a DFARS clause
- Customer records, contracts, and anything received under a confidentiality obligation
- Credentials, API keys, network diagrams, security configurations, and audit findings
- Source code that constitutes a trade secret or that carries a restrictive license
- Employee personal data, compensation figures, and investigation or disciplinary material
Notice the phrasing of the second column. The prohibition is against putting these categories into a public model, not against using AI on that data at all. That distinction is what makes a policy survivable. A blanket ban on AI for regulated data tells a clinician or a defense engineer that the tool everyone else in their industry is using is off limits to them permanently, and the predictable result is quiet non-compliance.
The alternative is to give the restricted data a compliant destination. A private AI deployment, running on hardware you control, keeps the data inside your boundary and turns the policy question from whether AI may be used into which system it may be used on. Petronella Technology Group builds these environments through private AI solutions and on-premise AI deployment, and for healthcare clients specifically through HIPAA-compliant AI. When that path exists, the acceptable use policy can be strict about public tools without being unrealistic about the work.
Shadow AI Is Why the Policy Exists
Unsanctioned AI use is not a hypothetical risk, and it is not primarily a discipline problem.
Shadow AI describes AI tools used inside an organization without review or approval. It is the AI-era descendant of shadow IT, but it spreads considerably faster for three reasons. The tools are free, so no purchase order creates a paper trail. They run in a browser, so no software installation triggers an endpoint alert. And they make people visibly better at their jobs within minutes, so adoption is driven by genuine enthusiasm rather than negligence.
That last point deserves emphasis, because it changes what a correct response looks like. The employee pasting a client email into a chatbot to draft a reply is usually not being careless about security. They are being conscientious about turnaround time. They have no way to evaluate a vendor's data retention terms, and nobody has ever told them the question matters. Treating this as a disciplinary matter misdiagnoses it. The organization failed to provide either a rule or a safe alternative, and the employee filled the vacuum.
Embedded AI complicates the picture further. Features are now shipping inside software your organization already licensed: transcription in meeting platforms, summarization in email clients, assistants in customer relationship and document management systems. These arrive by vendor update, not by a decision anyone made. An AI acceptable use policy that only contemplates employees visiting chatbot websites misses an entire category of exposure that entered through the front door with a release note.
The discovery work therefore matters as much as the drafting work. Before Petronella Technology Group writes a policy, the engagement inventories what is actually in use: browser-based tools reaching AI vendor domains, AI features enabled inside existing subscriptions, developer tooling with model integrations, and any application quietly sending data to a model API. A policy written without that inventory prohibits tools nobody uses while omitting the ones that carry real data.
Classify Before You Prohibit
A policy can only restrict data categories your organization has actually named. These are the classes most engagements end up defining.
Organizations that already carry a compliance obligation usually have some of this scheme defined, which makes the AI policy faster to write and more defensible once written. A defense contractor has already identified where Controlled Unclassified Information lives in order to build a system security plan. A medical practice has already mapped protected health information for its HIPAA risk analysis. In those cases the AI policy inherits an existing map rather than inventing one, and the resulting rules line up with controls the organization is already assessed against.
Organizations without that groundwork should expect classification to be the longest part of the project. That is not wasted effort. A data classification scheme is a prerequisite for nearly every compliance framework, so the work performed to support an AI policy pays down obligations under CMMC, HIPAA, and SOC 2 at the same time.
Which Standard Is Your Policy Answering To?
An AI acceptable use policy is evidence for several different regimes at once. Knowing which one you are writing for determines the level of formality required.
NIST AI Risk Management Framework
The voluntary United States framework organized around Govern, Map, Measure, and Manage. An acceptable use policy is a core artifact of the Govern function, which asks whether policies and procedures for AI risk exist, are documented, and are communicated across the organization.
AI governance framework →ISO/IEC 42001
The certifiable management system standard for artificial intelligence. It expects a documented AI policy approved by leadership, defined roles, and evidence of ongoing review. This is the regime in which a policy is formally audited rather than merely recommended.
ISO 42001 certification →CMMC and NIST SP 800-171
No AI-specific control exists yet, and none is needed to create the obligation. Controlled Unclassified Information entering a public model is a disclosure to an unauthorized system, assessed under existing access control and media protection requirements.
CMMC compliance guide →HIPAA
Sending protected health information to a vendor without a business associate agreement is a disclosure under the Privacy Rule. Because most consumer AI vendors will not sign one, the practical answer for clinical data is a private deployment rather than a public tool.
HIPAA compliance →There is a fifth audience that matters commercially even though it is not a standard: your customers. Security questionnaires and vendor risk reviews now routinely ask whether the respondent maintains a documented AI usage policy, whether employees are trained on it, and whether AI is used in delivering the service being purchased. Organizations that answer yes with an attached document move through procurement faster than those that answer with a paragraph of reassurance.
Six Ways AI Policies Fail
Patterns seen repeatedly in policies written from a downloaded sample.
It bans AI outright
A prohibition with no approved alternative does not stop AI use, it stops AI use from being visible. Staff continue on personal devices and personal accounts, which removes even the logging and enterprise terms that a sanctioned tool would have provided. The organization ends up with more exposure and less evidence.
It names no specific tools
A policy referring only to generative AI tools in the abstract leaves every practical question unanswered. Employees cannot tell whether the assistant built into the software they use all day is covered, and managers cannot enforce a rule that identifies nothing.
It ignores the subscription tier
The same vendor product can carry entirely different data handling terms across consumer, team, and enterprise plans. A policy that approves a product by name, without specifying the tier and the account it must be used under, approves the version with the weakest protections by omission.
It is never communicated
A document that lives in a shared folder is not a control. Assessors ask for evidence of distribution, acknowledgement, and training. Without that record, the organization has written the policy without having implemented it, which is a distinction auditors are practiced at drawing.
It contradicts existing policy
Where the AI policy permits something the data handling, remote work, or third-party risk policy forbids, the conflict surfaces at the worst possible moment. The AI policy has to be reconciled against the documents already in force, not written alongside them.
It is never revised
An AI policy approved eighteen months ago predates the model versions, agentic features, and embedded assistants your organization now uses daily. Stale policies are worse than absent ones, because they create documented expectations that current practice openly violates.
How Petronella Builds Your AI Policy
The sequence used on client engagements, built around discovery first and drafting last.
Discover actual AI use
Inventory the AI tools genuinely in use across the organization, including browser-based services, AI features already enabled inside licensed software, developer tooling with model integrations, and any application sending data to a model API. This step regularly surprises leadership, and it is what keeps the policy grounded in reality.
Map data classes and obligations
Identify the categories of data your organization holds and the regulatory or contractual constraints already attached to each. For regulated clients this reuses work already performed for CMMC, HIPAA, SOC 2, or PCI DSS rather than duplicating it.
Define the approved tool path
Decide which tools are sanctioned, at which tier, under which accounts, and for which roles. Where a business need involves regulated data, specify the private or on-premise deployment that gives the requirement a compliant home instead of a flat refusal.
Draft against a framework
Write the policy so that its clauses map to the NIST AI Risk Management Framework, and to ISO/IEC 42001 where certification is the goal. Drafting against a framework from the start means the document doubles as audit evidence rather than needing to be rewritten for one later.
Reconcile with existing policy
Review the new policy against acceptable use, data handling, remote work, and third-party risk documents already in force, and resolve every conflict before approval. This is the step most commonly skipped and the one most likely to produce an audit finding.
Roll out, train, and schedule review
Distribute the approved policy, capture acknowledgements, deliver role-appropriate training so staff understand the reasoning rather than only the rules, and set a named owner with a review interval. Training material can be folded into existing security awareness training so it reaches people through a channel they already expect.
Free Template vs Generic Consultant vs Petronella
What each route delivers, and where each one structurally falls short.
| Capability | Petronella Technology Group | Free Downloadable Template | Generic Compliance Consultant |
|---|---|---|---|
| Discovery of AI already in use | Inventoried before drafting begins | Not possible, no view of your environment | Varies, often a self-reported questionnaire |
| Data classification tied to your systems | Mapped to where your data actually lives | Generic placeholders you must fill in | Usually inherited from a prior client |
| Compliant destination for regulated data | Private and on-premise AI built in house | Out of scope entirely | Advises a prohibition, cannot deliver an alternative |
| Alignment to NIST AI RMF and ISO 42001 | Drafted against the framework from the start | Sometimes claimed, rarely mapped clause by clause | Depends heavily on the individual consultant |
| Reconciliation with existing policies | Conflicts resolved before approval | No knowledge of your other documents | Offered as a separate engagement |
| Regulated-industry experience | CyberAB RPO #1449, CMMC-RP team, HIPAA practice since 2015 | None | Varies by firm |
| Rollout, training, and acknowledgement | Included, with awareness training delivery | Left entirely to you | Often billed separately |
| Keeping the policy current | ComplianceArmor maintains it as living documentation | Static file, stale within months | Requires a new engagement each cycle |
Free AI policy templates are genuinely useful for one purpose: showing a leadership team the shape of the document so they can decide to fund the real one. They fail as finished policies because every clause that carries risk is precisely the clause a template must leave blank. The template cannot know your data classes, your approved tools, your regulated obligations, or which AI features are already running inside software you licensed last year.
ComplianceArmor Keeps the Policy From Going Stale
The failure mode after approval is not a bad policy. It is a correct policy that quietly stops describing reality.
Petronella Technology Group built ComplianceArmor because compliance documentation decays predictably. A policy is accurate on the day it is approved and drifts from that day forward as tools change, staff turn over, and vendors ship features nobody requested. AI policy decays faster than any other category, because the underlying products change on a timescale of weeks.
Treating the AI acceptable use policy as living documentation means the approved tool list, the data classification mapping, and the acknowledgement records stay attached to the policy rather than scattered across a shared drive. When a customer questionnaire asks for the current document, or an ISO/IEC 42001 auditor asks for evidence of review, the answer is retrievable rather than reconstructed. The same platform maintains the CMMC, HIPAA, SOC 2, and PCI DSS documentation many of our clients carry alongside it, which is what keeps the AI policy consistent with the rest of the program instead of contradicting it.
Verified Client Feedback
"Craig and his team treat your business like it's their own. That level of care and dedication is rare, and it's why we keep coming back."
Milo Rivera, TrustIndex verified review
Rated 4.7 across 92 verified TrustIndex reviews.
Why Petronella Writes These Policies
AI policy work sits at the intersection of two practices most firms keep separate.
Petronella Technology Group has operated from Raleigh, North Carolina since April 2002 and has held a BBB A+ rating since 2003. The compliance practice is a CyberAB Registered Provider Organization, RPO #1449, with a CMMC Registered Practitioner certified team serving defense contractors across the Triangle and nationwide. The healthcare practice has run HIPAA security work since 2015. That regulated-industry background is what makes an AI policy enforceable rather than aspirational, because the constraints on your data are already understood before the AI question is asked.
The AI practice is not theoretical either. The firm launched its AI division in 2023 and runs production AI agents in its own operations, alongside client work in custom AI development, AI automation services, and AI agent development. Writing a rule about where model data travels is considerably easier when your team has deployed the models.
Craig Petronella, author of Beautifully Inefficient and an MIT AI-certified technologist, founded the firm and leads its AI and compliance work. He is a CMMC Registered Practitioner, an NC Licensed Digital Forensics Examiner, license number 604180-DFE, and a cybersecurity expert witness who has been featured on NBC, ABC, CBS, FOX, and WRAL. He has published 15 books on cybersecurity and compliance and hosts the Encrypted Ambition podcast, where AI governance and security are recurring subjects. His complete catalog is available on the books page.
Organizations across Raleigh, Durham, Cary, Chapel Hill, Apex, and the wider Research Triangle work with the firm on AI governance, with nationwide delivery for clients outside North Carolina. For AI strategy work beyond the policy itself, see AI governance consulting and AI consulting in Raleigh. For the security side of AI deployment, see enterprise AI security and AI cybersecurity solutions. The full practice is described on the AI services page, and the broader security program on cyber security.
AI Acceptable Use Policy Questions
What is an AI acceptable use policy?
An AI acceptable use policy is a formal internal document that defines which artificial intelligence tools employees may use, what categories of company and customer data may be entered into them, what outputs require human review before being relied upon, and who approves a new AI tool before it is used. It functions as a governance control, providing evidence under the NIST AI Risk Management Framework and ISO/IEC 42001 that AI use is managed rather than merely tolerated.
Can I just download a free AI policy template?
A template is a useful starting structure but not a finished policy. Every clause that carries real risk is the clause a template must leave blank: your data classification scheme, your approved tool list and subscription tiers, your regulated obligations, and the AI features already running inside software you license. Organizations that adopt a template without completing that work typically have a document that neither guides employees nor satisfies an auditor.
What should an AI policy prohibit?
At minimum, entering protected health information, Controlled Unclassified Information, customer records received under confidentiality obligations, credentials and API keys, security configurations, proprietary source code, and employee personal data into public AI models. The prohibition should be scoped to public tools rather than to AI in general, with an approved private deployment provided as the compliant alternative for regulated data.
Does CMMC require an AI acceptable use policy?
CMMC does not currently contain an AI-specific control, and none is needed to create the obligation. Controlled Unclassified Information entering a public AI model constitutes a disclosure to an unauthorized system, which is assessed under existing access control and media protection requirements in NIST SP 800-171. Defense contractors should treat AI use as in scope for their existing assessment regardless of whether a dedicated control appears.
Is it a HIPAA violation to use ChatGPT with patient data?
Sending protected health information to a vendor without a business associate agreement in place is a disclosure under the HIPAA Privacy Rule. Most consumer-tier AI services will not execute a business associate agreement, which makes that path unavailable to covered entities. The practical answer for clinical workflows is a private or HIPAA-eligible deployment where the data stays within a boundary covered by an appropriate agreement.
What is shadow AI?
Shadow AI is the use of artificial intelligence tools inside an organization without review or approval. It spreads faster than traditional shadow IT because the tools are free, run entirely in a browser without triggering an installation alert, and deliver visible productivity gains within minutes. It also arrives through vendor updates, as AI features appear inside software the organization already licensed.
How often should an AI policy be reviewed?
An annual review is the outer limit of usefulness, and most organizations benefit from a shorter cycle. The AI product landscape changes on a timescale of weeks, so a policy approved eighteen months ago will predate the model versions, agentic capabilities, and embedded assistants staff now use daily. The policy should name an accountable owner and a stated review interval, and treating it as living documentation is what keeps it from drifting.
Who should own the AI acceptable use policy?
Ownership belongs to whoever already owns information security or compliance policy, so the AI policy is reconciled against existing documents rather than written alongside them. In smaller organizations without that role, a virtual chief information security officer arrangement provides the accountable owner an auditor expects to see named. What matters is that a specific person is identified, not a committee or a department.
Write the Policy Before You Need the Evidence
Petronella Technology Group discovers the AI already in use across your organization, maps it against the obligations you carry, and delivers an acceptable use policy your team can follow and your auditor can accept. Call 919-348-4912 or request a consultation.
Petronella Technology Group, Inc. / 5540 Centerview Dr., Suite 200, Raleigh, NC 27606 / 919-348-4912
Last Updated: August 3, 2026