Artificial intelligence
The clause your supplier contract does not contain
Your contract describes a service: availability, support, price. It almost never says what the supplier is allowed to do with your data.
An accountancy practice in Algiers signs for a tool that reads incoming invoices and extracts the amounts. The contract runs to eleven pages. It describes availability, support, termination, price. On what the supplier may do with the invoices themselves, it says one sentence, and that sentence is a general promise of confidentiality.
That is the usual shape, and it is insufficient for a precise reason: the law does not ask the supplier to be discreet, it asks you to define what they do. For an artificial intelligence project, where the supplier receives the content and not only the metadata, the gap between those two formulations is the whole subject.
This article gives the clauses one by one, with what each prevents and what a supplier will negotiate. It does not re-establish that a subcontractor exists — the subcontractor behind your supplier is covered elsewhere — it writes what has to be in the contract once you know.
Your contract describes a service, not a processing activity
Open the contract you signed for your last tool and search for the word “data”. You will find it three times: in a general confidentiality clause, in an ownership clause saying your data remains yours, and in a backup clause. None of the three says what the supplier does with that data.
The difference is between a promise about behaviour and a definition of scope. “We treat your data confidentially” is a promise; “we process your data solely to carry out the instructions described in the annex, and for nothing else” is a scope. The first can be honoured sincerely while doing exactly what the second forbids.
The commonest concrete case is product improvement. A supplier who uses your exchanges to improve their product breaches no confidentiality promise: they disclose nothing. They nonetheless carry out processing you did not authorise, for a purpose that is not yours.
The practical consequence is that a service contract is not completed by a sentence. It is completed by an annex describing the processing, and that annex is the same information your register already holds — which makes the work far lighter than it looks.
What the law requires of a processing contract
Law 18-07 of 10 June 2018 handles the subject in three short articles. Article 38 puts technical and organisational security measures on you. Article 40 imposes a confidentiality obligation that survives the end of the role. And article 39 is the one that decides the shape of the contract.
It sets two requirements. The first is about the choice: the controller must select a processor offering “sufficient guarantees inherent in the technical and organisational security measures”, and must ensure those measures are respected. Choosing is therefore not only signing, it is verifying — and a verification that left no trace did not happen.
The second is about the instrument: the relationship “must be governed by a contract or legal act binding the processor to the controller”, and that act must provide that “the processor acts only under the sole instruction of the controller and in compliance with legal obligations”. That sentence is short and it is the heart of everything that follows.
The above describes the state of a regulation as at 21 August 2026 and does not replace a lawyer’s advice. Law 25-11 of 24 July 2025 adds a reinforcement of the expected clauses — security, confidentiality, reversibility, incident notification, localisation — and places a register obligation on the processor as well, kept available to the authority.
The instruction clause: the shortest sentence and the heaviest
“The processor acts only on the controller’s documented instruction.” A handful of words, and they reverse the burden of proof. Without them the question becomes “was the supplier entitled to” and gets argued; with them the question becomes “where is the instruction”, and it is either answered or it is not.
The word doing the work is “documented”. A spoken instruction exists and cannot be proved; a written one is a document either party can produce. In practice the processing annex *is* the instruction: it describes what the supplier does, and anything not in it is not instructed.
The consequence businesses do not anticipate is that the annex then has to be maintained. Adding a feature that processes the data differently — summarising instead of extracting, classifying instead of summarising — requires updating the annex, and that is an exchange of emails rather than a contract amendment.
A supplier will rarely negotiate this clause, because it protects them too. A provider executing a documented instruction is within their role; a provider improvising carries a responsibility they did not want. It is the clause obtained most easily, and it is the most useful.
The purpose clause: use for anything else
This is the clause that handles product improvement, and it has to be written positively and negatively. Positively: the supplier processes the data solely for the purposes described in the annex. Negatively: they do not use it to train, tune or evaluate a model, nor to build a dataset, nor to produce statistics outside your scope.
Both formulations are needed because the first alone leaves a door open. “Solely for the purposes described” can be read as covering whatever serves to deliver the service, and improving the model serves to deliver the service. The second formulation closes that reading by naming the act rather than its justification.
What the supplier will negotiate here is aggregate statistics, and it is often a reasonable concession: counting requests, measuring response times, knowing error rates. The line to hold is that the aggregate must not be reducible to a person or to your business, and that gets written down.
One caution specific to this market: many suppliers handle this question with an account setting rather than a clause. A setting can be changed, including by mistake, and it does not bind them contractually. Ask for the clause, switch on the setting, and note the date you did.
The localisation clause: where, and who tells you
It names the country or region where the data is processed and stored, and forbids changing it without your prior written agreement. The second half matters more than the first: a supplier can move a workload from one region to another for entirely legitimate technical reasons, and you will learn about it by reading their status page.
This clause is what makes your “what leaves the country” column hold over time. The register describes what you do today; without a contractual commitment on localisation, it describes what you did on the day you wrote it.
The supplier will negotiate the notice period rather than the principle. Thirty days is a reasonable and defensible ask; a “reasonable” notice with no duration is a clause that says nothing. If the supplier cannot commit to a duration, they have just told you something useful about how well they control their own infrastructure.
Backups have to be covered too, and they often escape the main clause. Data processed in one region and backed up in another has left the country just the same, and it is the line technical annexes forget most regularly.
Onward subcontracting: knowing, and being able to object
Your supplier uses others: whoever runs the model, whoever hosts, sometimes whoever transcribes. The clause must provide three things, and the order matters: an up-to-date list of onward processors, prior notice before adding one, and a right to object within a stated period.
The third is the one that gets lost. Many contracts grant notice and not objection, which leaves you knowing without being able to act. A right to object with no consequence is not one either: it has to be backed by a right to terminate without penalty if the objection is not followed.
What the supplier will negotiate is granularity. They will rarely agree to submit every change of regional host to you and will often agree to name the companies that actually process the content. That is the right line to hold: the list must cover who sees the data, not who supplies cable.
Finally, the same obligations must be required to flow down. A clause that protects you from your supplier and does not oblige them to impose the same on the next one stops at the first link, and the supplier behind the supplier is precisely the one you did not choose.
The security clause: describe rather than promise
Article 38 puts the technical and organisational measures on you, and article 39 asks you to ensure your processor respects them. A clause saying “the provider implements appropriate measures” lets you ensure nothing.
What is verifiable amounts to four things: encryption in transit and at rest, access management at the supplier — who, how many people, under what control — the retention period of their logs, and the existence of an audit or certification you can ask to see. The last is the only one that produces a document.
The supplier will negotiate the audit right, and legitimately: nobody can host every customer on their premises. The usual counterpart is disclosure of a third-party audit report, and it is enough in the great majority of cases — provided the clause says at what frequency and within what deadline, failing which the report is three years old.
One precaution costing a sentence: ask that the described measures cannot be reduced during the contract without prior notice. Without it the description is a photograph of the day of signature, and nothing obliges the supplier to keep it true.
The incident clause: their deadline must be shorter than yours
This is the most frequently absent clause and the most mechanically necessary. Your obligation to notify the authority runs in days from the moment you become aware of a breach. If the breach happens at your supplier, they learn of it first, and your clock starts when they tell you.
A simple arithmetic constraint follows: the deadline you impose on the supplier has to be clearly shorter than the one the law imposes on you, or you have handed your deadline to somebody with no reason to hurry. Twenty-four hours is a common and workable ask; “as soon as reasonably possible” is not.
The content of the notification matters as much as its speed. An alert saying “a security incident has occurred” lets you investigate nothing. The clause must require the nature of the incident, the categories of data involved, an estimate of the number of people, and the measures taken — which is exactly what you will have to pass to the authority.
Add an obligation to cooperate, in one sentence, or you will get a notification and nothing after it. The fourth document an inspection asks for is the trace of what was notified and what was done, and the second half is built from information held at the supplier.
Reversibility: get it back, then have it deleted
Two distinct obligations that contracts merge into one: returning your data in a usable format, and then deleting it, including at onward processors and in backups. A contract providing for return and not deletion leaves you with a copy at somebody you no longer pay.
The format is the technical part and it settles in one line: an open, documented format readable without the supplier’s tool. An export in a proprietary format is a return that obliges you to buy the tool again to read your own data.
Deletion is the part that needs proof. Ask for a written attestation, dated, explicitly covering backups according to their rotation cycle — a backup rotates over thirty or sixty days, and a deletion announced on the day of termination cannot be true before the end of that cycle. A serious supplier will say so themselves.
This clause also weighs at the moment of choosing. A supplier who accepts precise reversibility is one who believes they can keep you other than by holding on to you, and that is a signal about the rest of the contract — what to check before signing follows the same logic on a custom development.
The model paragraph, and what a supplier will take out of it
Here is what we put in our own contracts, to give to your counsel rather than to copy as it stands: “The provider processes personal data solely on the client’s documented instruction, for the purposes described in annex 1 alone, and uses it for no other purpose, in particular not to train, tune or evaluate a model. The data is processed and stored in the locations listed in annex 2, backups included; any change is subject to thirty days’ prior written notice, giving the client a right to object and, failing a response, a right to terminate without penalty.”
The rest fits in three sentences: “The provider maintains an up-to-date list of its onward processors in annex 3 and imposes equivalent obligations on them by contract. It notifies the client of any data breach within twenty-four hours of becoming aware of it, stating the nature of the breach, the categories and estimated volume of data involved, and the measures taken. On expiry of the contract it returns the data in an open, documented format, then deletes it, backups included, and issues a written attestation to that effect.”
What a supplier will remove first, in the order we have seen it happen: the thirty days becomes “reasonable”, the twenty-four hours becomes seventy-two, the right to terminate without penalty becomes a right to object with no consequence, and the deletion attestation becomes a statement of general policy. Each of those four retreats empties a clause while leaving it in the contract.
This paragraph is a starting point for a legal discussion, not a template to sign. It is written for ordinary processing, it covers neither sensitive data nor the case of a supplier established abroad, and it relieves you of none of the other obligations — the full framework, from the register to transfer is elsewhere and is not written into a contract.
The one-hour review, to run this week
Get out the contracts for your three main tools that touch data about people. Not all of them: the three that matter most. Open each and search for five words, in this order: “instruction”, “purpose”, “location”, “subcontractor”, “breach”.
Note for each whether it appears, and whether it appears in a sentence that binds the other party or in one that describes an intention. “The provider undertakes to” and “the provider endeavours to” are two different things, and the second is the more common.
The result fits on one sheet: three columns, five rows, yes and no. In the reviews we run, the “breach” row is empty in the great majority of contracts, and the “location” row is present without a notice commitment about as often.
That sheet is directly your priority order for the next renegotiation, and it has another immediate use: it tells you which of your suppliers you could not honestly describe in your register. It is an hour, it is done without us, and it needs no legal training.
What we do, and what we refuse
We run the review above, write the technical annex — what the tool processes, which fields, to which locations, with what retention — and prepare the list of questions to put to the supplier before signing. That is the part where the difficulty is knowing what to ask, and it is a technical skill before it is a legal one.
We also test the commitments rather than reading them. A supplier promising an export in an open format can prove it in thirty minutes; a supplier announcing notification within twenty-four hours has a channel, a recipient and a format, or they do not. Those checks are made before signing and almost nobody asks for them.
We do not draft your contract and we do not approve the one put in front of you. Drafting a clause that binds you is a lawyer’s act, and a technical supplier who takes it on leaves you with a text nobody qualified has read and for which they do not answer. We supply the material; your counsel writes.
And we refuse to place ourselves in a contract where we would be both the integrator and the judge of the compliance of a supplier we recommended. If we proposed the tool, have the clause read by somebody other than us — it is the only honest position available to us, and it regularly costs us the review work.
Frequently asked questions
Will a foreign supplier agree to change its contract?
Rarely the master agreement, often an annex. Large suppliers publish a data processing addendum you simply accept, and it covers half of what is described here; smaller suppliers genuinely negotiate. In both cases the first question to ask is about onward processors, because it is the answer that tells you fastest who you are dealing with.
What if the supplier refuses everything?
That is information about the supplier and not only about the contract, and it is worth taking seriously. A provider who cannot commit on localisation does not control it; a provider refusing a numbered notification deadline has no internal procedure. The refusal is sometimes the most useful thing to come out of the negotiation.
Are we responsible if the supplier is at fault?
Responsibility for the processing stays with the business that collected the data, and the contract organises recourse between the two of you rather than relieving you. That is exactly why the selection clause matters: article 39 asks you to choose a processor offering sufficient guarantees, and a verification that left no trace is hard to rely on later.
Separate annex or everything in the contract?
An annex, for a practical reason: it describes processing that evolves, and an annex is updated by written exchange whereas a contract is changed by amendment. It is also the same information your register already holds, which makes drafting far quicker than it looks.
What about a tool used with no contract, self-service?
The terms and conditions are the contract, and they generally say the opposite of what is described here: data used to improve the service, no guaranteed localisation, no notification commitment. That is not a legal vacuum, it is a contract you accepted without reading, and the question becomes whether that processing can honestly appear in your register.
Is this model paragraph enough?
No, and it is not written to be. It covers ordinary processing, it handles neither sensitive data nor a supplier established outside the country, and it replaces neither the transfer authorisation nor the rest of your obligations. It is a starting point to give to a lawyer, and it is here because a clause described without being written helps nobody.
Where we come in
Five words searched across three contracts give fifteen boxes. It is the empty ones on the “breach” row that decide the next renegotiation.
- We put your main contracts through the five-word sieve and hand back the sheet filled in.
- We draft the technical annex: activities, fields, locations, retention, actual recipients.
- We test the commitments before signature — an export that is genuinely open, a notification channel that exists.
Writing the text belongs to a lawyer, and where the tool came from us, a third party has to review its commitments — not us.
Read next
Plugging AI into what you already have
These projects fail on the connection, not the model. What to inventory before signing, and where to put the seam.Two systems that never quite agree
An integration that runs is not an integration that is correct. What to put in place the day the two sides start to diverge.Paying an AI supplier from Algeria
The project is scoped, the team is ready, and the card is declined. That is not a fault: it is the service-import regime.
Let us talk about your project
A free audit, no commitment: we look at your online presence and tell you what is holding it back.