From Pilot to Production Contract: What to Renegotiate in AI

To move from a paid pilot to a production contract for an AI agent, replace the terms written for learning with terms written for operation. That means a defined role, named owners, support and incident duties, data and access rules, a pricing structure that fits ongoing use, and a clear exit. The pilot contract answered whether the idea worked. The production contract must say who keeps it working, keeps it safe and keeps it affordable.

Key takeaways

• A pilot contract buys evidence. A production contract buys a service, so the unit of purchase, the duties and the review rhythm all change.
• Scope must move from a test of one workflow to a named role with approval boundaries, permissions and an observable success criterion.
• Operations need written owners: monitoring, evaluations, incident response, change approval and permission review should not be left implied.
• Data, credentials and configuration need portability and deletion terms before the agent holds real company context.
• Pricing and usage limits should be renegotiated around how the agent will actually be used, with alerts and a review date, not carried over from the pilot.

Why does a pilot contract not fit a production service?

A pilot is designed to be forgiving. It usually has a short horizon, a small group of users, a narrow workflow and an informal understanding that things may break. The contract reflects that: broad language about "services", few obligations on either side, and an end date that works as a natural exit.

Production reverses each of those assumptions. People depend on the agent, so a failure has a cost. The agent holds memory, connects to tools and acts inside channels, so mistakes can reach customers or records. The engagement has no natural end date, so drift becomes the main risk: the agent slowly stops matching the business, and nobody is clearly responsible for noticing.

If you sign the pilot terms forward, you inherit gaps nobody chose. Who answers when the agent behaves oddly on a weekend? Who approves a new tool connection? What happens to the memory the agent built over many months if you leave? A pilot rarely needs those answers. A production service cannot run without them.

It helps to be clear about what the pilot was supposed to prove before you decide what carries over. The article on proof of concept, pilot or production describes what each stage must demonstrate. If the pilot did not prove its stated criterion, the right move is to extend or stop it, not to renegotiate into production.

Which scope and success terms should change?

In a pilot, scope often reads like a feature list: the agent will draft replies, summarize tickets, search documents. In production, scope should read like a job description. A role has a purpose, inputs it may use, actions it may take, actions it may only propose, and people who review its work.

Rewrite the scope section so it answers these points:

• The single role the agent fills, in one sentence a new employee could understand.
• The tools and data sources it may use, each with the level of access it needs and no more.
• The actions it may take alone, the actions that need human approval, and the actions it must never take.
• The channels where it operates and who may instruct it.
• The success criterion, stated so someone can observe it without asking the vendor.

The success criterion deserves the most attention. Pilot criteria are often about demonstration: it worked on the sample. Production criteria are about ongoing quality: work completed correctly, escalations handled, reviewer corrections trending in the right direction. Our guide to success criteria for an AI agent pilot is a good starting point, and the production version should add how often the criterion is measured and who sees the result.

Also write down what happens when you want to expand the role. Without a defined route, every addition becomes a negotiation or, worse, an informal favor. A change process that names who requests, who approves and how the change is tested keeps growth deliberate. The AI agent statement of work article shows how to lay these sections out.

What operating duties belong in a production contract?

This is where most pilots leave the largest gap. During a pilot, the team that built the agent also watches it, because they are close to it. In production, that attention has to be a contracted duty, or it fades.

The duties to name explicitly are these:

• Monitoring: what is observed (task outcomes, errors, tool failures, usage), where it is recorded, and who can read it. Observability concepts such as traces, logs and metrics are a useful shared vocabulary here, and the [OpenTelemetry observability primer](https://opentelemetry.io/docs/concepts/observability-primer/) explains them plainly.
• Recurring evaluations: a fixed set of test cases the agent must keep passing, run on a schedule and after every change. The [Anthropic guide to evals for agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) describes how such tests are built.
• Incident response: what counts as an incident, how it is reported, the expected acknowledgment time in plain terms, who has authority to pause the agent, and how a written review follows.
• Integration maintenance: who fixes a connection when a connected tool changes its interface or credentials expire.
• Permission review: how often access is reviewed and who signs off. The permission review walkthrough can serve as the template.
• Controlled improvements: how changes reach the live agent, with testing and a rollback path.

Avoid vague promises such as "ongoing support". Ask for the response behavior you can verify, and agree on what is outside the agreement, such as new roles or new departments. If the vendor offers tiers of support, ask which tier matches the risk of the role, not the size of your company.

For a fuller picture of what recurring work looks like, the explainer on what managed AI services include lists the activities you can reasonably expect to see in a contract.

What should the contract say about data, access and exit?

A pilot often runs on test data and borrowed credentials. Production means real documents, real customer information and real accounts. The data and access terms must be tightened before that happens, not after.

Start with data. State what categories of company data the agent may process, where that data is stored, who at the vendor can see it, and whether any of it may be used to improve other systems. State how long conversation history and memory are kept and how deletion works, including backups. If you operate under a regulator or a data protection authority, add the obligations that follow from that, and have your own counsel confirm the wording.

Then access. Credentials should belong to your organization, be scoped to the minimum the role needs, and be revocable by you without the vendor's help. The [OWASP authorization guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) is a reliable reference for least privilege and for checking permissions on every request rather than once at login. Ask who holds administrative access on the vendor side and how that access is logged.

Finally, exit. A production contract that cannot be left cleanly is a dependency, not a service. Agree in advance on:

• Export of configuration, prompts, tool definitions, evaluation sets and memory in a usable format.
• Deletion of your data after exit, with written confirmation.
• A transition period in which the agent keeps running while you move.
• Documentation that a competent third party could follow.

The piece on avoiding AI vendor lock-in goes through these portability questions in more detail, and it applies to any provider, including us.

How should pricing and usage limits change?

Pilot pricing is usually shaped by the pilot: a fixed effort for a fixed period. Production usage is continuous and tends to grow, so the structure should be renegotiated to match. This is not about the number. It is about what the number covers and what happens when use rises or falls.

Ask the vendor to separate the parts of the service so that you can see what you are paying for: build and change work, recurring operations, and the underlying model and tool usage. The guide to AI agent pricing models compares usage, seat and retainer approaches and the trade-offs of each.

Then add controls:

• Usage limits and budget alerts, so a runaway process or a surge cannot produce a surprise.
• A named person who receives those alerts on your side.
• A review date at which the structure is revisited against actual use.
• A rule for how changes in underlying model costs are passed on, if they are.

It is also worth agreeing on a way to talk about value. The FinOps idea of [unit economics](https://www.finops.org/framework/capabilities/unit-economics/) is useful: relate cost to a unit the business understands, such as a completed request or a handled case, so that a conversation about spend becomes a conversation about output. That makes renewals less adversarial, which matters when you reach the point described in the article on renewing an AI services contract.

A renegotiation plan you can run in order

The following illustrative scenario shows the sequence. Imagine a regional distributor that ran a paid pilot of an agent helping its order desk answer status questions. The pilot contract covered a time period, a general description of support and a single shared login. The pilot went well, and the operations director wants to continue.

Her first move is to list what the pilot never defined: who watches the agent, who may change it, what data it holds and what happens if the distributor leaves. Those four items become the agenda for the production conversation. The rest follows the steps below.

• Step one: write the role in one paragraph and the success criterion in one sentence, and confirm both with the person who will own the agent after launch.
• Step two: inventory every system, credential and data source the pilot touched, and decide which ones continue, which are replaced and which are removed.
• Step three: replace shared logins with scoped credentials that your organization owns.
• Step four: draft the operating duties list (monitoring, evaluations, incidents, maintenance, permission review, changes) and ask the vendor to mark each as included, optional or excluded.
• Step five: agree on data handling, retention, deletion and the exit package in writing.
• Step six: restructure pricing around the separated components, with usage alerts and a review date.
• Step seven: set a short transition review, in which both sides check the first period of production against the contract and correct anything that does not match.

A sponsor on your side should own this process end to end. The article on the executive sponsor role explains what that person needs to be able to decide, and the article on what the first months look like helps set expectations for the transition review.

How does a managed approach handle this transition?

At Be Human, the first engagement defines one useful role, the memory and tools it needs, the approval boundaries and an observable success criterion. When that engagement moves into managed operations, those same definitions become the contract's scope, and the recurring work is listed as specific duties: monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements. Identity, memory, channels, tools and permissions stay under the client's control, and changes go through an approval step rather than being applied informally. Service is remote, in English and Portuguese.

Frequently asked questions

Should we sign a production contract right after the pilot ends? Only if the pilot met the success criterion you wrote at the start. If the evidence is mixed, extend the pilot with a narrower question or stop it cleanly, which the guide on pausing or stopping an AI pilot covers. Signing early to avoid a gap in service usually locks in problems you could still fix cheaply.

What is the single most overlooked term? Exit and portability. Teams focus on features and price, then discover that configuration, memory and evaluation sets are not exportable. Ask for the export format and deletion confirmation in the contract, before the agent holds months of accumulated context.

Do we need a different contract for each new role the agent takes on? Not necessarily a new contract, but each new role needs its own scope, permissions and success criterion, added through a defined change process. Treating each role as an addendum keeps responsibilities clear and lets you review roles independently. It also makes it easier to retire one role without disturbing the others.

Who should own the contract on our side? One accountable leader, usually the person whose function benefits most from the agent, with legal, security and finance consulted on their parts. A contract with no internal owner tends to drift, so name the owner and a backup in the document itself. If your company has no AI governance yet, a lightweight start is described in the article on AI governance for mid-sized companies.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.