Apr 2026
Compliance

Designed inside GDPR, not bolted on after

Most AI tools treat data protection as a setting. There is a toggle somewhere, a region picker, a data-processing agreement you sign and then hope holds. The work is real, and it never quite finishes, because the default state of the tool is to send your data somewhere else.

We started from the other end. If prompts, completions, and agent memory never leave the device, most of what the GDPR asks for is already true. Not because we configured it, because there was nothing to send.

The safe state is the default state

When a task runs on a local model, the data stays on your machine. No processor, no transfer, no third country. The cloud is opt-in per prompt and per model, a choice you make rather than a default you have to keep fighting.

That flips the usual burden. Instead of proving that a remote service handles your data correctly, you start from a position where the data did not move. The documentation gets shorter because the architecture is doing the work.

When you do reach for the cloud

Sometimes you want a frontier model, and that means a remote call. Soriku is a Dutch company building on European infrastructure, with Mistral as the recommended primary, so the default path stays inside the EU. US providers are available too, by your choice and with your own key.

For the detail that goes in a procurement form, the data-subject rights, what gets collected in each mode, and how breaches are handled, see the GDPR and EU AI Act docs.

Why it matters

Compliance built as an afterthought is fragile. Every new feature is a new place for data to leak, and every audit is a new round of checking. Compliance that falls out of the architecture is quieter. You are not maintaining a promise, you are running software that cannot break it in the first place.

← Back to blog