How to Build an AI Acceptable Use Policy That Holds Up in an Audit

An AI acceptable use policy (AUP) is a concise, enforceable rule set that tells employees what AI tools they may use, what data they can put into those tools, and how outputs must be reviewed before they go anywhere near a customer or a regulator. If you don't have one yet, the single most useful thing you can do this week is publish a minimal, enforceable version that maps data classes to tool tiers and requires human sign-off on anything high risk. A perfect policy that ships in six months protects nobody. A rough one that ships Monday does.

Skip the 40-page draft. Start with four pieces:

• Scope: which employees, contractors, and embedded AI features the policy covers
• Tool tiers: which platforms are approved, restricted, or banned outright
• Data rules: what can and cannot be typed into a prompt box
• Review requirements: when a human must check the output before it goes out the door

Quick fact: organizations in regulated industries that lack an enforced AI policy tend to generate audit findings tied to model risk management, because examiners increasingly expect AI governance to look like the model risk controls banks and insurers already run. A policy that exists only as a PDF nobody read doesn't satisfy that expectation. One that maps to a recognized framework does.

Key Takeaways

An AI acceptable use policy only functions when its data rules, tool tiers, and human review requirements are enforced through logged runtime controls, not just published as a document.

Table of Contents

• What Should an AI Acceptable Use Policy Include?
• How Do You Decide Which AI Tools Are Approved?
• What Data Is Safe to Put Into an AI Tool?
• Which AI Uses Should Be Permitted or Blocked?
• How Do You Enforce and Audit an AI Policy?
• How Should You Roll Out a New AI Policy?
• What Does a Basic AI Policy Template Look Like?
• How Marfi Turns AI Policy Into Runtime Evidence
• Why the Standard AI Policy Advice Falls Short
• Get Help Turning Policy Into Practice
• Sources

What Should an AI Acceptable Use Policy Include?

A workable AUP is built from five components, and each one needs to answer a specific question an auditor or a confused employee would ask.

1. Scope and definitions. Name who the policy covers (employees, contractors, vendors with system access) and what counts as "AI" for the purposes of the document. This matters more than it sounds. Most policies miss embedded AI features quietly rolled into tools people already use, like a CRM's auto-summarize button or a spell checker with a generative assist layer. If your definition only covers "ChatGPT and similar chatbots," you've left half your exposure uncovered.
2. Approved tools and tiered access. Separate enterprise-grade platforms with contractual data protections from free consumer tools, and be explicit about which tier applies to which task.
3. Data classification and handling rules. Tie every data class your company handles (public, internal, confidential, regulated) to a specific rule about where it can and can't go.
4. Permitted and prohibited uses. List actual examples, not abstractions. "Drafting a first pass at a job description" is permitted; "making a final hiring decision based on AI screening" is not.
5. Governance and human review. Spell out who owns the policy, who approves exceptions, and which outputs need a named person's sign-off before publication.

For the data and use-case rules specifically, the language matters because it's what an auditor reads first:

• Use verbs, not vibes: "may," "must," "may not," not "should consider."
• Attach a data class to every rule, not just a tool name.
• Require a human review step to be logged, not just performed.
• Name the policy owner by role, not by individual, so it survives turnover.

Institutional policies, like UT Austin's acceptable-use page for generative AI tools, are a good sanity check here. They tend to spell out tiering and permitted uses in language that's blunt enough for a general audience but specific enough to enforce, which is exactly the balance a corporate AUP needs.

How Do You Decide Which AI Tools Are Approved?

Most companies don't have a shadow AI problem because employees are reckless. They have one because nobody gave them a fast, legitimate way to get a new tool approved, so they use whatever's free and available. A tiered approval model fixes that without turning IT into a bottleneck.

Three tiers cover almost every real-world case:

• Tier 1, enterprise-approved: contracted platforms with data processing agreements, single sign-on, and no training on your inputs. These are cleared for most business use, including drafting client communications with human review.
• Tier 2, consumer/free-tier tools: general public chatbots without an enterprise agreement. Restrict these to non-sensitive brainstorming, public research, or personal productivity, never anything touching internal or regulated data.
• Tier 3, internal or source-grounded systems: retrieval-based tools built on your own document sets with citations and refusal behavior baked in. These are your best option for anything customer-facing, because source-grounded AI with logging and citations is the most direct technical control against hallucinated or unverifiable output.

When someone requests an unlisted tool, run it through a short checklist before saying yes: Does the vendor's data processing agreement rule out training on your inputs? Does it support SSO and centralized logging? Can it be deployed privately, or does it route data through a shared public model? A tool that fails two or more of those questions belongs in Tier 2 at best, regardless of what the sales page promises.

Pro Tip: Set a hard SLA on tool approval requests, five business days for standard requests, two for anything blocking a live project, with automatic escalation to the policy owner if that clock runs out. Slow approval processes are the number one reason employees route around the policy entirely.

What Data Is Safe to Put Into an AI Tool?

The fastest way to make an AUP usable is to give employees a decision rule they can apply in the ten seconds before they paste something into a prompt box, not a paragraph they have to interpret.

Four data tiers cover most organizations:

• Public: marketing copy, published reports, general web content. Safe for any approved tool tier.
• Internal: unpublished internal memos, non-sensitive project details. Safe for Tier 1 enterprise tools only.
• Confidential: contracts, financials, strategic plans, employee records. Requires Tier 1 tools with a data processing agreement in place, and often requires redaction first.
• Restricted/regulated: protected health information, personally identifiable information, payment card data, credentials. Blocked from general-purpose AI entirely, full stop, unless routed through a source-grounded, privately deployed system with documented access controls.

A few concrete examples make this real. A patient's diagnosis history goes nowhere near a consumer chatbot, but a de-identified, aggregated version of that same data can support an internal Tier 1 analysis. A customer's Social Security number should never appear in a prompt, even to "just format it." Login credentials, API keys, and access tokens are an automatic block regardless of destination.

Three controls reduce the risk at the point of use rather than relying on employees to remember the rules: input filters that catch obvious PII patterns before submission, anonymization tools that strip identifiers from a dataset before it's summarized, and retrieval-augmented systems that answer from an approved internal document set instead of an open model. NIST's AI Risk Management Framework treats this kind of layered control, not a single policy line, as the actual test of whether an organization is managing AI risk responsibly.

Which AI Uses Should Be Permitted or Blocked?

Policy clauses only matter once they translate into what someone does at their desk on a Tuesday. Break permitted uses down by role so the rule feels specific rather than theoretical.

Marketing teams can draft social copy, first-pass blog outlines, and ad variations with an approved tool, provided a human edits and approves before publishing. Engineering teams can use AI code assistants for boilerplate and test generation, but any AI-suggested code touching authentication, payment processing, or data access needs a human security review before merge. Legal and compliance staff can use AI to summarize case law or flag contract clauses for review, never to finalize a regulatory filing or client-facing legal opinion without an attorney's sign-off.

Prohibited uses need the same specificity:

1. Never paste PHI, PII, or credentials into a consumer-grade AI tool.
2. Never let AI output finalize a regulated disclosure, financial statement, or compliance filing without named human review.
3. Never use AI as the sole basis for a hiring, firing, or promotion decision.
4. Never connect an AI agent to production systems without a documented approval and a logged audit trail.

Edge cases deserve their own line item because they're where policies quietly fail. Agentic tools that take autonomous action, IDE plugins with codebase-wide access, and third-party integrations buried inside existing software all count as "AI use" under the policy, even when nobody typed a prompt. Guidance from UT Austin's provost office on responsible AI adoption treats these embedded and agentic cases explicitly, which is worth mirroring, because "we didn't think of it as AI" is not a defense an auditor accepts.

How Do You Enforce and Audit an AI Policy?

A policy without enforcement is a wish list. Build enforcement in four escalating steps so the response always matches the risk.

1. Allow. Standard use within an approved tier, no friction, but still logged.
2. Warn. A user attempts a borderline action (pasting something that looks like PII into a Tier 1 tool); the system flags it and asks for confirmation.
3. Block. A clear policy violation (regulated data heading into an unapproved tool) gets stopped automatically, no exceptions.
4. Route. High-risk requests, like anything touching a regulatory filing, get automatically routed to a named human reviewer instead of completing.

Audit evidence needs to exist before an examiner asks for it, not after. Capture what tool was used, what data class was involved, who approved the output, and when, and retain those logs for at least as long as your industry's document retention rules require. Financial services templates commonly recommend naming an accountable executive owner and reviewing the policy at least annually, which is a reasonable floor even outside finance.

When something does go wrong, the escalation path should be as clear as an incident response plan, because that's effectively what it is: the employee or system flags it, a designated reviewer triages within a set window, and anything involving regulated data or a client-facing error hands off to compliance and incident response immediately.

Pro Tip: Put the AUP review date on the same calendar as your incident response plan review. AI capabilities move fast enough that a policy written 12 months ago probably has a gap; reviewing it alongside IR keeps both current and gives you one less recurring meeting to schedule.

How Should You Roll Out a New AI Policy?

Publishing a policy and rolling one out are different jobs, and the gap between them is where most AI governance actually fails. The most common failure mode isn't a bad clause, it's a good policy that nobody read because it lived in a shared drive nobody opens.

1. Publish the policy somewhere employees already look, not a new location they'll forget.
2. Announce it through a real communication, not a footer link in a company newsletter.
3. Run role-based training so marketing hears about content review while engineering hears about code review.
4. Hand out a one-page quick-reference card mapping data tiers to tool tiers, taped next to the policy document, not buried inside it.

Keep the policy alive with short reinforcement, not annual re-reads: a microlearning nudge when someone opens a new AI tool, an embedded prompt reminder inside the tool itself, and a five-minute mention in regular manager briefings.

Track three numbers from day one: adoption (how many employees have acknowledged the policy), incidents (how many warn/block events happen monthly), and approval turnaround (whether your SLA is holding). Fast exception intake matters more than people expect. If a legitimate request sits for two weeks, someone will just use the unapproved tool anyway.

What Does a Basic AI Policy Template Look Like?

A workable skeleton fits in one paragraph plus a checklist. Here's the paragraph structure: name the scope (employees, contractors, embedded AI features), name an accountable owner by role, define your tool tiers, state your data handling rules by classification, and specify the enforcement model (allow, warn, block, route) with named consequences for violations.

The reviewer checklist for any new tool or high-risk use case should ask:

• Does this tool have a signed data processing agreement ruling out training on inputs?
• What data classification is this use case touching, and is that tier permitted for this tool?
• Does the output require human sign-off before it's used externally, and who is that person?
• Is there a logging mechanism capturing this use for audit purposes?
• If this is an exception request, what's the expiration date on the exception?

For sign-off language, keep it specific: "This output was reviewed by [name/role] on [date] and approved for external use," logged in whatever system you already use for approvals. Vague sign-off ("reviewed by the team") doesn't survive an audit request. Practical templates built for 2026 policy drafting offer more complete starting language if you want a fuller first draft to edit down.

How Marfi Turns AI Policy Into Runtime Evidence

A written policy is a promise. An auditor wants proof the promise is kept, and that's the gap most AI governance programs never close. Marfi builds that bridge by mapping each policy component, tool tiers, data rules, human review requirements, directly into the compliance operations and continuous monitoring it already runs for regulated clients.

That looks like:

• Managed compliance tied to frameworks you're already accountable to, including SOC 2, CMMC, and NIST-aligned readiness, so your AUP isn't a standalone document but one control among many that auditors can trace.
• A 24/7 security operations center that can enforce the allow/warn/block/route model in practice, not just on paper, catching a restricted-data violation as it happens instead of during next quarter's review.
• Secure AI governance and workflow automation that builds human review checkpoints directly into the tools people use daily, so sign-off is a logged step, not an honor system.

The outcome leaders actually need from this isn't a nicer document. It's evidence: logs an examiner can review, a review cadence that's actually followed, and a chain of custody from policy clause to enforced control.

A policy that only exists on paper generates zero audit evidence. A policy enforced through logged, tiered runtime controls generates exactly the evidence a NIST AI RMF-aligned examiner is trained to look for.

Pro Tip: If your compliance team can't produce a log showing who approved a specific AI output within five minutes of being asked, your enforcement model exists in theory, not in practice.

Why the Standard AI Policy Advice Falls Short

Most guidance on building an AI acceptable use policy treats the document as the finish line. Write the policy, get legal sign-off, publish it, done. That's backwards, and it's why so many companies end up with a policy that reads well and enforces nothing.

The judgment this article's research actually supports is blunter: an AUP is only as good as its runtime controls. A decision matrix that lives in a PDF protects nobody the moment an employee opens a new tab and starts a free chatbot session. What actually holds up under audit is a policy that's been translated into logged, automated checkpoints, tiered approvals, blocked data paths, mandatory sign-off gates, because that's the only version that produces evidence instead of intentions.

Where conventional advice falls shortest is on maintenance. Plenty of guides describe what a good AUP contains. Very few address what happens when a new AI feature ships inside a tool you already use, or when an employee's workaround becomes the unofficial process because the approved path was too slow. That's not a policy problem. That's a change management problem, and it needs the same discipline you'd apply to a production system change: version control, a review trigger tied to major AI capability shifts, and an owner who's actually measured on whether the policy is followed, not just whether it exists.

If you take one thing from this, prioritize the enforcement layer before you polish the prose. A rough policy with real logging beats a beautiful one with none.

— Danny

Get Help Turning Policy Into Practice

Writing the policy is the easy part. Marfi exists for the harder part: making sure what you wrote actually governs what happens inside your systems every day. For regulated companies juggling SOC 2, HIPAA, CMMC, or NIST obligations alongside a growing list of AI tools employees want to use, Marfi replaces the usual patchwork of point solutions with one accountable team overseeing the whole stack, IT, cybersecurity, compliance, and secure AI operations together.

That matters most in the gap this article kept circling back to: the space between a written AUP and one you can actually prove is enforced. Marfi's secure AI governance and workflow automation service builds the tiered approvals, data handling rules, and human review checkpoints directly into daily operations, backed by a 24/7 security operations center and SOC 2 Type II verified processes. If your policy exists but your evidence doesn't, that's the fastest problem to fix. Talk to Marfi about your AI governance setup and find out what's already covered and what's still a gap.

Sources

• NIST AI Risk Management Framework
• Acceptable Use of Generative AI Tools — UT Austin
• AI Acceptable Use Policy: A Complete Template and Guide for 2026 — Sekurely
• Customgpt

Recommended

• FedRAMP Readiness & Continuous Operations | MARFI
• Managed Compliance & Continuous GRC Services | MARFI
• CMMC, DFARS & NIST SP 800-171 Readiness | MARFI