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.
High-risk AI systems under the EU AI Act must produce architectural documentation that satisfies AISDP Module 3. This module requires descriptions of system architecture, model type, algorithmic approach, key design choices, inputs and outputs, and human-machine interaction design. For machine learning systems, the scope extends to network architecture, feature engineering pipelines, and hyperparameter selection methodology. Effective documentation uses multiple diagram types at increasing levels of abstraction. System Context Diagrams establish the compliance boundary, Container Diagrams reveal technical building blocks, Component Diagrams expose internal structure where compensating controls reside, Data Flow Diagrams support Article 12 traceability, Deployment Diagrams satisfy hardware and software environment requirements, and Sequence Diagrams demonstrate human oversight workflows. Organisations must adopt consistent notation standards and version diagrams alongside code artefacts to prevent documentation drift. The AISDP should layer its architectural documentation so that governance leads, technical reviewers, and cybersecurity assessors each access the detail appropriate to their role. Interface specifications covering API contracts, data contracts, and human interface designs complete the documentation package.
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 standard. This threshold applies to every diagram, specification, and narrative within the architectural section of the 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 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.
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.
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 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 .
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.
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.
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.
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.
CTO of Standard Intelligence. Leads platform engineering and contributes to the PIG series technical content.
Record-Keeping
Technical Documentation Contents
