Terms of service do not give an AI agent a GDPR lawful basis for every step

Your product has an AI assistant, and a user types one sentence into it: "Find a time next week for a call with Maria and send her an invite." The agent reads the user's calendar, searches their inbox for Maria's last email to find her address and time zone, sends her the invite, and saves a note that Maria prefers mornings so the next request goes faster. Your platform also keeps the run to improve the agent. The user asked for one thing, and the agent processed personal data in five steps, four of which involve Maria, who has never heard of your product.

When a customer's privacy reviewer, or a regulator, asks which lawful basis covers each of those steps, "it is in our terms" is no longer an answer. On 8 October 2026 the UK's data protection regulator, the ICO, wrote that "a user's instruction to an agent doesn't automatically provide a lawful basis for all the processing that follows", and neither do your terms of service 2. The contract basis covers only the steps that are objectively necessary to do what the user asked, and only for the user's own data, and EU courts and regulators read it the same way. Every other step needs another basis, usually legitimate interests backed by a written assessment. A step with no basis at all is unlawful processing, in the top tier of GDPR fines 11.

The ICO's text is a public consultation, called a call for evidence, that sets out its "current thinking" on AI agents 1 with a closing date for comments of 20 November 2026 13. It creates no new law, but the UK GDPR it applies is in force today (the ICO's announcement). If you sell to businesses, your customer usually picks the bases, and the B2B section below explains why you should still write the step list yourself.

When does "necessary for a contract" cover a step?

When two conditions hold. The person whose data it is must be party to the contract, and the step must be objectively necessary to deliver what that person asked for.

The first condition is in the text of the law. Article 6(1)(b) allows processing "necessary for the performance of a contract to which the data subject is party" 5. The ICO's guidance on the contract basis says it "does not apply if you need to process one person's details but the contract is with someone else" 6. Maria has no contract with you, so for her data this basis is not available, however necessary the step is.

The second condition is where most agent steps fail. The ICO says the contract basis "only applies where data handling is objectively necessary to provide the service requested by the person" 2. The EU reads it the same way. In a 2023 judgment on how Meta justified its data processing for Facebook, the Court of Justice of the EU, the EU's highest court, held that the processing must be "objectively indispensable for a purpose that is integral to the contractual obligation", and that it is irrelevant that the processing is mentioned in the contract or "merely useful" for it 7.

For an agent, I take the service the user requested to be the task they typed. A step the agent chose because it was useful, such as remembering something for later, falls outside it.

Which steps of an agent run need a different basis?

Run the two conditions over the five steps. Here I assume you are the controller for all five, the company that decides why and how the data is used, as you are when you sell to individuals.

The first three steps are what the user asked for, so the contract covers the user's own data in them. Maria's data in the same steps needs another basis, usually legitimate interests. I would call that an easy case: Maria has been emailing the user, and an invite from them is the kind of use she would expect.

The memory note fails both conditions. It is about Maria, and nobody asked for it. The ICO says that "an agent's ability to identify a new use for personal information doesn't mean that the use is automatically compatible with the original purpose", and it names information kept from one task to support a future one as the case that raises that question 3.

Keeping the run to improve the agent fails for the user too. The EDPB, the body of all EU data protection authorities, does not consider the contract basis "generally" appropriate for "improving a service or developing new functions within an existing service" 8.

The same exercise works on any agent. Its tool list is the list of steps it can take, which is also where the recipients your privacy policy has to name come from.

What can replace the contract basis?

Usually legitimate interests. Sometimes the better answer is to redesign or drop the step, and more rarely it is to ask for consent.

Legitimate interests fits steps like the invite to Maria. The ICO accepts it may be available for some agent processing, and names training the model that runs the agent as a likely case, but organisations "must not assume that this lawful basis applies by default" and "may only rely on it if a legitimate interests assessment is in place" 2. That assessment is a written record of three tests: is there a legitimate interest, is this use of the data necessary for it, and do the person's interests override it 9. For the invite, I would expect the record to be short. For a memory that builds a profile of everyone the user emails, the third test is much harder to pass.

Redesigning or dropping the step is often the cheapest answer. If the memory feature is worth having, I would make it something the user turns on, store only what the user's own tasks need, and let them see and delete it. Once the user has asked for memory, I think storing their own data in it can count as necessary for a service they requested. Maria's data in the memory still needs another basis.

Consent has a high bar: freely given, informed, specific, unambiguous and revocable 2. A confirmation prompt before the agent acts is good design, and the ICO encourages approval steps. At most it gives you the user's consent, because Maria never sees the prompt.

Who needs the lawful basis if my product is B2B?

Usually your customer, for the steps its staff ask the agent to do. When a business uses your product, it is normally the controller for what the agent does with its data, and it picks the basis. The people typing instructions are its employees, and their employment contracts are not what an agent's scheduling or research is necessary for. The people they email have no contract with the business at all. So in my view the contract basis rarely fits, and the customer will mostly rely on legitimate interests.

You are a controller yourself for any step you run for your own purposes, such as keeping runs or training a shared model on customer data. The ICO also says organisations that "determine or exert sufficient influence over the purposes and means" of processing through an agent "can be controllers", and that for agents "decisions about protocols, permissions and access controls may more heavily influence the means of processing" 4. How far that reaches is not settled.

So my advice to a B2B vendor is to do the whole exercise as if you were the controller. Your customer needs the step list to choose its bases, the list belongs in your documentation and your DPA anyway, and it covers you if the ICO's broader reading of controller turns out to apply to you.

What should you do if you ship an AI agent?

If you ship an AI agent that acts on users' instructions, you need a lawful basis for each step it takes with personal data, or else those steps breach Article 6, which sits in the UK GDPR's top tier of fines: up to £17.5 million or 4% of worldwide turnover 11.

1. List the steps. Take the agent's tool list and write one row for each thing it can do with personal data: read, search, send, remember, train. Mark whose data each row touches and whether the task the user typed needs it.
2. Write a basis for every row. The contract covers rows that are the user's own data and needed for the task. For the rest, write a legitimate interests assessment, ask for valid consent, or redesign or remove the step. In a B2B product, give the finished list to your customers, in your documentation and your DPA.
3. Tell the people the agent contacts. Maria's data came from someone else, so Article 14 applies: unless an exemption applies, the first message the agent sends her has to carry, or link to, who is processing her data, why, on what basis and where it came from 12. That is a change to what the agent sends, on top of the policy text.
4. Update the privacy policy. Article 13 requires the legal basis for each purpose 10, so memory and training each need their own line.
5. Check where the agent runs. If it runs on the user's machine, as a browser extension or desktop app, and reads or stores information there, the UK's device storage rules (PECR) require consent unless that is strictly necessary for a service the user asked for 2.

If you sell in the UK and want a say in the final guidance, the response form takes answers until the closing date.

Each new tool or memory you give the agent adds a row to this list. We build Lawcel, which reads pull requests against a company's legal documents and flags the ones that change what the privacy policy has to say, so a change like that reaches whoever owns the policy before it ships.