EU AI Act Art.21 Cooperation with Competent Authorities: Developer Guide (High-Risk AI 2026)

EU AI Act Article 21 is the on-demand access mechanism of the high-risk AI framework. Where Art.20 governs what providers must do autonomously when non-conformity is detected, Art.21 governs what all high-risk AI operators — providers, deployers, importers, and distributors — must do when a market surveillance authority requests information, access, or cooperation. The obligation is unconditional, the access scope is broad, and the confidentiality protections available to operators are narrower than many compliance teams assume.

For developers and engineering teams, Art.21 has concrete build implications: MSA access to training data and source code must be technically possible, Annex IV technical documentation must be production-ready and deliverable on short notice, and confidentiality claims must be pre-documented to survive MSA review. Running this infrastructure on EU-native platforms materially simplifies the cooperation framework by eliminating parallel CLOUD Act compellability from the equation.

This guide covers Art.21(1)-(4) in full: the universal cooperation obligation, the MSA access scope, Annex IV documentation handover mechanics, Art.78 confidentiality protections, the Art.21 × Art.20 corrective action synergy, Art.21 × Art.74 market surveillance authority powers, Art.21 × Art.79 risk-based access, NIS2 Art.32/33 dual cooperation obligations for critical infrastructure operators, Python implementation for DocumentAccessRequest, MSACooperationTracker, ConfidentialityClaimRecord, and Art21ComplianceChecker, CLOUD Act dual-compellability risk for MSA records, and the 40-item Art.21 compliance checklist.

Art.21 in the High-Risk AI Compliance Chain

Art.21 occupies the market surveillance cooperation layer of Chapter III Section 2:

Art.21 is triggered externally — by a market surveillance authority investigation, a serious incident report under Art.73, an Art.79 risk classification, or a targeted market surveillance activity under Art.74. The provider (and all other operators in the supply chain) cannot pre-empt or defer this trigger. When the MSA requests cooperation, the obligation activates immediately.

Art.21(1): Universal Cooperation Obligation

Scope: All Operators

Art.21(1) is notable for its universal operator scope. Unlike most obligations in Chapter III Section 2 that apply primarily to providers, Art.21(1) covers:

• Providers: The entity that places the high-risk AI system on the market or puts it into service
• Deployers: Entities that use a high-risk AI system under their own authority in a professional context
• Importers: Entities established in the EU that place a high-risk AI system with a third-country provider on the EU market
• Distributors: Any entity in the supply chain that makes a high-risk AI system available on the EU market

Developer implications of universal scope:

A SaaS platform (deployer) using a third-party high-risk AI API for employment screening is subject to Art.21 cooperation obligations just as the AI provider is. This is not merely a contractual downstream obligation — it is a direct regulatory duty imposed on the deployer by the EU AI Act.

For API providers and platform vendors building infrastructure for AI applications: your downstream customers who are deployers are legally obligated to cooperate with MSAs. Your infrastructure must be capable of supporting their cooperation (access logs, request routing records, system availability metrics) on investigative notice.

The Content of the Cooperation Obligation

Art.21(1) requires operators to take necessary measures to enable MSAs to exercise their powers under Chapter IX. Specifically, this encompasses:

1. Providing information requested by the MSA
2. Granting access to the AI system and its documentation
3. Providing technical assistance for testing and evaluation
4. Making staff available for interviews and technical explanation
5. Cooperating in any investigation the MSA conducts

The term "necessary measures" is broad. An MSA conducting a high-risk AI investigation has authority that extends to the full operational context of the system — not just the model artefact.

Art.21(2): MSA Access Rights to AI System Internals

What MSAs Can Request

Art.21(2) provides the specific operational access rights that MSAs can exercise:

1. Source code access: MSAs can request access to the source code of the high-risk AI system when they have reasonable grounds to believe it does not comply with the Regulation
2. Training data access: Access to training datasets, including validation and test datasets, and the data used for bias detection and correction
3. Model access: Access to the model itself, including weights, architecture specifications, and performance metrics
4. Testing infrastructure access: Access to testing and validation environments sufficient to run evaluations

"Reasonable grounds" standard:

Art.21(2) does not require the MSA to prove non-conformity before requesting access — only to have "reasonable grounds to believe" it. This is a lower threshold than certainty, consistent with the Art.20(1) "reason to believe" activation standard for corrective actions.

Practically, reasonable grounds arise from:

• An Art.73 serious incident report
• A deployer complaint under Art.29(4)
• Market surveillance activity identifying statistical anomalies
• A third-country authority alert through the EU ICSMS system
• An Art.72 post-market monitoring report indicating systemic issues

Technical Readiness Requirements

For providers, Art.21(2) creates de facto technical architecture requirements:

Source code: The codebase must be version-controlled, reproducible, and deliverable in a form that allows the MSA's technical experts to review it. Obfuscated or encrypted production code without a mechanism for authorised MSA review likely fails the cooperation obligation.

Training data: Datasets used for training, validation, and testing must be retained and accessible. The retention period intersects with Art.11(3)'s 10-year technical documentation retention requirement. A provider who has deleted training data after deployment creates an Art.21(2) cooperation gap.

Model artefacts: The specific model version placed on the market — including weights, architecture files, and performance benchmarks — must be accessible in a form that allows MSA-commissioned technical evaluation. Container images or versioned model registries maintained for the Art.11(3) retention period satisfy this requirement.

Testing environments: The ability to reproduce the conformity assessment testing environment is required. This means infrastructure-as-code, containerised test environments, or documented reproducibility procedures must be maintained for the full post-market lifetime of the system.

Art.21(3): Annex IV Technical Documentation Handover

On-Demand Documentation Production

Art.21(3) creates a distinct obligation: upon MSA request, the provider must provide the Annex IV technical documentation — the full pre-market documentation package that underlies the conformity assessment under Art.43.

Annex IV documentation covers 8 sections:

1. General description of the AI system (intended purpose, system interactions, system architecture)
2. Detailed description of design and development (methods, architecture, model design choices)
3. Training, validation, and testing data (datasets, data governance, bias assessment)
4. Post-market monitoring system description
5. Risk management documentation (Art.9 risk register, risk assessment methodology, mitigations)
6. Changes to the system and conformity assessment documentation
7. Declaration of conformity and standards applied
8. EU representative information (where applicable)

Production readiness requirement:

Art.21(3) assumes this documentation can be produced on investigative demand. Unlike routine disclosure obligations (where timelines may be negotiated), MSA investigations under Art.74 can proceed on short notice. Annex IV documentation that requires weeks to compile — because it was never maintained as a production-ready package — creates a material compliance gap.

Format requirements:

The Regulation does not specify a machine-readable format for Annex IV, but MSAs assessing technical conformity will expect documentation that is structured, cross-referenced, and verifiable. A 200-page PDF that cannot be cross-referenced to model artefacts is technically compliant but practically inadequate for a serious investigation.

Art.21(4) + Art.78: Confidentiality Protections

What Art.78 Protects

Art.78 provides that MSAs and other national competent authorities must respect confidentiality when processing information and data obtained in carrying out their tasks. Specifically, Art.78 protects:

• Trade secrets: Commercial information that meets the EU Trade Secrets Directive (2016/943) definition
• Professional secrecy: Information subject to legal professional privilege or equivalent protections
• Intellectual property rights: Proprietary technical information that is not necessary for market surveillance purposes

What Art.78 Does NOT Protect

Critically, Art.78 confidentiality is not an absolute bar to MSA access. The key limitation is that Art.78 protects how MSAs handle information after they receive it — it does not allow providers to refuse to produce information in the first place.

What this means in practice:

A provider cannot refuse Art.21(2) source code access on the grounds that it is a trade secret. What Art.78 ensures is that the MSA treats the source code as confidential after receiving it. The MSA cannot publish the code, share it with competitors, or disclose it beyond what is necessary for the investigation.

Pre-documenting Confidentiality Claims

Proactive confidentiality claim documentation — before an MSA investigation begins — strengthens the provider's Art.78 position:

• Trade secret register: Document which components, datasets, algorithms, and architectural decisions qualify as trade secrets under Directive 2016/943
• IP portfolio map: Document which AI Act-required materials are subject to registered or unregistered IP rights
• Proportionality argument: For each confidential element, document why the full information is not necessary for the MSA's compliance assessment purpose

MSA proportionality constraint:

Art.78 also constrains MSA access requests — the MSA must limit access to what is necessary for its investigation purpose (proportionality principle, Art.5 TFEU). A well-documented confidentiality register strengthens the provider's argument that a summary or aggregated version of sensitive data satisfies the investigation's proportionality requirement.

Art.21 × Art.20: Corrective Action Triggers Cooperation

Art.20 and Art.21 are designed to work in sequence: Art.20 governs what the provider does autonomously when non-conformity is detected; Art.21 governs what the provider must do when the MSA initiates investigation based on that non-conformity.

The Art.20 → Art.21 activation sequence:

1. Provider detects non-conformity → Art.20(1) corrective action triggered
2. Provider takes corrective action, informs downstream chain (Art.20(1))
3. If Art.79(1) risk is identified, provider notifies MSA (Art.20(2))
4. MSA receives Art.20(2) notification → opens investigation under Art.74
5. MSA requests Art.21 cooperation: documentation, access, staff interviews
6. Provider must cooperate under Art.21(1)-(3)

Implications for Art.17 QMS design:

The Art.17(1)(f) communication procedures must cover both the Art.20 proactive reporting sequence and the Art.21 reactive cooperation sequence. A QMS that handles corrective action notifications but lacks an MSA cooperation workflow is incomplete.

Art.20 records as Art.21 material:

When an MSA opens an Art.21 investigation following an Art.20 notification, the Art.20 corrective action records — non-conformity assessments, risk assessments, downstream notification logs — become Art.21 cooperation material. These records were compiled under Art.20's "immediately" requirement and must be producible to the MSA. This creates a specific documentation quality standard for Art.20 records: they must be sufficiently detailed to serve both the Art.20 cascade notification purpose and a subsequent Art.21 investigation.

Art.21 × Art.74: Market Surveillance Authority Powers

Art.74 defines the substantive powers that MSAs can exercise when they conduct market surveillance activities under the AI Act. Art.21 is the legal basis for operators' cooperation with these powers.

Art.74 MSA powers relevant to Art.21 cooperation:

Notice vs. unannounced inspections:

Art.74 provides for both announced (with prior notice to the operator) and unannounced inspections. For unannounced access, the MSA's technical team must be able to access systems in real-time. This imposes a practical requirement: designated MSA liaison contacts and access procedures must be pre-established, not assembled after an unannounced inspection begins.

Art.21 × Art.79: Risk-Based MSA Access

Art.79 defines the threshold that activates the most intensive MSA powers, including emergency measures and cross-border coordination.

Art.79(1) risk definition (recap):

Risk as defined in Art.79(1) means a situation where a high-risk AI system presents a risk to the health, safety, or fundamental rights of persons, or to compliance with obligations under Union or national law.

Art.79 investigation pathway:

When an MSA identifies Art.79(1) risk, the investigation escalates:

1. Art.79(2): MSA carries out an evaluation of the AI system → Art.21 cooperation obligation is at its most extensive
2. Art.79(3): MSA may require corrective or restrictive measures → operator must implement immediately
3. Art.79(4): MSA informs the European AI Office and other Member State MSAs
4. Art.79(5): Cross-border coordination activated — other Member State MSAs may join the investigation

Cross-border cooperation multiplier:

Under Art.79(5), when an MSA informs the European AI Office of an Art.79 risk, other Member State MSAs may initiate their own Art.21 cooperation requests independently. A provider that has placed a high-risk AI system in 10 Member States could theoretically face simultaneous Art.21 cooperation requests from 10 national MSAs for the same investigation.

This is not a theoretical risk for widely-deployed systems. The Art.21 cooperation infrastructure — documentation registry, access procedures, staff liaison protocols — must scale to simultaneous multi-jurisdictional investigation.

NIS2 Art.32/33: Simultaneous Cooperation Obligations for Critical Infrastructure

For operators deploying high-risk AI in critical infrastructure sectors (Annex I NIS2 — energy, transport, water, health, digital infrastructure, financial market infrastructure, public administration), Art.21 AI Act cooperation obligations exist simultaneously with NIS2 Art.32 and Art.33 cooperation duties.

NIS2 Art.32: Essential entities — supervision and enforcement

NIS2 Art.32(2) authorises the competent authority (NCA) to:

• Conduct on-site inspections and remote supervision
• Request evidence of cybersecurity risk management measures (NIS2 Art.21)
• Issue binding instructions for remediating identified non-compliance
• Designate monitoring officers for temporary supervision

NIS2 Art.33: Important entities — enforcement

NIS2 Art.33 provides equivalent powers for important entities, with the difference that NIS2 Art.33 is primarily ex-post (triggered by evidence of non-compliance) while Art.32 also includes proactive supervision.

Dual investigation scenario: AI Act MSA + NIS2 NCA

For a critical infrastructure operator deploying high-risk AI (for example, an energy grid AI system that qualifies under Annex III Category 2 AI Act and is operated by an essential entity under NIS2 Annex I):

Important distinction: AI Act MSA and NIS2 NCA may be different national authorities. The MSA for AI Act purposes is typically the market surveillance authority (e.g., the Federal Network Agency in Germany for digital services), while the NIS2 NCA may be a sector-specific regulator (energy regulator, transport authority). Operators running dual-regime systems must maintain separate liaison contacts for each authority.

The investigation information crossflow problem:

When an AI system incident triggers both an Art.21 AI Act investigation and a NIS2 Art.32 NCA investigation, the documents produced under each cooperation obligation may flow to different authorities. Art.78 AI Act confidentiality protections do not automatically bind the NIS2 NCA. Operators should document the authority-specific confidentiality regime applicable to each document produced — particularly where information produced to the AI MSA could be disclosed to the NIS2 NCA.

Implementation: Python Code for Art.21 Compliance

DocumentAccessRequest

from dataclasses import dataclass, field
from datetime import datetime, timedelta
from enum import Enum
from typing import Optional
from hashlib import sha256
import json

class AccessCategory(Enum):
    """Art.21(2) access categories requested by MSA."""
    SOURCE_CODE = "source_code"
    TRAINING_DATA = "training_data"
    VALIDATION_DATA = "validation_data"
    TEST_DATA = "test_data"
    MODEL_ARTEFACTS = "model_artefacts"          # weights, architecture, metrics
    TESTING_ENVIRONMENT = "testing_environment"
    ANNEX_IV_DOCUMENTATION = "annex_iv_documentation"  # Art.21(3)
    OPERATIONAL_LOGS = "operational_logs"        # Art.12 event logs
    QMS_DOCUMENTATION = "qms_documentation"      # Art.17 QMS records
    CORRECTIVE_ACTION_RECORDS = "corrective_action_records"  # Art.20 records
    STAFF_INTERVIEW = "staff_interview"

class CooperationStatus(Enum):
    RECEIVED = "received"
    ACKNOWLEDGED = "acknowledged"
    CONFIDENTIALITY_CLAIM_FILED = "confidentiality_claim_filed"
    PRODUCTION_IN_PROGRESS = "production_in_progress"
    PRODUCED = "produced"
    DISPUTED = "disputed"

@dataclass
class DocumentAccessRequest:
    """Art.21 cooperation request from a market surveillance authority."""
    request_id: str
    msa_authority: str                     # e.g., "Bundesnetzagentur (Germany)"
    msa_contact_email: str
    msa_reference_number: str
    investigation_basis: str               # Art.73/Art.74/Art.79 basis cited
    system_id: str
    system_name: str
    received_at: datetime
    response_deadline: Optional[datetime] = None
    access_categories: list[AccessCategory] = field(default_factory=list)
    status: CooperationStatus = CooperationStatus.RECEIVED
    produced_at: Optional[datetime] = None
    confidentiality_claims_filed: list[str] = field(default_factory=list)
    legal_counsel_notified: bool = False
    notes: str = ""

    def is_overdue(self) -> bool:
        if self.response_deadline and self.status != CooperationStatus.PRODUCED:
            return datetime.utcnow() > self.response_deadline
        return False

    def days_to_deadline(self) -> Optional[float]:
        if not self.response_deadline:
            return None
        delta = self.response_deadline - datetime.utcnow()
        return delta.total_seconds() / 86400

    def to_audit_record(self) -> dict:
        return {
            "request_id": self.request_id,
            "msa": self.msa_authority,
            "reference": self.msa_reference_number,
            "basis": self.investigation_basis,
            "system": self.system_id,
            "received": self.received_at.isoformat() + "Z",
            "deadline": self.response_deadline.isoformat() + "Z" if self.response_deadline else None,
            "categories": [c.value for c in self.access_categories],
            "status": self.status.value,
            "confidentiality_claims": len(self.confidentiality_claims_filed),
            "overdue": self.is_overdue(),
        }

MSACooperationTracker

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

class InvestigationOutcome(Enum):
    OPEN = "open"
    CLOSED_NO_FINDING = "closed_no_finding"
    CLOSED_CORRECTIVE_ORDER = "closed_corrective_order"
    CLOSED_SUSPENSION_ORDER = "closed_suspension_order"
    CLOSED_MARKET_WITHDRAWAL = "closed_market_withdrawal"
    CLOSED_FINE_ISSUED = "closed_fine_issued"

@dataclass
class MSAInvestigationRecord:
    """Full lifecycle record of an Art.21 MSA investigation."""
    investigation_id: str
    msa_authority: str
    member_state: str
    art74_basis: bool = False              # Standard market surveillance
    art79_basis: bool = False              # Risk-based emergency access
    art73_incident_trigger: bool = False   # Triggered by serious incident report
    cross_border_active: bool = False      # Art.79(5) multi-MSA active
    nis2_parallel_investigation: bool = False  # NIS2 NCA running parallel inquiry
    opened_at: datetime = field(default_factory=datetime.utcnow)
    closed_at: Optional[datetime] = None
    outcome: InvestigationOutcome = InvestigationOutcome.OPEN
    access_requests: list[str] = field(default_factory=list)  # request_ids
    corrective_order_text: Optional[str] = None
    fine_amount_eur: Optional[float] = None

    def duration_days(self) -> Optional[float]:
        end = self.closed_at or datetime.utcnow()
        return (end - self.opened_at).total_seconds() / 86400

    def is_high_risk_investigation(self) -> bool:
        return self.art79_basis or self.cross_border_active or self.nis2_parallel_investigation


class MSACooperationTracker:
    """Tracks all Art.21 MSA investigations across the organisation's AI portfolio."""

    def __init__(self):
        self._investigations: list[MSAInvestigationRecord] = []
        self._requests: list[DocumentAccessRequest] = []

    def register_investigation(self, record: MSAInvestigationRecord) -> str:
        self._investigations.append(record)
        return record.investigation_id

    def register_request(self, request: DocumentAccessRequest) -> str:
        self._requests.append(request)
        return request.request_id

    def open_investigations(self) -> list[MSAInvestigationRecord]:
        return [i for i in self._investigations if i.outcome == InvestigationOutcome.OPEN]

    def overdue_requests(self) -> list[DocumentAccessRequest]:
        return [r for r in self._requests if r.is_overdue()]

    def pending_production(self) -> list[DocumentAccessRequest]:
        pending_statuses = {
            CooperationStatus.RECEIVED,
            CooperationStatus.ACKNOWLEDGED,
            CooperationStatus.CONFIDENTIALITY_CLAIM_FILED,
            CooperationStatus.PRODUCTION_IN_PROGRESS,
        }
        return [r for r in self._requests if r.status in pending_statuses]

    def investigations_for_system(self, system_id: str) -> list[MSAInvestigationRecord]:
        relevant_request_ids = {r.request_id for r in self._requests if r.system_id == system_id}
        return [
            i for i in self._investigations
            if any(rid in i.access_requests for rid in relevant_request_ids)
        ]

    def compliance_summary(self) -> dict:
        return {
            "open_investigations": len(self.open_investigations()),
            "overdue_requests": len(self.overdue_requests()),
            "pending_production": len(self.pending_production()),
            "high_risk_investigations": sum(1 for i in self.open_investigations() if i.is_high_risk_investigation()),
        }

ConfidentialityClaimRecord

from dataclasses import dataclass, field
from datetime import datetime
from typing import Optional

@dataclass
class ConfidentialityClaimRecord:
    """
    Art.78 EU AI Act confidentiality claim for information produced to an MSA.
    Filed at production time — not a refusal to produce, but a request for
    confidential treatment of produced material.
    """
    claim_id: str
    request_id: str                           # Links to DocumentAccessRequest
    material_description: str
    access_category: AccessCategory
    legal_basis: str                          # e.g., "EU Trade Secrets Directive 2016/943 Art.2(1)"
    trade_secret_criteria_met: list[str]      # Secrecy, commercial value, reasonable steps
    proportionality_argument: str             # Why full production exceeds investigation need
    alternative_offered: Optional[str] = None  # Summary / aggregated version offered
    filed_at: datetime = field(default_factory=datetime.utcnow)
    msa_response: Optional[str] = None
    msa_response_received_at: Optional[datetime] = None
    claim_upheld: Optional[bool] = None

    def is_trade_secret_directive_compliant(self) -> bool:
        """Checks EU Trade Secrets Directive Art.2(1) three-criteria test."""
        required = {
            "secrecy",          # Not generally known or readily accessible
            "commercial_value", # Has commercial value by virtue of secrecy
            "reasonable_steps", # Subject to reasonable steps to keep secret
        }
        met_lower = {c.lower() for c in self.trade_secret_criteria_met}
        return required.issubset(met_lower)

    def summary(self) -> dict:
        return {
            "claim_id": self.claim_id,
            "material": self.material_description,
            "category": self.access_category.value,
            "basis": self.legal_basis,
            "trade_secret_compliant": self.is_trade_secret_directive_compliant(),
            "alternative_offered": bool(self.alternative_offered),
            "status": "upheld" if self.claim_upheld else ("rejected" if self.claim_upheld is False else "pending"),
        }

Art21ComplianceChecker

from dataclasses import dataclass

@dataclass
class Art21ProcedureAudit:
    """Validates that an organisation has the required Art.21 procedures in place."""

    # Art.21(1) universal cooperation readiness
    has_msa_liaison_designated: bool = False          # Named contact for MSA requests
    has_msa_contact_registry: bool = False            # All relevant national MSAs documented
    has_cooperation_sop: bool = False                 # Written procedure for receiving MSA requests
    has_legal_counsel_escalation: bool = False        # Legal counsel notification trigger defined
    has_response_timeline_defined: bool = False       # Internal SLA for MSA request response

    # Art.21(2) source code and training data access readiness
    source_code_version_controlled: bool = False      # All deployed versions tagged and reproducible
    training_data_retained_accessible: bool = False   # Datasets retained per Art.11(3) schedule
    model_artefacts_versioned: bool = False           # Weights, architecture, metrics per deployed version
    testing_environment_reproducible: bool = False    # IaC or container-based reproducibility
    access_procedure_technical: bool = False          # Technical access can be granted to MSA team

    # Art.21(3) Annex IV documentation production
    annex_iv_production_ready: bool = False           # All 8 sections complete and deliverable
    annex_iv_cross_referenced: bool = False           # Documentation cross-references model artefacts
    annex_iv_format_structured: bool = False          # Structured, navigable format (not raw PDFs)
    annex_iv_10yr_retention_confirmed: bool = False   # Retained for full Art.11(3) period

    # Art.78 confidentiality protections
    trade_secret_register_exists: bool = False        # Components/datasets designated trade secrets
    confidentiality_claim_procedure: bool = False     # Pre-production confidentiality claim template
    ip_portfolio_documented: bool = False             # IP rights in AI components documented
    proportionality_arguments_prepared: bool = False  # Pre-drafted proportionality arguments

    # Art.21 × Art.20 integration
    art20_records_msa_producible: bool = False        # Art.20 corrective action records format meets Art.21 standard
    art21_cooperation_integrated_with_qms: bool = False  # Art.17(1)(f) covers Art.21 workflow

    # Art.21 × Art.74 inspection readiness
    unannounced_inspection_protocol: bool = False     # Procedure for unannounced Art.74 access
    staff_interview_capability: bool = False          # Technical staff can be made available for MSA interview

    # NIS2 Art.32/33 parallel obligation tracking (critical infra operators)
    nis2_nca_liaison_designated: bool = False         # Separate NIS2 NCA contact (may differ from AI MSA)
    dual_investigation_procedure: bool = False        # Procedure for simultaneous AI + NIS2 investigation
    cross_authority_information_flow_documented: bool = False  # Art.78 × NIS2 confidentiality crossflow mapped

    # Infrastructure jurisdiction
    investigation_records_eu_jurisdictioned: bool = False  # MSA correspondence on EU-native infrastructure

    def score(self) -> tuple[int, int]:
        fields = [v for v in vars(self).values() if isinstance(v, bool)]
        return sum(fields), len(fields)

    def missing_procedures(self) -> list[str]:
        return [
            field.replace("_", " ")
            for field, value in vars(self).items()
            if isinstance(value, bool) and not value
        ]

    def is_art21_compliant(self) -> bool:
        """Minimum Art.21 compliance: all core procedure requirements met."""
        core = [
            self.has_msa_liaison_designated,
            self.has_msa_contact_registry,
            self.has_cooperation_sop,
            self.source_code_version_controlled,
            self.training_data_retained_accessible,
            self.model_artefacts_versioned,
            self.annex_iv_production_ready,
            self.trade_secret_register_exists,
        ]
        return all(core)

CLOUD Act × Art.21: Investigation Records and Dual-Compellability Risk

Art.21 cooperation generates a specific category of sensitive documentation: MSA investigation records. These include MSA correspondence, document access logs, interview transcripts, technical access records, and confidentiality claim submissions. Under Art.78, this information is subject to confidentiality protections in the hands of the MSA. But the records on the operator's side are not covered by Art.78 — they are the operator's own business records, subject to standard cloud jurisdiction rules.

The CLOUD Act problem for Art.21 investigation records:

If an operator stores Art.21 cooperation records — MSA investigation correspondence, Annex IV documentation packages produced to the MSA, source code export logs, training data access records — on US-headquartered cloud infrastructure (AWS, Azure, GCP, Salesforce), the CLOUD Act (18 U.S.C. § 2713) allows US law enforcement to compel production of those records independently of EU law.

The specific risk for Art.21 records:

Art.21 investigations typically involve commercially sensitive material:

• Source code that is a trade secret under the EU Trade Secrets Directive
• Training data that may reveal competitive machine learning approaches
• MSA correspondence that reveals the regulatory risk profile of the provider's AI system
• Confidentiality claim documentation that explicitly identifies which aspects of the system the provider considers most commercially sensitive

A US law enforcement subpoena targeting Art.21 investigation records stored on US cloud infrastructure bypasses:

• Art.78 AI Act confidentiality protections (which bind the EU MSA, not the US government)
• GDPR Art.48 restrictions on international data transfers in response to third-country authority requests
• The provider's Art.78-based confidentiality claims (which were filed with the EU MSA, not the US government)

EU-native infrastructure mitigation:

An EU-headquartered operator using EU-native infrastructure for Art.21 cooperation records — no US parent entity, no US subsidiary, no US-based personnel with access — falls outside CLOUD Act jurisdiction. 18 U.S.C. § 2713 applies to "providers of electronic communication service or remote computing service." An EU entity with no US nexus cannot be compelled under the CLOUD Act.

For operators storing Art.21 materials (MSA correspondence, Annex IV packages, investigation exhibits) on US-based cloud infrastructure, the practical risk is an asymmetric dual-compellability scenario: the EU MSA is bound by Art.78 confidentiality in how it uses the material; the US government, if it subpoenas the same records from AWS or Azure, faces no Art.78 constraint.

Cross-Article Compliance Matrix

Art.21 Compliance Checklist (40 Items)

Art.21(1) Cooperation Readiness

1. ☐ MSA liaison contact designated: named individual responsible for Art.21 cooperation
2. ☐ MSA contact registry: relevant national MSA for each Member State of market presence documented
3. ☐ Cooperation SOP written and tested: step-by-step procedure for receiving and responding to Art.21 requests
4. ☐ Legal counsel escalation trigger defined: conditions under which legal counsel must be notified before response
5. ☐ Response timeline SLA defined: internal deadline for acknowledging and initiating production of MSA requests
6. ☐ Unannounced inspection protocol: procedure for receiving MSA team for unannounced Art.74 access
7. ☐ Staff interview procedure: technical staff can be made available for MSA interviews on defined notice
8. ☐ Art.21(1) training: engineering and compliance staff aware of cooperation obligations

Art.21(2) Technical Access Readiness

1. ☐ Source code version-controlled: all deployed high-risk AI system versions tagged, reproducible, and retrievable
2. ☐ Source code access procedure: MSA technical team can be granted access without compromising production systems
3. ☐ Training data retained and documented: training, validation, and test datasets archived per Art.11(3) retention schedule
4. ☐ Training data access procedure: datasets accessible to MSA with appropriate access controls
5. ☐ Bias assessment records retained: Art.10 bias correction documentation included in retained training data package
6. ☐ Model artefacts versioned: weights, architecture files, and performance benchmarks per deployed version retained
7. ☐ Model access procedure: MSA evaluation team can run model inference on test inputs in controlled environment
8. ☐ Testing environment reproducible: conformity assessment test environment can be recreated (IaC, containers)
9. ☐ Testing environment access procedure: MSA can run evaluation tests without unrestricted production access

Art.21(3) Annex IV Documentation Readiness

1. ☐ Annex IV Section 1 (general description) complete and current
2. ☐ Annex IV Section 2 (design and development) complete with architecture documentation
3. ☐ Annex IV Section 3 (training datasets) complete with data governance and bias assessment
4. ☐ Annex IV Section 4 (post-market monitoring description) current with Art.72 system details
5. ☐ Annex IV Section 5 (risk management) current with Art.9 risk register
6. ☐ Annex IV Section 6 (changes and modifications) updated for all post-market changes
7. ☐ Annex IV Section 7 (declaration of conformity) signed and current
8. ☐ Annex IV Section 8 (standards applied) current with applicable harmonised standards
9. ☐ Annex IV production procedure: documentation can be packaged and delivered to MSA within defined SLA

Art.78 Confidentiality Protection Preparation

1. ☐ Trade secret register: components, datasets, and architectural decisions qualifying as trade secrets documented
2. ☐ Trade Secrets Directive compliance: three-criteria test (secrecy, commercial value, reasonable steps) evidenced for each trade secret
3. ☐ IP portfolio documented: registered and unregistered IP rights in AI components identified
4. ☐ Confidentiality claim template: pre-prepared Art.78 claim template for common access categories
5. ☐ Proportionality arguments prepared: pre-drafted arguments for why summary/aggregated versions satisfy investigation purpose
6. ☐ Alternative production options documented: for each trade secret category, alternative production format available

Art.21 × Art.20/Art.17 Integration

1. ☐ Art.20 corrective action records meet Art.21 evidence standard: sufficient detail for MSA review
2. ☐ Art.17(1)(f) QMS communication procedures cover Art.21 MSA cooperation workflow
3. ☐ Art.17(1)(g) QMS incident register includes Art.21 investigation log entries
4. ☐ Art.21 investigation records retained for Art.11(3) 10-year period

NIS2 Art.32/33 Dual-Obligation Coverage (Critical Infrastructure)

1. ☐ NIS2 NCA liaison designated: separate from AI Act MSA liaison if different authority
2. ☐ Dual investigation procedure: Art.21 + NIS2 Art.32/33 simultaneous investigation workflow documented
3. ☐ Cross-authority information flow: Art.78 AI Act vs. NIS2 NCA confidentiality regime mapped per document type

Infrastructure Jurisdiction

1. ☐ Art.21 investigation records stored in EU-jurisdictioned infrastructure: MSA correspondence, Annex IV packages, access logs stored without CLOUD Act exposure

Enforcement Exposure

Art.21 violations are sanctionable under AI Act Art.99:

• Art.99(3): Failure to cooperate with MSAs as required under Art.21: up to €15 million or 3% of global annual turnover (whichever is higher for SMEs; whichever is higher for large enterprises)
• Art.99(5): Providing incorrect, incomplete, or misleading information to MSAs in response to Art.21 requests: up to €7.5 million or 1%

Why Art.21 non-compliance is particularly high-risk from an enforcement perspective:

1. The MSA is a direct witness to the non-compliance. When a provider fails to cooperate with an Art.21 request, the investigating authority directly experiences the refusal — unlike other compliance failures that require investigation to uncover
2. The paper trail is in the MSA's hands. The MSA's own correspondence and access logs document the provider's cooperation or non-cooperation precisely
3. Non-cooperation escalates the investigation. An Art.74 investigation where the provider fails Art.21 cooperation obligations gives the MSA grounds to apply Art.74(4) emergency suspension measures, which do not require full investigation completion
4. Cross-border multiplier. Art.21 non-cooperation against one MSA, reported to the European AI Office under Art.79(5), triggers engagement by other Member State MSAs simultaneously

What to Do Now

If you're a high-risk AI provider (August 2026 deadline):

1. Designate an MSA cooperation liaison now. This must be a named individual, not a role. MSA investigations move on short notice and "our compliance team will assign someone" is not an adequate response.
2. Audit your Annex IV documentation for production readiness. Can you package and deliver all 8 Annex IV sections within 48 hours of an MSA request? If not, you have a gap. Document the gaps and close them before the August 2026 deadline.
3. Version-control all deployed model artefacts. Weights, architecture specifications, and performance benchmarks for every deployed high-risk AI system version must be retained and retrievable. Delete-on-deploy practices are Art.21(2) compliance failures waiting to be discovered.
4. Build your trade secret register. Art.78 confidentiality claims are only effective if the underlying trade secret designation was pre-documented before the investigation. A post-hoc claim that source code is a trade secret is legally weaker than a register entry pre-dating the MSA request.
5. Integrate Art.21 procedures into your Art.17 QMS. The QMS communication procedures under Art.17(1)(f) must cover the Art.21 cooperation workflow. An MSA arriving for an Art.74 inspection should trigger your QMS, not create an ad hoc response.
6. Audit investigation record storage for CLOUD Act exposure. MSA correspondence, Annex IV packages, and source code access logs are investigation exhibits. Storing them on US-headquartered infrastructure exposes them to CLOUD Act compellability independent of the AI Act's Art.78 confidentiality framework.

If you're a deployer, importer, or distributor:

Art.21(1) cooperation is not just a provider obligation. As an operator in the high-risk AI supply chain:

• Ensure your operational data (Art.12 logs, deployment records, system usage metrics) can be produced to an MSA within your response SLA
• Maintain records of which high-risk AI systems you operate and under which provider conformity assessment
• Ensure your contractual agreements with providers include Art.21 cooperation data-sharing provisions — you cannot cooperate with the MSA about a provider's system if you have no contractual right to access the system's compliance documentation

See Also

• EU AI Act Art.20 Corrective Actions & Duty of Information: Developer Guide
• EU AI Act Art.17 Quality Management System: Developer Guide
• EU AI Act Art.11 Technical Documentation: Annex IV Deep Dive
• EU AI Act Art.12 Logging & Record-Keeping: Developer Guide
• EU NIS2 + AI Act Critical Infrastructure Double Compliance Guide