This is no longer a software question — it is an infrastructure question
Sovereign AI is the ability of a country or an organisation to build, run and govern AI according to its own rules, its own security requirements and its own values. In practice this means control over the whole intelligence supply chain: hardware, data and algorithms.
Governments now treat this not as a software purchase but as critical national infrastructure — in the same category as power and telecommunications. The European Commission moved to mobilise €20 billion for up to five AI gigafactories. Saudi Arabia elevated AI infrastructure to a strategic priority under Vision 2030.
Market size confirms it: the sovereign AI market, worth roughly $40 billion in 2025, is projected to reach $148 billion by 2032.
Being the contractor on work at that scale is not the same job as being a model reseller. It demands a different discipline: engineering discipline.
Being based in Türkiye is not a disadvantage here — it is the advantage
Gulf states and governments across emerging markets are explicitly seeking a non-US alternative. The reason is structural rather than ideological: they do not want their critical infrastructure tied to one country's companies and one country's export permissions.
Türkiye's position sits precisely in that gap. Neither the US nor China; adjacent to European regulation, connected to the Gulf culturally and commercially, and Turkish engineering firms are already a trusted party in Gulf infrastructure and defence procurement.
Language compounds it. Running Turkish, English and Arabic with one team, without a translation agency in the middle, looks like a small detail. It is not. A public specification is written in Arabic, the technical annex arrives in English, the fabricator speaks Turkish. Whoever holds all three at the same table wins the work.
Five commitments
These are contract clauses, not marketing lines. Each is measurable and each can be shown to have been breached.
1. Exit guarantee. On termination, within 30 days we hand over complete system documentation, all source code, model weights and an export of the data in open formats. We also run and record a 40-hour structured knowledge transfer. We write our own exit into our own contract.
2. Model independence. The architecture is never bound to a single model vendor. When a better or cheaper model appears, the institution can switch without rebuilding. Locking into one vendor is the most expensive mistake in this field.
3. Data does not cross the border. The deployment topology is declared separately for each jurisdiction. Where required the system runs fully air-gapped, with no outbound connection. In the Gulf, data residency is a redline rather than a preference, and we design for it.
4. Knowledge transfer is weekly. Not a handover ceremony at the end of the project, but auditable work that runs every week: documentation updates, code review with the institution's own staff, and a recorded architectural decision log. The goal is that the institution's team can run the system before we leave.
5. Provenance is shown. Every AI output the system produces can show what it was based on. In a system that produces institutional decisions, an unsourced answer is not acceptable.
Why we put this in writing
Because much of the industry does the opposite. Dependency is built in four ways, and all four are designed deliberately: technology lock-in (proprietary formats and closed interfaces), data lock-in (you cannot export your own data), contractual lock-in (long terms with penalties for leaving) and skillset lock-in (nobody but the vendor understands the system).
An institution ought to demand these things in its tender specification. We commit to them before they are demanded — because this is precisely the difference between us and a supplier who cannot offer them.
And it is not a sacrifice. Working with a supplier who is easy to leave is the lowest-risk option available to a buyer. Being the lowest-risk option is the shortest route to winning the work.
How to measure us
The questions to ask a supplier are well known. Ask us the same ones:
After the system is built, will your team be able to run it alone? What is the evidence — who was trained, in which week, on what?
If you stop working with us tomorrow, what is left in your hands? Source code, documentation, data, model weights — which of them, in what format, within how many days?
If the model we use shuts down or triples its price, what happens? Does the system keep running?
Where does your data physically sit and who can reach it? Is there a written topology?
A supplier who cannot answer these is not ready for institutional work, however good the presentation.
Five commitments — what they mean, how to verify them
| Commitment | What it means | How to verify |
|---|---|---|
| Exit guarantee | On termination, 30 days to full documentation, source code, model weights, data in open formats | Read the contract clause; the handover list is itemised |
| Model independence | Architecture not bound to one vendor; the model can be swapped | Ask to see the model layer isolated in the architecture diagram |
| Data stays in country | Deployment topology declared per jurisdiction; air-gapped possible | Ask for the written topology document and network diagram |
| Weekly knowledge transfer | Documentation, code review and architectural decision log every week | Ask for the weekly records; dates and attendees are written |
| Provenance | Every AI output can show what it was based on | Pick an answer at random in the system and ask for its source |