Acceptable-use policy for AI-enabled work

Start with the control objective, not a generic ban list

Write one control objective that connects AI use to the risk the organization is trying to manage. For example: “People may use approved AI services for bounded drafting and analysis while protecting restricted data, preserving accountable human decisions, and retaining enough evidence to investigate material errors.” This is more useful than “use AI responsibly” because it names the protected outcomes.

The NIST AI RMF Core calls for policies, procedures, and practices that reflect risk priorities; clear roles and lines of communication; inventories; documented human oversight; and ongoing monitoring and review. Use those outcomes as a design checklist, while recognizing that the AI RMF is voluntary and is being revised. It does not replace applicable law, sector rules, contracts, or internal authority.

Define the policy owner, security and privacy reviewers, business process owner, tool administrator, user, approver, and incident responder. A person can hold more than one role, but the authority must be explicit. Users should know who can approve a tool, who can authorize restricted data, who owns a business decision, and who can suspend access.

Sources: [1]

Classify uses by data, action, and consequence

Create a decision table with three axes. Data covers public, internal, confidential, regulated, personal, client-owned, and contract-restricted information. Action covers drafting, summarizing, extraction, analysis, code generation, external communication, record changes, and automated execution. Consequence covers reversible internal assistance through decisions that can materially affect people, money, rights, safety, customers, or public claims.

For each combination, mark one of four dispositions:

The NIST Generative AI Profile recommends context-specific risk mapping, defined human oversight, evaluation, documentation, incident learning, and controls for risks that generative AI can amplify. Translate those practices into the organization's own systems and use cases. Do not copy framework language without naming the actual tool, data, process, and accountable person.

• Allowed: an approved tool, permitted data, and low-consequence use with ordinary review.
• Allowed with controls: specified redaction, source checking, logging, approval, or sandboxing is required.
• Exception required: a named owner must document purpose, safeguards, duration, and residual risk before use.
• Prohibited: the use exceeds current authority or risk tolerance.

Sources: [2]

Write operating rules people can execute

Every rule should contain a trigger, required action, evidence record, owner, and escalation condition. “Check AI output” is too vague. A workable rule is: “Before an AI-assisted external factual claim is released, the content owner must compare each material claim with an authoritative source, retain the source reference and reviewed version, and escalate contradictions to the policy owner.”

Cover at least these operating areas:

Keep the rule close to the workflow. A policy page that nobody sees at the moment of action is weak operating evidence. Tool configuration, access controls, templates, approval steps, and training should reinforce the same boundary.

• approved tools, accounts, models, connectors, and plugins;
• permitted and restricted data, including screenshots and copied context;
• source verification, calculation checks, and citation handling;
• human approval for external communication and consequential action;
• intellectual property, confidentiality, privacy, and records obligations;
• testing before automation or integration changes;
• incident reporting, access suspension, and evidence preservation;
• supplier changes, model updates, and periodic reassessment.

Worked policy row: an AI-assisted customer briefing

Consider a synthetic team preparing a customer briefing from internal support notes. The policy row classifies the notes as confidential, the action as summarization plus external communication, and the consequence as material customer communication. The disposition is allowed with controls.

The user must work in the approved enterprise environment, exclude authentication secrets and unrelated personal data, cite each material factual claim to an internal source, flag uncertainty, and route the final briefing to the account owner. The evidence record includes the source list, reviewed draft version, approver, timestamp, and any removed unsupported claims. If the tool attempts to call an unapproved connector or the source notes contain contract-restricted data, the user stops and opens an exception request.

During a monthly sample, the reviewer finds that the briefing was approved but one product-availability claim lacked a source. The operating result is repair, not “policy complied.” The owner corrects the briefing, records the gap, checks whether the template prompted for evidence, and decides whether additional controls are needed. This demonstrates why policy effectiveness depends on operating evidence rather than publication of a document.

Define an exception path that cannot become a loophole

An exception request should identify the proposed use, data classes, tool and configuration, business purpose, expected duration, affected people, safeguards, accountable sponsor, legal or specialist review where required, and rollback plan. Set an expiry date. Permanent exceptions should become reviewed policy changes, not indefinite waivers.

Track exception volume, repeated reasons, overdue expiries, incidents, unsupported-claim findings, unapproved-tool attempts, and corrective actions. These signals do not prove that the policy is effective, but they show where to inspect. Low incident counts can mean low risk, weak reporting, or limited detection.

Test operation and review the policy on a schedule

Use a small evidence sample rather than relying only on training completion or employee attestations. Select use cases across data classes and consequence levels. Confirm that the tool was approved, required checks occurred, evidence was retained, approvals matched the rule, and exceptions were handled on time. Record failures and corrective actions without turning the review into surveillance beyond the stated purpose.

Set event-driven review triggers for new models, connectors, laws, contracts, incidents, material workflow changes, and evidence that users cannot follow the rule. Also set a calendar review date. The owner should record which sources and system behaviors were checked, what changed, and what remains uncertain.

Do not claim that an acceptable-use policy proves legal compliance, prevents incidents, or establishes control effectiveness. Those conclusions depend on jurisdiction, system configuration, implementation, testing, and operating evidence.

Two Prune can assess how a participant applies an acceptable-use rule in a bounded simulation, including data classification, source verification, escalation, and communication. It does not write an organization's legal policy, monitor production systems, certify compliance, rank people, or make employment decisions.