B8. Regulation and Compliance
Regulation is not a side issue for AI but a design variable of the strategy. The EU AI Act (Regulation 2024/1689) is the world’s first comprehensive AI law and applies extraterritorially: any company that develops, places on the market, or deploys AI systems is covered, provided people in the EU are affected, regardless of where the company is headquartered.
What this chapter delivers: a framing of the obligations, a decision tree for risk classification, the high-risk obligations in detail, and the interlocking with the GDPR, sector supervision, and German labor law. It does not replace legal advice; binding assessments are made together with legal and compliance functions.
As of: July 2026. This overview reflects the Digital Omnibus on AI: approval by the European Parliament on 16 June 2026, final approval by the Council on 29 June 2026. Publication in the EU Official Journal was imminent at the time of writing; the changes enter into force on the third day after publication. Until then, the original deadlines remain legally in force. Sources: European Commission (digital-strategy.ec.europa.eu), Council of the EU (consilium.europa.eu), EU Official Journal. See chapter E2 for how this is kept up to date.
What is the Digital Omnibus? The EU AI Act is the law itself; the Digital Omnibus on AI is an amendment package adopted in 2026 that adjusts the AI Act in specific places without changing its basic architecture. Above all, it postpones the application deadlines of the high-risk obligations, adds one prohibition (Art. 5), and phrases the AI-literacy obligation more softly. Wherever this chapter says “per Omnibus,” one of these changes is meant.
Structure of the chapter: the chapter has three parts. Part 1 applies to all use cases: risk classes, the decision tree for classification, the provider-or-deployer role question, the AI-literacy obligation (Art. 4), and deadlines and sanctions. Part 2 concerns specific constellations only: the obligations of the high-risk class and the rules for GPAI models. Part 3 covers law that applies in parallel with the AI Act: GDPR, sector supervision, and co-determination and liability. Plus two checklists with different jobs: the high-risk checklist is kept per system and sits in Part 2; the operational compliance checklist at the end of the chapter checks the company-wide organization.
Part 1: Foundations for all use cases
This part applies to every AI use case regardless of risk class and role: it settles the classification (risk class and legal role), the AI-literacy obligation, and deadlines and sanctions.
The risk-based approach: four tiers
The AI Act does not regulate the technology but the purpose of use. The higher the risk to health, safety, and fundamental rights, the stricter the obligations.
| Tier | Meaning | Examples | Obligations |
|---|---|---|---|
| Unacceptable risk | Prohibited (Art. 5) | Social scoring, manipulative techniques, certain biometric practices; new per Omnibus: generation of non-consensual intimate imagery and CSAM (transition period until 2 Dec 2026) | Use prohibited |
| High risk | Strictly regulated | Annex III (stand-alone): recruiting, creditworthiness, education, law enforcement, migration; insurance: risk assessment and pricing in life and health insurance. Annex I (embedded): medical devices, machinery, vehicles | Comprehensive provider and deployer obligations, conformity assessment (details in Part 2) |
| Limited risk | Transparency obligation (Art. 50) | Chatbots, generated text, images, audio | Disclosure of AI interaction, labeling of AI-generated content |
| Minimal risk | Free | Spam filters, recommendations, most internal tools | No specific obligations; good practice recommended |
Particularly relevant for the insurance industry: risk assessment and pricing in life and health insurance for natural persons are explicitly listed as high-risk applications under Annex III. Anyone using AI here falls under the most demanding regime of obligations.
Decision tree: which risk class does my use case fall into?
Every use case is checked in order. The check starts with the strictest case (prohibition) and works down to the mildest tier; as soon as one tier applies, the classification is found. The flowchart shows all paths and branches at a glance; the criteria for the individual questions are in the legend below it.
The five questions in detail, using the same numbering as the flowchart:
- Prohibited practice? (Art. 5) Does the use fall under Art. 5, e.g., social scoring, manipulative or certain biometric practices? → Yes: unacceptable risk, not permissible. Stop. No: continue with question 2.
- Annex III area? Does the use touch one of the high-risk areas under Annex III (recruiting, creditworthiness, insurance risk assessment and pricing, education, law enforcement, migration, critical infrastructure)? → Yes: continue with question 3 (exemption check). No: continue with question 4.
- Exemption under Art. 6(3)? Even an Annex III system is not high-risk if it does not pose a significant risk to health, safety, or fundamental rights because it performs only one of the following tasks: a narrow procedural task (e.g., structuring documents), improving the result of a previously completed human activity (e.g., polishing text), detecting patterns or deviations without its own decision authority (the human evaluates), or a purely preparatory task. The exemption never applies if the system performs profiling of natural persons. The classification must be documented and must withstand supervisory review. → Exemption applies: not high-risk, continue with question 5. Does not apply: high risk.
- Embedded in a regulated product? (Annex I) Is the AI a safety component of an already regulated product (medical device, machinery, vehicle)? → Yes: high risk. No: continue with question 5.
- Transparency case? (Art. 50) Does the AI interact directly with people or generate content? → Yes: limited risk, disclosure and labeling obligations. No: minimal risk (no specific obligations; good practice such as documentation and testing still recommended).
This is a complete classification: every use case ends in exactly one of the four risk classes. Two obligations, however, apply in addition and independently of the risk class: if personal data is processed, the GDPR applies in parallel (Part 3); anyone who provides a GPAI model themselves also fulfils the GPAI obligations (Part 2).
The decision tree applied to examples
The following use cases show the path through the flowchart. The middle column names the questions in the order in which they are worked through; skipped questions do not appear, because a branch bypasses them. Each example can thus be traced step by step in the flowchart.
| Use case | Path through the flowchart | Classification |
|---|---|---|
| Internal IT helpdesk chatbot | 1 no → 2 no → 4 no → 5 yes | Limited risk: users must be able to recognize they are interacting with AI |
| AI-assisted pre-selection and ranking of job applications | 1 no → 2 yes (employment) → 3 does not apply (ranking is profiling) | High risk: full set of obligations; additionally GDPR (Art. 22) and co-determination (Part 3) |
| Summarizing claims files as work preparation | 1 no → 2 yes (insurance touched) → 3 applies (purely preparatory, no profiling) → 5 no | Art. 6(3) exemption: not high-risk, document the classification; observe GDPR in parallel |
| AI pricing in health insurance | 1 no → 2 yes → 3 does not apply (pricing is the assessment itself and profiling) | High risk, no exemption possible |
Provider or deployer? The decisive role question
After the risk class, the role is the second decisive switch. “Role” means something different here than in chapter B7: there it is about organizational roles (who holds which job in the company), here about the legal role under the AI Act, which determines which set of obligations applies at all. The two levels are independent: the same person can be a product owner organizationally while their company becomes a provider legally. The AI Act distributes its obligations according to whether a company builds and places an AI system on the market (provider) or uses it under its own responsibility (deployer). The same high-risk classification means conformity assessment and CE marking for a provider, but primarily oversight, logging, and information duties for a deployer. Most companies are deployers, but they have obligations of their own and can become providers without noticing.
| Role | Definition | Core obligations (high risk) |
|---|---|---|
| Provider | Develops an AI system or places it on the market under its own name | Risk management, data evidence, technical documentation, conformity assessment, registration (details in Part 2) |
| Deployer | Uses an AI system under its own responsibility | Use according to instructions, ensure human oversight, keep logs, inform affected persons, monitoring (details in Part 2) |
Beware of role changes (Art. 25): anyone who distributes a purchased system under their own name, substantially modifies it, or repurposes it in a way that makes it high-risk becomes a provider with the full set of obligations. Practically relevant: a system heavily adapted through fine-tuning and a custom prompt framework for a new, high-risk purpose can trigger this change. Reassess the role question before every substantial adaptation.
AI literacy (Art. 4)
Besides the system-related obligations, the AI Act contains one cross-cutting obligation that affects every company regardless of risk class and role, and it already applies. That is why it sits here in Part 1: since February 2025, companies must ensure that people who operate or use AI systems have sufficient AI literacy. The Digital Omnibus phrases the obligation more softly (support the development of AI literacy instead of ensure), but this changes little in practice: without evidenced training, neither the deployer obligations (competent oversight persons, Art. 26) nor effective human oversight (Art. 14) can be fulfilled. Practical implementation: role-specific training paths and evidence, see chapter B11.
Current application dates (with Digital Omnibus)
The following overview shows which obligations apply from when. It is the basis of your own implementation planning: each deadline is matched against the use cases in your AI register to see which obligation affects which system and when.
| Date | What applies | Status |
|---|---|---|
| 1 Aug 2024 | Entry into force of the regulation | In force |
| 2 Feb 2025 | Prohibited practices (Art. 5) and AI literacy obligation (Art. 4) | Applies |
| 2 Aug 2025 | Obligations for GPAI models, governance rules, national authorities, sanctions framework | Applies |
| 2 Aug 2026 | Transparency obligations (Art. 50): disclosure of AI interaction, labeling of AI-generated content | Remains in place |
| 2 Dec 2026 | Grace period for watermarking on legacy systems (on the market before Aug 2026); end of transition for the new Art. 5 prohibition | Per Omnibus |
| 2 Dec 2027 | High-risk obligations for stand-alone Annex III systems | Postponed (Omnibus, adopted June 2026), previously 2 Aug 2026 |
| 2 Aug 2028 | High-risk obligations for Annex I systems embedded in regulated products | Postponed (Omnibus) |
Important: Parliament and Council adopted the Omnibus in June 2026; the new deadlines become legally binding with publication in the Official Journal (expected July 2026). The transparency obligations as of 2 August 2026 are not affected by the postponement. Those responsible should use the time gained as an implementation buffer, not as a reason to stand still: the obligations are coming, and data governance, documentation, and oversight concepts need lead time.
Sanctions
Violations are tiered in three levels and can exceed GDPR fines. The higher amount applies in each case; for SMEs and start-ups, the lower one.
| Violation | Fine up to |
|---|---|
| Prohibited practices (Art. 5) | EUR 35 million or 7 % of global annual turnover |
| Violations of other obligations (incl. high-risk obligations, transparency, GPAI) | EUR 15 million or 3 % of global annual turnover |
| False or misleading information to authorities | EUR 7.5 million or 1 % of global annual turnover |
Part 2: Obligations for specific constellations
This part concerns only some of the use cases: the obligations that bite at the high-risk classification, and the rules for GPAI models, which apply in addition when a company provides a base model itself. Anyone whose portfolio contains only transparency or minimal cases after the decision tree, and who provides no models themselves, can skip this part.
High-risk obligations in detail
This section applies exclusively to use cases in the high-risk class, the second tier of the risk pyramid from Part 1. The following table translates the obligations of Art. 9 to 27 into concrete work steps and evidence. It is the working basis for every use case classified as high-risk; the checklist afterwards serves as progress control. Much of the evidence in the right-hand column does not have to be maintained by hand: whoever runs deployment and evaluation through a standardized pipeline generates model cards, test reports, and logs automatically along the way (see chapter B6).
| Obligation (article) | What is concretely required | Typical artifacts and evidence |
|---|---|---|
| Risk management system (Art. 9) | A continuous, documented process across the entire lifecycle: identify risks to health, safety, and fundamental rights, assess them, mitigate them through design and measures, assess and communicate residual risks; testing before placing on the market | Risk register per system (see chapter D3), assessment and test protocols, documented measures |
| Data and data governance (Art. 10) | Training, validation, and test data must be relevant, sufficiently representative, and as error-free and complete as possible for the purpose; collection procedures, data provenance, and possible biases must be examined and documented | Data cards, quality reports, bias analyses (see chapters B4 and B10) |
| Technical documentation (Art. 11, Annex IV) | Create before placing on the market and keep current: system description and purpose, development process, architecture, training data, performance metrics and limits, risk management, changes over the lifecycle | System file, extended model card, architecture documentation |
| Record-keeping (Art. 12) | Automatic logging of relevant events over the lifetime, to allow tracing of risks and substantial modifications | Logging concept, retention rules, logs (see chapter B9) |
| Transparency toward deployers (Art. 13) | Understandable instructions for use: capabilities, performance limits, known risks, required human oversight, expected lifetime, maintenance | Instructions for use, release documentation |
| Human oversight (Art. 14) | Design systems so that humans can oversee them effectively: ability to intervene and abort, understanding of the limits, safeguards against over-reliance on automation (automation bias) | Oversight concept per use case (see chapter B10), training evidence for oversight personnel |
| Accuracy, robustness, cybersecurity (Art. 15) | Declare and achieve appropriate accuracy, resilience against errors and attacks (incl. AI-specific attacks such as data poisoning and adversarial attacks) | Evaluation reports with thresholds (see chapter D1), security tests and red-teaming reports (see chapter B9) |
| Quality management system (Art. 17, provider) | Documented QMS: regulatory compliance strategy, design, development, and testing procedures, data management, risk management, incident reporting, responsibilities | QMS manual or integration into the existing QMS/ISMS |
| Conformity assessment (Art. 43) and CE marking (Art. 47, 48) | Before placing on the market: perform the conformity assessment procedure (depending on the case, internal control or with a notified body), issue the EU declaration of conformity, affix the CE marking | Declaration of conformity, assessment report |
| Registration (Art. 49) | Registration of relevant Annex III systems in the EU database before putting into service; also document when the Art. 6(3) exemption is claimed | Registration evidence, documented exemption classification |
| Deployer obligations (Art. 26) | Use according to the instructions for use; oversight by competent, trained persons; checking input data for suitability; monitoring in operation; retention of logs; informing employees and affected persons about the use | Operating concept, training evidence, monitoring reports (see chapter D1) |
| Fundamental rights impact assessment FRIA (Art. 27) | Before putting into service, by certain deployers (public bodies as well as private deployers for, among others, creditworthiness and life/health insurance pricing): describe affected processes and groups of persons, risks to fundamental rights, oversight measures, remedial measures | FRIA document; interlock with the data protection impact assessment, avoid duplicate work |
Checklist: obligations for high-risk systems
This checklist belongs to the high-risk section: it is kept per high-risk system and serves as progress control for the obligations table above. For every use case classified as high-risk:
- Risk management system (Art. 9) established across the entire lifecycle
- Data governance (Art. 10): data quality and biases examined and documented
- Technical documentation (Art. 11) complete and current
- Logging (Art. 12) active, retention regulated
- Instructions for use (Art. 13) available or requested from the provider
- Human oversight (Art. 14) designed, persons named and trained
- Accuracy, robustness, cybersecurity (Art. 15) tested and evidenced
- Quality management system (Art. 17, provider) in place
- Conformity assessment (Art. 43) performed, CE marking where required
- Registration (Art. 49) in the EU database completed or exemption documented
- Deployer obligations (Art. 26) implemented in the operating concept
- FRIA (Art. 27) checked and performed where required
GPAI models (general-purpose AI)
What GPAI is: AI models with a general purpose, i.e., broadly usable foundation models such as large language models (terms in chapter A2). The AI Act regulates them in a dedicated block of obligations that sits alongside the risk classes: the risk classes assess a system’s concrete purpose of use, the GPAI rules the base model behind it. Anyone who provides foundation models or LLMs themselves (including internally after substantial modification) falls under the GPAI rules of Art. 53 ff.:
- All GPAI providers (Art. 53): technical documentation of the model, information and documentation for downstream providers, a policy to comply with EU copyright law (incl. text-and-data-mining reservations), a public summary of the training content.
- GPAI with systemic risk (Art. 51, 55): systemic risk is presumed from a training compute of 10^25 FLOP. Additionally: model evaluations including adversarial testing, assessment and mitigation of systemic risks, reporting of serious incidents, adequate cybersecurity.
- The GPAI Code of Practice (since July 2025) is the practical instrument of evidence: those who join and comply with it can rely on the presumption of conformity.
Most companies are users of purchased models. The provider obligations then rest with the model provider, but the use case built on top must still be classified independently according to its purpose. What users should contractually demand from the model provider: the documentation under Art. 53, assurances on copyright compliance, support with their own transparency and documentation obligations, and clarity on the use of their inputs (no training without consent). The vendor question catalog in chapter B3 contains the matching questions.
Part 3: Law that applies in parallel
This part leaves the AI Act and covers three areas of law that apply independently of it and must be satisfied at the same time in practice: data protection (GDPR), financial and insurance supervision, and German labor and liability law. The three sections below take them in turn.
Interface with the GDPR
The most important parallel is data protection. The rule of thumb for the boundary: the AI Act regulates the AI system, the GDPR the personal data inside it. So the AI Act does not replace the GDPR; both apply in parallel as soon as personal data is processed.
- Legal basis of the processing clarified (consider training, fine-tuning, and operation separately)
- Data protection impact assessment (DPIA) performed where required; interlocked with the FRIA
- Data subject rights (access, erasure, objection) implementable, including for data in knowledge bases and training sets
- Automated individual decisions (Art. 22 GDPR) assessed: where there is legal or similarly significant effect (credit, insurance, recruiting), a solely automated decision is only permissible in narrow exceptions; effective human review must be more than a rubber stamp
- Data processing agreements with model and platform providers in place (Art. 28 GDPR)
Sector supervision: finance and insurance
For regulated financial institutions, the national supervisory authorities remain responsible, in Germany BaFin. The AI Act applies in addition to existing supervisory requirements, not in their place. The key to efficient implementation: shared artifacts instead of parallel documentation worlds. The table shows where AI Act obligations and existing requirements demand the same thing.
| AI Act requirement | Existing requirement (examples) | Shared artifact |
|---|---|---|
| Risk management system (Art. 9) | MaRisk/MaGo risk management, VAIT/DORA ICT risk management | One risk register, extended by AI risks (see chapter D3) |
| Logging (Art. 12) | DORA logging and monitoring, VAIT logging requirements | One logging and monitoring concept |
| Robustness and cybersecurity (Art. 15) | DORA resilience and penetration testing | A joint test plan, AI scenarios added (see chapter B9) |
| Human oversight, model validation (Art. 14, 15) | Supervisory expectations for model risk management and validation | Validation reports, model cards (see chapter B7: model risk management) |
| Purchasing models and platforms | VAIT/MaGo outsourcing, DORA ICT third-party risk | One contract and exit dossier per vendor (see chapter B3) |
High-risk use cases (risk assessment and pricing in life/health) should be aligned early with compliance and, where appropriate, the supervisor.
National market surveillance
Beyond sectoral supervision, the AI Act requires a market surveillance authority in each member state to enforce compliance. In Germany, the Bundesnetzagentur (Federal Network Agency) takes on this role as the central body, complemented by the existing sector-specific supervisors (such as BaFin and the data protection authorities). The basis is the AI Market Surveillance and Innovation Promotion Act (KI-MIG), passed by the Bundestag in June 2026; approval by the Bundesrat and promulgation were still pending as of writing. In practice this means: the authority to which evidence, registrations, and incident reports are sent is identifiable and should be recorded in the AI register.
German specifics: co-determination and liability
Works council and co-determination. AI in the workplace regularly touches co-determination rights, independent of the AI Act classification:
- Systems that can monitor the behavior or performance of employees (technical capability is sufficient) are subject to co-determination under Section 87 (1) no. 6 of the Works Constitution Act (BetrVG). This applies to many AI tools with logging.
- The works council must be informed when AI use is being planned (Section 90 BetrVG) and may consult experts on AI without specific justification (Section 80 (3) BetrVG).
- Practical consequence: involve the works council early and aim for a framework works agreement on AI instead of negotiating every tool individually. This speeds up every later rollout and pays into acceptance.
Liability. The new EU Product Liability Directive (2024/2853) explicitly covers software and AI systems as products; transposition into German law is due by December 2026. The draft of a dedicated AI Liability Directive was withdrawn in 2025; the general rules apply (contract, tort, product liability). For practice this means: the documentation, logging, and evaluation evidence from this chapter are at the same time the exhibits with which a company exculpates itself in a liability case. For managing directors and board members, personal liability as a corporate body is added (Section 43 GmbHG, Section 93 AktG): deploying AI without an adequate control, documentation, and oversight structure risks personal liability in the event of damage or fines, which D&O insurance only partly cushions. The same evidence therefore also limits the personal liability risk of leadership.
Checklist: operational compliance (company-wide)
Unlike the high-risk checklist in Part 2, which is kept per system, this list checks the company-wide compliance organization:
- AI register: inventory of all deployed and planned AI systems maintained
- Risk classification documented per system (decision tree in Part 1), incl. justified Art. 6(3) exemptions
- Roles clarified per system: provider or deployer; role-change risk assessed for adaptations
- AI literacy (Art. 4): role-specific training established and evidenced
- Transparency implemented: labeling of chatbots and AI-generated content (from 2 Aug 2026)
- Responsible function for AI Act compliance named (see chapter B7)
- Procurement: contracts secure documentation under Art. 53, data sovereignty, audit rights (see chapter B3)
- Cybersecurity obligations checked: NIS2 for entities in regulated sectors, DORA in the financial sector (reporting channels and deadlines see chapter B9)
- Works council involved, works agreement checked or concluded
- Deadline monitoring: application dates matched against the AI register, owners named per deadline
- Regular review for new use cases, changed systems, or a changed legal situation
This content is for orientation and is not legal advice. Binding classifications and measures must be aligned with the responsible functions for legal, data protection, and compliance.