GDPR-boundary analytics foundation
travel technology design engagement
Label it honestly
This is a design engagement: an architecture and a decision-ready proposal, not a delivered build. We mark it as such because the difference matters — it is the same difference we ask our clients to respect in their own claims.
Context
A travel-technology client needed an analytics foundation over sensitive operational data, including imagery, with AI components in scope from the start — and a hard requirement that personal data never cross the boundary unprotected.
Constraint
UK/EU GDPR applied throughout. Anonymised data is still personal data under the recital-26 reading, so "we anonymised it" was not an exit from scope. The architecture had to make the boundary structural: raw data physically cannot reach the governed compute tier.
What we designed
A three-zone architecture — client datacentre, cloud region, analyst endpoints — with a GDPR spine: source systems and a de-identification service permanently on-prem; only an anonymised projection crosses to the cloud; images masked by face/plate detection with irreversible masking and metadata stripping before anything leaves. Model work runs on the masked projection only. A multi-provider model menu keeps vendor leverage with the client, and a governed read layer gives agents allow-listed, audited, read-only access to the analytical store.
What it changed
The client received a decision-ready architecture with cost structure, phase boundaries and an honest statement of what remains open to discovery. The governed-read-layer design is the same concept that now ships inside Texera Engine.