EU AI Act QMS Audit Readiness: Conformity Assessment, NCA Inspections & the August 2026 Deadline

Post #5 in the sota.io EU AI Act Quality Management System Series

Four posts ago, we mapped the Art.17 Quality Management System. We built the Art.9 risk management system, structured the Art.11 technical documentation, and wired up the Art.72 post-market monitoring feedback loop. Now comes the audit.

The EU AI Act's compliance architecture is not a filing exercise. It culminates in Art.43 conformity assessment — the formal process that transforms your QMS documentation into a legal compliance claim. That claim is embodied in the Art.47 EU Declaration of Conformity and, for CE-marked products, the CE marking itself. Once your system is on the market, Art.74 gives national competent authorities broad inspection powers that reach into the operational internals of your QMS.

This guide is about being ready for that moment: what conformity assessment actually requires, what NCA inspectors look for under Art.74, how Art.21 shapes your cooperation obligations, and the 30-item audit readiness checklist that ties together the entire QMS series.

The Conformity Assessment Gate

Article 43 establishes two conformity assessment routes for high-risk AI systems, depending on the Annex III category:

Route A — Internal control (Annex VIII): The provider performs the conformity assessment independently. No notified body involvement. This applies to most high-risk AI systems listed in Annex III that do not fall under Route B. The provider must demonstrate that their QMS (Art.17), risk management system (Art.9), technical documentation (Art.11), and data governance practices meet the requirements of the Act.

Route B — Third-party conformity assessment: Required for biometric categorisation systems and certain real-time remote biometric identification systems under Annex III, and for high-risk AI systems that are safety components in products already subject to CE marking under harmonised Union legislation (medical devices, machinery, vehicles). A notified body examines and certifies.

For the majority of software-native high-risk AI systems — credit scoring, employment screening, education assessment, access to essential services — Route A applies. That means your internal QMS is the conformity assessment.

What Art.43 Internal Control Actually Tests

When performing Route A conformity assessment, you must verify and document that:

1. QMS completeness (Art.17): All required QMS elements exist and are operational — not just documented but implemented and producing outputs.

2. Risk management currency (Art.9): The risk management system has been executed iteratively and the final risk assessment reflects the system as actually deployed, not as originally designed.

3. Technical documentation accuracy (Art.11): The Annex IV documentation matches the deployed system. If the system changed between initial documentation and deployment, the documentation must have been updated accordingly.

4. Data governance compliance (Art.10): Training and validation data practices meet the Art.10 requirements — lineage documented, bias evaluation performed, data quality criteria applied.

5. Post-market monitoring plan (Art.72): The monitoring plan is in place, operational, and connected to the corrective action procedures in the QMS.

6. Human oversight measures (Art.14): The human oversight measures described in the technical documentation are actually implemented in the deployed system.

The conformity assessment is not a one-time document review. It is a verification activity — you must have evidence that each requirement is met, not just a plan or policy that says it will be met.

# Conformity assessment evidence matrix
class ConformityAssessmentMatrix:
    """Maps each Art.43 requirement to the evidence that satisfies it."""
    
    requirements = {
        "Art17_QMS": {
            "evidence": [
                "QMS_master_document_v{version}.pdf",
                "QMS_procedure_register_{date}.xlsx",
                "Management_review_minutes_{quarter}.pdf",
                "Change_control_log_{year}.xlsx",
            ],
            "owner": "quality_manager",
            "last_verified": "deployment_date",
        },
        "Art9_RMS": {
            "evidence": [
                "Risk_assessment_report_v{version}.pdf",
                "Risk_register_{date}.xlsx",
                "Residual_risk_acceptance_sign-off.pdf",
                "Post-deployment_risk_update_{date}.pdf",
            ],
            "owner": "risk_owner",
            "last_verified": "post_deployment_review",
        },
        "Art11_TechDoc": {
            "evidence": [
                "Technical_documentation_AnnexIV_{version}.pdf",
                "System_architecture_diagram_v{version}.png",
                "Algorithm_validation_report.pdf",
                "Version_history_log.xlsx",
            ],
            "owner": "technical_lead",
            "last_verified": "final_version_sign-off_date",
        },
        "Art10_DataGovernance": {
            "evidence": [
                "Data_governance_policy_{version}.pdf",
                "Dataset_lineage_documentation.xlsx",
                "Bias_evaluation_report_{dataset}.pdf",
                "Data_quality_assessment_{date}.pdf",
            ],
            "owner": "data_officer",
            "last_verified": "training_completion_date",
        },
        "Art72_Monitoring": {
            "evidence": [
                "Post-market_monitoring_plan_{version}.pdf",
                "Monitoring_dashboard_configuration.json",
                "First_monitoring_report_{period}.pdf",
            ],
            "owner": "operations_lead",
            "last_verified": "first_monitoring_cycle_completion",
        },
        "Art14_HumanOversight": {
            "evidence": [
                "Human_oversight_specification_v{version}.pdf",
                "Operator_training_records.xlsx",
                "Override_mechanism_test_results.pdf",
            ],
            "owner": "product_manager",
            "last_verified": "uat_completion_date",
        },
    }
    
    def assess_readiness(self) -> dict:
        gaps = []
        for req, spec in self.requirements.items():
            for evidence_item in spec["evidence"]:
                if not self._evidence_exists(evidence_item):
                    gaps.append({"requirement": req, "missing": evidence_item})
        return {"ready": len(gaps) == 0, "gaps": gaps}

The EU Declaration of Conformity (Art.47)

Once conformity assessment is complete, Art.47 requires the provider to draw up an EU Declaration of Conformity (DoC). The DoC is the formal legal statement that the high-risk AI system meets the requirements of the EU AI Act.

The Art.47 DoC must contain:

• Provider identification: Name, registered trade name, and address
• System identification: Name, type, and version/lot number
• Statement of conformity: Declaration that the system conforms to the EU AI Act
• References to harmonised standards: If any were used during conformity assessment
• Notified body information: If Route B was used — NB name, number, and certificate reference
• Place and date of issue
• Signature and function of the person signing on behalf of the provider

The DoC must be drawn up in one of the official languages of the Member State where the system is placed on the market, or in a language acceptable to the national competent authority. It must be updated whenever a substantial modification triggers a new conformity assessment.

Substantial Modifications and the Re-Assessment Trigger

A substantial modification under the EU AI Act is a change to a high-risk AI system that affects the system's compliance with the requirements of the Act, or that alters the intended purpose of the system. Substantial modifications require a new conformity assessment and a new or updated DoC.

Your QMS change control procedures (required under Art.17) must include a substantial modification evaluation gate — a documented process for determining whether a proposed change constitutes a substantial modification:

class SubstantialModificationEvaluator:
    """
    EU AI Act change control gate.
    Called by QMS change control whenever a system change is proposed.
    """
    
    SUBSTANTIAL_INDICATORS = [
        "change_to_intended_purpose",
        "change_to_high_risk_category_classification",
        "material_change_to_algorithm_architecture",
        "change_to_training_data_distribution",
        "removal_of_human_oversight_mechanism",
        "expansion_to_new_deployment_context",
        "change_to_output_type_or_consequential_scope",
    ]
    
    NON_SUBSTANTIAL_EXAMPLES = [
        "bug_fix_with_no_functional_change",
        "performance_optimisation_within_validated_bounds",
        "infrastructure_update_without_model_change",
        "ui_change_not_affecting_AI_output",
        "security_patch_not_affecting_model",
    ]
    
    def evaluate(self, change_description: str, impact_assessment: dict) -> dict:
        is_substantial = any(
            indicator in impact_assessment.get("flags", [])
            for indicator in self.SUBSTANTIAL_INDICATORS
        )
        return {
            "substantial": is_substantial,
            "triggers_reassessment": is_substantial,
            "doc_update_required": is_substantial,
            "rationale": impact_assessment.get("rationale", ""),
            "documented_by": impact_assessment.get("assessor", ""),
            "date": impact_assessment.get("date", ""),
        }

Every change control decision — substantial or not — must be documented in the QMS change log with the rationale. NCAs inspecting under Art.74 will specifically ask to see change control records and the corresponding DoC revision history.

What Art.74 NCA Inspectors Actually Look For

Article 74 grants national competent authorities broad powers to conduct market surveillance, including on-site inspections, requests for documentation, and — critically — access to the AI system itself under test conditions. Understanding what inspectors are trained to look for is the most practical way to prioritise your audit readiness efforts.

The Three Inspection Modes

Documentary review: The inspector requests your technical documentation package (Art.11/Annex IV), your QMS master document, risk assessment reports, and post-market monitoring reports. They verify completeness against the regulatory requirements and cross-check consistency across documents.

What fails here: Inconsistencies between the technical documentation and the actual deployed system version. Risk assessments that do not address the specific risks identified in Annex III for your category. QMS procedures that exist on paper but show no evidence of implementation (no records, no outputs).

System access test: The inspector tests the AI system's behaviour against the technical documentation claims — particularly the human oversight mechanisms (Art.14) and the system's response to edge cases and anomalous inputs. They may request access to audit logs and inference records.

What fails here: Human oversight mechanisms that are documented but not implemented or that can be trivially bypassed. Confidence scores or uncertainty outputs that the technical documentation claims exist but are not surfaced in the actual system. Audit logs that are incomplete or tampered with.

Operational review: The inspector examines your post-market monitoring outputs — are you collecting the data your Art.72 monitoring plan says you will collect? Are monitoring triggers connected to actual corrective action procedures? Is there evidence that monitoring findings have been fed back into the risk management system?

What fails here: Monitoring plans that describe processes that are not operational. Monitoring data that is collected but never reviewed or acted upon. Corrective action procedures that have been triggered but not completed.

Art.21 Cooperation Obligations

Article 21 requires providers and deployers of high-risk AI systems to cooperate with competent authorities on their request. This cooperation obligation has practical implications for how you structure your compliance operations:

• Documentation access: You must be able to provide complete technical documentation on request, within the timeframes specified by the authority. Typically this means having documentation in a structured, readily accessible format — not scattered across SharePoint folders or Confluence spaces.

• System access: For remote or on-site system testing, you must be able to provide a testing environment that faithfully represents the production system. Maintaining a staging environment that mirrors production (including the same model version, the same human oversight mechanisms, and the same monitoring infrastructure) is both a technical requirement and a practical inspection readiness measure.

• Personnel availability: The inspection team will want to speak with the person responsible for the QMS, the person responsible for the risk management system, and typically an engineer who can explain the model architecture. Having designated, knowledgeable contacts is part of Art.21 cooperation.

class Art21CooperationReadiness:
    """Track cooperation readiness for NCA inspections."""
    
    contacts = {
        "qms_responsible": {
            "role": "Quality Manager",
            "name": "{name}",
            "availability": "business_hours",
            "documentation_access": "full",
        },
        "risk_owner": {
            "role": "Risk Management System Owner",
            "name": "{name}",
            "availability": "business_hours",
            "documentation_access": "full",
        },
        "technical_lead": {
            "role": "AI System Technical Lead",
            "name": "{name}",
            "availability": "on-call",
            "documentation_access": "technical",
        },
        "legal_counsel": {
            "role": "Legal / Compliance Counsel",
            "name": "{name}",
            "availability": "on-call",
            "documentation_access": "regulatory",
        },
    }
    
    documentation_access = {
        "primary_repository": "internal_qms_portal",
        "access_time_from_request": "< 2 business hours",
        "formats_available": ["PDF", "Excel", "JSON artifacts"],
        "version_control": "Git + QMS document management system",
        "encryption": "at_rest_and_in_transit",
    }
    
    testing_environment = {
        "staging_environment": "production_mirror",
        "model_version_parity": "automated_check",
        "monitoring_parity": "same_pipeline",
        "access_provisioning_time": "< 4 hours on request",
    }

Common Audit Failure Modes (and How to Avoid Them)

Based on the regulatory framework structure and the conformity assessment guidance issued by EU AI Office, the failure modes that most commonly lead to enforcement findings cluster around five patterns:

Pattern 1 — Documentation drift: The system changed after initial documentation and the documentation was not updated. The AI system in production does not match what the Annex IV technical documentation describes. Fix: make technical documentation updates a mandatory gate in your change control process. The documentation must always describe the system as deployed, not as originally designed.

Pattern 2 — Process-without-records: The QMS includes the right procedures, but there are no records showing the procedures were followed. Risk assessments with no sign-off. Monitoring with no reports. Training with no records. Fix: every QMS procedure must produce a dated, signed record as its output. Procedures without records are the compliance equivalent of unexecuted code — they have no effect.

Pattern 3 — Monitoring disconnected from QMS: The Art.72 monitoring system collects data, but the data never triggers any action in the QMS. Fix: monitoring triggers must be formally connected to corrective action procedures in the QMS master document, with a documented escalation matrix.

Pattern 4 — Incomplete risk coverage: The risk assessment addresses general AI risks but does not specifically address the risks in the relevant Annex III category. A hiring algorithm that addresses fairness generically but does not specifically address the Art.9 requirements for employment screening. Fix: the risk assessment must map directly to the specific risks listed in Annex III for your category, plus any use-case-specific risks.

Pattern 5 — Human oversight not implemented: The technical documentation describes human oversight mechanisms that are not present in the deployed system, or that are present but do not function as described. This is the most serious failure mode because it goes to the fundamental safety rationale of the high-risk classification. Fix: human oversight mechanisms must be tested end-to-end in a production-representative environment before the conformity assessment is completed.

The 30-Item QMS Audit Readiness Checklist

This checklist ties together the five posts in this series. Every item must be checkable with a document, a record, or a system demonstration.

Art.17 Quality Management System (Posts #1 + #5)

• QMS master document exists, is version-controlled, and is reviewed at least annually
• QMS scope statement explicitly identifies all high-risk AI systems covered
• All QMS procedures have designated owners and are linked from the master document
• Change control procedure includes a substantial modification evaluation gate
• Management review records exist for the most recent review cycle
• Internal audit schedule exists and at least one audit has been completed pre-deployment
• Non-conformance log exists and all open non-conformances have assigned owners and due dates

Art.9 Risk Management System (Post #3)

• Risk assessment report addresses the specific Annex III category risks for your system
• Risk register identifies all risks, their likelihood and severity scores, and control measures
• Residual risk acceptance has documented sign-off from an appropriate authority
• Risk assessment was updated after final pre-deployment testing
• Risk register update triggers are defined in the QMS monitoring procedure

Art.11 Technical Documentation (Post #2)

• Annex IV documentation is complete across all required sections
• Technical documentation version matches the deployed system version
• System architecture diagram reflects the production architecture
• Algorithm validation report documents accuracy, fairness, and robustness metrics
• Data governance documentation covers lineage, quality criteria, and bias evaluation

Art.72 Post-Market Monitoring (Post #4)

• Post-market monitoring plan is part of the technical documentation
• Monitoring infrastructure is operational and producing data
• At least one monitoring review has been completed since deployment
• Monitoring escalation matrix connects monitoring triggers to corrective action procedures
• Art.73 incident reporting thresholds and timelines are documented (2/10/15 days)

Art.43 Conformity Assessment

• Conformity assessment route (A or B) has been determined and documented
• All six conformity assessment dimensions have been verified with evidence
• Evidence matrix exists mapping each requirement to its supporting documentation
• Conformity assessment report is signed by an authorised person

Art.47 EU Declaration of Conformity

• DoC exists and contains all required Art.47 elements
• DoC is in an appropriate language for the target market
• DoC version is aligned with the current conformity assessment report
• DoC update process is defined in the QMS change control procedure

Art.21 Cooperation / Art.74 Inspection Readiness

• Named contacts designated for QMS, risk management, and technical roles
• Documentation can be provided in complete, structured form within 2 business hours
• Staging environment mirrors production for testing purposes
• Audit log retention meets the 10-year minimum (or documented alternative per legal advice)

Connecting the QMS Feedback Loop

The five posts in this series have traced a complete circuit:

Art.17 QMS establishes the management system that governs all compliance activities. It provides the governance structure, the procedures, and the accountability framework.

Art.11 Technical Documentation turns the QMS commitments into specific, verifiable artefacts. Every claim in the DoC must be traceable to a section of the technical documentation.

Art.9 Risk Management makes the compliance claims defensible. It identifies what can go wrong, how badly, and what controls are in place. The risk assessment is the analytical core of the conformity assessment.

Art.72 Post-Market Monitoring keeps the entire system honest after deployment. It is the mechanism by which you discover that your pre-deployment assumptions were wrong — and by which you correct the QMS, the risk assessment, and the technical documentation to reflect what you have learned.

Art.43/47 Conformity Assessment is the moment when you formalise the claim that all of the above is true and correct. It is not the end of the compliance journey — it is the checkpoint at which you are legally accountable for the claim.

The system is circular by design. August 2, 2026 is not a finish line. It is the date by which your first loop must be complete.

The August 2, 2026 Deadline

The EU AI Act's core requirements for high-risk AI systems — Arts. 9, 10, 11, 13, 14, 15, 16-29 — apply from August 2, 2026. For high-risk AI systems that are already on the market before that date, a transition period applies: providers have until August 2, 2027 to bring those systems into compliance, provided the system has not undergone a substantial modification in the interim.

For systems not yet deployed, the compliance deadline for any new deployment after August 2, 2026 is immediate. If your system is deployed after that date without a completed conformity assessment and DoC, you are in violation of the Act from day one.

The enforcement structure under Art.74 gives national competent authorities the tools to discover non-compliance. And the penalties under Art.99 — up to €15 million or 3% of global annual turnover for violations of the core high-risk AI requirements — are calibrated to make non-compliance economically irrational.

Build the QMS. Complete the conformity assessment. Draw up the DoC. Close the loop.

The series is complete. The deadline is 58 days away.

This concludes the sota.io EU AI Act Quality Management System Series: Art.17 QMS architecture (#1), Art.11 technical documentation (#2), Art.9 risk management (#3), Art.72 post-market monitoring (#4), and this conformity assessment / audit readiness guide (#5). Read the complete series at sota.io/blog.