Model Selection Governance and Documentation

Model selection for a high-risk AI system is a compliance-significant decision that must follow a defined governance process. It should not be left to the discretion of individual data scientists. The aisdp prescribes a process where the Technical SME proposes a candidate, the team evaluates against documented criteria, and the results are reviewed by the AI Governance Lead before the selection decision is formally recorded with supporting analysis.

This governance record forms part of the AISDP evidence pack. It should be retrievable if a notified body or competent authority asks why a particular model architecture was chosen. Model Selection and Validation covers the broader framework within which this governance sits.

The Technical SME proposes candidate architectures, evaluates them against compliance criteria, and recommends a selection. The AI Governance Lead then reviews this recommendation against both the compliance criteria and the risk assessment findings. Legal counsel reviews the intellectual property and gpai provider implications separately.

For systems where the model choice has significant commercial implications, such as selecting a costly proprietary model over a less expensive open-source alternative, the Business Owner should also be consulted. The AI Governance Lead holds final approval authority for the selection decision.

The governance process must include a mechanism for challenging the model choice. If the Classification Reviewer, Legal and Regulatory Advisor, or any other stakeholder believes the selected model does not adequately satisfy the compliance criteria, they should be able to raise a formal objection.

The objection is documented, discussed, and resolved through the governance process. How the objection was resolved, including any changes to the choice or additional compensating controls, is recorded in the model selection rationale document. This challenge mechanism ensures that compliance concerns are surfaced and addressed before a selection becomes final.

The weighted decision matrix brings structure to the trade-off between performance and compliance. Model selection in a compliance-regulated context differs fundamentally from selection in a purely performance-driven context: the best-performing model is not necessarily the most compliant model.

Six criteria form the basis of the matrix: documentability, testability, auditability, bias detectability, maintainability, and determinism. Each criterion is scored on a three-level scale (strong, adequate, weak) for every candidate model. The scoring must be evidence-based, not impressionistic. "Documentability: strong" means a qualified reviewer could reproduce the training process from the documentation alone.

A deep neural network that achieves marginally higher accuracy than a gradient-boosted ensemble may be a poor compliance choice if it cannot produce the per-decision explanations required for Article 14 human oversight, or if its stochastic outputs complicate Article 12 logging requirements.

The matrix should be weighted according to the system's risk profile. For a high risk ai system in the employment domain, where Article 14 human oversight is paramount and affected persons have a right to explanation under Article 86, explainability-adjacent criteria (documentability, auditability, bias detectability) should carry higher weight. For a safety-critical system where Article 15 robustness is paramount, testability and determinism should carry higher weight. The weights must be documented and approved by the AI Governance Lead before the evaluation begins, to avoid post-hoc rationalisation of a preferred choice. explores the explainability requirements that influence this weighting.

Model cards are the standardised documentation format for capturing model selection outputs as compliance evidence. A model card, as defined by Mitchell et al. (2019), records the model's intended use, its performance evaluation results including disaggregated metrics across subgroups, its known limitations, its training data summary, and its ethical considerations.

Google's Model Cards Toolkit automates generating model cards from evaluation metrics, producing a structured HTML or Markdown document that can be stored as a Module 3 evidence artefact. Hugging Face's Model Card metadata schema extends this further with machine-readable fields that can be queried programmatically. Both formats support the evidence requirements of the AISDP.

AISDP Module 3 requires describing "the key design choices and their rationale," making the model selection rationale document a core component. The document should cover the following areas:

• The system's functional requirements (what the model must do).
• The compliance requirements derived from the risk assessment, including minimum explainability, testability, and auditability standards.
• The candidate architectures evaluated, including traditional heuristic and statistical approaches.
• The evaluation methodology: datasets used, metrics computed, and how compliance criteria were scored.
• The evaluation results, presented as a comparison table showing each candidate's performance, compliance criterion scores, IP risk profile, and cost.
• The recommended selection with the rationale, including trade-offs accepted.
• The governance approval record: who reviewed, who approved, and any objections raised and how they were resolved.

This documentation serves two audiences. The Technical SME reviews it for technical soundness. The Classification Reviewer and any notified body review it for evidence that the organisation made a considered, risk-aware choice and did not simply default to the most complex available model.

The selection rationale must cover every learned component in the system architecture, not only the primary decision-making model. Many high-risk AI systems incorporate multiple model components: embedding models used for retrieval or similarity matching, re-ranking models that refine search results, classification heads for routing or filtering, and auxiliary models used for monitoring or safety evaluation. Each component influences the system's outputs and carries its own risk profile.

A primary decision model warrants a full evaluation against all six compliance criteria. An embedding model used in a RAG pipeline warrants a focused assessment covering provenance, linguistic performance across the deployment languages, known biases in the representation space, and the version pinning strategy. An auxiliary safety classifier warrants documentation of its accuracy, its failure modes, and the consequences of those failures for the primary system's compliance profile.

The AI System Assessor verifies that the Model Selection Record is complete with respect to the system's architecture diagram. Any model component visible in the architecture that lacks a corresponding entry in the Model Selection Record is a documentation gap. Documentation and Evidence Management provides further guidance on structuring compliance documentation across multiple components.