How we handle your data, in detail.

When we handle personal data for you, we act as your processor under Article 28 GDPR and use the data only on your instructions.² We sign a data processing agreement with every client whose personal data we handle, and use only providers that offer one.

Before we start, we tell you which providers will see your data and where they process it. If your data must be processed in the EU, we can set that up with EU-region cloud deployments or open models hosted in the EU.

EU processing depends on the route, not the brand: a provider's global endpoint can process data outside the EU. With an open model on an EU server that we or you control, prompts reach no model vendor. The host still needs a processing agreement, and security measures such as encryption, access control and patching still apply.

The EU AI Act applies in stages.³ The dates below include the changes made by the Digital Omnibus on AI, which moved the high-risk deadlines and left the transparency date unchanged.⁴

EU law requires that people are told when they're dealing with an AI system. Agents that write to people on their own say so in their first message and in every email. They also name the company they write for, as the European Commission's guidelines expect of agents that handle correspondence.⁵ If an agent runs under your company's name, the Act is likely to treat your company as its provider, with duties of its own. We agree in writing who builds each disclosure.

We check every use case against the AI Act's banned and high-risk categories before we build. Inferring employees' emotions from their voice, for example, is banned at work except for medical or safety reasons, so we don't build it. Each deployment includes a short AI-literacy briefing for the people who supervise the agent. It covers what the agent is for, its limits, when to override it and which data rules apply.

• 2 February 2025: the bans on prohibited practices (Article 5) and the AI-literacy duty (Article 4) apply.³
• 2 August 2026: the transparency duties in Article 50 apply, including telling people they are dealing with AI.⁵
• 28 October 2026: KRiBSI, Poland's market-surveillance authority for AI, can inspect and fine from this date.⁶
• 2 December 2027: obligations for high-risk systems listed in Annex III apply, moved from 2 August 2026.⁴
• 2 August 2028: obligations for high-risk AI in products covered by Annex I apply, moved from 2 August 2027.⁴

Each connection gets only the permissions its job needs. During the audit, that means read-only access or anonymised samples, whichever you prefer. In production, we set up access with the narrowest permissions each connection can work with.

Credentials and API keys stay in accounts and vaults you control, and the systems run in accounts opened in your company's name. We work only with the access you grant. You can withdraw it at any time, and we remove access that is no longer needed.

Before launch, every agent is tested on your own past cases. The tests include questions your documents cannot answer, to confirm that the agent says so instead of guessing. A new system starts in draft mode, where a person checks every output, and runs steps on its own only when the results justify it.

Guardrails, the limits an agent works within, are set with you. Each agent answers from sources you approve and shows where each answer came from. Low-confidence results, failed checks and anything above your limits go to a person. By default, our agents draft and your team approves.

After launch, failed runs and unusual results alert us and the person you name. We check samples of the system's work against the test cases. After any change to a model, prompt or connected system, the tests run again. Testing lowers the risk of a wrong answer. It does not remove it.

Every failure reaches a named person, on your side and ours. We trace it in the logs, fix the cause and record what changed. Anything that stops your team working comes before improvements.

If an incident is a breach of personal data, we tell you without undue delay, as Article 33(2) GDPR requires of a processor.² We also share what the logs show, so that you can decide whether to report it to the supervisory authority.

During deployment, the old way of working stays available as a fallback until the results match. Each system's runbook explains how to run and repair it.

This page describes what we do. It does not claim a status we cannot prove.

• We hold no certifications, and no general GDPR certificate exists.
• We don't call a system compliant across the board. Compliance depends on the system, how it is used and each party's role.
• We don't promise that data never leaves the EU. That holds only on routes we set up for it.
• Zero retention is not a default. Providers typically keep request data for 30 days to detect abuse, and we request or configure zero retention where a project needs it.
• We don't promise that nobody else sees your data. Providers keep flagged content and may review it.
• We don't promise error-free or fully autonomous agents. A person stays in the loop wherever a mistake would be costly.
• We don't imply endorsement. Provider and tool names on this site are plain references.