Dieser Artikel ist derzeit auf Englisch verfügbar.
What Data Science and AI Teams Need to Know About AI Governance (That Nobody Told Them)
Data scientists and ML engineers build the AI systems that governance frameworks regulate. Most have had no formal training in the governance obligations their work creates. This is the briefing they need.
Key Takeaways
Data scientists and ML engineers are the people whose work most directly determines whether an organisation's AI is governable — documentation choices, data handling practices, and architecture decisions made during development determine compliance feasibility years later.
The EU AI Act's technical documentation requirements are specific: data scientists building high-risk AI systems must document training data composition, model architecture, performance metrics across demographic groups, and known limitations. This documentation cannot be retrospectively created from a deployed production system.
Bias testing is a technical obligation, not a policy aspiration: organisations deploying AI in high-risk categories must be able to demonstrate, with specific metrics, that the system does not produce discriminatory disparate impacts.
Model cards and data sheets — structured documentation of model capabilities, limitations, and training data — are becoming a regulatory requirement, not just a responsible AI best practice.
The most important AI governance contribution a data science team can make is building governance into the development lifecycle: documentation, bias testing, and explainability from the start, not retrofitted after deployment.
"Nur zu Informationszwecken. Dieser Artikel stellt keine rechtliche, regulatorische, finanzielle oder professionelle Beratung dar. Konsultieren Sie einen qualifizierten Spezialisten für spezifische Beratung."
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.