EU AI Act Compliance Software: A Buyer's Guide for 2027
Buyer guide to EU AI Act compliance software: Article 6 classification, Art 9 risk register, Art 11 docs, Art 43 conformity. Deadline 2 Dec 2027.
You have until 2 December 2027 to satisfy the high-risk AI obligations under Regulation (EU) 2024/1689 — that deadline applies to stand-alone Annex III systems under the Digital Omnibus agreed in May 2026. If your AI touches recruitment, credit scoring, biometrics, or any of the other eight Annex III categories, you need an Article 9 risk management system, Article 11 technical documentation, and an Article 43 conformity assessment. The question is not whether to use software — it is which software actually covers the ground.
This guide is a buying framework, not a ranked leaderboard: what the Act requires, the tool categories available, the dimensions that matter, and a selection checklist.
What EU AI Act Compliance Software Actually Needs to Do
The Act imposes obligations in layers. Your software needs to cover each layer that applies to your organisation's role and risk tier. Here is what that looks like in practice.
Article 5 Prohibited-Practice Screen
Before anything else, a system must be checked against the Article 5 prohibitions — subliminal manipulation, social scoring, untargeted facial scraping, real-time remote biometric identification in public spaces for law enforcement, sensitive biometric categorisation, and emotion recognition in workplace or educational settings. These have been in force since 2 February 2025; the fine ceiling is €35,000,000 or 7% of worldwide annual turnover (Article 99(3)). Any tool worth buying screens for Article 5 first, before routing to the high-risk workflow.
Article 6 and Annex III Classification
Article 6 determines whether a system is high-risk. Two routes: (1) safety components in Annex I regulated products — deadline 2 August 2028; or (2) systems listed in Annex III (biometrics, critical infrastructure, education, employment, access to essential services including creditworthiness and health/life insurance, law enforcement, migration, administration of justice).
The Article 6(3) filter matters: a system in an Annex III area is not high-risk if it poses no significant risk of harm — for example, a narrow procedural task or preparatory work. Only one of the four conditions needs to be met, but providers claiming it must document the assessment and still register under Article 49. Software that labels every Annex III use case as high-risk will over-scope your obligations.
Classification output should be explicit: Unacceptable / High / Limited / Minimal — not a proprietary score that obscures the regulatory basis.
Article 9 Risk Management System
High-risk providers must maintain a continuous risk management system — not a one-time assessment. Article 9 requires identification and analysis of known and foreseeable risks, estimation of misuse risks, evaluation against post-market data, and adoption of suitable mitigation measures. The risk register is the operational form of this obligation.
Article 11 / Annex IV Technical Documentation
Annex IV lists nine areas: general system description; development process; monitoring and control; risk management; data governance; lifecycle changes; transparency and instructions for use; human oversight measures; accuracy, robustness, and cybersecurity. This is a structured technical file, not a single document — it must survive an audit by a national market surveillance authority. Software that generates a PDF summary is not the same as software that builds and version-controls the structured file.
Article 27 Fundamental Rights Impact Assessment (FRIA)
The FRIA is a deployer obligation. It applies to public bodies deploying high-risk AI systems, and to deployers of creditworthiness (Annex III point 5(b)) and life/health insurance (Annex III point 5(c)) systems. Article 27(4) allows the FRIA to build on an existing GDPR DPIA (GDPR Article 35) — distinct obligations that can share infrastructure. Do not assume every employer deploying recruitment AI owes a FRIA; the obligation is narrower than many guides claim.
Article 43 Conformity Assessment and Article 47 Declaration of Conformity
Article 43 is the EU's mechanism for demonstrating, before a high-risk system goes to market, that it meets Articles 9–15. Most Annex III categories use Annex VI internal self-assessment — no notified body required. The exception is Annex III point 1 (biometrics), which generally requires the Annex VII notified-body route where harmonised standards are not applied.
The output of the conformity assessment is the Article 47 / Annex V Declaration of Conformity, which must be retained for ten years (Article 18). Software must generate this document and link it to the underlying evidence file — a conformity assessment is not just a workflow, it is a signed declaration.
Article 49 Registration
High-risk AI systems must be registered in the EU database (established under Article 71) before market placement — Article 49 governs the duty. Registration data includes provider identity, system description, intended purpose, risk classification, and conformity assessment status. Software should track registration data requirements and flag when they are ready for submission.
Article 72 Post-Market Monitoring and Article 73 Incident Reporting
Article 72 requires providers to establish and maintain a post-market monitoring system, collecting and reviewing data from deployed high-risk AI systems throughout their lifetime. Article 73 governs serious-incident reporting: no later than 15 days from awareness (2 days for widespread infringement or critical-infrastructure disruption; 10 days where a death has occurred). Deployers flag incidents to providers under Article 26; providers report to market surveillance authorities under Article 73.
Software that covers pre-deployment but stops at go-live is incomplete. The monitoring and incident workflows are post-go-live obligations that run for the system's entire operational life.
Audit Trail
The Act does not label "audit trail" as a standalone obligation, but it runs through multiple provisions: Article 12 (automatic logging by high-risk systems), Article 17 (QMS records), and Article 18 (technical documentation retention for ten years). An immutable, timestamped log of what was assessed, by whom, and when is the practical evidence base for any enforcement interaction.
Buyer-Fit Dimensions: What to Evaluate
Self-Serve vs Enterprise Implementation
Some tools are designed for self-serve use — plain-language intake forms, no consultants, credit-card checkout. Others target enterprise clients: six-to-twelve-month implementations, dedicated customer-success teams, custom pricing. Neither model is inherently better — the right choice depends on your organisation's size, technical capability, and urgency.
A 30-person HR-tech company with one high-risk recruitment system does not need an enterprise implementation. A regulated financial institution with forty AI deployments across multiple jurisdictions may genuinely benefit from enterprise tooling that integrates with existing GRC infrastructure. The mismatch risk cuts both ways: over-specifying wastes budget; under-specifying leaves obligation gaps.
EU Hosting and Data Residency
The Act's documentation requirements mean sensitive technical information — training data descriptions, model architecture, known failure modes, risk assessments — lives inside the compliance tool. For companies subject to GDPR, data residency is not a preference. Verify EU/EEA hosting, which legal entity signs the DPA, and which sub-processors handle infrastructure.
Multi-Framework Cross-Mapping
Many companies already operate under ISO/IEC 42001, NIST AI RMF, or GDPR obligations. A tool that cross-maps Article 9 risk management to ISO 42001 Annex A controls, or links Article 10 data governance to GDPR Article 30 records of processing, reduces duplication and makes a coherent case to auditors. ISO/IEC 42001 certification is voluntary — it supports the Article 17 quality management system but does not substitute for the Article 43 conformity assessment. Cross-mapping is a workflow efficiency, not a compliance shortcut.
Deterministic vs LLM-Generated Outputs
Two approaches exist. Deterministic, rule-based engines produce the same classification output from the same intake, every time. The rule that fired is human-readable, the output is reproducible — essential when an auditor asks why a system was classified high-risk. LLM-based outputs can draft documentation faster, but outputs may vary run-to-run, are harder to trace to a specific regulatory basis, and carry hallucination risk.
Ask any vendor: "If I run the same intake twice, do I get the same classification?" If the answer is "it depends," factor that into the audit-defensibility of the documentation it produces.
Price and Time-to-Value
At the self-serve end of the market, annual pricing starts in the low hundreds to low thousands of euros. Enterprise tools are contract-priced. The more important question than the annual fee is time-to-value: how long from signup to a completed classification, a first technical documentation draft, and a working risk register?
For companies facing the December 2027 deadline, implementation time is not a minor variable. A tool that takes six months to configure eats a meaningful fraction of the available runway.
Categories of Tooling and Their Trade-offs
Dedicated EU AI Act / AI Governance Tools
Purpose-built tools offer article-mapped workflows, AI inventory management, and structured documentation generation. Variation within the category is wide: some are EU-native and self-serve; others are US-headquartered with EU coverage added later; some focus on providers, others on deployers. The risk is picking a vendor whose roadmap diverges from where enforcement actually lands.
Broad GRC / Governance Suites
Established GRC vendors have added EU AI Act modules. The appeal is consolidation — one system for GDPR, ISO 27001, SOC 2, and the AI Act. The trade-off: the AI Act module is often shallower than a dedicated tool, adequate for the Article 9 risk register but thin on Article 11 / Annex IV documentation generation or the Article 27 FRIA. Verify which specific deliverables the module produces, not just which articles it mentions.
Point Tools and Manual Workflows
Spreadsheet-based AI registries and manually assembled technical files cost less upfront but do not scale. A spreadsheet provides no audit trail, no immutable logging, and no workflow enforcement. For a company building toward a conformity assessment, a manual approach requires complete reconstruction into a structured format before submission.
Legal and Consulting Services
Law firms and consultancies can advise on classification edge cases and review conformity declarations before they are signed. They are not a substitute for tooling — they cannot maintain a continuous risk management system or keep a real-time audit log. The practical combination is a self-serve or light-enterprise software tool for ongoing operational obligations, with legal counsel brought in for targeted review of the conformity declaration and registration data.
How Confir Fits This Landscape
Confir is a rule-based EU AI Act compliance tool for compliance, legal, and IT teams at smaller companies. Its classification engine is deterministic: Article 5 prohibited-practice screen, then Article 6 / Annex III classification with the Article 6(3) filter, then role derivation (Provider Article 16 / Deployer Article 26 / Importer Article 23 / Distributor Article 24). The same intake always produces the same output.
Coverage spans the full obligation stack: Article 9 risk management system and risk register, Article 11 / Annex IV technical documentation pack, Article 27 FRIA for qualifying deployers, Article 43 conformity assessment support, Article 47 / Annex V Declaration of Conformity, Article 49 registration data, Article 72 post-market monitoring and Article 73 incident-reporting workflows, and an immutable audit log. Cross-maps to ISO/IEC 42001 and NIST AI RMF. EU-hosted, self-serve, from €600/year.
Selection Checklist
Use this before you commit to any tool.
Obligation coverage
- Does it screen Article 5 prohibited practices before routing to Article 6 classification?
- Does it surface the Article 6(3) exemption filter and document the assessment?
- Does it generate a structured Article 11 / Annex IV technical file — not just a summary?
- Does it produce the Article 47 / Annex V Declaration of Conformity?
- Does it support the Article 27 FRIA for deployers of creditworthiness and life/health-insurance AI?
- Does it maintain an Article 9 risk register and cover Article 72 / Article 73 monitoring and incident timelines?
- Does it maintain an immutable audit log?
Technical and operational
- Same intake = same output? (deterministic vs AI-generated)
- EU/EEA data hosting? Whose DPA do you sign?
- How long from signup to a first completed compliance record?
- Does it handle multiple AI systems in one account?
- How quickly does the tool reflect updated regulatory guidance?
Commercial and fit
- Is the implementation model right for your team size?
- What are total costs including implementation, training, and annual licence?
- Does it cross-map to ISO/IEC 42001, NIST AI RMF, or GDPR if you need that?
If a tool cannot answer the obligation-coverage questions with specific article references rather than vague capability claims, it is not ready to be your compliance system of record.
Frequently Asked Questions
What is the difference between a compliance tool and a compliance consultant for EU AI Act purposes?
Tools maintain operational obligations continuously — the Article 9 risk register, the Article 11 technical file, the audit log, the post-market monitoring. Consultants provide legal judgment on edge cases: whether a specific use case triggers Annex III classification, whether the Article 6(3) exemption applies, whether your conformity declaration will withstand scrutiny. Most organisations need both. A company with a clear-cut high-risk deployment can run the program with self-serve tooling and bring counsel in for a targeted review of the conformity declaration before it is signed.
The source says "Annex II" — is that the same as the high-risk use-case list?
No. The EU AI Act uses Annex III for the list of high-risk AI use cases (eight areas, including biometrics, employment, credit scoring, and law enforcement). Annex II lists harmonised EU legislation for products where AI used as a safety component triggers high-risk classification under Article 6(1) — machinery, medical devices, rail, and similar. Any guide or tool that cites "Annex II" for the high-risk use-case list has an error. The correct reference is always Annex III.
Does my compliance tool need to cover both the provider and deployer obligation sets?
It should. Many SaaS companies are providers — they ship AI under their own brand — but also deployers of third-party AI tools internally. The obligation sets differ: providers carry the full Article 9–15 stack plus Article 43 conformity; deployers carry Article 26 duties (oversight, monitoring, 6-month log retention) and, in some cases, the Article 27 FRIA. A tool that handles only one role leaves gaps.
How does deterministic output matter in practice for an audit?
A national market surveillance authority examining your conformity declaration will want to understand how the risk classification was reached. A deterministic, rule-based engine produces a traceable finding: "high-risk under Article 6 / Annex III point 4(a) because it screens job applicants." A finding generated by a language model may vary by phrasing, may not cite the specific regulatory basis, and cannot be reproduced identically — making it harder to defend. Audit-defensibility is the whole point of building the documentation file.
What does the December 2027 deadline actually mean for my implementation plan?
Under the Digital Omnibus agreed in May 2026, stand-alone Annex III high-risk systems must comply by 2 December 2027; Annex I safety-component systems have until 2 August 2028. "Comply by" means the full Article 9–15 obligation stack is satisfied, the Article 43 conformity assessment is complete, the Article 47 Declaration of Conformity is signed, and the system is registered under Article 49. Assembling that documentation typically takes four to twelve months — starting a software evaluation now is the right pace.
Can ISO/IEC 42001 certification satisfy the Article 43 conformity assessment?
No. ISO/IEC 42001 certification is voluntary and supports the Article 17 quality management system and the Article 9 risk management evidence. It contributes to the technical file and may simplify the Annex VI internal self-assessment. It does not substitute for the Article 43 conformity assessment. A tool claiming ISO 42001 "satisfies Article 43" is incorrect.
Which AI systems most often trigger the high-risk stack for a software company?
Any system that screens or ranks job applicants (Annex III point 4(a)), influences creditworthiness decisions (point 5(b)), assists in health or life insurance pricing (point 5(c)), or processes biometric data for identification (point 1) is almost certainly high-risk. Customer-facing chatbots and internal productivity tools are generally minimal-risk or limited-risk (Article 50 disclosure duties apply). Classification must be done system by system — "we don't do high-risk AI" is not defensible without documented assessments.
Related guides
- EU AI Act compliance requirements for smaller companies
- AI system inventory management tools
- Article 17 quality management requirements
- AI governance software comparison
- EU AI Act compliance requirements
- AI risk classification levels
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 →