The Engineering Manager's EU AI Act Compliance Checklist (2026)

Building an EU AI Act compliance checklist for engineering managers starts with one correction: the calendar most teams use is outdated. Codacy's own compliance research and the European Commission's Digital Omnibus agreement confirm that while the heaviest high-risk obligations now land in December 2027, the AI literacy duty has applied since February 2025, while its supervision and enforcement began in August 2026.

Knowing which is which determines where your team's limited engineering hours should go this quarter.

Most guidance on this topic is written for legal and GRC teams, leaving engineering managers to translate articles and recitals into repository controls, CI/CD policies, and logging on their own. This translation problem got harder in 2026 because the compliance timeline now runs on two tracks.

This checklist maps concrete engineering practices to specific obligations, marks what's legally required versus operationally recommended, and gives every item a verifiable basis so you can defend your prioritization to your own leadership.

How does the 2026 EU AI Act timeline actually break down?

The Regulation entered into force in August 2024 on a staggered schedule, and the Digital Omnibus reshaped that schedule without touching its underlying structure. Two obligations already apply and were untouched by the recent amendments, transparency rules apply from August 2026 with one narrow exception, and the heavy high-risk regime now has real runway.

The takeaway for engineering leaders isn't permission to defer everything. Literacy and transparency work is due now; high-risk build work has runway but benefits from starting the documentation and testing habit early. Note also that "applicable" and "in force" aren't the same thing in EU legislation, which is exactly why so many internal calendars got this wrong this year.

How should you read this checklist?

Each item below separates a legal duty from an engineering choice about how to satisfy it. The Regulation defines outcomes, not repository structure, so every item states what's required, why it exists, and one concrete way engineering teams commonly implement it, tagged Must have, Should have, or Nice to have based on how directly the Regulation supports it.

What should engineering track first: your AI inventory and risk classification?

You cannot classify risk, apply transparency rules, or evidence literacy for AI systems you haven't catalogued, which makes an inventory the precondition every other obligation depends on.

The mechanism that actually works is tying the registry to your codebase rather than a spreadsheet: a version-controlled file that updates through the same pull request process as the code it describes, so the inventory moves at the speed of your repositories instead of a quarterly survey nobody has time to run.

Given that research across 34,266 repositories found 1 in 4 organizations had gaps in AI agent config files, the case for automated inventory over self-reporting is hard to argue against. This is precisely the gap Codacy's AI Inventory is built to close, scanning committed config files, dependency manifests, and environment variables to surface AI models, SDKs, API keys, and MCP server definitions without asking developers to self-report.

• Maintain a registry of AI systems and models (Owner: Engineering Manager; Must have). Track role classification (provider vs. deployer), data flows, and where each system is embedded, gated by a required pull request for any addition or change.
• Classify each system against the four risk tiers (Owner: Engineering Manager with Legal for edge cases; Must have). Add a classification field and a short written rationale to the registry entry at design time, since Article 6 and Annex III determine which obligations actually bite.
  
  

What does AI literacy actually require from engineering teams?

Article 4 requires providers and deployers to take measures to support the development of AI literacy among their staff and other persons dealing with AI systems on their behalf, taking into account their technical knowledge, experience, education and training, and the context in which the AI systems are used.

This duty has been enforceable since February 2025 regardless of risk tier, with supervision and enforcement beginning in August 2026, which makes it the most overlooked near-term obligation on this whole list.

It covers the developers now using AI tools, not only people building AI-facing features, and Recital 20 defines literacy in principles-based terms rather than as a fixed curriculum, so there's no certificate to buy your way into. Compliance here is demonstrated through dated training records and role-calibrated content, not a badge on a wall.

• Run role-specific AI literacy sessions with dated records (Owner: Engineering Manager with People/HR; Must have). Cover how coding assistants make decisions, their limitations, and the risks they introduce into code, then keep completion records as your evidence trail.
• Fold secure AI development practices into onboarding (Owner: Engineering Manager with Security; Should have). This is an engineering control that strengthens your Article 4 evidence rather than a separate legal requirement, covering what not to paste into a model and where human review stays non-negotiable.
  
  

Which teams does Article 50 transparency actually reach?

Article 50 reaches far more engineering teams than the high-risk regime because it covers AI systems that interact directly with people and certain systems that generate or manipulate content, subject to specific conditions and exceptions.

Chatbot, virtual assistant, or generative feature that ships to users falls into scope from 2 August 2026, and the machine-readable marking requirement for synthetic content is the one piece worth tracking closely, since providers of generative AI systems already on the market before that date get a grace window running to 2 December 2026 under the amended Article 50(2), while anything placed on the market after August 2026 must comply immediately with no transition at all.

• Disclose AI interaction at first contact (Owner: Product with Engineering; Must have). Ship a reusable "you're interacting with AI" component and make its presence a merge check on AI-facing UI, per the requirement that the information be clear and distinguishable at first interaction.
• Mark AI-generated content in a machine-readable format (Owner: Engineering with Product; Must have, with the noted grace window). Apply provenance metadata at the generation service layer and test that the mark survives your content pipeline rather than getting stripped downstream.
• Record exemption rationales where you rely on one (Owner: Legal with Engineering Manager; Should have). Store a short decision record linked to the registry entry whenever you claim the editorial-responsibility carve-out or another exemption.
  
  

Should you build for high-risk obligations now if they don't apply until 2027?

Most teams using AI assistants and building internal tools will never fall inside the Annex III high-risk regime, but teams building systems that touch hiring, credit, or biometric identification should start the documentation habit now, because the deferred deadlines only bought time, not exemption.

Article 9 requires a risk management system that connects data governance, testing, and logging into one maintained process rather than a one-off assessment, and building that muscle in 2026 means it's already running when the December 2027 deadline for Annex III systems, or the August 2028 deadline for Annex I embedded systems, actually lands.

• Stand up a living risk register tied to releases (Must have if in scope). Gate high-risk releases in your CI/CD pipeline on an updated risk register entry, tested against predefined metrics before go-live and on any material change.
• Design an override-and-stop control with a named oversight owner (Must have if in scope). Article 14 requires effective human oversight, including the ability for designated people to intervene and, where appropriate, interrupt the system.
• Extend logging pipelines to capture material events (Must have if in scope). Article 12 requires automatic event logging for risk identification and post-market monitoring; wire this into observability you already run rather than bolting on a separate system.
• Template technical documentation as a release artifact (Must have if in scope). Treat Article 11 and Annex IV documentation as something generated alongside the system, not written after the fact.
  
  

What's different if you build on general-purpose AI models instead of training your own?

Most engineering teams integrate general-purpose AI models rather than provide them, and that distinction determines whether you inherit provider duties under Article 53.

If you place a GPAI model on the EU market yourself, you may be a provider (fine-tuning or modifying an existing GPAI model does not automatically make you a provider, although significant modifications can trigger provider obligations).

A provider has obligations around technical documentation, downstream information, a copyright compliance policy, and a public training-data summary using the AI Office template. If you simply call someone else’s API, you generally remain a downstream user or integrator rather than the GPAI provider, although obligations can still apply to the AI system you build or deploy.

• Record provider-versus-integrator status per model (Must have for anyone training or placing GPAI models; Should have as due diligence for integrators). Add this field to your model registry and store the upstream provider's documentation alongside, treating each integrated model like a software bill of materials entry.
• Publish a training-data summary and copyright policy if you're a provider (Must have if you are a GPAI provider). Keep the model card and training-data summary version-controlled and protected from unintended edits, since this is the evidence that supports your Article 53 obligations.
  
  

How should engineering teams handle logging and incident readiness?

Most of what makes the obligations above enforceable comes down to change management and monitoring that most teams already partially have, plus market-surveillance readiness that becomes enforceable in 2026, regardless of risk tier.

Pinning model and prompt versions in a version-controlled configuration means any change is reviewable and reversible, which matters because Chapter IX's market-surveillance apparatus, including the rewritten Article 75 and its companion articles, becomes applicable on 2 August 2026 alongside the transparency rules.

• Pin model and prompt versions under version control (Should have; engineering control, not a named legal requirement itself).
• Extend your incident process to cover AI-specific failure modes (Should have; readiness for a regime enforceable from 2026).
• Add AI-specific health metrics to existing dashboards (Should have generally, Must have if high-risk in scope).
  
  

What evidence actually needs to survive an audit?

Compliance for most obligations on this list is demonstrated through process and documentation rather than a fixed certificate, which means the durable trail matters as much as any individual control.

Short, ADR-style decision records for classification, exemption, and control choices, stored in version control next to the systems they describe, give you a defensible history when an auditor asks why a system was classified the way it was.

The second piece is retrievability: every registry entry should link one hop away to its literacy records, transparency implementation, and decision history, because documentation that can't be produced quickly under scrutiny doesn't help you.

Where does consistent enforcement fit?

The Regulation defines outcomes, but the recurring engineering challenge is enforcing them the same way across dozens of repositories.

The durable answer is enforcement at the point of change: checks in pull requests and CI, controls that travel with the codebase, and evidence generated as a byproduct of normal delivery rather than assembled later during a scramble. This is where a unified platform matters in practice.

Codacy applies consistent policy, security scanning, and quality gates across every connected repository, so items on this checklist like inventory hooks, marking checks, and evidence trails get enforced automatically through the AI Risk Hub rather than depending on individual developer discipline.

A policy only matters if it's actually enforced on every change, not just the ones someone remembers to review.