AI Governance in Practice: What Companies Actually Need
AI governance has become a doubly overloaded term at DACH companies. On one side, there are 200-page frameworks nobody maintains. On the other, the term gets used as if a short email policy were enough. Both extremes miss the operational reality.
This guide describes what companies actually need before and after their first production AI system — pragmatic, documented, without consulting theatre. Drawn from real DACH company practice, not from a standards workshop.
Short answer
AI governance at companies needs five building blocks: a well-maintained AI system register, a short accountability and escalation matrix, a documented data protection and data classification concept, clear human-in-the-loop rules per application, and an audit log covering model and configuration changes. More paperwork is almost never more protection — well-maintained documentation beats complete but neglected documentation. Governance is an ongoing practice, not a project with an end date.
1. What companies should clarify before their first production AI system
These four questions must be answered before go-live. If not, governance runs behind operations — and gets more expensive and less certain the further behind it falls.
Who is accountable for this system?
One specifically named person for day-to-day operation, a second for strategic accountability. Not "IT" or "the team." With a name, a mandate, and an escalation path to management.
Which data flows where?
Data classification per input: what is personal data, what is a trade secret, what is public? Which legal basis applies under GDPR? Where does the model run — EU-sovereign, hybrid, on-premise? Is a data processing agreement in place with every provider?
Where does the human stay in the loop?
Which decisions may the system make on its own, where is human sign-off mandatory, where does a four-eyes principle apply? Especially important for decisions with legal effect on individuals (GDPR Art. 22).
What happens when something changes?
How is a model update approved? Who tests it, who decides, who communicates to the affected departments? Who documents the change? Closely tied to Managed AI Operations in Practice.
2. The five building blocks of pragmatic governance
More is rarely better. These five building blocks are enough for most enterprise applications. They are tightly interlinked — each one is useless without the others.
AI system register
Structured, maintainable, one entry per production AI system. Minimum fields: purpose, model, provider, data flows, DPA status, accountable owner, risk classification, last change.
Accountability and escalation matrix
Who is authorized to put a system into production, who monitors day-to-day operation, who decides on anomalies, who escalates to management. One page with names, roles, escalation paths — not an org-chart mural.
GDPR concept and data classification
Legal basis, data minimization, record of processing activities, a data processing agreement with every provider, data classification per data flow, a deletion and disclosure concept. Preparation for exactly what your data protection officer wanted to see anyway.
Documented per application
Which decisions the system may make on its own, where human sign-off is mandatory, where a four-eyes principle applies. Documentation of the human decision — protects customers, employees and the company.
Model and configuration changes
Every change to model version, prompt, escalation rule, confidence threshold or interface is logged with date, owner and rationale. In an audit or after an anomaly, traceability is mandatory — reconstructing it after the fact does not work in practice.
3. Where companies over-build — and where they under-build
Two extremes we see regularly in practice. Both cost money, both deliver little protection.
What's too much
- • A 200-page framework nobody opens
- • Five parallel audit paths with no clear hierarchy
- • "AI Act-compliant" stamps from vendors, with nothing behind them
- • Committee structures with no decision-making mandate
- • Documents that stop being accurate after 6 months
What's too little
- • "We're already handling that, we don't need a register"
- • No named accountability per system
- • No data classification of the inputs
- • Model updates with no testing and no documentation
- • No audit log, no rollback path
The right middle ground: a well-maintained set of compact documents that can be kept current in day-to-day operations — and that delivers answers an audit or a customer questionnaire can actually check.
4. Which reference frameworks governance should connect to
Governance doesn't develop in a vacuum. It should connect to the reference frameworks that matter for AI at DACH companies — so the documentation stays compatible once an audit, a corporate supplier questionnaire, or an insurance review comes along.
EU AI Act (EU Regulation 2024/1689)
Regulation (EU) 2024/1689. Practically relevant: Art. 9 (risk management), Art. 12 (logging), Art. 14 (human oversight), Art. 17 (quality management system), Art. 50 (transparency towards users). High-risk obligations phase in from August 2026.
ISO/IEC 42001 — AI Management System
Published in late 2023. Even without pursuing certification, its Plan-Do-Check-Act structure is a practical frame for an AI system register and accountability matrix.
GDPR and Art. 22
Where automated decisions have legal effect on individuals, GDPR Art. 22 applies. Cleanly identify this threshold in practice and build in four-eyes or human-in-the-loop steps wherever they make regulatory and operational sense.
NIS2 for affected companies
If your company falls within the scope of NIS2 (implemented in Austria via the NISG 2024), AI systems touch risk management, incident reporting and supply-chain obligations. Integrating with your existing ISMS makes more sense than running two parallel structures.
These reference frameworks don't replace a legal assessment — they are the structural basis on which such an assessment can build efficiently.
When formal governance is worth building — and when it isn't
- • An AI system is running in production with external impact
- • Customers or auditors are asking about your AI use
- • Several AI applications are being built in parallel
- • NIS2, ISO 27001 or comparable standards already apply
- • A high-risk system under the EU AI Act is plausible
- • There are only experiments, no production systems
- • A heavyweight consulting framework gets bought without a reason
- • The documentation demanded permanently exceeds your capacity to maintain it
- • External "compliance stamps" are promised with no substance behind them
- • Governance gets built disconnected from day-to-day operations
Frequently asked questions about AI governance in practice
From what point do we need AI governance?
What is the difference between governance and compliance?
We are not a high-risk provider under the EU AI Act — do we still need governance?
How many pages of documentation do we really need?
Who is operationally responsible for governance at an SME?
Related topics
AI governance →
The production pillar behind this guide: five governance levers, reference frameworks EU AI Act / ISO 42001 / GDPR / NIS2.
Managed AI operations: what comes after go-live →
Governance and operations belong together — model updates, drift response and the audit log become practical here.
On-premise or cloud AI? →
Data classification, EU hosting and hybrid architectures — the architecture decision that carries governance.
Glossary →
AI governance, GDPR, on-premise, drift — compact definitions.
Ready to build governance pragmatically?
In a free initial call, we assess the governance gaps in your current or planned AI systems — pragmatic, without consulting theatre, connected to the EU AI Act, GDPR and ISO 42001.
Request a free initial call