The EU AI Act requires organisations deploying high-risk AI systems to demonstrate that model selection decisions account for regulatory obligations. Article 9, Article 10, Article 12, Article 15, and Annex IV each impose requirements that directly affect which model architectures are suitable for compliant deployment.
Organisations must assess candidate models against six compliance criteria alongside traditional performance metrics: documentability, testability, auditability, bias detectability, maintainability, and determinism.
Organisations must assess candidate models against six compliance criteria alongside traditional performance metrics: documentability, testability, auditability, bias detectability, maintainability, and determinism. The Technical SME evaluates each criterion and scores it on a three-level scale of strong, adequate, or weak. The ai system assessor records these scores in the model selection rationale document, creating an auditable record of why a particular model was chosen. This structured evaluation ensures that compliance considerations inform the selection decision from the outset, rather than being retrofitted after a model has already been integrated into the system. Model Selection and Due Diligence covers the broader due diligence framework within which these criteria sit.
Each criterion maps to a specific regulatory obligation under the EU AI Act. Documentability relates to Annex IV requirements for design specifications. Testability supports the validated risk controls required by Article 9. Auditability addresses the record-keeping obligations of Article 12. Bias detectability connects to the bias assessment requirements of Article 10. Maintainability underpins the ongoing resilience mandate of Article 15. Determinism supports reproducibility during conformity assessment.
Documentability asks whether the model's architecture, hyperparameters, and decision process can be described precisely enough to satisfy Annex IV, Section 2.
Documentability asks whether the model's architecture, hyperparameters, and decision process can be described precisely enough to satisfy Annex IV, Section 2. The assessment determines whether a qualified reviewer could reproduce the training process from the documentation alone. The Technical SME reviews the model architecture and determines whether its structure can be expressed in a technical specification document.
Different architectures score very differently on this criterion. A logistic regression model has strong documentability because every parameter is a named coefficient with a direct interpretation. A transformer with billions of parameters has weaker documentability: the architecture itself can be described, but the learned representations cannot be enumerated at the parameter level. Where documentation gaps exist, the assessment should identify compensating controls that would be needed, such as detailed behavioural characterisation in lieu of parameter-level documentation. The ai system description package must capture whatever level of documentation the model architecture supports.
Testability determines whether the model architecture supports the testing required by Article 15, covering accuracy, robustness, and fairness evaluation.
Testability determines whether the model architecture supports the testing required by Article 15, covering accuracy, robustness, and fairness evaluation. The assessment establishes whether standard evaluation methodologies exist for the candidate architecture and whether those methodologies are sufficient for the system's risk profile. Risk Assessment Fundamentals provides the framework for determining what level of testing the risk profile demands.
Architecture type has a significant effect on testing complexity. Some architectures, such as decision trees and linear models, produce deterministic outputs that simplify testing because the same input always yields the same output. Others, including large language models and diffusion models, produce stochastic outputs that require statistical testing frameworks to evaluate meaningfully. The assessment should specify the testing methodology that would be needed for the candidate architecture and estimate the testing effort involved, so that the organisation can factor testing costs into the selection decision.
Auditability assesses whether the model produces outputs that can be logged, traced, and attributed in accordance with Article 12's record-keeping requirements.
Auditability assesses whether the model produces outputs that can be logged, traced, and attributed in accordance with Article 12's record-keeping requirements. The key question is whether individual decisions can be reconstructed from the logs after the fact.
Models that require only the input and the model version for output reconstruction are strongly auditable, because a third party can reproduce any given decision with minimal context. Models where the output depends on runtime conditions present greater challenges. When session state, conversation history, or retrieval-augmented generation context influences the output, more sophisticated logging is required. The assessment must specify exactly what the system needs to log to enable full decision reconstruction, and this logging specification feeds directly into the system's technical documentation and monitoring design. Logging and Traceability addresses the detailed implementation of these logging requirements.
Bias detectability measures whether fairness metrics can be computed at the subgroup level and whether the model can be interrogated for proxy variable effects.
Bias detectability measures whether fairness metrics can be computed at the subgroup level and whether the model can be interrogated for proxy variable effects. The assessment determines whether the candidate architecture supports feature attribution methods, such as SHAP, LIME, or integrated gradients, that can identify when ostensibly neutral features act as proxies for protected characteristics.
The model's output format matters for fairness analysis. Models that produce calibrated probability scores are more amenable to disaggregated fairness evaluation across all protected characteristic subgroups. Models that produce only ranked outputs or categorical labels provide less material for subgroup analysis. The Technical SME must determine whether the architecture supports fairness-aware training or post-hoc calibration as remediation options if bias is detected during evaluation or post-market monitoring.
Maintainability evaluates whether the model can be retrained, fine-tuned, or recalibrated in response to post-market monitoring findings without triggering a substantial modification assessment under Article 15.
Maintainability evaluates whether the model can be retrained, fine-tuned, or recalibrated in response to post-market monitoring findings without triggering a substantial modification assessment under Article 15. The criterion also examines whether the model's behaviour remains stable across minor updates.
Architecture type strongly influences maintainability scoring. Some architectures, such as gradient-boosted trees and logistic regression, produce stable and predictable changes when retrained on augmented data. The impact of additional training data can be estimated in advance, making incremental maintenance straightforward. Deep neural networks, by contrast, can exhibit large behavioural shifts from small data changes, making incremental maintenance more difficult and increasing the risk that a routine update triggers a substantial modification assessment. The assessment evaluates this sensitivity and documents the expected maintenance approach in the model selection rationale.
Determinism assesses whether the model produces the same output consistently for a given input.
Determinism assesses whether the model produces the same output consistently for a given input. Deterministic models simplify compliance because reproducibility supports conformity assessment: any given decision can be verified by re-running the input through the same model version.
Stochastic models require additional controls to achieve sufficient reproducibility for compliance purposes. These controls include temperature clamping to reduce output variability, seed fixing to enable reproducibility during testing, and output logging to maintain traceability when exact reproduction is not possible. The assessment must determine whether the candidate architecture is inherently deterministic or inherently stochastic. For stochastic architectures, the Technical SME specifies the controls needed and assesses the performance cost of imposing those controls, since constraints like temperature clamping may degrade the model's effectiveness at its intended task. Repeated inference testing validates whether the chosen controls achieve acceptable reproducibility levels.
Logistic regression models have strong documentability because every parameter is a named coefficient. Transformer models with billions of parameters have weaker documentability: the architecture can be described, but learned representations cannot be enumerated. Documentation gaps require compensating measures such as detailed behavioural characterisation.
Stochastic models like large language models produce different outputs for the same input across executions. This complicates reproducibility for conformity assessment. Controls such as temperature clamping, seed fixing, and output logging are needed, but these may degrade the model's effectiveness at its intended task.
Article 15 requires ongoing resilience, meaning models must be retrained or recalibrated in response to post-market monitoring findings. Some architectures like gradient-boosted trees produce stable, predictable changes when retrained, while deep neural networks can exhibit large behavioural shifts that risk triggering a substantial modification assessment.
Organisations assess candidate models against six compliance criteria (documentability, testability, auditability, bias detectability, maintainability, determinism) using a three-level scoring scale, with results recorded in the model selection rationale document.
Documentability requires that a model's architecture, hyperparameters, and decision process can be described precisely enough to satisfy Annex IV, Section 2, enabling a qualified reviewer to reproduce the training process from documentation alone.
Testability assessment determines whether standard evaluation methodologies exist for the candidate architecture and whether they suffice for the system's risk profile, covering accuracy, robustness, and fairness evaluation as required by Article 15.
Auditability requires that model outputs can be logged, traced, and attributed per Article 12, with the assessment specifying what must be logged to enable full decision reconstruction.
Bias detectability assessment determines whether the architecture supports feature attribution methods and disaggregated fairness evaluation across protected characteristic subgroups, as required by Article 10.
Deterministic models simplify compliance through reproducibility, while stochastic models require additional controls such as temperature clamping, seed fixing, and output logging to achieve sufficient reproducibility for conformity assessment.
Data and Data Governance
Record-Keeping
EUR-LexAccuracy, Robustness, Cybersecurity
EUR-LexTechnical Documentation Contents
EUR-Lex