Skip to content
Confir.
Blog

EU AI Act Gap Analysis Template: A Copy-Paste Compliance Matrix

Template29 May 2026· 16 min read

A free EU AI Act gap analysis template: a copy-paste matrix mapping every obligation (Articles 9-15, 16, 26) to its gap, owner, and the 2 Dec 2027 deadline.

A gap analysis under Regulation (EU) 2024/1689 (the EU AI Act) maps each binding obligation against your current controls to surface the delta — then assigns a priority, an owner, and a target date to every gap. For a high-risk AI system the core obligations sit in Articles 9 to 15, with provider duties in Article 16 and deployer duties in Article 26.

This page gives you the matrix as a clean markdown table you can paste straight into Google Sheets or Excel and start filling in today. It differs from a yes/no checklist: a checklist confirms a control is present, a gap analysis measures the distance between today's state and the legal requirement and turns each gap into an owned, dated action.

Before you populate a single row, classify your systems under Article 6 and Annex III and confirm which deadlines actually bind you — the timeline shifted in 2026 and not every date moved. The sections below walk through classification, hand you the matrix, explain each row, and show how to prioritise and remediate.


What an EU AI Act Gap Analysis Is

A gap analysis is the diagnostic step before remediation. It is not a policy, a control, or a sign-off — it is the structured comparison that tells you, obligation by obligation, how far your organisation is from the legal requirement and what it will take to close the distance.

Gap analysis vs. compliance checklist

The two artifacts are complementary, not interchangeable. A checklist answers is the control present? with a tick. A gap analysis answers how far are we from the requirement, who owns the work, and when is it due? Use the compliance checklist to verify presence; use the matrix on this page to plan and sequence the work.

DimensionCompliance checklistGap analysis matrix
Output per itemYes / no / partialDelta + priority + owner + date
Question answeredIs the control present?How far are we, and who closes it?
Best forVerification, audit prepPlanning, sequencing, remediation
FormatCheckbox listEight-column matrix
LifecyclePoint-in-time confirmationLiving document, re-baselined

Who needs to run one — providers, deployers, importers

Scope the analysis by role first, because the duty set depends on it. A provider (Article 16) develops a high-risk system and places it on the market under its own name; a deployer (Article 26) uses one under its own authority in a professional context; an importer (Article 23) and distributor (Article 24) sit in the supply chain between them. A single organisation is frequently both provider and deployer for different systems — so run the matrix per system, not per company.

How this template is structured

The matrix has eight columns: Requirement | Article | Applies (Y/N) | Current state | Gap | Priority | Owner | Target date. The first two columns are fixed; the rest you fill in. Run the applicability triage first — classify each system against Article 6 and Annex III so the Applies column is grounded in a documented decision, not a guess. Once the dated gaps exist, pair the matrix with the implementation roadmap to sequence them into a delivery plan.


Before You Start: Classify Your Systems and Confirm Which Deadlines Bind

The matrix only fully applies to high-risk systems. Two questions decide how much of it you fill in: what risk tier is each system? and which dates actually bind me right now?

Risk classification under Article 6 and Annex III

Determine the risk tier before anything else:

  1. Prohibited — practices banned outright under Article 5 (in force since 2 February 2025).
  2. High-risk — under Article 6(1) where the system is a safety component of a product covered by Annex I harmonisation legislation, or under Article 6(2) where it falls within an Annex III stand-alone use case.
  3. Limited-risk — transparency duties under Article 50 (chatbots, synthetic media, deepfakes).
  4. Minimal risk — no specific obligations beyond the cross-cutting ones.

The full obligation matrix below is written for high-risk systems. For a limited-risk system you fill in only the transparency, literacy, and role rows.

What is already in force today

Three obligation sets bind you now and were not deferred:

  • Article 5 prohibitions — since 2 February 2025.
  • GPAI provider obligations under Articles 51-55 — since 2 August 2025.
  • Article 4 AI-literacy duty — applies to all AI, not only high-risk.

Keep these rows at the top of the matrix regardless of any change to the high-risk timeline.

The Digital Omnibus deferral — agreed, not yet law

A provisional political agreement on the Digital Omnibus (reached 6-7 May 2026, with the COREPER text confirmed around 13 May 2026) agreed to defer the stand-alone Annex III high-risk obligations under Article 6(2) from 2 August 2026 to 2 December 2027, and the Annex I product-embedded high-risk obligations under Article 6(1) from 2 August 2027 to 2 August 2028.

As of June 2026 this deferral is agreed but not yet law. It still needs a European Parliament plenary vote, formal Council adoption, and publication in the Official Journal. Until that happens the statute still reads 2 August 2026 for stand-alone Annex III high-risk systems. Plan against the earlier date until the change is published, then update your target dates.

Two further points matter for sequencing. The new dates are fixed calendar dates — the "stop-the-clock" proposal that would have tied the delay to the availability of harmonised standards was rejected, so do not treat the timeline as standards-contingent. And a new 2 December 2026 deadline was added (a CSAM / "nudifier" prohibition plus content-marking obligations), while most Article 50 transparency duties are unchanged with content-marking and watermarking moving to 2 December 2026.


The Copy-Paste EU AI Act Gap Analysis Template

Copy the table below directly into a spreadsheet. The first two columns are fixed reference; fill in the remaining six per system. Keep provider and deployer rows visually separated so a dual-role organisation can see both duty sets without double-counting.

RequirementArticleApplies (Y/N)Current stateGapPriorityOwnerTarget date
Risk management systemArt 9
Data and data governanceArt 10
Technical documentationArt 11 / Annex IV
Record-keeping and loggingArt 12
Transparency and instructions for useArt 13
Human oversightArt 14
Accuracy, robustness, cybersecurityArt 15
Provider obligations (consolidated)Art 16
EU database registrationArt 49
Deployer obligationsArt 26
Fundamental rights impact assessment (FRIA)Art 27
AI literacyArt 4
Prohibited-practice screenArt 5
Limited-risk transparencyArt 50

Column definitions

  • Applies (Y/N) — the output of your Article 6 and role-based triage, not a guess.
  • Current state — evidence-backed fact: the actual policy, log, or document, linked. An aspiration is not a current state.
  • Gap — the specific missing control or artefact, described concretely.
  • Priority — driven by the binding date and the penalty tier the gap sits under.
  • Owner — a single named person, never a team.
  • Target date — back-planned from the relevant deadline, with buffer for review.

Provider vs. deployer rows

Articles 9 to 16 and 49 are provider rows. Article 26 is the deployer row set, and Article 27 (FRIA) applies to certain deployers only. Article 4 (literacy) and Article 5 (prohibitions) bind both. Add a header note to the spreadsheet recording the classification decision and the assumed binding date, so the matrix is auditable later when someone asks why a date was set.


Row-by-Row: What Each Obligation Requires

This section explains the substance behind each Requirement cell so your Gap descriptions are grounded in what the article actually demands.

Risk, data, and documentation (Articles 9-12)

Risk management system - Article 9. A continuous, iterative risk management system running across the system's whole lifecycle, identifying and mitigating reasonably foreseeable risks to health, safety, and fundamental rights, and verifying the effectiveness of the measures adopted.

Data and data governance - Article 10. Training, validation, and testing data sets must meet quality criteria — relevant, sufficiently representative, and to the best extent possible free of errors and complete — under documented data-governance practices that examine bias and provenance.

Technical documentation - Article 11 and Annex IV. Technical documentation drawn up before the system is placed on the market and kept current, containing every element listed in Annex IV (system description, design and development, monitoring, performance metrics, risk management).

Record-keeping and logging - Article 12. The system must technically allow for the automatic recording of events (logs) over its lifetime, to a degree of traceability appropriate to its intended purpose.

Transparency, oversight, and robustness (Articles 13-15)

Transparency and instructions for use - Article 13. The system must be sufficiently transparent and accompanied by instructions for use that enable deployers to interpret and use the output appropriately.

Human oversight - Article 14. Effective oversight by natural persons must be built in, so a person can understand the output, monitor operation, and intervene in or halt the system during use.

Accuracy, robustness, cybersecurity - Article 15. Appropriate levels of accuracy, robustness, and cybersecurity, declared and maintained consistently across the lifecycle.

Provider, deployer, literacy, registration, and FRIA (Articles 16, 26, 4, 49, 27)

Provider obligations - Article 16 consolidates the provider's duties: ensuring conformity, drawing up documentation, registration, and corrective action. Deployer obligations - Article 26 require use in accordance with instructions, human oversight, input-data relevance where the deployer controls it, monitoring of operation, and log retention. AI literacy - Article 4 mandates a sufficient level of AI literacy among staff who operate or use the systems. EU database registration - Article 49 requires registration of high-risk systems in the EU database before market placement or putting into service. FRIA - Article 27 requires certain deployers — bodies governed by public law and specified actors — to carry out a fundamental rights impact assessment before deployment. Cross-reference the AI risk assessment workflow for the Article 9 and Article 27 rows, since both depend on a structured risk-scoring method.


How to Fill In and Prioritise the Matrix

Follow these steps for each system, in order:

  1. Classify and confirm role. Set the Applies column from the Article 6 and role triage. A row that does not apply is marked N, with the reason in Current state.
  2. Capture current state from evidence. Link the actual policy, log, or document — never an intention. An unverifiable claim is itself a gap.
  3. Describe the gap concretely. Name the specific missing control or artefact, not a vague "needs work".
  4. Score priority on two axes. Weigh proximity to the binding date against the penalty tier the gap sits under, so the most exposed obligations rise to the top.
  5. Assign one named owner. A single person per row, with the authority to act — not a team or a department.
  6. Back-plan the target date. Work backwards from the relevant deadline, leaving buffer for evidence review and any conformity-assessment lead time.

Setting priority by deadline and breach tier

Penalty exposure should shape priority. The fines under Article 99 are tiered:

Breach typeCap (whichever is higher)Reference
Article 5 prohibited practicesEUR 35 million or 7% of worldwide annual turnoverArt 99(3)
Most high-risk obligation breachesEUR 15 million or 3% of worldwide annual turnoverArt 99(4)
Incorrect / incomplete / misleading info to authoritiesEUR 7.5 million or 1% of worldwide annual turnoverArt 99(5)

For SMEs and start-ups, a proportional cap under Article 99(6) applies — the fine is the lower of the fixed sum or the percentage — which can shift the relative priority for smaller organisations.

Assigning owners and target dates

A gap analysis is not a one-off. Article 9 risk management and Article 72-style post-market monitoring make it a living document, so re-run the matrix on a fixed cadence and version each pass. Owners stay accountable across re-baselines; target dates move only when the binding date or the evidence does.


From Gaps to a Remediation Plan

A filled matrix is the input to delivery, not the end of it. Convert every non-empty Gap cell into a backlog item with the owner and target date intact, then sequence them.

Turning the matrix into a roadmap

Sequence the backlog by priority and dependency in the implementation roadmap. Keep the already-in-force rows — Article 5, the Articles 51-55 GPAI duties, and Article 4 literacy — at the top regardless of any deferral, because they bind today.

Where ISO 42001 fits

Map overlapping controls once. An ISO/IEC 42001 AI management system covers much of the Article 9, 10, and 17 ground, so the ISO 42001 gap assessment can be run alongside this matrix to avoid duplicate work. Where a control satisfies both frameworks, record the evidence once and reference it from both.

Keeping the analysis current as the law moves

Treat the binding-date assumption as a variable. When the Digital Omnibus deferral is published in the Official Journal, update the Target date column from the 2 August 2026 baseline to the agreed 2 December 2027 (Annex III) and 2 August 2028 (Annex I) dates. Re-baseline after every material model change, new intended purpose, or regulatory update. If you do not yet know your role or risk tier, start with where to start before populating rows, and keep the matrix versioned so the audit trail of decisions survives.


How Confir helps

Confir auto-generates this gap analysis. From a registered AI system it classifies the system under Articles 5 and 6 using Annex III logic, determines which articles apply, and pre-populates the Requirement, Article, and Applies columns — so your team starts from a structured matrix rather than a blank sheet. Each row maps to a specific Article or Annex provision, and gaps are linked to the underlying evidence and assigned owners and target dates inside the platform, so the export mirrors the copy-paste template above.

The synthesis engine is deterministic and rule-based: each obligation maps to a defined provision through the same logic every time, with no model inference and no hallucination. Binding dates update automatically as the legal calendar moves — including the in-force versus agreed-but-not-yet-law distinction — so target dates never drift from the statute. Use the static template here to scope manually; use Confir when you need the matrix maintained, evidenced, and re-baselined across a portfolio of systems.


Frequently Asked Questions

What is an EU AI Act gap analysis? It is a structured assessment that maps each binding obligation in Regulation (EU) 2024/1689 against your organisation's current controls to identify the delta — the gap. For each obligation you record current state, the missing control, a priority, an owner, and a target date, producing a prioritised, auditable remediation plan rather than a simple pass/fail checklist.

Which AI Act obligations does the gap analysis template cover? It covers the high-risk obligation domains: risk management (Article 9), data governance (Article 10), technical documentation (Article 11 and Annex IV), record-keeping (Article 12), transparency (Article 13), human oversight (Article 14), and accuracy and cybersecurity (Article 15). It also includes provider duties (Article 16), deployer duties (Article 26), AI literacy (Article 4), registration (Article 49), and FRIA (Article 27).

When do EU AI Act high-risk obligations apply? The statute currently reads 2 August 2026 for stand-alone Annex III high-risk systems. The Digital Omnibus agreement of May 2026 would defer this to 2 December 2027 and Annex I product-embedded systems to 2 August 2028, but as of June 2026 that change is agreed, not yet law — it still needs a Parliament vote, Council adoption, and Official Journal publication.

What are the penalties for non-compliance with the EU AI Act? Breaching the Article 5 prohibitions can cost up to EUR 35 million or 7% of worldwide annual turnover. Most other obligation breaches reach up to EUR 15 million or 3%. Supplying incorrect, incomplete, or misleading information to authorities is up to EUR 7.5 million or 1%. SMEs and start-ups benefit from a proportional cap under Article 99(6).

How do I fill in an AI Act gap analysis matrix? Classify each system's risk tier and role first, then mark which Articles apply. Record current state from actual evidence, not intentions. Describe each gap as a specific missing control, set priority by deadline proximity and penalty exposure, assign one named owner per row, and back-plan a target date from the relevant binding deadline.

Is a gap analysis the same as an EU AI Act compliance checklist? No. A checklist confirms whether a control is present with a yes/no answer. A gap analysis goes further: it measures the distance between your current state and the legal requirement, then turns each gap into an owned, dated remediation action with a priority. Use a checklist to verify presence and a gap analysis to plan the work.

What is already in force under the EU AI Act today? The Article 5 prohibitions have applied since 2 February 2025, and GPAI provider obligations under Articles 51-55 since 2 August 2025. The Article 4 AI-literacy duty also applies. These were not deferred by the Digital Omnibus, so they bind today regardless of any change to the high-risk timeline — keep them at the top of your matrix.


Manage your EU AI Act compliance in one place

Confir automates risk classification, technical documentation, and audit trails for any company. No consultants. No 6-month projects. 7-day free trial.

Start free trial →