AI Accountability Starts With A Simple Question: Who Can Change The System?
Tolga Dinçer is the founder and CEO of DT Cloud.
gettyI was in a discussion with a financial institution located in Türkiye evaluating a local cloud option for its AI and data platform. My first question had an easy answer: “Is the data in Türkiye?” Yes.
Then I asked: “Who holds root administrative privileges? Who controls identity policies and encryption keys? Who decides which updates reach production? If access to a global control plane disappears, can the organization continue operating and auditing locally?” The answers became less clear.
We knew where the data lived. What was harder to establish was who ultimately controlled the system—who could change its behavior, what operational data left the environment and whether the organization could continue independently if an external dependency became unavailable.
The architecture was not necessarily noncompliant. The problem was different: We had been using data location as shorthand for control, when the two are not the same. That conversation changed how I think about AI sovereignty and accountability.
For regulated industries, data residency matters. A local zone can address residency or proximity but not local control if identity, keys, updates or the control plane remain external. For an AI system, I increasingly ask a different question first: “Who can change its behavior?”
Even if the data stays where expected, a remote administrator can change access policies, encryption keys may depend on an external authority and model versions, guardrails, routing or logging can change. None of this requires the primary dataset to move. Data residency is therefore a prerequisite for sovereignty, not proof of it.
The same applies to open source: Access to source code can improve transparency and reduce dependency, but it does not guarantee operational sovereignty. If an organization cannot independently operate and sustain the system, a critical dependency remains. Sovereignty is not isolation. It is the ability to choose, operate through disruption and, when necessary, change providers.
By “control plane,” I do not simply mean an administration console. I mean the infrastructure’s authority layer: identity, permissions, encryption keys, orchestration, policies, updates, telemetry and the mechanisms that determine how workloads operate.
As AI execution becomes more distributed, a model may be trained in one environment, deployed in another and run inference at the edge. Organizations must balance regulation, latency, resilience and access to compute. Shared infrastructure can make large-scale GPU compute more economical, while sensitive data, real-time inference and continuity needs may make local execution preferable or necessary.
The answer is not to run every workload everywhere, but to place workloads according to policy. Sensitive data and latency-critical inference may stay local or at the edge; large-scale training may use approved shared capacity. Wherever execution happens, the organization still needs authority over identity, keys, policy and auditability.
The principle I favor: central standards, local execution and the ability to observe, decide and continue operating when connectivity or an external dependency is lost. Major AI governance frameworks point in the same direction. The NIST AI Risk Management Framework treats governance as a cross-cutting function throughout the AI life cycle. The EU AI Act similarly requires capabilities such as automatic logging and effective human oversight for high-risk systems.
For CEOs, CIOs and boards, I would make accountability more practical: Take one AI system that matters to the organization and test it against three questions.
Start by mapping authority. Who has root administrative access? Who controls identities and encryption keys? How is privileged vendor access granted? Who can deploy a new model, change a guardrail, redirect a workload or alter a policy?
Do not stop at the organizational chart or contract. Follow the technical chain of authority. The goal is not to eliminate every external dependency but to know where authority sits and which decisions remain under the organization’s control.
Imagine a regulator asks why a particular AI-assisted decision changed. Can the organization reconstruct the data, model version, policy, human approval and permissions that produced that outcome? It is not enough to know the system was available or that logs exist somewhere. The evidence chain should show what changed, who authorized it and what the system was operating with at that moment.
If the organization cannot reconstruct that history from trusted records, accountability becomes difficult to demonstrate when it matters most.
Finally, test continuity and exit rather than assuming them. What happens if connectivity to a central control plane is interrupted or a provider becomes unavailable? Can the organization isolate the environment safely? Do monitoring and governance continue? Can workloads, policies and records move to another environment if necessary?
Many organizations address these questions contractually, but they also need to test them technically. An exit right that exists only on paper is not an operational capability.
AI governance is often discussed with legal, risk and compliance teams. They belong in the conversation, but they cannot be the only ones in the room. Infrastructure, security and platform teams also need to be involved, because every governance commitment eventually reaches a technical enforcement point.
My recommendation is simple: Choose one production AI workload and trace it end to end. Do not begin with model performance or the number of GPUs behind it.
Begin with authority. Who can change it? How can you prove what changed? Can you continue operating when an external dependency disappears? If leadership cannot answer those three questions clearly, another policy document will not close the gap.
AI accountability depends on more than local execution. It depends on whether the organization retains the authority, evidence and operational independence to remain accountable for how it runs.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
