SovAIHub
ModulesSAI-120
SAI-120 table of contents
Overview2 min readContent reviewed

Introduction to sovereign AI architecture

Translate system purpose, sovereignty requirements, threats, and operating constraints into a vendor-neutral architecture method.

Last content review 2026-08-03Included in SAI-120

Architecture connects requirements to operation

A sovereign AI reference architecture is not a product diagram. It is a vendor-neutral method for assigning responsibilities, boundaries, interfaces, controls, evidence, and operational decisions across the complete AI system lifecycle.

The architecture should make it possible to explain what the system does, where control changes, who owns material decisions, how required properties are enforced, and how the implementation can be verified and changed.

Required inputs

Begin with:

  • Intended purpose, prohibited uses, users, affected parties, and decision impact.
  • Data classes, knowledge sources, models, tools, interfaces, and external dependencies.
  • Sovereignty control requirements across data, models, infrastructure, operations, and evidence.
  • Trust boundaries, flows, assets, attack surfaces, and prioritized threat scenarios.
  • Availability, latency, capacity, recovery, cost, portability, and skills constraints.

Do not choose components before these inputs are sufficiently understood.

Architecture principles

SAI-120 applies these principles:

  1. Purpose before platform: architecture follows the approved outcome and boundary.
  2. Explicit authority: every material decision and privileged action has an owner.
  3. Controlled interfaces: data, identity, artifacts, tools, and evidence cross boundaries through defined contracts and policy.
  4. Versioned behavior: models, prompts, retrieval, policy, tools, and configuration are identifiable and change-controlled.
  5. Evidence by design: claims and controls have planned verification evidence.
  6. Failure is architectural: rejected requests, unavailable dependencies, degraded models, rollback, and recovery have designed behavior.
  7. Portability is tested: exit and change paths exist at the levels the organization actually requires.
  8. Platform neutrality, explicit adapters: stable responsibilities remain independent of rapidly changing technology-specific implementation.

Quality attributes and trade-offs

Architecture must balance confidentiality, integrity, availability, safety, performance, cost, usability, observability, maintainability, portability, and assurance. Maximizing one can weaken another.

For example, strict disconnection can reduce remote exposure while increasing artifact, update, support, and operational complexity. Record such consequences in an architecture decision record.

SAI-120 outputs

The module produces a coherent view set, responsibility map, controlled-interface model, decision records, control and evidence placement, portability plan, and readiness backlog. These artifacts should be usable whether the implementation targets cloud, private cloud, on-premises, hybrid, edge, restricted, or air-gapped infrastructure.