Net NinjasBook a call
All talks and takeaways

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.

StopWhat I check thereForm of the dataRegionWho runs itRetention
Client and APIWhat the request carries, and which fields the feature really needs.
Policy gatewayWhich identifiers get removed or pseudonymised, and where the lookup table lives.
Prompt builderWhether the finished prompt still holds a name, a date of birth, or a record number.
Retrieval and vector storeWhich sources the embeddings came from, and whether a deleted record leaves the index.
Model endpointThe region of the endpoint, and what the provider keeps and for how long.
Response handlingWhere re-identification happens, and who approves the draft.
Application logsWhether prompts or responses appear in a log line.
Tracing and error trackingWhether request bodies travel to a tool outside the EU.
Evaluation setsWhether test cases hold real records or synthetic ones.
Backups and snapshotsWhether copies of the stores above stay in the same region.

Eight leak paths I check first

Each yes scores one point.

  1. 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. 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. 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. 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. 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. 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. 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. 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

  1. 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.
  2. 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.
  3. I read the settings of each observability tool. Payload capture, data scrubbing rules, and the region of the tool's own storage.
  4. 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 call

These 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.

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?