Assurance
How Nakato meets the rules your data is held under.
The legal basis the layer is built on, the frameworks it is built against, and the evidence behind every answer.
The legal basis
Built to the regulator's own test
Under UK and EU GDPR, data is personal if a person can be identified from it, directly or indirectly (Article 4(1)). Whether they can be re-identified is judged on all means likely to be used, including combinations of details that together point to one person (Recital 26).
The ICO puts it as a test: could a motivated intruder, with the internet, public records and social media but no specialist knowledge, work out who a record is about? The courts have since held that what matters is whether the recipient has any realistic means of identifying anyone.
That is the line Nakato is built to. Your real data never leaves your environment as models only receive a twin that attackers have no reasonable means of being re-identified. Our detection is trained to find the indirect details that pattern matching misses, and twins these too.
The model has no reasonable means of identifying your customers.
The claim a compliance lead can put their name to, and the one the layer is designed around.
The frameworks
Built against regulation from the start
- GDPR and UK GDPR. Data protection by design, with pseudonymisation as the regulators define it.
- EU AI Act. Transparency evidence for high-risk systems, produced as the layer runs.
- DORA. Operational resilience inside your own environment, not a new external dependency.
- FCA and PRA. Supervisory evidence on demand, with every substitution and its reversal on the record.
- SOC 2. Controls aligned to the framework, documented and checkable in the audit trail.
Where each thing lives
Stays in your environment
The record, as written
Joan Mercer
The map from each twin to its original
Edith Hargreaves → Joan Mercer
The audit trail of every swap and its reversal
Your boundary
Crosses to the model
The twin, in place of the record
Edith Hargreaves
The task you asked it to do
What stays inside your pseudonymisation domain, and the only things that cross to the model.
The review
The questions a review will ask
Sign-off relies on a familiar set of questions. These answers come from how the layer is built, not from promises.
Where does our data go?
Your real data never leaves your environment. The layer runs in your VPC or on your premises, on a small language model with no dependency on a large AI provider. Only the twin crosses to the model.
What happens when detection is unsure?
It fails closed. A value below the confidence gate is held back, never passed through.
Can we evidence what was substituted?
Yes. The audit trail records every substitution and its reversal, ready for internal audit or supervisory review.
Which models can we use?
Any. The layer sits in front of the model, not inside it, so you can change provider without rewriting your governance.
What does detection actually catch?
Context, not keywords: more than fifty types of entity, including the indirectly identifying details that pattern matching misses.
Do we need to change how our data is classified?
No. The layer works with your existing classification and the data you already hold.
Model risk
Model inputs are model risk
Supervisors treat what goes into a third-party model as a risk the firm owns, including data exposed through its inputs. A record that is sent to a model but can be traced back to a customer is an unmanaged one.
The twin manages it at the point of query. The input is the twin; everything is logged in an audit trail.
One route in, one route back, and a record of every step between.
The evidence
Checked, not asserted
Every substitution and its reversal is written to the audit trail, so a reviewer can retrace a decision without seeing the underlying data.
The headline benchmarks are on the home page: detection, reversal and how little of the original can be recovered under attack. See the benchmarks.
The full report, with its methodology, is available on request. Email hello@nakato.ai.