"GDPR-compliant" has become one of the least informative phrases in software. It usually means a cookie banner, a privacy policy someone adapted from a template, and a data-export button that took three weeks to build because nobody designed for it. The regulation gets treated as paperwork to satisfy at the end, rather than a set of constraints to build from.
We took the opposite approach. The GDPR's principles — data minimisation, purpose limitation, privacy by design and by default — map cleanly onto engineering decisions, and we made them early.
Compliance as architecture, not paperwork
The difference shows up in where the work happens. Bolt-on compliance lives in documents and process; designed-in compliance lives in the system's shape. Data residency isn't a clause in our terms, it's where the compute physically runs. "We don't sell your data" isn't a promise, it's that there's no pipe out for it to flow through.
When the architecture enforces the principle, the policy is just describing reality. That's the version you can actually stand behind in an audit.
Privacy by default, literally
"By default" is the word that does the work in the regulation, and it's the one most products ignore. Optional analytics that default to on aren't privacy by default; they're privacy if you go find the setting and turn it off.
So in our stack, the privacy-preserving choice is the starting state. Strictly necessary processing runs; anything beyond it — analytics, marketing — is off until you actively opt in, with equal-weight choices and no dark patterns nudging you toward "accept all." The consent banner on this very site works that way on purpose.
Your rights are buttons, not requests
The GDPR gives people real rights — access, correction, export, erasure. In a bolt-on system those become support tickets: you email someone, they go spelunking in a database, weeks pass. We designed so the common ones are mechanical. Your data is something you can see, export in a portable format, and delete — and when you delete it, its influence on your agents' memory goes with it.
A right you can exercise yourself, quickly, is worth far more than one you have to formally demand.
We don't train on your data
The single most important line, and the one we get asked about most: we do not train foundation models on your content. Your prompts, documents, and agent outputs are processed to do your work and then retained only under a schedule you can see — not quietly absorbed into a model that then benefits every other customer.
This is also where sovereignty and privacy meet. Data that stays in your region, under EU law, with no training pipe and no egress, is data whose story you can tell completely. The full detail — legal bases, retention, your eight rights and how to use them — is laid out in GDPR & Your Rights. Plain language, because privacy you can't understand isn't really privacy.