Data compliance strategy
Our privacy policy describes what we collect. Our regulation page explains why regulation matters. This page explains how we operationally secure GDPR compliance across our architecture and supplier chain.
Our principles at a glance
Our compliance strategy is built on five principles that together cover the full data flow — from the user's keyboard to the language model's response and back again.
- 01We do not take on tasks that require processing special category data.
- 02Proactive filtering of sensitive input.
- 03Zero Data Retention throughout the chain.
- 04Our own infrastructure is EU-hosted.
- 05Third-party providers, the responsibility chain and lawful transfer mechanisms.
Principle 1
We do not take on tasks that require processing special category data
Our current chatbot implementations are designed for commercial use cases: product questions, order handling, returns and general enquiries. Those scenarios do not require processing data that falls under GDPR Art. 9 — health data, political opinions, religious beliefs, biometric data, sexual orientation, trade-union membership and similar data.
We cannot control what an end user writes in a chat window. But we can do our best to ensure that sensitive information is not passed further down the chain. That is the purpose of Principle 2.
Principle 2
Proactive filtering of sensitive input
Every incoming user message passes through a pre-processing layer before it reaches the language model. Pattern recognition scans for likely sensitive content — CPR-like Danish civil registration number formats, credit-card formats, medical terms and similar signals. Messages flagged as potentially sensitive are discarded, and the user is told not to share that type of information.
The purpose is to handle the user interaction responsibly and avoid sensitive data unintentionally reaching a sub-processor. Other flow steps — more advanced classification, metadata logging — can be added over time to improve precision, but the core is simple: questionable input is discarded.
This directly supports GDPR Art. 5's data minimisation principle: we process the minimum data necessary and actively reject what falls outside scope.
Principle 3
Zero Data Retention throughout the chain
We use only language-model providers where Zero Data Retention is contractually enabled. Prompts and responses are not stored, logged or used for model training by the provider.
This obligation applies to the whole chain — not only our own layer. It is enforced contractually through our direct databehandleraftale/data processing agreement with our provider and that provider's Art. 28(4) flow-down obligations to its own sub-processors. We do not hold — and do not need to hold — direct data processing agreements with every downstream model provider. The chain structure handles this (see Principle 5).
In practice, we use OpenRouter's Zero Data Retention feature. The provider exposes structured, programmatic ZDR classification at sub-provider level, and we route requests only to endpoints carrying that classification.
Principle 4
Our own infrastructure is EU-hosted
All Token Effort-controlled infrastructure — databases, runtime, logs, configuration and vector storage of customer data — is hosted in the EU region. Customer conversation logs remain in the EU.
This is a strategic choice that simplifies our compliance requirements and ensures that the data we control is subject to a consistent and strong legal framework. The specific transfer mechanisms for third-party providers are covered under Principle 5; this principle is about reducing the need for transfers in the first place.
Principle 5
Third-party providers, the responsibility chain and lawful transfer mechanisms
The responsibility chain — how compliance flows through sub-processors
GDPR establishes a clear responsibility structure for processing personal data. In our case, the chain looks as shown below. The central point is that we enter into one direct data processing agreement with our provider, and Art. 28(4) requires that provider to impose equivalent data-protection obligations on its sub-processors. We do not contract directly with each sub-processor — that is the purpose of the GDPR chain structure.
Our due diligence as controller
We exercise our duty as dataansvarlig/controller through documented, deliberate measures:
We choose a provider with a GDPR-compatible data processing agreement
Our direct data processing agreement is the instrument that contractually binds the chain — including Art. 28(4) flow-down and, for sub-processors in third countries, appropriate Art. 46 transfer mechanisms such as SCCs and the EU-US Data Privacy Framework.
We configure the provider conservatively
The provider offers structured controls — filtering by region, filtering by Zero Data Retention policy and explicit selection of approved sub-providers. We use all three. Requests are routed only to sub-processors that meet all criteria at the same time.
Sub-processor compliance is the provider's responsibility
The provider maintains structured metadata about each sub-provider's hosting region and data-retention policy. These classifications are the provider's own representations, bound by our data processing agreement. Our due diligence is to configure the system in line with those classifications; the Art. 28 chain places responsibility for sub-processor compliance with the direct processor.
We exclude third countries without a transfer basis
We explicitly exclude sub-providers hosted outside the EU or USA. No data is routed to jurisdictions without EU adequacy decisions or equivalent Art. 46 safeguards flowing through the provider's contracts.
We choose Zero Data Retention by default
This removes secondary-use risk at the end of the chain — no sub-processor stores, logs or trains on customer data. Combined with regional restrictions, the only downstream processing is the inference call itself, which is then discarded.
We document the configuration
Our internal Transfer Impact Assessment records active routing parameters, approved sub-processors and the legal instruments supporting the chain. This documentation is available to customers and supervisory authorities upon reasonable request.
What this means in practice
Our compliance strategy does not rest on hopeful trust in anonymous sub-processors. It rests on (a) a direct contract with our provider, (b) the provider's own contractual obligations down the chain under Art. 28(4), and (c) a conservative configuration that systematically excludes sub-processors and jurisdictions without appropriate transfer mechanisms or data-protection guarantees. This is the structure GDPR prescribes for processor chains — not a way around it.
Documentation and accountability
- Internal documentation
- Transfer Impact Assessment, sub-processor overview and data-flow diagrams. Available to customers and supervisory authorities upon reasonable request.
- Our role
- Dataansvarlig/controller for our own operations, databehandler/processor for customers' end-user data.
- Contact
- mail@token-effort.com
Last updated · 22 April 2026