EU AI Act Gap Analysis: A Practical Evidence Checklist for 2026

Most companies that suspect they have an EU AI Act obligation are not short of information about the law. They are short of a view of their own position: which systems are affected, what proof already exists, and what is missing. An EU AI Act gap analysis is the exercise that produces that view.

A useful gap analysis does not end with a list of legal requirements. It identifies which AI systems are affected, what evidence is missing, who owns each remediation task, and what should happen next. This guide walks through the steps in order, the evidence to collect and the deliverables to expect, and closes with a checklist. It is technical and organisational guidance rather than legal advice: formal determinations for a specific system belong with your counsel.

What is an EU AI Act gap analysis?

An EU AI Act gap analysis is a structured comparison between the obligations that Regulation (EU) 2024/1689 places on your organisation and the evidence you can actually produce today. It works system by system: for each AI system you establish your role, classify the risk, gather the existing documentation, and record where proof is absent, incomplete or out of date. The output is a set of working documents rather than an opinion: an inventory, a classification record, an evidence register, a gap matrix and a remediation roadmap with owners and dates. The difference from a legal memo matters. A memo tells you that Article 12 requires automatic logging for high-risk systems. A gap analysis tells you that the credit-scoring model in your lending workflow writes logs the vendor deletes after 30 days, that nobody owns the fix, and that it has to be resolved before the high-risk obligations apply on 2 December 2027.

Why does the provider or deployer role come first in a gap analysis?

The provider or deployer role comes first in an EU AI Act gap analysis because it decides which obligations you are measuring against. A provider of a high-risk system is assessed against the design-and-evidence duties in Articles 9 to 16: risk management, data governance, technical documentation, logging, instructions for use, human oversight and accuracy. A deployer is assessed against the operational duties in Article 26: use according to the instructions, competent oversight, monitoring and log retention. Assess against the wrong role and every later finding is wrong with it. The role is set per system rather than per company, so a single organisation usually holds both. Record three things for each system: whose name it carries on the market, whether you have modified it or changed its intended purpose, and the reasoning behind the conclusion. Our guide to provider versus deployer obligations covers the Article 25 triggers that turn a deployer into a provider.

How do you create an AI system inventory?

An AI system inventory is a single register of every AI system your organisation develops, sells, buys or uses, and it is the foundation the rest of the gap analysis stands on. Cast the net wider than the projects your data team knows about. Most inventories surface three groups: systems built in-house, systems bought from vendors, and AI features embedded in software you already license, such as CV screening in an HR suite or lead scoring in a CRM. Procurement records, the software asset list and a short survey of department heads usually find more than interviews with IT alone. For each system, record eight fields: name, business owner, vendor or internal team, intended purpose, who is affected by its output, what data it uses, where it runs, and whether it is in development, pilot or production. Expect the list to be longer than anyone predicted, and expect most entries to turn out minimal-risk.

How do you classify each system's risk level?

Risk classification under the EU AI Act sorts each inventoried system into one of four tiers: prohibited practices under Article 5, high-risk under Article 6, limited risk with transparency duties under Article 50, and minimal risk with no specific obligations. High-risk status arrives by two routes. The first is AI used as a safety component of a product covered by the EU product legislation listed in Annex I, such as medical devices or machinery. The second is a use case listed in Annex III, including employment, education, creditworthiness, access to essential services and biometrics. Article 6(3) lets a provider conclude that an Annex III system is not high-risk when it performs only a narrow procedural or preparatory task, but that assessment has to be documented before the system is placed on the market. Write down the reasoning for every classification, including the minimal-risk ones. Our guide to the risk framework explains the tests, and the risk classifier gives a first indication.

What evidence should you collect for each AI system?

Evidence collection in an EU AI Act gap analysis covers seven areas, and in each one the question is the same: does a document or record exist, who owns it, and when was it last updated? Collect what exists before writing anything new, because a gap analysis measures the current state. For systems outside the high-risk tier, intended purpose and vendor documentation are usually enough. For high-risk systems all seven areas apply, weighted by role: providers carry the design evidence, deployers the operational evidence.

Intended purpose

The intended purpose is the written statement of what the system is for, who uses it and on whom. Classification depends on it, and so does the Article 25 question of whether your use has drifted from what the provider placed on the market. Look for it in product specifications, vendor instructions for use and internal approval documents.

Data provenance

Data provenance evidence shows where training, validation and testing data came from, how it was labelled and cleaned, and what is known about its gaps and biases. Article 10 sets the standard for providers of high-risk systems. Deployers need a narrower record: that the input data they control is relevant and sufficiently representative for the intended purpose.

Testing and validation

Testing and validation evidence is the record of how the system was shown to work: test plans, metrics, results per subgroup, robustness checks and the conditions the tests ran under. Article 15 requires appropriate accuracy, robustness and cybersecurity for high-risk systems. A deployer should hold the provider's declared performance figures and any acceptance testing done on its own data.

Logs and record retention

Logging evidence shows that a high-risk system automatically records events, as Article 12 requires, and that those records are actually kept. Deployers must retain logs for at least six months under Article 26, and providers keep technical documentation for ten years after the system is placed on the market. Check the vendor's default retention window against both. Our guide to document retention for AI systems covers the tension with GDPR data minimisation.

Human oversight

Human oversight evidence names the people who supervise the system and shows they have the competence, training and authority to intervene, as Articles 14 and 26 require. Look for a named role, a written procedure for overriding or stopping the system, training records, and at least one example of an override being recorded in practice.

Monitoring and incident procedures

Monitoring evidence shows that someone watches the system in operation and knows what to do when it misbehaves. Providers need a post-market monitoring plan under Article 72 and a process for reporting serious incidents under Article 73. Deployers need a route to suspend use and inform the provider. A procedure that has never been tested counts as a partial gap.

Vendor documentation

Vendor documentation is the evidence a deployer cannot create for itself: instructions for use under Article 13, the EU declaration of conformity, CE marking status, and contract terms covering log access, change notification and incident cooperation. Ask for it in writing. A vendor that cannot supply it for a high-risk system is itself a finding.

How do you map evidence against the applicable obligations?

Mapping evidence against EU AI Act obligations means building a gap matrix: one row for each obligation that applies to a system, given its role and risk tier, and a column for the evidence found. A provider of a high-risk system has rows for Articles 9 to 15, the quality management system under Article 17, conformity assessment, registration and post-market monitoring. A deployer has rows for each duty in Article 26 and, where it applies, the fundamental rights impact assessment under Article 27. Rate each row on a three-point scale: met, with a reference to the document that proves it; partial, where something exists but is incomplete, outdated or unowned; and missing. Finer scales invite debate about scores instead of fixes. Every partial or missing row gets a one-line description of what would close it. A worked example: Article 26 log retention, rated partial, evidence is a vendor setting of 90 days, closing action is to extend retention to at least six months and confirm the export format.

How do you prioritise gaps by risk and deadline?

Prioritising EU AI Act gaps comes down to three questions for each gap: does the obligation already apply, how severe is the harm if the control fails, and how long does the fix take? Start with anything already in force. The Article 5 prohibitions have applied since 2 February 2025 and the general-purpose AI model rules since 2 August 2025, so a gap there is a present exposure rather than a planning item. For high-risk systems the dates are later: under the Digital Omnibus on AI, Regulation (EU) 2026/1744, Annex III systems apply from 2 December 2027 and AI embedded in Annex I products from 2 August 2028. Those dates are closer than they look for long-lead work. A quality management system, technical documentation to the Annex IV standard and a conformity assessment involving a notified body each take months, so they go to the top of the roadmap even when the deadline seems distant. Quick fixes, such as extending log retention or naming an oversight owner, should be closed immediately whatever their rank.

What should the final gap analysis deliver?

A finished EU AI Act gap analysis should deliver six working documents that your team can act on without the people who wrote them:

• System inventory: every AI system in scope, with owner, vendor, intended purpose and lifecycle stage.
• Role and risk classification: provider or deployer and the risk tier for each system, with the reasoning and the Annex I or Annex III reference where one applies.
• Evidence register: what documentation exists for each system, where it is stored, who owns it and when it was last reviewed.
• Gap matrix: each applicable obligation rated met, partial or missing, with the evidence reference and the closing action.
• Remediation roadmap: the closing actions sequenced by legal deadline, severity and lead time.
• Ownership and deadlines: a named person and a date against every action, agreed with the people named.

An assessment that hands over a summary of the Regulation and a traffic-light slide has skipped the useful part. A fair test of the package: could a new compliance lead pick it up in month two and know what to do on Monday morning?

What can you handle internally and what needs outside help?

Most of an EU AI Act gap analysis can be handled internally, and the parts that need outside help fall into two different kinds: legal and technical. Internal teams are best placed to build the inventory, identify owners, collect existing documents and request vendor paperwork, because they know where things are. Legal counsel is the right source for contested determinations: whether a borderline system falls under Annex III, whether the Article 6(3) exception holds, how contracts allocate provider and deployer duties, and anything involving a regulator. Technical implementation support is a separate need. It covers making the evidence exist: designing logging that can reconstruct a decision, building validation protocols, documenting data lineage and drafting technical documentation to the Annex IV standard. Many companies need both, in sequence, and confusing the two is common. A law firm will not build your logging pipeline, and an engineering partner should not sign off your classification. Where the underlying data and infrastructure are the real obstacle, an AI readiness audit addresses that layer directly.

What does a 30-day starting plan look like?

A 30-day starting plan for an EU AI Act gap analysis is enough to reach a first inventory, a classification for every system and a prioritised gap list, provided one named person owns the work. A sequence that fits most mid-sized organisations:

1. Days 1 to 5: name the owner, agree the scope, and build the inventory from procurement records, the software asset list and a department survey.
2. Days 6 to 12: set the role and risk tier for each system with the reasoning recorded, and send borderline cases to counsel.
3. Days 13 to 22: collect evidence across the seven areas for every high-risk and transparency-tier system. Send vendor documentation requests on day 13, since replies take weeks.
4. Days 23 to 30: fill in the gap matrix, rate each row, assign owners and dates, and present the roadmap to management.

Thirty days will not close the gaps. It will tell you how many there are, which ones matter, and whether 2 December 2027 is comfortable or tight.

What does an EU AI Act evidence checklist look like?

An EU AI Act evidence checklist condenses the gap analysis into questions that can be answered yes, partly or no for each system. Treat every "partly" or "no" on a high-risk system as a row in the gap matrix.

• Is the system in the inventory, with a named business owner?
• Is the provider or deployer role recorded, with the reasoning?
• Have the Article 25 triggers (branding, substantial modification, changed purpose) been checked?
• Is the risk tier recorded, with the Annex I or Annex III reference or the Article 6(3) assessment?
• Is there a written intended purpose, and does actual use match it?
• Is the origin, preparation and known bias of the data documented?
• Are test and validation results on file, including the conditions they were produced under?
• Does the system log events automatically, and are logs retained for at least six months?
• Is technical documentation complete and under version control?
• Is a competent, trained person named for human oversight, with authority to stop the system?
• Is there a monitoring routine and a tested incident procedure?
• Are the vendor's instructions for use, declaration of conformity and CE status on file?
• Do vendor contracts cover log access, change notification and incident cooperation?
• Does every open gap have an owner and a date?

Sector rules add to the list. In healthcare, AI that qualifies as a medical device under the MDR or IVDR brings its own clinical evidence and notified body route. In manufacturing, AI acting as a safety component of machinery follows the Annex I timeline of 2 August 2028.

Frequently asked questions

How long does an EU AI Act gap analysis take?

A first pass of an EU AI Act gap analysis takes about 30 days for an organisation with one owner and a manageable number of systems. Inventory and classification fit in the first two weeks. Evidence collection takes longest, mainly because vendor documentation requests are slow to come back, and large portfolios extend the timeline.

Do we need a gap analysis if we only use AI tools bought from vendors?

Yes. Using a vendor's system makes you a deployer, and deployers of high-risk systems carry their own duties under Article 26: competent human oversight, monitoring, and log retention for at least six months. A gap analysis also checks whether branding or modifying a bought-in tool has made you its provider under Article 25.

Is a gap analysis the same as a conformity assessment?

No. A conformity assessment is the formal procedure under Article 43 that a provider completes before placing a high-risk system on the market. A gap analysis is an internal, preparatory exercise with no legal status of its own. It shows what is missing so that a later conformity assessment, or a customer's due diligence, does not fail.

Does an EU AI Act gap analysis have to be done by a lawyer?

No. Most of the work is operational: building the inventory, collecting documents and checking that logs, oversight and monitoring exist in practice. Legal counsel is needed for contested determinations, such as whether a borderline system falls under Annex III. Technical support is needed where the evidence has to be built.

How often should a gap analysis be repeated?

An EU AI Act gap analysis should be updated whenever a new AI system is introduced, an existing one is substantially modified or its intended purpose changes, since each can alter the role or the risk tier. Beyond those triggers, reviewing the inventory and the gap matrix once a year is a sensible baseline.