Eu Ai Act Specialist

EU AI Act Compliance Specialist

Production-ready compliance patterns for Regulation (EU) 2024/1689 -- the EU Artificial Intelligence Act. Covers risk classification, provider/deployer obligations, GPAI model requirements, conformity assessment, and AI governance.

---

Clarify First

Before classifying or mapping obligations, confirm these inputs. If any is unknown or vague, ASK — do not assume:

• [ ] Intended purpose and domain — what the system does and its Annex III area (drives the risk classification and which obligations apply)
• [ ] Role — provider, deployer, GPAI provider, or importer (determines the obligation set)
• [ ] Biometric / GPAI characteristics — uses biometrics, is a GPAI model, or trained with >10^25 FLOPs (drives the prohibited / high-risk / systemic-risk path and the conformity-assessment route)

Stop rule: ask only the 2-3 that most change the output. If the user says "just draft it," proceed and list your assumptions at the top of the classification.

AI System Inventory and Classification Workflow

The agent classifies AI systems under the EU AI Act's risk-based framework and maps applicable obligations.

Workflow: Classify and Map Obligations

1. Inventory all AI systems -- for each system, document: name, provider/developer, description, intended purpose, deployment status, affected persons, geographic scope, data processed, and decision impact level. 2. Apply classification decision tree to each system:

• Does it meet the Art. 3(1) definition of an AI system? If no, document exclusion.
• Does it fall under a prohibited practice (Art. 5)? If yes, flag as UNACCEPTABLE RISK -- must be discontinued.
• Is it a safety component of an Annex I product? If yes, HIGH-RISK (product legislation path).
• Does it fall under an Annex III category? If yes, apply Art. 6(3) exception analysis. If exception does not apply, HIGH-RISK.
• Does Art. 50 transparency obligation apply? If yes, LIMITED RISK. Otherwise, MINIMAL RISK.

3. Map obligations based on classification -- assign compliance owners for each obligation. 4. Run gap analysis using scripts/ai_compliance_checker.py to identify compliance gaps. 5. Prioritize remediation by deadline urgency, penalty severity, and number of affected persons. 6. Validation checkpoint: Every AI system classified; prohibited practices flagged for immediate action; high-risk systems have assigned compliance owners and remediation timelines.

Example: AI System Classification Output

{
  "system_name": "Resume Screener v2.1",
  "provider": "Internal ML Team",
  "intended_purpose": "Screen job applications and rank candidates for recruiter review",
  "ai_act_classification": "HIGH-RISK",
  "classification_rationale": "Annex III Category 4 - Employment: AI for recruitment and screening of job applicants",
  "art_6_3_exception": false,
  "exception_rationale": "System directly influences which candidates proceed to interview stage - not a narrow procedural task",
  "applicable_obligations": [
    "Risk management system (Art. 9)",
    "Data governance (Art. 10)",
    "Technical documentation (Art. 11)",
    "Record-keeping / automatic logging (Art. 12)",
    "Transparency and information to deployers (Art. 13)",
    "Human oversight (Art. 14)",
    "Accuracy, robustness, cybersecurity (Art. 15)",
    "Quality management system (Art. 17)",
    "Conformity assessment (Art. 43)",
    "CE marking (Art. 48)",
    "EU database registration (Art. 49)",
    "Post-market monitoring (Art. 72)"
  ],
  "compliance_deadline": "2026-08-02",
  "assigned_owner": "Head of AI Governance"
}

---

Risk Classification System

The AI Act uses a risk-based approach with four tiers.

Tier 1: Prohibited Practices (Art. 5) -- Banned from 2 February 2025

Tier 2: High-Risk AI Systems (Art. 6, Annex III)

An AI system is high-risk if it falls under Annex III categories OR is a safety component of a product covered by Annex I harmonization legislation.

Annex III Categories:

Tier 3: Limited Risk -- Transparency Obligations (Art. 50)

Tier 4: Minimal Risk

No mandatory requirements. Voluntary codes of conduct encouraged (Art. 95).

---

Provider Obligations for High-Risk AI

Providers of high-risk AI systems must comply with all of the following:

---

Deployer Obligations (Art. 26)

---

General-Purpose AI Models (GPAI)

GPAI Provider Obligations (Art. 53) -- Effective 2 August 2025

Systemic Risk GPAI Models (Art. 51, 55)

Classified as systemic risk if: high impact capabilities, AI Office designation, or trained with >10^25 FLOPs (rebuttable presumption).

Additional obligations: Model evaluation with adversarial testing, red-teaming proportionate to risk, systemic risk assessment and mitigation, incident tracking and reporting, cybersecurity protection, energy consumption reporting.

---

Conformity Assessment Workflow

The agent guides organizations through conformity assessment for high-risk AI systems.

Workflow: Internal Control (Annex VI)

1. Establish QMS per Art. 17 -- document design, development, testing, data management, and post-market monitoring processes. 2. Compile technical documentation per Art. 11 -- system description, development process, risk management, data governance, performance metrics. 3. Implement all Chapter III Section 2 requirements -- verify each obligation is addressed. 4. Conduct internal assessment:

• Verify risk management system addresses all identified risks (Art. 9)
• Verify data governance meets Art. 10 requirements
• Verify technical documentation is complete and current (Art. 11)
• Verify logging capability (Art. 12)
• Verify transparency and instructions for use (Art. 13)
• Verify human oversight design (Art. 14)
• Verify accuracy, robustness, cybersecurity (Art. 15)
• Confirm QMS covers all required elements (Art. 17)

5. Sign EU Declaration of Conformity (Art. 47), affix CE marking (Art. 48), register in EU database (Art. 49). 6. Implement post-market monitoring (Art. 72) and maintain documentation updates. 7. Validation checkpoint: All 12 provider obligations verified; declaration signed; CE marking affixed; EU database registration complete; post-market monitoring operational.

Workflow: Third-Party Assessment (Annex VII)

Required for biometric identification systems (Annex III point 1) and cases where harmonized standards are insufficient.

1. Complete all internal control steps above. 2. Select and engage notified body with relevant AI system expertise. 3. QMS assessment -- notified body reviews and assesses QMS; issues certificate or requires corrective action; annual surveillance. 4. Technical documentation assessment -- notified body reviews documentation, tests system, issues type-examination certificate. 5. Sign EU Declaration of Conformity with notified body identification number on CE marking. 6. Maintain ongoing compliance -- notified body surveillance, notify of significant changes, maintain all documentation. 7. Validation checkpoint: Notified body certificates issued; CE marking with NB number affixed; ongoing surveillance scheduled.

---

Bias Detection and Fairness Testing

The agent performs bias detection per Art. 10 data governance requirements.

Workflow: Bias Testing

1. Define protected attributes -- age, gender, ethnicity, disability, religion, and other relevant characteristics for the system's context. 2. Analyze data distribution -- check representation ratios (target: 0.8-1.25 vs. population), class imbalance ratios (>0.5), and coverage of all known groups. 3. Evaluate outcome fairness using these metrics:

• Demographic parity: P(positive outcome) equal across groups (within 80% / four-fifths rule)
• Equalized odds: TPR and FPR equal across groups (within 80%)
• Predictive parity: PPV equal across groups (within 80%)
• Calibration: Predicted probabilities accurate for all groups (within 5pp)

4. Identify proxy variables -- check for features correlated with protected attributes. 5. Implement mitigation -- data augmentation, re-sampling, re-weighting, adversarial debiasing, threshold adjustment, or reject option classification as appropriate. 6. Validate -- re-run analysis to confirm improvement. 7. Document -- record all findings, measures taken, and residual bias levels in technical documentation. 8. Validation checkpoint: All protected attributes tested; fairness metrics within thresholds or residual bias documented with justification; mitigation measures recorded.

Example: Bias Detection Command

# Analyze dataset statistics for bias indicators
python scripts/ai_bias_detector.py --input dataset_stats.json \
  --protected-attributes gender,age_group,ethnicity

# Output as JSON for integration with compliance documentation
python scripts/ai_bias_detector.py --input dataset_stats.json --json

---

Implementation Timeline

Penalties (Art. 99)

SMEs and startups receive proportionate treatment (lower of absolute or percentage).

---

AI Model Documentation Templates

Template: AI System Description

AI SYSTEM DESCRIPTION
=====================
System Name:
Version:
Provider:
Date:

1. GENERAL INFORMATION
   - Intended purpose:
   - Target users (deployers):
   - Affected persons:
   - Geographic scope:
   - AI Act classification:
   - Annex III category (if applicable):

2. TECHNICAL ARCHITECTURE
   - Model type:
   - Input data modalities:
   - Output description:
   - Key design choices and rationale:

3. TRAINING AND DATA
   - Training data sources:
   - Data volume and characteristics:
   - Data preparation methods:
   - Bias examination results:

4. PERFORMANCE
   - Accuracy metrics:
   - Robustness testing results:
   - Known limitations:
   - Performance across demographic groups:

5. HUMAN OVERSIGHT
   - Oversight level: [human-in-the-loop / on-the-loop / in-command]
   - Override mechanism:
   - Automation bias safeguards:

Template: Risk Management Documentation

RISK MANAGEMENT SYSTEM -- AI SYSTEM
====================================
System Name:
Version:
Risk Management Lead:
Date:

1. RISK IDENTIFICATION
   | Risk ID | Description | Likelihood | Severity | Risk Level |
   |---------|-------------|------------|----------|------------|
   | R-001   |             |            |          |            |

2. RISK CONTROL MEASURES
   | Risk ID | Measure | Type | Verification | Status |
   |---------|---------|------|-------------|--------|
   | R-001   |         |      |             |        |

3. RESIDUAL RISK ASSESSMENT
   - Acceptability determination:
   - Overall risk-benefit analysis:

4. POST-MARKET DATA INTEGRATION
   - Review frequency:
   - Trigger conditions for update:

---

Tools

AI Risk Classifier

# Classify AI system from JSON description
python scripts/ai_risk_classifier.py --input system_description.json

# Classify from inline JSON
python scripts/ai_risk_classifier.py --inline '{
  "name": "Resume Screener",
  "description": "AI system that screens job applications and ranks candidates",
  "domain": "employment",
  "uses_biometrics": false,
  "decision_type": "automated_with_review",
  "affected_persons": "job applicants",
  "eu_deployment": true
}'

# JSON output for programmatic use
python scripts/ai_risk_classifier.py --input system.json --json

AI Compliance Checker

# Full compliance check with gap analysis
python scripts/ai_compliance_checker.py --input compliance_status.json

# Check deployer obligations only
python scripts/ai_compliance_checker.py --input compliance_status.json --role deployer

# JSON output with remediation steps
python scripts/ai_compliance_checker.py --input compliance_status.json --json

AI Bias Detector

# Analyze dataset for bias indicators mapped to Art. 10
python scripts/ai_bias_detector.py --input dataset_stats.json

# Specify protected attributes explicitly
python scripts/ai_bias_detector.py --input dataset_stats.json \
  --protected-attributes gender,age_group,ethnicity --json

---

Reference Documentation

---

---

Troubleshooting

---

Success Criteria

• All AI systems inventoried and classified -- every system assessed against the risk-based framework with documented classification rationale, including Art. 6(3) exception analysis where applicable
• Prohibited practices identified and discontinued -- all Art. 5 prohibited practices flagged by February 2, 2025, with documented evidence of discontinuation or lawful exception application
• High-risk systems fully compliant by August 2, 2026 -- all 12 provider obligations verified, EU Declaration of Conformity signed, CE marking affixed, and EU database registration complete
• Bias testing completed for all high-risk systems -- demographic parity, equalized odds, and predictive parity metrics within four-fifths threshold for all protected attributes, or residual bias documented with justification
• GPAI model obligations met by August 2, 2025 -- technical documentation maintained, downstream provider information supplied, copyright compliance verified, and training data summary published
• Conformity assessment completed per correct route -- internal control (Annex VI) or third-party assessment (Annex VII) selected based on system classification, with all certificates issued and filed

---

Scope & Limitations

In Scope:

• AI system risk classification across all four tiers (Prohibited, High-Risk, Limited Risk, Minimal Risk)
• Annex III category analysis and Art. 6(3) exception evaluation
• Provider and deployer obligation mapping with compliance gap analysis
• GPAI model classification including systemic risk determination (10^25 FLOPs threshold)
• Bias detection and fairness testing mapped to Art. 10 data governance requirements
• Conformity assessment workflow guidance (Annex VI internal control and Annex VII third-party)
• Implementation timeline tracking with penalty exposure assessment

Out of Scope:

• Actual ML model training, retraining, or adversarial testing -- this skill provides compliance frameworks, not ML engineering tools
• Notified body selection, engagement, or audit execution
• National regulatory sandbox applications or experimental AI system exemptions
• Detailed GPAI Code of Practice implementation beyond obligation mapping
• CE marking physical affixation or EU database registration system interaction
• Legal advice on liability, insurance, or contractual allocation of AI Act obligations

Important Notes:

• The EU AI Act compliance deadline of August 2, 2026 for high-risk systems is firm -- organizations should begin classification and gap analysis immediately
• Penalties are severe: up to EUR 35 million or 7% of global turnover for prohibited practices, EUR 15 million or 3% for high-risk non-compliance
• SMEs and startups receive proportionate penalty treatment (lower of absolute or percentage)

---

Integration Points

---

Tool Reference

ai_risk_classifier.py

Classifies AI systems into EU AI Act risk categories based on a JSON system description.

Input Fields: name, description, domain, sub_domain, uses_biometrics, biometric_type, biometric_context, interacts_with_persons, generates_content, content_type, decision_type, affected_persons, is_safety_component, product_legislation, eu_deployment, social_scoring, manipulates_behavior, targets_vulnerable_groups, predictive_policing_individual, untargeted_scraping, is_gpai, training_compute_flops, critical_infrastructure, infrastructure_type.

ai_compliance_checker.py

Validates AI system compliance against all provider and deployer obligations with gap analysis.

Output: Overall compliance score (0-100), per-obligation status, gap analysis with Art. references, and prioritized remediation recommendations.

ai_bias_detector.py

Analyzes dataset statistics for bias indicators mapped to Art. 10 data governance requirements.

Thresholds: Representation ratio 0.8-1.25 (within 20% of population), class imbalance >0.5, four-fifths rule (0.8) for disparate impact, proxy correlation >0.5 for proxy variable detection.

---

Regulation Reference: Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 Last Updated: March 2026 Version: 1.0.0

EU AI Act Classification Guide

Complete reference for classifying AI systems under Regulation (EU) 2024/1689. Covers Annex III high-risk categories, prohibited practices, GPAI model classification, and sector-specific guidance.

---

Table of Contents

• Classification Decision Tree
• Prohibited Practices — Complete Definitions
• Annex III High-Risk Categories — Detailed Reference
• Art. 6(3) Exception Analysis
• GPAI Model Classification
• Systemic Risk Assessment Methodology
• Software as Medical Device (SaMD) Classification
• AI in Regulated Sectors Mapping
• Classification Examples

---

Classification Decision Tree

Master Decision Flow

START: Does the system meet the Art. 3(1) definition of an AI system?
│
├── NO → OUT OF SCOPE
│   Document: Why the system does not meet the AI system definition
│   (e.g., simple rule-based logic, traditional software, basic automation)
│
└── YES → STEP 1: Check Prohibited Practices (Art. 5)
    │
    ├── System falls under Art. 5 prohibition
    │   → UNACCEPTABLE RISK
    │   Action: Discontinue immediately. Penalties up to EUR 35M / 7% turnover.
    │   Exception analysis: Check if narrow exceptions apply (Art. 5(2)-(4))
    │
    └── No prohibited practice
        │
        → STEP 2: Check Annex I (EU harmonisation legislation)
        │
        ├── System IS a safety component of a product covered by Annex I
        │   → HIGH-RISK (product legislation path)
        │   Assessment: Follow conformity assessment of the relevant product legislation
        │   Note: Annex I Section A → applies from Aug 2026
        │         Annex I Section B → applies from Aug 2027
        │
        └── System is NOT a safety component of Annex I product
            │
            → STEP 3: Check Annex III categories
            │
            ├── System falls under an Annex III category
            │   │
            │   → STEP 3a: Art. 6(3) exception analysis
            │   │
            │   ├── ALL four conditions met AND no significant risk
            │   │   → NOT HIGH-RISK
            │   │   Action: Document the exception determination and rationale
            │   │   Note: System may still have transparency obligations (Step 4)
            │   │
            │   └── Exception does NOT apply
            │       → HIGH-RISK
            │       Action: Full Chapter III Section 2 obligations apply
            │
            └── System does NOT fall under Annex III
                │
                → STEP 4: Check transparency obligations (Art. 50)
                │
                ├── System has transparency obligations
                │   → LIMITED RISK
                │   Action: Implement required disclosures
                │
                └── No transparency obligations
                    → MINIMAL RISK
                    Action: No mandatory requirements; voluntary codes encouraged

Is It an AI System? (Art. 3(1) Analysis)

A system qualifies as an AI system if ALL of the following are true:

Systems that are typically NOT AI systems:

• Simple if/then rule engines with no learning component
• Traditional database queries
• Basic calculators or spreadsheet formulas
• Static template-based content generation
• Conventional cybersecurity tools (firewalls, antivirus signatures)

---

Prohibited Practices — Complete Definitions

1. Subliminal Manipulation (Art. 5(1)(a))

Prohibited: AI systems that deploy subliminal techniques beyond a person's consciousness, or purposefully manipulative or deceptive techniques, with the objective or effect of materially distorting behaviour causing or likely to cause significant harm.

Key elements:

• Techniques operate below conscious awareness OR are purposefully manipulative/deceptive
• Objective or effect (not just intent) of materially distorting behaviour
• Causes or is likely to cause significant harm (physical, psychological, financial)

Examples:

• Subliminal visual/audio stimuli in AI-generated content designed to influence purchasing
• AI systems using dark patterns that exploit cognitive biases to manipulate decisions
• Personalized psychological manipulation at scale

NOT prohibited:

• Standard recommendation systems (unless they cross into manipulation)
• A/B testing with transparent variations
• AI-assisted marketing that does not use subliminal techniques

2. Exploitation of Vulnerabilities (Art. 5(1)(b))

Prohibited: AI systems exploiting vulnerabilities due to age, disability, or specific social or economic situation, with the objective or effect of materially distorting behaviour causing significant harm.

Key elements:

• Targets vulnerability related to age, disability, or socioeconomic situation
• Exploits (not merely affects) the vulnerability
• Materially distorts behaviour
• Causes significant harm

Examples:

• AI targeting elderly persons with deceptive financial products
• AI exploiting children's developmental vulnerabilities in gaming/social media
• AI targeting persons with cognitive disabilities with manipulative content
• Predatory lending AI targeting economically vulnerable communities

3. Social Scoring (Art. 5(1)(c))

Prohibited: AI systems used by public authorities (or on their behalf) evaluating or classifying natural persons over a period based on social behaviour or personal/personality characteristics, where the social score leads to detrimental or unfavourable treatment that is unjustified or disproportionate.

Key elements:

• Used by or on behalf of public authorities
• Evaluates/classifies persons based on social behaviour or personal traits
• Creates a social score
• Score leads to detrimental treatment in unrelated contexts, or treatment disproportionate to the behaviour

Examples:

• Government citizen scoring systems affecting access to services
• Public authority systems denying benefits based on social media behaviour
• Municipal systems scoring residents for civic compliance

4. Individual Predictive Policing (Art. 5(1)(d))

Prohibited: AI systems making risk assessments of natural persons to assess or predict the risk of committing a criminal offence, based solely on profiling or personality traits.

Key elements:

• Risk assessment for predicting criminal offending
• Based solely on profiling or personality traits
• Not based on objective, verifiable facts directly linked to criminal activity
• Individual-level prediction (not aggregate crime analytics)

NOT prohibited:

• AI supporting investigation of specific criminal activity
• Crime pattern analysis (geographic, temporal) not targeting individuals
• AI assessing evidence in active investigations

5. Untargeted Facial Image Scraping (Art. 5(1)(e))

Prohibited: AI systems creating or expanding facial recognition databases through untargeted scraping of facial images from the internet or CCTV footage.

Key elements:

• Creates or expands a facial recognition database
• Uses untargeted scraping (not specific, lawful collection)
• Sources: internet or CCTV footage

6. Emotion Recognition in Workplace/Education (Art. 5(1)(f))

Prohibited: AI systems inferring emotions in the workplace or educational institutions, except where for medical or safety reasons.

Key elements:

• Infers emotions of natural persons
• Context: workplace or educational institution
• Exception: medical reasons (e.g., detecting fatigue in safety-critical roles) or safety reasons

Examples (prohibited):

• Employee sentiment monitoring during meetings
• Student attention/engagement detection during lectures
• Job interview emotion analysis

Examples (permitted exceptions):

• Fatigue detection for commercial vehicle drivers (safety)
• Medical monitoring of patient emotional state during therapy

7. Biometric Categorization by Sensitive Attributes (Art. 5(1)(g))

Prohibited: AI systems categorizing natural persons based on biometric data to deduce race, political opinions, trade union membership, religious or philosophical beliefs, sex life, or sexual orientation.

Exception: Labelling or filtering of lawfully acquired biometric data in the area of law enforcement.

8. Real-Time Remote Biometric Identification in Public Spaces (Art. 5(1)(h))

Prohibited: Use of real-time remote biometric identification systems in publicly accessible spaces for law enforcement purposes.

Narrow exceptions (Art. 5(2)) — only if strictly necessary for one of:

• Targeted search for specific victims (abduction, trafficking, sexual exploitation)
• Prevention of specific, substantial, imminent threat to life or physical safety, or genuine and present/foreseeable threat of a terrorist attack
• Identification of suspects for specific serious criminal offences (Art. 5(3) list)

Safeguards for exceptions:

• Prior judicial or independent administrative authorisation required
• Limited in time, geographic scope, and number of persons
• Cannot be used for other purposes once identified

---

Annex III High-Risk Categories — Detailed Reference

Category 1: Biometric Identification and Categorisation

Scope: AI systems intended for:

Examples:

• Airport facial recognition for boarding verification
• Access control using fingerprint/iris recognition
• Customer emotion analysis in retail settings
• Age verification using facial analysis

Category 2: Critical Infrastructure

Scope: AI systems intended as safety components in the management and operation of:

Key qualifier: The AI must be a SAFETY COMPONENT — meaning its failure or malfunction would endanger safety.

Category 3: Education and Vocational Training

Scope: AI systems intended to be used for:

Examples:

• University admission scoring algorithms
• Automated essay grading systems
• AI-powered exam proctoring with behaviour analysis
• Adaptive learning systems that determine student placement levels
• AI recommending educational pathways based on student data

Category 4: Employment and Worker Management

Scope: AI systems intended to be used for:

Examples:

• CV/resume screening algorithms
• Video interview analysis AI
• Employee performance prediction systems
• Workforce scheduling AI based on behavioural patterns
• Productivity monitoring with AI-driven analysis
• AI-assisted hiring/firing decision support

Category 5: Essential Services

Scope: AI systems intended to be used for:

Examples:

• AI credit scoring models
• Insurance underwriting AI for life/health policies
• Social welfare eligibility determination systems
• Emergency 911/112 call prioritization AI
• AI fraud detection in financial services (NOT high-risk — explicit exception)

Category 6: Law Enforcement

Scope: AI systems intended to be used by law enforcement authorities for:

Category 7: Migration, Asylum, and Border Control

Scope: AI systems intended to be used by public authorities or on their behalf for:

Category 8: Administration of Justice and Democratic Processes

Scope:

---

Art. 6(3) Exception Analysis

An AI system that falls under Annex III may still be classified as NOT high-risk if the provider determines it does not pose a significant risk to health, safety, or fundamental rights, AND the system performs one of the following:

Exception Conditions (must meet at least one)

Additional Requirement

The AI system must NOT pose a significant risk of harm to health, safety, or fundamental rights of natural persons, including by not materially influencing the outcome of decision-making.

Documentation Requirement

If a provider determines an Annex III system is not high-risk under Art. 6(3): 1. Document the determination and the rationale before placing on market 2. Notify the relevant market surveillance authority with the documentation 3. Register in the EU database with the determination

Examples

---

GPAI Model Classification

What Is a GPAI Model? (Art. 3(63))

An AI model (including trained with large amounts of data using self-supervision at scale) that displays significant generality, is capable of competently performing a wide range of distinct tasks regardless of the way it is placed on the market, and can be integrated into a variety of downstream systems or applications.

GPAI vs AI System

GPAI Classification Criteria

Is the model a GPAI model?
├── NO → Standard AI system rules apply
└── YES
    ├── Standard GPAI → Art. 53 obligations
    │   - Technical documentation
    │   - Information for downstream providers
    │   - Copyright compliance
    │   - Training data summary
    │
    └── Systemic Risk GPAI?
        │
        ├── Training compute >= 10^25 FLOPs? → PRESUMED systemic risk
        │   (provider can rebut presumption)
        │
        ├── AI Office designation based on high impact capabilities?
        │   → DESIGNATED systemic risk
        │
        └── Neither → Standard GPAI (Art. 53 only)

Open-Source GPAI Exception (Art. 53(2))

GPAI models released under a free and open-source licence (allowing access, usage, modification, and distribution with attribution) benefit from reduced obligations:

• Must still comply with copyright policy and training data summary
• Exempt from technical documentation and downstream provider information requirements
• Exception does NOT apply to systemic risk models — they must meet ALL obligations regardless of licensing

---

Systemic Risk Assessment Methodology

Quantitative Indicators

Qualitative Indicators

AI Office Designation Process

1. AI Office may initiate designation based on available evidence 2. Provider is notified and can submit views 3. AI Office issues reasoned decision 4. Provider can challenge designation 5. Commission may update the compute threshold by delegated act

---

Software as Medical Device (SaMD) Classification

AI systems that qualify as medical devices are subject to both the AI Act and EU MDR 2017/745.

Dual Classification

SaMD Classification Under MDR (Rule 11 + MDCG 2019-11)

AI Act Implications for SaMD

• Must comply with BOTH MDR conformity assessment AND AI Act requirements
• Conformity assessment follows the MDR route (not AI Act Annex VI/VII)
• AI Act high-risk obligations (Art. 9-15, 17) still apply in full
• Technical documentation must address both MDR Annex II/III and AI Act Annex IV requirements

---

AI in Regulated Sectors Mapping

Cross-Regulation Mapping

GDPR Interaction

---

Classification Examples

Example 1: CV Screening Tool

Example 2: Customer Service Chatbot

Example 3: AI Credit Scoring Model

Example 4: Spam Filter

Example 5: AI Diagnostic Imaging (Medical)

Example 6: Large Language Model (Foundation Model)

Example 7: Social Media Content Moderation

---

Regulation Reference: Regulation (EU) 2024/1689, Annexes I, III, and relevant recitals

Last Updated: March 2026

AI Governance Framework

Comprehensive reference for establishing AI governance structures aligned with EU AI Act (Regulation EU 2024/1689) requirements. Covers organizational design, ethics oversight, model lifecycle governance, incident management, and conformity assessment procedures.

---

Table of Contents

• AI Governance Organizational Structure
• AI Ethics Board
• AI Registry and Inventory Management
• Model Lifecycle Governance
• Responsible AI Principles — Legal Requirements Mapping
• AI Incident Management
• Conformity Assessment Procedures
• CE Marking Process for AI Systems

---

AI Governance Organizational Structure

Recommended Governance Model

Organizations deploying AI systems subject to the EU AI Act should establish a three-tier governance structure:

TIER 1: STRATEGIC GOVERNANCE
┌─────────────────────────────────────────────────┐
│  Board of Directors / Executive Leadership       │
│  - Overall accountability for AI strategy        │
│  - Risk appetite and tolerance setting           │
│  - Resource allocation for AI compliance         │
└──────────────────────┬──────────────────────────┘
                       │
TIER 2: OVERSIGHT AND ADVISORY
┌──────────────────────┴──────────────────────────┐
│  AI Ethics Board / AI Governance Committee       │
│  - Policy development and review                 │
│  - Ethical review of high-risk AI systems        │
│  - Fundamental rights impact oversight           │
│  - Exception and escalation decisions            │
└──────────────────────┬──────────────────────────┘
                       │
TIER 3: OPERATIONAL GOVERNANCE
┌──────────────────────┴──────────────────────────┐
│  AI Compliance Function                          │
│  ┌───────────────────────────────────────────┐  │
│  │ AI Compliance Officer / Team              │  │
│  │ - Risk classification                     │  │
│  │ - Conformity assessment coordination      │  │
│  │ - Post-market monitoring                  │  │
│  │ - Regulatory liaison                      │  │
│  └───────────────────────────────────────────┘  │
│  ┌───────────────────────────────────────────┐  │
│  │ AI Technical Governance                   │  │
│  │ - Data governance (Art. 10)               │  │
│  │ - Technical documentation (Art. 11)       │  │
│  │ - Model validation and testing            │  │
│  │ - Bias detection and fairness testing     │  │
│  └───────────────────────────────────────────┘  │
│  ┌───────────────────────────────────────────┐  │
│  │ AI Risk Management                        │  │
│  │ - Risk identification and evaluation      │  │
│  │ - Control measure design                  │  │
│  │ - Incident management                     │  │
│  │ - Human oversight implementation          │  │
│  └───────────────────────────────────────────┘  │
└─────────────────────────────────────────────────┘

Key Roles and Responsibilities

Governance Documentation Requirements

---

AI Ethics Board

Purpose

The AI Ethics Board provides independent oversight and advisory guidance on the ethical dimensions of AI system development and deployment. While not explicitly required by the AI Act, an ethics board is a best practice that supports compliance with fundamental rights obligations, bias prevention, and responsible AI deployment.

Composition

Operating Procedures

Meetings: Quarterly regular meetings; ad-hoc meetings for urgent reviews

Quorum: Minimum of 4 members including Chair and at least one external member

Review triggers:

• New high-risk AI system proposed for development
• Significant change to an existing high-risk AI system
• Bias detection findings requiring mitigation decisions
• Fundamental rights impact assessment results
• Serious incident involving an AI system
• Ethical concern raised by any employee (whistleblower pathway)

Decisions:

• Advisory recommendations (non-binding but must be addressed with documented rationale)
• Escalation to Board of Directors for strategic decisions
• Authority to recommend halting deployment pending investigation

Ethical Review Process

1. SUBMISSION
   └── Project team submits AI Ethics Review Request
       Including: system description, risk classification,
       FRIA (if applicable), bias analysis results

2. SCREENING (5 business days)
   └── Ethics Board secretariat reviews for completeness
       ├── Complete → Schedule for review
       └── Incomplete → Return with guidance

3. REVIEW (15 business days)
   └── Board members review documentation
       └── Meeting to discuss findings and concerns

4. DETERMINATION
   ├── APPROVED — proceed with noted conditions
   ├── APPROVED WITH CONDITIONS — proceed after addressing conditions
   ├── DEFERRED — additional information or analysis required
   └── NOT APPROVED — significant ethical concerns; do not proceed

5. FOLLOW-UP
   └── Monitor conditions and report back at defined intervals

---

AI Registry and Inventory Management

AI System Registry

Maintain a comprehensive registry of all AI systems in the organization. This supports the EU database registration requirement (Art. 49) and internal governance.

Registry Fields

Inventory Management Process

1. DISCOVERY
   └── Identify all AI systems across the organization
       ├── Procurement records (vendor AI systems)
       ├── IT system inventory
       ├── Development team records
       └── Shadow AI detection (unofficial AI tool usage)

2. REGISTRATION
   └── Enter each AI system into the registry
       └── Complete all required fields

3. CLASSIFICATION
   └── Apply risk classification (use ai_risk_classifier.py)
       └── Document classification rationale

4. ONGOING MANAGEMENT
   ├── New systems: Register before development begins
   ├── Changes: Update registry on any significant change
   ├── Retirement: Mark as retired, retain records
   └── Reviews: Quarterly review of all active systems

5. REPORTING
   ├── Management dashboard: Active systems by risk level
   ├── Compliance status: Gap analysis per system
   └── Board reporting: Summary metrics and risk posture

Shadow AI Detection

Organizations must also detect and manage unofficial AI system usage:

---

Model Lifecycle Governance

Lifecycle Stages

┌─────────┐    ┌───────────┐    ┌──────────┐    ┌────────────┐    ┌───────────┐
│ CONCEPT  │ -> │ DEVELOP   │ -> │ VALIDATE │ -> │ DEPLOY     │ -> │ MONITOR   │
│ & DESIGN │    │ & TRAIN   │    │ & TEST   │    │ & OPERATE  │    │ & MAINTAIN│
└─────────┘    └───────────┘    └──────────┘    └────────────┘    └───────────┘
                                                                        │
                                                                        v
                                                                  ┌───────────┐
                                                                  │ RETIRE    │
                                                                  └───────────┘

Stage 1: Concept and Design

Gate criteria: Risk classification completed and documented; ethics review approved (if high-risk); resource plan approved.

Stage 2: Develop and Train

Gate criteria: Bias examination completed; risks identified and documented; technical documentation initiated.

Stage 3: Validate and Test

Gate criteria: All tests passed or accepted with documented rationale; risk management measures verified; technical documentation complete.

Stage 4: Deploy and Operate

Gate criteria: Conformity assessment completed; CE marking applied; EU database registration confirmed; monitoring active.

Stage 5: Monitor and Maintain

Triggers for re-assessment:

• Significant model performance degradation
• Bias metric exceeding defined thresholds
• Serious incident reported
• Change in intended purpose or deployment context
• Material change to the model (retraining, architecture change)
• Regulatory guidance update

Stage 6: Retirement

---

Responsible AI Principles — Legal Requirements Mapping

Mapping Ethical Principles to Legal Obligations

---

AI Incident Management

Incident Classification

Serious Incident Definition (Art. 3(49))

An incident or malfunctioning of an AI system that directly or indirectly leads to any of the following: 1. Death or serious damage to the health of a person 2. Serious and irreversible disruption of the management or operation of critical infrastructure 3. Breach of obligations under Union law intended to protect fundamental rights 4. Serious damage to property or the environment

Incident Response Process

1. DETECTION
   ├── Automated monitoring alerts
   ├── Human oversight personnel reports
   ├── Deployer incident reports
   ├── Affected person complaints
   └── External reports (authorities, media)

2. TRIAGE (within 1 hour)
   ├── Classify severity (Critical / High / Medium / Low)
   ├── Assign incident owner
   ├── Determine if serious incident (Art. 3(49))
   └── Activate appropriate response team

3. CONTAINMENT (immediate for Critical/High)
   ├── Assess need to halt system operation
   ├── Implement immediate corrective measures
   ├── Preserve evidence and logs
   └── Secure affected data

4. INVESTIGATION
   ├── Root cause analysis
   ├── Impact assessment (persons affected, scope, severity)
   ├── Review risk management adequacy
   ├── Assess whether system still meets requirements
   └── Identify systemic issues

5. REPORTING (within 15 days for serious incidents)
   ├── Report to market surveillance authority (Art. 73)
   │   ├── Authorities of ALL member states where incident occurred
   │   ├── Include: description, corrective actions, known details
   │   └── Follow up with additional information as available
   ├── Report to notified body (if applicable)
   └── Notify deployers

6. CORRECTIVE ACTION
   ├── Implement corrective measures
   ├── Update risk management system
   ├── Update technical documentation
   ├── Retrain model if needed (with governance controls)
   └── Communicate changes to deployers

7. CLOSURE AND LEARNING
   ├── Verify corrective actions are effective
   ├── Update post-market monitoring system
   ├── Document lessons learned
   ├── Update AI literacy training if needed
   └── Close incident record

Incident Documentation Requirements

---

Conformity Assessment Procedures

Internal Control Procedure (Annex VI)

For high-risk AI systems where internal control is sufficient (Annex III categories 2-8, with harmonised standards applied):

PHASE 1: PREPARATION (months 1-3)
├── 1.1 Establish/verify QMS meets Art. 17 requirements
├── 1.2 Verify all Chapter III Section 2 requirements are implemented
├── 1.3 Compile technical documentation (Art. 11, Annex IV)
├── 1.4 Complete all testing (accuracy, robustness, cybersecurity, fairness)
└── 1.5 Designate person(s) responsible for conformity assessment

PHASE 2: INTERNAL ASSESSMENT (months 3-5)
├── 2.1 Review technical documentation for completeness and accuracy
├── 2.2 Verify risk management system (Art. 9)
│   ├── Risks identified, evaluated, and controlled
│   ├── Testing completed against defined metrics
│   └── Residual risks acceptable
├── 2.3 Verify data governance (Art. 10)
│   ├── Data quality criteria met
│   ├── Bias examined and mitigated
│   └── Special category data handled properly
├── 2.4 Verify record-keeping (Art. 12)
│   ├── Automatic logging implemented
│   └── Retention periods defined
├── 2.5 Verify transparency (Art. 13)
│   ├── Instructions for use complete
│   └── All required information included
├── 2.6 Verify human oversight (Art. 14)
│   ├── Oversight level appropriate
│   ├── Mechanisms functional
│   └── Automation bias safeguards in place
├── 2.7 Verify accuracy, robustness, cybersecurity (Art. 15)
│   ├── Performance metrics meet targets
│   ├── Robustness tested
│   └── Cybersecurity measures proportionate
├── 2.8 Verify QMS (Art. 17)
│   └── All QMS elements documented and implemented
└── 2.9 Document assessment findings and conclusions

PHASE 3: DECLARATION (month 5-6)
├── 3.1 Prepare EU Declaration of Conformity (Art. 47)
│   ├── Provider name and address
│   ├── AI system identification
│   ├── Declaration of conformity with AI Act
│   ├── Reference to harmonised standards applied
│   ├── Signed by authorized representative
│   └── Date and place of issuance
├── 3.2 Affix CE marking (Art. 48)
├── 3.3 Register in EU database (Art. 49)
└── 3.4 Retain documentation for 10 years

PHASE 4: POST-MARKET (ongoing)
├── 4.1 Implement post-market monitoring system (Art. 72)
├── 4.2 Maintain documentation updates
├── 4.3 Report serious incidents within 15 days (Art. 73)
├── 4.4 Re-assess conformity on significant changes
└── 4.5 Annual compliance review

Third-Party Assessment Procedure (Annex VII)

For biometric identification systems (Annex III category 1) and cases where harmonised standards are insufficient:

PHASE 1: PREPARATION (months 1-4)
├── 1.1 Complete all Phase 1 steps from internal control procedure
├── 1.2 Select notified body
│   ├── Check notified body competence and scope
│   ├── Verify designation covers the AI system type
│   └── Agree on timeline and scope of assessment
└── 1.3 Prepare submission package for notified body

PHASE 2: QMS ASSESSMENT BY NOTIFIED BODY (months 4-8)
├── 2.1 Submit QMS documentation to notified body
├── 2.2 Notified body reviews:
│   ├── QMS documentation completeness
│   ├── QMS implementation (may include on-site audit)
│   ├── Representative sample of AI system development records
│   └── Evidence of QMS effectiveness
├── 2.3 Notified body determination:
│   ├── QMS certificate issued → proceed to Phase 3
│   └── Corrective action required → address and re-submit
└── 2.4 QMS certificate issued (valid for specified period)

PHASE 3: TECHNICAL DOCUMENTATION ASSESSMENT (months 6-10)
├── 3.1 Submit complete technical documentation to notified body
├── 3.2 Notified body reviews:
│   ├── Technical documentation completeness (Annex IV)
│   ├── System compliance with requirements (Art. 9-15)
│   ├── Data governance and bias examination results
│   ├── Testing and validation results
│   └── Human oversight design
├── 3.3 Notified body may:
│   ├── Request additional testing
│   ├── Conduct independent testing
│   ├── Review source code or training data (subject to confidentiality)
│   └── Interview development team
├── 3.4 Notified body determination:
│   ├── EU type-examination certificate issued → proceed to Phase 4
│   └── Non-conformity identified → address and re-submit
└── 3.5 Type-examination certificate issued (valid for specified period)

PHASE 4: DECLARATION AND MARKING (months 10-12)
├── 4.1 Prepare EU Declaration of Conformity
│   ├── Reference both QMS certificate and type-examination certificate
│   └── Include notified body identification number
├── 4.2 Affix CE marking with notified body identification number
├── 4.3 Register in EU database
└── 4.4 Retain documentation for 10 years

PHASE 5: ONGOING SURVEILLANCE (annual)
├── 5.1 Notified body periodic surveillance audits
├── 5.2 Notify notified body of any planned significant changes
├── 5.3 Obtain approval before implementing significant changes
├── 5.4 Maintain QMS and technical documentation
└── 5.5 Report serious incidents to notified body

Selecting the Correct Assessment Path

---

CE Marking Process for AI Systems

CE Marking Requirements (Art. 48)

CE Marking Process

1. CONFIRM ELIGIBILITY
   └── System has completed conformity assessment (Annex VI or VII)

2. PREPARE DECLARATION
   └── EU Declaration of Conformity signed per Art. 47

3. DESIGN MARKING
   ├── Standard CE marking format
   ├── Add notified body number (if applicable): CE XXXX
   └── Determine placement (system, packaging, or documentation)

4. APPLY MARKING
   ├── For software: In the system UI, About screen, or documentation
   ├── For hardware: Physical marking on the device
   ├── For digital-only: In documentation and EU database entry
   └── Ensure visibility, legibility, indelibility

5. REGISTER
   └── Update EU database registration with CE marking status

6. MAINTAIN
   ├── Ensure marking remains valid throughout system lifetime
   ├── Re-assess if significant changes are made
   └── Remove if conformity can no longer be ensured

Declaration of Conformity Content (Art. 47)

The EU Declaration of Conformity must contain:

---

Last Updated: March 2026 Regulation Reference: Regulation (EU) 2024/1689 — EU Artificial Intelligence Act