Managed Security Services: CISO Does Not Bear Sole Liability
Benedikt Langer
8 min. read In many organisations, the CISO is seen as the person who stands accountable for security. ...
Read Article
7 Min. reading time
37 percent of CIOs report having complete visibility over all AI tools in their organization. The rest make governance decisions about a system they don’t fully understand. Autonomous AI exacerbates this blind flight: When models make decisions independently, it’s often not just explainability that’s missing – the complete decision path is missing too.
Key Takeaways
- Shadow AI is the fundamental problem. AI tools operate in most companies outside of IT control – governance then comes into play too late structurally.
- Explainability and Audit Trail are not the same. XAI explains individual decisions but doesn’t document decision history. CIOs need both, but often only get one.
- EU AI Act sets the framework but doesn’t fill it. High-risk classification is the starting point, not the goal. The actual governance work happens after that.
Related:CIOs under pressure: 62 percent on AI governance / Logicalis CIO Report 2026: Only 37 percent have full visibility
The Question CIOs Ask Too Late
What is autonomous AI? An AI system is considered autonomous when it makes operational decisions or triggers actions without a human reviewing each individual case. The criterion is not the technology, but the process: Credit decisions, anomaly detection in production facilities, or personnel pre-selection can all run autonomously – whether they do depends on the architecture, not the model.
Autonomous AI makes decisions. That’s the point. Not: AI supports decisions – that’s the language of the pilot phase. The question “Do we have AI governance?” often comes one or two years after the question “Do we have autonomous AI?”. That’s the actual gap.
The EU AI Act categorizes systems into risk classes. High-risk applications – credit decisions, HR tools, critical infrastructure – need transparency documentation, regular testing, and human monitoring. This sounds like compliance. But it’s first an engineering question: Who has an overview of what is being decided – and who can trace it?
37 %
of CIOs report having complete visibility over all AI tools in their organization.
Source: Logicalis CIO Report 2026
Three Points Where Governance Structurally Fails
The first problem is Shadow AI. Employees use AI tools via browser extensions, SaaS accounts, and API accesses that never appear in IT procurement. This isn’t maliciousness, it’s efficiency. When these tools make decisions or provide decision-making bases, they don’t exist for governance purposes anyway.
Three questions clarify the risk: Are there AI-generated outputs that land in documented business processes without being marked as AI-generated? Are AI tool accesses billed through personal accounts to bypass IT procurement? Has IT discovered an AI tool in the last six months that they previously knew nothing about? One “yes” is enough: Then governance structurally kicks in too late.
The second problem is the confusion between Explainability and Audit-Trail. XAI methods like SHAP or LIME explain why a model made a decision in a specific case. This is useful, but not an Audit-Trail. An Audit-Trail documents: Which model, which version, which data, which timestamp, who used the decision? In practice, CIOs implement XAI and think Explainability is thereby solved.
Explainability is a feature. Traceability is a requirement. The two are confused too often in the governance context.
The third problem hits later, but harder: Vendor Lock-in with AI models. Anyone who has fine-tuned a foundation model from a cloud provider has proprietary weights on proprietary infrastructure. A change means data export, retraining, validation, re-certification. For high-risk systems, this typically takes six to eighteen months. This isn’t a problem in the pilot phase. It becomes a problem when a vendor changes terms or no longer meets compliance requirements.
What’s in the EU AI Act – and what’s not
The AI Act mandates for High-Risk Systems: technical documentation, risk management system, dataset documentation, logging, human oversight, accuracy metrics. This is the regulatory minimum framework.
What the AI Act doesn’t provide: a governance framework for the organization behind it. Who is internally responsible for a high-risk system? Which process decides whether a new AI tool is high-risk? What happens when a system is used for a new application that is subsequently classified as high-risk? Each organization must answer these questions itself. The AI Act is the entry gate, not the framework.
What Structurally Helps
- AI inventory with use-case classification, updated at least quarterly
- Clear ownership: one name per system, not a department
- Decision log of model versions with deployment date and use context
- Regular drift check against defined accuracy threshold
- Contract clauses for portability in high-risk vendor decisions
What Governance Theater Is
- AI ethics committee without decision-making authority over specific deployments
- Use-case approval without technical review of actual architecture
- XAI dashboard that is only opened when complaints arise
- AI policy without defined process for Shadow AI cases
- One-time risk assessments without specified repetition interval
Three Questions Before Every Autonomous AI Implementation
The first: What decisions does the system make – and with what consequences? Not: “What problem does it solve?” But: What happens when the system is wrong? Who bears the consequences – legally, operationally, reputationally?
The second: Who can stop the decision? Every autonomous system needs a defined escalation path. No path means: The decision happens until something serious happens.
The third: How long does it take to replace the system? Answer this question before the system is in use. After that, the answer is irrelevant.
Risk registers for autonomous AI are useful if someone actually looks at them – and if the questions in them point to specific systems, not abstract categories. The NIST AI Risk Management Framework provides a practical starting point here that goes beyond the AI Act minimum standard.
Frequently Asked Questions
What is considered an “autonomous” AI system from a governance perspective?
A system is considered autonomous when it makes decisions or triggers actions without a human reviewing each individual case. The criterion is not the technology, but the process: If an employee routinely adopts the system’s decision without checking its content, the system is operating de facto autonomously.
Which AI applications fall under the EU AI Act as high-risk?
Annex III of the AI Act lists eight areas: biometric identification, critical infrastructure, education, employment, essential services, law enforcement, border management, and justice. Within these areas, the specific use case matters. Most companies underestimate how many of their internal tools are potentially affected.
What is the difference between XAI and an audit trail?
XAI methods (SHAP, LIME, Counterfactuals) explain why a model made a particular decision in a specific case. An audit trail, on the other hand, documents the entire decision path: model version, input data, timestamp, person using it. Both are necessary – neither replaces the other. CIOs who only use XAI lack compliance-traceability.
How do I handle Shadow AI in my organization?
First: Inventory rather than sanction. Employees use AI tools for efficiency reasons, not to sabotage IT policies. A pragmatic approach combines regular self-disclosure processes (quarterly tool reporting), browser extension monitoring, and clear communication about which tools are approved. Zero-tolerance policies without alternatives drive Shadow AI deeper into invisibility.
What specific steps are recommended for establishing an AI governance framework?
Four steps in this order: (1) Create an AI inventory – all systems used, responsible parties, use cases. (2) Risk classification according to AI Act – which systems fall into high-risk categories? (3) Assign ownership – one name per system, not “the IT department”. (4) Establish review cycles – quarterly inventory update, annual risk assessment, immediate review when the system or its use changes.
More from the MBF Media Network
- cloudmagazin: Container Image Diet 2026 – Distroless, Wolfi, Chainguard for DACH DevOps
- SecurityToday: RSA Conference 2026 Wrap-up – DACH-CISO Tasks on PQC, Detection, Vendor Consolidation
- MyBusinessFuture: EUDI Wallet from Pilot Rollout 2026 – Identity Infrastructure for SMEs
Source Cover Image: Pexels / Vlada Karpovich