1. Why are sovereignty and regulatory considerations becoming central in AI projects today?
Faustine Cachera: The EU AI Act has fundamentally shifted the conversation. It forces organisations to address key questions at design stage: what type of system they are building, what data they use, whether they can lawfully use it, who bears responsibility across the value chain, and where processing takes place.
Sovereignty matters because it gives organisations control over data location, applicable legal framework, access rights, and allocation of responsibilities. For many organisations, this has become a precondition for scaling safely.
Bénédicte d’Allard: From a regulatory and operational standpoint, sovereignty has become a practical concern. Boards and control functions increasingly expect to understand where the system runs, what data it relies on, who can access it, and how decisions and incidents are escalated.
In regulated sectors such as finance and healthcare, these expectations already apply. If these questions are left unanswered, organisations often realise too late that their operating model is incompatible with their regulatory obligations.
Anthony Necker: Sovereignty has become a practical necessity because AI now supports critical business functions. Organisations must know where data is processed, under which jurisdiction, and retain control over their models. Without this, they face vendor lock-in, limited reversibility, and exposure to external decisions, including potential loss of access. Sovereign infrastructure mitigates these risks by ensuring data locality, control over models, and alignment between technical architecture and regulatory requirements.
2. What are the main mistakes you observe in AI projects that do not address these aspects from the outset?
Faustine Cachera: The most frequent mistake is to focus on the use case and defer the legal mapping. Teams begin testing models, connect datasets or onboard providers, and only later assess whether they have a valid legal foundation: the lawfulness and scope of permissible data use, intellectual property rights over inputs and outputs, regulatory compliance obligations, or the allocation of responsibilities across the contractual chain.
Documentation is another recurring gap. Organisations may have a promising pilot but no clear record of purpose, training or fine-tuning logic, human oversight, or incident handling. This becomes a real obstacle when scaling.
Bénédicte d’Allard: Another common failure point is ownership. Projects are launched as innovation initiatives, but no one defines who is accountable for model performance, who validates the data perimeter, who ensures ongoing compliance with applicable regulatory requirements, or who monitors the system once it is live.
Underestimating infrastructure choices is also a recurring mistake. If an organisation cannot clearly explain where processing occurs, how environments are structured, or how access is controlled, the project will not withstand governance review.
3. In practical terms, how is implementation structured from an infrastructure and technological sovereignty perspective?
Anthony Necker: In practice, sovereignty relies on three elements: control over data, control over models, and architectural flexibility. With MeluXina, data is processed locally within a trusted and stable jurisdiction. With platforms like Flinky, organisations can deploy and retain their own models, avoiding dependency on black-box providers. This approach complements hyperscalers, enabling hybrid architectures where sensitive workloads remain sovereign, while standard workloads leverage the cloud.
4. If you had to give one key recommendation to organisations moving from pilots to large-scale deployment, what would it be?
Faustine Cachera: Before scaling, organisations should be able to clearly document four elements: the purpose of the system and its risk profile; the legal and regulatory basis underpinning data use and deployment; the responsibility chain across providers; and the human oversight and escalation model. Without these, scale will expose weaknesses that pilots conceal.
Bénédicte d’Allard: Make scale a controlled operating model, not an IT rollout. Define governance early: who approves the use case, who owns the model in production, what controls apply to data, access, performance and incidents, and how the organisation will evidence compliance over time.
Anthony Necker: Treat sovereignty and architecture as foundational, not as an afterthought. Start by classifying data and workloads to define the required level of control, then design the target architecture accordingly. Prioritise real production use cases over sandbox pilots and ensure infrastructure choices allow reversibility and scalability from day one. The ability to replicate, migrate, and govern AI systems over time is what ultimately differentiates successful deployments from stalled initiatives.
