Why this briefing exists
AI governance frameworks — the EU AI Act, NIST AI RMF, ISO 42001, sector-specific regulatory guidance — are written for risk managers, lawyers, and compliance professionals. They describe obligations in terms of policies, processes, and organisational structures. They do not explain, in terms that a data scientist or ML engineer would find immediately actionable, what the governance requirements mean for the technical work of building AI systems.
This creates a gap. The compliance obligations created by the EU AI Act are technical obligations as much as they are policy obligations: they require technical documentation that can only be created by people who understand the model; they require bias testing that requires specific technical methodologies; they require explainability mechanisms that must be built into the model architecture. A compliance team that understands the regulation but not the technical implementation cannot deliver compliant AI. A data science team that understands the technical implementation but not the regulatory requirements will build AI that cannot be governed.
Technical documentation: what you must create during development
The EU AI Act requires technical documentation for high-risk AI systems that is specific, comprehensive, and current. The documentation requirements cannot be satisfied by a summary produced after deployment — they require information that must be captured during development, including training data composition and quality assessment, model architecture and training process, performance evaluation methodology and results (including performance across demographic subgroups), known limitations and out-of-scope use cases, and cybersecurity measures.
The practical implication for data science teams: governance documentation must be part of the development workflow, not a separate compliance exercise conducted after deployment. Model cards — structured documentation of model purpose, capabilities, limitations, training data, and evaluation results — are the most practical implementation of this requirement. Making model card completion a step in the model deployment pipeline ensures that the documentation exists and is current.
Bias testing: from aspiration to technical obligation
Bias testing is not a new concept in responsible AI — it has been recommended best practice for years. What has changed is the regulatory context: organisations deploying high-risk AI must be able to demonstrate, with specific metrics, that their systems do not produce discriminatory disparate impacts. This is a technical obligation that requires specific methodology choices during model development and evaluation.
The specific bias testing methodology matters. Aggregate performance metrics — overall accuracy, precision, recall — are insufficient to demonstrate absence of discriminatory disparate impact. Disaggregated evaluation — measuring performance separately for different demographic groups and testing whether performance disparities are statistically significant — is what regulators will look for. The data science team must have access to demographic data for the evaluation dataset (which creates its own data governance obligations), and the evaluation results must be documented in a form that can be reviewed by compliance and legal teams.
