Who Controls the Intelligence? An Enterprise Architecture Guide to AI Sovereignty — The Sovereignty Stack, Part 3
The Sovereignty Stack // Part 3 AI Sovereignty — When Enterprise Intelligence Becomes a Strategic Dependency
Most organisations believe their AI strategy begins with choosing a model. Which one performs best on their benchmarks. Which provider offers the most competitive pricing. Which API integrates most cleanly into existing systems.
Those are reasonable questions. They are also the wrong place to start.
The more consequential question — the one most architecture governance processes have not yet asked — is a different one entirely.
Because the next generation of vendor lock-in is unlikely to be infrastructure. It will be something harder to see and significantly harder to migrate. It will be enterprise intelligence itself — and understanding what that means is what this article is about.
01 — Why AI Is Different From Every Platform Shift That Preceded It
Cloud computing changed where software runs. Virtualisation changed how infrastructure is provisioned. SaaS changed how applications are delivered. Each of these was a significant architectural transition, and each introduced new dependencies that organisations learned — sometimes painfully — to govern.
Artificial Intelligence introduces a dependency of a different character altogether.
Software automates work. AI increasingly influences judgement. It shapes how organisations analyse information, prioritise options, surface recommendations, and — in an expanding set of use cases — execute decisions. That is not a subtle distinction. For decades, Enterprise Architecture has governed what technology does. AI introduces the question of how the organisation thinks.
Most organisations are still approaching AI as though it were another software capability evaluation. The procurement questions dominate: which model, which provider, which price point. Enterprise Architecture needs to begin somewhere else — with the question of who ultimately controls the intelligence increasingly shaping organisational decisions.
02 — AI Doesn't Replace Enterprise Architecture. It Amplifies It.
There is a tendency to describe AI as a new layer sitting on top of existing architecture. That framing is incomplete in an important way.
AI does not replace Enterprise Architecture. It increases the cost of getting architecture wrong.
Every AI capability inherits the governance maturity of the architecture beneath it. Without trusted, well-governed data, AI produces unreliable outputs. Without governed identities, AI agents cannot safely act on behalf of the organisation. Without resilient platforms, AI capabilities cannot be sustained. Without interoperable standards, AI becomes difficult to migrate between providers. Without transparent supply chains, the AI itself cannot be independently trusted.
The sovereignty of your AI can therefore never exceed the sovereignty of the enterprise architecture supporting it. Organisations that have not resolved their data governance, identity, and platform sovereignty challenges before deploying AI at scale will find those gaps amplified — not papered over — by AI adoption.
03 — The Real Lock-In Is Not the Model
Enterprise Architects who lived through the early years of cloud adoption learned a hard lesson: migration becomes most difficult precisely when a platform has been most successful. The greater the business value, the deeper the dependency, and the more painful the exit.
AI follows exactly the same pattern — but the dependency that matters most is not the one most organisations are tracking.
Foundation models will continue to evolve. Providers will change. New capabilities will emerge and existing ones will be commoditised. The model itself is, in an important sense, the most portable part of an AI architecture.
The harder dependency is context.
- Prompt libraries developed and refined over years of operational use
- Retrieval-Augmented Generation repositories encoding organisational knowledge
- Evaluation datasets that define what "good" looks like for your specific domain
- Knowledge graphs built from internal processes and expertise
- Agent workflows encoding business logic and decision sequences
- Fine-tuned organisational behaviours that reflect institutional reasoning
Individually, each of these looks like an implementation detail. Collectively, they become something else entirely — Enterprise Intelligence. This context layer gradually evolves into a new class of enterprise asset, and potentially the most difficult capability to migrate when provider relationships change.
04 — Five Questions Every Enterprise Architect Should Ask
Most AI discussions begin with capability. Enterprise Architecture should begin with dependency. Before any significant AI initiative proceeds, five questions deserve honest answers.
Can We Leave?
If today's AI platform became unavailable tomorrow, what organisational capability would disappear with it? Could prompts, evaluation datasets, and RAG repositories move to another provider? Or would years of accumulated intelligence need to be rebuilt from scratch? This is the exit question — and it should be asked at the architecture stage, not after years of investment.
Who Controls the Intelligence?
Who ultimately governs the models influencing your organisational decisions? Can today's AI capability realistically be replaced if strategic priorities change, or has the organisation become dependent on one provider's models, APIs, and commercial roadmap in ways that were never formally assessed or approved?
Who Controls the Context?
Owning the model matters. Owning the context increasingly matters more. Can prompt libraries, RAG repositories, evaluation datasets, and organisational knowledge move between providers without rebuilding business capability? If the answer is unclear, the organisation has an undocumented dependency on assets it may not formally own.
Who Controls Trust?
Every AI capability ultimately operates through identity — users, machine identities, service accounts, APIs, and AI agents. If those identities are not governed under least-privilege principles with proper audit trails, the intelligence operating through them cannot be effectively governed either. Trust governance is the prerequisite for AI governance.
Who Controls Evolution?
Traditional software evolves through planned releases on a schedule the organisation can anticipate and test against. Foundation models evolve continuously and independently. Capabilities improve, reasoning changes, safety mechanisms are updated, commercial priorities shift, and export controls can emerge without notice. Organisations that depend on AI for significant decisions are increasingly dependent on intelligence that evolves outside their own release governance. Very few architecture review boards currently assess that dependency explicitly.
05 — Enterprise Intelligence as a New Asset Class
For decades, Enterprise Architecture has governed a defined set of asset categories: business processes, applications, data, and technology infrastructure. AI introduces a category that does not fit cleanly into any of these.
| Traditional EA Asset | AI-Era Equivalent | Governance Implication |
|---|---|---|
| Application logic | Prompt engineering standards | Requires versioning, ownership, and portability standards |
| Reference data | Evaluation datasets | Requires lifecycle management and provider independence |
| Knowledge management systems | RAG repositories and knowledge graphs | Requires data residency and portability governance |
| Business process models | Agent workflows | Requires authorisation frameworks and audit trails |
| Domain expertise | Domain-specific fine-tuned reasoning | Requires IP protection and vendor independence assessment |
These are no longer implementation details managed by delivery teams. They are strategic enterprise assets that require the same governance, lifecycle management, portability planning, and architectural oversight applied to any other critical organisational capability.
06 — The Saudi Arabia and NCA Context
The five questions above apply to any jurisdiction. In Saudi Arabia, they carry specific regulatory weight that organisations in the government and regulated private sector cannot treat as theoretical.
The NCA's Cloud Cybersecurity Controls (CCC) already establishes obligations around data residency, cloud provider assurance, and shared-responsibility governance for cloud-hosted workloads. As AI capabilities are increasingly delivered through cloud platforms — often by hyperscalers operating under international commercial terms — the question of where AI processing occurs, where context data resides, and who can access it becomes a direct CCC compliance question, not just an architectural preference.
The Data Cybersecurity Controls (DCC) extend this further: where organisational knowledge encoded in RAG repositories and evaluation datasets constitutes personal or sensitive data under Saudi classification, those assets carry explicit handling, residency, and lifecycle obligations. Prompt libraries trained on internal communications or business processes may fall within scope depending on their content.
Beyond the NCA frameworks, Saudi Arabia's PDPL establishes data subject rights and data controller obligations that extend into AI contexts — particularly where AI systems make or influence decisions affecting individuals. The intersection of AI governance, data sovereignty, and regulatory compliance is no longer a future consideration for Vision 2030 programmes. It is a present architectural requirement.
Organisations deploying AI in the Kingdom should be conducting AI sovereignty assessments alongside their NCA framework scoping exercises — not as separate workstreams, but as integrated architectural governance.
07 — A Practical Assessment Framework
When reviewing AI initiatives, Enterprise Architects and GRC teams should be working through a structured set of questions across three dimensions. The list below is not exhaustive, but it represents the questions most commonly absent from current AI governance processes.
| Dimension | Question | What a Good Answer Looks Like |
|---|---|---|
| Intelligence & Autonomy | Which business decisions are now influenced or delegated to AI? | A documented decision inventory with human-in-the-loop thresholds defined and approved at the appropriate governance level |
| Intelligence & Autonomy | Could organisational knowledge move without rebuilding business capability? | Context assets are documented, owned, stored in provider-agnostic formats, and subject to portability testing |
| Identity & Trust | Are AI agents operating under governed machine identities? | Every AI agent has a formal identity, least-privilege access, and is subject to the same IAM governance as human users |
| Identity & Trust | Can AI recommendations be independently explained, audited, and challenged? | Explainability requirements are defined at the architecture stage; audit logs exist for AI-influenced decisions |
| Strategic Choice | If today's AI provider became unavailable, what would continue working? | An exit scenario has been formally assessed; critical capabilities have documented alternatives or migration paths |
08 — The Architecture Takeaway
The organisations that will navigate the AI era most effectively are not necessarily those that adopt AI earliest or most broadly. They are the organisations that understand their dependencies clearly — the intelligence, the context, the trust architecture, the exit options — and govern those dependencies with the same rigour applied to any other critical enterprise asset.
AI does not sit outside Enterprise Architecture. It magnifies every architectural decision beneath it. The quality of your AI sovereignty is, ultimately, a reflection of the quality of the architecture it sits on.
Next in the Series — Part 4: One question has surfaced repeatedly in the discussions following Parts 1, 2, and 3: does interoperability belong under Platform Sovereignty or Standards Sovereignty? The answer is more nuanced than it first appears. Part 4 explores why organisations often confuse the ability to replace technology with the ability to preserve capability — and why platforms, infrastructure, open standards, and supply chains together determine whether strategic choice truly exists.
Comments
Post a Comment