Privacy as architecture: per-person encryption and the k≥5 floor

“Your data is safe” is the most devalued phrase in software. That's why we prefer to explain the mechanism instead of asking for trust.

One key per person

Every employee has their own encryption key (DEK), wrapped by a key service (KMS) only the running system can use. Your history is encrypted with YOUR key. When the system assembles context to reply to Ana, it can only decrypt Ana's data: Bruno's text does not exist in that request — it's not a prompt rule an injection could bypass, it's cryptography.

“Olvida todo” is real deletion

If you write 'olvida todo' to Sabia (and confirm), your key is deleted. Your entire history — conversations, memory, preferences, dates — becomes cryptographically unrecoverable instantly, even in backups. It's not a soft-delete: it's the disappearance of the only key that could read it.

The k≥5 floor

The company only sees anonymous counts per topic, and only when at least 5 distinct people touched that topic during the week. Below that floor, the topic doesn't exist for the company. It's a database constraint, not a promise: the row with k below 5 cannot be written.

• Not even the founding team can read conversations: the debugging role sees only ciphertext.
• Preferences, dates and memory are personal data: they never enter a report.
• Billing is flat-band — counting 'active seats' would leak who uses the coach, so it isn't counted.

Start with the free diagnostic →