EU AI Act Developer Compliance Checklist 2026

The August 2, 2026 EU AI Act enforcement date isn’t moving — at least not for most teams. And yet the majority of engineers building AI features for EU users have a compliance gap that looks less like a sprint and more like a full quarter of catch-up work.

The EU AI Act isn’t written for engineers. It’s written for legal teams, procurement leads, and policymakers. That’s the problem.

This guide doesn’t explain what the AI Act is — there are plenty of those. It maps every enforceable obligation on the high-risk AI track to a specific engineering task: a YAML file to write, a CI gate to add, a log schema to implement. Open a ticket for each one. Close the gap sprint by sprint. EU AI Act developer compliance starts with knowing exactly what “done” looks like in code.

Does Your AI Feature Even Qualify as High-Risk? Run the Annex III Classification in Under an Hour

Before writing a single line of compliance code, you need to know where your system falls. The EU AI Act uses a tiered risk structure:

• Prohibited: Real-time biometric mass surveillance, social scoring, subliminal manipulation — if you’re shipping any of these, stop
• High-risk (Annex III): Specific sectors and use cases — employment decisions, education access, credit scoring, critical infrastructure, law enforcement
• Limited-risk: Chatbots, deepfakes — lighter disclosure obligations
• Minimal-risk: The majority of AI features — no mandatory requirements

The Annex III list covers eight domains. If your system makes or materially influences a consequential decision in any of them, you’re likely high-risk:

1. Biometric identification and categorization
2. Critical infrastructure management
3. Education and vocational training (determining access or outcomes)
4. Employment and worker management (CV screening, performance monitoring, task allocation)
5. Essential private and public services (credit scoring, social benefits eligibility)
6. Law enforcement
7. Migration and border control
8. Administration of justice

The engineering task here isn’t a legal opinion — it’s a versioned classification record. Create docs/ai-act/classification.md that answers each Annex III domain question, cites the specific subparagraph you reviewed, and names the engineer who signed off — then commit it to git. If you’re audited, “we checked the list” won’t hold up. “Here’s our reasoning in commit a4f8c2” will.

According to an appliedAI study of 106 enterprise AI systems, 18% were high-risk, 42% low-risk, and 40% had unclear classification. That ambiguity is expensive: misclassifying a high-risk system and correcting it post-deployment can increase compliance outlays by 20–40%. Locking AI risk classification in version control is the single highest-leverage thing you can do before any other compliance work begins.

If you’re near an edge case — a feature that might qualify as a high-risk employment or credit tool — document the Article 6(3) carve-out analysis too. That reasoning needs to survive team turnover.

Article 9 in Code: Turning the Risk Management Requirement Into a Living Risk Register

Article 9 says you must implement a risk management system for high-risk AI. Every legal guide repeats this. None of them say what it looks like as code.

It looks like a YAML file — version-controlled, updated as part of your engineering workflow. Not a spreadsheet a compliance officer owns. A document engineers touch every sprint.

A minimal schema:

# risk-register.yaml
schema_version: "1.0"
system_id: "loan-approval-classifier"
last_reviewed: "2026-04-01"
owner: "ml-platform-team"

risks:
  - id: RISK-001
    description: "Model shows higher false positive rate for non-native speakers"
    article_reference: "Art. 9, Art. 10"
    severity: high
    mitigation: "Stratified bias testing by language group added to QA pipeline (see test/bias/language_stratify.py)"
    residual_risk: medium
    status: mitigated
    last_updated: "2026-03-15"
    updated_by: "jane.smith@company.com"

Each entry maps a risk to its Article 9 obligation, names a mitigation, and tags an engineer. Add a RISK- entry creation step to your incident retrospective template. Require a risk-register.yaml diff on any PR that changes model architecture, training data, or inference logic.

The risk register isn’t a document you write once. Article 9 explicitly requires it to be applied “throughout the lifecycle.” That means it changes when your model changes.

Article 11 + Annex IV: Building a Machine-Readable Technical Documentation File That Survives CI/CD

Article 11 requires technical documentation to exist before deployment and stay current. Annex IV specifies what it must contain: system description, training data overview, monitoring approach, human oversight measures, and performance benchmarks.

For teams shipping continuously, a Word doc is unmanageable. You’ll ship a model update on Tuesday and forget to update the PDF by Wednesday. The only approach that scales is a machine-readable source file that generates the Annex IV document.

Create docs/ai-act/annex-iv.yaml:

# annex-iv.yaml
system:
  name: "Loan Approval Classifier v2"
  version: "2.4.1"
  intended_purpose: "Assists loan officers evaluating personal loan applications under €50,000"
  deployment_context: "Deployed by Acme Bank; used by loan officers in Germany and France"

training_data:
  datasets:
    - name: "Internal Loan History 2018–2024"
      size_records: 2400000
      bias_assessment: "docs/ai-act/bias-assessment-2024-q4.pdf"
  preprocessing_steps: "see ml/pipelines/preprocessing.py"

performance_metrics:
  accuracy: 0.91
  false_positive_rate: 0.07
  test_dataset: "holdout_2025_q1"
  last_evaluated: "2026-03-28"

human_oversight:
  override_mechanism: "Loan officer can reject any model recommendation via UI flag"
  audit_log: "All decisions logged to compliance-events topic (Article 12 logging)"

Add a CI step that lints this file against an Annex IV schema validator on every pull request. Missing required fields after a model change? Build fails.

Documentation preparation accounts for up to 40% of total conformity assessment costs, which run €5,000–€50,000 per system. Machine-readable docs you validate automatically pay that cost once. Also: Article 11 documentation must be retained for at least 10 years after deployment, so design your archiving strategy now.

Article 12: Why You Needed to Start Logging Yesterday — The 6-Month Retention Math

Here’s the calculation most guides skip entirely.

Article 12 requires high-risk AI systems to automatically generate logs retained for a minimum of six months. Enforcement begins August 2, 2026. If you start your logging program on August 2, you have zero months of retained logs on day one of enforcement.

Work backward: to have six months of logs on August 2, your logging infrastructure had to be live by February 2, 2026. If you’re starting now, you’re operating with a shrinking window — and you need to start this week, not next sprint.

What Article 12 logs must capture:

• Each use event (not each API call — one inference session or decision cycle)
• Input data characteristics (not necessarily raw inputs, depending on sensitivity)
• Output and confidence scores
• Human oversight events (overrides, rejections)
• System version at time of inference
• Timestamp and operator identifier

The logs must be automatically generated by the system itself. Manual logging processes don’t satisfy the requirement. The output must be machine-generated, machine-timestamped, and written to a tamper-evident or append-only store.

A baseline log schema:

{
  "event_id": "uuid-v4",
  "system_id": "loan-approval-classifier",
  "system_version": "2.4.1",
  "timestamp_utc": "2026-04-17T14:23:11Z",
  "operator_id": "acme-bank-loan-ops",
  "session_id": "session-uuid",
  "input_summary": {
    "feature_count": 42,
    "data_source": "loan_application_form",
    "sensitive_fields_present": true
  },
  "output": {
    "recommendation": "approve",
    "confidence": 0.87,
    "threshold_applied": 0.75
  },
  "human_oversight_event": null,
  "log_schema_version": "1.0"
}

One important caveat: as of April 2026, there is no finalized technical logging standard — drafts prEN 18229-1 and ISO/IEC DIS 24970 are still in progress. Design your schema to be extensible. You’ll migrate fields when standards finalize, not rebuild the entire pipeline. AI observability infrastructure helps you design a logging stack that satisfies Article 12 without rebuilding your entire data platform.

Push logs to an append-only store: AWS S3 Object Lock, GCS with bucket retention policies, or Kafka with compaction disabled for the compliance topic. Add a CI check that verifies the logging sink is configured before any high-risk model deployment proceeds.

Article 10: Baking Bias and Data Governance Checks Into Your QA Pipeline

Article 10 requires high-risk AI systems to be trained on data that is “relevant, representative, free of errors and complete” — and to actively address potential biases. This is a QA engineering requirement, not a data science research project you hand off to someone else.

Bias checks belong in your CI pipeline, running on every model update, with a pass/fail gate.

Tools that integrate cleanly:

• Great Expectations: Add validation suites that check for representation across protected characteristics. Fail the pipeline if demographic group representation falls below a defined threshold.
• Deepchecks: ML validation library with built-in drift detection and bias metrics. Run it as a CI step against your validation dataset on each model retrain.
• Evidently AI: Monitors data drift in production and can push alerts to your incident management system.

The Article 10 engineering checklist:
– [ ] Define protected characteristics relevant to your deployment domain
– [ ] Create stratified test splits by each characteristic
– [ ] Write a bias test suite (Great Expectations or Deepchecks)
– [ ] Add bias tests to CI — block merge if thresholds are breached
– [ ] Log bias metrics to your risk register, linked to specific RISK- entries
– [ ] Define a human review trigger (e.g., false positive rate for any group exceeds 1.5× the average)

Keep bias test results in version control alongside your model artifacts. You’ll need to show these results during a conformity assessment.

Article 14: Engineering Human Oversight — Override Mechanisms, Audit Trails, and the UI Changes You’ll Need

Article 14 is frequently summarized as “humans must be able to oversee the AI.” That sounds abstract until you break it into concrete UI and backend tasks.

Override mechanism: Every high-risk AI output must be rejectable by the human operator. This isn’t just a UI button — the rejection must be logged with a reason code, fed back into your Article 12 log, and capable of stopping downstream automated processes. If your model output triggers an automated API call two seconds later, a “reject” button that only updates the UI doesn’t satisfy Article 14.

Decision audit trail: Every human interaction with a model output — approval, rejection, modification — must be logged with a timestamp and user identifier. This is separate from your Article 12 system log, but linkable via session ID.

Interpretability surface: Operators must be able to “understand the capacities and limitations” of the system. Practically: your UI needs to surface confidence scores, flag when inputs fall outside the model’s trained distribution, and display known failure modes. At minimum, add a system info panel showing model version, last validation date, and documented edge cases.

Human-in-the-loop AI engineering requires planning override mechanisms from the architecture phase — retrofitting them is expensive and often architecturally messy.

The engineering task list:
– [ ] Implement override/reject mechanism with downstream process halt
– [ ] Log all human oversight events to Article 12 log schema via session ID
– [ ] Surface confidence scores in operator-facing UI
– [ ] Add out-of-distribution input detection (flag inputs that differ significantly from training distribution)
– [ ] Document failure modes in UI help text and in Article 13 instructions for use

Wiring It All Together: The Compliance Gates to Add to Your CI/CD Pipeline Before August 2

Compliance drift happens when there’s no automated check preventing it. Add these gates to your pipeline now.

PR-level checks — fail the build if:
– annex-iv.yaml is missing required Annex IV fields after a model-related file change
– risk-register.yaml has no entry with last_updated within 90 days on any model PR
– Bias tests fail against the validation dataset
– Logging sink configuration is missing or misconfigured
– classification.md has not been reviewed in more than 6 months

Deployment-level checks:
– Article 12 log schema version matches the deployed model version
– Human oversight override endpoint passes an integration test
– Out-of-distribution detection threshold is configured and active

A minimal GitHub Actions step:

- name: EU AI Act Compliance Gate
  run: |
    python scripts/compliance_check.py \
      --annex-iv docs/ai-act/annex-iv.yaml \
      --risk-register docs/ai-act/risk-register.yaml \
      --classification docs/ai-act/classification.md \
      --logging-config config/logging.yaml

The compliance_check.py script validates schema completeness, checks last-updated timestamps, and verifies logging configuration. It’s a few hundred lines of Python that prevents compliance rot between releases — worth building in Sprint 4.

Sprint-by-Sprint EU AI Act Compliance Roadmap: From Now to August 2, 2026

With roughly three months to go, here’s how to sequence the work across your remaining sprints.

Sprint 1 (Start immediately):
– Complete Annex III classification; commit docs/ai-act/classification.md
– Inventory every AI feature touching EU users — including SaaS-embedded AI and vendor-supplied models (the “shadow AI” gap is the most common compliance miss)
– Stand up Article 12 logging infrastructure — every day you delay shortens your retained log window

Sprint 2:
– Create docs/ai-act/risk-register.yaml with initial RISK- entries for identified risks
– Draft annex-iv.yaml for each high-risk system
– Integrate bias test suite into CI pipeline

Sprint 3:
– Build override/reject mechanism in operator-facing UI with downstream halt capability
– Implement decision audit trail; link to Article 12 log via session ID
– Add out-of-distribution input detection

Sprint 4:
– Build and add compliance_check.py to CI/CD
– Draft Article 13 instructions for use as a formal deliverable
– Run internal dry-run audit against Annex IV checklist

Sprint 5 (Buffer):
– Address gaps found in dry-run
– Verify 6-month log retention window is on track
– Engage a notified body for conformity assessment if required (budget €5,000–€50,000 depending on system complexity)

The math on why this matters: penalties for high-risk non-compliance reach up to €15 million or 3% of global annual turnover. Prohibited practices carry fines up to €35 million or 7% of global turnover. AI compliance failures cost organizations $4.4 billion in losses across 2025 alone. A five-sprint compliance program is cheap compared to a single enforcement action.

Write the Ticket, Not the Excuse

EU AI Act developer compliance isn’t a legal problem with engineering implications — it’s an engineering problem that happens to have legal teeth. Every obligation in the high-risk AI track maps to something buildable: a YAML schema, a CI gate, a UI component, an append-only log sink.

The teams that struggle in August won’t be the ones who didn’t understand the regulation. They’ll be the ones who understood it and never opened a ticket.

Start with your Annex III classification today. It takes under an hour, it costs nothing, and it determines everything else on this list. Once you know where you stand, every item above has a clear owner, a definition of done, and a sprint slot to land in.