Data processing agreement for an AI assistant

Anyone running an AI assistant on their own website processes personal data: messages, contact details given voluntarily, technical information from the session. If the assistant comes from a service provider, that provider processes the data on your behalf - and Article 28 of the General Data Protection Regulation requires a contract for this. The data processing agreement, or DPA, is not a formality for the end of the project but the place where it is written down who may do what with the chat data. Article 28(3) sets out a framework and eight duties the contract must carry, Article 28(2) governs the authorisation of further processors, and point (g) says what happens to the data when the contract ends. This article works through the points in order, translates them into the building blocks of a chat assistant and answers the question that most often stays open in AI projects: what applies when the language model runs at a third party? It does not replace legal advice, but it offers reliable guidance before you sign.

Enlarge graphic

Labels in the illustration

• Controller
• Your company: determines the purposes and means of processing
• Instructions, Article 28(3)(a)
• Processor
• Operation of the AI assistant, hosting and storage
• Authorisation, Article 28(2)
• Sub-processor
• Data centre, language model, connected services
• The same duties, Article 28(4)
• The chain stays closed: the first is liable for the second one
• Eight duties from Article 28(3)
• a
• Process only on
• documented instructions
• b
• Confidentiality of the
• people involved
• c
• Security measures under
• Article 32
• d
• Sub-processing only with
• authorisation
• e
• Help with requests from
• data subjects
• f
• Help with breach reports
• and impact assessments
• g
• Delete or return the data
• at the end of the term
• h
• Provide evidence and
• allow audits
• Written form may be in electronic format, Article 28(9)
• End of the contract: delete or return all data, copies included
• Exception: statutory retention duties, Article 28(3)(g)

Data processing under Article 28 GDPR

When a Provider Is a Processor

The General Data Protection Regulation distinguishes two roles. Under Article 4(7), the controller is whoever decides on the purposes and means of the processing. Under Article 4(8), the processor is whoever processes personal data on behalf of the controller. With a website assistant the assignment is usually clear: your company decides that there is an assistant, which topics it covers, which details it collects and how long conversations are kept. The provider supplies the technology, operates it and comes into contact with the chat data along the way. It pursues no purposes of its own - it carries out instructions.

The line runs where the provider starts pursuing purposes of its own. Anyone who uses the conversations from your chat window to improve their own offering, to train their own model or to build analyses across several customers is deciding on purposes and means themselves. Article 28(10) draws a clear consequence from this: in respect of that processing, the processor is then considered a controller. That is no small matter, because the full set of duties travels with the role - and on your side a transfer arises that would need a legal basis of its own.

In practice the question often arises whether the mere possibility of access is enough. A provider that maintains an application and could reach the conversation data through remote maintenance is, in the view of the supervisory authorities, regularly processing that data as well. The safe route is therefore to conclude the contract instead of arguing about the likelihood of access. How hosting, storage and access can be cleanly separated in an assistant is set out in detail under data protection and hosting and in the article on the GDPR-compliant AI assistant.

The Eight Duties From Article 28(3)

Article 28(3) first requires a framework: the contract must set out the subject matter and duration of the processing, the nature and purpose of the processing, the type of personal data, the categories of data subjects and the obligations and rights of the controller. Only then do the eight points (a) to (h) follow with the duties of the processor. On form, Article 28(9) applies: the contract shall be in writing, including in electronic form. A verbal understanding or a promise in a quotation email does not meet this.

• Point (a) - bound by instructions: the processor processes the data only on documented instructions, including for any transfer to a third country.
• Point (b) - confidentiality: the people involved are committed to confidentiality or are under a statutory obligation of secrecy.
• Point (c) - security: all technical and organisational measures required under Article 32 must be taken.
• Point (d) - sub-processing: the conditions in Article 28(2) and (4) for further processors are respected.
• Point (e) - data-subject rights: the processor helps you answer requests for access, rectification or erasure.
• Point (f) - assistance: it assists with the duties in Articles 32 to 36, that is security, breach notification and impact assessment.
• Point (g) - end of the service: after the provision of the processing services the data is deleted or returned at your choice, copies included.
• Point (h) - evidence and audits: it makes all necessary information available and allows audits, including inspections.

These eight points sound abstract until you lay them over a chat assistant. The type of data is then chat content, contact details given voluntarily, timestamps and technical information from the session. The categories of data subjects are website visitors, existing customers and, depending on use, applicants or employees. The purpose is answering enquiries and routing them to the responsible place, the duration matches the term of the contract. Whoever writes these details into the annex instead of leaving a blank line has the contract half finished - and notices while filling it in which data flows nobody in the project has named yet.

Bound by Instructions: What a Documented Instruction Is

Being bound by instructions is the core of processing on behalf. Article 29 makes clear that the processor and any person acting under its authority may process the data only on instructions from the controller, unless they are required to process it by Union or Member State law. Article 28(3)(a) requires the same binding force in the contract, and in documented form.

With an AI assistant, instructions are not formal letters but decisions that are taken during operation anyway: which content goes into the knowledge base, which details the assistant may ask for, how long conversations are stored, when a case goes to a human, which systems are connected through tool control in the Custom package. Documented means that these decisions are recorded in a readable form - in the annex to the contract, in a configuration log or in a ticket. For the case where the processor considers an instruction to infringe data protection law, Article 28(3) provides a duty to speak up after point (h): it must inform the controller immediately.

Sub-Processors and Their Authorisation

Hardly any assistant runs without further participants. Servers, storage, sending notifications, possibly the language model: all of these can be further processors. Article 28(2) allows this, but not silently. The processor may only engage another processor with prior specific or general written authorisation from the controller. Under a general authorisation it must inform the controller of any intended change, so that the controller has the opportunity to object to such changes.

Article 28(4) closes the chain. Where another processor is engaged, the same data protection obligations as in the main contract must be imposed on it. If it fails to meet them, the first processor remains liable to the controller for compliance. For you this means: you do not have to negotiate with every data centre individually, but you should know who is in the chain. A list with name, seat, place of processing and the service provided belongs in the contract as an annex, not on a subpage that can change without notice.

When the Language Model Runs at a Third Party

An AI assistant consists of several building blocks: the application with the chat window, the storage for conversations and knowledge content, and the language model that formulates the answer. For the contract the third block is the most delicate, because it is the only one the inputs leave once it sits outside the house. Every message a visitor types then goes to a place that must be named in the contract. Whether a model provider is a sub-processor does not depend on what it calls itself, but on the fact that it processes personal data for the operation of your assistant.

The second point besides the location is the handling of the inputs. If a model provider uses the transmitted texts to improve its own models, it processes them for a purpose of its own - and slides into the role described in Article 28(10). The contract therefore needs a sentence that rules this out, for inputs and outputs alike. It should equally state how long the provider keeps the requests, whether it stores them for abuse monitoring and who has access there. These details are in the model provider's terms; carrying them over into your own contract is the work that makes the difference.

Technical and Organisational Measures as an Annex

Point (c) refers to Article 32, and Article 32 requires measures appropriate to the risk. It names, among other things, encryption, the ability to ensure the confidentiality, integrity, availability and resilience of the systems, the ability to restore access after an incident, and a process for regularly testing the effectiveness of the measures. This is deliberately open, because an assistant for opening hours carries a different risk than one that takes in health data.

• Encrypted transmission between chat window, application and storage, plus a clear statement of whether and how stored conversations are encrypted.
• Separated tenants: one customer's knowledge base and conversations do not sit in the same pot as another's.
• Role-based access, plus a log of who looked into plain-text conversations and when.
• Defined retention periods for conversations, logs and backups, stating how long deleted data still remains in the backups.
• A route for notifications: who informs whom within what period when a personal data breach is noticed.
• Testing the effectiveness at fixed intervals, with a date and a result, not just as a declaration of intent in the contract.

Deletion at the End of the Contract

Point (g) governs the exit. After the end of the provision of the processing services, all personal data must be deleted or returned at the choice of the controller, and existing copies must be deleted, unless Union or Member State law requires storage. The choice is yours, not the provider's - and it should already be made in the contract, or at least given a deadline.

With an assistant, more hangs on this sentence than you might think when signing: conversations, log files, analyses, the knowledge base with your own texts, backups from recent weeks and, where applicable, cached requests at the model provider. It therefore makes sense to agree three things. First, a format for the return that you can read without the provider's software. Second, a period within which deletion happens, counted from the end of the service and not from a later request. Third, a short confirmation that the deletion has taken place, stating when the last backups containing that data expire. Retention duties, for example under commercial or tax law, remain unaffected, but they concern accounting records and not the conversation history in the chat.

Audit Rights and Evidence in Everyday Use

Point (h) gives you two things: a claim to all the information necessary to demonstrate compliance with the obligations in Article 28, and the right to audits, including inspections, conducted by you or another auditor you mandate. In practice, for a website assistant a documented answer is usually enough: the list of sub-processors, the description of the measures under Article 32, the retention periods and the place of processing. What matters is that the contract describes this route instead of tying an audit to conditions nobody can meet.

On top of that come two duties that are easily overlooked. Article 30(2) requires the processor as well to maintain a record of the processing activities it carries out on your behalf; this complements your own record but does not replace it. And Article 33(2) obliges it to notify you of a personal data breach without undue delay after becoming aware of it. That notification triggers your own deadline under Article 33(1), which is set at 72 hours - which is why the contract should name a contact point and a way to reach them, not a general postal address.

Liability and Fines: Who Answers for What

Article 82(2) draws the line between the roles. A processor is liable for damage caused by the processing only where it has not complied with the obligations specifically directed to processors, or where it has acted outside or contrary to lawful instructions from the controller. For everything else the controller remains responsible. On the fines side, Article 83(4)(a) covers infringements of the obligations in Articles 25 to 39, which include Article 28: the ceiling there is up to 10 million euros or up to 2 percent of the total worldwide annual turnover of the preceding financial year, whichever is higher.

Checklist Before You Sign

The points so far add up to a manageable list of questions that should be settled before introducing an assistant. It does not replace an individual review, but it shows where a template contract is still empty. Anyone who goes through it with the provider quickly notices whether they know their own processing.

• Is there a written contract under Article 28, and is the annex filled in with the actual data?
• Are the type of data, categories of data subjects, purpose and duration described rather than left as boilerplate?
• Is it agreed that processing happens only on documented instructions, and where those instructions are recorded?
• Is there a named list of sub-processors with seat, place of processing and service provided?
• Are the duty to inform and a period to object regulated for a change of sub-processor?
• Does the contract say where the language model runs and that inputs and outputs are not used for outside purposes?
• Are the Article 32 measures described in an annex, with retention periods and a statement of how long backups still hold deleted data?
• Has the choice between deletion and return been made, with a deadline, a format and confirmation of deletion?

In the end, a data processing agreement is less a piece of legal art than a description of what happens anyway. That is precisely where its value lies: filling it in forces you to think your own processing through to the end - from the first sentence in the chat window to the deletion run after the contract ends. XICBOT assistants are operated with hosting in Germany, with named sub-processors and with an annex that describes the actual data flow. If you would like to hold an existing contract against the points above, write to us about what it concerns; how an assistant is connected technically is described under integration.

Frequent questions