AI Email Governance Policy: What to Put in Writing

An AI email governance policy is the enterprise-level document that answers a single question for auditors, regulators, and your own board: how does this company oversee the use of AI in the one channel where a mistake reaches a customer inside a minute? It is not the acceptable use policy an employee reads on day one. It is the parent document the AUP inherits from — the one that names the committees, the tools, the data boundaries, the tiers of automated action, and the human being responsible when something goes wrong.

Most governance policies fail the same way. They read as sophisticated risk theory that no one can act on, or as a fifty-page appendix to an existing information-security policy that no one reads. This guide gives you the seven sections a working AI email governance policy actually needs, the scoring table auditors expect against, a worked example of the one section teams get most wrong, and an honest recommendation about which tools help you meet the policy versus which ones you write around.

The short answer: seven sections, one document#

A working AI email governance policy names seven things, in this order: scope (what the policy covers and what sits outside it), the approved-tool list (named products, named tenants, named plans), autonomy tiers (what a person, a copilot, and an autopilot are each allowed to do, and who grants each level), prohibited data classes (what may never be processed by AI, in any form), logging and review (what is captured, who reviews it, on what cadence), incident handling (how mistakes are surfaced and remediated), and named owners (a role behind every clause).

These are not a menu — they are the minimum set an auditor working from the NIST AI Risk Management Framework or ISO/IEC 42001 will look for, mapped to the specific mechanics of email. Skip a section and you have not written a shorter policy. You have written one that will fail the first control review or the first incident, whichever comes first.

Criteria that actually matter#

The failure mode of most AI governance policies is that they cover abstract principles — accountability, transparency, fairness — that no one can enforce on a Tuesday afternoon. The criteria below are the operational ones. Each is written to fail loudly rather than fail silently: if a policy meets it, you can prove that; if it does not, you can point at the clause and fix it.

1. Scope, stated in one paragraph#

Say plainly which surfaces, teams, and use cases the policy covers, and which it does not. AI in email is a wider surface than most policies realise: it includes drafting assistants, triage and classification agents, calendar and follow-up automation, meeting-note summarisers that email themselves out, and every browser extension or plugin that reaches into a mailbox. If the policy silently applies to some of those and not others, employees will assume it applies to none.

State the negative space too. If the policy does not cover marketing-email tooling (because it lives under marketing operations), or transactional email from your product (because it lives under engineering), name that and point at the sibling policy. A scope clause that leaves a gap becomes the gap where an incident lives.

2. Approved tools, by name and by tenant#

The list is not "AI email assistants." It is a named table of products, plans, and login paths, with the data-processing posture that made each one approvable — enterprise tenant, no-training-on-prompts contractual terms, SSO required, region of data processing recorded. Personal ChatGPT and enterprise ChatGPT look identical and are different tools for policy purposes; the same is true of Microsoft 365 Copilot on a consumer versus enterprise tenant.

Publish the request path for adding a tool. Governance policies that ban everything unlisted force a shadow-AI problem underground; ones that permit everything remove the point of a policy. The workable shape is a short allowlist, a clear prohibition line, and a named intake owner (usually the CISO or the AI risk lead) with a target turnaround so a team asking to add a tool is not waiting for a committee that meets quarterly.

3. Autonomy tiers, and who grants each#

This is the section unique to AI in email, and the one nearly every general-purpose AI policy skips. Define the tiers of action explicitly: Manual (a human writes and sends), Copilot (AI drafts, a human approves before send), and Autopilot (AI sends within a named allowlist, without pre-send human approval). Say which recipients, which message types, and which senders are eligible for each tier — and name the role that grants an escalation to Autopilot for a given workflow.

For most enterprises the default should be Copilot with a narrow, documented Autopilot allowlist for routine categories (out-of-office responses, calendar confirmations, receipt-of-message acknowledgements). Everything else pauses for a human. NIST's AI Risk Management Framework treats a human-in-the-loop as the primary mitigation for generative-AI risk in customer-facing content, and this clause is where you write that down in a way you can actually enforce.

4. Prohibited data classes#

List the categories that may never be processed by an AI email tool, in any form — prompt, attachment, quoted thread, or classification input. Concrete categories, not "sensitive data." At minimum: full or partial payment card numbers, government identifiers (SSN, national ID, passport), banking credentials, protected health information, personnel-file contents (compensation, reviews, disciplinary records), attorney-client privileged material, unreleased financial results, and any customer data covered by a contract that restricts AI subprocessors.

Include the two categories governance policies almost always miss: inbound customer messages containing any of the above (you did not put the SSN in, the customer did, but the AI processing it is the same event), and internal threads discussing customers by name where those customers have not consented to AI processing. Point at your data classification standard for definitions, but restate the categories here — a policy that requires a cross-reference to be actionable is not actionable.

5. Logging, review cadence, and audit access#

Every AI action taken against email — every draft generated, every automated send, every rule triggered, every classification label applied — must be logged with enough context that a reviewer can reconstruct what happened months later. State the retention period, the fields captured (actor, tool, model tier, message id, action taken, outcome), and who is authorised to query the log.

Then state the review cadence: spot-checks weekly by the operating team, sampled review monthly by the compliance owner, full audit annually. ISO/IEC 42001 explicitly requires that AI management systems document how nonconformity is identified and handled, and reviewers will look for the words — a named sample size, a named reviewer role, a named escalation trigger. Without those specifics the logging clause is a promise that the log exists, which is not the same as evidence that anyone reads it.

6. Incident handling with a self-report window#

Someone will paste something they should not have, or an autopilot rule will fire on a message it should not have touched. The question is whether you learn about it in an hour or in a subpoena. Name the reporting channel, the required facts (tool, prompt or trigger, recipient if any, whether prohibited data was involved), and promise in the policy itself that a self-reported incident within 24 hours is treated as good-faith remediation rather than misconduct.

Then link the incident register to your existing information-security incident process rather than building a parallel one. AI incidents are a class of information-security incident — they belong in the same tracker, the same triage, and the same root-cause review as any other data exposure. A separate AI incident register is a governance smell; it usually means the AI team is trying to hide from the security team.

7. Named owners, for every clause#

The last section is the one that turns a document into a control. For each of the previous six sections, name the role (not the person) responsible for maintaining it, and the role responsible for enforcing it. Scope and named owners themselves usually sit with the CISO or an AI risk officer; approved tools with the CIO or head of IT; autonomy tiers with the business-line owner for the workflow; prohibited data with the DPO; logging and review with the compliance owner; incidents with the incident-response lead.

Also name the owner of the document — one role, not a committee — with a review cadence and a change log at the foot of the policy. Six months is a defensible interval; anything longer and the policy will visibly outrun the model, the regulations, and the tooling. ISO/IEC 42001 and the NIST AI RMF both expect documented review cadence, and it is one of the first artefacts an assessor asks for.

Scoring table: section, risk, owner, review#

Use the table below as a review pass on any draft governance policy. If a section in your document cannot fill all four columns concretely — a specific risk it prevents, a named role that enforces it, and a review interval — the section is not done. It is aspirational text, and aspirational text fails audits and incidents both.

Worked example: an autonomy-tier clause that actually works#

Abstract clauses are easy to nod at and impossible to enforce. Below is what an autonomy-tier clause looks like when it is written to be acted on rather than admired. Adapt the categories to your business; keep the shape.

Notice what the example does. Every tier is defined by what it permits and what it prohibits, in words a non-lawyer recognises. The "Never Autopilot" line is the one clause most policies avoid writing because it forecloses future flexibility, and it is exactly the clause an auditor and a regulator will look for. The escalation path names a role and an artefact, so a team wanting to expand automation has a door to knock on rather than a committee to guess at.

Red flags: signs the policy will not survive its first test#

If your draft governance policy shows any of the patterns below, fix them before the document goes for signature. Each one is a failure we have watched play out in real reviews.

• It defines principles without controls. "We will use AI responsibly" is a value statement, not a policy. Every principle needs a clause underneath it that says who does what by when, or the principle is decoration.
• It has no autonomy tiers. A general-purpose AI policy that treats email the same as document drafting misses the whole point — email sends. If the policy does not distinguish drafting from sending, it will be applied to neither.
• It cites frameworks without adopting them. Naming the NIST AI RMF and ISO/IEC 42001 in the preamble and then writing a policy that maps to neither is a common failure. If you cite a framework, at least map the sections.
• It bans everything or permits everything. Blanket bans drive use underground; blanket permissions remove the ability to say no. A working policy has an allowlist, a prohibition list, and a request path.
• It has no named owner for the document itself. "The AI governance committee" is not an owner — committees do not answer email. One role, with a name behind it, keeps a policy alive.
• It has no review cadence, or one longer than a year. The models, tools, and regulations move faster than that. Six months is defensible; twelve is a promise the policy will be wrong by the time anyone reads it.
• It confuses the governance policy with the acceptable use policy. The AUP is the one-page derivative employees read; the governance policy is the parent document the AUP inherits from. Publishing only the parent leaves employees guessing; publishing only the child leaves auditors guessing.

What we would pick, and why (honest)#

The policy is only as strong as the tools that have to enforce it. A governance policy that requires approve-before-send, a full audit trail of every action, undo on mistakes, hard prohibitions on named data classes, and a documented Autopilot allowlist needs email tooling that makes 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, a per-action audit log, one-tap undo, and no training on user mail — on Gmail, Outlook, and any IMAP account. Those controls map cleanly onto the autonomy-tier, logging, and incident sections above without a policy team having to explain the workaround for each one.

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

Where AI Emaily is not the right fit: if your governance program is anchored in a GRC platform — ServiceNow IRM, RSA Archer, OneTrust AI Governance — and your compliance team expects every AI action to feed that platform natively, our audit log lives inside the app and is queryable by API rather than a first-class connector to those systems today. Microsoft 365 Copilot has built harder on the native Purview and Microsoft-tenant reporting surface than we have, and for a Microsoft-standardised enterprise that treats its tenant as the enforcement boundary, that is the correct pick. Our controls sit inside the app rather than at the tenant layer, and both approaches work — the question is which one the compliance team already runs.

Getting from outline to signed document#

Draft the seven sections above in plain English. Circulate to one lawyer, one security lead, one IT lead, and two frontline operating managers — not a committee of twelve. Rewrite until every section fills all four columns of the scoring table. Publish it in the same place employees already find HR and security policies, require acknowledgement on next login, and set a six-month review date on the document itself with the change log at the foot.

Then do the operational work the policy assumes: turn on SSO for the approved tools, block unapproved ones at the endpoint or network layer where you can, configure approve-before-send in the drafting and agent tool your team uses, wire the audit log into the same review process as your other security logs, and run one thirty-minute training session on the prohibited data list with real examples from your own inbox. A policy without that scaffolding is a document. A policy with it is a control.