EU AI Act Art.33 Obligations for Notified Bodies: Developer Guide (2026)

EU AI Act Article 33 defines what a notified body must be, how it gets authorised, and what obligations it carries throughout its lifecycle. Notified bodies are the third-party certification organisations that conduct conformity assessments under Annex VII — the mandatory external route for high-risk AI systems in the biometric identification category (Annex III point 1) and any system where the internal control path of Annex VI is legally or technically insufficient.

For developers, Art.33 is the lens through which to evaluate which notified body to engage, whether that body's assessment procedures create downstream compliance risk, and how the body's infrastructure choices affect the jurisdiction of your conformity records. Choosing an unaccredited, out-of-scope, or CLOUD-Act-exposed notified body can invalidate an entire conformity assessment — a catastrophic result at the 8-week-before-market-placement gate imposed by Art.31.

Art.33 does not impose direct obligations on AI system providers. Its obligations bind Member States, accreditation bodies, and the notified bodies themselves. But the developer's due-diligence responsibility under Art.31(2) — selecting the right conformity route — makes Art.33 compliance a provider-facing decision with direct regulatory consequences.

Art.33 in the EU AI Act Architecture

Art.33 sits within Chapter V (Standards, Conformity Assessment, Certificates, Registration), alongside Art.31 (conformity procedure), Art.34 (procedural obligations for notified bodies), and Art.35 (notified body coordination group). The relationship:

A body conducting Annex VII assessments without Art.33 compliance status is not a notified body — and certificates it issues do not satisfy Art.31 requirements.

Art.33(1): Accreditation Requirement

Art.33(1) establishes the accreditation gate: a body can only be notified under Art.33 if it has been accredited by a national accreditation body (NAB) designated pursuant to Regulation (EC) No 765/2008 (the EU Accreditation Regulation).

The accreditation must confirm the body complies with the requirements set out in Annex VII of the AI Act, which covers:

Developer due diligence: Before engaging a notified body, verify their accreditation certificate from the NAB covers AI system conformity assessment specifically — not just generic product certification or ISO management system audits. A body accredited for medical device certification under MDR may not have accreditation that covers Annex III AI Act categories.

Art.33(2): Competence Requirements for AI Assessment

Art.33(2) requires notified bodies to demonstrate specific competence for high-risk AI assessment. Unlike traditional product certification, AI system assessment requires understanding of:

• Machine learning — supervised, unsupervised, reinforcement learning architectures and their failure modes
• Statistical methods — bias detection, distributional shift, performance degradation over time
• Data governance — dataset provenance, representativeness, data minimisation as in Art.10
• Human oversight mechanisms — how Art.14 override and interrupt capabilities function in deployed systems
• Sector-specific knowledge — Annex III point 1 biometrics requires forensic and law enforcement domain expertise; Annex III point 5 employment AI requires HR process and discrimination law knowledge

Art.33(2) also requires that staff with AI assessment responsibility are not involved in the design, manufacturing, supply, installation, or use of the AI systems they assess — a direct competence-independence link.

For developers: When selecting a notified body, request their competence matrix. Ask specifically which Annex III points they are accredited to assess and which ML domains their staff are qualified in. Mismatch between your system's technical architecture and the body's ML competence creates assessment quality risk.

Art.33(3): Notification to the Commission via NANDO

Art.33(3) requires Member States to notify the European Commission of accredited bodies through the NANDO (New Approach Notified and Designated Organisations) database — the same system used for notified bodies under the Medical Device Regulation (MDR/MDR-IVDR), Machinery Regulation, and other product safety directives.

The notification must include:

The NANDO database is the authoritative public source for verifying notified body status. A body's own website claiming notified body status is insufficient — the NANDO entry is the legally operative record.

Developer action: Before contracting with any notified body for an Annex VII assessment, verify their NANDO entry is current, their scope covers your specific Annex III category, and their notification has not been suspended or withdrawn. This verification should be documented in your conformity assessment records.

import requests
from datetime import datetime

class NotificationStatusManager:
    """Verify notified body NANDO status and track notification changes."""

    NANDO_API_BASE = "https://ec.europa.eu/growth/tools-databases/nando/index.cfm"

    def __init__(self, notified_body_id: str, annex_iii_category: str):
        self.notified_body_id = notified_body_id
        self.annex_iii_category = annex_iii_category
        self.verification_log: list[dict] = []

    def verify_active_status(self) -> dict:
        """
        Verify notified body has active NANDO status for required scope.
        In production: query NANDO API or scrape NANDO database.
        Returns status dict for conformity record documentation.
        """
        verification = {
            "notified_body_id": self.notified_body_id,
            "annex_iii_category": self.annex_iii_category,
            "verification_date": datetime.utcnow().isoformat(),
            "nando_url": f"{self.NANDO_API_BASE}?fuseaction=app.notifiedbody&id={self.notified_body_id}",
            "checks_required": [
                "NANDO status: NOTIFIED (not suspended, not withdrawn)",
                f"Scope includes Annex III {self.annex_iii_category}",
                "Annex VII activities: Type-examination or QMS assessment",
                "Accreditation certificate not expired",
                "No pending suspension proceedings",
            ],
            "documentation_note": "Screenshot/export of NANDO entry must be retained as part of Art.31 conformity record",
        }
        self.verification_log.append(verification)
        return verification

    def alert_on_status_change(self, previous_status: str, current_status: str) -> bool:
        """
        Alert if notified body status changes during ongoing assessment.
        Critical: suspension during assessment invalidates the certificate.
        """
        status_degradation = {
            ("NOTIFIED", "SUSPENDED"): "CRITICAL — Ongoing assessment may be invalidated",
            ("NOTIFIED", "WITHDRAWN"): "CRITICAL — Assessment certificates no longer valid",
            ("SUSPENDED", "WITHDRAWN"): "HIGH — Historical certificates under question",
        }
        alert_key = (previous_status, current_status)
        if alert_key in status_degradation:
            return True  # Trigger provider notification
        return False

Art.33(4): Independence Requirements

Art.33(4) establishes that notified bodies must be operationally independent from the AI system providers, importers, distributors, and deployers they assess. Independence encompasses:

• Financial independence — revenue from a single client must not create dependency
• Organisational independence — no shared management, board members, or ownership with assessed parties
• Staff independence — individual assessors must have no personal interest in the outcome
• Temporal independence — staff who previously worked for a provider are excluded from assessing that provider's systems

Independence applies at the level of both the legal entity and individual assessment staff. A notified body that routinely employs former employees of the provider it is assessing — even if organisationally separate — creates independence risk that may trigger scrutiny from the notifying authority.

Developer implication: Independence cuts both ways. The provider cannot coach, influence, or pre-share assessment conclusions with the notified body. Any attempt to shape the assessment outcome risks not just the certificate but the provider's ability to use that notified body in future.

Art.33(5): Subcontracting Rules

Art.33(5) permits notified bodies to subcontract specific assessment tasks — for example, specialised ML bias testing, domain-specific technical evaluation, or language-specific documentation review. The rules:

The notified body must also ensure that the subcontractor is subject to the same confidentiality and independence obligations as the body itself.

Developer action: When a notified body discloses subcontracting, request the subcontractor's competence evidence and verify that the subcontractor is not an entity with whom you have a commercial or employment relationship. Document this due diligence in your assessment records.

Art.33(6): Use of Subsidiaries

Art.33(6) applies the same subcontracting framework to use of subsidiaries. A notified body may engage its own subsidiaries in assessment work, but:

• The subsidiary must meet the same Annex VII requirements
• The provider must be notified
• The parent notified body remains fully responsible
• The subsidiary's independence from the provider must be independently verifiable

This clause is practically significant for large testing and certification organisations (TÜV, Bureau Veritas, SGS, DNV) that operate through national subsidiaries. A German notified body using its Spanish subsidiary to assess a Spanish-language AI system's documentation is permitted — but the Spanish subsidiary must independently meet Annex VII standards.

Art.33(7)–(8): Monitoring and Suspension

Art.33(7) requires the notifying authority (typically the national market surveillance authority or a designated body in each Member State) to conduct ongoing surveillance of notified bodies. Surveillance includes:

• Annual review of accreditation certificate validity
• Periodic competence audits (typically every 2–3 years)
• Review of complaints from AI system providers or affected persons
• Investigation of incorrect or invalidated certificates

Art.33(8) gives notifying authorities the power to suspend or withdraw notification if a body:

• No longer meets Annex VII requirements
• Fails to take corrective action within a specified timeframe
• Has issued certificates for systems that subsequently caused serious incidents

Suspension affects all certificates issued by the body during the suspension period. Withdrawal is retroactive — it raises questions about all certificates the body has issued.

Developer contingency: Build a monitoring procedure that tracks the NANDO status of your notified body quarterly. A suspension during your conformity validity period does not automatically invalidate your certificate — but it triggers a notification obligation to your competent authority and may require re-assessment with a different body.

Art.33(9): Commission Challenge Mechanism

Art.33(9) gives the European Commission the power to challenge the competence of a notified body by requesting the notifying Member State to provide evidence of the body's compliance with Annex VII requirements. If the Member State fails to provide satisfactory evidence, the Commission can require the Member State to take corrective action — up to requiring suspension of the body.

This creates a two-tier oversight structure:

• Member State level: national accreditation body monitors Annex VII compliance
• EU level: Commission can challenge and require corrective action

The Commission has actively used equivalent powers under MDR and NLF directives. Notified bodies under the EU AI Act should expect scrutiny to be at least as intensive given the novelty and sensitivity of AI system assessment.

Art.33(10): Coordination Group for Notified Bodies

Art.33(10) requires notified bodies to participate in the coordination group for AI Act notified bodies (established under Art.35). The group:

• Develops common assessment methodologies for Annex III AI categories
• Shares experience on interpretation of technical requirements
• Promotes consistency in certificate scope and duration decisions
• Reports to the Commission on systemic issues observed in assessments

Coordination is critical for developer predictability: without it, an Annex VII assessment from a German notified body might apply materially different standards than one from a Dutch body — creating an internal market fragmentation problem that the Commission has encountered in MDR/IVDR implementation.

Art.33 × Art.31 × Art.34 × Art.35 Intersection Matrix

CLOUD Act Risk for Notified Body Assessment Records

Art.33 creates an often-overlooked jurisdiction issue. When a notified body stores assessment records — technical documentation reviewed, test results, QMS audit reports, correspondence with the provider — on US-controlled cloud infrastructure, those records become subject to US CLOUD Act compellability.

The practical risk:

EU-native PaaS advantage: A notified body that operates exclusively on EU-native infrastructure — and specifically documents this in their service agreement with you — provides assessment records that are subject only to EU data governance: GDPR, NIS2 Art.21 (if the body handles critical infrastructure AI), and the AI Act itself. No US CLOUD Act parallel compellability.

When negotiating with notified bodies, include a jurisdiction clause specifying that all assessment-related data, including documentation reviewed and assessment reports, must be stored on EU-resident infrastructure with no cross-border transfers to CLOUD Act-subject entities.

Python Implementations

NotifiedBodyAccreditationRecord

from dataclasses import dataclass, field
from datetime import date, datetime
from enum import Enum
from typing import Optional

class NotificationStatus(Enum):
    NOTIFIED = "notified"
    SUSPENDED = "suspended"
    WITHDRAWN = "withdrawn"
    PENDING = "pending_notification"

class AnnexIIICategory(Enum):
    POINT_1_BIOMETRIC = "annex_iii_point_1_biometric_identification"
    POINT_2_CRITICAL_INFRA = "annex_iii_point_2_critical_infrastructure"
    POINT_3_EDUCATION = "annex_iii_point_3_education_vocational"
    POINT_4_EMPLOYMENT = "annex_iii_point_4_employment_workers"
    POINT_5_ESSENTIAL_SERVICES = "annex_iii_point_5_essential_private_services"
    POINT_6_LAW_ENFORCEMENT = "annex_iii_point_6_law_enforcement"
    POINT_7_MIGRATION = "annex_iii_point_7_migration_asylum"
    POINT_8_JUSTICE = "annex_iii_point_8_justice_democratic"

@dataclass
class NotifiedBodyAccreditationRecord:
    """
    Complete accreditation record for an EU AI Act notified body.
    Satisfies Art.33(1) documentation requirement for provider due diligence.
    """
    # Identity
    nando_id: str                          # NANDO database unique identifier
    body_name: str                         # Legal name of notified body
    country_code: str                      # ISO 3166-1 alpha-2 (DE, NL, FR...)
    nab_name: str                          # National accreditation body name

    # Accreditation
    accreditation_certificate_number: str
    accreditation_expiry_date: date
    accreditation_standard: str            # Typically EN ISO/IEC 17065 or 17021

    # Scope
    scope_annex_iii_categories: list[AnnexIIICategory]
    scope_annex_vii_activities: list[str]  # "type_examination", "qms_assessment", "tech_doc_review"

    # Notification status
    notification_status: NotificationStatus = NotificationStatus.NOTIFIED
    notification_date: Optional[date] = None
    suspension_reason: Optional[str] = None

    # Infrastructure
    infrastructure_jurisdiction: str = "EU"   # "EU" or "US-controlled" or "mixed"
    cloud_act_risk: bool = False

    # Due diligence
    verification_date: date = field(default_factory=date.today)
    verified_by: str = ""                  # Person performing verification

    def covers_category(self, category: AnnexIIICategory) -> bool:
        return category in self.scope_annex_iii_categories

    def is_valid_for_assessment(self) -> tuple[bool, list[str]]:
        issues = []
        if self.notification_status != NotificationStatus.NOTIFIED:
            issues.append(f"Notification status: {self.notification_status.value} (must be NOTIFIED)")
        if self.accreditation_expiry_date < date.today():
            issues.append(f"Accreditation expired: {self.accreditation_expiry_date}")
        if self.cloud_act_risk:
            issues.append("Infrastructure: CLOUD Act jurisdiction risk — negotiate EU-only storage clause")
        return len(issues) == 0, issues

    def to_conformity_record_entry(self) -> dict:
        """Format for inclusion in Art.31/Art.48 conformity documentation."""
        return {
            "notified_body_nando_id": self.nando_id,
            "notified_body_name": self.body_name,
            "accreditation_certificate": self.accreditation_certificate_number,
            "accreditation_valid_until": self.accreditation_expiry_date.isoformat(),
            "notification_status": self.notification_status.value,
            "scope_categories": [c.value for c in self.scope_annex_iii_categories],
            "verification_date": self.verification_date.isoformat(),
            "verified_by": self.verified_by,
            "infrastructure_jurisdiction": self.infrastructure_jurisdiction,
        }

CompetenceAssessmentTracker

from dataclasses import dataclass, field
from typing import Optional

@dataclass
class AICompetenceDomain:
    domain: str             # e.g. "supervised_ml", "bias_detection", "nlp"
    staff_count: int        # Number of qualified staff
    qualification_evidence: str  # Certificates, publications, prior assessments
    annex_iii_applicability: list[str]  # Which Annex III categories this covers

@dataclass
class CompetenceAssessmentTracker:
    """
    Verify that a notified body has required AI competence for a specific assessment.
    Implements Art.33(2) due diligence check for provider records.
    """
    notified_body_nando_id: str
    system_annex_iii_category: AnnexIIICategory
    system_ml_architecture: str    # "transformer", "cnn", "gradient_boosting", etc.
    system_domain: str             # "biometrics", "employment", "credit_scoring"

    declared_competences: list[AICompetenceDomain] = field(default_factory=list)
    competence_gaps: list[str] = field(default_factory=list)
    assessment_risk_level: str = "unknown"  # "low", "medium", "high", "critical"

    # Minimum competence requirements by Annex III category
    CATEGORY_COMPETENCE_MAP: dict = field(default_factory=lambda: {
        AnnexIIICategory.POINT_1_BIOMETRIC: [
            "facial_recognition_ml", "biometric_template_protection",
            "liveness_detection", "demographic_bias_testing",
            "law_enforcement_domain_knowledge"
        ],
        AnnexIIICategory.POINT_4_EMPLOYMENT: [
            "nlp_cv_screening", "statistical_bias_detection",
            "protected_characteristic_analysis", "employment_law_eu",
            "algorithmic_fairness_metrics"
        ],
        AnnexIIICategory.POINT_5_ESSENTIAL_SERVICES: [
            "credit_scoring_ml", "explainability_lime_shap",
            "fairness_in_lending", "eu_consumer_credit_directive"
        ],
    })

    def assess_competence_match(self) -> tuple[str, list[str]]:
        """
        Check if notified body's declared competences match assessment requirements.
        Returns: (risk_level, list_of_gaps)
        """
        required = self.CATEGORY_COMPETENCE_MAP.get(
            self.system_annex_iii_category, []
        )
        declared_domains = {c.domain for c in self.declared_competences}
        gaps = [r for r in required if r not in declared_domains]

        if len(gaps) == 0:
            risk = "low"
        elif len(gaps) <= 1:
            risk = "medium"
        elif len(gaps) <= 3:
            risk = "high"
        else:
            risk = "critical"

        self.competence_gaps = gaps
        self.assessment_risk_level = risk
        return risk, gaps

    def generate_competence_request(self) -> list[str]:
        """Generate list of competence evidence to request from notified body."""
        return [
            f"Staff CV showing {domain} expertise"
            for domain in self.CATEGORY_COMPETENCE_MAP.get(
                self.system_annex_iii_category, []
            )
        ] + [
            "List of previously assessed AI systems in same Annex III category",
            "Names and qualifications of assessment team for your system",
            "Subcontracting plan (Art.33(5)) if any assessment tasks are delegated",
        ]

Art.33 40-Item Compliance Checklist for Developers

Checklist for AI system providers before and during Annex VII conformity assessment engagement.

Notified Body Selection (Art.33(1)–(2))

1. Verify notified body exists in NANDO database at time of engagement
2. Confirm NANDO notification status is ACTIVE (not suspended, not withdrawn)
3. Verify NANDO scope explicitly covers your Annex III category
4. Confirm NANDO scope covers required Annex VII activities (type-examination, QMS, tech doc review)
5. Review national accreditation certificate number and expiry date
6. Confirm accreditation standard is EN ISO/IEC 17065 or equivalent for AI Act scope
7. Request competence matrix demonstrating AI-specific expertise per Art.33(2)
8. Verify staff qualifications in ML architecture used by your system
9. Request list of prior AI Act assessments (or equivalent EU AI system assessments) completed
10. Confirm body has sector-specific knowledge matching your Annex III deployment domain

Independence Verification (Art.33(4))

1. Conduct conflict-of-interest screen: does body have commercial ties to your company?
2. Check that assessment staff have no prior employment history with your organisation
3. Verify no shared board members or investors between your company and the notified body
4. Confirm the body does not hold equity in any AI system providers operating in your market
5. Review body's impartiality policy (Annex VII(5)) and ensure it covers your engagement

Subcontracting Due Diligence (Art.33(5)–(6))

1. Request disclosure of any subcontracting planned for your assessment
2. Verify subcontractor also appears in NANDO or has equivalent accreditation
3. Check subcontractor has no conflicts of interest with your company
4. Confirm the notified body will retain full responsibility for subcontracted work
5. Document subcontracting arrangement in your conformity assessment records

Infrastructure and Jurisdiction (CLOUD Act)

1. Ask the body where assessment records will be stored (datacenter country)
2. Identify whether storage infrastructure is subject to US CLOUD Act (AWS, Azure, Google)
3. If CLOUD Act risk exists, negotiate EU-only storage clause in engagement contract
4. Request written confirmation that no assessment data will be transferred outside EEA
5. Verify body's own internal IT systems are not on US-controlled cloud infrastructure

Assessment Process Controls (Art.33 × Art.34)

1. Request the body's assessment procedure document for Annex VII type-examination
2. Confirm the body follows the coordination group guidance from Art.35 (when available)
3. Agree on timeline: Annex VII assessments typically require 12–20 weeks minimum
4. Identify which specific Annex IV documentation sections will be evaluated
5. Confirm the body will review your risk management system (Art.9) as part of QMS assessment

Certificate and Record Management

1. Confirm certificate will include NANDO identification number and scope reference
2. Agree on certificate validity period (typically 5 years with annual surveillance)
3. Obtain written confirmation of what triggers mandatory re-assessment under Art.23 changes
4. Establish the body's process for issuing supplementary certificates for substantial modifications
5. Document the certificate reference in your Art.48 Declaration of Conformity template

Ongoing Monitoring

1. Set quarterly calendar reminder to verify NANDO status remains active
2. Subscribe to national accreditation body announcements for suspension/withdrawal notices
3. Establish internal process for responding to Art.33(7) surveillance audit requests
4. Build contractual right to receive 30-day advance notice of body's suspension or accreditation review
5. Confirm the body participates in the Art.35 coordination group and monitor group guidance outputs

Art.33 Enforcement Exposure

Art.33 violations bind notified bodies and Member States, not providers directly. However, provider exposure arises indirectly:

The provider's insulation from direct Art.33 penalties depends entirely on robust due diligence documentation. Using the checklist above and retaining evidence of each verification step creates a defensible record that you relied in good faith on a properly notified body.

See Also

• EU AI Act Art.31: Conformity Assessment Procedure for High-Risk AI — which route requires a notified body and how to navigate Annex VI vs. Annex VII
• EU AI Act Art.32: EU Database Registration for High-Risk AI — the registration step that follows a successful Annex VII assessment
• EU AI Act Art.30: Post-Market Monitoring for High-Risk AI — the ongoing obligations that begin after registration
• EU AI Act Art.17: Quality Management System Requirements — the QMS that notified bodies assess under Annex VII
• EU AI Act Art.9: Risk Management for High-Risk AI Systems — the risk management framework underlying all conformity assessment inputs