Strona główna / Artykuły

AI Act and GDPR for AI Automation in the EU: What Applies When

AI Act dates after the 2026 Digital Omnibus, where back-office automation falls, and the GDPR points we design for: minimisation, processors, Article 22, DPIA.

Wydawca: REACTAPP.TOP3 min czytania743 słów

Artykuł opublikowany po angielsku.

Companies in the EU that automate work with AI deal with two sets of rules at once: the GDPR, which has applied since May 2018 and covers personal data whether or not AI is involved, and the AI Act, Regulation (EU) 2024/1689, which is coming into application in stages. This is an engineer's summary of what we design for when we build AI automation. It is not legal advice; for your own case, talk to a lawyer or your data protection officer.

The AI Act timeline as of November 2026

The AI Act entered into force on 1 August 2024 and applies in steps. In July 2026 it was amended by the Digital Omnibus on AI, Regulation (EU) 2026/1744, which moved the dates for high-risk systems. The current picture:

DateWhat applies
2 February 2025Prohibited AI practices (Article 5) and AI literacy (Article 4, since amended by the Omnibus)
2 August 2025Obligations for providers of general-purpose AI models, governance and penalties
2 August 2026General date of application, including most transparency obligations
2 December 2026Deadline for marking AI-generated content for systems placed on the market before 2 August 2026
2 December 2027High-risk rules for stand-alone systems listed in Annex III
2 August 2028High-risk rules for AI embedded in products covered by Annex I legislation

Dates and details can change again through further amendments and guidance, so check the official sources before relying on them.

Where typical business automation falls

The AI Act sorts systems by use, not by technology. Most back-office automation, such as extracting invoice data, checking supplier certificates against a list of requirements or summarising contracts for an internal reviewer, is not in the high-risk categories. High-risk uses are listed in Annex III and include areas like recruitment and worker management, creditworthiness assessment of individuals, access to essential services, education and critical infrastructure.

That line is worth checking early. A tool that ranks job applicants or decides who gets a loan is a very different project from one that reads delivery notes, even if the code looks similar.

Even outside high-risk, some obligations apply: companies are expected to support AI literacy among staff who use these systems, people should be told when they are talking to a chatbot, and certain generated content has to be marked as such.

What the GDPR already requires

For most document automation the GDPR is the bigger day-to-day concern, because contracts, invoices and HR files contain personal data. The points we design around:

  • Lawful basis and purpose. Data collected for one purpose cannot simply be reused for training or a new analysis.
  • Data minimisation. Process only the fields the task needs; mask or drop the rest before it reaches a model.
  • Processors and transfers. Every external service that sees personal data, including a cloud model API, is a processor that needs a data processing agreement, and transfers outside the EEA need a valid mechanism.
  • Automated decisions. Article 22 restricts decisions based solely on automated processing that have legal or similarly significant effects on a person. A human who really reviews the case, with the authority to change the outcome, is the usual design answer.
  • Impact assessment. Processing likely to result in a high risk to individuals needs a data protection impact assessment before it starts.
  • Retention and access. Raw files, extracted data and logs need defined retention periods and role-based access.

Design choices that make compliance easier

Most of what the rules ask for is also good engineering:

  • keep a log of what the system did, with which model version, and who approved the result;
  • keep a person in the loop for decisions about people, and make the review real, with the source document visible;
  • run models on infrastructure you control when the data is sensitive (see local AI for confidential documents);
  • maintain a test set and measure accuracy before and after every change (see evaluations and human review);
  • write down what the system is for and what it must not be used for.

Official sources

  • AI Act: Regulation (EU) 2024/1689 on EUR-Lex
  • Digital Omnibus on AI: Regulation (EU) 2026/1744 on EUR-Lex
  • GDPR: Regulation (EU) 2016/679 on EUR-Lex
  • The European Commission's AI Act pages and the guidance of your national data protection authority

We build AI automation with logging, human review and data minimisation from the first prototype. See demo to production and AI agents for document review. Legal assessment of your specific case stays with your lawyers.