TL;DR

Regulation (EU) 2024/1689 uses a staged, role- and risk-based framework. This article is an engineering checklist for recording applicability, classifying intended use, maintaining evidence, and preparing governance controls; it is not legal advice and does not turn example controls into a conformity assessment.

Table of Contents

Key Takeaways

  • Scope is fact-dependent: Article 2 requires a role, market, deployment, and output-use analysis rather than a single “long-arm” test.
  • Four-tier risk: Systems are classified as Unacceptable, High-risk, Limited-risk, or Minimal-risk—each tier carries different obligations.
  • Technical documentation: Annex IV requires structured evidence; do not reduce it to a fixed checklist count or a model card.
  • Logging is contextual: Article 12 requires capabilities for automatic event recording, with content and retention tied to the system and applicable duties.
  • Dates need version control: Record the legal basis, transition rule, amendment status, and jurisdiction for every deadline.

Related reading: If you are building LLM-powered products, review our earlier guide on LLM Guardrails Engineering for runtime safety patterns that complement compliance infrastructure.

Why This Matters Now

The dates below are a planning baseline, not a complete applicability decision. Confirm the consolidated Regulation, transitional provisions, Commission guidance, and any amendments before release:

Milestone Date Status
Regulation enters into force Aug 1, 2024 Done
Prohibited practices banned Feb 2, 2025 Enforceable
AI literacy obligations Feb 2, 2025 Enforceable
GPAI model obligations Aug 2, 2025 Enforceable
High-risk AI system provisions Aug 2, 2026 Check Article 113 and applicable transition
Product-embedded AI systems Aug 2, 2027 Upcoming

Article 2 requires a fact pattern analysis: provider or deployer role, placement or deployment in the Union, and specified output use. It should be assessed alongside GDPR, product-safety law, sector rules, and contractual allocation; do not infer scope from hosting region alone.

The Act contains different maximum fine levels for prohibited practices, other breaches, and incorrect information, with undertaking-size rules and procedural safeguards. Quote the applicable article and current text when preparing a legal position.

Enforcement Timeline

The following chart is a simplified planning view, not a complete legal timeline. Confirm the current consolidated text and transition rules before using it for a release decision.

gantt title EU AI Act Enforcement Timeline dateFormat YYYY-MM-DD axisFormat %b %Y section Already Active Prohibited Practices Banned :done, pp, 2025-02-02, 2025-02-02 AI Literacy Obligations :done, al, 2025-02-02, 2025-02-02 GPAI Model Obligations :done, gp, 2025-08-02, 2025-08-02 section Upcoming Deadlines High-Risk System Obligations :crit, hr, 2026-08-02, 2026-08-02 Codes of Practice Finalized :active, cp, 2026-05-02, 2026-08-02 Product-Embedded AI Systems :pe, 2027-08-02, 2027-08-02 Full Enforcement - All Provisions :fe, 2027-08-02, 2027-08-02

Risk Classification Decision Tree

The foundation is an applicability record, followed by classification of the system's intended purpose and role. This simplified tree is an engineering triage aid, not a legal classifier; Article 6 exceptions, product-safety routes, and later guidance require human review.

flowchart TD A["AI System Assessment"] --> B{"Does it use subliminal - manipulative - or exploitative techniques?"} B -- Yes --> C["UNACCEPTABLE RISK - Article 5 - System is PROHIBITED"] B -- No --> D{"Does it perform real-time biometric identification in public spaces?"} D -- Yes --> C D -- No --> E{"Does it perform social scoring by public authorities?"} E -- Yes --> C E -- No --> F{"Is it listed in Annex III high-risk categories?"} F -- Yes --> G{"Does an Article 6 exception apply and is it documented?"} G -- No --> H["HIGH-RISK - map provider/deployer duties"] G -- Yes --> I["Record the exception and reassess the use"] F -- No --> J{"Do other transparency or sector duties apply?"} J -- Yes --> L["Specific transparency or other duties"] J -- No --> M["No conclusion without applicability review"] style C fill:#ff6b6b,color:#fff style H fill:#ffa94d,color:#fff style L fill:#74c0fc,color:#fff style M fill:#69db7c,color:#fff

Annex III high-risk categories include AI systems used in:

  1. Biometric identification and categorization
  2. Critical infrastructure management
  3. Education and vocational training access
  4. Employment, worker management, and recruitment
  5. Access to essential services (credit scoring, insurance)
  6. Law enforcement
  7. Migration, asylum, and border control
  8. Administration of justice and democratic processes

A recruitment, credit, education, or similar use may fall within Annex III, but classification depends on intended purpose, role, exceptions, and the exact system function. Document the reasoning instead of relying on a keyword match.

Engineering Checklist Overview

For a system confirmed as high-risk, map each applicable article to an owner, control, evidence artifact, and review trigger. The following is an engineering mapping, not a substitute for the legal text:

Requirement Article Engineering Deliverable
Risk Management System Art. 9 Continuous risk identification and mitigation pipeline
Data Governance Art. 10 Training data lineage, bias analysis, data quality metrics
Technical Documentation Art. 11 + Annex IV Versioned evidence package matched to the system
Automatic Logging Art. 12 Event recording with integrity, access, retention, and privacy controls
Transparency Art. 13 User-facing documentation and instructions for use
Human Oversight Art. 14 Effective intervention, interpretation, override, and stop procedures
Accuracy and Robustness Art. 15 Bias testing, adversarial testing, performance benchmarks
Conformity Assessment Art. 43 Self-assessment or third-party audit + CE marking
Post-Market Monitoring Art. 72 Continuous performance monitoring after deployment

The following sections show illustrative control patterns. They omit storage, identity, legal review, deletion, and failure handling; adapt and test them against the actual system rather than treating them as compliant drop-ins.

Audit Logging Infrastructure

Article 12 requires capabilities for automatic recording of events. The implementation should preserve provenance and integrity while limiting personal data, access, and retention to what the applicable purpose and law require; a hash chain alone is not “immutability” or compliance.

Logging Middleware in TypeScript

The following middleware captures every AI inference request with the metadata required by Article 12:

typescript 
import { v4 as uuidv4 } from "uuid";
import crypto from "crypto";

interface AuditLogEntry {
  traceId: string;
  timestamp: string;
  systemId: string;
  systemVersion: string;
  inputHash: string;
  outputHash: string;
  modelId: string;
  modelVersion: string;
  userId: string;
  riskTier: "high" | "limited" | "minimal";
  humanOversightTriggered: boolean;
  confidenceScore: number;
  processingTimeMs: number;
  geolocation: string;
  dataRetentionDays: number;
}

function createAuditLogEntry(
  request: AIRequest,
  response: AIResponse,
  metadata: SystemMetadata
): AuditLogEntry {
  return {
    traceId: uuidv4(),
    timestamp: new Date().toISOString(),
    systemId: metadata.systemId,
    systemVersion: metadata.version,
    inputHash: crypto
      .createHash("sha256")
      .update(JSON.stringify(request.input))
      .digest("hex"),
    outputHash: crypto
      .createHash("sha256")
      .update(JSON.stringify(response.output))
      .digest("hex"),
    modelId: metadata.modelId,
    modelVersion: metadata.modelVersion,
    userId: request.userId,
    riskTier: metadata.riskTier,
    humanOversightTriggered: response.confidenceScore < metadata.confidenceThreshold,
    confidenceScore: response.confidenceScore,
    processingTimeMs: response.processingTimeMs,
    geolocation: request.geolocation ?? "unknown",
    dataRetentionDays: metadata.retentionPolicyDays,
  };
}

Immutable Log Storage

Logs should be tamper-evident and protected by storage controls, access separation, backup, deletion policy, and independent verification. An append-only chain is only one possible integrity signal:

typescript 
import crypto from "crypto";

interface ChainedLogBlock {
  sequence: number;
  previousHash: string;
  entry: AuditLogEntry;
  blockHash: string;
}

function appendToChain(
  chain: ChainedLogBlock[],
  entry: AuditLogEntry
): ChainedLogBlock {
  const previousHash =
    chain.length > 0 ? chain[chain.length - 1].blockHash : "GENESIS";
  const payload = JSON.stringify({ previousHash, entry });
  const blockHash = crypto
    .createHash("sha256")
    .update(payload)
    .digest("hex");

  const block: ChainedLogBlock = {
    sequence: chain.length,
    previousHash,
    entry,
    blockHash,
  };
  chain.push(block);
  return block;
}

This pattern can make some changes detectable, but it is not a blockchain, immutable storage, signature, access-control system, or regulatory guarantee.

Bias Testing Pipeline

Articles 10 and 15 require appropriate data governance, accuracy, robustness, and cybersecurity measures. The Act does not prescribe one universal demographic-parity metric or a 0.8 pass threshold. Select metrics, slices, uncertainty, and human review based on the use, data, and applicable rights risks.

Bias Metrics Computation in Python

All thresholds and metrics in the following code are illustrative policy inputs, not statutory pass/fail values. A production evaluation also needs dataset provenance, missing-group handling, uncertainty, legitimate-purpose analysis, and human review.

python 
from dataclasses import dataclass
from typing import Dict, List
import numpy as np


@dataclass
class BiasReport:
    metric: str
    group_a: str
    group_b: str
    group_a_rate: float
    group_b_rate: float
    disparity_ratio: float
    passes_threshold: bool
    threshold: float


def compute_demographic_parity(
    predictions: List[int],
    sensitive_attr: List[str],
    positive_label: int = 1,
    threshold: float = 0.8,
) -> List[BiasReport]:
    groups: Dict[str, List[int]] = {}
    for pred, attr in zip(predictions, sensitive_attr):
        groups.setdefault(attr, []).append(pred)

    group_rates = {
        g: np.mean([p == positive_label for p in preds])
        for g, preds in groups.items()
    }

    reports = []
    group_names = sorted(group_rates.keys())
    for i, g_a in enumerate(group_names):
        for g_b in group_names[i + 1 :]:
            rate_a = group_rates[g_a]
            rate_b = group_rates[g_b]
            ratio = min(rate_a, rate_b) / max(rate_a, rate_b) if max(rate_a, rate_b) > 0 else 1.0
            reports.append(
                BiasReport(
                    metric="demographic_parity",
                    group_a=g_a,
                    group_b=g_b,
                    group_a_rate=round(rate_a, 4),
                    group_b_rate=round(rate_b, 4),
                    disparity_ratio=round(ratio, 4),
                    passes_threshold=ratio >= threshold,
                    threshold=threshold,
                )
            )
    return reports

CI/CD Integration

Add bias testing as a required pipeline step. Here is a GitHub Actions workflow:

yaml 
name: EU AI Act Bias Testing
on:
  pull_request:
    paths:
      - "models/**"
      - "training/**"
      - "config/model-*.yaml"

jobs:
  bias-audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.12"

      - name: Install dependencies
        run: pip install -r requirements-bias-testing.txt

      - name: Run demographic parity tests
        run: |
          python -m pytest tests/bias/ \
            --tb=short \
            --junitxml=reports/bias-report.xml \
            -v

      - name: Run equalized odds tests
        run: |
          python scripts/bias_audit.py \
            --model-path models/latest/ \
            --test-data data/bias-test-set.csv \
            --threshold 0.8 \
            --output reports/bias-audit.json

      - name: Upload bias report
        uses: actions/upload-artifact@v4
        with:
          name: bias-audit-report
          path: reports/

      - name: Fail on bias threshold violation
        run: |
          python scripts/check_bias_results.py \
            --report reports/bias-audit.json \
            --fail-on-violation

This illustrative pipeline shows how to preserve evaluation evidence. Its thresholds are policy placeholders, not EU AI Act safe harbors; a passing score does not prove non-discrimination or legal compliance. For RAG systems, define retrieval slices and rights risks separately from model-output metrics.

Technical Documentation Generator

Annex IV specifies the information that technical documentation must cover for the relevant high-risk system. The following generator is only an illustrative schema; it is not a complete legal submission or a “model card” substitute:

typescript 
interface AnnexIVDocumentation {
  generalDescription: {
    intendedPurpose: string;
    systemArchitecture: string;
    interactionWithHardware: string;
    versionsOfRelevantSoftware: string[];
  };
  detailedDescription: {
    developmentMethodology: string;
    designSpecifications: string;
    systemArchitectureDiagram: string;
    computationalResources: string;
  };
  dataGovernance: {
    trainingDataDescription: string;
    dataSources: string[];
    dataPreparationSteps: string[];
    dataLabelingMethodology: string;
    dataBiasAssessment: string;
  };
  monitoringAndTesting: {
    performanceMetrics: Record<string, number>;
    testingProcedures: string[];
    validationDatasets: string[];
    knownLimitations: string[];
  };
  riskManagement: {
    identifiedRisks: RiskEntry[];
    mitigationMeasures: string[];
    residualRisks: string[];
  };
  humanOversight: {
    oversightMeasures: string[];
    interfaceDescription: string;
    overrideCapabilities: string[];
  };
  accuracyAndRobustness: {
    accuracyMetrics: Record<string, number>;
    robustnessTests: string[];
    cybersecurityMeasures: string[];
  };
  changeLog: ChangeEntry[];
  previousVersions: string[];
}

interface RiskEntry {
  riskId: string;
  description: string;
  likelihood: "low" | "medium" | "high";
  impact: "low" | "medium" | "high";
  mitigation: string;
  status: "open" | "mitigated" | "accepted";
}

function generateAnnexIVSkeleton(
  systemId: string,
  systemName: string
): AnnexIVDocumentation {
  return {
    generalDescription: {
      intendedPurpose: `[REQUIRED] Describe the intended purpose of ${systemName}`,
      systemArchitecture: "[REQUIRED] High-level architecture overview",
      interactionWithHardware: "[REQUIRED] Hardware dependencies and requirements",
      versionsOfRelevantSoftware: ["[REQUIRED] List all software dependencies"],
    },
    detailedDescription: {
      developmentMethodology: "[REQUIRED] Training methodology and approach",
      designSpecifications: "[REQUIRED] Model architecture specifications",
      systemArchitectureDiagram: "[REQUIRED] Link to architecture diagram",
      computationalResources: "[REQUIRED] GPU/TPU requirements and training cost",
    },
    dataGovernance: {
      trainingDataDescription: "[REQUIRED] Statistical summary of training data",
      dataSources: ["[REQUIRED] List all training data sources with provenance"],
      dataPreparationSteps: ["[REQUIRED] Data cleaning and preprocessing pipeline"],
      dataLabelingMethodology: "[REQUIRED] Annotation guidelines and inter-annotator agreement",
      dataBiasAssessment: "[REQUIRED] Demographic bias analysis results",
    },
    monitoringAndTesting: {
      performanceMetrics: {},
      testingProcedures: ["[REQUIRED] Unit tests, integration tests, adversarial tests"],
      validationDatasets: ["[REQUIRED] Hold-out validation set descriptions"],
      knownLimitations: ["[REQUIRED] Known failure modes and edge cases"],
    },
    riskManagement: {
      identifiedRisks: [],
      mitigationMeasures: [],
      residualRisks: [],
    },
    humanOversight: {
      oversightMeasures: ["[REQUIRED] Human review triggers and procedures"],
      interfaceDescription: "[REQUIRED] Operator dashboard and override UI",
      overrideCapabilities: ["[REQUIRED] Kill switch, confidence gating, manual approval"],
    },
    accuracyAndRobustness: {
      accuracyMetrics: {},
      robustnessTests: ["[REQUIRED] Adversarial input testing results"],
      cybersecurityMeasures: ["[REQUIRED] Model extraction, data poisoning protections"],
    },
    changeLog: [],
    previousVersions: [],
  };
}

Human-in-the-Loop Override Systems

Article 14 requires effective human oversight for applicable high-risk systems. A confidence score is not a reliable proxy for uncertainty or a legal decision rule; oversight must provide sufficient competence, authority, information, time, and ability to intervene or stop the system.

Confidence-Gated Override Pattern

Confidence gating can be one signal in a broader, validated routing policy. Do not allow a model-generated confidence value alone to authorize, reject, or bypass human review.

python 
from enum import Enum
from dataclasses import dataclass, field
from datetime import datetime
from typing import Optional


class DecisionRoute(Enum):
    AUTO_APPROVE = "auto_approve"
    HUMAN_REVIEW = "human_review"
    AUTO_REJECT = "auto_reject"


@dataclass
class OversightDecision:
    request_id: str
    model_output: str
    confidence: float
    route: DecisionRoute
    human_reviewer: Optional[str] = None
    human_decision: Optional[str] = None
    human_rationale: Optional[str] = None
    override_timestamp: Optional[str] = None
    audit_fields: dict = field(default_factory=dict)


def route_decision(
    request_id: str,
    model_output: str,
    confidence: float,
    auto_approve_threshold: float = 0.95,
    auto_reject_threshold: float = 0.3,
) -> OversightDecision:
    if confidence >= auto_approve_threshold:
        route = DecisionRoute.AUTO_APPROVE
    elif confidence <= auto_reject_threshold:
        route = DecisionRoute.AUTO_REJECT
    else:
        route = DecisionRoute.HUMAN_REVIEW

    return OversightDecision(
        request_id=request_id,
        model_output=model_output,
        confidence=confidence,
        route=route,
        audit_fields={
            "routed_at": datetime.utcnow().isoformat(),
            "auto_approve_threshold": auto_approve_threshold,
            "auto_reject_threshold": auto_reject_threshold,
        },
    )

Kill Switch Implementation

Article 14(4)(e) explicitly requires the ability to "interrupt the operation of the high-risk AI system through a stop button." Here is a minimal implementation:

typescript 
interface KillSwitchState {
  systemId: string;
  isActive: boolean;
  deactivatedBy: string | null;
  deactivatedAt: string | null;
  reason: string | null;
  fallbackBehavior: "reject_all" | "human_only" | "cached_responses";
}

class AIKillSwitch {
  private state: KillSwitchState;

  constructor(systemId: string) {
    this.state = {
      systemId,
      isActive: true,
      deactivatedBy: null,
      deactivatedAt: null,
      reason: null,
      fallbackBehavior: "reject_all",
    };
  }

  deactivate(operatorId: string, reason: string): void {
    this.state.isActive = false;
    this.state.deactivatedBy = operatorId;
    this.state.deactivatedAt = new Date().toISOString();
    this.state.reason = reason;
    this.emitAuditEvent("SYSTEM_DEACTIVATED", this.state);
  }

  checkActive(): boolean {
    return this.state.isActive;
  }

  private emitAuditEvent(eventType: string, payload: unknown): void {
    console.log(JSON.stringify({ eventType, payload, timestamp: new Date().toISOString() }));
  }
}

These patterns are directly related to the jailbreak defense mechanisms covered in LLM Jailbreak Analysis and Defense—when a jailbreak is detected, the kill switch can immediately halt the compromised system.

Fundamental Rights Impact Assessment

Article 27 requires certain deployers of high-risk systems to conduct a Fundamental Rights Impact Assessment (FRIA) before use. It is related to, but not interchangeable with, a GDPR DPIA; applicability and required content must be checked against the article and the deployer's role.

FRIA Template Structure

All dates, counts, thresholds, review cadences, and outcomes in this YAML are fictional placeholders. Replace them with a documented legal basis and an approved rights assessment; none is a statutory default.

yaml 
fria:
  metadata:
    system_name: "AI Resume Screening System v2.1"
    system_id: "HRS-2026-001"
    deployer: "TechCorp International"
    assessment_date: "2026-05-16"
    assessor: "Compliance Engineering Team"
    review_frequency: "quarterly"

  scope:
    intended_purpose: "Automated screening of job applications"
    target_population: "Job applicants in EU member states"
    geographic_scope: ["DE", "FR", "NL", "ES", "IT"]
    estimated_affected_persons: 50000
    deployment_timeline: "2026-Q3"

  rights_impact_analysis:
    - right: "Non-discrimination (Article 21 EU Charter)"
      risk_level: "high"
      description: "Model may exhibit bias based on gender or ethnicity in resume language"
      affected_groups: ["gender_minorities", "ethnic_minorities", "age_groups"]
      mitigation:
        - "Demographic parity testing with 0.8 threshold"
        - "Blind resume processing - PII stripped before model inference"
        - "Quarterly bias audit by external assessor"
      residual_risk: "medium"

    - right: "Right to an effective remedy (Article 47 EU Charter)"
      risk_level: "medium"
      description: "Rejected candidates must be able to contest AI-assisted decisions"
      affected_groups: ["all_applicants"]
      mitigation:
        - "Human review mandatory for all rejections"
        - "Explainability report generated per decision"
        - "Appeals process with 30-day SLA"
      residual_risk: "low"

    - right: "Right to privacy (Article 7 EU Charter)"
      risk_level: "medium"
      description: "Processing of personal data in resumes and application materials"
      affected_groups: ["all_applicants"]
      mitigation:
        - "Data minimization - only relevant fields extracted"
        - "Auto-deletion after 180 days per GDPR Article 17"
        - "Encryption at rest and in transit"
      residual_risk: "low"

  oversight_measures:
    human_review_trigger: "All negative decisions"
    operator_training: "40-hour AI oversight certification"
    escalation_path: "Operator > Team Lead > DPO > Legal"

  conclusion:
    overall_risk: "medium"
    deployment_approved: true
    conditions: "Subject to quarterly bias audit and annual FRIA review"

Validate YAML and compare FRIA revisions with the repository's ordinary CI tooling; the choice of formatter is not a regulatory control.

Conformity Assessment and CE Marking

The conformity-assessment route depends on the system's legal route, applicable product legislation, harmonised standards, and the relevant Annex III category. Do not encode “biometric” or “critical infrastructure” as the only deciding conditions without checking Article 43 and current guidance.

Self-Assessment Decision Logic

typescript 
type AssessmentRoute = "self_assessment" | "notified_body_required";

interface ConformityResult {
  systemId: string;
  route: AssessmentRoute;
  annexIVComplete: boolean;
  riskManagementComplete: boolean;
  biasTestingPassed: boolean;
  humanOversightImplemented: boolean;
  auditLoggingActive: boolean;
  ceMarkingEligible: boolean;
  blockers: string[];
}

function evaluateConformityReadiness(
  systemId: string,
  category: string,
  checks: ComplianceChecks
): ConformityResult {
  const needsNotifiedBody =
    category === "biometric_identification" ||
    category === "critical_infrastructure";

  const blockers: string[] = [];
  if (!checks.annexIVDocumentation) blockers.push("Annex IV documentation incomplete");
  if (!checks.riskManagementSystem) blockers.push("Risk management system not established");
  if (!checks.biasTestingPassed) blockers.push("Bias testing thresholds not met");
  if (!checks.humanOversightMechanism) blockers.push("Human oversight not implemented");
  if (!checks.auditLogging) blockers.push("Audit logging not active");
  if (!checks.friaCompleted) blockers.push("FRIA not completed");

  return {
    systemId,
    route: needsNotifiedBody ? "notified_body_required" : "self_assessment",
    annexIVComplete: checks.annexIVDocumentation,
    riskManagementComplete: checks.riskManagementSystem,
    biasTestingPassed: checks.biasTestingPassed,
    humanOversightImplemented: checks.humanOversightMechanism,
    auditLoggingActive: checks.auditLogging,
    ceMarkingEligible: blockers.length === 0,
    blockers,
  };
}

The output of this function is an internal readiness record, not an EU Declaration of Conformity. CE marking requires the applicable conformity procedure, responsible legal entity, declaration, registration and other product-law steps; passing these booleans alone does not authorise market placement.

AI Literacy Program

Article 4 establishes AI-literacy duties for providers and deployers, subject to the staged application of the Act and the context of the people involved. Training hours are not prescribed by the Act; define role-specific competence and evidence.

What AI Literacy Means in Practice

This is not about making everyone an ML engineer. It means:

  1. Operators understand the system's capabilities, limitations, and known failure modes
  2. Developers understand the regulatory obligations their code must satisfy
  3. Business stakeholders understand the risk classification and its implications
  4. End users are informed when they interact with an AI system (transparency obligation)

Minimum Training Curriculum

Role Required Knowledge Hours
ML Engineers Full Annex IV documentation, bias testing, logging requirements 16
Backend Engineers Audit logging, kill switch, human oversight API integration 8
Product Managers Risk classification, FRIA process, post-market monitoring 8
Operators System limitations, override procedures, escalation protocols 12
Customer Support Transparency scripts, user rights, complaint handling 4

For engineering teams working with AI Agents, literacy training should also cover autonomous decision-making risks and the additional oversight requirements for agentic systems. Our guide on Harness Engineering provides a framework for evaluating and constraining agent behavior.

Post-Market Monitoring

Article 72 requires a post-market monitoring system proportionate to the nature and risks of the AI system. This must be established before deployment and maintained throughout the system's lifecycle.

Monitoring Dashboard Schema

The metrics below are illustrative operational baselines, not legal thresholds or mandatory retention periods. Calibrate them to the intended purpose, risk, data quality, and incident procedure.

yaml 
post_market_monitoring:
  system_id: "HRS-2026-001"
  monitoring_plan:
    frequency: "continuous"
    review_cadence: "monthly"
    responsible_team: "ML Platform - Compliance"

  metrics:
    performance:
      - name: "accuracy"
        baseline: 0.94
        threshold: 0.90
        current: null
        alert_on: "below_threshold"
      - name: "false_positive_rate"
        baseline: 0.03
        threshold: 0.05
        current: null
        alert_on: "above_threshold"

    fairness:
      - name: "demographic_parity_ratio"
        baseline: 0.92
        threshold: 0.80
        current: null
        alert_on: "below_threshold"
        protected_attributes: ["gender", "ethnicity", "age_group"]

    operational:
      - name: "human_override_rate"
        baseline: 0.08
        alert_on: "above_0.15_or_below_0.02"
        description: "Anomalous rates may indicate model drift or miscalibrated thresholds"
      - name: "mean_confidence_score"
        baseline: 0.87
        alert_on: "below_0.75"

  incident_reporting:
    serious_incident_sla: "Verify Article 73 deadline for the incident type"
    internal_escalation: "24 hours to compliance team"
    root_cause_analysis: "required within 30 days"

  data_retention:
    audit_logs: "Policy-defined; document legal basis"
    monitoring_reports: "Policy-defined; document legal basis"
    incident_records: "Policy-defined; document legal basis"

Monitoring should trigger triage, containment, investigation, and escalation according to the incident definition and applicable procedure. Article 73 does not create a universal 72-hour rule analogous to GDPR; verify the relevant deadlines and exceptions in the current text before encoding an SLA.

For teams using vector databases in production RAG systems, post-market monitoring should also track retrieval quality metrics and embedding drift. If your retrieval pipeline degrades, the downstream AI system's compliance posture is directly affected.

Further Reading

FAQ

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

Potentially. Article 2 requires a fact-specific analysis of provider/deployer role, market placement or deployment, and output use. A third-country product is not automatically in scope merely because an EU resident can view an output; check the current Regulation and guidance.

What is the difference between high-risk and limited-risk AI systems?

High-risk status depends on intended purpose, role, applicable product-safety route, Article 6, Annex III, and documented exceptions. Transparency duties are also use-specific; direct interaction alone does not settle classification.

How much does EU AI Act non-compliance cost?

The Act sets different maximum administrative-fine levels depending on the violation and undertaking. Quote the applicable article and current consolidated text; headline caps are not an automatic bill.

When should I start preparing for EU AI Act compliance?

Start with an applicability record now. The Act uses staged dates and transition rules for prohibited practices, AI literacy, GPAI, high-risk systems, and product-embedded systems; do not rely on a countdown without checking Article 113 and current guidance.

Can I use open-source models and still be compliant?

Possibly. Open-source treatment depends on the provider's role, model characteristics, and applicable Article 53 conditions. A downstream provider or deployer may have separate duties based on the integrated system and intended purpose; record the model revision, license, role, data, evaluations, and mitigations.

Summary

The EU AI Act is not abstract policy—it is a concrete set of engineering requirements with hard deadlines and significant penalties. For any AI product team targeting the EU market, the compliance checklist comes down to six infrastructure pillars:

  1. Applicability and classification: Record the role, intended purpose, legal route, exceptions, and reasoning.
  2. Audit logging: Implement traceable, privacy-aware event recording with integrity and retention controls.
  3. Evaluation: Choose fairness, accuracy, robustness, and security measures that fit the use and document uncertainty.
  4. Human oversight: Build confidence-gated routing and kill switches into your inference architecture.
  5. Technical documentation: Generate and maintain Annex IV documentation as living artifacts, not one-time PDFs.
  6. Post-market monitoring: Deploy continuous monitoring with automated alerting and incident response SLAs.

Dates and obligations must be checked against the current consolidated Regulation, transition rules, and guidance. Responsible engineering controls are useful evidence, but they do not by themselves establish legal compliance.

For deeper exploration of the security and evaluation patterns that underpin compliance, continue with the Harness Engineering series—particularly the guides on LLM jailbreak defense and AI agent privacy.

Primary Sources