EU AI Act Gap Analysis: A Control-by-Control Method With a Matrix Template

An EU AI Act gap analysis is a control-by-control comparison of your current AI governance against the obligations that actually apply to your systems under Regulation (EU) 2024/1689. For each requirement you record the required state, your current state, the size of the gap, and a priority — and the output is a ranked remediation list, not a narrative report.

The governing logic is the obligation set in Chapter III, Section 2 (Articles 9–15) for high-risk systems, tied to your role under Article 16 (provider) or Article 26 (deployer). The analysis is only as good as the inventory feeding it: you cannot assess an obligation you have not yet mapped to a system and a role. This guide gives you the five-step method, the six-column matrix, and a worked high-risk row set you can copy.

---

What an EU AI Act Gap Analysis Actually Is

The Working Definition

A gap analysis is requirement-by-requirement, not thematic. Each applicable obligation under Regulation (EU) 2024/1689 becomes one row, and you assess current-state against required-state for that single control. The deliverable is a gap-analysis matrix plus a prioritised remediation backlog — every item tied to an article, an owner, and a deadline.

That is the difference between an exercise that produces action and one that produces a document nobody reads. A gap analysis names the specific control, the specific shortfall, and the specific fix.

Gap Analysis vs Readiness Assessment

These two are routinely conflated, and the distinction changes what you get back.

A readiness assessment tells you roughly where you stand. A gap analysis tells you precisely what to remediate and in what order. If you are deciding whether to begin at all, start with where to start; if you already know the Act applies, the gap analysis is the next instrument.

What the Output Looks Like

The artefact is a six-column matrix feeding a backlog. Each backlog item carries an owner, an effort estimate, a target date, and the article it closes. No prose summary substitutes for it, because a prose summary cannot be sequenced, assigned, or re-run.

---

The Five-Step Gap Analysis Method

The method is linear and repeatable. Run it once to establish the baseline, then re-run it after each remediation sprint.

1. Scope which systems. Pull from your AI inventory every system that makes or supports a consequential decision, generates outputs used downstream, or processes personal data. Obligations attach per system, not per company — so a single tool that is benign in one context and high-risk in another needs two assessments.
2. Determine applicable obligations by risk tier and role. For each system, fix the risk tier — prohibited under Article 5, high-risk under Article 6 read with Annex III, limited-risk transparency under Article 50, or minimal — and your role: provider under Article 16 or deployer under Article 26. The tier and role together derive the obligation set. Our risk classification guide walks the tiering decision in full.
3. Assess each obligation, current vs required. Write the required state (what the Article demands) beside the current state (what you actually have today, with evidence). This side-by-side comparison is what makes it a gap analysis rather than a checklist.
4. Rate the gap. Score each row as none (compliant, evidenced), partial (a control exists but is incomplete or undocumented), or missing (no control). A three-state rating drives clearer prioritisation than a numeric score nobody can defend.
5. Prioritise by risk and deadline. Rank in-force obligations and high-residual-risk systems above obligations whose deadline has moved and low-impact systems. Map each gap to the penalty tier it sits under so the ranking is defensible, not subjective.

---

The Gap-Analysis Matrix (With a Worked Template)

The Six Columns

The core artefact uses six columns: Requirement | Article | Current state | Required state | Gap | Priority. The whole exercise exists to populate this table.

Each row should carry an evidence pointer in the current-state cell — a policy link, a log sample, a document ID — so the matrix doubles as the audit trail an authority would request. Priority should reference both the penalty tier and the applicable deadline.

A Worked High-Risk Row Set

For a high-risk system, the first-pass matrix usually looks like this. Most companies score partial or missing on the majority of rows.

How to Keep It Audit-Defensible

The matrix is a living register, not a one-time deliverable. Re-run it after each remediation sprint and after any substantial modification (Article 3(23)) that could change a system's classification or your role. A frozen matrix from twelve months ago is evidence of nothing.

---

The High-Risk Requirement Set: Articles 9–15

For any system classified high-risk, Articles 9–15 are the dense core of the gap analysis. Each is its own row.

Risk Management and Data Governance — Articles 9–10

Article 9 requires a risk management system established, implemented, documented and maintained as a continuous, iterative process across the system's lifecycle — not a one-off assessment. Article 10 requires data governance: training, validation and testing data sets must meet quality criteria appropriate to the intended purpose. Treat Article 9 as the spine — the risk management system feeds the data, documentation, oversight and robustness controls, so a missing Article 9 row usually predicts gaps across the rest. See the Article 9 risk management system for the full lifecycle breakdown.

Documentation, Logging and Transparency — Articles 11–13

Article 11 requires technical documentation drawn up before the system is placed on the market, with the minimum content set out in Annex IV. Article 12 requires automatic recording of events (logging) over the system's lifetime. Article 13 requires transparency and instructions for use to deployers, so they can interpret and use the output correctly.

Human Oversight and Robustness — Articles 14–15

Article 14 requires human oversight to be designed into and enabled for the system — built in, not bolted on. Article 15 requires appropriate levels of accuracy, robustness and cybersecurity, maintained across the lifecycle.

---

Provider vs Deployer: Assessing Article 16 and Article 26 Duties

Your role determines which obligation rows even appear in the matrix.

Provider Obligations — Article 16

A provider carries the full stack: risk management, technical documentation, conformity assessment, registration, and post-market monitoring. If you build a high-risk system, or place one on the market under your own name, every Article 9–15 row is yours plus the Article 16 procedural duties on top.

Deployer Obligations — Article 26

A deployer carries a lighter but real set. Assess these rows: use the system per the provider's instructions; ensure human oversight; monitor operation and report serious incidents; keep automatically generated logs; and — where applicable — run a Fundamental Rights Impact Assessment under Article 27.

When Role Shifts Change the Gap

The same system can put you in both roles for different obligations. Worse, it can shift you from deployer to provider under Article 25 if you rebrand, substantially modify, or change the intended purpose of a high-risk system. Flag role-shift risk explicitly in the matrix: a planned fine-tune or rebrand can convert a short deployer row-set into the full Article 16 provider stack, materially expanding the gap. Mis-assigning the role is the most common gap-analysis error — it causes companies either to over-invest against provider duties they do not hold, or to miss provider duties they do.

---

Documentation and AI Literacy: Two Rows Most Companies Miss

Technical Documentation — Article 11 / Annex IV

Article 11 read with Annex IV defines the minimum technical documentation a high-risk provider must hold: a general description of the system, design specifications, data requirements, the risk management system, and post-market monitoring among other elements. Annex IV is effectively a documentation checklist in its own right — so map each Annex IV element to a current-state evidence pointer rather than scoring Article 11 as a single line. Otherwise a partial rating hides which half is missing.

AI Literacy — Article 4, Already in Force

Article 4 (AI literacy) applies to providers and deployers and has been in force since 2 February 2025. It is not a future obligation, so a missing rating here is a live exposure, not a planning item. It is frequently scored none because it has no certification and feels soft — yet it is a documented duty across all risk tiers. Assess whether staff who use AI have demonstrable, role-appropriate competence.

Both rows are easy to overlook precisely because they are paperwork-and-people obligations rather than engineering ones — which is exactly why they belong explicitly in the matrix.

---

Timing the Gap Analysis: What Is in Force vs What Moved

The priority column lives or dies on getting the dates right.

Already in Force

Three obligation sets are already live and rank highest regardless of any deferral:

• Article 5 prohibitions — since 2 February 2025.
• Article 4 AI literacy — since 2 February 2025.
• GPAI model obligations (Articles 51–55) — since 2 August 2025.

The 2 December 2027 High-Risk Date Is Agreed but Not Yet Law

Under the Digital Omnibus political agreement (6–7 May 2026, COREPER text confirmed around 13 May 2026), the stand-alone high-risk Annex III date is set to move from 2 August 2026 to 2 December 2027, and Annex I product-embedded high-risk from 2 August 2027 to 2 August 2028.

State the freshness caveat plainly: as of June 2026 this is agreed but NOT yet law. It still needs a European Parliament plenary vote, formal Council adoption, and Official Journal publication. Until then the statute still reads 2 August 2026 for high-risk Annex III — so plan to the earlier date and treat the later one as the working target. The deferral is to fixed calendar dates; it is not tied to the availability of harmonised standards. The standards-contingent "stop-the-clock" proposal was rejected, so do not describe the high-risk timeline as standards-dependent.

Not everything moved. A new 2 December 2026 deadline was added (the CSAM/"nudifier" prohibition and content-marking duties), and most Article 50 transparency is unchanged, with content-marking and watermarking applying from 2 December 2026.

How Timing Changes Your Priority Column

The practical rule: in-force obligations first, then the nearest fixed future dates (2 December 2026), then the high-risk set planned for 2 December 2027 and 2 August 2028. Cross-reference the penalty tiers so each priority carries its exposure.

---

Turning the Gap Analysis Into a Remediation Plan

From Rated Rows to a Ranked Backlog

Convert each partial and missing row into a remediation item with an owner, an effort estimate, a target date, and the article it closes. The prioritised list is the point of the whole exercise — feed it into the compliance implementation roadmap and track it against the compliance checklist.

Sequencing Against the Deadline

Sequence backward from the operative deadline for each system. Front-load in-force gaps and the long-lead high-risk work — Article 9 risk management, Annex IV documentation, Article 14 oversight design — that takes months to assemble. Re-run the gap analysis after each sprint so the matrix shows movement from missing → partial → none. That movement is itself your evidence of good-faith progress.

How Confir Auto-Generates the Gap List

Confir's compliance engine auto-generates the gap list. It walks each inventory entry through Article 5 and Article 6 / Annex III classification, derives the role via Article 25 logic, and outputs the applicable obligation rows already rated — with the rule that fired shown in plain English.

The engine is deterministic and rule-based: the same inputs always produce the same gap list, with the same logic every time — no model inference, no hallucination. Every rating is traceable to the article that triggered it, which is exactly what an audit defence requires.

---

How Confir Helps

Running a control-by-control gap analysis across a fleet of systems by hand is where most programmes stall. Confir structures the entire flow: the AIRC module classifies each inventory entry under Articles 5 and 6 / Annex III and assigns the role under Article 25 logic; AITR covers the data and technical-robustness rows (Articles 10 and 15); AITO covers transparency and human oversight (Articles 13 and 14); and AIGM covers governance, risk management and post-market monitoring (Articles 9, 16 and 26). The output is the six-column matrix already populated and rated, with each rating traceable to the article that triggered it.

Because the synthesis engine is deterministic and rule-based — the same logic every time, no model inference, no hallucination — re-running the gap analysis after a remediation sprint produces a clean, comparable delta you can show an authority.

---

Frequently Asked Questions

What is an EU AI Act gap analysis? It is a control-by-control comparison of your current AI governance against the obligations that apply to your systems under Regulation (EU) 2024/1689. For each requirement you record the required state, your current state, the gap (none, partial or missing) and a priority. The output is a prioritised remediation list, not a narrative report.

What is the difference between a gap analysis and a readiness assessment? A readiness assessment is a higher-level maturity sweep that asks whether you have processes at all. A gap analysis is the deeper, requirement-by-requirement comparison: it names the specific Article, the exact shortfall, the evidence you hold, and the fix. The readiness assessment tells you roughly where you stand; the gap analysis tells you precisely what to remediate and in what order.

How do I do an EU AI Act gap analysis? Five steps. Scope which systems from your inventory; determine applicable obligations by risk tier and role; assess each obligation current state versus required state; rate the gap as none, partial or missing; then prioritise by risk exposure and deadline. The result is a six-column matrix (requirement, article, current state, required state, gap, priority) feeding a ranked remediation backlog.

Which articles apply to high-risk AI systems? The core high-risk requirement set is Articles 9 to 15: risk management (Art 9), data governance (Art 10), technical documentation (Art 11 with Annex IV), logging (Art 12), transparency to deployers (Art 13), human oversight (Art 14), and accuracy, robustness and cybersecurity (Art 15). Providers then add Article 16 duties; deployers carry Article 26 duties.

When do EU AI Act high-risk obligations apply? The Digital Omnibus agreed in May 2026 sets the stand-alone high-risk Annex III date at 2 December 2027 and product-embedded high-risk at 2 August 2028. As of June 2026 this is agreed but not yet law — it still needs Parliament and Council adoption and publication, so the statute still reads 2 August 2026. Plan to the earlier date.

What goes in a gap-analysis matrix? Six columns: the requirement in plain English; the Article (and Annex where relevant); the current state with an evidence pointer; the required state the Article demands; the gap rated none, partial or missing; and a priority tied to the penalty tier and deadline. Each high-risk obligation under Articles 9 to 15 becomes its own row, as do Article 16, Article 26 and Article 4.

What are the penalties for non-compliance with the EU AI Act? There are three tiers. Article 5 prohibition breaches reach up to €35 million or 7% of worldwide annual turnover (Article 99(3)). Most other obligation breaches reach up to €15 million or 3% (Article 99(4)). Supplying incorrect, incomplete or misleading information to authorities reaches up to €7.5 million or 1% (Article 99(5)). SMEs and start-ups get proportional caps under Article 99(6).

---

Related guides

• the ready-to-use EU AI Act gap analysis template
• Where to start with EU AI Act compliance
• The compliance implementation roadmap
• The EU AI Act compliance checklist
• AI risk classification framework
• The Article 9 risk management system
• EU AI Act penalty tiers explained