In the path, not after the fact
Scrubbing downstream is simpler to build and leaves a window in which unprotected data exists somewhere. Putting enforcement in the path removes the window at the cost of a harder latency budget.
A scrubbing mechanism for support data that met privacy obligations without giving up the low latency the data was valuable for.
Support data is most useful while a case is open. It also carries personal information, which brings regulatory obligations about what may be retained and in what form.
The usual resolutions are unsatisfying in opposite directions: scrub in batch and the data is stale by the time it is clean, or restrict access and the operational value disappears. Neither treats low latency and privacy enforcement as things that have to hold at the same time.
Shared ownership stated as such. Nothing here claims sole authorship of a platform.
Move enforcement into the streaming path instead of running it as a downstream batch, so data is protected as it flows instead of after it has settled somewhere unprotected.
Remove the dependency that was forcing the latency instead of optimising around it. The critical path was long because of what it passed through, not because any single step was slow.
Fit into the existing pipeline instead of standing up a parallel one, keeping a single path for the data and a single place where the guarantee holds.
The ones with a real cost on the other side.
Scrubbing downstream is simpler to build and leaves a window in which unprotected data exists somewhere. Putting enforcement in the path removes the window at the cost of a harder latency budget.
Privacy enforcement applied to support data in near real time, improving regulatory posture while keeping the data available quickly enough to be operationally useful.