A regulated AI deployment example becomes meaningful when an AI feature meets a real control boundary: a customer-support copilot that must answer quickly, protect personal data, stay within budget and provide evidence of what happened on every request. The challenge is not choosing one capable model. It is operating several providers without creating a separate security, compliance and cost-control project around each one.
For a UK or EU business, that means treating the model call as a governed production transaction. The application should not decide, ad hoc, which provider receives a prompt, whether personal data can leave the boundary, or how much a workflow is allowed to spend. Those decisions need to be applied consistently before a request reaches a model.
The regulated AI deployment example
Consider a software company running an internal support assistant for its operations and customer-success teams. The assistant can search approved knowledge sources and draft responses to account queries. Prompts may contain names, email addresses, account references and commercially sensitive context. Some requests are straightforward summarisation; others need stronger reasoning. Usage also varies sharply during incident periods.
The company has four requirements. First, it needs controls against prompt injection and jailbreak attempts, particularly where the assistant processes content copied from tickets or uploaded documents. Second, personal data must be handled according to the organisation's defined policy. Third, the team needs an audit trail without retaining full prompt and response content by default. Finally, Finance needs a hard limit on spend so a badly configured workflow cannot become an open-ended cost centre.
A direct integration to one provider can be acceptable for a prototype. In production, it leaves policy enforcement scattered across application services, provider dashboards and internal scripts. Adding a second provider for resilience or price-performance makes this worse. Every new integration can become another place where controls drift.
The better architecture places one governed doorway between the application and its model providers. The application retains its existing OpenAI-compatible calling pattern. The control plane applies the same sequence to every request: prompt shield, then DLP, then routing, then output moderation.
That order matters. A prompt shield assesses potentially malicious instructions before a request is processed further. DLP then evaluates sensitive data according to the policy action selected for that route or workload: log, warn, redact or block. Where redaction is required, the value is replaced with [REDACTED]; it is not tokenised or restored later. Only after these controls does routing select the most cost-effective capable provider and model. Output moderation is applied before the response returns to the application.
Deploy without changing business logic
The application team does not need to rebuild the assistant around a new SDK or introduce model-specific branches into business logic. With routeur.ai, the production change is limited to the API key and base URL. The request body remains in the familiar OpenAI-compatible shape, and the model can be set to auto so routing rules make the provider decision.
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": "Draft a response to this customer query." } ] )For engineering teams, this is more than deployment convenience. Keeping the integration byte-for-byte identical outside the endpoint and key change reduces the chance that governance work changes product behaviour. The assistant remains the assistant. The policy layer becomes independently manageable by the platform, security and compliance teams.
A named route can be used where the workload needs a clear operating profile, such as a route dedicated to customer support or internal legal review. Routing rules and priorities then determine which models can serve that route and how failover behaves. This avoids embedding provider preference in each application repository.
Set policy at the request boundary
The deployment should begin with a small number of explicit decisions, not a long catalogue of theoretical controls. Which data classes can be sent to models? What should happen when personal data is found? Which workloads require stronger output moderation? Which teams can use the route? What is the maximum permitted spend for the relevant budget period?
The answer will differ by use case. An internal meeting-note assistant might warn when it detects personal data, allowing an authorised user to make an informed choice. A customer-facing service may require redaction or blocking instead. For a workflow preparing regulated correspondence, output moderation should be stricter than for a low-risk internal ideation tool.
This is where scoped API keys are useful. A key can be limited to the intended route or team boundary, reducing the impact of accidental reuse. Named routes also make policy intent legible. An auditor or incident responder should be able to see that a request originated from the support-assistant route rather than infer it from provider logs.
Hard spend caps complete the boundary. They should not be treated as a routing preference. When a cap is reached, the expected operational outcome is an alert or a block with a 429 response, rather than silently moving traffic to a cheaper model. A hard cap protects the organisation from uncontrolled consumption; routing continues to optimise eligible requests within the budget that has been set.
Evidence without default payload retention
Regulated AI operations need evidence, but retaining every prompt and completion indefinitely can create its own data-protection burden. Metadata-only logging by default offers a practical middle ground. Teams can review request timing, route selection, provider and model choices, policy outcomes, latency, usage and cost without automatically storing the underlying payload.
Payload retention should be an explicit opt-in decision for narrowly defined operational needs, such as investigating an incident or evaluating response quality in a controlled environment. That distinction is important. Logging is not a reason to collect more content than the organisation needs.
Per-request traces make this operational. When a support manager reports an unexpected answer, the platform team should be able to establish whether the request was shielded, whether DLP found sensitive content, which route applied, which provider served the request and whether output moderation intervened. This is the basis for useful incident handling, rather than a vague statement that the system is monitored.
For organisations preparing for EU AI Act record-keeping obligations, the trace also creates a more workable evidence path. It links a production outcome to the controls and routing decision in force at that point in time. It does not remove the need for governance processes, risk assessment or human accountability. It does make the technical record easier to produce and review.
Test the controls before production traffic
A regulated deployment should be tested as a set of failure cases, not merely as a successful chat demonstration. Use dry runs to inspect how a request would be handled without sending it to a provider. Routeur-Dry-Run is useful when validating a new routing rule or DLP policy. Routeur-Trace can be enabled when a team needs diagnostic visibility for a specific request. Where testing requires a controlled provider or model selection, Routeur-Provider and Routeur-Model are the available request-level overrides.
The test set should include a benign request, a prompt-injection attempt embedded in ticket text, a request containing an email address or account detail, an unsafe proposed response and a request made after the relevant hard spend cap has been reached. The objective is to confirm exact outcomes: shield intervention, DLP action, route choice, moderation result and budget enforcement.
Do not assume one policy fits every assistant. The trade-off is real. More blocking reduces exposure but can interrupt valid work. More redaction protects data but may lower response quality because the model has less context. A wider provider pool improves resilience and price options but requires clearer routing priorities. These are operational choices that should be owned, documented and revisited as usage changes.
The useful closing test is simple: when a request fails, costs spike or a regulator asks how an output was produced, can the team show the decision path without searching through application code and multiple provider consoles? If the answer is yes, the AI feature is no longer just deployed. It is being operated with control.