Sovereign Generative AI for the Public Sector: Lessons from DILA

What does sovereign generative AI mean for a public body?

In a public-service context, sovereign means the institution stays in control of where its data lives, who can access it, how the system is secured and how every answer can be traced back to a source. It is a statement about control and accountability, not about nationality of technology.

At DILA, which belongs to the services of the Prime Minister, these requirements shaped the platform from the first day rather than being added at the end.

Why is generative AI harder to deploy in the public sector?

Public institutions need to deploy generative AI while meeting strict requirements for data sovereignty, security, traceability and regulatory compliance. Those requirements apply to every application, which is exactly where the trouble starts.

When each application is built on its own, document ingestion, embeddings, retrieval, orchestration, security controls, evaluation and observability are rebuilt for every project. The duplication is expensive, but the larger risk is inconsistency: each copy of the security layer is a separate thing to audit, and each project ends up with its own idea of what good quality means.

This is why I argue that the question for a public body is rarely which model to choose. It is how to avoid solving the same compliance problem a fifth time.

There is also a human cost. Teams that rebuild the same plumbing for every project spend their time on infrastructure instead of on the service the citizen will actually use, and the people who must approve each system face a different design every time.

What was the challenge DILA set out to solve?

The objective was to move beyond isolated proofs of concept and to establish a sovereign, reusable AI foundation capable of accelerating production-ready RAG and agentic applications. RAG, retrieval-augmented generation, means the model answers from the institution’s own documents rather than from memory alone.

My contribution was to lead a team of 9 people on the product and delivery approach of the platform, with a strong focus on modular architecture, component reuse and scalable AI delivery. I describe my own role only as far as the case study does: the platform is the work of the whole team.

How does a platform approach change the way AI is delivered?

The shift was from building each application independently to assembling standardised, governed AI components. The approach combined several elements, each of which answers a duplicated cost named above.

• A sovereign architecture compatible with strict hosting, security and data-sovereignty requirements, including SecNumCloud considerations.
• Reusable building blocks: document ingestion, chunking, embeddings, hybrid retrieval, reranking, prompt management and LLM integration.
• Agentic orchestration: reusable workflows for tool calling, multi-step reasoning and agent-based task execution.
• A RAG factory: document-based assistants created from configurable retrieval pipelines rather than project-specific implementations.
• An evaluation framework that measures RAG quality systematically.
• Governance by design: access management, traceability, auditability and sovereignty requirements embedded in the components themselves.
• Repeatable implementation patterns that cut development effort and improve consistency across projects.

How do sovereignty requirements translate into platform features?

The table below is my reading of how each requirement named in the case maps to a platform behaviour. It is a framing for discussion, not a description of the internal design, which I do not detail here.

How was the quality of the answers evaluated?

A public body cannot ship an assistant on the strength of a good demonstration. The platform introduced systematic RAG quality measurements, which gave every application the same yardstick.

Four measures are worth knowing, because they are the ones people search for. Faithfulness asks whether the answer is supported by the retrieved documents. Answer relevancy asks whether it addresses the question. Context precision asks whether the retrieved passages were the right ones, and context recall asks whether the right passages were found at all.

The reported scores were 0.94 for faithfulness, 0.91 for answer relevancy, 0.89 for context precision and 0.92 for context recall. Evaluation covered 85% of priority RAG scenarios. I give these figures as reported for that platform, not as a benchmark for other contexts.

What matters for a public service is less any single score than the discipline behind it. When the same four measures are applied to every assistant, a change can be judged as an improvement or a regression, and a reviewer can ask for evidence instead of trusting a presentation.

What did the platform change in practice?

New RAG applications could reuse shared document processing, retrieval, evaluation and security capabilities, and agentic applications could build on existing orchestration patterns and tool integrations. This reduced duplicated engineering work, accelerated experimentation and established a more consistent approach to quality and governance. The reported results:

• Content creation became 70% faster.
• RAG application delivery time fell by 60%, from 10 weeks to 4.
• 75% of common technical capabilities were reused.
• Cost per AI request fell by 30%, through pipeline optimisation and reuse.
• Implementation time for prototyping agentic workflows fell by 50%.

What can other public bodies learn from DILA?

The case page states the lesson plainly: the value of an enterprise AI platform is not only the intelligence it provides, but how quickly and reliably it lets an organisation build its next application. These are the points I would carry to another public body, and none of them depends on a particular model or supplier.

• Treat RAG pipelines, agentic workflows, evaluation and governance as platform capabilities, not as features of one project.
• Write sovereignty and security requirements into the reusable components, so compliance is inherited rather than repeated.
• Agree the quality measures before the first release, and keep the same measures for every application.
• Measure the platform by how quickly the next application can be built, not by how impressive the first one looks.
• Keep the team small and the components shared: a team of 9 can only serve several applications if they do not each start from scratch.