Module 3 of the AI System Description Package requires comprehensive architectural documentation covering system structure, model design, and human-machine interaction. The governing principle is that a qualified technical reviewer must be able to reconstruct the system's design rationale and operational behaviour from the documentation alone.
Module 3 of the AI System Description Package mandates a description of the system's architecture, model type, algorithmic approach, key design choices, inputs and outputs, and the human-machine interaction design.
Module 3 of the AI System Description Package mandates a description of the system's architecture, model type, algorithmic approach, key design choices, inputs and outputs, and the human-machine interaction design. Where the system uses machine learning, this scope extends to the network architecture, the feature engineering pipeline, hyperparameter selection methodology, and any ensemble or chaining of models.
The governing principle is sufficiency for external review: a qualified technical reviewer must be able to understand the system's structure and behaviour from the documentation alone. If a competent external reviewer cannot reconstruct the design rationale and operational behaviour, the documentation fails to meet the annex iv standard. This threshold applies to every diagram, specification, and narrative within the architectural section of the System Architecture Documentation package.
Architectural documentation for a high-risk AI system requires multiple diagram types, each serving a distinct purpose within the AISDP.
Architectural documentation for a high-risk AI system requires multiple diagram types, each serving a distinct purpose within the aisdp. Selecting the right combination ensures that every compliance audience can access the information relevant to their role.
The System Context Diagram (C4 Level 1) places the AI system as a single box within its broader environment. It shows deployer systems, data sources, human operators, and external service dependencies. This diagram answers the question "what does this system connect to?" and establishes the system boundary, a compliance-critical concept that defines what falls within scope of the AISDP and what remains external.
The Container Diagram (C4 Level 2) reveals the major technical building blocks inside the system boundary: the inference service, feature engineering pipeline, data ingestion API, monitoring dashboard, logging infrastructure, model registry, and supporting databases or message queues. Each container is labelled with its technology choice and primary responsibility. This diagram serves as the primary reference for understanding technical composition.
Component Diagrams (C4 Level 3) show the internal structure of sufficiently complex containers. For an inference service, this might include the model loading module, feature transformation module, prediction module, explanation generator, and post-processing module. These diagrams are particularly important for showing where compensating controls are implemented within each layer.
The Data Flow Diagram traces data from ingestion to output across the full system.
The Data Flow Diagram traces data from ingestion to output across the full system. For a high-risk AI system, it should show raw input data entering the system, validation and preprocessing steps, feature computation, model inference, post-processing and threshold application, explanation generation, output delivery to the human oversight interface, and logging at each stage. This diagram is essential for demonstrating Article 12 compliance with record-keeping requirements and for enabling traceability analysis.
The Deployment Diagram captures the physical or cloud infrastructure: the container orchestration platform, cloud provider and region, node types and resource allocations, network topology (VPC, subnets, security groups), and external service endpoints. This diagram supports Annex IV's requirement to describe the hardware and software environment and feeds directly into cybersecurity documentation under Module 9.
Sequence Diagrams document critical interaction patterns such as a complete inference request, an operator override, a model deployment event, or a break-glass activation. They show the step-by-step message flow between components, including timing and error handling paths. These diagrams are particularly valuable for demonstrating the human oversight workflow: what information is presented to the operator, in what order, and what happens when the operator accepts, modifies, or rejects the system's recommendation.
Organisations should adopt a consistent notation standard across all architectural diagrams.
Organisations should adopt a consistent notation standard across all architectural diagrams. The C4 model (Context, Containers, Components, Code) provides a practical framework for structuring diagrams at increasing levels of detail. UML remains widely understood and suits component and sequence diagrams. ArchiMate is appropriate for organisations aligning AI system architecture with enterprise architecture documentation.
Regardless of notation, the Technical SME must version diagrams alongside code and model artefacts. A diagram reflecting the architecture as designed six months ago rather than the architecture as deployed today constitutes a non-conformity. Tooling that generates diagrams from code or infrastructure definitions, such as Structurizr for C4 or Terraform graph for deployment diagrams, reduces the risk of documentation drift.
Different AISDP audiences require different levels of architectural detail, and the documentation must be structured accordingly.
Different AISDP audiences require different levels of architectural detail, and the documentation must be structured accordingly. Context and Container diagrams suit the AI Governance Lead, Legal and Regulatory Advisor, and notified body reviewers who need to understand system scope and composition without deep technical detail. Component and Sequence diagrams serve the Technical SME and engineering team, who must verify that documented architecture matches the implemented system.
The Deployment Diagram serves both the cybersecurity assessor verifying security architecture and the infrastructure team confirming that the documented environment matches reality. The AISDP should layer its architectural documentation at increasing levels of detail so each reader can access the level appropriate to their role without being overwhelmed by irrelevant information.
Architecture decisions made at design time also carry implications for eventual decommissioning. Systems designed with clear infrastructure-as-code definitions, isolated credential namespaces, and modular data storage are substantially easier to decommission in a controlled and auditable manner. The Technical SME should treat decommission-readiness as a non-functional requirement during architecture design.
Beyond diagrams, the AISDP must document interfaces between components, between the system and its deployers, and between the system and its operators.
Beyond diagrams, the AISDP must document interfaces between components, between the system and its deployers, and between the system and its operators. Interface specifications should include API contracts such as OpenAPI definitions for REST APIs, Protocol Buffer definitions for gRPC services, and JSON Schema for message formats.
Data contracts must define the schemas, types, and value range expectations for data flowing between components, following the contract testing approach. Human interface specifications are equally important: wireframes or screenshots of the operator interface, annotated to show the information presented, the actions available, and the workflow enforced. Together, these specifications ensure that every integration point is documented to the standard required by annex iv.
A qualified technical reviewer must be able to understand the system's structure and behaviour from the documentation alone. If a competent external reviewer cannot reconstruct design rationale and operational behaviour, the documentation is insufficient.
By versioning diagrams alongside code and model artefacts, and by using tooling that generates diagrams from code or infrastructure definitions, such as Structurizr for C4 or Terraform graph for deployment diagrams.
The system boundary defines what falls within scope of the AISDP and what is external. It is established by the System Context Diagram and is a compliance-critical concept that determines the reach of documentation obligations.
Module 3 mandates descriptions of system architecture, model type, algorithmic approach, key design choices, inputs and outputs, and human-machine interaction design, at a level sufficient for a qualified reviewer to understand the system's structure and behaviour.
System Context Diagrams (C4 Level 1), Container Diagrams (C4 Level 2), Component Diagrams (C4 Level 3), Data Flow Diagrams, Deployment Diagrams, and Sequence Diagrams, each serving different audiences and compliance purposes.
Data Flow Diagrams trace data from ingestion to output showing every processing stage, supporting Article 12 traceability. Deployment Diagrams capture infrastructure, network topology, and external endpoints, feeding into cybersecurity documentation.
The C4 model provides a practical framework for structuring diagrams at increasing detail levels. UML suits component and sequence diagrams. Diagrams must be versioned alongside code to prevent documentation drift.
Documentation should be layered so governance leads see Context and Container diagrams, technical teams see Component and Sequence diagrams, and cybersecurity assessors see Deployment diagrams, each at the appropriate level of detail.
API contracts (OpenAPI, Protocol Buffers, JSON Schema), data contracts defining schemas and value ranges, and human interface specifications with annotated wireframes showing operator workflows.
Record-Keeping
Technical Documentation Contents
EUR-Lex