A privacy policy cannot intercept a prompt containing a customer’s account number. A DPIA cannot stop a developer selecting an unapproved model at 17:00 on a Friday. GDPR AI tools are useful only when they turn data-protection decisions into controls that operate on every production request.
For teams running LLM features across products, internal copilots and automated workflows, the question is not whether an AI tool has a GDPR page. The question is whether it gives engineering, security and compliance teams evidence and control at the point data is sent to a model provider.
Why GDPR becomes an infrastructure problem
GDPR obligations apply to the processing around an AI system, not to a model in isolation. The practical work includes establishing a lawful basis, defining retention, managing processor relationships, protecting data by design and being able to demonstrate what controls are in place. When applications call several LLM providers directly, those controls tend to fragment quickly.
One product team may log full prompts for debugging. Another may use a model provider in a different region. A third may add basic redaction in application code, while an internal assistant bypasses it entirely. None of those choices is necessarily deliberate non-compliance. They are the predictable result of each team building its own path to a provider.
The operational answer is one governed doorway between applications and model providers. That doorway should apply the same policies before a request leaves the organisation, regardless of which provider or model eventually handles it.
What GDPR AI tools must control at request level
A useful evaluation starts with the data path. Ask what happens to a prompt from the moment an application creates it through to the final response, trace and retained record. High-level assurances matter less than the controls that are actually enforceable.
Sensitive data handling before routing
A DLP control should inspect prompts before provider selection and support an outcome that matches the risk. Logging a detection may suit a controlled test. Warning can help teams identify poor prompt construction. Redaction replaces detected information with [REDACTED], allowing a lower-risk request to continue. Blocking prevents the request from being sent at all.
These choices are not interchangeable. Redaction may be practical for a support summarisation workflow where the model does not need a customer identifier. Blocking is more appropriate where the identifier is essential to the task and removing it would create misleading output. A mature policy model makes that distinction explicit rather than treating all PII as one category.
DLP is also only one layer. Prompt-injection and jailbreak shielding must run before data protection logic can be relied upon, because a hostile instruction may attempt to alter the intended task or extract information. In a governed request path, the order should be clear: prompt shield, then DLP, then routing, then output moderation.
Output moderation completes the loop. A prompt may be clean while the generated response is unsuitable for an end user or exposes content that should not be returned. Input and output controls address different failure modes and should be evaluated separately.
Logging that proves operation without creating a new data store
Logs are often where a well-intentioned AI deployment creates avoidable exposure. Full prompt and response retention can be helpful during an incident, but it can also create a broad, searchable store of personal data. Treating it as a default is difficult to justify for many workloads.
Look for metadata-only logging by default, with payload retention as an explicit opt-in decision. Metadata can support operational analysis through timestamps, request outcomes, selected providers and models, policy actions, cost and latency, while limiting routine retention of request content.
Per-request traces matter here. A trace should allow an authorised team to establish how a request was handled: whether a policy fired, which route was selected, whether a fallback occurred and what the final outcome was. That is more useful for accountability than a generic dashboard showing aggregate request volume.
Provider choice, region and processor governance
A multi-provider architecture creates useful resilience and commercial leverage, but it also expands the governance surface. Each route should have defined provider and model priorities, and teams should understand where data is processed for the selected configuration.
For UK and EU organisations, EU data residency and clear GDPR processor terms can simplify the operational model, but they do not remove the need for a documented processing assessment. The organisation deploying the system still needs to decide which data may enter which workflow, who can access it, and how long it should be retained.
Scoped API keys are equally relevant. A broad key shared across environments makes it harder to isolate a misuse event or demonstrate which service initiated a request. Keys should be scoped according to the application, environment and operational responsibility they serve.
A practical architecture for governed AI requests
The strongest GDPR AI tools do not require developers to rebuild every application around a new proprietary interface. A gateway that remains compatible with the OpenAI API allows teams to centralise controls while keeping application behaviour stable.
With routeur.ai, the application points its existing client at https://api.routeur.ai/v1 and uses a route such as auto. Business logic can remain byte-for-byte identical while the request passes through a single policy and routing layer.
import os from openai import OpenAI
client = OpenAI( api_key=os.environ["ROUTEUR_KEY"], base_url="https://api.routeur.ai/v1" )
response = client.chat.completions.create( model="auto", messages=[ {"role": "user", "content": "Summarise this support case for an agent."} ] )That small change is significant because governance moves out of scattered application code. Teams can apply named routes, routing rules and priorities centrally. They can use capable models for demanding tasks and more cost-effective models where appropriate, with automatic failover when a provider is unavailable. The application remains focused on its product workflow rather than provider-specific policy handling.
This does not mean every workload should be routed identically. A customer-facing legal assistant, a code-generation tool and an internal meeting summariser have different risk and quality requirements. Named routes allow those differences to be deliberate, reviewable configuration rather than hidden conditional logic across repositories.
Cost controls are also data-governance controls
Uncontrolled spend is usually discussed as a FinOps issue, but it has a governance dimension. Unexpected AI usage often indicates that teams are experimenting outside an agreed operating model, or that an automated workflow is behaving differently than expected.
Hard spend caps and budgets create a clear boundary. When a cap is reached, requests can be blocked with a 429 rather than continuing silently. That may be disruptive if poorly planned, so critical services need sensible budgets, monitoring and ownership. It is still preferable to discovering an uncontrolled workload after it has accumulated cost and processed more data than intended.
Cost reporting also helps challenge whether a workflow needs to send complete source material to a premium model. Sometimes the right improvement is better prompt design, smaller input scope or a different route, not simply a larger budget.
How to assess GDPR AI tools before deployment
Avoid scorecards based solely on compliance badges. Ask the vendor and your own engineering team to walk through a real request: a support agent pastes a customer message containing an email address, the preferred provider is unavailable, and the workflow reaches its monthly cap. The answers should be specific.
A credible implementation can show which policy detects the data, whether it logs, warns, redacts or blocks, how fallback routing is constrained, what trace is retained, and what happens at the spend limit. It should also make payload retention a conscious configuration decision rather than an accidental by-product of debugging.
Then test the operating model. Security needs visibility into policy enforcement. Compliance needs evidence for its records. Platform teams need to change routes without application redeploys. Product teams need predictable quality. If each requirement requires a separate proxy, logging system and provider integration, the control surface will become harder to maintain over time.
The useful standard is simple: every LLM request should have a known route, an enforceable policy path and an accountable record. Build that before AI usage becomes too widespread to reconstruct later.