EAAPLEnterprise AI Architecture Pattern Library
EAAPL›Library›Regulatory Compliance›
Proven
⇄ Compare

EAAPL-CMP003 — EU AI Act Compliance Architecture

📋 Regulatory Compliance🏭 Field-tested in AU

EAAPL-CMP003 — EU AI Act Compliance Architecture

Status: Proven
Tags: eu-ai-act human-oversight audit-logging high-complexity
Version: 1.3
Last Updated: 2026-06-12
Author: Enterprise AI Architecture Pattern Library

1. Executive Summary

The EU Artificial Intelligence Act (Regulation (EU) 2024/1689) establishes legally binding obligations for providers and deployers of AI systems across risk classifications. High-risk AI systems—defined in Annex III and covering employment, education, essential services, law enforcement, migration, and administration of justice—face the most stringent requirements: technical documentation (Article 11), conformity assessment (Article 43), CE marking, human oversight (Article 14), transparency (Article 13), post-market monitoring (Article 61), serious incident reporting (Article 62), and EU database registration (Article 51).

This pattern provides a reference architecture for the technical and governance controls required to achieve and maintain EU AI Act compliance for high-risk AI deployments. It clearly differentiates obligations that fall on providers (those who develop and place the AI system on the market) from those that fall on deployers (those who use the AI system in their operations). Organisations that are both provider and deployer carry the combined obligation set. Adoption enables organisations to demonstrate conformity to notified bodies, national authorities, and the European AI Office while building customer trust through transparent, accountable AI.

2. Problem Statement

Business Problem

The EU AI Act creates direct legal obligations with enforcement consequences: market access prohibition for non-compliant high-risk systems, fines up to EUR 30 million or 6% of global annual turnover for violations. Organisations deploying AI systems that fall within Annex III categories face concrete compliance deadlines that require architectural changes to existing systems—these cannot be addressed through policy alone.

Technical Problem

Existing AI system architectures were not designed to meet EU AI Act technical obligations. Key gaps include: absence of comprehensive technical documentation systems capturing model architecture, training data, validation methods and limitations; no conformity assessment process or CE marking workflow; human oversight mechanisms that are advisory rather than having genuine ability to override or halt; transparency disclosures not presented to end users at the point of interaction; post-market monitoring programmes that do not feed back into the risk management system.

Symptoms

  • AI system documentation exists as informal README files rather than the structured technical documentation required by Article 11
  • There is no mechanism for users to know they are interacting with an AI system (Article 13 transparency obligation unmet)
  • Human reviewers can see AI recommendations but cannot halt or override the AI system in real time
  • No serious incident reporting workflow exists aligned with Article 62 timelines
  • No registration has been made or planned for the EU AI database (Article 51)

Cost of Inaction

Dimension Consequence
Regulatory Fines up to EUR 30M or 6% global turnover (Article 99); market withdrawal orders
Financial Product redesign costs increase 300–500% if compliance is retrofitted post-deployment
Market Access EU market access prohibited for non-compliant high-risk AI systems
Reputational Public reporting by national competent authorities; EU AI Office investigations

3. Context

When to Apply

  • Organisations placing high-risk AI systems (Annex III categories) on the EU market
  • Deployers using Annex III AI systems in EU operations, regardless of provider's location
  • Systems used in: biometric identification, critical infrastructure, education/vocational training, employment/worker management, essential private and public services (including creditworthiness), law enforcement, migration/asylum, administration of justice
  • General-purpose AI models with systemic risk (Article 51 — models trained with >10^25 FLOPs) used within high-risk applications

When NOT to Apply

  • AI systems that are exclusively low-risk or minimal-risk under the EU AI Act classification
  • Research and development activities that do not place the system on the market
  • AI used in purely personal, non-professional contexts
  • Military and national security AI (excluded from scope by Article 2(3))

Prerequisites

Prerequisite Description
Risk Classification Assessment Formal determination of whether the AI system falls within Annex III categories
Data Governance Programme Capability to document training data provenance, quality measures, and data governance
Quality Management System ISO 9001 or equivalent QMS that can be extended to cover the AI lifecycle
Legal Counsel EU AI Act specialist review of system classification and obligation mapping
Conformity Assessment Plan Determination of which conformity assessment procedure applies (Annex VI or VII)

Industry Applicability

Industry Annex III Categories Applicability
Financial Services Creditworthiness assessment, insurance risk, employment screening High — multiple Annex III categories typically apply
Healthcare Medical devices (covered by MDR — interaction point), health insurance Medium — MDR intersection; Article 6(4) exemptions complex
HR Technology Employment recruitment, performance evaluation, task allocation, termination High — direct Annex III category (Article III.4)
Education Technology Student assessment, admission decisions, monitoring during examinations High — direct Annex III category (Article III.3)
Law Enforcement Biometric identification, risk assessment, evidence evaluation High — most stringent controls; Article III.6
Government / Public Sector Benefit allocation, social scoring prohibited, administrative decisions High — Annex III.5 essential services
Autonomous Vehicles Safety components in road vehicles covered under other EU product safety law Partial — AI Act interaction with sector regulation

4. Architecture Overview

The EU AI Act Compliance Architecture is structured around five integrated system layers that together fulfil the legal obligations applicable to high-risk AI system providers and deployers.

Layer 1 — Risk Classification and Scoping Before any implementation activity, a risk classification assessment must formally determine whether the AI system falls within Annex III categories. The assessment process includes: use-case analysis against each Annex III category (nine categories as of final text), output classification (prohibited/high-risk/limited transparency/minimal risk), and documentation of the classification rationale to be retained as evidence of compliance due diligence. Where a system is borderline, the precautionary principle applies: assume high-risk until a notified body or legal counsel confirms otherwise. The risk classification assessment output feeds directly into the technical documentation system and quality management system.

Layer 2 — Technical Documentation System (Article 11) Article 11 requires providers to maintain technical documentation before the system is placed on the market and to keep it updated throughout the system lifecycle. The documentation system must capture all items listed in Annex IV: general description of the system; description of design, development, and intended purpose; information about training, validation, and testing data; description of monitoring, functioning, and control systems; description of appropriate human oversight measures; description of any pre-determined changes; and results of conformity assessment. The technical documentation system should be implemented as a structured document management system (not an ad-hoc wiki) with version control, change management workflows, and access control to prevent unauthorised modification.

Layer 3 — Human Oversight and Override Mechanisms (Article 14) Article 14 is one of the most technically demanding obligations. It requires that high-risk AI systems be designed and developed to allow effective oversight by natural persons during the period of use. Specifically: (a) systems must be able to be supervised by a human; (b) humans must be able to understand the capabilities and limitations of the system; (c) humans must be able to correctly interpret output; (d) humans must be able to decide not to use the system or override its output; (e) humans must be able to intervene in or interrupt the system via a stop function. This requires implementing a Human Oversight Layer with: real-time confidence scoring displayed alongside AI outputs; explanation panels showing the primary factors in the AI recommendation; a visible and accessible override control on every AI-assisted decision interface; a system halt capability accessible to nominated human oversight roles; and audit logging of every override and halt action.

Layer 4 — Transparency and User Information (Article 13) Where the AI system interacts directly with natural persons, those persons must be informed that they are interacting with an AI system unless this is obvious from context. The transparency system must: display an AI interaction notice at the start of every interaction; provide users with information about the intended purpose of the system; explain how to contact the deployer; describe the level of human oversight applied; and—for automated decisions—provide meaningful information about the logic involved. This is implemented as a Transparency Layer that injects disclosure notices into all user-facing AI interfaces and logs the presentation of each disclosure.

Layer 5 — Post-Market Monitoring and Incident Reporting (Articles 61, 62) Providers must implement a post-market monitoring system that actively collects and analyses data from deployed systems to identify previously unknown risks, serious incidents, and near misses. The monitoring system must generate periodic reports and feed findings back into the risk management system. Serious incidents—defined as incidents that cause or could cause death, serious harm, serious disruption to infrastructure, or violations of fundamental rights—must be reported to the relevant national competent authority. Providers must report serious incidents within 15 working days of becoming aware (immediately where life is at risk). Deployers must report serious incidents to the provider immediately and to national competent authorities where required.

5. Architecture Diagram

ARCHITECTURE DIAGRAM
flowchart TD subgraph Input["Request and Classification"] A[User Input] B{Risk Classifier} end subgraph Core["AI System Core"] C[Inference Engine] D[Confidence Scorer] E[Human Oversight Interface] end subgraph Compliance["Compliance Controls"] F[(Technical Documentation)] G[Post-Market Monitor] H[Incident Reporter] end A --> B B -->|high-risk| C B -->|prohibited| H C --> D D --> E E -->|override or halt| F E -->|output accepted| A C --> G G -->|serious incident| H G -->|feedback| F style A fill:#dbeafe,stroke:#3b82f6 style B fill:#f3e8ff,stroke:#a855f7 style C fill:#f0fdf4,stroke:#22c55e style D fill:#f0fdf4,stroke:#22c55e style E fill:#f0fdf4,stroke:#22c55e style F fill:#fef9c3,stroke:#eab308 style G fill:#f0fdf4,stroke:#22c55e style H fill:#fee2e2,stroke:#ef4444

6. Components

Component Type Responsibility Technology Options Criticality
Risk Classification Engine Governance Assess AI system against Annex III categories; generate classification rationale Custom assessment tool, OneTrust AI Governance, Credo AI High
Technical Documentation System Governance Store and version all Annex IV documentation; change management Confluence, SharePoint, Collibra, Alation Critical
Quality Management System Governance Control processes for AI development lifecycle; non-conformance management ISO 9001 QMS, SAP QM, Veeva Vault High
Conformity Assessment Module Governance Manage Annex VI / VII assessment process; CE marking issuance Custom workflow, ServiceNow, Archer Critical
EU AI Database Registration Governance Submit and maintain registration in EU AI Act database (Article 51) EU AI Database portal (EADB), custom integration Critical
AI Inference Engine Core Execute model inference with explainability output AWS SageMaker, Azure ML, Vertex AI, self-hosted Critical
Confidence Scorer Core Assign calibrated confidence to AI outputs; generate explanations SHAP, LIME, Captum, model-native explanations High
Human Review Interface UI Present AI output with confidence, explanation, override, halt controls Web app, Salesforce UI, ServiceNow, custom React/Vue Critical
Transparency Disclosure Module UI Inject AI interaction notice into all user-facing AI surfaces Custom middleware, OneTrust, TrustArc High
Override and Halt Controller Core Record human decisions to override or halt; enforce halt state Custom event sourcing; Kafka; PostgreSQL Critical
Post-Market Monitor Operations Track performance metrics, drift, bias, error rates post-deployment Fiddler, WhyLabs, Evidently AI, SageMaker Monitor High
Serious Incident Reporter Operations Queue, document, and dispatch Article 62 incident notifications ServiceNow, Jira, custom Critical
Oversight Audit Logger Security Immutable log of all human oversight actions, overrides, and halts Immutable S3, Azure Immutable Blob, Splunk Critical

7. Data Flow

Primary Flow

Step Actor Action Output
1 Provider Conduct risk classification assessment against Annex III Classification record: prohibited / high-risk / limited / minimal
2 Provider Prepare Annex IV technical documentation; register with QMS Technical documentation package version-controlled in DMS
3 Provider Complete conformity assessment (Annex VI self-assessment or Annex VII notified body) Conformity assessment certificate; CE marking authorisation
4 Provider Register system in EU AI database (Article 51) Registration ID in EADB
5 Deployer Deploy system with transparency, oversight, and monitoring controls activated Live system with all Article 13, 14, 61 controls operational
6 End User Begin interaction — transparency disclosure presented and logged User informed they are interacting with AI system
7 AI System Process user input; generate output with confidence score and explanation AI output + confidence + explanation factors
8 Human Reviewer Review AI output; exercise override or halt if appropriate; action logged Decision record: accepted / overridden / halted
9 Post-Market Monitor Continuously analyse performance; detect drift, bias, and errors Performance metrics; anomaly alerts
10 Deployer On serious incident: notify provider; notify national competent authority within 15 working days Article 62 incident report submitted

Error Flow

Step Failure Detection Recovery
Risk Classification Error System misclassified as minimal-risk when it is Annex III Internal audit; legal review; regulator finding Re-classify; implement full high-risk controls; notify authority if already deployed non-compliant
Conformity Assessment Gap Annex IV documentation incomplete at time of deployment Notified body review; internal QMS audit Suspend EU market placement; complete documentation; re-assess
Human Oversight Bypass System deployed in configuration where override control is not accessible to users Post-market audit; internal compliance check Halt system; redesign oversight interface; investigate affected decisions
Article 62 Notification Missed Serious incident not reported within 15 working days Post-incident timeline review; authority inquiry Submit late notification with explanation; implement incident detection improvements
Technical Documentation Out of Date System change made without updating Annex IV documentation QMS change management gate; audit Update documentation; assess whether change required new conformity assessment

8. Security Considerations

Provider vs Deployer Security Obligations

Obligation Provider Deployer Architectural Control
Technical documentation access control Must protect documentation from unauthorised access Must obtain documentation from provider DMS role-based access; non-disclosure provisions in deployer contract
Human oversight integrity Design oversight mechanisms into the system Implement oversight mechanisms in the deployment context Override and halt controls must be tamper-resistant; audit log immutable
Post-market monitoring data security Provide monitoring capability Operate monitoring and share findings with provider Monitoring data encrypted in transit and at rest; access limited to authorised roles
Incident evidence preservation Preserve technical evidence of incidents Preserve operational evidence Immutable logging from point of incident; legal hold process

OWASP LLM Top 10 — EU AI Act Mapping

OWASP LLM Risk EU AI Act Obligation Architectural Control Article Reference
LLM01 Prompt Injection Human oversight must detect adversarial manipulation Input validation; WAF; anomaly detection flagged for human review Article 14 — human oversight must remain effective
LLM02 Insecure Output Handling Transparency requires accurate representation of AI outputs Output validation; schema enforcement; no executable content injected Article 13 — users must understand what the system does
LLM03 Training Data Poisoning Training data must be governed under Article 10; data quality measures required Training data provenance; integrity hashing; data governance documentation Article 10 — training data governance
LLM04 Model Denial of Service Post-market monitoring must detect availability failures as potential serious incidents Availability monitoring; capacity management; DoS protection Article 61 — post-market monitoring includes availability
LLM05 Supply Chain Vulnerabilities Technical documentation must disclose third-party components; providers responsible for supply chain SBOM for AI components; third-party component assessment; Annex IV documentation Article 11 — Annex IV documentation; Article 28 — obligations along value chain
LLM06 Sensitive Information Disclosure High-risk AI systems often process sensitive data; fundamental rights impact Output filtering; PII redaction; fundamental rights impact assessment Article 9 — risk management; Article 10 — data governance
LLM07 Insecure Plugin Design Agentic AI tools with excessive permissions undermine human oversight Tool whitelisting; least privilege; human approval for high-consequence tool calls Article 14 — human oversight; Article 9 — risk management
LLM08 Excessive Agency Article 14 explicitly requires human ability to halt autonomous AI action Hard limits on autonomous action; halt function required by Article 14(e) Article 14(e) — stop function required
LLM09 Overreliance Article 14 requires humans understand AI limitations and can correctly interpret output Confidence scoring; explanation display; user training documentation Article 14(b)(c) — human must understand and interpret
LLM10 Model Theft Technical documentation, including model architecture details, is sensitive IP DMS access control; model weight encryption; IP protection provisions in deployer agreements Article 11 — documentation protection

9. Governance Considerations

Provider Obligations

Obligation Article Governance Control Evidence
AI Risk Management System Article 9 Documented risk management process covering the entire lifecycle Risk management system documentation; risk register
Training Data Governance Article 10 Documented data governance: collection, labelling, quality, bias assessment Data governance records; bias audit reports
Technical Documentation Article 11 Structured Annex IV documentation maintained and version-controlled Document management system records
Record-Keeping Article 12 Logs of system operation; audit trail for accountability Immutable operation logs
Transparency to Deployers Article 13 Instructions for use; deployer-facing documentation Instructions for use document; deployer training records
Human Oversight Design Article 14 Oversight mechanisms built into product; deployer guidance Product design specification; test results demonstrating oversight function
Accuracy, Robustness, Cybersecurity Article 15 Performance benchmarks; adversarial testing results Validation and testing results; pen test reports
Conformity Assessment Article 43 Completed Annex VI or VII assessment Conformity declaration; CE mark authorisation; notified body certificate
EU Database Registration Article 51 Active registration in EU AI database EADB registration record with ID

Governance Artefacts

Artefact Description Retention
Risk Classification Record Formal assessment against Annex III with rationale Lifetime of system + 10 years
Annex IV Technical Documentation Full Annex IV package; version-controlled; updated on each change 10 years after system placed on market (Article 18)
Conformity Declaration Article 47 declaration of conformity; CE marking documentation 10 years
Oversight Action Log Immutable log of every human override and halt action 10 years
Serious Incident Reports Article 62 notifications submitted to national competent authority 10 years
Post-Market Monitoring Reports Periodic summaries of system performance, incidents, near-misses 10 years
Training Data Records Provenance, quality assessments, bias analyses 10 years after system placed on market

10. Operational Considerations

Monitoring and SLOs

SLO Target Measurement Breach Action
Human Oversight Availability 100% — override and halt controls available during all operational hours Real-time UI health check Halt AI system if oversight control inaccessible; P1 incident
Transparency Disclosure Presentation 100% of user interactions receive disclosure Disclosure presentation rate metric Block interaction until disclosure confirmed; alert compliance team
Serious Incident Detection to Report Article 62: report within 15 working days Calendar tracking from detection Legal escalation if approaching deadline; daily status update
Post-Market Monitor Coverage 100% of production inferences captured in monitoring Monitoring coverage rate Alert MLOps team; investigate gap
Technical Documentation Currency 100% of Annex IV sections updated within 5 business days of system change Doc update lag metric Block deployment of system change until documentation updated
EU Database Registration Currency Registration updated within timeframes specified in Article 51 Registration age vs last system change Compliance team alert; notify registrar

Disaster Recovery

Scenario RTO RPO Recovery Procedure
AI System Outage 4 hours 0 minutes (stateless inference) Failover to secondary region; all oversight controls must be activated before resuming
Human Oversight Interface Failure Immediate halt required N/A AI system halted; manual process invoked; interface restored before resumption
Oversight Audit Log Corruption 24 hours 1 hour Restore from immutable backup; assess data integrity; notify compliance if gap
EU Database Inaccessibility 48 hours N/A — registration does not affect operation Queue updates; submit when database available

11. Cost Considerations

Cost Drivers

Cost Driver Indicative Cost Notes
Notified body conformity assessment (Annex VII) EUR 50,000–200,000 per system Required where self-assessment not permitted (biometrics, law enforcement AI)
Technical documentation preparation EUR 30,000–100,000 per system (initial) Ongoing maintenance: EUR 5,000–20,000/year per system
Post-market monitoring platform EUR 20,000–80,000/year Fiddler, WhyLabs, or equivalent; scales with prediction volume
Human oversight interface development EUR 50,000–150,000 per system One-time; higher for complex decision UIs
EU AI database registration Currently free (EU regulatory portal) Staff time for preparation and submission
Compliance programme management EUR 150,000–400,000/year 1–2 FTE EU AI Act compliance specialists
Legal and regulatory counsel EUR 30,000–100,000/year Ongoing advisory; higher in early compliance years

Indicative Cost Range

Organisation Size Annual EU AI Act Compliance Cost Notes
Small enterprise (1–2 high-risk AI systems) EUR 200,000–500,000 First year higher due to initial documentation and conformity assessment
Mid-size enterprise (3–10 systems) EUR 700,000–2,000,000 Economies of scale in programme management; per-system costs decrease
Large enterprise (10+ systems) EUR 2,000,000–10,000,000 Dedicated AI compliance team; notified body relationships; ongoing monitoring at scale

12. Trade-Off Analysis

Architecture Options

Option Description Pros Cons Recommended For
Option A: Self-Assessment (Annex VI) Provider conducts own conformity assessment; declares conformity Lower cost; faster time to market; no external dependency Limited to permitted categories; less external credibility AI systems where Annex VII notified body assessment is not mandated
Option B: Notified Body Assessment (Annex VII) Accredited notified body conducts independent assessment Maximum regulatory credibility; customer trust; identifies real gaps Significant cost (EUR 50K–200K); 3–6 month lead time Biometric systems, law enforcement AI, highest-stakes high-risk categories
Option C: Harmonised Standards Compliance Implement AI Act harmonised standards (CEN/CENELEC JTC 21) when published Presumption of conformity; predictable requirements Standards still being developed; potential lag Organisations willing to wait for standards maturity before deployment

Architectural Tensions

Tension Trade-Off Resolution
Human Oversight vs Automation Efficiency Article 14 oversight slows automated decision processes Design oversight as low-friction for routine decisions; high-friction for high-consequence decisions
Transparency vs Commercial Sensitivity Article 13 requires users to understand the system; Annex IV documentation is commercially sensitive User-facing transparency is about purpose and limitations, not proprietary model details; Annex IV is protected
Post-Market Monitoring Completeness vs Privacy Comprehensive monitoring captures personal data about users and decisions Anonymise or pseudonymise monitoring data where possible; data minimisation principle applied
Provider vs Deployer Liability Both have legal obligations; overlapping responsibilities create complexity Clear contractual allocation of obligations; deployer agreement specifies each party's responsibilities

13. Failure Modes

Failure Likelihood Impact Detection Recovery
System Misclassified as Non-High-Risk Medium Critical — zero compliance controls deployed Regulator audit; legal review Immediate halt; implement full compliance programme; assess affected decisions
Human Oversight Controls Not Operational Medium Critical — Article 14 breach; decisions made without oversight Post-market monitoring; audit Halt system; redesign UI; re-deploy with functioning oversight
Serious Incident Notification Missed Low High — Article 62 breach; fines; reputational damage Internal review; authority inquiry Late notification; process review; implement detection improvements
Technical Documentation Not Updated High Medium — Article 11 breach; invalidates conformity assessment Internal QMS audit Update documentation; re-run conformity assessment if material change
Provider Ceases Operations Low High — deployer loses access to documentation and support Contract monitoring Deployer must obtain technical documentation before provider ceases; Article 28 protections
Transparency Disclosure Not Presented Medium High — Article 13 breach; user rights violated Compliance audit; user complaint Deploy disclosure retroactively; notify affected users; remediate

Cascading Failure Scenario

An HR AI system for hiring decisions is deployed without a completed risk classification assessment. The deployer's legal team assumed the system was minimal risk. The system makes hiring recommendations without the human oversight controls required by Article 14. A candidate who was rejected files a complaint with the national data protection authority, which refers the matter to the national AI supervisory authority. During investigation, authorities discover: no Annex IV documentation, no conformity assessment, no EU database registration, no human oversight mechanism. Fines are issued against both the provider (for placing a non-conforming system on the market) and the deployer (for use without required controls). All hiring decisions made by the system during the non-compliant period are subject to review.

14. Regulatory Considerations

Regulation Specific Obligation Architectural Control Reference
EU AI Act Risk classification for Annex III categories Risk Classification Engine with Annex III analysis Article 6; Annex III
EU AI Act Technical documentation before market placement Technical Documentation System (Annex IV) Article 11; Annex IV
EU AI Act Conformity assessment procedure Annex VI (self) or Annex VII (notified body) workflow Article 43
EU AI Act CE marking Post-conformity marking and declaration Article 47, 48
EU AI Act Human oversight — understand, interpret, override, halt Human Oversight Layer with override and halt controls Article 14(a)–(e)
EU AI Act Transparency to users — AI interaction disclosure Transparency Disclosure Module at point of interaction Article 13
EU AI Act Post-market monitoring Post-market monitoring system feeding risk management Article 61
EU AI Act Serious incident reporting within 15 working days Serious Incident Reporter with notification workflow Article 62
EU AI Act EU AI database registration EADB registration workflow Article 51
EU AI Act Provider obligations along the value chain Deployer agreement with obligation mapping Article 28
GDPR Lawful basis for AI processing of personal data Privacy controls integrated into AI pipeline GDPR Article 6
GDPR Automated decision-making with legal effects Human oversight layer; Article 22 compliance GDPR Article 22
ISO 42001 AI Management System aligns with EU AI Act governance ISO 42001 AIMS provides governance framework ISO/IEC 42001:2023

15. Reference Implementations

AWS

Component AWS Service
Technical Documentation System Amazon WorkDocs + versioning; or Confluence on EC2
Post-Market Monitoring Amazon SageMaker Model Monitor + Clarify (bias detection)
Oversight Audit Logging CloudTrail + S3 Object Lock (WORM)
Serious Incident Notification Amazon SNS + Lambda (notification workflow)
Human Review Interface Custom React app on AWS Amplify; SageMaker Ground Truth (human-in-loop)
Transparency Disclosure Lambda@Edge injection into CloudFront-served responses

Azure

Component Azure Service
Technical Documentation System Azure DevOps Wiki + SharePoint with version control
Post-Market Monitoring Azure Machine Learning Data Drift + Responsible AI dashboard
Oversight Audit Logging Azure Monitor + Immutable Blob Storage
Serious Incident Notification Azure Logic Apps + Service Bus notification pipeline
Human Review Interface Azure AI Content Safety + custom portal on Azure Static Web Apps
Transparency Disclosure Azure API Management policy injection

GCP

Component GCP Service
Technical Documentation System Google Drive with version history + Confluence
Post-Market Monitoring Vertex AI Model Monitoring + Explainable AI
Oversight Audit Logging Cloud Audit Logs + Cloud Storage Bucket Lock
Serious Incident Notification Cloud Pub/Sub + Cloud Functions notification workflow
Human Review Interface Custom app on Cloud Run; Vertex AI Human-in-Loop
Transparency Disclosure Cloud Armor response header injection

On-Premises

Component Technology
Technical Documentation System Confluence Data Center; SharePoint Server; Alation
Post-Market Monitoring Evidently AI; WhyLabs; Great Expectations; custom Grafana dashboards
Oversight Audit Logging Splunk Enterprise + WORM storage appliance
Serious Incident Notification ServiceNow ITSM workflow; PagerDuty
Human Review Interface Custom web application; Streamlit for lower-volume use cases
Pattern ID Pattern Name Relationship Notes
EAAPL-CMP002 APRA CPS234 AI Security COMPLEMENTARY EU entities with APRA obligations apply both; EU AI Act covers risk and transparency; CPS234 covers security
EAAPL-CMP004 Privacy-Preserving AI PREREQUISITE GDPR obligations are intertwined with EU AI Act for systems processing personal data
EAAPL-CMP005 ISO 42001 Implementation COMPLEMENTARY ISO 42001 provides the management system; EU AI Act provides the legal obligations; deploy together
EAAPL-CMP006 NIST AI RMF Implementation COMPLEMENTARY NIST AI RMF GOVERN/MAP/MEASURE/MANAGE functions operationalise EU AI Act risk management obligations
EAAPL-AGT003 Human-in-the-Loop Oversight EXTENSION Article 14 human oversight is the EU AI Act's most demanding technical requirement; HITL pattern provides implementation detail
EAAPL-SEC002 AI Audit Logging PREREQUISITE Article 12 record-keeping obligation requires immutable audit logging infrastructure

17. Maturity Assessment

Overall Maturity Label: Proven

Dimension Level 1 (Initial) Level 2 (Repeatable) Level 3 (Defined) Level 4 (Managed) Level 5 (Optimising) Current Pattern Level
Risk Classification No formal classification Ad-hoc assessment when prompted Formal Annex III assessment process Classification integrated into AI project intake Continuous re-assessment as Act evolves Level 3
Technical Documentation None or informal README Structured but incomplete documentation Full Annex IV documentation with version control Documentation as code; auto-generated from system metadata Documentation continuously validated against deployed system Level 3
Human Oversight No override mechanism Override possible but not designed in Formal override + halt controls in all high-risk UIs Override actions feed back into model improvement Oversight quality metrics drive continuous system improvement Level 3
Post-Market Monitoring No monitoring Manual periodic reviews Automated monitoring with alerting Monitoring feeds risk management system Predictive monitoring identifies risks before incidents Level 3
Incident Reporting No process Ad-hoc incident response Documented Article 62 workflow with timelines Drilled process with measured notification times Automated incident detection and reporting pipeline Level 3

18. Revision History

Version Date Author Changes
1.0 2025-08-01 EAAPL Working Group Initial draft aligned to EU AI Act final text (August 2024)
1.1 2025-11-15 EAAPL Working Group Added provider vs deployer obligation differentiation; expanded Article 14 detail
1.2 2026-02-20 EAAPL Working Group Added OWASP LLM Top 10 mapping; updated conformity assessment timelines
1.3 2026-06-12 EAAPL Working Group Added general-purpose AI model (Article 51) context; updated cost ranges; added cascading failure scenario
← Back to LibraryMore Regulatory Compliance →