EU AI Act Art.21 Cooperation with Competent Authorities: Documentation Requests, Source Code Access Under Art.74(10), Contact Point Obligations, and Art.21 × Art.74 × Art.18 × Art.93 Integration (2026)

Article 21 of the EU AI Act is the obligation that closes the loop between provider compliance and regulatory enforcement. It establishes the affirmative duty of providers to cooperate with national competent authorities (NCAs): to provide documentation on request, to make the AI system accessible for assessment, and — in the most demanding cases — to provide source code access under specific conditions. Without Art.21, the entire compliance architecture of Chapter III would be unverifiable in practice.

Art.21 sits precisely at the end of the core provider obligations sequence: Art.17 (QMS), Art.18 (documentation keeping), Art.19 (log retention), Art.20 (corrective actions), Art.21 (cooperation with authorities). Each of these obligations feeds into the next. Art.18 mandates retention of documentation for 10 years precisely so that Art.21 requests can be satisfied at any point within that window. Art.19 mandates log retention so that NCAs can audit what an AI system was doing during the period under review. Art.20 creates the notification pathway that initially engages NCA attention. Art.21 then defines what that engagement requires.

This guide covers the full scope of Art.21: what documentation must be provided, in what language, under what timeline, at what threshold source code access is required, how the contact point obligation works, how the supply chain cooperation duties interact, and what penalties apply for non-cooperation.

The Legal Architecture of Art.21

Art.21(1) — Documentation and Information on Request:

Providers of high-risk AI systems shall, upon request by a national competent authority, provide all information and documentation necessary to demonstrate the conformity of the high-risk AI system with the requirements set out in Section 2, in a language which can be easily understood by that authority.

Three elements of Art.21(1) require unpacking.

"Upon request" establishes that the Art.21 obligation is reactive rather than proactive. Unlike Art.72 (post-market monitoring), which requires providers to proactively collect and analyse operational data, Art.21 requires cooperation when the NCA initiates a request. However, the obligation to be ready to comply is continuous — the documentation infrastructure that Art.21(1) requests must be maintained at all times, not assembled after a request arrives. The 10-year documentation retention mandate of Art.18 is the structural mechanism that ensures Art.21 readiness.

"All information and documentation necessary to demonstrate conformity" is a broad formulation. The baseline is the technical documentation defined in Art.11 and Annex IV — nine categories covering: general system description, design specifications, training data characteristics, validation and testing results, conformity assessment documentation, post-market monitoring plan, and the QMS documentation under Art.17. But "all information and documentation necessary" is not limited to this baseline. An NCA investigating a specific compliance question may request:

• Internal correspondence relating to a design decision that affects Art.14 human oversight
• Statistical performance data from post-market monitoring that goes beyond what is in the Annex IV documentation
• Contracts with data providers that bear on Art.10 data governance compliance
• Audit logs from the QMS under Art.17 documenting how a known performance issue was handled
• Supply chain documentation identifying the origin of training datasets

The scope of an Art.21(1) request is bounded by what is "necessary to demonstrate conformity" — meaning an NCA cannot use Art.21(1) to conduct a fishing expedition for commercially sensitive information unrelated to compliance. But within the bounds of what the Section 2 requirements demand, the documentation obligation is comprehensive.

"In a language which can be easily understood by that authority" is the language requirement. NCAs operate in the official language(s) of their Member State. An Art.21(1) request from the German Federal AI Office (BAIK) is likely to require documentation in German. A request from the Irish Data Protection Commission (in its capacity as NCA for AI deployed in Ireland) may be satisfied in English. The "easily understood" standard means providers cannot provide highly technical documentation in a language the NCA does not read without risking non-compliance.

The practical implication for providers operating across multiple EU Member States: technical documentation should either be prepared in a common NCA-accessible language (English is widely accepted in practice, though not mandated) or be maintained with translation capacity. The EU AI Act does not require simultaneous multi-language documentation, but it does require that documentation be translated upon request. The cost of translation is a compliance cost that providers must build into their compliance architecture.

Art.21(2) — Source Code Access:

Upon a reasoned request of a national competent authority, providers shall also provide the source code of the high-risk AI system where that is necessary to assess the conformity of the high-risk AI system with Section 2 requirements.

The source code access provision in Art.21(2) is one of the most commercially sensitive elements of the entire EU AI Act compliance architecture. Source code is the most proprietary artifact a technology provider possesses. The conditions under which Art.21(2) applies therefore require careful analysis.

"Reasoned request" is a higher threshold than the "request" standard for documentation in Art.21(1). The NCA must provide reasons for why source code is necessary — it cannot request source code as a routine element of conformity assessment. The NCA must articulate why the other documentation (Annex IV technical documentation, logs, testing results) is insufficient to assess conformity, and why source code inspection would address the conformity question the NCA is investigating.

"Where that is necessary to assess conformity" further limits the source code obligation. Source code access is a measure of last resort — it is appropriate when the documentation under Art.21(1) does not allow the NCA to reach a conclusion on the conformity question at issue, and when the source code would provide information that the other documentation cannot. For most conformity assessments, Annex IV documentation supplemented by testing access to the AI system will be sufficient. Source code requests under Art.21(2) are expected to be exceptional rather than routine.

The Art.74(10) Source Code Access Framework

Art.21(2) cross-references Art.74(10) for the conditions under which source code access may be required. Art.74(10) provides:

Where necessary to assess the conformity of a high-risk AI system with this Regulation and upon a reasoned request, national competent authorities shall be granted access to the source code of the high-risk AI system by the provider.

Art.74 gives the broader inspection framework for market surveillance. Art.74(10) is the specific provision establishing source code access as an inspection tool, subject to the same "reasoned request" and "necessary" conditions as Art.21(2). The two provisions work together: Art.21(2) establishes the provider's cooperation obligation, Art.74(10) establishes the NCA's corresponding power to request source code as part of its market surveillance function.

The Art.74(10) framework includes an important constraint: the source code access must be subject to the Regulation's confidentiality protections. NCAs who access source code under Art.74(10) are bound by obligations of professional secrecy that prevent the source code from being disclosed to third parties. The practical expectation is that NCAs will have access to source code in a controlled environment — either a secure facility operated by the NCA, or a provider-operated secure remote access environment — rather than receiving copies of the source code.

Source Code Access: Practical Threshold Analysis

Language Requirement: Practical Architecture

The language requirement in Art.21(1) ("in a language which can be easily understood by the national competent authority") creates compliance risk for providers who maintain technical documentation in a single language. The practical architecture options are:

Option 1 — English as base language, translation on request: Maintain core technical documentation in English, which is widely understood by EU NCAs. Upon receiving an Art.21(1) request from an NCA that requires documentation in another language, initiate translation of relevant sections. This approach is appropriate where the volume of Art.21 requests is low and the provider has translation capacity.

Option 2 — Multi-language documentation maintained proactively: For providers with significant market presence in specific Member States — particularly Germany, France, Spain, and Italy, whose NCAs are most likely to issue Art.21 requests — maintain proactive translations of the Annex IV technical documentation in those languages. Higher upfront cost, but faster and more reliable compliance.

Option 3 — Certified translation service retainer: Engage a certified legal/technical translation service on retainer, with contractual SLAs for technical AI documentation. Allows on-demand compliance without proactive translation cost.

The language requirement applies to "all information and documentation necessary" — meaning that for a major Art.21(1) request, the translation burden can be substantial. Planning for this contingency is part of the Art.21 compliance infrastructure.

Contact Point Obligation

Art.21(3) provides: Providers shall provide a contact point for national competent authorities, ensuring continuous accessibility during normal business hours.

The contact point obligation is a structural compliance element that is frequently overlooked in AI Act compliance programmes. It requires:

Designated accessibility: A specific contact point — a person, role, or monitored email/phone channel — must be designated for NCA communications. This is not a generic customer service contact. The contact point must be in a position to respond to NCA requests intelligently and to route requests to the appropriate internal teams (legal, technical, compliance).

Continuous accessibility during normal business hours: The contact point must be accessible during normal business hours in the EU Member States where the provider has placed high-risk AI systems on the market. For a provider operating in Germany, "normal business hours" means Central European Time (CET/CEST). For a provider operating in Ireland, it means GMT/IST. For a multi-country provider, the contact point must cover all relevant business hours, which for providers operating across all EU Member States may require an accessible window of approximately 09:00-18:00 CET as a minimum.

Practical implementation: Most compliance programmes implement the contact point as:

• A dedicated email address (e.g., ai-compliance@company.com) monitored by the compliance or legal team
• A documented escalation pathway from that email to technical documentation holders and legal counsel
• An SLA for initial response (typically 24 business hours for initial acknowledgement, followed by a substantive response timeline based on request complexity)

The contact point information is typically disclosed in the EU Declaration of Conformity under Art.47 and in the technical documentation under Art.11.

Cooperation Timeline: What Does "Promptly" Mean?

Art.21 does not specify explicit response timelines, unlike Art.73 (which specifies 72-hour and 15-day windows for serious incident reports). In practice, response timelines for Art.21 requests are:

These timelines are not mandated in the Regulation but reflect expected practice under administrative cooperation frameworks. NCAs that issue Art.21 requests will typically specify a response deadline in the request itself. Failure to meet the deadline without a valid explanation constitutes non-cooperation, which triggers Art.93 penalty exposure.

Supply Chain Cooperation: Authorized Representatives, Importers, Deployers

Art.21 is a provider obligation, but the supply chain cooperation framework extends beyond providers.

Authorized Representatives (Art.22): Providers established outside the EU who place high-risk AI systems on the EU market must designate an authorized representative. The authorized representative's mandate under Art.22 includes being the primary contact for NCAs in the EU. In practice, the authorized representative handles Art.21(1) document requests by coordinating with the provider to assemble and transmit the required documentation. The authorized representative must have sufficient access to the provider's documentation to perform this function effectively — this is a contractual requirement that must be built into the authorized representative agreement.

Importers (Art.23): Importers of high-risk AI systems must cooperate with NCAs on request, providing documentation and information about the provider and the system. The importer's cooperation obligation is narrower than the provider's — importers typically do not possess source code — but extends to what they know about the system and its provenance.

Deployers (Art.26(7)): Deployers of high-risk AI systems must cooperate with NCAs when the NCA is conducting an assessment of the system in the deployers' deployment environment. The deployer cooperation obligation under Art.26(7) includes providing access to logs retained under Art.19(2) and information about the specific deployment context that may be relevant to the conformity assessment.

Art.21 × Art.74 Intersection: The Full Inspection Powers Framework

Art.21 establishes the cooperation obligation from the provider's perspective. Art.74 establishes the corresponding inspection powers from the NCA's perspective. Understanding both provisions together provides the complete picture.

Art.74(1-3): NCAs have the power to conduct market surveillance of AI systems placed on the EU market, including accessing any documentation and technical information held by operators. This is the general inspection power that Art.21(1) responds to.

Art.74(4): NCAs may request providers to provide samples of AI systems for testing. This is distinct from Art.21(1) documentation requests — it is a request for access to the operational system itself. Providers must comply with reasonable testing access requests.

Art.74(5-9): NCAs may conduct announced and unannounced inspections of premises where high-risk AI systems are developed or operated. Providers must permit these inspections and may not obstruct or delay them.

Art.74(10): Source code access on reasoned request, as discussed above.

The Art.74 powers mean that Art.21 cooperation is not the ceiling of NCA inspection authority — it is the floor. NCAs have powers beyond what Art.21 requires providers to offer proactively. Art.21 establishes the minimum cooperation standard; Art.74 establishes the NCA's power to go further.

Art.21 × Art.18: Documentation Retention as Cooperation Infrastructure

The relationship between Art.21 and Art.18 is architecturally fundamental. Art.18 requires providers to retain:

• The technical documentation required by Art.11 and Annex IV
• The EU Declaration of Conformity under Art.47
• All other documentation and evidence demonstrating conformity

This retention obligation extends for 10 years after the last unit of the AI system is placed on the market. The purpose of this 10-year retention window is precisely to enable Art.21 compliance. An NCA may request documentation under Art.21(1) at any point during the 10 years — for example, investigating an incident that occurred 3 years after market placement. If the documentation has been purged, the provider cannot comply with Art.21(1) and faces Art.93 penalty exposure.

The practical implication: documentation retention under Art.18 is not merely a record-keeping compliance exercise. It is the infrastructure for the Art.21 cooperation obligation. A documentation retention policy that purges records prematurely creates direct Art.21 non-compliance risk.

Non-Cooperation: Art.93 Penalty Exposure

Failure to cooperate with NCAs under Art.21 is subject to the administrative penalties of Art.93. The penalty framework distinguishes between different types of violations:

Art.93(3): Failure to comply with obligations under the Regulation — including Art.21 cooperation obligations — is subject to a maximum fine of €15,000,000, or in the case of an undertaking, a maximum of 3% of total worldwide annual turnover for the preceding financial year, whichever is higher.

Art.93(4): Supply of incorrect, incomplete, or misleading information to NCAs in response to Art.21 requests is subject to the same €15,000,000 / 3% maximum.

Non-cooperation with NCAs is therefore not a minor compliance gap — it carries the same penalty ceiling as substantive non-conformity with Section 2 requirements. The practical consequence: providers who receive Art.21 requests must treat compliance as a priority matter, involving legal counsel and compliance leadership, with documented procedures for managing the request.

Art.93(5): For SMEs and startups, penalties are proportionate and consider their economic viability. The Regulation explicitly requires NCAs to impose proportionate penalties, giving particular consideration to company size and economic strength.

Art.21 in Multi-Regulatory Environments: GDPR, NIS2, DORA

Providers subject to multiple regulatory regimes will receive cooperation requests from multiple authorities. Understanding how Art.21 interacts with parallel cooperation obligations is essential:

Art.21 × GDPR Art.58: Under GDPR, supervisory authorities have the power to obtain access from controllers and processors to all personal data and all information necessary for the performance of supervisory tasks. Where a high-risk AI system processes personal data, the GDPR supervisory authority may request the same documentation that an NCA requests under Art.21. The AI Act does not displace GDPR obligations — providers must maintain documentation that satisfies both the GDPR Art.58 access framework and the Art.21 cooperation framework.

Art.21 × NIS2 Art.32: NIS2 grants supervisory authorities the power to request documentation, access information systems, and conduct security audits of essential and important entities. Where a provider is also an essential entity under NIS2 (e.g., a digital infrastructure provider), NCA requests under Art.21 and NCA requests under NIS2 Art.32 may cover overlapping subject matter. The documentation architecture should be designed to respond to both.

Art.21 × DORA Art.37: DORA requires financial entities to cooperate with competent authorities in the financial sector (ESAs and national supervisors) regarding ICT risk management. Where an AI provider is a financial entity, DORA cooperation obligations layer on top of AI Act Art.21 obligations. The documentation required by DORA Art.37 (ICT risk management documentation) overlaps significantly with the AI Act Annex IV technical documentation — maintaining a unified documentation architecture that satisfies both is more efficient than parallel documentation systems.

Python CooperationManager Implementation

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


class RequestType(Enum):
    DOCUMENTATION = "documentation"
    SYSTEM_ACCESS = "system_access"
    SOURCE_CODE = "source_code"
    TESTING_ACCESS = "testing_access"
    EMERGENCY = "emergency"


class RequestStatus(Enum):
    RECEIVED = "received"
    ACKNOWLEDGED = "acknowledged"
    IN_PROGRESS = "in_progress"
    PENDING_TRANSLATION = "pending_translation"
    RESPONDED = "responded"
    OVERDUE = "overdue"
    CLOSED = "closed"


@dataclass
class NCARequest:
    request_id: str
    nca_name: str
    member_state: str
    request_type: RequestType
    received_date: datetime
    deadline: Optional[datetime]
    subject: str
    requires_source_code: bool = False
    requires_translation: bool = False
    target_language: Optional[str] = None
    status: RequestStatus = RequestStatus.RECEIVED
    response_log: list = field(default_factory=list)

    def days_to_deadline(self) -> Optional[int]:
        if self.deadline:
            return (self.deadline - datetime.now()).days
        return None

    def is_overdue(self) -> bool:
        if self.deadline:
            return datetime.now() > self.deadline
        return False


class CooperationManager:
    """Art.21 EU AI Act — cooperation with NCAs."""

    SLA_DAYS = {
        RequestType.DOCUMENTATION: 10,
        RequestType.SYSTEM_ACCESS: 15,
        RequestType.SOURCE_CODE: 20,
        RequestType.TESTING_ACCESS: 15,
        RequestType.EMERGENCY: 2,
    }

    def __init__(self, contact_point_email: str, contact_point_name: str):
        self.contact_point_email = contact_point_email
        self.contact_point_name = contact_point_name
        self.active_requests: list[NCARequest] = []
        self.documentation_registry: dict[str, dict] = {}

    def receive_request(
        self,
        nca_name: str,
        member_state: str,
        request_type: RequestType,
        subject: str,
        requires_source_code: bool = False,
        target_language: Optional[str] = None,
        nca_deadline: Optional[datetime] = None,
    ) -> NCARequest:
        """Register an incoming Art.21 NCA request."""
        request_id = hashlib.sha256(
            f"{nca_name}{datetime.now().isoformat()}{subject}".encode()
        ).hexdigest()[:12]

        # Determine deadline: NCA-specified or internal SLA, whichever is earlier
        internal_sla = datetime.now() + timedelta(days=self.SLA_DAYS[request_type])
        if nca_deadline:
            deadline = min(nca_deadline, internal_sla)
        else:
            deadline = internal_sla

        request = NCARequest(
            request_id=request_id,
            nca_name=nca_name,
            member_state=member_state,
            request_type=request_type,
            received_date=datetime.now(),
            deadline=deadline,
            subject=subject,
            requires_source_code=requires_source_code,
            requires_translation=target_language is not None,
            target_language=target_language,
        )
        self.active_requests.append(request)
        return request

    def validate_source_code_request(self, request: NCARequest) -> dict:
        """Check Art.21(2) + Art.74(10) prerequisites for source code access."""
        issues = []
        if not request.requires_source_code:
            issues.append("Request does not indicate source code requirement")
        # Art.21(2): must be a "reasoned request"
        if "reasoned" not in request.subject.lower() and request.requires_source_code:
            issues.append(
                "Source code request should include NCA reasoning (Art.21(2) 'reasoned request' requirement)"
            )
        return {
            "eligible": len(issues) == 0,
            "issues": issues,
            "recommendation": (
                "Engage legal counsel before providing source code access. "
                "Agree on secure access protocol with NCA. "
                "Source code access should occur in controlled environment per Art.74(10)."
            ),
        }

    def prepare_documentation_package(
        self, request: NCARequest, doc_ids: list[str]
    ) -> dict:
        """Assemble Annex IV documentation package for Art.21(1) response."""
        package = {
            "request_id": request.request_id,
            "nca": request.nca_name,
            "prepared_at": datetime.now().isoformat(),
            "documents": [],
            "language_note": None,
        }

        annex_iv_categories = [
            "general_description",
            "design_specifications",
            "training_data_characteristics",
            "validation_testing_results",
            "conformity_assessment_documentation",
            "post_market_monitoring_plan",
            "qms_documentation",
            "eu_declaration_of_conformity",
            "technical_standards_applied",
        ]

        for doc_id in doc_ids:
            if doc_id in self.documentation_registry:
                package["documents"].append(self.documentation_registry[doc_id])

        if request.requires_translation and request.target_language:
            package["language_note"] = (
                f"Translation to {request.target_language} required per Art.21(1). "
                f"Initiating translation workflow."
            )

        return package

    def check_overdue_requests(self) -> list[NCARequest]:
        """Identify overdue Art.21 requests — Art.93 penalty risk."""
        overdue = []
        for req in self.active_requests:
            if req.is_overdue() and req.status not in (
                RequestStatus.RESPONDED,
                RequestStatus.CLOSED,
            ):
                req.status = RequestStatus.OVERDUE
                overdue.append(req)
        return overdue

    def generate_compliance_report(self) -> dict:
        """Art.21 cooperation status for QMS Art.17 documentation."""
        total = len(self.active_requests)
        overdue = len([r for r in self.active_requests if r.is_overdue()])
        responded = len(
            [r for r in self.active_requests if r.status == RequestStatus.RESPONDED]
        )
        return {
            "total_requests": total,
            "responded": responded,
            "overdue": overdue,
            "response_rate": responded / total if total > 0 else 1.0,
            "contact_point": {
                "name": self.contact_point_name,
                "email": self.contact_point_email,
            },
            "art_21_status": "COMPLIANT" if overdue == 0 else f"NON-COMPLIANT ({overdue} overdue)",
        }

Art.21 × Art.17 QMS Integration

Art.21 cooperation is not a standalone obligation — it must be integrated into the QMS maintained under Art.17. The QMS integration requirements for Art.21 include:

Procedure for handling NCA requests: The QMS must include a documented procedure specifying: who is notified when an Art.21 request arrives, who is responsible for coordinating the response, what documentation exists and where it is stored, what the escalation pathway is for complex or source-code requests, and what the sign-off process is before documentation is transmitted to an NCA.

Contact point maintenance: The QMS must include a process for maintaining and updating the Art.21(3) contact point designation — ensuring that changes in personnel or contact mechanisms are reflected in public disclosures and notified to NCAs.

Documentation readiness audit: The QMS should include a periodic (at minimum annual) audit of Art.21 readiness: are all Annex IV documentation categories complete and current? Is the technical documentation in a language accessible to relevant NCAs? Have all post-market monitoring findings been documented in a form that can be provided to an NCA?

Response timeline tracking: The QMS should include a tracking mechanism for active Art.21 requests, with automated alerts for approaching deadlines and escalation protocols for requests approaching the Art.93 penalty threshold.

Art.21 Compliance Checklist (20 Items)

Documentation Infrastructure (Art.21(1))

• Annex IV technical documentation complete for all deployed high-risk AI systems
• Documentation maintained in a language accessible to NCAs in all deployment Member States (or translation capacity in place)
• Art.18 10-year retention system operational for all Annex IV documentation categories
• Post-market monitoring records (Art.72) integrated into Art.21 documentation package
• Art.19 log retention architecture operational (6-month minimum + sector extensions)
• Art.20 corrective action records documented and retained
• EU Declaration of Conformity (Art.47) current and accessible
• QMS documentation under Art.17 maintained in Art.21-ready format

Contact Point (Art.21(3))

• Dedicated Art.21 contact point designated (named role or monitored channel)
• Contact point accessible during business hours in all deployment Member States
• Contact point information disclosed in EU Declaration of Conformity
• Escalation pathway from contact point to legal/technical/compliance documented
• Internal SLA for Art.21 request acknowledgement (≤2 business days) and response (≤10 days for standard requests)

Source Code Readiness (Art.21(2) / Art.74(10))

• Source code access protocol defined for Art.21(2) requests (secure environment, access controls)
• Legal review process in place for evaluating Art.21(2) reasoned requests
• Confidentiality protections under Art.74(10) documented and communicated to relevant NCAs
• Version-controlled source code repository with clear version-to-deployment mapping

Supply Chain and Multi-Regulatory Coordination

• Authorized representative agreement includes Art.21 coordination obligations (if applicable)
• Deployer agreements include Art.26(7) cooperation obligations
• Cross-regulation documentation architecture covers GDPR Art.58 + NIS2 Art.32 requests (where applicable)
• Art.93 penalty risk register includes Art.21 non-cooperation as a tracked risk with escalation trigger

Summary

Art.21 is the enforcement-facing counterpart to the compliance-facing obligations of Art.17-20. It transforms the documentation and operational infrastructure built under those obligations into a practically auditable compliance architecture. Three elements are operationally critical:

Documentation readiness at all times — not assembled after a request, but maintained under Art.18 for immediate production. A provider who needs to scramble to locate Annex IV documentation in response to an Art.21 request has failed to comply before the request arrived.

Language accessibility — the "easily understood" standard requires either proactive multi-language documentation for major Member State markets or on-demand translation capacity. Neither is free. Both are compliance costs.

Contact point continuity — the Art.21(3) contact point obligation is an ongoing operational obligation, not a one-time designation. Personnel changes, organisational restructuring, and contact mechanism changes must be managed proactively to maintain continuous NCA accessibility.

The source code access threshold under Art.21(2) and Art.74(10) is the element that most requires legal strategy. Source code is the most proprietary artifact in any technology provider's possession. Having a pre-designed protocol for responding to Art.21(2) requests — including secure access arrangements, confidentiality agreements, and legal review — is essential for providers who operate high-risk AI systems in categories where in-depth conformity assessment is likely (Annex III categories 1-8).

See Also: EU AI Act Art.20 Corrective Actions | EU AI Act Art.18 Documentation Keeping | EU AI Act Art.17 QMS Implementation