EU AI Act Compliance Software: A Buyer's Guide to the Four Categories That Actually Matter

Someone has told you to buy an AI Act compliance tool. You have a budget, a shortlist of vendors who all describe themselves in almost identical language, and no obvious way to tell them apart.

This guide is not a ranking. We do not sell compliance software and we are not going to tell you which product to buy. What we can do is explain the four distinct categories this market contains, what each can genuinely evidence, what none of them can do, and the questions that separate a working product from a well-designed dashboard.

First, check whether the vendor knows what week it is

Start here, because it is the cheapest signal you will get.

Regulation (EU) 2026/1744, the Digital Omnibus on AI, was published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026. Stand-alone Annex III high-risk obligations moved to 2 December 2027; Annex I embedded high-risk to 2 August 2028. Article 50 transparency did not move and applies from 2 August 2026.

A great deal of vendor marketing, RFP boilerplate and "AI Act readiness" content was written against a 2 August 2026 high-risk deadline. Some of it is now selling urgency that no longer exists. When you review a shortlist, check whether the product pages, roadmap and sales deck still count down to the old date. It is a fast proxy for how closely a vendor actually tracks the regulation they claim to automate - and for whether the roadmap you are being sold was built on a since-corrected assumption.

The four categories

The single most useful thing to understand about this market is that it contains four different kinds of product, solving four different problems, frequently sold in language that makes them sound interchangeable. They are not.

1. GRC automation platforms

What they are: compliance-heritage tools - evidence collection, control mapping, policy management, audit trails - that have added an AI Act framework alongside their existing SOC 2 and ISO 27001 engines.

What they evidence well: policy management, control mapping, approval workflow, the paper trail of who reviewed what and when. If you already run one for security compliance, adding the AI Act framework is often the cheapest credible step.

What they cannot do: anything model-specific. A GRC platform cannot test your model, measure its accuracy, or tell you whether it drifted. It records that someone asserted the model was tested.

Who it suits: organisations whose AI Act exposure is mostly governance and documentation rather than deep technical risk.

2. Enterprise AI governance platforms

What they are: purpose-built for AI risk - model inventories, AI risk registers, risk classification workflows, framework mapping, approval chains and audit exports.

What they evidence well: this is the closest category fit for Article 11 and Annex IV technical documentation work and for standing up an Article 17 quality management system. Structured inventory and classification is exactly what these are built for.

What to watch: pricing typically runs in the region of €15,000-€80,000+ per year, implementation is a project rather than a signup, and several vendors store data outside the EU. That last point deserves a direct question - you are buying this tool for an EU compliance purpose, and a cross-border transfer arrangement that creates its own GDPR problem is a poor trade.

Who it suits: organisations with a real Annex III or Annex I high-risk portfolio and the headcount to run the platform.

3. LLM observability and evaluation tooling

What they are: engineering tools - request tracing, evaluation suites, drift and quality monitoring, output logging.

What they evidence well: Article 15 accuracy and robustness evidence, Article 12 automatic logging, and the monitoring substrate an Article 72 post-market monitoring plan needs. This is the only category that generates evidence about the model itself rather than about your process.

What they cannot do: produce a technical file, manage a QMS, or track classification decisions. These are instruments, not filing cabinets.

Who it suits: anyone actually running models in production, largely regardless of tier - and note this budget usually already sits with engineering, not compliance.

4. Runtime control planes and policy enforcement

What they are: inference-time guardrails - output policy, PII filtering, blocking, human-in-the-loop routing.

What they evidence well: Article 14 human oversight design and Article 50 disclosure and output marking. Enforcement at the point of use, with logs proving the control fired.

What they cannot do: documentation. A control plane stops bad outputs; it does not assemble the file explaining why the system is safe.

Who it suits: teams with a live Article 50 deadline on 2 August 2026 and customer-facing generative surfaces.

The central point: most organisations that do this properly end up with coverage across two or three of these categories, or with a knowing, documented gap. The failure is not choosing the wrong category - it is buying one and believing you have bought all four.

Eight capabilities to test in a demo

Paste these into your RFP. For each, one question that distinguishes a real capability from a screenshot.

Capability	The question that exposes it
Model inventory	"Import our actual system list live in this call, including two vendor tools with no API. What happens?"
Data lineage	"For this model, show me which training datasets fed it and where that link comes from - inferred or asserted by a human?"
Risk classification	"Walk me through classifying a system under the Article 6(3) exception. Where is the written assessment stored?"
Framework mapping	"Show the AI Act mapping updated for Regulation (EU) 2026/1744. When did you ship that change?"
Approval workflows	"Show an approval that was rejected, and what the system did next."
Runtime monitoring	"Is this polling a metrics endpoint, or is your agent in the request path?"
Evidence collection	"Show me the export you would hand a notified body, generated from live data - not a sample file."
Audit export	"Regenerate that export for a date six months ago. Does it reproduce exactly?"

The last one matters more than it sounds. Evidence has to be reconstructable as of a point in time, because models change and the question an auditor asks is what you knew and did then.

AI Act-specific diligence questions

Beyond generic software procurement, ask:

• Where is our data hosted, and who can access it? A tool bought for EU regulatory compliance that creates its own transfer exposure is a net negative.
• Does this cover deployer obligations or only provider obligations? Many platforms are built entirely around the provider's Articles 9-17 journey and handle Article 26 deployer duties and the Article 27 FRIA thinly or not at all. If you mostly buy AI rather than build it, this question decides the shortlist.
• Can it produce Annex IV-shaped output? Not "supports technical documentation" - an export whose structure maps to the nine Annex IV sections.
• Does it handle the Article 6(3) record and EU database registration? The Omnibus simplified the Annex VIII information requirements but kept the registration obligation and the requirement to document the assessment before market placement.
• How does it version evidence as models change? Retraining is routine; if evidence silently overwrites, your audit trail has a hole.
• Does it map to ISO/IEC 42001? Certification against 42001 is becoming a market differentiator, and a tool that supports both saves duplicated effort.

When you do not need a tool at all

This section is the one vendors will not write for you.

If your inventory is under roughly ten systems and none of them is high-risk, a spreadsheet plus a well-organised document repository is defensible, auditable and dramatically cheaper. The AI Act does not require you to hold evidence in a platform. It requires you to hold evidence.

More importantly: software does not create compliance. It stores and organises the evidence of work you still have to do. The 2026 readiness report that found 83% of organisations had no formal AI system inventory also found 74% had no designated internal owner for AI compliance. No product fixes either. A governance platform deployed into an organisation where nobody owns AI compliance produces an empty, expensive, well-designed database.

Both figures come from a private survey rather than official EU data, but the pattern is the one every implementation consultant describes: tooling bought to substitute for step one, which is finding out what you actually run.

Buy the tool after the inventory exists, not instead of building it.

A note on lock-in

This market is still forming. Category boundaries move, vendors reposition between the four types described above, and the harmonised standards that will eventually define what good technical documentation looks like are not finished.

Signing a three-year contract now means betting on a product roadmap against a regulation whose implementing detail is still being written - and, as the Omnibus just demonstrated, whose dates can move by sixteen months on six weeks' notice.

Two practical protections: prefer a shorter initial term with a renewal option over a discounted multi-year commitment, and insist on a data portability and exit clause that gets your evidence out in a usable structured format. You may well need to change tools before 2 December 2027, and your evidence has to survive the move.

---

This post is general information about the EU AI Act as at 30 July 2026, not legal advice, and not a product recommendation. Primary sources: the AI Act, Regulation (EU) 2026/1744 and the Commission's AI Act policy page.