The Request That Has to Stay Home
Most model-placement decisions are judgment calls about cost and latency. A data subject access request is not one of them, and building the pipeline for it taught me more about designing AI systems than anything else I did this year.
Under GDPR and CCPA, a person can ask a company what personal data it holds on them, and the company has thirty days to answer. It is a small obligation, and the clearest teaching example I have found for how to design an AI system.
A data subject access request asks you to gather everything you know about one named individual and put it in one place. That compilation is more sensitive than any of its parts, and sending it to a public API would create a second copy of the problem the law exists to prevent.
Most placement decisions weigh cost against latency against how much a leak would hurt. This one decides itself, which is why it was worth building first.
What the pipeline does
It writes the compliance record before it looks up a single row: subject, request type, received timestamp, statutory deadline. If discovery fails, the model is unreachable or anything downstream falls over, the record that a request arrived already exists. It lives in the CRM rather than in the workflow engine’s memory, which has proved forgetful on at least one other thing I run.
Then it searches the person record, notes, opportunities and tasks. A subject with no records produces a clean “no data held” outcome rather than an error, because a negative result is still a result a regulator can ask about.
The summarizing step runs on a 7B model on my own machine, reached only over a private network. It sees names, note titles, stages and counts, never raw payloads. If that endpoint is unavailable, the pipeline does not fall back to a public model. It refuses and says so in the report. A fallback would have been three lines of code and would have destroyed the only property that mattered.
The gate
The pipeline never sends anything to the data subject. It compiles the report, states which model boundary it honored, drafts a proposed response, and stops.
A person reads it and decides what is owed. Scoping a DSAR response can require legal judgment, and that is the last place I want a confident sentence standing in for a decision nobody made.
What verifying it looked like
Six executions against the live endpoint, not a mock. Missing header: 401. Wrong secret: 401. Malformed request: 400 with a readable error. A synthetic person with three notes and one opportunity, found and summarized in about a second and a half, with nothing touching a public API. An unknown email returning “not found”, with the governance record still written.
Then I deleted all of it — the fixture person, the opportunity, the notes, and the two governance entries my own test runs had created — and re-queried to confirm nothing remained. A year ago I would have skipped that step. Building something that handles other people’s data teaches you to clean up your own test fixtures.
The full teardown is on the Marain site.