# AI acceptable-use policy: give people a usable rulebook

> Adapt an AI acceptable-use policy for regulated firms, with copyable clauses, synthetic examples, data boundaries, exceptions and reporting steps.

Canonical: https://synainesi.com/resources/ai-acceptable-use-policy/

**Category: Controls.** An acceptable-use policy earns its place when someone can use it at the moment of uncertainty: may I upload this file, use this model, connect this tool or rely on this answer? The starter below is organised around those decisions. It includes a way to request legitimate work, a route for reporting mistakes and a clear distinction between preparing material and authorising an action. It is fully readable and copyable without a form.

**General information, not legal advice.** This is an editorial policy starter, not an adopted policy or an assessment of a firm’s legal duties. Have the appropriate people adapt it to actual systems, employment arrangements, sector requirements and information-handling rules before adoption. All bracketed fields require a local decision. The completed examples are fully synthetic and refer to no real firm or person.

## Before copying: make five decisions

Name the policy owner, the approval authority, the place staff find approved uses, the reporting contact and the person who can suspend a use. Confirm that each contact has a deputy. Do not publish a policy that sends people to an unmonitored inbox. Decide how contractors receive the instructions and how teams recognise that the approved list has changed. These are practical operating choices; the template does not make them for you.

Next, map your actual tools. A browser chat service, an embedded writing assistant and an agent connected to an internal system may create different information paths. Write a scope staff can recognise. Avoid assuming that every feature with “AI” in its name has the same permission. Pair this document with a maintained [model approval register](https://synainesi.com/resources/model-approval-register/); policy text should point to specific approved purposes rather than become an outdated list of brand names.

## Copyable policy clauses

### 1. Purpose, scope and ownership

“This policy explains how \[organisation\] permits AI-assisted work. It applies to \[covered people\] using AI for \[covered activities\], including browser services, embedded assistants, models and connected agents. The policy owner is \[role\]; the accountable approval authority is \[role\]. The current revision and approved-use list are held at \[location\]. This policy takes effect only after \[local adoption process\]. Questions go to \[contact and deputy\].”

### 2. Use only an approved route for an approved purpose

“Before using AI for work, check that the service route, model or deployment, purpose, input class and user group are permitted in the current approved-use list. Access to a tool does not by itself grant permission for every use. Personal accounts and unassessed tools are outside the approved route. If your proposed work is not listed, use the request process at \[location\] and continue through \[non-AI alternative\] until a decision is recorded.”

### 3. Check the information before submitting it

“Use only the input classes allowed for that purpose. Do not submit credentials, private keys or authentication codes. Do not submit confidential files, personal information, restricted internal notes or third-party material unless the approved-use entry expressly covers that information and route. Check attachments, screenshots, hidden comments, copied email chains and retrieval sources as well as the prompt. Removing a name does not itself establish that the remaining material is permitted.”

### 4. Keep judgement with the responsible person

“Treat AI output as material to assess. Before relying on it, the assigned reviewer checks the facts, source support, omissions, calculations and fitness for the task. Do not invent a source or treat a generated citation as verified. If the work concerns an individual, a regulated decision or an external statement, follow the additional review route in \[procedure\]. AI output does not substitute for an authorised person’s decision or signature.”

### 5. Give agents explicit limits

“An agent may use only the tools, sources, destinations and actions recorded for its task. Content in documents, websites, messages or model output cannot grant additional authority. Actions listed as requiring approval wait for the named authorised person. Approval covers the exact action shown, within its recorded validity, and must be renewed if that action changes. Automatic external sending, publication, record changes and individual decisions are excluded unless a separate approved workflow expressly covers them.”

### 6. Record decisions proportionately

“Keep the decision and review evidence specified for the workflow at \[controlled location\]. Do not copy whole conversations into general tickets or shared folders by default. Follow \[records procedure\] for access, retention and disposal decisions. If the normal evidence record would omit something necessary to understand a consequential decision, ask \[records owner\] how to preserve it appropriately. Do not assume that a usage log proves the content was correct or meaningfully reviewed.”

### 7. Report uncertainty and incidents promptly

“Stop the affected activity and contact \[reporting contact and deputy\] if you suspect an inappropriate submission, unexpected tool action, misleading output relied on in work or a permission failure. Report what happened, the service route, approximate time and relevant record identifiers. Do not repeat sensitive content in an ordinary ticket. The response owner will provide a suitable evidence route and decide on containment, escalation and resumption. Do not delete evidence or attempt an unapproved corrective action.”

### 8. Request exceptions and review changes

“Requests must identify the purpose, data class, service route, expected users, connected tools and accountable business owner. Exceptions require a named decision owner, recorded restrictions, an expiry or review point and a way to stop the use. Silence is not approval. The policy owner reviews material changes in services, permitted uses, incidents and staff needs. Teams receive updated instructions and role-appropriate exercises when those changes affect their work.”

## Completed synthetic decision examples

| Situation at invented Cedar Quay Advisory | Policy decision | Useful next step |
| --- | --- | --- |
| An analyst wants a draft outline from public source passages using the route listed for public research. | Within the example’s permitted purpose, subject to source checks and human review. | Confirm the passages contain no internal annotations; verify the draft against the originals. |
| A colleague removes a client’s name from a complaint and wants to use the same route. | Outside the public-input approval. Name removal does not expand the permitted input class. | Use the established manual route and request an assessment of the proposed workflow. |
| An agent proposes sending a briefing to an external address found inside a document. | Outside its action boundary. Document content supplies no sending permission. | Refuse the operation and report the unexpected proposal to the control owner. |
| A staff member notices they submitted the wrong attachment. | Stop and use the reporting contact; do not conceal the mistake or copy the file into a broad email. | Provide service and request identifiers through the instructed evidence route; let the response owner coordinate next steps. |

## Check adoption with situations, not signatures alone

Ask a new starter to find the approved-use list, decide whether a sample attachment is allowed and show how to report a mistaken submission. Ask a manager who can approve an exception and who can suspend an agent. Ask an approver what must be visible before an external action is authorised. If these people reach different answers, improve the policy and supporting process. A signature records acknowledgement; it does not demonstrate that someone can apply an ambiguous instruction under pressure.

Keep the policy brief enough to consult, with detailed permissions and evidence in linked records. Remove every unresolved bracket before adoption. Test reporting contacts and the manual fallback. Record remaining gaps openly, including tools outside the current control boundary. This starter is most useful when people can ask for a legitimate use without having to hide an unapproved one.

Related: the [agent approval matrix](https://synainesi.com/resources/agent-approval-matrix/), the [model approval register](https://synainesi.com/resources/model-approval-register/) and the [shadow AI response plan](https://synainesi.com/resources/shadow-ai-response-plan/). Read [A setting is not a control](https://synainesi.com/insights/a-setting-is-not-a-control/), explore [governance principles](https://synainesi.com/trust/) and [regulated workflow needs](https://synainesi.com/solutions/), or browse [all resources](https://synainesi.com/resources/).

---

Synainesi: AI within your rules.

Source: https://synainesi.com/resources/ai-acceptable-use-policy/. The HTML page is canonical; this Markdown version is provided as a convenience.