Use case · Secure data for AI pilots
Your legal team needs months to approve one data extract, and once it leaves, it cannot be called back. Here a start-up pilots its model on data from three government offices without receiving a single row about a person: it asks a question, and gets figures for groups, computed inside the foundation. Small groups are withheld, the records stay with the offices, and revoking a key refuses the next question at once.
Objective 7 of the UAE National AI Strategy 2031
Illustrative demonstration with fictional residents and a fictional pilot company.
Approving one data extract can take your legal team months. And once it leaves, you cannot call it back. With Samture, a pilot asks your offices a question instead of asking for a file. Each office decides, field by field. It receives figures per district, enough to compare its forecasts with what happened, never a row about a person. Small groups are withheld. A follow-up question that would expose a small group by comparing answers is refused, with the reason. Revoke a key, and the next question is refused. A pilot waits for a key, not for an extract.
Why pilots stall
To test a model, a company needs real data. The usual answer is an extract: a file that leaves the office, is hard to track and impossible to call back. So pilots take months to approve, or they run on data that is too thin to learn anything from.
Once an extract is sent, the office no longer controls where it goes or how long it stays.
Useful pilots combine data from several offices, and joining them usually means sharing the ID number.
When a result is questioned later, nobody can show which records it came from.
What the foundation does
Records from several offices are joined inside the foundation on the identifier they share, and the identifier never leaves. The join is computed per question and never stored as a combined dataset. The pilot receives figures per group, never a row about a person, and groups of fewer than five people are withheld. Each office issues its own key for its own fields. The source records stay with the offices, traceable on their side. Revoking a key refuses the next question at once, and because only group figures ever left, there are no personal records out there to call back.
The way in is the same as for every Samture engagement: a structural assessment first, then a demonstrator on your own processes and data, then a roadmap. Every engagement has one accountable Samture lead, from the first assessment to production.
Questions
Names and ID numbers are never released, and the pilot never receives rows about individuals: only figures per group, with small groups withheld. Whether a combination of fields is still too revealing is assessed per pilot under the data protection rules that apply to the office, as part of issuing the key, together with the purpose, the period and a log of every question asked. Repeated questions are checked, so that small groups cannot be uncovered by comparing answers.
Each office, for its own data, by issuing a key that covers specific fields for a specific purpose and period. A request for anything else is refused and shows why.
Each office keeps its own records. Joining happens inside the foundation, on infrastructure in the UAE that the offices control, under an agreement that names who operates it. The pilot only ever receives answers to its questions, never datasets.
Objective 7 asks for the data and supporting infrastructure that make the UAE a test bed for AI. This use case shows how to open data for experiments without giving up control of it.
Meet Samture
Pick a slot, or send a message and we find a moment that suits you.