How should teams choose between self-assessment and notified body review for high-risk AI systems?

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 lacking harmonized standards require notified body review. Make the decision before implementation so documentation, scheduling, and approval paths match the actual obligation.

Why This Matters for Security Teams

Choosing the wrong assurance path is not a paperwork issue. Under the EU AI Act, the choice between internal control and notified body review affects design gates, evidence collection, launch timing, and who can sign off on residual risk. For teams running model development, MLOps, or procurement, the classification decision also determines whether governance can stay inside the business or must include an external conformity assessment.

That matters because high-risk AI systems often span multiple owners: product, legal, security, data science, and compliance. If the review path is decided late, documentation gaps tend to appear after model validation is already complete, which makes remediation expensive and can force deployment delays. Current guidance suggests aligning the assurance route with the risk classification at the earliest architecture stage, not after a release candidate is already ready for approval. The NIST Cybersecurity Framework 2.0 is useful here because it reinforces governance, risk ownership, and control traceability even though it is not specific to the EU AI Act.

In practice, many security teams encounter the need for external review only after a delivery timetable has already been committed and the evidence trail is too thin to satisfy the chosen route.

How It Works in Practice

The operational sequence is straightforward, but the evidence burden is not. First, classify the AI system against the EU AI Act high-risk categories and confirm whether the use case falls under Annex III or another regulated path. Then check whether the system can be covered by internal control using the Act’s requirements and any applicable harmonized standards. Where harmonized standards or common specifications are available and the category permits it, self-assessment is typically the default. Where they are absent, or where the system involves certain biometric identification use cases, notified body involvement becomes more likely.

Teams should treat this as a control design exercise, not a legal afterthought. A practical workflow usually includes:

• Documenting the exact use case, data sources, intended purpose, and human oversight model.
• Mapping each requirement to a named owner, test artifact, and approval record.
• Recording why internal control is sufficient, or why notified body review is required.
• Aligning model governance, cybersecurity, and privacy evidence so the same package supports multiple review steps.

For evidence quality, the AI risk conversation should be tied to lifecycle controls such as logging, versioning, change management, and post-deployment monitoring. NIST’s AI governance guidance in the NIST Cybersecurity Framework 2.0 helps teams structure that traceability, while the NIST Cybersecurity Framework 2.0 also provides a practical model for assigning risk ownership across functions. The point is not to turn cyber controls into AI compliance, but to ensure the AI assurance path has verifiable operational support.

These controls tend to break down when AI systems are built from shared components across jurisdictions because the final product owner cannot easily prove which obligations were inherited, which were adapted, and which remained unresolved.

Common Variations and Edge Cases

Tighter external review often increases cost and launch friction, requiring organisations to balance regulatory certainty against delivery speed. That tradeoff is especially visible when a system sits close to a high-risk boundary but is not an obvious fit for a single category.

One common edge case is a product that uses a foundation model inside a higher-risk workflow. The model itself may not force notified body review, but the combined system can still inherit high-risk obligations depending on its intended purpose and deployment context. Another is vendor-provided AI: procurement teams may assume the supplier has already solved conformity assessment, but responsibility usually remains with the deploying organisation for the final use case and configuration. There is no universal standard for this yet in industry practice, so teams should rely on the legal category and the system’s actual function, not marketing labels.

Biometric identification deserves special caution because regulatory triggers can differ from other Annex III use cases. Similarly, if a harmonized standard is not yet available or does not adequately cover the system’s design, internal control may no longer be enough. In that case, the safest operational approach is to build the evidence pack as if external review will be required, even before the final decision is confirmed. That keeps documentation, test results, and risk acceptance ready for escalation rather than rebuilt under deadline pressure.

For teams managing related security obligations, the NIST Cybersecurity Framework 2.0 remains a useful anchor for governance and assurance discipline, even though the EU AI Act determines the formal route. The practical failure mode is usually not misunderstanding the rule in theory, but assuming a self-assessment path will remain available after the system’s final scope has been defined.

Related resources from NHI Mgmt Group

• Which control should teams prioritise first for high-risk AI systems: logging or documentation?
• How should security teams limit the risk from AI agents that have access to production systems?
• How should security teams reduce indirect prompt injection risk in AI systems?
• How should security teams choose between managed and self-hosted CIAM?