Running your own model in a Polish data centre makes self-hosted AI compliance easier on one specific point: your data never reaches a third-party API provider and never leaves the European Economic Area. It does not remove a single obligation under the GDPR, the AI Act, NIS2 or DORA. This article sets out what self-hosting changes, what it does not, and how to document an AI system before an audit.
The question comes up whenever a business team wants to connect a language model to contracts, customer records or HR files. On top of the GDPR, three newer frameworks apply: the EU Artificial Intelligence Act, the NIS2 Directive (transposed in Poland through an amendment to the National Cybersecurity System Act, known as KSC) and DORA for the financial sector. We describe the legal position as of November 2026, from the perspective of a team that runs GPU servers and carries out compliance audits. This article is for information only and is not legal advice.
Where your data goes when you use a public AI API
Under the GDPR, sending a prompt to a public model means a processor is handling your data. Here is what actually leaves the company:
- Prompts and outputs. A pasted contract clause, CV or customer complaint goes to the provider with all the personal data in it.
- Logs and retention. Providers keep requests for a period, e.g. to detect abuse; how long depends on their plan and contract, not on you.
- Sub-processors. Behind an API there is usually a chain of model vendor, cloud provider and support contractors, each of which you have to know about and approve.
- Transfers outside the EEA. Many providers process data in the US, relying on the EU-US Data Privacy Framework or standard contractual clauses. These are lawful mechanisms, but the CJEU struck down the two previous bases for EU-US transfers, so a change in the legal landscape is not a theoretical risk.
- Use for training. Consumer plans may use data to improve models by default. Business plans usually do not, but check the contract, not the marketing page.
Then there are staff using personal AI accounts because the company offers no alternative; see how to avoid data leaks to public AI tools.
What a self-hosted model in Poland changes, and what it does not
What changes
An open-weight model running on a GPU server in Poland removes the API provider and its sub-processors from the processing chain. Data stays in the EEA, so Chapter V of the GDPR on international transfers does not apply. You configure logging, retention and backups yourself. You know exactly which model version is answering, which matters for reproducibility and for explaining outputs later. Our guide to self-hosted LLMs for business covers choosing the model, hardware and operating model.
If the server sits with an infrastructure provider (rental or colocation), that provider is still a processor, but it is one known company in Poland with a data processing agreement, not a chain of companies across several jurisdictions.
What does not change
- You are still the controller. You remain responsible for the legal basis, purpose limitation, data minimisation and informing data subjects.
- A DPIA may still be mandatory. Article 35 GDPR applies to high-risk processing wherever the server is. Assessing candidates, processing health data or profiling customers usually requires one.
- Access control. A RAG system connected to an entire file share will show HR documents to a sales rep unless you carry permissions through to the retrieval layer.
- Logging and retention. Prompt logs are themselves personal data. Decide who can read them and when they are deleted.
- Data subject rights. Access, rectification and erasure also apply to vector indexes and fine-tuning datasets.
- Application security. Prompt injection, leaks through model outputs and over-privileged agents are as real on your server as in the cloud.
The AI Act: roles, risk categories and the timeline as of November 2026
The AI Act (Regulation (EU) 2024/1689) entered into force on 1 August 2024 and applies in stages. In July 2026 the timeline was amended by Regulation (EU) 2026/1744, the “Digital Omnibus on AI”. It was published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026, a few days before the original deadline for high-risk systems.
| Obligations | Apply from |
|---|---|
| Prohibited practices (Art. 5) and AI literacy (Art. 4) | 2 February 2025 |
| General-purpose AI (GPAI) models, for model providers | 2 August 2025 |
| Transparency obligations (Art. 50), e.g. telling people they are interacting with AI | 2 August 2026, with a transition until 2 December 2026 for marking content from systems already on the market |
| New prohibitions added by the Omnibus (incl. non-consensual intimate content) | 2 December 2026 |
| High-risk systems listed in Annex III (e.g. recruitment, credit scoring) | 2 December 2027 (originally 2 August 2026) |
| High-risk systems in products covered by Annex I (e.g. medical devices) | 2 August 2028 (originally 2 August 2027) |
National enforcement is being set up too: Poland’s Act on Artificial Intelligence Systems has been in force since 11 August 2026, with provisions on inspections and penalties applying from 28 October 2026. The postponement is no reason to wait: high-risk deployments need process and documentation changes, and the GDPR applies in full today.
Provider or deployer
The AI Act distinguishes mainly between the provider, who develops an AI system and places it on the market under its own name, and the deployer, who uses a system in its own operations. A company running an open-weight model behind an internal assistant is usually a deployer; the original developer remains the GPAI model provider. The line shifts when you:
- offer an AI system to others under your own name or trademark,
- make a substantial modification to a high-risk system, or change a system’s intended purpose so that it becomes high-risk (Art. 25),
- significantly fine-tune a general-purpose model. The Commission’s guidelines tie provider status for a modified model to, among other things, the compute used for the modification. Typical LoRA fine-tuning on company data usually stays well below that, but document it.
Risk categories in practice
| Category | Examples | Consequence |
|---|---|---|
| Prohibited | Emotion recognition of employees and candidates, social scoring, manipulation exploiting vulnerabilities | Must not be used |
| High-risk (Annex III) | CV screening and candidate evaluation (point 4), creditworthiness assessment of individuals (point 5), grading students (point 3) | Full set of requirements: human oversight, logs, data quality, informing affected people |
| Limited (transparency) | Customer chatbot, generated images and video | Disclose that users are dealing with AI, label content |
| Minimal | Document summaries, translation, coding assistant, search across internal procedures | No specific AI Act requirements; GDPR and security still apply |
Most business uses of LLMs are minimal-risk. Recruitment is where companies most often stray into high-risk territory unawares; see AI in recruitment and the AI Act.
NIS2: your AI system is part of the supply chain
NIS2 has to be transposed into national law in each Member State. In Poland, the amendment to the KSC Act has applied since 3 April 2026 (Journal of Laws 2026, item 252). Essential and important entities assess for themselves whether they meet the criteria and register, and the act sets transition periods for implementing the requirements. If your organisation is in scope, an AI system with access to production data is one more element of your risk management:
- Supply chain. The API vendor, model publisher and infrastructure provider are ICT suppliers whose risk you assess. Verify the source and checksums of downloaded model weights as for any other software.
- Assets and vulnerabilities. The inference server, vector database and integrations need patching, scanning and access control.
- Incident handling. NIS2 requires an early warning within 24 hours and an incident notification within 72 hours. To establish what leaked through model outputs, you need logs collected centrally, for example in a SIEM.
With a public API, logs, location and model changes sit with the provider; with your own model, they sit with you. If you are unsure whether and how the new rules apply to you, start with a NIS2 audit.
DORA: an AI provider is an ICT third-party provider
DORA (Regulation (EU) 2022/2554) has applied since 17 January 2025 to banks, investment firms, insurers, payment institutions and other financial entities. To DORA, a public AI API is simply a third-party ICT service. That means:
- an entry in the register of information on ICT third-party arrangements,
- mandatory contractual provisions, especially where the service supports critical or important functions,
- an exit strategy for when the provider changes terms, retires a model or goes down,
- a concentration risk assessment, since a handful of large model vendors serve a large share of the market,
- including the AI system in digital operational resilience testing and incident classification.
An open-weight model on a dedicated server in Poland makes the exit strategy simpler: you hold the weights, and the server can be moved or rebuilt. We cover financial use cases (report analysis, KYC, AML) in AI in finance under DORA. A DORA audit covers compliance of the whole ICT environment.
Self-hosted AI compliance checklist: documenting AI before an audit
The minimum for every AI system that works with company data, in the cloud or on your own GPUs:
| Area | What to prepare | Basis |
|---|---|---|
| AI system register | List of use cases: purpose, model and version, input data, business owner, AI Act risk category | AI Act, GDPR (records of processing) |
| AI Act role | A note on whether you are provider or deployer, with reasoning (fine-tuning, own brand, change of purpose) | AI Act Art. 3, 25 |
| Legal basis and DPIA | Legal basis, DPIA for high-risk uses, DPO opinion | GDPR Art. 6, 9, 35 |
| Location and processors | Where servers are, data processing agreements, sub-processor list, any transfers outside the EEA | GDPR Art. 28, Chapter V |
| Access control | Who uses the model, RAG permissions matching source permissions, MFA on admin panels | GDPR Art. 32, NIS2 |
| Logging and retention | What you log (prompts, outputs, metadata), where, for how long, who can see it | GDPR, AI Act (logs for high-risk), NIS2 |
| Supply chain | Source of model weights, licence, checksums, ICT supplier assessment | NIS2, DORA |
| Incidents and continuity | Reporting procedure, exit strategy, backups of configuration and indexes | NIS2, DORA |
| People | AI use policy, training, named people overseeing outputs | AI Act Art. 4 and 26, GDPR |
If you have no security lead in-house to own this list, a vCISO can take the role and merge GDPR, NIS2 and AI Act requirements into one set of documents instead of three.
FAQ: frequently asked questions
Is using ChatGPT at work GDPR compliant?
It can be, with a data processing agreement, known sub-processors and locations, a lawful basis for transfers outside the EEA, and clear rules on what staff may enter. Personal accounts are the usual problem.
Does a self-hosted AI model in the EU make you GDPR compliant?
No. It removes the transfer to an API provider and outside the EEA, but you remain the controller and still need a legal basis, access control, log retention rules and, where required, a DPIA.
When do AI Act high-risk obligations apply?
Following Regulation (EU) 2026/1744, obligations for Annex III systems such as recruitment tools apply from 2 December 2027, and for systems embedded in Annex I products from 2 August 2028. The Article 5 prohibitions have applied since February 2025.
Is a company using an open-source model a provider under the AI Act?
Usually not; internal use makes you a deployer. You become a provider if you offer the system under your own name, substantially modify a high-risk system or repurpose a system as high-risk.
Does DORA prohibit public AI models?
No, but it treats them like any other ICT third-party service: register of information entry, required contract terms, an exit strategy and a concentration risk assessment.
Want to run AI on infrastructure in Poland and have it audit-ready from day one? See our GPU servers in a Tier III, ISO 27001 certified data centre and get in touch. We will help you size the hardware and prepare self-hosted AI compliance documentation for the GDPR, the AI Act, NIS2 and DORA.