Suppose your customer service team wants an AI agent that reads the shared mailbox, looks into the order system and answers customers itself. The vendor sends its standard contract: a licence, a service level and a data processing agreement as an annex. It says nothing about what the agent may do, who can stop it, which logs you get or what happens when the model is replaced. An agent does not only answer, it acts. For AI procurement in general see AI procurement and contracts and assessing an AI vendor; this article covers what an agent adds.
Buying an AI agent and the contract in brief
Start with the roles, because they determine what you can demand. Under the AI Act the vendor is usually the provider and you the deployer; under the GDPR you are, as a rule, the controller and the vendor the processor. If you build or modify the agent, or put it into service under your own name, you can become the provider yourself (Article 3(3), Article 25(1)). Fix what the agent is for, that the vendor does not use your data for its own purposes (if it does, it is a controller for that processing, Article 4(7) and Article 28(10) GDPR) and that it binds every sub-processor, such as the model provider, to the same obligations (Article 28(4) GDPR). Assess plug-ins and MCP servers that you connect yourself separately: such a party may be your own processor or a controller in its own right. Also arrange security, logs, incident notification in hours, approval points, a kill switch you operate, change management, audit rights and exit. Between businesses the contract mostly decides who bears the loss: the revised directive on defective products only gives natural persons a right to compensation.
Which role do you have when you buy an AI agent?
The role determines the duty. According to the European Commission an agent is typically an AI system, which it calls a preliminary view. A provider is whoever develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trademark, including for its own use (Article 3(3)); a deployer is whoever uses it under its authority. Under the GDPR you are, as a rule, the controller and the vendor the processor (Article 4(7) and (8)). Your AI Act role can shift:
| What you do | Your role under the AI Act |
|---|---|
| Have an agent built, or retrain an existing generative system, and put it into service under your own name, even only internally | Provider (Article 3(3); Commission guidelines, point 11) |
| Use a general-purpose agent for an Annex III use, such as assessing job applicants | Provider of a high-risk system (Article 25(1)(c)) |
| Put your name on a high-risk system or modify it substantially | Provider (Article 25(1)(a) and (b)); under (a) the contract may allocate the obligations differently |
The deployer's duties for high-risk systems (Article 26) apply to Annex III from 2 December 2027. If the system was already on the market or in service before that date, they apply only after a significant change in its design, and for public authorities by 2 August 2030 at the latest (Article 111(2)). A contract you sign now may run longer, so settle changes and cooperation up front. If the agent is not high-risk, most of the requirements come from the GDPR, plus Article 4 and Article 50 of the AI Act. Record the roles per agent in an annex and read the vendor's terms: if the original provider has clearly specified that its system is not to be changed into a high-risk system, it does not have to cooperate (Article 25(2)). If you build a high-risk system on a vendor's platform, Article 25(4) requires a written agreement on information, technical access and assistance. The Agent check shows which duties are likely to apply; the framework is in the guide to AI agents and the law.
What should the agent do, and what not?
Describe the task in the contract or an annex: actions, data, systems and what the agent must never do. The intended purpose given by the provider (Article 3(12)) counts towards the risk class. Under the GDPR the purpose must be fixed in advance and you may not use more data than necessary (Article 5(1)(b) and (c) GDPR). The Dutch Data Protection Authority calls limiting an agent to one specific task good practice and notes that providers leave the building of guardrails to organisations (RAN 6). Record which limits the vendor supplies and start with restricted permissions.
What may the vendor do with your data?
A processor processes only on your documented instructions (Article 28(3)(a) GDPR). Record that the vendor and its subcontractors do not use your inputs, outputs, logs and derived data, such as the agent's memory, to train or improve models, unless you allow it in writing for a defined purpose. If the vendor infringes the GDPR by determining purposes and means itself, for example by training on your data, it is considered a controller for that processing (Article 28(10) GDPR). If you do allow it, the vendor is a controller for that purpose and you need your own legal basis to pass the data on. Trade secrets are protected mainly by the contract, not by the GDPR.
What goes into the data processing agreement, and who is in the chain?
Article 28(3) GDPR prescribes the content, from instructions and confidentiality to help with data breaches and DPIAs, deletion or return, and audits. With an agent the difficulty lies in the chain: behind the vendor work a model provider, hosting and tools such as plug-ins and MCP servers (connections through which an agent reaches tools and data sources). Arrange:
- a current list of all sub-processors with name, address and contact person, which the EDPB expects you to have at hand at all times, plus the place of processing;
- prior authorisation, or notice with a right to object, for every new or replacement sub-processor (paragraph 2), and by contract also for a new model or tool from an existing sub-processor;
- the same obligations for every subcontractor, for whose performance the vendor remains fully answerable to you (paragraph 4);
- an allow-list of tools and versions with a bill of materials (SBOM), as six cyber agencies advise.
What security can you demand?
Article 32 GDPR requires measures appropriate to the risk. For an agent that means: limit what it can do. Demand a separate identity per agent, least privilege (only what the task needs), short-lived credentials and a test environment, as six cyber agencies jointly advise. Do not settle for a promise that prompt injection (hidden instructions) is excluded: the UK NCSC considers it very possible that it can never be fully prevented. Ask for a design that limits damage, results of red teaming (simulated attacks to find weak spots) and a deadline for fixing vulnerabilities. More: security risks of AI agents.
Which logs do you get, and for how long?
Without logs you cannot reconstruct what the agent did. Record what is logged (tool calls with outcomes, approvals, model version), that the agent cannot alter the logs, that you can view and export them, and how long they are kept. For high-risk systems the system must record logs (Article 12) and the provider must describe how you collect and read them (Article 13(3)(f)). The deployer keeps the logs under its control for at least six months, unless other law, in particular data protection law, provides otherwise (Article 26(6)). If the logs sit only with the vendor, bring them under your control through the contract.
When must the vendor report an incident?
A processor must notify you of a personal data breach without undue delay (Article 33(2) GDPR); you notify the Dutch Data Protection Authority yourself without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to result in a risk (paragraph 1), and you document every breach (paragraph 5). So agree a deadline in hours, with a contact point available day and night. Define incident more broadly than a data breach: also an agent acting outside its task or a successful hidden instruction. For high-risk systems the provider reports a serious incident immediately and no later than 15 days after the provider or you become aware of it; 10 days if someone dies, 2 days for a widespread infringement or a disruption of critical infrastructure (Article 73). As deployer you inform the provider first (Article 26(5)): agree how you inform each other. Essential and important entities face 24 and 72 hour deadlines for a significant incident under the Dutch Cybersecurity Act; see AI agents and the Dutch Cybersecurity Act.
Who approves, and who can stop the agent?
Human oversight only works if it is built into the software and not only into the instruction to the model. Record which actions the agent may never take without a person's approval (sending externally, paying, deleting, decisions about people), that you set those approval points yourself and that the agent stops when in doubt. Arrange a kill switch you operate yourself: pause the agent and revoke its access without waiting for the vendor. For high-risk systems a person must be able to halt the system with a stop button or a similar procedure (Article 14(4)(e)), and you must suspend use when there is a risk (Article 26(5)). If the agent decides about people, GDPR Article 22 applies too.
Who makes sure people know it is an AI?
Article 50(1) rests on the provider: a system intended to interact directly with people must be designed so that they know it is AI, unless that is already obvious to a reasonably well-informed and observant person, at the latest at the first interaction (paragraph 5). That has applied since 2 August 2026. According to the Commission guidelines of 20 July 2026 (point 31, not binding), an agent should also disclose on whose behalf it acts. Record that the vendor builds the disclosure in and that you set the organisation name and language per channel. If you put the agent into service under your own name, you may be the provider yourself.
What if the vendor changes the model or the agent?
An agent changes even when you notice nothing: a new model, a tool with different permissions, a function that disappears. Record: advance notice of material changes, a test environment, the ability to pin the version, rollback, and a right to object or to terminate at no cost. Let these terms prevail over the general terms and online documentation, which the vendor can amend itself. The right to object to a new sub-processor is in Article 28(2) GDPR; for high-risk systems the provider states pre-determined changes in the instructions for use (Article 13(3)(c)).
How do you check the vendor?
The data processing agreement must stipulate that the processor makes available all information necessary to demonstrate compliance with its obligations under Article 28 GDPR, and allows for and contributes to audits, including inspections (Article 28(3)(h) GDPR). That statutory minimum concerns the processing of personal data. Access to configuration, permissions and logs, audit reports and test results is something you add as a contractual term. The AI Act requires the provider of a high-risk system to supply instructions for use (Article 13), not to accept audits by you; you use those instructions for your DPIA (Article 26(9)). An approved code of conduct or certification is only one element for demonstrating guarantees (Article 28(5) GDPR).
How do you get out of the contract?
At the end, the processor deletes or returns all personal data at your choice and deletes existing copies, unless the law requires storage (Article 28(3)(g) GDPR). Name the agent's memory, search index, logs and copies at sub-processors explicitly, and ask for confirmation of deletion. If the agent is a cloud service covered by the Data Act, the contract must since 12 September 2025 provide for a notice period of at most two months to start the switch, a transition period of at most 30 days, which the provider may extend to no more than seven months if it is technically unfeasible, and at least 30 days to retrieve data (Article 25 Data Act).
Who bears the loss when the agent does something wrong?
Towards your own customers the ordinary rules apply; see who is responsible when an AI agent makes mistakes. Between you and the vendor, the contract mostly decides what you can recover. The revised directive on defective products (Directive (EU) 2024/2853) does not help businesses: only natural persons have a right to compensation and property used exclusively for professional purposes is excluded (Articles 5 and 6); it also applies only to products placed on the market or put into service after 9 December 2026. Arrange yourself which loss the contract covers, how high the cap on damages is, what falls outside it (such as a breach of confidentiality or of processor duties) and whether the vendor is insured.
Checklist: the clauses at a glance
Use the table as a working list in the negotiation; (HR) means: high-risk systems only. If you buy as a public body, you can also use the EU model contractual clauses for AI procurement (MCC-AI, updated version of 5 March 2025, with a version for high-risk systems and a light version), and as a Dutch municipality the GIBIT 2025 purchasing terms of the VNG. These are models, not law: the MCC-AI were written for public organisations, cover only AI Act topics and are not a full contract, so you arrange the GDPR, intellectual property and the allocation of loss elsewhere. They differ from the voluntary model terms that the AI Office may recommend under Article 25(4) for contracts between a provider of a high-risk system and its suppliers. For the questions to ask up front there is the AI vendor questionnaire. If you want someone to read the draft along with you, you can hire Zahed Ashkara as an AI and privacy legal adviser.
| Clause | What to record | Anchor |
|---|---|---|
| 1. Roles | Provider, deployer, controller, processor | AI Act Art. 3, 25; GDPR Art. 4, 28 |
| 2. Purpose and scope | Task, data, limits | AI Act Art. 3; GDPR Art. 5 |
| 3. Use of data | No training without agreement | GDPR Art. 28(3), (10) |
| 4. Chain | Sub-processors, plug-ins, MCP servers | GDPR Art. 28(2), (4) |
| 5. Security | Least privilege, red teaming | GDPR Art. 32 |
| 6. Logs | Content, export, retention | AI Act Art. 12, 13, 26 (HR) |
| 7. Incidents | Deadline in hours, contact point | GDPR Art. 33; AI Act Art. 26, 73 (HR) |
| 8. Approval and kill switch | In the software, under your control | AI Act Art. 14, 26 (HR) |
| 9. Transparency | Disclosure that it is AI, and on whose behalf the agent acts | AI Act Art. 50(1); guidelines point 31 (not binding) |
| 10. Changes | Notice, test environment, objection | GDPR Art. 28(2); AI Act Art. 13 (HR) |
| 11. Audit | Information and audits; test results and configuration by contract | GDPR Art. 28(3)(h); contract |
| 12. Exit | Deletion or return, switching | GDPR Art. 28(3)(g); Data Act Art. 25 |
| 13. Loss | Coverage, cap, exceptions | Contract; Directive 2024/2853 |
Frequently asked questions about buying an AI agent
Sources
Newsletter
Every Tuesday, the AI Act week ahead in 5 minutes
A practical briefing on deadlines, new guidance and enforcement, so you know what matters this week. No spam and you can unsubscribe in one click.
Practical and short · No spam · One-click unsubscribe