A practical guide for lawyers, Data Protection Officers (DPOs) and compliance officers. GDPR Articles 5/6/9/22/32/35, Schrems II, the EU-US Data Privacy Framework, AI Act 2024/1689, DPIA for on-premise AI, the CNIL approach and the Polish DPA trend in 2024-2026 - all in one place, with verbatim quotes from the legal acts and links to official sources. RODO is the Polish equivalent of GDPR; throughout this article we use the international term GDPR.
The General Data Protection Regulation (GDPR - known in Poland as RODO; Regulation (EU) 2016/679) entered into force on 25 May 2018 and remains the foundational act for every AI deployment in the European Union. The AI Act of 2024 does not replace the GDPR - it operates alongside it, and where personal data is concerned the GDPR takes precedence. For a compliance officer this means that on-premise AI is not "GDPR-safe by design" simply because the slogan "server in Poland" appears on a slide. It is a defensible GDPR path when the architecture, contracts and controls minimise transfer, telemetry and audit-trail risks. Below are six GDPR articles worth knowing verbatim and by name.
Article 5 GDPR defines seven processing principles: lawfulness, fairness and transparency, purpose limitation, data minimisation, accuracy, storage limitation, integrity and confidentiality, and accountability. These are the principles almost every Polish DPA decision relies on. An on-premise architecture supports minimisation (data physically does not leave the organisation), it caps retention (the controller has physical control over the lifecycle of the logs) and it strengthens accountability (the entire audit trail is local, exportable, and signed with a hash).
Article 6 GDPR lists six legal bases for processing of ordinary personal data: consent (point a), contract (point b), legal obligation (point c), protection of vital interests (point d), task carried out in the public interest (point e), and legitimate interest (point f). For private-sector AI the most common bases are contract (e.g. serving an accounting firm's client) or legitimate interest (e.g. an internal compliance assistant), provided that a balancing test (LIA - Legitimate Interest Assessment) has been performed and documented.
Article 9 GDPR prohibits the processing of data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic data, biometric data, data concerning health and data concerning a natural person's sex life or sexual orientation, unless one of the ten exceptions in paragraph 2 applies (including explicit consent, employment law, vital interests, political or religious activity, data manifestly made public by the data subject, legal claims, important public interest, preventive medicine, archiving, and scientific research). For law firms handling medical malpractice cases or for accounting firms running HR services in the medical sector this means that any prompt to an external LLM may contain special categories of data, and the processing itself requires both an Article 6 basis and an Article 9(2) exception. That bar is very high for SaaS AI; it is considerably lower for on-premise.
Article 22 GDPR sits at the heart of every discussion about AI and automated decision-making. It establishes the right of the data subject not to be subject to a decision based solely on automated processing, including profiling, that produces legal effects or similarly significantly affects them. The full text (verbatim quote, reused 1:1 from research GAPS section 4.4):
"1. The data subject shall have the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning him or her or similarly significantly affects him or her.
2. Paragraph 1 shall not apply if the decision: (a) is necessary for entering into, or performance of, a contract between the data subject and a data controller; (b) is authorised by Union or Member State law to which the controller is subject and which also lays down suitable measures to safeguard the data subject's rights and freedoms and legitimate interests; or (c) is based on the data subject's explicit consent.
3. In the cases referred to in points (a) and (c) of paragraph 2, the data controller shall implement suitable measures to safeguard the data subject's rights and freedoms and legitimate interests, at least the right to obtain human intervention on the part of the controller, to express his or her point of view and to contest the decision.
4. Decisions referred to in paragraph 2 shall not be based on special categories of personal data referred to in Article 9(1), unless point (a) or (g) of Article 9(2) applies and suitable measures to safeguard the data subject's rights and freedoms and legitimate interests are in place."
The practical implications of Article 22 for on-premise AI are very concrete. First, if an AI system recommends a decision (e.g. "approve this invoice because it matches the white list") and the human merely clicks "OK" without a real assessment, a supervisory authority may treat that as an automated decision within the meaning of Article 22. Second, paragraph 4 expressly forbids basing automated decisions on special categories of data (Article 9), unless very narrow conditions are met. Third, on-premise makes the duty of "human intervention" easier to satisfy: the model, the context and the reasoning chain all stay local and interpretable - in contrast to a "black box" sitting in someone else's cloud.
Article 32 GDPR requires the controller and the processor to implement "appropriate technical and organisational measures" proportionate to the risk. The Polish DPA practice in 2024-2026 makes it clear that the authority looks at risk analysis as the foundation - the PLN 40,000 fine for SPZOZ Pajęczno (Polish DPA decision, 2024) was imposed precisely for the absence of such an analysis prior to a ransomware attack. By default, on-premise AI shrinks the attack surface: fewer transfers outside the customer environment, no product call-home by default and less dependence on external sub-processors in the chain.
Article 35 GDPR requires a DPIA when processing - in particular using new technologies - is likely to result in "high risk" to the rights and freedoms of natural persons. Paragraph 3(b) explicitly flags large-scale processing of special categories of data under Article 9 or data relating to criminal convictions under Article 10 as cases that require a DPIA. Deployments of AI in a medical law firm, a labour law firm processing biometric employee data, or an accounting firm serving medical clients almost always require a DPIA. Details follow in section 5.
Mapping on-premise AI onto the six GDPR articles: Article 5 (minimisation - data physically does not leave the premises), Articles 6 and 9 (an internal audit trail makes documenting the legal basis easier), Article 22 (interpretability with citations rather than a black box), Article 32 (control over the security measures themselves), Article 35 (a DPIA that is shorter because it does not need to cover US transfers, Schrems II, the Cloud Act, FISA 702, or sub-processor chains). For more context on the very concept of "private AI" - and how it differs from "local" or "on-premise" - see /en/docs/private-ai-fundamentals.
On 16 July 2020 the Court of Justice of the European Union (CJEU) handed down its judgment in case C-311/18 (Data Protection Commissioner v Facebook Ireland Ltd, Maximillian Schrems) - a ruling that reshaped the architecture of global compliance. The CJEU struck down the Privacy Shield adequacy decision (the previous EU-US transfer framework) and left the validity of the Standard Contractual Clauses (SCC) as a basis under Article 46 GDPR, but with one fundamental caveat: SCC are valid only if the destination country provides protection "essentially equivalent" to that in the EU and the controller has performed a Transfer Impact Assessment (TIA) and put additional safeguards ("additional measures") in place where the assessment shows gaps.
The most editorially powerful passage of the judgment is paragraph 184. The CJEU writes that the protection afforded by the transfer mechanism must be "actionable in practice" - not just a formal contractual statement, but a real, enforceable path of redress when third-country authorities reach for the data of EU subjects. Verbatim quote:
"The protection afforded by that mechanism must, in practice, be actionable."
A short sentence with far-reaching consequences. Every data controller in the EU - be it a Polish law firm, an accounting firm, a hospital, or a municipality - must actually verify whether a US-based SaaS provider is in a position to ensure that US authorities will not reach for client data. A piece of paper is not enough. A Polish enterprise user who pastes a client contract into ChatGPT is, in legal terms, performing a transfer to a third country, and the absence of an adequate "additional measure" exposes the controller to a fine under Article 83 GDPR.
From a DPIA perspective the practice is as follows. If a Polish medical law firm uses Microsoft Copilot in Microsoft 365 with data residency in Frankfurt, the Schrems II assessment must answer two questions: (1) can Microsoft Corporation, as a US entity, be the addressee of a Cloud Act warrant for data stored in Germany? (2) are there "additional measures" - including client-side encryption with a key Microsoft does not hold - that practically rule out access by US authorities? Without a positive answer at both levels the transfer remains risky. Many law firms in 2024-2026 chose the simpler path: blocking cloud AI for medical and legal client data, and instead deploying an on-premise model (e.g. BezChmury 11B v3 or PLLuM) with local RAG.
We continue this logic in section 3 - the 2023 DPF partially lowered transfer risk, but only for certified entities and only within the scope expressly covered by the framework. The Cloud Act and FISA 702 remain in the background.
On 10 July 2023 the European Commission adopted Implementing Decision (EU) 2023/1795 finding that the United States ensures an adequate level of protection for personal data transferred to organisations participating in the EU-US Data Privacy Framework (DPF). This decision is the successor to Privacy Shield and - in the Commission's view - addresses the concerns raised in the Schrems II judgment. For a compliance officer this means that a transfer to a certified DPF participant is, prima facie, permissible under Article 45 GDPR without a separate TIA. But - and this is a critical "but" - only for entities expressly listed on the official DPF list, and only within the scope of their certification.
The official list of DPF participants is published and updated by the U.S. Department of
Commerce at https://www.dataprivacyframework.gov/list.
For the most commonly used AI providers, the status as of 1 May 2026 looks as follows
(source: research FULL plus direct verification of DPF participant pages):
A compliance officer contracting an AI service from a US provider should always check the current status on the DPF list - and write the specific entity into the contract (e.g. "Microsoft Corporation, certificate #6474, scope: Cloud Service Provider") together with the scope of services covered by certification. Brand alone ("Microsoft", "Google", "AWS") is not sufficient: a corporate group may include several entities with different statuses.
The Clarifying Lawful Overseas Use of Data Act (Cloud Act) of 2018 authorises US law enforcement to demand access to data held by providers subject to US jurisdiction - even if the server is physically located in the EU. The mechanism is domestic: it relies on warrants issued by US federal courts. A US company, regardless of the data centre region, is the addressee of such a warrant.
The Foreign Intelligence Surveillance Act, section 702 (FISA 702) goes further: it authorises US intelligence agencies to conduct programmatic surveillance of communications of non-US persons located outside the US, where those communications transit the infrastructure of US "electronic communication service providers". FISA 702 was precisely the centrepiece of the CJEU's argument in Schrems II - the Court found that this surveillance does not meet the test of "proportionality" required by the EU Charter of Fundamental Rights.
The practical consequence for AI workloads is as follows:
The diagram below illustrates how transfer risk shifts after the introduction of DPF (2023) and after the deployment of on-premise (on the client side).
The practical conclusion of section 3: DPF + EU data residency lowers risk but does not eliminate it. On-premise delivers a hard compliance posture without the need to actively manage "additional measures" and without the constant monitoring of the DPF list (which can evolve - for instance if NOYB successfully challenges DPF before the CJEU in a "Schrems III" case, on which we comment cautiously because the timeline cannot be predicted reliably).
Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 (the "AI Act") was published in the Official Journal of the EU, L series, on 12 July 2024 and entered into force on 1 August 2024. The AI Act is the world's first horizontal legal act regulating artificial intelligence - in that sense it has global significance. The purpose of the regulation is set out in Recital 1:
"The purpose of this Regulation is to improve the functioning of the internal market by laying down a uniform legal framework in particular for the development, the placing on the market, the putting into service and the use of artificial intelligence systems (AI systems) in the Union… while ensuring a high level of protection of health, safety, fundamental rights… and to support innovation."
For a compliance officer, Recital 1 is a clear signal: the AI Act is not an act prohibiting AI. It is an act that organises the market, protects fundamental rights and supports innovation at the same time. The same recital can be cited by the deployer as a justification for the project ("the AI Act allows our model if we meet the requirements") and by the client's lawyer ("the AI Act requires you to deploy this safely").
"'AI system' means a machine-based system that is designed to operate with varying levels of autonomy and that may exhibit adaptiveness after deployment, and that, for explicit or implicit objectives, infers, from the input it receives, how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments."
The definition is deliberately broad. It covers both classical ML (a decision-tree classifier) and LLMs (Bielik, GPT, Claude). Three elements are key: (1) machine-based, (2) varying levels of autonomy, (3) inferring from input - generating output. A KSeF assistant that reads an accountant's question and returns a recommendation with a citation to a statute is an "AI system" within the meaning of the AI Act.
The AI Act is designed as a staged act. The schedule:
For a compliance officer in a Polish law firm or accounting firm, the critical year is 2026: 2 August 2026 is the date from which most high-risk systems under Annex III must be fully compliant. Good news: a typical on-premise KSeF assistant or compliance assistant for an accounting firm is not high-risk. The European Commission's official AI Act Service Desk FAQ makes it clear that classification follows from a specific use case in Annex III, not from the mere fact that AI is being used in a given sector. An "internal document assistant" or "Q&A tool" used by an accountant or lawyer does not become high-risk automatically if it does not fit any Annex III category.
What does BezChmury require as an AI system? First, technical documentation - a description of the architecture (BezChmury 11B v3, RAG, local SSoT base of 630 facts), a description of the base model's training data, the intended purpose ("compliance assistant for Polish accounting firms and law firms"), and the limitations (defined scope: KSeF, GDPR, ZUS; out-of-scope domains excluded). Second, transparency to the end user - a notice that the response comes from AI, that it may contain errors, and that every fact carries a source citation. Third, GPAI obligations for the BezChmury 11B v3 model itself (on the SpeakLeash side as the developer). Help for compliance officers is provided by the European Commission's AI Act Service Desk (ai-act-service-desk.ec.europa.eu), which hosts the official FAQ, the AI Act Explorer and contextual help for specific use cases.
Detailed guidance for deploying BezChmury in a client's infrastructure - including audit-ready technical documentation - is available at /en/docs/ksef-bezchmury.
A Data Protection Impact Assessment (DPIA) is required under Article 35 GDPR for any processing operation that presents a high risk. The European Data Protection Board (EDPB) in Opinion 28/2024 of December 2024 explicitly states that for AI one must take into account, among other things, the processing of special categories of data, automated decision-making or profiling, data protection by design (privacy by design) and the DPIA itself. Below is a nine-element DPIA template for an on-premise AI deployment, grounded in the structure of Article 35(7) GDPR and EDPB / Polish DPA guidance.
A DPIA for cloud AI must cover additional chapters: an adequacy assessment of the transfer (Schrems II, DPF, SCC, TIA), an inventory of sub-processors (each in a separate table with location and DPF status), Cloud Act / FISA 702 risk, redress mechanisms for data subjects, "additional measures" (including client-side encryption with a customer-held key - Customer Key, BYOK). A DPIA for on-premise AI is shorter - focus on local security, retention, model risk, but without having to weave together a chain of nineteen sub-processors across three jurisdictions.
A sample DPIA for BezChmury KSeF Private - an example excerpt for an accounting firm serving 80 clients - contains the following entries: purpose = "local KSeF and compliance assistant", legal basis = Article 6(1)(b) (contract) plus Article 6(1)(f) (legitimate internal interest), categories of data = accounting data (NIP, REGON, address, contact data, invoice amounts), AI log retention = 24 months, measures = AES-256 disk encryption, RBAC, audit log with a hash of every query, no transfer to the US, no external telemetry. Residual risk after measures: low. Consultation with the Polish DPA: not required. This outline is a starting point, not a finished document - every organisation has its own specifics and its own DPO.
The Commission nationale de l'informatique et des libertés (CNIL) is the French data protection regulator - the counterpart of the Polish DPA (UODO). Since 2024 CNIL has been running an action plan for generative AI that has become one of the most important soft interpretive sources for European compliance. CNIL does not ban AI; it requires "responsible deployment" - a deployment grounded in a documented risk assessment.
Five CNIL priorities in the AI area (based on the official action plan and guidance):
"This guide will therefore be relevant for some of the data processing necessary for the design of AI systems, including generative AIs."
CNIL has also published five Q&As on generative AI that are the most practical compilation of the EU interpretive direction. The most important answers: (1) yes, generative AI may process personal data, but it requires a DPIA and transparency; (2) consent is not always required - legitimate interest (Article 6(1)(f)) is often sufficient if it has passed a balancing test; (3) training data may be personal data and requires assessment - in particular the scraping of public data does not exempt anyone from GDPR; (4) output data may contain personal data and must be treated analogously to input data; (5) on-premise and local models reduce the risk surface but do not exempt anyone from a DPIA.
The practical lesson for Polish compliance: the Polish DPA is likely to follow a similar path. Polish decisions in 2024-2026 (section 7) show that the authority focuses on risk analysis, mitigation measures and documentation, rather than on banning specific technologies. A compliance officer who keeps up with the current CNIL writing has a sound basis for designing a DPIA - including for on-premise deployments.
The Polish DPA (UODO - Urząd Ochrony Danych Osobowych) shifted the emphasis of its decisions in 2024-2026 from formal information-duty defects towards risk analysis, appropriate technical and organisational measures (Article 32), and breach notification deadlines (Articles 33 and 34). Four concrete cases worth knowing:
Polish DPA notice of 13 August 2024. A hacker attack covered a wide range of patient and employee data: health data, PESEL numbers, bank accounts, identity documents and passwords. The Polish DPA found that security measures were insufficient (Article 32) and the risk analysis was deficient. This is the largest Polish DPA fine of 2024 against a private entity.
Ransomware attack. The Polish DPA found that the controller had not performed the risk analysis required before implementing security measures (Articles 24, 32, 34). The decision is an important precedent for the public sector - it shows that the Polish DPA looks at process, not only at the outcome of an incident.
Late breach notification (Article 33: 72 hours from discovery) and delayed notification of the data subjects (Article 34). The case demonstrates that deadlines are hard - the formal 72 hours has operational weight.
Loss of a USB stick containing personal data (including health data). The Polish DPA found a lack of appropriate safeguards on portable media and a missing risk analysis (Articles 5(1)(f), 5(2), 32). A trivial event with very real financial consequences.
In decision DKN.5131.3.2025 the Polish DPA required the controller to state whether it had performed the risk analysis necessary to determine whether the incident resulted in a breach requiring notification to the authority and to the data subjects. This is a directional signal: the regulator does not ask about fashionable AI labels; it asks for a documented procedure. A compliance officer deploying on-premise AI has a real advantage in this context - the local architecture simplifies the documentation (fewer sub-processors, no transfer, local log retention), which translates directly into a higher-quality DPIA.
A note on maximum fines: Article 102(1) of the Polish Personal Data Protection Act caps the maximum administrative fine for public-finance entities listed in Article 9(1)-(12) and (14) of the Public Finance Act at PLN 100,000, and for entities in Article 9(13) at PLN 10,000. For private entities the ceiling under Article 83 GDPR applies - up to EUR 20 million or 4% of annual turnover, whichever is higher.
Practical conclusions for an AI deployment: every implementation in the medical sector or on special categories of data requires a DPIA + a risk analysis + documented measures. On-premise reduces the risk surface by default but does not exempt anyone from the documentation. A case study of a medical law firm that deployed BezChmury in response to a Polish DPA audit is described in /en/case-studies/law-firm-marek.
FAQ
If this article surfaced gaps in your AI deployment or you need a concrete DPIA for on-premise, the fastest path is a 15-minute demo of BezChmury KSeF Private. We will show: (1) the local BezChmury 11B v3 model running with no internet connection, (2) a sample DPIA for an accounting firm and a law firm, (3) the GDPR compliance flow with the audit log and an export for the auditor, (4) integration with your existing ERP / KSeF / white list.
Dominik Witanowski - building BezChmury since 2024. Ten years in IT, a focus on source-backed scoring and private RAG for compliance in the Polish accounting, legal and medical sectors. Since 2026 responsible for the BezChmury product family (KSeF Private, Accountant Private, GDPR Private, Enterprise On-Prem), built around the local BezChmury 11B v3 model (SpeakLeash + ACK Cyfronet AGH) and an SSoT base of 630 verified facts. Deployments use an on-premise architecture, GDPR-aware controls and minimisation of transfers outside the customer environment.
Disclaimer. This article is informational material and does not constitute legal advice. Compliance decisions concerning on-premise AI, DPIAs, transfers to third countries and the classification of AI systems within the meaning of the AI Act should be taken in consultation with a DPO, legal counsel or tax adviser appropriate to your organisation. All quotes from legal acts come from official sources (EUR-Lex / CURIA / Polish DPA / CNIL); in case of any editorial doubt please verify against the direct text of the document.
LISTA BETA · ZNIŻKA 30% PRZED LAUNCH
Dołącz do listy beta – ekskluzywny krąg wczesnych testerów BezChmury. Co 2 tygodnie wysyłam dziennik dewelopera: co buduję, co łamie, co decyduję.
SŁOWNIK POJĘĆ
ŹRÓDŁA
Wszystkie cytaty dosłowne w artykule pochodzą z powyższych oficjalnych źródeł.
Inline odniesienia oznaczone [N] linkują do tej listy.
A short KSeF Private demo (15 min). We will show local execution, control questions, source base and how BezChmury reduces the risk of hallucinations.