Acceptable Use Policy for AI Email Drafting: A Clause-by-Clause Outline

An acceptable use policy for AI email is the document your employees actually read and sign — not the fifty-page governance framework legal keeps in a shared drive. The governance policy tells the company how it will oversee AI. The acceptable use policy tells one person, at their desk, at 4:47 on a Tuesday, whether they can paste this specific customer message into this specific tool to draft this specific reply.

If the answer to that question is not on one page in language a new hire understands, you do not have an acceptable use policy. You have a wish. Below is the clause-by-clause outline of what belongs on that page, why each clause is there, how to score a draft against the shape auditors expect, and where most policies quietly fail.

The short answer: six clauses, one page#

A working acceptable use policy for AI email drafting names six things. Anything shorter leaves employees guessing; anything longer stops being read. The six are: which tools are approved, which data classes are prohibited from ever entering a prompt, when a human must review a draft before it sends, when a recipient must be told AI helped, how to report a mistake, and what happens when the policy is broken.

These are not arbitrary. They map to the four questions any auditor — internal, external, or a regulator under the EU AI Act's transparency rules — will ask about your AI use: what tool, what data, who checked it, who was told. Cover the four questions in language a marketing hire can act on without calling legal, and you have a policy. Leave any of them abstract and you have a document that gets ignored the first time it gets in the way of a deadline.

The clauses that actually matter#

Every clause below solves a specific failure mode we have seen in real incidents. Skip a clause and you are not being lean — you are choosing which incident you will have.

1. Approved tools#

Name the tools by name. "AI email assistants" is not a list. If ChatGPT, Microsoft 365 Copilot, Google Gemini in Workspace, and one email-native client are on the approved list, write those names down. Everything else is unapproved by default — no exceptions, no "just this once."

For each named tool, state the plan and the data-processing posture that made it approvable: enterprise tenant with no-training-on-prompts contractual terms, workspace-provisioned account, SSO required. A personal ChatGPT account and an enterprise ChatGPT tenant are different tools for policy purposes, even though the interface looks identical. Say so explicitly, because employees will not infer it.

2. Prohibited data classes#

This is the clause that keeps you out of court. List the categories of information that must never appear in an AI prompt, in an attached file, or in a copy-pasted email body. Concrete categories, not "sensitive data." Every employee has a different theory of what sensitive means; a list is the only version that survives.

At minimum the prohibited list should cover: full payment card numbers, government identifiers (SSN, national ID, passport), banking credentials and account numbers, protected health information under HIPAA or your local equivalent, personnel-file contents (compensation, performance reviews, disciplinary records), attorney-client privileged material, unreleased financial results, source code marked confidential, and any customer data covered by a contract that names AI subprocessors as a restricted class.

Then name the two categories employees actually stumble on, which most policies miss: (1) inbound customer emails that contain any of the above — you did not put the SSN into the tool, the customer did, but pasting the message into a drafting prompt is the same act — and (2) internal threads discussing customers by name where the customer has not consented to AI processing. Say both out loud.

3. Mandatory human review before send#

Every AI-drafted email that goes to a person outside the company must be read by a human before it sends. Not skimmed. Read. The clause should say so in one sentence and then define what "reviewed" means: the sender confirms the facts are correct, the tone matches the relationship, and no prohibited data has been echoed back into the reply.

For internal email, the review requirement can be lighter — a glance is often enough — but the policy still needs to say that. "Use judgement" is not a policy; it is a shrug. If your organisation runs any form of AI autopilot or scheduled auto-send, this clause is where you carve out the narrow, named categories where automated send is permitted (routine acknowledgements, calendar confirmations, out-of-office replies) and make it explicit that everything else pauses for a human. NIST's AI Risk Management Framework treats this human-in-the-loop control as the primary mitigation for generative-AI drafting risk, and it is the one control that costs nothing to implement.

4. Disclosure to recipients#

Say when AI must be disclosed and when it must not. The EU AI Act's Article 50 transparency rules require disclosure for AI-generated content in specific contexts; many jurisdictions are heading the same direction, and enterprise customers increasingly ask about it in security reviews. A policy that stays silent forces every individual to decide, which means the answer will be inconsistent and, in some jurisdictions, non-compliant.

A workable rule looks like this: substantive first-touch outreach that was AI-drafted gets a disclosure line, either in the email itself or in a hover-explainable signature. Ongoing conversations with an established contact do not. Legal advice, medical advice, financial recommendations, and hiring decisions never get an AI-only draft, disclosed or not — they get a human-written draft, full stop. Write those three tiers into the clause with named examples from your own business, or employees will pattern-match to the tier that saves them the most typing.

5. Incident reporting#

Someone will paste something they should not have. The question is whether you find out in an hour or in a subpoena. Name the reporting channel — a specific Slack channel, a specific email address, a named security contact — and promise, in the policy itself, that a self-reported incident within 24 hours is treated as good-faith remediation, not misconduct.

Then say what the reporter has to include: which tool, which prompt (or a description if the exact text is gone), which recipient if the draft was sent, and whether prohibited data was involved. Without those four facts you cannot triage, and without the good-faith clause you will not hear about the incidents you most need to hear about.

6. Enforcement#

The consequences clause is the one most policies soften into meaninglessness. "Violations may result in disciplinary action" tells no one anything. State the tiers: a first accidental infraction triggers a documented conversation and refresher training; repeated or wilful infractions escalate through your existing HR framework; use of a prohibited tool with prohibited data is a terminable offence on first occurrence. Name the owner (usually the head of security or the CISO) who signs off on each tier.

This clause is unpleasant to write and that is exactly why it belongs. A policy without teeth is training material; a policy with teeth is a policy. ISO/IEC 42001 explicitly requires that AI management systems document how nonconformity is handled — and auditors will look for the specific words.

Scoring table: clause, risk, enforcement#

Use the table below as a review pass on any draft AUP. If a clause in your document cannot fill all three columns concretely, the clause is not done — it is aspirational text that will not survive its first test.

Worked example: what a good clause reads like#

Abstract advice is easy to nod at and impossible to enforce. Below is what a Prohibited Data clause looks like when it is written to be acted on rather than admired. Adapt the categories to your regulatory footprint, keep the shape.

Notice what the example does. Every bullet is a category a non-lawyer can recognise in ten seconds. The final line names a channel and gives permission to interrupt someone, which is the single hardest cultural thing to write into a policy and the reason most policies fail quietly.

The equivalent clause on human review reads the same way: "Before you send an AI-drafted email to anyone outside the company, read it aloud to yourself. Confirm the three specific facts you are asserting are correct. Delete any sentence you would not defend in a deposition. Then send." That is a policy. "Users should exercise appropriate oversight of AI-generated content" is not.

Red flags: signs your policy is not going to work#

If your draft AUP has any of these characteristics, it will not survive contact with a real deadline. Fix them before circulating for signature.

• It is longer than two pages. Employees do not read past two pages of policy; if the AUP is a subsection of a fifteen-page governance document, publish the AUP as a standalone one-pager and reference the governance doc as the source.
• It uses the passive voice throughout. "Data should not be shared" leaves the actor unspecified; "Do not paste customer PII into any tool not on the approved list" tells one person what to do.
• It has no named owner. Every clause should be traceable to a role — CISO for enforcement, DPO for prohibited data, IT for approved tools — and the document itself should have one person who owns the next revision.

• It does not distinguish consumer accounts from enterprise tenants of the same product. This is the single most common gap and the single most expensive incident.
• It bans everything or permits everything. A blanket ban drives use underground; a blanket permission removes any ability to say no. The workable shape is a short allowlist, a clear prohibition list, and a documented request path for anything else.
• It has no disclosure guidance. Under the EU AI Act and rising customer expectations elsewhere, silence on disclosure is a position — and increasingly the wrong one.
• It confuses approval-before-send with autopilot bans. Approval-before-send is the safe default that lets employees benefit from AI drafting without sending unreviewed content. Banning autopilot outright without explaining the difference tells people the tool is dangerous when the real risk is the workflow, not the tool.

What we would pick, and why (honest)#

Any AUP is only as strong as the tool that has to enforce it. If your policy requires approve-before-send, a full audit trail of every send, undo on mistakes, and a hard line between drafts and dispatched messages, the tool has to make those the default rather than options a busy user turns off. We build AI Emaily, and it is designed around exactly that split — Manual, Copilot, and Autopilot modes with the approval step in the middle, plus a per-send audit log and one-tap undo. That maps cleanly onto the review, incident-reporting, and enforcement clauses above, on Gmail, Outlook, and any IMAP account.

For a team writing an AUP from scratch, the honest recommendation is: name AI Emaily as the approved email-native drafting tool, keep your existing enterprise ChatGPT or Copilot tenant on the approved list for general drafting, and prohibit everything else by default. Employees write email in an email client; letting them draft where they already work removes the copy-paste step that is where most of the prohibited-data incidents happen.

Where AI Emaily is not the right fit: if your compliance regime requires enforcement at the Microsoft 365 tenant level — Purview DLP scanning every prompt, Sensitivity Labels flowing into the drafting tool, Insider Risk Management triggering on AI-generated content — Microsoft 365 Copilot has built harder on that native tenant integration than we have, and that is the correct pick for a Microsoft-standardised enterprise that treats its Purview stack as the enforcement layer. Our controls live inside the app rather than at the tenant boundary. Both approaches work; pick the one your compliance team already runs.

Getting from outline to signed document#

Draft the six clauses in the shape above, in plain English, on one page. Circulate it to one lawyer, one security lead, and two frontline managers — not a committee of twelve. Rewrite until every clause fills all three columns of the scoring table. Publish it in the same place employees already look for HR policies, require an acknowledgement on next login, and set a six-month review date on the document itself.

Then do the operational work the policy assumes: turn on SSO for the approved tools, block the unapproved ones at the endpoint or network layer where you can, configure approve-before-send in whatever drafting tool your team uses, and run one thirty-minute training session on the prohibited data list with real examples. A policy without the operational scaffolding is a document; a policy with it is a control.