EU AI Act Compliance Checklist 2026: Gap Assessment Steps and Tools

If your company has any meaningful exposure to the EU market and runs AI systems anywhere in the business, the August 2, 2026 high-risk deadline is now inside the window where preparation, not planning, is what counts. The gap between "we should look at the AI Act" and "we are defensibly in compliance on every high-risk system" is roughly a quarter of focused cross-functional work — and the artifact that turns that quarter into something coherent is a structured gap assessment.

This is the practical checklist most companies are working from in 2026: what to inventory, what to classify, what to document, what to test, and where the tools are good enough versus where they still need to be assembled. It pairs directly with our EU AI Act compliance overview for 2026 — that piece covers the why; this one covers the what and the in-what-order.

Step 1 — Build the AI inventory before doing anything else

The single most common failure mode in 2026 AI Act programs is starting compliance work on the systems someone in legal already knew about, while ignoring the AI features quietly enabled inside the SaaS stack. The first artifact every program needs is a complete inventory — and "complete" is a higher bar than it sounds.

• In-house models and agents. Anything trained, fine-tuned, or operated by the company directly. This is the easiest category to find and usually the smallest in count.
• Embedded AI features inside SaaS tools. The CRM scoring lead quality. The ATS screening résumés. The customer-support tool routing tickets. The contract-review tool flagging risky clauses. These are the inventory items most often missed and most often regulated.
• Internally built agents and assistants. The chatbot HR built on top of OpenAI to answer policy questions. The Slack bot finance built to summarize expense reports. These count and they need entries.
• Customer-facing AI. Any model surfaced to a user — recommendation engines, support bots, generation tools, search ranking. Whether built or bought, it goes in.

The minimum viable inventory has, for each system: a name, the use case in one sentence, the data inputs, the data outputs, the affected population (employees, candidates, customers, the public), the system owner inside the company, and the vendor relationship if any. That schema is enough to drive classification and is the spine of everything that follows.

Step 2 — Classify each system against Annex III

Classification is the step that consumes the most legal attention and produces the most argument. The honest stance is to over-classify first and de-scope second. Annex III enumerates the high-risk categories — employment and worker management, credit scoring and creditworthiness assessment, insurance underwriting and pricing for life and health, critical infrastructure, education and vocational training access, biometric identification, law enforcement, migration and asylum, and administration of justice. Anything touching these lines starts as high-risk in the spreadsheet; the legal team then earns the right to argue it down with documented reasoning.

The classification rationale matters as much as the classification itself. Auditors in 2027 will not ask companies to prove that their high-risk systems are compliant — they will ask companies to prove they correctly identified what was not high-risk. Every "not high-risk" entry needs a one-paragraph defense.

Step 3 — The six compliance artifacts for each high-risk system

For every system that ends up classified as high-risk, the AI Act requires a defined set of artifacts. The compliance program is, structurally, the work of producing and maintaining these six things:

1. Risk-management system. A documented process — not a policy — covering hazard identification, risk evaluation, mitigation measures, and residual-risk acceptance. Tied to lifecycle stages: design, training, validation, deployment, monitoring. Should be a living document with quarterly review cadence.
2. Data and data governance documentation. Provenance of training, validation, and testing datasets. Known representativeness gaps. Bias-mitigation steps. For vendor-provided models, this is mostly a paper-extraction exercise; for in-house models, it is a writing exercise. Both take longer than expected.
3. Technical documentation. A structured file describing the system, its components, its development process, and its testing. Modeled on the CE-marking technical file and as dense.
4. Logging and traceability. System operations have to be logged in a way that allows post-market monitoring and incident reconstruction. This is the artifact most often missing on day one and the one with the longest engineering lead time — instrumentation is a multi-sprint retrofit on most systems.
5. Human-oversight design. A documented oversight layer with the authority to override or pause the system. For credit decisioning, this is the underwriter veto. For hiring screens, the recruiter override. Designed, not promised.
6. Accuracy, robustness, and cybersecurity evidence. Quantitative testing covering normal operation, edge cases, adversarial inputs, and the surrounding security posture. Overlaps with model-risk-management programs in financial services; from scratch in less-regulated sectors.

Step 4 — Vendor due diligence and contract re-papering

The harshest realization in most 2026 compliance programs is that vendor contracts signed before the AI Act do not extract the documentation the deployer now needs. The procurement workstream is not optional — it is the second-largest line item after engineering.

Practical questions to take to every AI vendor: provide the technical documentation for the system; specify whether the system is classified as high-risk and on what grounds; commit to incident-reporting cooperation within the 15-day window; clarify what happens to prompts and outputs (do they enter training pipelines?); identify EU representation if the vendor is non-EU; and disclose any sub-processors. The answers — or the silences — drive whether the vendor stays in scope. Companies that ran AI compliance automation programs already have most of this scaffolding; everyone else builds it now.

Step 5 — Post-market monitoring and incident response

The August 2026 date is not the finish line. It is the date at which the post-market clock starts running. Companies need, before that date: a defined incident definition, a 15-day reporting process to the supervisory authority, performance dashboards reviewed at a documented cadence, and a feedback loop into the risk-management system.

The reporting clock is short by design. Companies without a pre-built process will miss the first deadline they encounter, and the second incident will be the regulatory event. The fix is operational: a tabletop exercise in Q3 2026 that simulates a serious incident and walks the team through every step from detection to filing. The companies that have done this discover the gaps; the ones that have not discover them in production.

Step 6 — Tooling: what is good enough in 2026

The AI Act compliance tooling market is young. Most platforms are either re-skinned GRC tools or thin wrappers around model-evaluation suites. The practical 2026 stack tends to assemble from pieces:

• Inventory and classification: a structured database (often a Notion or Airtable spine in the early stages, migrated to a GRC platform once the count gets above forty entries).
• Documentation: markdown or Confluence-style living documents tied to system records. Templates exist; bespoke writing is unavoidable.
• Logging and telemetry: existing observability stack (Datadog, Grafana, OpenTelemetry) extended with model-specific metrics. New tooling rarely required.
• Bias and robustness testing: open-source libraries (Fairlearn, Aequitas, Foolbox) or commercial alternatives. Quality varies; methodology matters more than tool brand.
• Incident management: existing IR processes adapted with AI-specific triggers and a separate reporting channel for supervisory authorities.

What does not yet exist as a buyable product: an integrated platform that covers inventory through post-market monitoring with EU-specific defaults. Companies that wait for one will miss the deadline; companies that assemble from pieces hit it.

Step 7 — Sequence and owners

A program that lands on time has the following sequence: inventory and classification in May–June 2026, the six artifacts in parallel sprints across June–July, vendor re-papering across June–August, post-market monitoring infrastructure in July, and a tabletop exercise in late July. An internal owner — typically titled head of AI governance, reporting to the chief legal or chief risk officer — is named on day one with budget and authority that matches the obligation. The companies without a named owner by June 2026 will not finish.

The gap assessment is not a deliverable — it is the operating model for the next quarter. Companies that treat it as a one-time exercise produce a document; companies that treat it as a quarterly cadence produce defensible compliance.

For organizations standing this up now, the part that benefits most from an outside operator is the early scaffolding — turning a vague "we should look at the AI Act" into a concrete inventory and classification with documented rationale by the end of June. Our AI compliance and risk automation work is structured around exactly this: building the inventory, running the Annex III classification, drafting the artifact templates, and instrumenting the post-market monitoring so the legal team has something operational to audit rather than an ambition to defend.