A team AI policy is useful only when it helps someone make a concrete decision before using a tool. General statements such as “use AI responsibly” do not explain which work is allowed, what information may be entered, or when a human must approve the result.
NIST’s AI RMF treats governance as a continuous function across the AI lifecycle. The NIST Privacy Framework adds privacy risk management, and OWASP guidance highlights the need to treat external content carefully and limit unnecessary autonomy. A practical policy turns those principles into workflow rules.
This guide is not legal advice. Organization-specific requirements should be reviewed by the appropriate owners.
1. Define purpose, scope, owner, and review date
State:
- who is covered;
- which browser tools, APIs, assistants, extensions, and agents are covered;
- which teams and data environments are included;
- who approves exceptions;
- who reviews incidents and policy changes.
Record a policy version, effective date, owner, and next review date.
2. Classify work by risk and consequence
Use categories that people can apply before starting work.
| Class | Example | Default control |
|---|---|---|
| Allowed | Brainstorming with public information | Approved account and normal review |
| Conditional | Drafting from internal non-sensitive material | Approved workspace and human review |
| Restricted | Work involving sensitive internal information | Named owner and additional review |
| Not approved | Work outside documented authority or controls | Stop and request a separate decision |
The same activity may change class depending on the data and intended action.
3. Define data and input rules
For each data class, state:
- whether input is allowed;
- which account or workspace may be used;
- whether redaction or approval is required;
- retention and deletion expectations;
- whether files, screenshots, logs, prompts, and retrieved documents are included.
Do not focus only on names. Combined details may reveal confidential context even when direct identifiers are removed.
Generated output also needs a data class because it may reproduce or transform sensitive input.
4. Approve exact accounts and configurations
An approved provider does not make every account type approved.
Record:
- personal account, organization workspace, or API project;
- allowed plan and region;
- administrator and billing owner;
- identity and authentication requirements;
- history, retention, and training settings;
- approved connectors and extensions;
- logging, export, and deletion procedures.
Re-review when terms, data practices, integrations, ownership, or account architecture changes.
5. Separate assistance from authority
The policy should state what a model may suggest and what requires human approval.
External communication, publication, payments, access changes, deletion, production changes, and other consequential actions should require an authorized person before the first visible or difficult-to-reverse step.
The approver should see the exact payload, relevant evidence, intended destination, side effects, and rollback path.
Require least privilege, narrow tools, and short-lived authorization for workflows that can act on another system.
6. Treat retrieved content and generated output as untrusted
Text inside webpages, files, messages, tickets, and retrieval results is content to analyze, not permission to change policy or use additional authority.
Separate:
- organization instructions;
- user requests;
- external content;
- tool results;
- final approved actions.
Important facts, citations, calculations, and external messages require verification proportional to their impact.
7. Define evidence, disclosure, and recordkeeping
For important workflows, record as appropriate:
- user and business purpose;
- tool, model, plan, and date;
- input data class;
- source documents and versions;
- raw output;
- human edits and approval;
- checked evidence;
- action taken;
- exceptions and incidents.
Protect the evidence itself with access, retention, and deletion rules.
Define when AI assistance must be disclosed to readers, customers, reviewers, or other affected people. The rule may differ by workflow.
8. Require evaluation and monitoring
Approval for one task is not approval for every task.
Repeated workflows should have:
- an intended purpose;
- representative test cases;
- critical failure conditions;
- a current baseline;
- an owner and escalation path;
- a review schedule.
Monitor accepted outcomes, correction time, important failures, incidents, cost, and reviewer feedback. Model or product changes should trigger regression checks for important workflows.
9. Use narrow, expiring exceptions
An exception request should include:
- business need;
- exact tool and configuration;
- data classes;
- affected systems;
- expected benefit;
- risks and controls;
- duration and owner;
- exit and deletion plan.
Exceptions should expire unless renewed. One project’s approval should not become an undocumented organization-wide approval.
10. Define incident and suspension procedures
The policy should explain how to report unexpected disclosure, misleading output used externally, account problems, unapproved actions, service outages, or failures to export or delete required data.
Define who may suspend a tool, revoke access, preserve evidence, notify owners, and decide whether use may resume.
Review the policy after incidents and when models, products, connectors, data classes, contracts, or ownership changes.
Minimum policy table
| Area | Minimum question |
|---|---|
| Scope | Who and which systems are covered? |
| Use cases | What is allowed, conditional, restricted, or not approved? |
| Data | What may be entered and under which controls? |
| Configuration | Which account, plan, settings, and connectors are approved? |
| Authority | What requires human approval? |
| Verification | Which outputs require checks? |
| Records | What evidence is kept and protected? |
| Disclosure | When must AI assistance be disclosed? |
| Exceptions | Who may approve them and when do they expire? |
| Incidents | How is use reported, suspended, and resumed? |
| Review | Which events trigger re-evaluation? |
Short rollout checklist
Before publishing the policy, confirm that:
- a named owner and review date exist;
- work is classified by risk;
- data rules cover files, prompts, logs, and retrieval sources;
- approved configurations are explicit;
- consequential actions require human approval;
- external content cannot grant authority;
- important outputs require verification;
- exceptions expire;
- incident and suspension paths are clear;
- workers receive examples and training.
The best policy is not the longest document. It is the document that helps a person make the correct decision before data is uploaded, an output is trusted, or an action becomes difficult to reverse.