Renewing an AI Services Contract: What to Review First

To renew an AI services contract well, review what the service actually did during the term before you discuss what the next term should include. Collect usage evidence, incident records, scope changes, data terms and exit options, in that order, and bring them to the renewal conversation. Start well before the notice date, so you still have the option to renew, change, narrow or leave.

Key takeaways

• Evidence comes first. A renewal conversation without usage and quality records is a negotiation about opinions.
• Incidents and near misses show how a provider behaves under pressure, which a sales presentation cannot.
• Scope usually drifts during a term. Compare what is written with what is running, and write the difference down.
• Data terms (training, retention, location, subprocessors, deletion) deserve a fresh read, because the service now holds more of your context than when you signed.
• Confirm you can leave. Test an export of memory, configuration and documentation before you commit to another term.

Why is renewal a decision and not an administrative step?

Most AI services contracts are signed at the start of an experiment. The wording reflects what everyone hoped the service would do, a rough guess at usage, and a data arrangement that seemed adequate when the agent had little access. A term later, the agent may be part of daily work, hold months of accumulated memory, and touch systems nobody listed at signing.

Renewal is the one moment when you have both leverage and information. You have a record of what happened, and the provider wants to continue. An automatic renewal clause quietly removes that moment: if the notice date passes, the old text carries forward, including assumptions that no longer hold.

Before you read any new proposal, find three things: the notice date and the way notice must be given, the current statement of work, and the name of the person inside your company who owns the relationship. If nobody owns it, assign someone now. Also note which stage the service is in. Terms written for a proof of concept rarely suit a service that people depend on every day.

What usage evidence should you collect first?

Usage evidence answers one question: did the service do the job you hired it for? Pull it from two places. The provider's monitoring shows volume and reliability. Your own team shows whether the output was good enough to use.

Gather these items:

• The success criterion written at the start, and the current reading against it
• Volume of tasks handled, by type and by channel
• Active users, and how that group changed over the term
• A sample of outputs reviewed by the person who owns the process, including outputs that were corrected or discarded
• Time to finish the work with and without the agent, as best your team can state it
• Spend compared with what you expected, expressed per completed task rather than as a single total

The last item matters more than it looks. A total tells you what you paid. A cost per completed outcome tells you whether continuing is sensible, and it is the core idea behind unit economics as practiced in cloud financial management.

Be careful with adoption figures on their own. Many people logging in does not show that work improved. If you review the agent like a role, with goals, evidence, feedback and changes, you get a cleaner picture than activity counts can give.

Where evidence is missing, record the gap. A gap is a finding in itself: it tells you what to require the provider to record in the next term.

Which incidents and near misses belong in the review?

An incident is anything that caused a wrong action, an exposure of data, an outage, a failed integration or a message that reached the wrong person. A near miss is something an approval step caught, or something you noticed late and luckily without harm. Both belong in the review, because near misses show where the guardrails were doing real work.

For each event, ask the provider and your own team the same questions:

• What happened, and what was the effect on your work or your customers?
• Who found it, you or the provider?
• How long did it take to acknowledge, contain and explain?
• What was changed afterward, and is the change documented?
• Has something similar happened again?

The second question is revealing. A provider that tells you about problems before you notice them is giving you something no uptime claim can. A provider whose records are thin, or who cannot reconstruct what happened, is telling you something too.

Also include incidents on your side: a person who pasted sensitive material into the wrong channel, or a workflow that relied on the agent without anyone checking it. A shared risk framework such as the NIST AI Risk Management Framework can help you sort events into categories, so patterns become visible rather than anecdotal. The goal is not a perfect record. It is a clear view of what the next term needs to prevent.

How do you check whether the scope has drifted?

Scope drift is normal. A team asks the agent for one more task, someone connects a new folder, a manager adds a colleague to the channel. Each step seems small. At renewal, you need to compare three versions of reality: what the contract says, what the agent is configured to do, and what your staff believe it does.

List and compare these elements:

• Tasks the agent performs, and tasks it was asked to avoid
• Channels it answers on
• Tools and systems it can read from or write to
• Permissions attached to each tool
• People who can instruct it
• Approval boundaries, meaning which actions need a human to confirm
• Data sources feeding its memory

Any difference is a decision to make: write it into the contract, remove it, or restrict it. A structured permission review is the cleanest way to settle the permission side, and it should happen before you sign, not after.

Illustrative scenario: a company signed for an agent that answers supplier questions by email. During the term, the team also connected it to a shared drive and began asking it, through chat, to draft purchase summaries. At renewal, the contract still describes only email. The review finds two tasks with no written approval and a drive permission that nobody has reviewed. The company renews, but with the new tasks written in, the drive access narrowed to the folders the work needs, and a named owner for each task.

That outcome is better than either extreme. The company did not discard useful work, and it did not leave undocumented access in place.

Which data terms deserve a second read?

The service now holds more of your information than when you signed. It may keep conversation history, summaries, documents and learned preferences. That makes the data terms worth reading again, with current facts in hand rather than the assumptions of the first week.

Check these points, and involve legal counsel for anything that carries regulatory weight:

• Whether your data or the agent's logs can be used to train models, and whether that is stated in writing. The article on whether your AI provider trains on company data explains what to ask for.
• How long data is retained, and what happens to backups
• Where data is stored and processed, and whether that changed
• Which subprocessors are involved, and whether the list changed since signing
• Who on the provider side can access your data, and how that access is logged
• How breaches are notified, and within what commitments
• How deletion is requested and confirmed at the end of the term

Watch for terms that changed through updates to policies or addenda rather than through a renewal document. Providers sometimes revise terms by notice, and the renewal is your chance to confirm which version applies.

Also compare the contract with how your company actually uses the service. If staff share customer records with the agent but the agreement was written for internal documents only, the data terms may no longer fit the work.

What exit options should be in place before you sign again?

Nobody enjoys planning an exit while renewing, which is why it gets skipped. Yet the strength of your position in every future negotiation depends on whether leaving is a credible option. If you cannot leave without losing months of accumulated work, you are negotiating from a weak position.

Confirm what you would receive at the end of the contract:

• The agent's instructions, configuration and tool definitions in a readable format
• The memory and knowledge it has built, in a form another system could use
• Evaluation sets and test cases used to judge quality
• Documentation of integrations, including who holds the accounts and credentials
• Logs and records you need for your own audit or compliance obligations
• Reasonable transition help for a defined period
• Written confirmation that your data is deleted afterward

Then test it. Ask for a sample export now, while the relationship is healthy, and check whether someone other than the provider can make sense of it. A promise of portability is worth less than an export you have opened. The article on avoiding AI vendor lock-in goes deeper on what to hold in your own hands.

If the exit picture is unclear, that is a reason to choose a shorter term or to add a review point partway through, rather than a reason to postpone the question.

What is a practical renewal plan, step by step?

Use this sequence. It keeps the review ordered, so the proposal does not set the agenda.

• Step one: find the notice date, confirm how notice must be given, and name one owner for the review.
• Step two: request records from the provider, including usage reports, the incident log, the change history, the subprocessor list and the current configuration.
• Step three: collect your own evidence, including output samples from the process owner, feedback from users, and cost per completed outcome.
• Step four: compare the contract, the configuration and daily practice, and list every difference in scope and permissions.
• Step five: re-read the data terms and request a sample export to test your exit.
• Step six: decide among four options: renew as is, renew with changes, renew for a shorter term, or leave.
• Step seven: write the agreed changes into the document, including approval boundaries, reporting duties and exit terms, before anyone signs.

In Be Human's managed approach, much of this evidence already exists before renewal comes up. Managed operations can include monitoring, recurring evaluations, integration maintenance, permission review and incident response, and each of these leaves a record the client can read during the term. Changes follow approval boundaries the client controls, so the scope on paper and the scope in production are meant to match. A renewal conversation then starts from records both sides already share, not from reconstruction.

Frequently asked questions

When should we start reviewing an AI services contract before it renews? Start well before the notice date in the contract, because collecting evidence and negotiating changes both take time. If notice must be given in writing, add margin for internal approvals. Starting early keeps every option open, including leaving.

Should we renew for the same term length? Not necessarily. If scope is still shifting or the exit path is unclear, a shorter term or a mid-term review point gives you room to adjust. If usage is stable, incidents are rare and exports have been tested, a longer term is easier to justify.

What if the provider cannot supply usage or incident records? Treat that as a significant finding and ask for the records to be produced as a condition of renewing. Without them you cannot judge value or risk, and you will face the same blindness next year. Reporting duties, such as a regular usage summary and an incident log, can be written into the new term.

Is it better to switch providers than to renew? It depends on what the evidence shows, not on how long you have been with the provider. If the service meets its success criterion, handles incidents openly and lets you export your work, renewal with updated terms is usually simpler. If those things are missing, use the exit options you have verified and compare alternatives against the same checklist.

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