On Thursday, 6 August 2026, at 1.01 p.m., Edyta Madziar of the Social Communication Department at Poland's Personal Data Protection Office (UODO) saved the final revision of entry number 4533. Its title reads like a remark overheard in a corridor rather than a statement from a supervisory authority: "Before you deploy an AI tool, check whether it complies with GDPR principles." Beneath it sit five downloadable files — a covering letter and four checklists in editable format.
Technically speaking, this is nothing. No decision, no fine, no order. The Office itself states that the material is not a binding interpretation of the law and does not determine GDPR compliance, and that the answers need not be shown to anyone. Compliance documents rarely disclaim their own authority so thoroughly.
And yet it is one of the more interesting moves the Polish authority has made this year — precisely because it is not guidance. The problem UODO is addressing here is not that organisations do not know the rules. It is that they ask about them at the wrong moment.
Four days after the AI Act, eight months after a survey
The publication date is no accident. On 2 August 2026, Regulation 2024/1689 — the AI Act — entered the phase in which the transparency obligations under Article 50 apply with no transitional period. We covered that deadline as it fell. Four days later, the national data protection authority put an operational tool on the table for organisations that have just realised they are running something meeting the definition of an AI system.
The second piece of context is longer. On 28 January 2026, Data Protection Day, the Office published its "Strategic Report — A Study of Organisational Needs in the Use of Artificial Intelligence and Personal Data Protection." It was prepared by the Artificial Intelligence Working Group operating within the Social Panel of Experts to the President of UODO, based on a nationwide survey and group interviews with seven private-sector umbrella organisations.
The August question lists are a direct response to the findings of that study. This is a rare and noteworthy sequence: the authority gathers data on the market's readiness, publishes a diagnosis, and six months later releases a tool tailored to the gaps it found. Polish regulatory practice more often delivers a tool without a diagnosis, or a diagnosis without a tool.
The figure worth pausing over: 95.9 per cent
The January report contains three numbers worth remembering, because they explain everything else.
First: 17 per cent of surveyed organisations already use artificial intelligence. The rest either do not use it at all, are running pilots, or plan to deploy. These are self-reported figures, and anyone who has run a tool inventory knows that declaration and reality are two different quantities — a point we made when writing about shadow AI.
Second: between 41 and 58.5 per cent of entities see no connection between AI tools and the processing of personal data. The range reflects the fact that different aspects of that connection were tested, but even the lower bound is striking. Close to half of all organisations believe that feeding a language model a client email, a meeting note or a sales sheet with the names of account managers simply falls outside GDPR.
Third, and most damning: 95.9 per cent do not consider themselves prepared to deploy AI in compliance with GDPR. Read alongside the second figure, this describes an organisation that simultaneously sees no problem and knows it cannot handle it. That is not a contradiction — it is a description of a company where the person buying the tool is not the person accountable for compliance.
It is worth setting these results against what organisations actually use AI for. The most frequently cited application was the automation of administrative processes at 41.2 per cent, followed by data analytics at 31 per cent. These are precisely the two areas in which personal data appear almost by definition, because administrative processes serve people and analytics describe their behaviour. The declared absence of any link between AI and personal data processing collapses against the respondents' own answers to the neighbouring question.
The most important sentence in the whole UODO announcement is a different one, however: the compliance question is usually asked once the tool is already running, after the decisions about which data to use and which vendor to pick have been made. The entire purpose of the publication is to move that question a few weeks earlier, ahead of the signature on the purchase order. Asking it then costs an hour of conversation. Asking it six months later costs a migration, a contract renegotiation, or the withdrawal of a tool the team has grown attached to.
Why a list of questions rather than more guidance
Guidance has one rarely discussed weakness: it addresses the person who already knows they ought to read it. It reaches the data protection officer, the legal department, the compliance officer. It does not reach the head of customer service testing an assistant that drafts email replies, or the recruitment specialist who has just uploaded three hundred CVs into a tool promising initial screening.
A list of questions works differently, because it travels. You can email it to someone with no time for a thirty-page document, and you can put it on the table during a vendor call. It turns the conversation from a law exam into a product interview. The difference is psychological, but in deployment practice it is decisive.
UODO states explicitly who the material is for: data protection officers and the people responsible for technology procurement and deployment. That second audience is new here, and it is the real protagonist of the publication. The Office has noticed that the compliance of an AI tool is settled in the procurement function, not the legal one — and addressed the document to whoever actually makes the decision.
The lists were prepared by Professor Dominik Lubasz of the University of Łódź, supported by other members of the Social Panel of Experts and by the Office's own specialists. The name bodes well for the material's practical character: this is the author of GDPR commentaries that data protection officers use daily, not a theorist.
Four sets and the logic behind the split
The division into four versions is deliberate and is itself a diagnosis of the market.
The SME version was written for organisations using off-the-shelf AI systems — those that never go through a model training stage and have no extensive legal expertise in-house. This is by far the largest population and the most neglected, because material on AI and GDPR has generally been written as though every reader were building their own model.
The public sector version accounts for the principle of legality and the rules of administrative procedure. That distinction carries practical weight, as set out below.
Version 0, described as a zero-level checklist using a functional approach, addresses organisations that fit neither of the above categories, including those building or fine-tuning their own models. The name signals the sequence: these are the questions you ask before you even know which category you belong to.
The extended version is common to all groups and is completed when the entry list reveals the triggers described in its scope — in particular the building or fine-tuning of a model, or an effect on the legal position of individuals. The structure is therefore two-stage: a filter, then a deeper analysis wherever the filter catches something. Exactly the logic that governs the data protection impact assessment under Article 35 GDPR, where a necessity test precedes the full analysis.
For SMEs: you are buying off the shelf, so ask the seller
A small company's position differs from a corporation's not in the scale of risk but in the degree of influence over the product. Buying a ready-made tool on subscription, you decide nothing about model architecture or training data. You decide something else — and that is the list of things to ask about before the invoice arrives.
Will the data entered into the tool be used to train the vendor's model, and if so, can that be switched off, and is the switch off by default or on request? Where are the data physically processed, and does any transfer outside the European Economic Area occur — if so, on what Chapter V basis? How long does the vendor retain query content, and is retention configurable? Does the vendor act as a processor within the meaning of Article 28 GDPR and offer a data processing agreement, or merely terms of service?
Two principles are least considered at the point of purchase and come up first during an inspection. Purpose limitation under Article 5(1)(b) GDPR means that data collected to fulfil an order do not automatically become training material for a sales assistant. Data minimisation under point (c) of the same provision requires asking whether the tool genuinely needs the entire customer record, or whether an identifier and three fields would do. In practice most deployments pass through a stage where someone exports the full table because it is faster, and nobody ever revisits it.
These are questions a vendor will either answer within a single call or not answer at all. The absence of an answer is itself an answer, and it is worth recording. Our audit work shows the pattern regularly: a company holds three AI subscriptions and not one document defining the vendor's role — and that role determines who is accountable when the data leak, a lesson taught clearly by the UODO fine imposed on DPD Polska over its chain of sub-processors.
Public sector: ask about the legal basis, not consent
A separate version for public bodies is not a courtesy to government offices but a consequence of a genuine legal difference. An administrative body cannot rely on consent or on legitimate interests to the extent that a business can. Article 6(1)(e) GDPR requires processing to be necessary for the performance of a task carried out in the public interest or in the exercise of official authority — and that task must be grounded in a legal provision.
This produces a question a business never asks itself: where is the provision that lets me use this tool for this activity? If a mayor wants a language model to draft responses to freedom-of-information requests, they must identify not only the purpose but the legal basis for that specific operation. The rules of administrative procedure add another layer — an administrative decision must contain a statement of facts and law prepared by the authority, not generated by a system whose behaviour the authority cannot explain.
On top of that sits an obligation still rarely discussed in local government: the fundamental rights impact assessment under Article 27 of the AI Act, which public bodies deploying high-risk systems carry out alongside the Article 35 GDPR assessment. These are two different documents examining two different things, even where they draw on the same factual record. The Polish Act on Artificial Intelligence Systems, signed by the President on 24 July, provides a transitional period here for local government units — but transitional periods end, and the habit of documenting takes years to build.
The extended version: where GDPR meets the AI Act
The most interesting element of the package is the extended version, because it is the first UODO material to signal obligations from outside GDPR so plainly. The Office is not the market surveillance authority for the AI Act — from November 2026 that will be the Commission for the Development and Security of Artificial Intelligence. And yet risk classification and fundamental rights impact assessment appear in its question list.
That makes sense, because from an organisation's perspective the division of competence between authorities is noise. If you buy a tool for initial candidate screening, you are simultaneously processing personal data under GDPR and operating a system that Annex III to the AI Act classifies as high-risk. Two regimes, two authorities, one purchasing decision — and one set of questions to ask before making it.
The extended version is completed conditionally, where the entry list reveals model building or fine-tuning, or an effect on the legal position of individuals. That second trigger is broad and should be read literally. Legal effects are produced not only by a system rejecting a credit application, but also by a tool that orders a service queue according to predicted customer value, or a model suggesting which case to handle first.
The boundary was drawn by the Court of Justice of the European Union in Case C-634/21 (SCHUFA), which held that generating a score already constitutes automated decision-making under Article 22 GDPR where its recipient in practice follows it. The implication for AI deployments is unforgiving: the line "it is only a recommendation, a human makes the decision" holds only where that human genuinely has the time, the competence and the data to reject it. If an employee approves forty suggestions a day, the oversight is fictional and the system decides on its own — whatever the procedure says.
What the list does not solve, stated plainly
The Office hedged carefully and honestly, so it bears repeating without softening. The questions do not replace a risk analysis, a data protection impact assessment or a fundamental rights impact assessment. They are a starting point for those analyses. They are not a binding interpretation and do not determine GDPR compliance. The answers need not be submitted to the supervisory authority.
That last sentence is often misread. It does not mean a completed list is not worth keeping — it means there is no obligation to file it. The distinction matters, because in an inspection or after a breach a completed, dated and signed list is evidence of accountability under Article 5(2) GDPR. A controller must demonstrate compliance, not merely comply. A document showing that someone asked eighteen questions before deployment and received answers to fourteen is worth more in that moment than a security policy signed three years earlier.
There is also a limitation UODO does not mention, visible in the file format. Checklists distributed as word-processing documents will be completed once, at first deployment, and forgotten. Yet AI tools change faster than any software we have known: the vendor updates the model, adds file analysis, alters the retention policy in its terms. An answer that was true in August may be false by November, so the list needs one more question of your own — the date of the next review.
Who really makes the AI purchasing decision
This brings us to the point that is absent from the announcement but follows directly from it. In the classic procurement model, IT buys the system and legal reviews the contract. AI tools broke that pattern, because they are cheap, self-service and sold directly to business units.
The consequence is that the decision about which categories of data will reach an external model is taken by someone who has never seen the record of processing activities. Not through recklessness — from their perspective this is simply a productivity purchase, not a new processing activity with a new recipient and a new transfer. Until the organisation has a place where those two perspectives meet, no checklist will work.
There is one more reason the pattern fails to close. Article 4 of the AI Act has, since 2 February 2025, required an adequate level of AI literacy among staff working with these systems — an obligation addressed to the organisation, not to its legal department. In most companies we see, GDPR training happens once a year and contains not a word about generative models, while training on the AI tool is delivered by the vendor and contains not a word about personal data. The gap between the two is exactly where incidents are born.
The value of the UODO publication therefore lies not in the wording of the questions but in the pretext it creates for building that meeting point. Introducing the rule that "every tool processing work content passes through the entry list" is a change to a process, not to a document. Process changes are hard to drive without an external reference point — and material carrying the supervisory authority's name is precisely such a point.
Wiring the initial questions into procurement
Practical implementation comes down to three decisions, none of which requires a budget.
First, the threshold. You must establish at what point a tool falls within the procedure. Tying this to price does not work, because the riskiest tools are often free. A sensible threshold is functional: the procedure covers every tool into which an employee enters content created at work, regardless of whether anyone paid for it.
Second, the owner. The entry list needs a recipient who collects it and judges whether the case calls for the extended version. In smaller organisations this will be the data protection officer; in larger ones, a designated person in procurement working with the DPO. The critical point is that it must not be the requester — someone who wants a tool is a poor reviewer of their own request.
Third, the consequence of refusal. A procedure after which everything is approved anyway teaches employees that it is a formality. There must be a real path to rejection and, more importantly, a path to conditional approval with restricted data categories. The most common honest outcome is not "no", but "yes, without customer personal data and without documents marked confidential".
It is also worth using the window the Office has left open. Until 30 September 2026, comments and experiences from using the lists can be sent to pytania_inicjalne@uodo.gov.pl and will feed into an update of the material. An organisation that tests the checklist on three real purchases and sends back its notes does more than discharge an obligation — it helps shape the tool it will later rely on.
Why Fib.Code: GDPR-compliant AI deployments
Fib.Code combines three capabilities that this subject requires in combination: data protection officer practice, information security expertise at the level of ISO/IEC 27001, and the technical experience to verify what a tool actually does with data rather than what its product page promises. A vendor conversation without that third layer ends with marketing copy transcribed into documentation.
We work to three principles. First, inventory before policy — you cannot write sensible rules for tools you do not know exist. Second, one decision, one record — every tool approval ends with a dated note stating the permitted data scope and the name of the person who decided. Third, reviews in the calendar, because the tool changes faster than the document describing it.
The outcome is a set ready to place in front of an inspector: a register of AI systems with assigned risk category and legal basis, completed entry lists for every tool, impact assessments where required, a generative-AI usage policy with a clear catalogue of prohibited data, and a review schedule that keeps all of it current.
What to do this weekend: inventory your AI tools
Download the version matching your organisation's profile from the UODO website and call a forty-five-minute meeting for Monday with the person responsible for IT, the data protection officer and one representative of the department that most often reaches for new tools. Work through six questions, noting a name and a deadline against each.
First: which AI-based tools do we actually use, distinguishing those bought by the company from those started independently by employees? Second: which of them receive content containing personal data or trade secrets? Third: for which do we hold a signed processing agreement, and for which merely accepted terms of service?
Fourth: is the use of our data for model training enabled by default in any tool, and who will check the settings by the end of the week? Fifth: does any of these tools affect the legal position of individuals — candidates, employees, customers, residents — because that triggers the extended version and an impact assessment. Sixth: from Monday, who is accountable for ensuring the next tool does not enter the organisation without passing through the entry list?
If the first question reveals that nobody can name every tool in use, you have your answer on where to start — and the company of nearly 96 per cent of respondents who admitted they are not prepared.
Get in touch: l.grabowski@fibcode.com | fibcode.com/en/contact. Directly related reading: shadow AI, or how data leaves a company with nobody deciding, what actually took effect on 2 August 2026 under the AI Act, the Polish AI Act, KRiBSI and supervision from November — three layers of the same puzzle: practice, obligation, and the authority that will enforce it.
