The Notified Body Process the AI Act Won't Spell Out
- Leverage ISO 42001: You can reuse approximately 60% of your existing ISO/IEC 42001 evidence to satisfy Annex IV documentation requirements, drastically reducing duplication.
- Operations over Policies: Auditors prioritize live Article 12 logging and Article 72 post-market monitoring loops over static compliance manuals.
- Notified Body Bottlenecks: Identify early if you need third-party assessment; the queue for accredited notified bodies is already creating a 90-day delay trap.
- Continuous Artifacts: The technical documentation file is a living entity. Auditors specifically target your version-control history and modification logs.
Major consultancies want a twelve-month retainer to prepare you for the EU AI Act. You can skip the consultant. By focusing on operational telemetry instead of endless policy drafting, you can cut your compliance runway almost in half.
As enterprise PMOs race to complete their EU AI Act August 2026 enforcement deadline checklist, the priority must shift from theory to demonstrable, audit-ready engineering.
Market surveillance authorities will not be satisfied with PDF policies; they will demand to see your live logging, data governance, and risk management systems in motion.
If you want to know how to navigate the EU AI Act conformity assessment notified body process without burning your entire IT budget, you need a precise, technical roadmap. Here is the 11-step playbook designed to cut audit prep time by 45%.
Phase 1: Baselining and System Identification
You cannot secure what you cannot see. The first phase of audit prep requires ruthless visibility across all global departments, rooting out unmanaged algorithms.
Step 1: Execute a Shadow AI Discovery Sweep
Central IT must map every AI system deployed across the enterprise, including those procured on departmental credit cards. Document this as an AI Bill of Materials (AI-BOM). Classify each system according to Article 6 and Annex III.
Step 2: Run the Article 6(3) Derogation Analysis
If a system falls under Annex III but performs a narrow procedural task without posing significant harm, you can attempt an Article 6(3) derogation. You must formally document the rationale and register this derogated status in the EU database immediately.
Phase 2: Building the Operational Controls
This phase separates the compliant enterprises from the penalized ones. You must build these controls directly into your Software Development Life Cycle (SDLC), treating them as core product requirements.
Step 3: Establish the Article 9 Risk Management System
This must be an iterative, continuous process. Document your methodology for identifying foreseeable risks to health, safety, and fundamental rights. Ensure your risk register is directly linked to your mitigation engineering tickets.
Step 4: Execute Article 10 Data Governance
Auditors will heavily scrutinize your training, validation, and test datasets. You must maintain hard evidence of dataset representativeness, quality controls, and aggressive bias examination protocols.
For multinationals utilizing offshore engineering hubs to process this data, aligning these controls with local privacy laws is non-negotiable. Ensure your teams integrate the structural privacy controls detailed in the DPDP Act AI Compliance Guide India.
Step 5: Implement Article 12 Logging
Your system must automatically record events relevant to identifying national-level risks and substantial modifications. Set log retention minimums to six months, scaling up for critical infrastructure systems.
Step 6: Operationalize Article 14 Human Oversight
Human-in-the-loop (HITL) must be a tangible product feature. Document the specific UI/UX mechanisms that allow human operators to override the AI's output, and ensure every override action is logged.
Phase 3: The Documentation and Conformity Stack
With the operational telemetry actively running, you can now compile the regulatory artifacts required to pass a formal market surveillance inspection.
Step 7: Map ISO 42001 Evidence (The 45% Shortcut)
Do not build your documentation from zero. Map your existing ISO/IEC 42001 artifacts directly to the AI Act requirements. This effectively covers roughly 60% of the baseline, allowing you to focus bespoke engineering efforts solely on the gaps.
Step 8: Build the Annex IV Technical Documentation
Compile the Article 11 technical documentation file strictly following the nine-section structure mandated by Annex IV. Establish strict version control; auditors will immediately request the change-log tracing material modifications.
Step 9: Stand Up Article 72 Post-Market Monitoring
Treat this as a live Site Reliability Engineering (SRE) workload. Build a continuous observability loop with documented, automated triggers that detect performance drift, model degradation, or adverse safety incidents.
Step 10: Run the Conformity Assessment
Determine your assessment path. Most systems qualify for self-assessment (Annex VI). If you deploy biometrics or Annex I embedded systems, you must immediately secure a third-party audit.
Learn how to navigate the notified body process early; failing to get into an accredited auditor's queue on time is a massive operational risk that halts deployments.
Step 11: Register in the EU AI Database and Affix CE Marking
Once conformity is proven, draft and sign the Article 47 EU Declaration of Conformity. Affix the CE marking to the system and complete your mandatory registration in the official EU AI database before placing the system on the market.
Conclusion
Understanding how to prepare for EU AI Act conformity assessment and notified body requirements is an exercise in engineering discipline, not legal theory. If your compliance strategy relies entirely on static policy documents, you will fail your first market surveillance inspection.
Take this 11-step playbook and integrate it directly into your SDLC. Force your engineering teams to build logging, risk monitoring, and human oversight directly into the codebase.
By front-loading the operational telemetry, you can bypass the consultancy fees, cut your audit prep time by 45%, and secure your global market access ahead of the regulatory deadline.
Frequently Asked Questions (FAQ)
Auditors immediately request the Article 11 technical documentation file, specifically checking the version-controlled change log. They will also demand proof of your Article 9 risk management framework and operational logs generated under Article 12 to verify continuous compliance in production.
If eligible for self-assessment, an internal team can complete it in 4 to 6 weeks, assuming documentation is ready. If a third-party notified body is required (Module H), the process frequently takes 90 to 120 days due to severe auditing bottlenecks.
Most Annex III systems (like HR or credit scoring) qualify for self-assessment. However, biometric identification systems and AI embedded in regulated physical products (Annex I, like medical devices or machinery) strictly require third-party assessment by an accredited notified body.
The file must contain the general system description, development methods, data governance proof, performance metrics, risk management documentation, harmonised standards applied, the post-market monitoring plan, and a comprehensive log of all lifecycle modifications as outlined in Annex IV.
You must present a dynamic, continuous risk register that identifies known and foreseeable risks to safety and fundamental rights. Evidence must include documented mitigation strategies, testing results validating those strategies, and engineering tickets showing risk-based architectural changes.
Article 12 requires automated logging of events to trace the system's functioning throughout its lifecycle, monitor for drift, and facilitate post-market monitoring. Retention periods are not explicitly fixed but generally demand a minimum of six months, longer for safety-critical applications.
Providers must establish a continuous, SRE-style observability system to proactively collect and analyze performance data after deployment. The system must automatically detect degradation, drift, or adverse incidents, triggering mandatory reporting to the AI Office and national authorities.
Registration under Article 49 requires submitting provider details, the AI system's intended purpose, its risk classification, the outcome of the conformity assessment, and a copy of the Article 47 EU declaration of conformity before the system is placed on the market.
Yes. Approximately 60% of ISO/IEC 42001 controls map directly to AI Act requirements. However, the remaining 40%—particularly regarding Article 10 data governance and Article 14 human oversight—requires distinct, AI-Act-specific engineering artifacts that standard 42001 audits do not cover.
When a market surveillance authority identifies non-compliance, they issue a formal request for corrective action. Providers typically have between 10 to 30 days to remediate the documentation or operational flaws before formal administrative fines or market withdrawal orders are executed.