dooopSoftware · Organization · 12 min

How to Create AI Usage Agreements for Teams

Define free, supervised, and blocked uses to reduce ambiguities, protect data, and review AI practices in daily work.

Published on September 6, 2026

CENTRAL THESIS

An AI agreement is not a broad policy. It is a visible boundary to decide uses, exceptions, and reviews in real work.

Classify uses by risk and reversibility. Record only what changes decisions, precedents, or team practices.

Within the same team, one person uses artificial intelligence to generate tests, another to review architecture, and another avoids the tool for fear of making mistakes. Without an AI usage agreement in development, these practices become individual criteria. The boundary needs to be visible: what is allowed, what requires supervision, what is prohibited, and how to handle exceptions.

When AI Use Becomes Operational Noise

The team senses the noise before naming it. A pull request arrives with an apparently correct solution, but no one knows if AI influenced the decision. One person asks the assistant to explain a piece of legacy code. Another pastes sensitive information into an external prompt. A third stops using the tool because they do not want to take a risk that was not discussed.

The AI usage agreement exists to reduce this operational ambiguity. It does not replace security policy, access management, technical review, legal guidance, or data governance. It also does not solve productivity, quality, or maturity alone. Its role is more specific: to make practices and limits known enough so the team can work without relying on individual interpretations for each task.

This point matters because AI tends to amplify what already exists in the organization. The presentation of the DORA 2025 report describes AI as an amplifier of existing strengths and weaknesses and highlights the organizational system as a relevant part of return on investment. The source does not prove that team agreements guarantee results but reinforces a useful reading: if the process is confusing, the tool does not magically make coordination clear.

Therefore, AI usage agreements in development work best when close to real work. They need to answer questions that arise in code, product, data, security, and user experience. The broader strategic discussion can be in an adoption plan, such as in how to create an artificial intelligence strategy connected to business. Here, the decision is smaller and more everyday: how the team should use AI tomorrow without improvising criteria.

What Needs to Be Included in an AI Usage Agreement

A team agreement can start short. In practice, it should fit on one consultable page and answer six decisions.

Authorized use: which tasks the team can perform with AI without prior authorization.
Supervised use: which tasks require explicit human review before becoming code, decision, or delivery.
Prohibited use: which data, content, decisions, or behaviors cannot be sent, generated, or accepted with AI.
Sufficient traceability: when the team needs to record that AI influenced a decision.
Responsible for exceptions: who decides unforeseen cases and how that decision is documented.
Review trigger: which events cause the agreement to change.

Specificity appears when the agreement guides a concrete doubt. "Use AI with common sense" is not enough. "AI may be used to draft unit tests for own code, provided the expected behavior review is done by the person responsible for the change" already establishes an operational boundary.

Similarly, "do not send sensitive data" may be insufficient if the team does not specify which types of data appear in its context. Credentials, tokens, client information, internal data without authorization, and proprietary excerpts with sharing restrictions need to be treated more concretely. The agreement does not need to list every possible scenario but should reduce the margin for dangerous interpretations.

This kind of clarity also helps separate AI usage agreements from training. Training developers means teaching criteria, techniques, and critical review, a different topic from defining operational agreements. If the main doubt is training, it is worth linking it to a discussion like leadership and augmented human. If the doubt is authorization, limit, and exception, the agreement is the correct artifact.

How to Separate Free Use, Supervised Use, and Blocked Use

The simplest way to start is to classify uses into three groups: free, supervised, and blocked. This classification avoids two common extremes: allowing everything because the tool seems useful or blocking everything because the organization does not yet master all risks.

Free use is suitable for low-risk, reversible, and easy-to-review tasks. Examples: asking for an explanation of a public technical concept, drafting tests for an already understood function, comparing naming alternatives, summarizing authorized internal documentation, or generating question ideas for a technical review. Even in these cases, free does not mean automatic. The person remains responsible for what they accept.

Supervised use involves decisions that may affect architecture, security, data, business rules, or user experience. This includes refactoring suggestions with broad impact, designing critical flows, analyzing probable causes of incidents, interpreting product metrics, and changes in rules that affect user-perceived behavior. AI can support exploring alternatives, but the decision must be reviewed by someone with technical or product responsibility.

Blocked use covers situations where the team cannot assess the risk or is not authorized to expose the content. Sending credentials, pasting client data, accepting code without review, delegating security decisions without human validation, or using a tool without clarity on data handling are examples of limits that must be explicit. Blocking is not a statement against AI. It is a way to preserve judgment where the team does not yet have sufficient control.

A practical criterion is to ask: if the AI’s response is wrong, who notices, how soon, and with what potential damage? If the answer is "anyone on the team notices before integration," the use tends to be free. If it is "only someone experienced notices after affecting architecture, data, or user," the use should be supervised or blocked.

How to Document the Agreement to Make It Findable and Reliable

The agreement should not live in a lost chat conversation. It also does not need to become a lengthy document that no one consults. It should be in the same environment where the team looks for engineering practices, onboarding, code review, and recurring decisions.

DORA addresses documentation quality by attributes such as clarity, ease of location, and reliability, and recommends active creation and maintenance of documentation, as described on the documentation quality page. This reference does not validate a specific AI agreement format but offers useful criteria to assess whether the agreement will be found and used.

A reliable agreement makes clear:

who maintains the document;
when it was last reviewed, if this information exists in the repository or tool used;
which decisions are in effect;
how to propose adjustments;
where to record relevant exceptions;
which related documents need to be consulted, such as security, data, and code review.

Avoid turning the agreement into a generic file named "AI." A name like "AI Use in the Product Squad" or "AI Agreement in Engineering" facilitates search and reduces ambiguity. If the organization already has a page about maturity or governance, such as AI maturity: how to diagnose the organization’s starting point, the team agreement can point to it. But the reverse path must also exist: broader documents should lead to practical agreements.

The point is not to ask people to trust AI, nor to trust individual judgment blindly. It is to keep the boundary available before the decision.

How to Turn Exceptions into Learning, Not Improvisation

No agreement covers everything. Tools change, models change, doubts arise, products evolve. Therefore, exceptions need a defined path. Without this path, the team creates informal governance: whoever has more urgency decides, whoever has more fear blocks, whoever has more influence interprets.

A simple exception flow can request four pieces of information:

what the use case is;
what data, code, or decision will be exposed to AI;
what risk the person perceives;
what result they expect to obtain.

With this, a technical leader, a small group, or a defined role decides whether to authorize, deny, or request adjustment. The decision should be recorded when it creates precedent. Not every doubt needs to become minutes, but an exception that changes the team’s understanding needs to be available for the next person.

It is also worth separating exception from experiment. An operational exception is a one-time authorization to handle an unforeseen case. An experiment requires a testable hypothesis, evaluation criteria, and some way to measure impact. Microsoft describes its ExP platform as a way to incorporate experimentation into the development cycle, validate hypotheses, measure impact, and iterate products, as detailed on the Microsoft Research page about ExP. This does not mean every feedback retrains a model or every AI attempt is an experiment.

This distinction avoids a common confusion. Learning from AI use is not accumulating loose stories. It is turning recurring doubt into agreement adjustment, hypothesis into experiment, and incident into practice change. DORA also relates learning culture to software delivery performance and proposes treating learning as an organizational investment, as described on its learning culture page. This does not authorize concluding that every product learns automatically. Organizational learning requires practice, recording, and review.

When to Review AI Usage Agreements

Reviewing the agreement by calendar can help, but cadence alone often becomes bureaucracy. The most useful approach is to combine observable triggers. The agreement should be reviewed when something changes in risk, context, or team learning.

Good triggers include:

adoption of a new AI tool by the team;
relevant change of model, vendor, or configuration;
incident or near incident involving AI use;
repetition of the same doubt in the team channel;
change in the type of data used in the product;
alteration in critical business rules;
evidence that the agreement is not being followed;
new team members revealing ambiguity in the document.

The agreement can also change when the team gains competence. A use previously supervised can become free if the team has created good review criteria and the risk is low. The reverse can also happen. A free use can be restricted if doubts, failures, or undue exposure arise.

Here, leadership needs to resist two shortcuts. The first is treating the agreement as punishment after an error. The second is treating the review as a ritual without consequence. A good agreement changes when there is enough learning to change practice.

Short Model to Review AI Usage Agreements in Development

Use this model as a quick review of the agreement before presenting it to the team.

Authorized Use

Question: which tasks can the team perform with AI without prior authorization?

A good answer cites specific tasks, such as drafting tests, comparing alternatives, or summarizing authorized internal documentation. A weak answer only says use is allowed to increase productivity.

Supervised Use

Question: which tasks require explicit human review before becoming code, decision, or delivery?

A good answer includes changes in architecture, security, business rules, data, and user experience. A weak answer assumes pull request review solves any AI use.

Prohibited Use

Question: what cannot be sent, generated, or accepted with AI?

A good answer defines clear limits for sensitive data, credentials, proprietary code without authorization, and decisions the team cannot audit. A weak answer uses generic phrases like "use with common sense."

Sufficient Traceability

Question: when does the team need to record that AI was used?

A good answer differentiates trivial use from use that influences technical decisions, product behavior, or risk analysis. A weak answer requires recording everything or nothing.

Responsible for Exceptions

Question: who decides cases not foreseen in the agreement?

A good answer indicates a responsible role or group, response time, and how the decision will be documented. A weak answer leaves each person to decide individually.

Review Trigger

Question: what causes the agreement to change?

A good answer lists observable triggers, such as new tool, incident, recurring doubt, model change, or data type alteration. A weak answer schedules review only when someone remembers.

Fictional Example: AI Agreement for a Product Squad

Imagine a fictional squad responsible for a self-service area in a digital product. The team uses AI in engineering tasks but notices large practice differences among people. Some use the tool to generate tests, others to discuss refactoring, others avoid any use because they do not know what is accepted.

The initial agreement could be as follows: the team allows AI to draft unit tests, explain legacy code without sensitive data, and compare implementation alternatives. It requires supervision for changes in business rules, flows affecting user experience, architecture decisions, and any analysis involving internal data. It blocks sending client data, credentials, tokens, logs with improper identification, and acceptance of code without human review.

Traceability is also proportional. If AI helped write a simple test, no separate record beyond the reviewed code is needed. If it influenced an architecture decision or business rule, the person records in the pull request or decision document that AI was used as support, which alternative was considered, and which human criterion prevailed.

Exceptions are handled by the squad’s technical leadership and a product person when there is user behavior impact. When the same doubt appears more than once, it becomes a candidate for agreement adjustment. At each team review cycle, recurring doubts are evaluated.

The hypothesis to measure, in this fictional example, is not "AI increased productivity." It is more specific: whether the agreement reduces repeated doubts about authorization and improves the quality of review discussions. This hypothesis requires the team’s own evidence and cannot be presumed.

The next step is to document a short agreement, classify uses as free, supervised, and blocked, define exceptions, and review when there is a real learning trigger. Thus, human judgment is outlined before the next decision arrives.

If you want to discuss this decision in your company’s context, talk to dooop.

Sources

NEXT DECISION

Discuss Application in the Company

Conversation about the software company context

Content from dooop. Registration allows linking this topic to the reader’s journey and tracking interest in the subject.