77 officer roles, all coveredArt. 33 GDPR, 72 hours to report a breach93 controls under ISO/IEC 27001:2022905 ready-to-run audit templates in the workspace§ 130 OWiG, supervisory duty of the management boardOfficer appointment letter, signed, filed, evidencedOne workspace for tasks, trainings, audits, documentationDIN 14095 fire protection plans, standardisedEU AI Act, the first horizontal AI regulation worldwide77 officer roles, all coveredArt. 33 GDPR, 72 hours to report a breach93 controls under ISO/IEC 27001:2022905 ready-to-run audit templates in the workspace§ 130 OWiG, supervisory duty of the management boardOfficer appointment letter, signed, filed, evidencedOne workspace for tasks, trainings, audits, documentationDIN 14095 fire protection plans, standardisedEU AI Act, the first horizontal AI regulation worldwide
EU AI Act Compliance: Obligations, Risk Tiers, and Operational Playbook
Governance & Compliance

EU AI Act Compliance: Obligations, Risk Tiers, and Operational Playbook

11 July 202613 min readBy Dr. Henrik Bauer
CIVAC

The EU Artificial Intelligence Act entered into force on 1 August 2024 with staggered application dates running to August 2027. This guide explains the risk-based regime, the obligations for providers and deployers, and the operational steps that make AI Act compliance audit-ready.

Regulation (EU) 2024/1689, known as the EU Artificial Intelligence Act, entered into force on 1 August 2024 following its publication in the Official Journal on 12 July 2024. Application is staggered: prohibitions under Article 5 and AI literacy duties under Article 4 became applicable on 2 February 2025, governance rules and obligations for general-purpose AI (GPAI) models took effect on 2 August 2025, and the core obligations for high-risk AI systems begin on 2 August 2026. The full regime, including extended transition rules for AI systems embedded in regulated products, applies from 2 August 2027. The Act is the first horizontal, binding AI law in any major jurisdiction and applies extraterritorially to any provider placing AI systems on the EU market or whose outputs are used in the Union under Article 2.

For European compliance officers, the AI Act adds a new vertical to the existing GDPR, NIS-2, and ISO/IEC 27001:2022 stack. This article sets out the risk tiers, the obligations that attach to each tier, the specific deadlines you must meet, the documentation that a competent authority will ask to see, and the operational platform choices that determine whether your organisation lands in audit-ready territory or in the line of fire of Article 99 penalties, which run up to 35 million euro or 7 percent of worldwide annual turnover for the most serious infringements. The deadline runs from the date of knowledge of an issue, so a robust intake and triage process is now non-negotiable.

Auf einen Blick

  • The EU AI Act applies a four-tier risk model and assigns the heaviest obligations to providers and deployers of high-risk systems under Annex III.
  • AI literacy under Article 4 has been mandatory since 2 February 2025; the core high-risk obligations apply from 2 August 2026.
  • Penalties under Article 99 reach 35 million euro or 7 percent of worldwide annual turnover for prohibited practices and material non-compliance.

Regulatory Architecture: A Four-Tier Risk Model

The EU AI Act organises obligations around four risk tiers. Unacceptable-risk practices, listed exhaustively in Article 5, are prohibited. These include social scoring by public authorities, untargeted scraping of facial images to build recognition databases, real-time remote biometric identification in publicly accessible spaces (with narrow law-enforcement exceptions), emotion recognition in workplaces and educational settings, and certain forms of predictive policing. High-risk systems, defined in Article 6 and Annex III, cover use cases in critical infrastructure, education, employment, essential private and public services, law enforcement, migration, and the administration of justice. Annex I adds high-risk classification for AI systems that are safety components of products regulated under existing Union law (medical devices, machinery, toys, lifts, in vitro diagnostics, and more).

Limited-risk systems, primarily chatbots, deepfakes, and generative content, must comply with the transparency obligations in Article 50, including labelling of AI-generated text, audio, image, and video. Minimal-risk systems, the residual category, face no Act-specific obligations but remain subject to general product-safety and consumer-protection law. For European compliance officers, the architecture maps to the work of the compliance officer: classification of every in-scope system, allocation of provider or deployer status, and continuous monitoring of the AI inventory as new use cases are deployed across business units. Article 4 imposes an additional cross-cutting duty: ensuring sufficient AI literacy of staff who operate or use AI systems on the organisation's behalf. The risk-tier classification is the gateway exercise: without a clean inventory and a defensible tiering decision per system, every downstream obligation becomes brittle and any audit becomes a fishing expedition.

Provider Versus Deployer: Who Carries Which Duties

The Act distinguishes sharply between providers (Article 3(3)) and deployers (Article 3(4)). A provider develops an AI system or has one developed and places it on the market or puts it into service under its own name or trademark. A deployer uses an AI system under its authority, except where the use is purely personal and non-professional. Most enterprises will be deployers for third-party AI tools (Microsoft Copilot, OpenAI ChatGPT Enterprise, Google Gemini for Workspace, Salesforce Einstein) and may simultaneously be providers if they develop or substantially modify an AI system for internal or external use.

Provider obligations for high-risk systems are extensive: risk management system (Article 9), data and data governance (Article 10), technical documentation (Article 11 and Annex IV), record-keeping (Article 12), transparency and information to deployers (Article 13), human oversight (Article 14), accuracy, robustness, and cybersecurity (Article 15), quality management system (Article 17), conformity assessment (Article 43), CE marking (Article 48), and registration in the EU database (Article 49 and 71). Deployers carry lighter but still substantive obligations under Article 26: instructions for use, human oversight, monitoring, logging, fundamental rights impact assessment for certain deployers (Article 27), and a duty to inform affected persons in specific scenarios. The provider/deployer split must be documented per system in a structured AI register, which the CIVAC workspace provides as a managed template. Article 25 contains additional rules that can switch a deployer into a provider position: putting one's name or trademark on a high-risk system, substantial modification, or modifying the intended purpose of a system not originally classified as high-risk in a way that brings it within Annex III. These transitions are easy to overlook in fast-moving product teams and must be captured by a change-management trigger inside the AI register, not by ad-hoc legal review.

GPAI Models: The Article 51 to 55 Regime

General-purpose AI models, defined in Article 3(63) as models that display significant generality and competence to perform a wide range of distinct tasks, were brought into application on 2 August 2025. Articles 51 to 55 set out the obligations. All GPAI providers must produce and maintain technical documentation of the model (Article 53(1)(a) and Annex XI), provide information to downstream providers integrating the model (Article 53(1)(b) and Annex XII), implement a copyright compliance policy reflecting Directive (EU) 2019/790, and publish a sufficiently detailed summary of training content. Open-source models benefit from a partial carve-out, but only if their parameters and weights, including model architecture and usage information, are publicly available under a free and open-source licence.

GPAI models with systemic risk, identified through training-compute thresholds (10^25 FLOPs) or designation by the European Commission, carry additional duties under Article 55: state-of-the-art model evaluation including adversarial testing, systemic-risk assessment and mitigation, serious-incident reporting to the AI Office, and adequate cybersecurity protection. The Commission has published a voluntary GPAI Code of Practice, which becomes the principal compliance reference for providers until harmonised standards are adopted. Deployers integrating GPAI into their products must verify that providers have met their obligations and document the integration boundary in the AI register. The dual-model nature of CIVAC applies here: licence the workspace for your internal officers, or have our officers appointed for you. Either way, a structured GPAI sub-register sits inside the platform. The sub-register captures the model identifier, version, provider, downstream integration points, copyright policy reference, training summary reference, and the contractual licence terms, so that downstream conformity assessments under Article 43 can rely on a stable upstream record.

Article 4 AI Literacy: The Often-Overlooked Foundation

Article 4 of the AI Act, applicable since 2 February 2025, requires providers and deployers to take measures to ensure, to the best of their ability, a sufficient level of AI literacy of their staff and other persons dealing with the operation and use of AI systems on their behalf. The obligation is framed broadly and is not limited to high-risk systems. It covers technical knowledge, experience, education, and training, and must consider the context of use and the persons or groups on which the AI is to be used. The European AI Office has published guidance suggesting role-based training pathways, regular refreshers, and documented learning outcomes.

Operationally, AI literacy is a compliance officer's deliverable. The CIVAC workspace contains role-based AI literacy templates for executives, product managers, HR specialists, customer-service agents, and technical engineers. Each training cycle is logged, the materials are versioned, and the completion record is available for audit. The hallmark applies: bestellurkunde, unterschrieben, abgelegt, belegbar. The same applies to AI literacy: certificate, signed, filed, demonstrable. Without documented training, deployer obligations under Article 26(1) cannot credibly be met, because the duty to operate the system in accordance with its instructions for use presupposes literacy. Linking AI literacy delivery to the deployer obligation under Article 26 in a single platform avoids the common pitfall of treating training as an HR matter detached from compliance evidence. The European AI Office has signalled that literacy will be among the first enforcement priorities, because it requires no harmonised standards and can be assessed from documentation alone.

Conformity Assessment, CE Marking, and the EU Database

High-risk AI systems require conformity assessment before being placed on the market under Article 43. Two routes exist. The internal control route (Annex VI) applies to most high-risk systems and is performed by the provider on its own responsibility, with technical documentation prepared in accordance with Annex IV and conformity declared under Article 47. The third-party conformity assessment route (Annex VII) applies to a narrower set of cases, notably biometric identification systems, and requires involvement of a notified body designated under Article 31. The conformity assessment result is captured in an EU declaration of conformity (Article 47) and the system bears the CE marking under Article 48.

Following conformity assessment, providers must register the system in the EU database for high-risk AI systems (Article 71) before placing it on the market. Public authorities deploying high-risk systems also have a registration duty under Article 49(1)(a). The database is operated by the Commission and includes information from Annex VIII. Substantial modifications, defined in Article 3(23), trigger a new conformity assessment. The audit-fest principle applies in full: documented, dokumentiert, Article 43-fest. Misuse of CE marking or non-registration is a separate Article 99 violation and is regularly the first item examined by a market-surveillance authority during inspection. Providers should also plan for harmonised standards developed by CEN and CENELEC under JTC 21, which will form the presumption-of-conformity layer once published. Until then, the conformity assessment relies on the essential requirements of the Act and on the technical specifications adopted by the Commission. A platform-based controls library that maps each Annex IV element to evidence and to a responsible role shortens preparation time and reduces the risk that documentation drifts out of sync with deployed system versions.

Fundamental Rights Impact Assessment Under Article 27

Article 27 introduces a Fundamental Rights Impact Assessment (FRIA) for specific deployer categories: bodies governed by public law, private operators providing public services, and certain private deployers using high-risk systems for creditworthiness and life and health insurance scoring (Annex III, points 5(b) and 5(c)). The FRIA must be performed prior to the first deployment of a high-risk AI system, must address the processes in which the system will be used, the categories of natural persons likely to be affected, the specific risks of harm, the human oversight measures, and the measures to be taken in case of materialised risks. The deployer must notify the market-surveillance authority of the assessment result via a template provided by the AI Office.

The FRIA dovetails with the GDPR Data Protection Impact Assessment under Article 35 GDPR but is not identical: the FRIA covers all fundamental rights in the EU Charter, not only data protection. A combined DPIA/FRIA workflow makes operational sense and is reflected in the CIVAC compliance workspace, which links data protection assessments to fundamental rights assessments at the system-record level. The competent supervisory authority can request the assessment; the deployer must produce it on demand. Andere führen Compliance wie einen Aktenschrank. Wir führen sie wie Software. The FRIA is the area where this distinction becomes most visible, because the assessment must be live-updated whenever the use context changes, not refiled annually as a static report. The CIVAC workspace links each FRIA to a system-level change log and to the human-oversight role assignment under Article 14, so that a change in oversight personnel automatically triggers a FRIA review task.

Incident Reporting, Post-Market Monitoring, and Logging

Article 72 obliges providers of high-risk AI systems to establish a post-market monitoring system, documented in a plan that is part of the technical documentation under Annex IV. The plan must collect, analyse, and report on the performance of the system throughout its lifetime and feed findings back into the risk-management system under Article 9. Serious incidents, defined in Article 3(49), trigger Article 73 reporting duties: the provider must notify the market-surveillance authority of the Member State where the incident occurred, within 15 days of becoming aware of the incident (Article 73(2)). For incidents causing death the reporting window shortens to 10 days; for widespread infringements and certain critical-infrastructure incidents the window narrows to 2 days under Article 73(3).

Logs generated by high-risk AI systems must be kept for a period appropriate to the intended purpose, at minimum six months unless Union or national law provides otherwise (Article 12(3) and Article 19(1)). Deployers retain logs for the same period. This logging requirement aligns operationally with the 24-hour early-warning and 72-hour follow-up reporting paths required under NIS-2 and with the 72-hour data-breach notification under Article 33 GDPR. A unified incident-reporting workspace that maps AI Act, NIS-2, and GDPR triggers to one intake form prevents the typical mistake of fragmented reporting and missed deadlines. The deadline runs from the date of knowledge, so log-driven detection is essential. The CIVAC workspace consolidates these paths in a single incident register, with role-based escalation and pre-populated notification templates for the relevant authorities in each Member State.

Penalties Under Article 99 and Enforcement Architecture

Article 99 sets three tiers of administrative fines. Tier one, for non-compliance with the prohibition of AI practices in Article 5, reaches 35 million euro or, for undertakings, up to 7 percent of total worldwide annual turnover for the preceding financial year, whichever is higher. Tier two, covering most other obligations of providers and deployers, reaches 15 million euro or 3 percent of worldwide annual turnover. Tier three, for supplying incorrect, incomplete, or misleading information to notified bodies or competent authorities, reaches 7.5 million euro or 1 percent of worldwide annual turnover. Article 101 sets a separate fine regime for GPAI providers, capped at 15 million euro or 3 percent of worldwide annual turnover.

Enforcement is layered. The European AI Office at the Commission supervises GPAI providers directly. National competent authorities, designated under Article 70, supervise providers and deployers within their territory and operate through national market-surveillance authorities. The European Artificial Intelligence Board coordinates the network. The first enforcement actions are expected to target Article 5 prohibitions and Article 4 literacy failures, because both have been applicable since February 2025 and require no harmonised standards to enforce. The CIVAC platform tracks all three tiers of obligations in a single risk register, with mapped controls and an evidence repository, so that an inspector who calls finds the file ready. Reviewing the enforcement posture quarterly and stress-testing the AI register against the latest Commission guidance turns Article 99 from a theoretical risk into a known and managed exposure, and the hallmark applies: der Prüfer ruft an, der Nachweis liegt bereit.

Operationalising AI Act Compliance with CIVAC

The EU AI Act, the GDPR, NIS-2, and the ISO/IEC 27001:2022 Information Security Management System share a common operational backbone: a documented inventory of assets, a structured risk-management process, role-based responsibilities, evidence storage, and incident response. CIVAC is a compliance platform and officer-as-a-service that operationalises this backbone for European organisations. The workspace contains a managed AI system register with provider/deployer classification, automated risk-tier triage, FRIA and DPIA templates linked at the system-record level, AI literacy curricula by role, the GPAI sub-register, an incident-reporting workflow that maps AI Act, NIS-2, and GDPR deadlines, and 490 ready-to-use audit templates. EU data residency on an ISO/IEC 27001:2022 ISMS is contractually fixed.

Licence the workspace for your internal officers, or have our officers appointed for you. Under the officer-as-a-service model, a CIVAC-appointed compliance officer takes operational responsibility for the AI Act regime with a 2-business-day SLA, instead of the 2 to 6 weeks typical of traditional consultancies. Both models satisfy Articles 4, 9, 17, 26, and 72 of the AI Act and can be switched without data migration. Turn reading into a brief, aus dem Lesen einen Auftrag machen: write to info@civac.de or use the contact form on civac.de. A 30-minute baseline call returns a prioritised list of the five most urgent AI Act gaps in your organisation, with concrete next steps and an indication of the regulatory exposure attached to each gap. The output is usable internally whether or not you decide to engage CIVAC operationally, and it doubles as a board-ready briefing document.

FAQ

Which deadline matters most for our 2026 planning under the AI Act?

Two deadlines structure 2026 work. First, AI literacy under Article 4 has been in force since 2 February 2025 and any audit will probe it. Second, the core obligations for high-risk AI systems begin on 2 August 2026. Most enterprises should treat August 2026 as their primary readiness milestone and build the literacy programme in parallel during the first half of the year.

Are we a provider or a deployer when we use OpenAI or Microsoft Copilot?

If you use the tools as offered, you are a deployer. If you substantially modify the system or place it on the market under your own name, you become a provider for that modified system under Article 25. Fine-tuning a foundation model with proprietary data and offering it externally typically crosses the threshold. The classification must be documented per system in your AI register.

Does the AI Act apply to companies based outside the EU?

Yes. Article 2 sets out an extraterritorial scope: the Act applies to providers placing AI systems on the EU market or putting them into service in the Union, regardless of their establishment, and to providers and deployers whose AI outputs are used in the Union. A US software vendor selling to EU customers is in scope, as is a non-EU deployer whose output reaches EU residents through any channel.

How does the AI Act relate to the GDPR?

The two regimes are complementary. The GDPR governs personal data processing; the AI Act governs the AI system itself. A high-risk AI system processing personal data triggers both. A Data Protection Impact Assessment under Article 35 GDPR and a Fundamental Rights Impact Assessment under Article 27 AI Act may share inputs but address different scopes. Running them in a unified compliance workspace avoids duplication and reduces audit friction.

What does AI literacy under Article 4 actually require?

Article 4 requires providers and deployers to take measures to ensure a sufficient level of AI literacy of staff and other persons operating AI systems on their behalf, considering technical knowledge, experience, education, training, and the context of use. Operationally, this means role-based training, completion records, periodic refreshers, and documented learning outcomes that an auditor can verify.

Can CIVAC act as our external AI Act compliance officer?

Yes. Under the officer-as-a-service model, CIVAC appoints an external compliance officer who maintains the AI register, runs the literacy programme, prepares conformity assessments, manages incident reporting, and represents you in audits. Alternatively, you license the workspace for your internal officers and use the templates yourselves. Both models satisfy Articles 4, 17, 26, and 72 of the AI Act.

No obligation

Sounds like a lot of work?

Officer duties, deadlines, paperwork — that's exactly what we take off your hands. Say hello and we'll show you how.

Turn this into a mandate.

Let us carry the operational weight. External officer, templates and documentation in one workspace. No obligation.

Related articles