Contracts, Ongoing Management, and Exit

A deployer holds real obligations under the AI Act, and almost none of them can be met without information held by the provider.

You must use the system in accordance with the instructions for use, which the provider writes. You must assign human oversight to people with the necessary competence, which requires knowing the system's limitations, which the provider documents. You must keep logs, which the provider generates and may host. You must report serious incidents, which requires recognising them, which requires knowing what normal behaviour looks like.

So the contract is not a formality appended to a technical decision. It is the mechanism by which you obtain the ability to comply.

This reverses the usual dynamic in software contracts, where the terms are largely about money, uptime and liability, and the substantive value is in the product. Here a substantial part of the value is contractual, because a good system supplied without information is a system you cannot lawfully operate in a high-risk context.

The corollary: negotiate these terms while you still have the leverage of not having chosen, which is before the implementation team has committed to a vendor rather than after.

The single most important clause states what the system is for.

The intended purpose is the anchor for the whole regulatory analysis. It is what the provider's conformity assessment was carried out against. It defines the boundary beyond which modification makes you the provider. It determines whether the accuracy claims hold, since they were established for that purpose.

So the contract should state the intended purpose as the provider declares it, and separately state your intended use, and the two should visibly match. Where your use is narrower, say so, because a narrower use is usually a safer position. Where it is broader, you have found the problem before deployment rather than after.

Two further clauses follow from it.

An obligation on the provider to notify you if the declared intended purpose changes, since that can change your position without any action on your side.

And an acknowledgment that use outside the declared purpose is your responsibility, which is not a concession but a clarification, because it makes visible in the contract what the Act already provides.

Organisations that skip this clause discover the boundary during an incident, which is the most expensive moment to learn where it was.

A cluster of clauses exists to guarantee the flow of information your own obligations depend on.

Provision and maintenance of the instructions for use, updated when the system changes, in a language you can use.

Supply of the information needed for human oversight, including limitations, known failure modes, and the technical measures that help interpret output.

Access to logs, with the retention period specified, and clarity on whether logs are yours or the provider's. Article 26 requires deployers to keep logs to the extent they are under their control, so if the provider hosts them, the contract is what brings them under your control.

Cooperation with authorities, so that when a market surveillance authority asks you something, the provider is contractually obliged to help rather than deciding case by case.

Support for a fundamental rights impact assessment where you must carry one out, since the assessment needs system information you do not hold.

And the right to audit or to receive evidence of continued compliance, proportionate to the risk.

The test for this cluster is simple. Walk through each of your deployer duties and ask what you need from the vendor to discharge it. Anything on that list which is not in the contract is a dependency on goodwill, and goodwill varies with account size and staff turnover.

The distinctive contractual problem with AI systems is that the product can change without any deployment on your side, and the change may be invisible until outcomes shift.

Three clauses address it.

Notification of material model changes in advance, with enough lead time to re-evaluate. Define material rather than leaving it to the provider, and anchor it to effects: any change expected to alter output distribution, accuracy, or behaviour on the populations you serve.

Notification of substantial modification in the AI Act sense, which is a narrower and more consequential category, because it triggers a new conformity assessment and can end a grandfathering position. A system you adopted on the basis that it predated the high-risk date loses that basis if the provider substantially modifies it.

And a right to re-evaluate after a material change, with a defined consequence if performance on your held-out set drops below the threshold from the previous lesson. Without a consequence the notification is a courtesy.

Many vendors resist advance notice on the grounds that they ship continuously. That is a real constraint and it is negotiable in form rather than substance: a version pin, a delayed rollout channel, or a commitment to notify for changes above a defined magnitude are all workable. A vendor unwilling to offer any of them is asking you to accept an unbounded change to a system you are accountable for.

The contract should make explicit who holds which duty, because the Act allocates by role and the roles can shift.

The provider side holds the requirements work, the technical documentation, the conformity assessment, CE marking, registration, post-market monitoring and serious incident reporting to authorities.

The deployer side holds use in accordance with instructions, human oversight assignment, input data relevance where it controls the input, monitoring, log retention, worker information, and a fundamental rights impact assessment where applicable.

The shared band in the middle is where disputes happen: incident recognition and escalation, information flow, and the determination of whether a change was substantial. Name an owner for each of these in the contract rather than leaving them to be worked out live.

And note the switch: branding, substantial modification, or repurposing moves you from the right column to the left, taking the whole provider set with it.

Two expectations are worth calibrating before negotiation, because both waste time.

Do not expect a performance warranty in the form you would want. Vendors will not warrant that a statistical system produces correct outputs, and the ones who would are the ones you should worry about. What is negotiable is narrower and still useful: a warranty that the system conforms to the declared specification in the instructions for use, that the accuracy figures were honestly measured on a described dataset, and that the provider has met its own obligations under the Act.

Do not expect indemnity for outcomes. A vendor will not indemnify you for a discrimination claim arising from a hiring decision you made using their tool, because the decision was yours. What is negotiable is indemnity for their own regulatory failures, for intellectual property claims arising from training data, and for breaches of data handling terms.

One clause worth pushing on specifically: a commitment that the vendor will not use your data to train models serving other customers, with the default set to off rather than opt-out. Defaults matter here more than the availability of a choice, because opt-outs are missed at renewal and by whoever configures the tenant.

And remember the liability cap is usually a fraction of the annual fee, while the harm from a badly performing decision system falls on people rather than on the contract. Sizing your own controls to the cap rather than to the harm is a category error.

Procurement does not end at signature, and the specific thing to watch for is drift: performance degrading as the world moves away from the conditions the system was evaluated under.

Four things to instrument.

Outcome distribution over time. If the proportion of applications the system scores highly shifts without a corresponding change in the applicant pool, something moved.

Disaggregated performance, re-measured periodically against the baseline captured during evaluation. This is why that baseline mattered, and re-measuring is only possible if you retained the ability to label outcomes.

Override rate, per reviewer and in aggregate. A falling override rate may mean the system improved, and may mean reviewers stopped looking. Both readings are worth investigating, and only sampling the decisions distinguishes them.

And complaints or challenges from affected people, which are the leading indicator that reaches you from outside the system.

Set a review cadence proportionate to consequence, and a defined trigger for re-evaluation: a material model change, a shift beyond a threshold in any of the above, or an incident.

The deployer's monitoring duty and the provider's post-market monitoring meet here. You are obliged to inform them of risks and serious incidents, and their monitoring depends on that flow, which is why the reporting channel belongs in the contract rather than in a support queue.

When something goes wrong, the provider is the one holding the technical facts and you are the one holding the affected person, so the arrangements have to be agreed in advance.

The provider's obligation to report serious incidents to market surveillance authorities runs on tiered deadlines: 15 days generally, 10 days where a death occurred, and 2 days for a widespread infringement or a serious and irreversible disruption of critical infrastructure. Those clocks start when the provider becomes aware.

Which means your recognition and escalation is the practical start of the chain. A deployer who takes four days to tell the provider has consumed most of a 2-day deadline before the provider knew there was one.

So the contract should specify a notification channel and timeframe from you to them, a reciprocal obligation to inform you of incidents affecting the system elsewhere, including at other customers, and a commitment to provide technical analysis for your own records.

Agree in advance who speaks to affected individuals and who speaks to authorities, because both conversations start at once and both go badly if improvised.

And note the parallel clock: where personal data is involved, the GDPR breach timeline runs on its own, shorter schedule. Deciding which regime applies during an incident is how deadlines get missed, so make that determination part of the escalation runbook rather than part of the incident.

Exit terms are negotiated at the start, when you have leverage, and used at the end, when you have none.

Four provisions.

Data return and deletion: your input data and the outputs, in a usable format, with deletion confirmed within a defined period, extending to backups and to subprocessors.

The model question: where the vendor trained or fine-tuned on your data, what happens to that model. Frequently the honest answer is that your data cannot be extracted from trained weights, which is a reason to have restricted training use in the first place rather than to rely on deletion at the end.

Transition assistance for a defined period, since a decision system embedded in an operational process cannot be switched off on a Friday.

And continued access to logs covering the period of use, because your retention obligation survives the contract. This one is routinely missed, and terminating a contract can otherwise put you in breach of a duty you still hold.

The deeper exit question is dependency. A system that has reshaped a process around itself is expensive to leave regardless of the terms, and where an alternative does not exist the exit clause is decorative. Where the decision matters and switching is implausible, that dependency is itself a risk for the register from the governance cursus, and it belongs there rather than being noticed at renewal.

Three lessons reduce to one idea: a deployer's position is derivative, so almost everything depends on what you established before signing.

Scoping decided your role and your risk tier, and those two determinations drive the cost of everything downstream.

Diligence produced the measured baseline, the documented limitations and the recorded reasoning, which are the inputs to oversight design, drift detection and the governance record.

The contract secured the information flow your own obligations depend on, and the change notification without which the system you evaluated and the system you run may diverge.

None of the three can be recovered later at the same price. A role assessment made after deployment is a defence rather than a decision. A baseline not captured cannot be reconstructed once the system is live. And terms not negotiated before selection are terms you are asking for as a customer rather than as a prospect.

The practical summary for an organisation buying AI: the leverage is entirely front-loaded, the obligations are entirely back-loaded, and closing that gap is what procurement diligence is for.