An AI tool can be introduced one person at a time, but it quickly changes how a whole team works. Someone drafts with it, someone else reviews it, a customer sees its answer, and a manager is asked to stand behind the outcome. An AI working agreement is the small, shared document that makes those expectations explicit before misunderstandings become process.
Table of Contents
Policy is not the point
Most companies respond to AI with a policy: a list of tools, prohibitions, and approvals. Those guardrails matter. But a policy often answers the legal question while leaving the working question untouched: when the assistant produces something that affects a customer, who checks it, who can change it, and what happens next?
An AI working agreement is more practical than a policy. It is a short operating pact among the people who use, review, and own a specific AI-enabled lane. It does not need to predict every model release. It needs to make the ordinary day legible.
That distinction matters for small teams. A generic rule such as “do not share confidential information” is necessary, but it does not tell a sales lead whether an assistant may answer a pricing question from an old deck. A useful agreement says which source wins, who owns that source, and when the conversation must move to a person. That is the difference between a rule on a shelf and a service customers can trust.
Five AI Working Agreement Promises
- Name the lane. State the job in one sentence: “This assistant triages contact requests and prepares a morning summary.” If the lane cannot be named, the assistant will quietly invent one.
- Name the human promise. Say what people still own: approval, customer commitments, sensitive judgment, or the final send. This is not a vote of no confidence in the tool; it is an honest service boundary.
- Name the allowed evidence. List the current sources and their owners. The team should be able to point to the source behind a consequential answer. meLink’s source-of-truth contract is a useful companion here: credible sources can still disagree, and the agreement needs a route for that conflict.
- Name the review rhythm. Decide what is checked every time, what is sampled weekly, and who looks at exceptions. A five-minute review that actually happens beats a beautiful dashboard nobody opens.
- Name the stop rule. Give users permission to pause the lane when its facts, behavior, or customer impact feel wrong. Record what stopped, who owns the next step, and what remains untouched while the team decides.
These are promises to one another, not technical settings. The National Institute of Standards and Technology’s AI Risk Management Framework makes the same broad point in a more formal language: trustworthy AI requires governance to be connected to the context in which the system is used. Context is where a short agreement earns its keep.
Start with one real workflow
Do not convene a committee to write an AI working agreement for every possible use of AI. Pick one live workflow with enough repetition to reveal its edges: inbound website questions, meeting-note preparation, or support-ticket triage. Invite the person who uses it, the person who reviews it, and the person accountable when it disappoints a customer.
Then walk through three recent cases: a routine success, an ambiguous request, and an uncomfortable near-miss. Ask five questions. What was the assistant asked to do? What evidence did it use? What did the human change or approve? What would have made us stop it? Who tells the customer what happens next?
The output can fit on one page. That limitation is a feature. If the agreement needs twenty pages, it is probably describing a system nobody can operate. The OECD’s AI Principles emphasize accountability and transparency; in a small business, those principles become real when a teammate can explain a specific workflow without opening a technical architecture diagram.
Use the agreement to improve the workflow, not merely to document it. If the team cannot name what “good” looks like, turn that into a small evaluation set. If the same uncertainty keeps appearing, tighten the source or route it to review. If a customer-facing answer depends on a judgment call, keep that judgment with the human. Those moves connect naturally to an AI evaluation set and to the human-friendly evidence captured in AI incident reviews.
Make the agreement a living tool
An AI working agreement should change when the work changes: a new source is added, an integration gains access, a new customer promise enters the lane, or a recurring correction reveals a mismatch. Review it after a meaningful incident and during a quiet week, not only after something goes wrong.
The goal is not to slow adoption down. It is to give a team a shared way to move quickly without outsourcing its judgment. Models will change. Interfaces will change. The agreement preserves the things that should not change by accident: the customer promise, the human responsibility, and the right to stop.
Start with one lane this week. Put the five promises where the people doing the work can see them. Revisit them after the next edge case, rather than waiting for a full rewrite. That is not bureaucracy. It is how a team makes AI useful enough to trust—and trustworthy enough to keep using.
Leave a Reply