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.
How the assessment path is decided
The decision point is less about the model itself and more about the regulatory pathway it falls into. For an AI system, that starts with whether it is high risk, because the EU AI Act treats conformity assessment differently depending on the category. If the system sits in Annex III, internal control is often enough; if it falls into a biometric category or lacks harmonised standards, the assessment burden changes materially.
That distinction matters because the chosen path determines who can sign off, what evidence must be assembled, and whether the programme needs to budget for an external review cycle. Teams should treat the assessment route as part of the deployment design, not as a final compliance cleanup step.
For organisations mapping an AI system to the regulatory route, the most useful anchor is the EU AI Act itself, which defines the high-risk structure and the conditions that push some systems beyond self-assessment. The European Commission’s EU AI Act regulatory framework is the most direct reference point for the classification logic behind that decision.
When internal control is usually enough
Most Annex III high-risk systems are designed to proceed through internal control, which is effectively a documented self-assessment against the Act’s requirements. That is not a lighter-duty shortcut, it is a formal route that still expects traceability around data governance, technical documentation, human oversight, logging, and post-market monitoring. In practice, the organisation must be able to show why the system fits the category and how the required controls are implemented.
Internal control works best when the provider can produce consistent evidence from the design and development lifecycle, and when the compliance case does not depend on an unsettled interpretation of the technical standard. Teams should assume that the internal route is only credible if engineering, product, legal, and assurance stakeholders can all review the same evidence set without gaps.
The operative question is whether the system can be assessed against the applicable requirements with internal evidence alone. When that answer is yes, the main effort becomes disciplined documentation rather than third-party certification.
When notified body review becomes the safer route
Some systems require external review because the regulation expects more independent assurance than the provider can supply alone. Biometric identification sits in that more sensitive lane, and systems that must comply without harmonised standards can also trigger notified body involvement. In those cases, the issue is not just compliance coverage, but whether an outside assessor must validate that the conformity path is appropriate and complete.
This is where teams need to understand the practical effect of a notified body early. External review can change the project timeline, evidence format, procurement assumptions, and release gating. If that path is discovered late, the organisation can end up redesigning the assurance process after the model, controls, and launch plan are already fixed.
When the category or standards status is uncertain, the prudent move is to assume the stricter assessment pathway until the classification is resolved. That avoids building a self-assessment process around a system that later turns out to need independent review.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST AI RMF and NIST SP 800-53 Rev 5 set the technical controls, while EU AI Act, ISO/IEC 42001:2023 and GDPR define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| EU AI Act | High-risk AI system conformity assessment | Directly governs whether the AI system uses internal control or notified body review. |
| Recommendation — Classify the system early and follow the conformity assessment route required by its risk category. | ||
| ISO/IEC 42001:2023 | 4.1 — Understanding the organization and its context | Supports deciding AI governance obligations from the system's intended use and regulatory context. |
| Recommendation — Define the AI system context and governance obligations before selecting the assurance path. | ||
| NIST AI RMF | GOVERN — GOVERN | Supports setting oversight, accountability and review decisions for AI risk management. |
| Recommendation — Establish oversight responsibilities and review criteria before deployment decisions are finalized. | ||
| NIST SP 800-53 Rev 5 | CA-2 — Security Assessments | Supports assessment evidence and periodic review needed for compliance decisions. |
| Recommendation — Use documented assessments to support the selected assurance path and its evidence base. | ||
| GDPR | 35 — Data Protection Impact Assessment | Relevant when biometric or other personal-data processing requires formal risk review. |
| Recommendation — Perform the required impact assessment when the AI system processes regulated personal data. | ||
Practitioner Guidance
What to verify: Confirm the exact AI Act classification before the governance plan is frozen. The key check is whether the system is an Annex III case that can rely on internal control, or whether biometric identification or missing harmonised standards push it into external review.
Decision rule: If the classification is clear and the evidence can be fully assembled internally, design for internal control. If the category is ambiguous, standards coverage is incomplete, or biometric identification is involved, budget for notified body review rather than assuming self-assessment will survive scrutiny.
What to measure: Track whether the team can produce a complete conformity file without forcing last-minute evidence gaps, because that is usually the earliest sign that the chosen route is wrong or under-scoped.
Practitioner takeaway: The important decision is not which review method is preferred, but which one the system’s classification legally requires, because the wrong assumption changes both compliance risk and launch timing.
Related resources from NHI Mgmt Group
- How should teams decide whether an AI control plane needs to be Kubernetes-native?
- How should teams decide whether an AI control plane needs to stay self-hosted?
- How do IAM teams decide whether an AI use case needs new controls or better NHI hygiene?
- How do teams decide whether an AI agent needs human approval?