Contract with an AI provider: what to check
AI project contracts: what to clarify about code ownership, data, support, liability and compliance before signing with your technology supplier.
Reading time: 9 min
The contract of an AI project has some specificities that traditional development contracts do not address: dependence on changing third-party services, data leaving the company, responsibility on automatically generated outputs.
They are points that close easily before signing and with a lot of difficulty after. This is the list of those that really matter.
In summary
- Properties of code and data: to write, not to presume.
- The credentials services should be registered to your company.
- We need the agreement on processing if the provider processes personal data.
- It must be distinguished what is maintenance and what evolution.
- They should be provided for Model Updates that change behavior.
- Readable documentation: this is what makes it possible to change providers.
The Seven Points to Close
- Code Properties. Who owns what is being made, and with what rights of use.
- Ownership and return of data. In what format, by when, with deletion from the supplier's systems.
- Credentials and accounts. Headed to your company, not the supplier.
- Documentation. Readable by those who did not write it, delivered at closing.
- Assistance. What's included, however, with what times, what it costs next.
- Maintenance and evolution. The distinction should be defined, even roughly.
- Compliance. System classification, written instructions of use, reporting of relevant changes.
Point 3 is what companies discover late: if the AI service account is in the name of the provider, changing partners means losing access and configurations. It is a simple request that no one rejects if posted at the beginning.
The Specificity of Changing Models
It is the point that distinguishes an AI contract from a classic development contract.
The services underlying the system — the models — are updated by their providers, sometimes without notice. The system’s behaviour can change from one day to the next: different responses, different formats and occasionally new errors.
- Who monitors that behavior has not changed
- What happens if an update worsens your case results
- If the provider notifies you when the underlying model changes
- Who pays the adjustment in these cases
These are questions that do not exist in traditional contracts, and that must be asked here. The answer does not have to be favorable to you: it must be there.
Responsibility and Compliance
If the system touches decisions on persons or falls within the high-risk ones, the obligations are shared between the supplier and the user — the distinction is in AI Act obligations for SMEs.
In the contract it must be clarified who does what:
| Appearance | Normally | To be verified |
|---|---|---|
| Technical documentation of the system | Supplier | Let it be delivered |
| Written instructions for use | Supplier | That they are understandable |
| Proper System Usage | User | Let the instructions be there |
| Human Surveillance | User | That it is practicable |
| Personal data processing | Both | Formalised Agreement |
The agreement on data processing is the one most often forgotten and the first one that is asked in case of verification. The framework is in GDPR and AI in the company.
Practical examples
Credentials in the name of the supplier. One company wanted to switch partners after two years and found that the AI service account, with all the configuration, was from the previous provider. Reconstruction from scratch.
No definition of maintenance. Every small change has become a negotiation. The relationship has deteriorated on issues from a few hours of work.
Unmanaged model update. A data extraction system started producing different results after an upstream update. No one noticed for weeks because no one was tasked with checking, and the contract did not provide for it.
What happens at the end of the relationship
It is the part that no one wants to discuss at first and that determines how free you are afterwards.
An AI project integrated into the processes becomes something you depend on. If at the time of switching providers you find that the code is not yours, that the documentation does not exist and that the accounts are registered to them, the choice is no longer yours.
- Code and configurations delivered in usable form.
- Documentation understandable by a technician who has not worked on the project.
- Credentials Headed to you, transferred to closing.
- Data returned in standard format and deleted from their systems.
- A period of flanking to those who take over, even short.
Point 5 costs little and is worth a lot: a few hours of handover avoids weeks of rebuilding. It must be negotiated at the beginning, when the relationship is good, not at the end when it is often no longer so.
The confidentiality clause, in the two senses
Contracts normally require the supplier to keep company information confidential. In AI projects it is worth being more specific, because the provider will have access to operational data in quantity.
It should be clarified whether your data can be used to improve their systems or as reference material for other customers, including in aggregate or anonymized form. Many standard contracts allow it with generic formulations, and it is a point worth being explicit about — especially if the data is about your way of working, which is a competitive asset.
The seven points in the table
| Point | If Missing | Difficulty getting it after |
|---|---|---|
| Code Properties | You can't change partners | High |
| Property and data return | Migration blocked | High |
| Credentials made out to you | Lose access and configurations | Very high |
| Readable documentation | No one can take over | High |
| Defined assistance | Negotiation at first failure | Medium |
| Maintenance vs. evolution | Continuous friction | Medium |
| Compliance and instructions for use | Obligations discovered late | Medium |
Mistakes to Avoid
- Not clarifying code ownership. You get it sooner, not later.
- Credentials in the name of the supplier. It blocks the change of partners.
- No definition of maintenance. It generates constant friction.
- Ignoring model updates. It is the specificity of these projects.
- Not requesting the personal data agreement. Fulfillment due.
- Accepting unreadable "technical" documentation. It must serve those who take over.
How to apply it in the company
Take this list of seven points and check it out on the contract you were offered. The missing ones ask for them: they are all reasonable requests that a serious supplier grants without question.
If on two or three of these points you encounter resistance, it is information about the relationship you are about to begin, more useful than any reference.
As these are aspects with legal implications, let them assist for the final draft: this guide serves to know what to ask, it does not replace an opinion.
The criteria of choice are in how to choose an AI provider, recurring costs in how much it costs to maintain an AI system.
A proportionate contract
It must be said to avoid the opposite effect: a contained project does not need a complex contract.
The seven points listed can be closed on a page additional to the commercial proposal, with simple formulations. The goal is not to protect yourself from any scenario, but to avoid the three situations that really arise: not being able to change providers, not knowing who pays for maintenance, not having data agreement when someone asks for it.
A contractual apparatus disproportionate to the value of the project slows down the start and does not add real protection. Better a clear page agreed quickly than twenty pages that delay the work by a month.
The criteria for choosing the right supplier are in how to choose an AI provider.
The case of small projects
For a first contained project the temptation is to completely skip the contractual part, and in part it is understandable: a heavy apparatus on a job of a few thousand euros is disproportionate.
The middle way is a page attached to the proposal that closes three points only: who the code is, who the credentials are registered to, what is included in the first months after release. They are the three situations that really present themselves and that, if not solved before, become problems at uncomfortable times.
The other four points —data restitution, documentation, maintenance-evolution distinction, compliance —become relevant as the project grows, and can be addressed at the second stage. The criterion is proportionality, not formal completeness, and also applies to the choice described in how to choose an AI provider.
Conclusion
A contract for an AI project must close seven points: code, data, credentials, documentation, assistance, maintenance-evolution distinction, compliance.
These are all points that are easily negotiated before signing. The time when they really need them una change of supplier, a failure, a verification.is also the time when it is too late to negotiate them.
If you want to understand what processes in your company can be automated with AI, Giallo Studio can help you turn the problem into a real workflow.
One last balance note: these points serve to protect both sides, not just you. A supplier who works with clear rules about perimeter, assistance and evolution manages to better size their work, and the relationships that last over time are those in which no one has to interpret what was included. The framework of choice criteria is in how to choose an AI provider.
Giallo Studio guides: methodology and sources
How we apply it in the company
Related resources
FAQ
Who owns the code in a custom AI project?
Whoever the contract says owns it; without clauses, the situation may be less favourable than you imagine. This is a point to clarify before signing: it is easy to secure during negotiations and difficult afterwards.
What happens to data if I change providers?
It should be written: that the data is yours, that it is returned to you in a usable format, and that it is deleted from the supplier's systems within a period. Without these clauses the transition to another partner becomes complicated or impossible.
Do we need an agreement on the processing of personal data?
If the provider processes personal data on your behalf, yes: it is a requirement under the GDPR and must be formalized. Many providers have a ready-made template; it must be requested, read and stored, not taken for granted.
Who is liable if the system causes damage?
It depends on what caused the damage and how liability is allocated in the contract. A defect in the supplied system is the provider's responsibility; use outside the instructions is yours. That is exactly why instructions for use must be delivered in writing.
What to ask about regulatory compliance?
That the provider states how it classifies the system under the AI Act, provides written instructions for use if the system is high-risk, and flags any update that materially changes the system’s behaviour.
Should the contract specify what happens if the provider closes down?
Yes, and it is a clause that is easy to obtain when the relationship is good. At a minimum, the code and documentation must belong to you and be accessible, so that another provider can take over without rebuilding everything from scratch.