What AI Act Conformity Assessment Actually Means
An AI Act conformity assessment is the documented process an economic operator uses to demonstrate that an AI system satisfies the requirements applicable to that system before placing it on the EU market, putting it into service, or using it in a way covered by the Regulation. For many AI products, the assessment is performed through a technical file, an EU database registration process, and a declaration of conformity, rather than through a bespoke inspection by a regulator. The assessment can also involve an internal control procedure, examination by a notified body, or another conformity route where the legislation requires or permits it. The applicable route depends on the system’s risk category, its intended purpose, and whether it is being placed on the market as a high-risk system under the Regulation’s product-safety rules. A conformity assessment is therefore not simply an independent AI audit, and it is not a general certificate issued by the European Commission. It is a legally defined compliance chain connecting classification, evidence, testing, documentation, quality management, and the provider’s formal declaration. The AI Act, Regulation (EU) 2024/1689, entered into force on 1 August 2024, and its prohibited-practice and governance rules began applying in stages during 2025 and 2026. As of 23 September 2026, the central compliance question for a provider is whether its specific system falls within a category that requires an assessment and whether the evidence is strong enough to survive regulator or customer scrutiny.
Also worth reading: What are the exact steps for EU AI Act conformity assessment, and how do high-risk systems navigate compliance before the August 2026 deadline? · What are the notified body requirements under the EU AI Act and how do they interact with MDR and IVDR conformity assessment? · How Should Startups Structure a Regulatory Risk Assessment Framework in 2026?
The Main Compliance Routes and Risk Categories
The AI Act uses risk-based categories rather than a single definition of “safe AI.” Prohibited AI practices generally apply from 2 February 2025, while obligations for general-purpose AI models apply from 2 August 2025, subject to the Regulation’s treatment of models already placed on the market. Most obligations attached to Article 6(1) high-risk systems, including product-safety systems covered by the existing EU legislative framework, are scheduled to apply from 2 August 2026. High-risk systems tied to Annex III use cases have a later date of 2 August 2027, although other provisions and product rules can affect earlier application. A system that is not classified as high-risk is not automatically compliant: a provider must still explain the classification, address applicable transparency or general-purpose AI duties, and consider other EU rules such as data protection, consumer protection, product liability, and cybersecurity.
| Feature | Internal control assessment | Notified-body assessment |
|---|---|---|
| Typical use | Some lower-risk or internally controlled compliance routes | Specified high-risk systems requiring third-party involvement |
| Who reviews the evidence | Provider’s own personnel and processes | Provider prepares evidence; accredited body conducts the relevant examination |
| Main output | Technical file, records, applicable declaration and registration | Notified-body assessment or certificate within the route required by EU law |
| Key limitation | Self-assessment does not create general immunity from enforcement | Independent review adds assurance, but costs money and does not transfer legal responsibility |
| When it matters most | Providers need a documented, repeatable route for a system not requiring third-party review | Providers of systems within harmonised legislation or other routes requiring external assessment |
Why the Digital Omnibus Matters in 2026
The compliance timetable has been discussed alongside proposed or enacted amendments under the EU’s Digital Omnibus work programme. Those discussions have included possible changes to timing, documentation, standardisation, and enforcement priorities. Legal references and commentary on the Digital Omnibus must be treated carefully because amendments adopted, published, and transcribed in commentary may not describe the same legal state. The purpose of a conformity assessment does not disappear if a deadline is deferred. Instead, the system classification, technical documentation, data-governance evidence, and post-market controls remain valuable evidence when the obligation becomes applicable.
A frozen or revised deadline should not be treated as permission to ignore the AI Act. A company developing a high-risk system for 2027 may still need to establish a quality management system, define its intended purpose, identify risks, allocate responsibilities, and document testing during 2026. Providers of general-purpose AI models may also face obligations connected to model documentation, copyright policy, and systemic-risk controls before any high-risk application is sold. The Commission’s framework materials and official AI Act service should be checked for the authoritative consolidated text, rather than relying on a news summary. The correct question is not “Has the AI Act been postponed?” but “Which legal text applies to this system, role, and distribution model on the relevant date?” That distinction is particularly important for software vendors selling across several EU member states.
What Providers Must Put in the Technical File
The central practical requirement is evidence that is specific, traceable, and reproducible. A compliance dossier should identify the system version, intended purpose, foreseeable misuse, deployment environment, and the reason for its risk classification. It should describe data sources, data quality controls, relevant assumptions, and how training, validation, and test datasets were selected. A high-risk provider should also be able to explain the risk-management process, accuracy and robustness testing, human-oversight design, cybersecurity measures, logging, user information, and post-market monitoring arrangements. The file should connect each claim to an artefact, such as a test report, model card, change log, incident record, supplier certificate, or controlled procedure.
The provider should not write “the system is accurate” without stating the metric, dataset, population, threshold, and limitations. Where performance depends on language, demographic conditions, geography, or operating conditions, the assessment should show whether the tested scope matches the claimed use. For biometric or other sensitive applications, the legal and technical justification for the system’s design should be recorded, but documentation alone cannot cure a prohibited practice. Human oversight should be more than a disclaimer saying that users can override the output. The dossier should show who can intervene, what information they receive, how quickly they can act, and what happens if the system fails.
Records should be stored in a controlled repository with version history and clear ownership. A provider that changes a model, a data source, a prompt library, or a safety control may need to reassess whether the original conformity evidence remains valid. External components should be identified with supplier documentation and contractual assurances, although outsourcing testing does not remove responsibility for the final product. The evidence should be readable to a competent reviewer rather than deliberately written only for marketing. A well-maintained file also helps a customer answer its own due-diligence questions and prepares the organisation for an EU database registration, a national authority enquiry, or a serious-incident investigation.
How to Choose an Assessment Route
Start with the product’s intended purpose, not with the model’s technical label. A general-purpose model may be integrated into an application that is high-risk, and an application may change classification depending on whether it makes decisions about employment, education, essential services, law enforcement, migration, or another regulated area. Check the AI Act’s definitions and Annex III, then check whether the system is also covered by an existing product-safety framework. If the product falls within more than one regime, identify the relationship between the AI Act and the other legislation instead of assuming that the stricter-looking label settles the analysis. Harmonised standards, common specifications, and guidance can influence the practical route, but they do not replace the underlying legal classification.
| Question to answer | Evidence to retain | Common failure |
|---|---|---|
| Is the system high-risk? | Written classification memo and intended-purpose description | Assuming “generative AI” equals a fixed risk category |
| Is the provider or deployer responsible? | Contract, deployment map, and responsibility matrix | Assigning every duty to a cloud or model supplier |
| Which conformity route applies? | Legal route analysis and applicable standard list | Starting technical work without checking the legislative annex |
| Has performance been tested? | Traceable test results and limitations | Publishing a benchmark unrelated to the actual use case |
| Can the system be monitored? | Logs, complaint process, incident plan, change history | Building a dossier but no post-market process |
Common Mistakes and Weak Compliance Claims
One frequent mistake is confusing a management-system certificate with an AI Act conformity assessment. Certifications for information security, cloud services, or quality management may support a broader compliance programme, but they do not by themselves prove that an AI system meets the AI Act’s specific requirements. Another mistake is treating an “AI audit” as a substitute for the provider’s legal duties. An independent report can be useful evidence, but it does not automatically cover transparency, data governance, human oversight, post-market monitoring, or the provider’s declaration. The same issue arises when a vendor says its system is “compliant” because it uses a model that has been certified; certification of a component does not establish conformity of a changed application or deployment.
A second error is over-relying on templates copied from another jurisdiction. Reports have been criticised for presenting generic questionnaires, unverified vendor claims, and self-attestations as formal conformity evidence. A credible assessment should identify the assessed version, scope, exclusions, test conditions, assessor identity, and date. It should distinguish what was actually tested from what was merely supplied by the client. A third error is assuming that formal approval by an notified body exists for every AI system. The AI Act does not create one universal AI certificate that makes all providers equivalent; the conformity procedure depends on the applicable legislative context and risk classification. Finally, a provider should not assume that a later transition date protects a system already placed on the market. Authorities can examine the date on which the system was made available, and the definition of placing on the market can cover more than a conventional hardware sale.
Costs, Timing, and When to Act
Costs vary widely because a lightweight classification memo, an internal technical file, and a third-party assessment of a complex biometric or safety-related system are different projects. As a rough procurement planning range, a legal and technical gap assessment for a limited commercial system may cost approximately €5,000 to €30,000; a more involved high-risk technical file, testing programme, and quality-management work may run from €30,000 to €150,000 or more; and notified-body work, specialised testing, data collection, and remediation can push a programme above €150,000. These are market estimates, not statutory EU prices. Model documentation, third-party testing, translation, security reviews, and engineering changes can account for much of the total, while a qualified legal adviser may charge separately from a technical assessor.
The timetable should be measured against the actual trigger. A provider should not wait until the final application date if its product has a long integration cycle, because customers may require documentation during procurement. A deployer should ask suppliers for classification information, instructions, relevant performance data, and incident contacts before deployment. A board or product owner should set a review date at least every six months for a fast-changing model and more frequently after a major model, data, or purpose change. Organisations building software agents should also examine whether the agent can take actions that change the risk profile compared with a static recommendation tool. The practical deadline is therefore earlier than the legal deadline when customers, insurers, or national authorities demand evidence before launch.
A Sensible Compliance Decision for 2026
The best route is the one that matches the system and can be maintained after launch. For a low-risk internal tool with no regulated intended purpose, a documented classification decision, privacy review, security controls, and vendor due diligence may be a reasonable starting point. For a high-risk application, the organisation should create a cross-functional conformity plan, define the applicable route, identify gaps, commission independent testing where needed, and maintain a controlled technical file. For a foundation-model provider, model-level documentation and governance should be addressed separately from downstream application assessment, while providers and deployers should agree who handles each obligation. Independent legal or technical support can be useful, particularly where the provider lacks notified-body experience, but brokers and advisers should be selected for demonstrated AI Act work rather than for a generic “compliance” label.
The prudent conclusion is not that every AI system needs an expensive certificate, nor that the Digital Omnibus makes compliance optional. It is that conformity assessment is a product-lifecycle discipline whose requirements depend on classification and role, and whose evidence must remain connected to the actual system. A provider that begins in 2026 can reduce future cost and exposure by documenting purpose, data, performance, oversight, and monitoring now, while verifying the current consolidated law and any adopted amendment before making a formal declaration. That approach is more defensible than a purchased report that says “EU AI Act compliant” without explaining what was assessed.