AI Accountability Starts With A Simple Question: Who Can Change The System?

Tolga Dinçer is the founder and CEO of DT Cloud.

I 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.​

Data Residency Is Necessary, But It Does Not Answer The Hardest Question​

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.