EU AI Act conformity assessment hinges on the right path

At a glance

What this is: Openlayer maps EU AI Act conformity assessment for high-risk AI systems and shows that the key decision is whether a system follows internal control or notified body review.

Why it matters: IAM, AI governance, and security teams need the assessment path decided early because it changes evidence collection, oversight design, and the records needed to prove compliance.

Context

Conformity assessment is the EU AI Act process that proves a high-risk AI system meets legal requirements before deployment. The governance gap is not just compliance timing, but the need to select the correct assessment route early enough to build the right documentation, controls, and post-market monitoring evidence.

For most Annex III systems, the issue is internal control versus third-party review, not whether assessment exists at all. That distinction matters for programmes that govern AI used in employment, credit, public services, or critical infrastructure, because the evidence model changes depending on whether the system is self-assessed or reviewed by a notified body.

Key questions

Q: How should teams decide whether an AI system needs internal control or notified body review?

A: Start by classifying the system against the EU AI Act's high-risk categories. Most Annex III systems use internal control, but biometric identification and systems without harmonised standards require notified body review. Decide early, because the assessment path determines the evidence model, scheduling burden, and whether external certification is part of the plan.

Q: Why does choosing the wrong conformity path create compliance risk?

A: Because each path expects different timing and evidence maturity. If teams assume self-assessment when external review is required, they can miss scheduling windows and under-prepare documentation. If they overcorrect and wait for third-party review when internal control applies, they may delay deployment unnecessarily and still fail to build usable monitoring records.

Q: What breaks when technical documentation is incomplete for EU AI Act conformity assessment?

A: Incomplete documentation stalls self-assessment and can fail a notified body review. Regulators expect architecture, data provenance, performance evidence, risk records, and monitoring design to be present before assessment begins. If those artefacts are fragmented across teams, the provider loses both speed and credibility.

Q: Should organisations treat post-market monitoring as part of conformity assessment or as a separate control?

A: Treat it as part of the same control loop. The EU AI Act expects ongoing evidence that the system continues to perform as assessed, so logging, performance tracking, and feedback into risk management must survive deployment. If monitoring sits outside the release process, the organisation loses continuity between approval and operation.

Technical breakdown

Internal control under Annex VI

Internal control is the self-assessment route for most Annex III high-risk AI systems. The provider verifies its quality management system, compiles technical documentation, and registers the system in the EU database before deployment. This path shifts responsibility onto the organisation to prove that risk management, data governance, testing, version control, and post-market monitoring are already operating as designed. The practical boundary is simple: if the system is not in a category reserved for external review, compliance depends on disciplined internal evidence rather than third-party certification.

Practical implication: build the QMS and documentation evidence before deployment, not after the model is live.

When notified body review applies

Notified body review is required for biometric identification systems and for high-risk AI systems where harmonised standards do not yet cover the relevant requirements. In that route, an accredited external body audits both the QMS and the technical documentation, and may request live testing or additional evidence. This is less about adding bureaucracy and more about recognising that some risk classes need independent verification because the regulatory baseline is still moving. The operational challenge is lead time, since scheduling and evidence preparation can stretch into months.

Practical implication: identify early whether biometric use or missing harmonised standards moves the system into third-party territory.

Technical documentation as the compliance spine

Technical documentation is the connective tissue of EU AI Act conformity assessment. It must describe the system, its intended use, training data provenance, design decisions, performance results, known limitations, risk controls, and post-market monitoring plan. Without that evidence, neither self-assessment nor notified body review can be completed credibly. For security and identity teams, the relevance is that governance records have to match actual system behaviour, not just policy intent. That turns documentation into an operational control surface rather than a filing exercise.

Practical implication: treat documentation, test evidence, and monitoring logs as one continuous control set.

NHI Mgmt Group analysis

Path selection is now a governance control, not an administrative detail. The article shows that the real compliance failure mode is choosing the assessment route too late, after documentation and monitoring design are already locked in. That means AI governance teams need the conformity pathway decided at project inception, because the route determines which evidence must exist and who must validate it.

Internal self-assessment will cover more organisations than many expect. Most Annex III systems fall into the internal control procedure, so the main risk is not always external certification delay. The practical problem is whether teams can prove that their quality management system, testing, and post-market monitoring were operating before deployment and not assembled retrospectively.

Conformity evidence debt: the article points to a growing gap between model delivery speed and the evidence needed to defend that delivery under the EU AI Act. Continuous testing, documentation, and monitoring become the only durable way to keep compliance current as models change. For identity and AI governance programmes, this means evidence generation must be built into delivery pipelines, not added as a separate audit project.

Biometric and standard-gap cases deserve a separate control model. These systems do not simply need more documentation, they need a different assurance posture because notified body review introduces external scheduling, additional evidence requests, and longer lead times. Teams governing identity-adjacent AI should treat that as a distinct operating model, especially where biometric identification or safety-critical use cases are involved.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: Ultimate Guide to NHIs — Regulatory and Audit Perspectives

What this signals

Conformity path choice is an evidence architecture decision. Teams that wait to distinguish self-assessment from notified body review usually discover that their QMS, test results, and monitoring logs were built for deployment, not for regulatory proof. The programme should decide the assessment route at the same time it defines the model's operating boundary.

AI governance debt: when documentation is assembled after the system is already live, every subsequent model update increases the cost of proving conformity. That is why continuous testing and monitoring matter as much as the original assessment, especially for systems that affect identity, access, or high-impact decisions.

For practitioners

• Map the assessment route at intake Classify each high-risk AI system against Annex I and Annex III before design decisions harden, so the programme knows whether internal control or notified body review applies.
• Build the QMS before deployment Document risk management, data governance, testing, version control, and post-market monitoring as live controls, not retroactive artefacts.
• Treat technical documentation as evidence engineering Maintain system description, training data provenance, performance results, limitations, and test records as one controlled evidence set.
• Plan for standard gaps and biometric triggers Flag biometric identification and any use case lacking harmonised standards as likely notified body cases, then schedule external review early.
• Embed post-market monitoring into release operations Link incident logging, performance tracking, and feedback loops directly back into the risk register so monitoring survives model updates.

Key takeaways

• The core risk in EU AI Act conformity assessment is not just meeting the deadline, but selecting the wrong review path early enough to derail evidence building.
• Most Annex III systems use internal control, yet biometric and standard-gap cases still require notified body review and longer lead times.
• Continuous documentation, testing, and monitoring turn conformity from a one-time project into an operating discipline.

Key terms

• Conformity assessment: A conformity assessment is the formal process used to show that a high-risk AI system meets the obligations required before it is placed on the market. It combines documentation review, technical verification, and evidence of operational controls, rather than relying on policy statements alone.
• Internal Control Procedure: The self-assessment path used for most Annex III high-risk AI systems. The provider verifies its own quality management system, prepares technical documentation, and registers the system directly, without an external notified body unless the rules require one.
• Notified Body: An accredited third-party organisation recognised by a member state to assess certain high-risk AI systems under the EU AI Act. It reviews evidence, tests, and documentation when self-assessment is not sufficient under the regulation.
• Quality Management System: The set of documented processes that governs how an organisation designs, tests, changes, and monitors a regulated AI system. For conformity purposes, it is not a policy shelf item. It is the control structure that proves the provider can manage the system responsibly.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management for practitioners responsible for access and assurance. It is designed for teams that need identity governance discipline across human and non-human systems.