Worksheet
The AI data-path map
A one-page worksheet that follows personal data through an AI feature, stop by stop, with the eight leak paths I check first.
The healthcare pattern from the talk is that sensitive data never reaches the model raw. A policy gateway strips or pseudonymises identifiers before the prompt is built. The model endpoint, the vector store, the logs, and the backups all sit in EU regions. A clinician signs off before anything reaches a patient record.
I'm starting to see teams get the model call right and leak the data somewhere else. A log line, an observability tool, or an error tracker holds the raw prompt in another region. This worksheet follows one request through every stop. Any cell that says 'not sure' is the next thing to find out.
From the talk: Your AI feature is an architecture problem
The map
One row per stop. The first two columns are mine, and the other four are for your own answers.
| Stop | What I check there | Form of the data | Region | Who runs it | Retention |
|---|---|---|---|---|---|
| Client and API | What the request carries, and which fields the feature really needs. | ||||
| Policy gateway | Which identifiers get removed or pseudonymised, and where the lookup table lives. | ||||
| Prompt builder | Whether the finished prompt still holds a name, a date of birth, or a record number. | ||||
| Retrieval and vector store | Which sources the embeddings came from, and whether a deleted record leaves the index. | ||||
| Model endpoint | The region of the endpoint, and what the provider keeps and for how long. | ||||
| Response handling | Where re-identification happens, and who approves the draft. | ||||
| Application logs | Whether prompts or responses appear in a log line. | ||||
| Tracing and error tracking | Whether request bodies travel to a tool outside the EU. | ||||
| Evaluation sets | Whether test cases hold real records or synthetic ones. | ||||
| Backups and snapshots | Whether copies of the stores above stay in the same region. |
Eight leak paths I check first
Each yes scores one point.
- 1.Prompts and responses stay out of our application logs. Logs carry the request ID, the model version, and the approver. The text lives in one store with its own retention.
- 2.Our tracing and error tools don't capture request bodies. Observability and error tracking tools often record payloads by default. That setting sends raw prompts to another company.
- 3.The model endpoint is pinned to an EU region. A global or cross-region endpoint can route a request outside the EU. The region is a deployment setting we can show.
- 4.We know what the model provider keeps, and for how long. Abuse monitoring and debugging logs on the provider's side are a stop on the map too.
- 5.The pseudonymisation table sits apart from the prompts. The key that links a token back to a person lives in our own system, under separate access (art. 4(5) Regulation (EU) 2016/679).
- 6.A deleted record also leaves the vector store. When a person's data has to be erased, the embeddings, caches, and summaries built from it go too (art. 17(1) Regulation (EU) 2016/679).
- 7.Our evaluation sets hold synthetic or anonymised cases. Real records in a test fixture end up in the repository, the CI logs, and on laptops.
- 8.Backups and snapshots stay in the approved regions. A cross-region copy of the vector store or the log bucket is a transfer nobody drew.
How I draw it: from the live accounts, not from the design doc
- I send one test request with a marker value. A made-up name such as Zebra-Quartz-7781 goes into the input. I then search every store, log, and tool for it.
- I list every outbound connection from the feature. VPC flow logs, the egress proxy, and the SDK configuration show each third party a request touches.
- I read the settings of each observability tool. Payload capture, data scrubbing rules, and the region of the tool's own storage.
- I compare the map with the sub-processor list. A provider on the map and missing from the list is a gap in the data processing agreement.
The rules behind the map
Health data is a special category of personal data (art. 9(1) Regulation (EU) 2016/679). Processing it on a large scale calls for a data protection impact assessment (art. 35(3)(b)). A startup that processes data for a hospital needs the hospital's written authorisation before it brings in a model provider (art. 28(2)). Data that leaves the EU falls under the transfer rules of Chapter V (art. 44). The map is the evidence behind all four answers.
What I leave out on purpose
I leave out a self-hosted model, a private cloud, and a data loss prevention suite. Each one costs months, and none of them finds a prompt in a log line. A marker value and an afternoon with the live accounts do.
Next step
I highly recommend bringing the map to a thirty-minute call, even half filled. We'll walk the live accounts and find the stops the design doc forgot. Could your team show a hospital's security team every place a patient's data goes, in one diagram?
Book a callThese takeaways are an engineer's reading of the rules and the tools. I wrote them to help teams decide what to build. They aren't legal advice. I recommend checking the current text with your own counsel before planning around a date or a threshold.
How I help
Cloud security hardening
I find the gaps in your cloud accounts, identity, network, and data, rank them by what an attacker reaches first, and close them with your team.
AI integration
I put language models to work on the problems that matter in your product and back office, and I ship them to production.
Other takeaways from this talk
Checklist
Six-layer AI architecture checklist
Twelve yes/no checks across the six layers of a production AI feature, two per layer. The model sits inside only one of them.
Template
AI decision log template
A copy-ready log for AI features that touch money or records: what the model proposed, what it saw, and who or what approved it.
Worksheet
Cost per AI action worksheet
A worksheet and a SQL query that turn tokens, model prices, and request logs into a cost per AI action and per customer.
Let's talk.
A 30-minute call, no pitch. We look at your current setup, your stage, and the thing that's bothering you about it. I give a straight opinion on what to change, what to leave alone, and whether the problem is the one it looks like. What's the one thing in your stack you'd fix tomorrow?
Prefer email or phone? hello@netninjas.eu or +31 6 45984313
