Sovereign AI starts
with the data you control.

AI sovereignty is the ability to decide and enforce how AI is used in your organization: which data it can reach, which models run where, under which law, and who can change or stop it. It combines jurisdiction, control of data and keys, choice of models and providers, and the internal capacity to operate the systems. It is not a product you buy. It is a set of technical, contractual and organizational decisions that keep authority with you as your use of AI grows.

Sovereign cloud concerns the infrastructure: who operates it, under which jurisdiction, and who can access it. Sovereign data concerns the information itself: where it resides, who holds the encryption keys and which law applies to it. Sovereign AI adds the models, prompts, outputs and agents: which models you may use, where inference happens, what the systems can reach and who governs them. A sovereign cloud is useful but not sufficient: AI can still send data to external services unless the architecture and policies prevent it.

No. On-premise is one option among four: a private cloud in a European region, your own cloud account with keys you hold, your data center, or a fully air-gapped environment. The right level depends on the sensitivity of the data, your obligations, performance needs and the team available to operate it. Many organizations combine levels, keeping the most sensitive workloads closest. What matters is that the choice is deliberate, documented and reversible, rather than decided by default by a provider.

The EU AI Act sets obligations according to risk. Depending on the system and your role as provider or deployer, they can include risk management, data governance, human oversight, logging and transparency toward users. GDPR applies whenever personal data is processed, including in prompts and retrieved documents: lawful basis, minimization, security and, where the risk is high, an impact assessment. A governed architecture makes these obligations easier to evidence. SDEN does not provide legal advice; your counsel confirms how each obligation applies to you.

Yes, under policy. A governed gateway can route each request according to rules you define: sensitive content goes to private models inside your perimeter, while approved, lower-risk tasks may use external frontier models under contract. Redaction, logging and approval rules apply on every path. This hybrid routing keeps access to the best available capability without letting it become the default for confidential data. The routing rules are yours, documented, and can change as models, providers and regulation evolve.

A first inventory is typically targeted within about 30 days of the start of an engagement. It covers the AI systems in use, the data they reach and where requests go. The actual timing depends on the scope agreed, access to the relevant systems and the availability of your teams, and it is confirmed during scoping. The inventory is a starting point: it grows into a register as governance matures and new use cases are approved.

The subject of governance is AI systems and data flows, not individual people. The gateway can record which system was used, for which purpose and with which data classification, so that policies can be enforced and costs attributed. How much of that is linked to individuals, who can see it and for how long are policy choices your organization makes, in line with employment law and your works council or staff representatives where relevant. Transparency toward employees is part of the design, not an afterthought.

The aim is that you can run the system without us. Handover typically includes the architecture documentation, the configuration of the gateway and policies, the register of AI systems, runbooks, access arrangements, recovery procedures and escalation paths. Named internal owners are trained during delivery, not after it. Ownership, licenses, repository access and operating responsibilities are agreed contractually, distinguishing custom work, pre-existing materials and third-party components. Support after handover is optional and scoped separately.