A One-Page AI Usage Policy That Actually Works

I want an AI usage policy to answer the questions that come up during real work: which data may enter a tool, who reviews the output, and who can authorize an action.

The policy should fit where people will read it. A short team agreement works best when it links to the approved tools, security rules, and review procedures that give it effect.

TL;DR

• Set data-handling and permission rules before the pilot starts.
• Give every change a named owner and an explicit review path.
• Keep tool access scoped, and define which actions require a human to execute them.
• Record useful evidence without turning session logs into a second store of sensitive data.
• Review the agreement after the pilot, after an incident, and on a regular schedule.

Start with the existing rules

Before a team tries an assistant on work material, I check the organization’s approved tools, data classifications, retention rules, and access policy. A new team agreement should reference those rules. It should not quietly override them.

The first version can be small. Name the permitted pilot work, the data it may use, the reviewer, and the stop conditions. After a month of actual work, use the results to revise the agreement. The First 90 Days post describes that adoption sequence.

A sample team agreement

This is an example to adapt with the team and the people responsible for security and data governance. The human-execution rule below is a deliberate choice for this example, not a claim that every automated workflow needs the same policy.

AI-assisted development agreement

Team: [name]. Owner: [name]. Effective: [date]. Next review: [date].

1. Every change has a named human owner. That person understands the change, records how it was verified, and owns follow-up.
2. Use approved tools and approved data. Keep customer data, personal information, credentials, and secrets out of general-purpose prompts. Use synthetic or redacted fixtures. Any work with real data must stay in an environment approved for it.
3. Review the behavior, regardless of who drafted it. Apply the normal tests and code review. Use the additional review required for the team’s documented critical systems.
4. Keep supported tool configurations reviewable. Record approved assistants, owners, and configuration in the team’s tool register. Document exceptions so support and review expectations are clear.
5. A human executes protected actions. For this team, that includes destructive production changes and customer-visible messages. An assistant may prepare the proposal and validation evidence; the authorized person reviews and executes it.
6. Scope tool access to the task. Review permission changes as code or through the organization’s access process. A tool being available does not establish permission to use it.
7. Retain decision and verification evidence. Record relevant actions, checks, and outcomes under defined access and retention rules. Redact sensitive material; do not retain raw prompts by default when they contain restricted data.
8. A qualified human approves security-critical changes. An assistant can draft code or flag risks. It does not replace the required reviewer.
9. Review the work assigned to assistants. Use accepted outcomes, defects, rework, cost, and reviewer feedback to decide what to expand or restrict.
10. Use incidents to improve the process. Name the owner of recovery and follow-up. Examine the assumptions, permissions, checks, and review conditions that allowed the failure without treating the tool or an individual as the whole explanation.

What the agreement protects

Ownership and review. An assistant’s contribution belongs in the record, but it does not settle whether a change is correct. The author and reviewer need enough evidence to explain the behavior and its limits.

Data and permissions. Read-only access still exposes data. Review the destination, retention, and permitted use as well as whether the tool can write. Reference the organization’s data-governance policy for provider training and storage restrictions.

Protected actions. List these explicitly. “Be careful with production” leaves too much to interpretation. For the sample policy, preparation and execution are separate: the assistant can produce a migration and checks, while an authorized person performs the change.

Evidence. A useful work record contains the decision, relevant tool action, verification result, and outcome. Logging everything indefinitely creates its own data-management problem. Choose access, redaction, and retention rules before collecting the record.

Keep implementation details in linked records

The agreement needs a stable home for decisions that change more often:

• an approved-tool register with supported configurations and owners;
• a list of critical systems and required reviewers;
• data-handling and retention rules;
• the current classes of work permitted in the pilot; and
• the procedure for reporting mistakes or requesting an exception.

I avoid adoption quotas such as “AI must assist 30% of commits.” They reward activity without showing whether the work improved. Task-specific acceptance, review defects, rework, and cost are more useful when measured against a baseline.

Review it against actual work

Quarterly is a reasonable starting cadence. A serious incident, a new data use, or a material permission change should trigger an earlier review.

I ask whether the agreement still matches practice, whether an ambiguous rule contributed to a failure, and whether the evidence supports expanding a class of work. Record the reason for each change and assign an owner to any corrective action.

For the implementation workflow, see the AI-Assisted Dev Adoption Loop. For agent-specific permissions and promotion checks, see Agent Rollout with Guardrails.