Adapted from the Polish article, originally published on 28 August 2026 and updated on 21 September 2026. The English version was published on 01 October 2026.
The demo takes thirty minutes. The tool summarises meetings, reads documents and drafts customer responses. Buying a licence takes a credit card. Understanding what happens to customer records, employee files, conversation history and generated results takes more work.
A DPA, security certificate and EU data region are useful evidence. Individually, none establishes that the tool is suitable for your process. Begin with the intended use and data flow, then assess the vendor and documents.
On 6 August 2026, UODO, Poland’s data protection authority, published initial questions for assessing AI and GDPR, including a version for smaller businesses using ready-made tools. The guidance is in Polish and is not binding law. The underlying GDPR is an EU regulation; this article uses the Polish regulator’s material as a practical procurement starting point.
What you will learn
- Why a DPA alone does not complete an AI review.
- Which data layers to assess beyond the prompt.
- How the vendor’s controller and processor roles can differ by operation.
- What to check about training, retention, subprocessors and transfers.
- How to assess whether human oversight works in the actual workflow.
- Which changes, incident and exit provisions belong in the contract.
In brief
- Assess a defined use case, not the vendor’s feature catalogue.
- Map inputs, integrations, outputs, history, telemetry and security logs.
- Check roles separately for service delivery, analytics, security and product development.
- Identify training, fine-tuning, evaluation and other reuse of data.
- Match the DPA to the real processing and assess transfers through the whole service chain.
- Agree incident cooperation, material changes, deletion and exit before deployment.
Use the regulator’s checklist as a starting point
UODO’s lists address several groups and deployment stages: smaller businesses using existing tools, public bodies, other organisations including those developing models, and a broader set that also flags AI Act questions.
The lists do not replace a risk assessment, data protection impact assessment or relevant fundamental-rights assessment. A missing answer does not automatically establish a GDPR breach. It may show that the business does not yet understand the process well enough to assess it.
That distinction matters during procurement. A vendor’s documents cannot answer questions the buyer has not settled about its own use of the system.
1. Which problem will the tool solve?
Review a specific workflow. The same tool may edit marketing copy, assess complaints or support recruitment. Those uses involve different data, effects on people and safeguards.
Describe who uses the system, what they provide, what result they receive, who makes the final decision and what happens when the result is wrong.
“An AI assistant for customer service” is too broad. Does it draft a reply, recommend a decision, send the message itself, grant a discount or reject a claim? That operational description should guide the legal review.
2. Which data actually reaches the service?
The prompt is only one layer. Attachments, connected sources, outputs, inferred information, history, technical logs and agent memory can all contain personal data. Removing a name from the prompt does not necessarily anonymise the wider workflow.
| Layer | Examples of data |
|---|---|
| Input | Prompt, email, recording, document, image |
| Context | CRM records, knowledge base, calendar, retrieved documents |
| Output | Response, summary, profile, recommendation |
| Telemetry | User identifier, IP address, usage time |
| History | Conversations, document versions, agent memory |
| Security | Access logs, alerts, administrative session records |
Separate production data from testing data. Uploading a full customer database “just to test quality” is still personal data processing. Choose a limited test dataset and assess it before the pilot starts.
3. Is the vendor a processor or a controller?
The role follows the actual decisions about purposes and means of processing, not only the label in the terms. A vendor may process data on the customer’s instructions for the main service and determine its own purposes for other operations.
Assess service delivery, maintenance and security, usage analytics, product development, model training or fine-tuning, and support separately.
Where the vendor processes personal data on the customer’s behalf, the arrangement needs to meet Article 28 GDPR, commonly through a data processing agreement or DPA. Where it uses data for its own purposes, calling it a processor does not settle the legal basis, transparency duties or responsibility for that operation.
Check how the contract describes those operations against the product settings and actual data flow. An agreement covering only the named application may leave connected services outside the assumed arrangement.
4. Is the data used to train or improve models?
Ask whether prompts, files, outputs, feedback or logs are used for training, fine-tuning, evaluation or other purposes. Check the account settings, service terms, DPA and technical documentation together.
“No training” does not necessarily mean no reuse. The vendor may distinguish base-model training, customer-specific fine-tuning, response evaluation, abuse prevention, feature development and manual review of samples. Assess the purpose and conditions of each operation.
Determine whether an exclusion is the default or must be enabled for each workspace or integration. A setting on one account may not describe the whole connected workflow.
The European Data Protection Board’s Opinion 28/2024 addresses questions about AI models, including anonymity and legal basis. A supplier’s general statement that a model is anonymous does not close that assessment.
5. How long is each data layer retained?
Review prompts, uploaded files, outputs, logs, backups, agent memory and copies held by subprocessors. Deleting a conversation from the interface may not immediately remove all copies.
Identify default periods, shorter settings available to the customer, who can request deletion, backup treatment and what happens after account closure. Ask whether data previously used for model development can be removed and what evidence the vendor provides.
If retention cannot be limited appropriately, the business may need to restrict the use case or data entered. Another paragraph in a privacy notice does not resolve every mismatch between the process and the tool.
6. Where is processing performed, and by whom?
Data-centre locations do not describe all processing. Examine subprocessors, administrative access, support and auxiliary services. An EU hosting region can coexist with access from another country.
Request the current subprocessor list, functions, locations, change-notification process and the procedure for objections. For transfers outside the European Economic Area, assess the relevant transfer mechanism and any supplementary measures needed for the circumstances.
The contract should explain the effect of a justified objection. An email address for objections is of limited use if the buyer has no workable remedy when the proposed change is unacceptable.
7. How are security and incidents handled?
A certificate may be useful evidence, but it does not describe every aspect of your deployment. Review MFA and SSO, administrator roles, encryption, key management, tenant isolation, logs, security testing, vulnerability handling and continuity.
Agree an initial incident channel, timing, minimum information, updates and a final report. The vendor’s process must support the customer’s applicable GDPR obligations. Do not assume the vendor’s contractual deadline and the controller’s statutory reporting assessment are the same thing.
Under Article 33 GDPR, a processor notifies its controller of a personal data breach without undue delay. Articles 33 and 34 also require the controller to assess notification duties to the authority and affected people. The supplier’s cooperation should make those assessments possible, including when the first facts arrive at 03:00 on a Saturday.
8. Can a person meaningfully challenge the result?
Human oversight needs knowledge, time, information and authority. A person approving a queue of recommendations without seeing their basis may provide little genuine control.
Check whether the reviewer can understand the relevant input, recognise limitations and change the decision. Do they have enough time? Does the organisation monitor overrides and default approvals? Can the affected person obtain a human review where required?
Where a decision is based solely on automated processing and has legal or similarly significant effects, assess Article 22 GDPR, including its conditions and exceptions. A nominal human approval does not automatically take the process outside that framework.
For a recruitment workflow, classification and organisational roles under the AI Act require a separate assessment. Our deployer-to-provider recruitment example explains why a change of purpose matters.
9. What happens when the model or terms change?
An AI service can change without a traditional deployment on the customer’s side. The vendor may replace the model, change retention, add a subprocessor or introduce more autonomous behaviour.
Define which changes require notice, testing, renewed assessment or agreement. Consider changes to model suppliers, data purposes, locations, subprocessors, security, retention and the system’s capabilities or limitations.
A material change should give the business time to assess the effect, update instructions or its DPIA, and leave the service if necessary. A DPIA is a data protection impact assessment; GDPR requires it where the planned processing is likely to create high risk to people’s rights and freedoms.
10. How will the business recover data and leave?
An exit plan should cover export, deletion, integrations, tokens, technical accounts and the records needed to demonstrate what happened. Cancelling a subscription is not the same as removing every connected flow.
Agree the export format, access period after termination, migration help, deletion deadlines, confirmation and backup treatment. Include agent memory, retrieval indexes and connected knowledge sources.
Retrieval-augmented generation, or RAG, allows a system to retrieve information from sources such as the customer’s knowledge base when preparing an answer. Exit therefore needs to cover those sources, indexes and integrations, not just a user’s login.
If a separate application is connected to the AI service, review that application’s provider, permissions and terms too. The main vendor’s DPA should not be assumed to cover every independent recipient.
A hypothetical case: AI assesses complaints, staff press Enter
This example is illustrative, not a client history. An online shop deploys AI to review complaints. It reads customer messages, retrieves CRM order history, classifies the issue, recommends a decision and drafts the response.
The pilot uses real complaints. The vendor says business-customer data is not used to train the main model, while another provision permits telemetry and selected interaction fragments to be used for quality and safety evaluation.
Conversation history disappears from the interface after 30 days; technical logs remain for a year. A moderation subprocessor works outside the EEA. Staff formally approve every response, but the interface gives them a ready decision without clearly showing its basis. In 96% of cases, they use the default approval.
Despite signing a DPA, the shop has not settled reuse purposes, retention by layer, transfers, customer rights, meaningful review, handling of a mistaken rejection or withdrawal of data after the pilot.
A stronger process would start with a data-flow map and limited test dataset. It would then establish roles, remove unnecessary reuse, shorten retention where appropriate, assess transfers and design a review screen that helps staff examine the recommendation. Those findings would inform the contract and deployment decision.
Turn the questions into a procurement process
- Describe the use case and expected result.
- Map the data, affected people and effect of the output.
- Establish the customer’s and vendor’s roles.
- Review terms, privacy information, DPA and subprocessors.
- Check actual settings, security, retention and transfers.
- Agree change, incident, supervision and exit arrangements.
- Name the process owner and the triggers for another review.
Product, procurement, security, the data protection function and the business owner should work from the same process description. If nobody knows which AI tools staff use, start with the inventory before assessing a single preferred vendor.
For help turning the use case and data map into an AI supplier contract, DPA or DPIA, see our technology and data protection legal services or contact us about the proposed deployment.
Sources and further reading
- UODO: Zanim wdrożysz narzędzie AI, sprawdź czy jest ono zgodne z zasadami RODO, initial questions and supporting checklists, in Polish.
- Opinion 28/2024 on certain data protection aspects related to the processing of personal data in the context of AI models, European Data Protection Board, official English version.
- Regulation (EU) 2016/679, the GDPR, particularly Articles 22, 28, 33, 34 and 35.