An AI control layer designed to survive a regulator — not a quarterly review.
An EU financial services company needed to run GenAI inside the operational-resilience and ICT third-party risk framework that DORA imposes on regulated firms. The existing prototypes worked in demos and fell over under the questions a supervisor would ask first: who saw what, when, on which model, with what guardrails, and how do you exit the provider tomorrow? We built an AI control layer where the audit trail is the architecture, not a wrapper around it. The system reached production in eight weeks and passed its compliance review with zero findings.
Client
An EU financial services company (under NDA). Delivered for the internal teams responsible for GenAI deployment under DORA and the EU AI Act — risk, compliance, technology, and the business owners of the AI use cases themselves.
Engagement
Discovery → architecture → build → go live in eight weeks. One Solution Architect accountable for the result, with AI engineers, a business analyst, a certified project manager, and QA. The control layer runs in the client's own cloud estate.
"Demo-grade GenAI" is not a category DORA recognises.
DORA is not a hypothetical pressure. Article 28 makes the firm — not the vendor — accountable for ICT third-party risk, including the AI services it consumes. The regulator's first questions about any GenAI system are not does it work — they are can you prove who saw which output, on which model, with which guardrails active, against which policy version, on which date, in which jurisdiction. They want exit readiness on the day the provider falls over. They want incident reporting that fits the EU's reporting taxonomy. They want evidence that risk classification under the EU AI Act has actually been done — not just claimed.
Most GenAI prototypes in the firm had been built the way GenAI is usually built: a vendor SDK directly wired into a feature, prompts living in code, logging good enough for debugging but not good enough for audit, and a hard architectural bet on one provider. That style of system fails its first supervisory review and there is no realistic refactor that fixes it after the fact. Governance has to be part of the request envelope — not a service bolted on later.
Three constraints shaped the build. Per-request auditability: every model interaction must produce a tamper-evident record covering identity, policy version, guardrail decisions, retrieval evidence, model output, and the downstream action taken. Model agnosticism: the firm cannot bet the business on one provider's API surface; switching cost has to be days, not quarters. Exit readiness: the firm must be able to demonstrate that a controlled exit is operationally executable — not a slide in a deck.
The audit trail is the architecture. The model is a pluggable component behind it.
A control layer that every request flows through — identity, policy, guardrails, retrieval, model, output guardrail, audit, downstream action — with the model itself behind an envelope the rest of the system does not depend on.
Identity and policy before the model sees a token. Every request enters through the firm's existing identity provider and resolves to a typed actor — user, system, or service principal — with a named policy version attached. The policy decides what data the request is allowed to touch, which models it is allowed to use, which guardrails are mandatory, which jurisdictions are in scope, and what the retention obligation is. The policy is a versioned artefact, not a prompt comment.
Per-request audit envelope. Each request is assigned an immutable audit ID at ingress. From there, every step — policy evaluation, guardrail evaluation, retrieval result, tool call, model output, downstream side effect — is captured under that single ID, with cryptographic ordering and tamper evidence. The audit log is not "good logging"; it is the contract with the supervisor.
Pre and post guardrails as first-class stages. Input guardrails — PII detection, prompt-injection classifiers, data-residency rules, prohibited-topic policies — run before the model sees the request and can refuse, redact, or escalate. Output guardrails — grounding checks, citation validation, sensitive-data detection, policy-aligned refusals — run before the response leaves the control layer. Both decisions are recorded against the audit ID.
Model-agnostic envelope. Bedrock (Claude), Azure OpenAI, OpenAI direct, and on-prem options are all behind one internal envelope with a typed contract. Switching providers for a use case is a configuration change and an evaluation re-run — not a rewrite. Exit readiness becomes a property of the architecture, not a PowerPoint commitment.
Grounded retrieval as the default for knowledge tasks. Where the use case is a knowledge or document task, retrieval is intersected with the policy's data-scope before the model sees a chunk. The evidence that grounds the answer is captured in the audit envelope, so a reviewer can reconstruct exactly which retrieved evidence the model saw on this request — not "what it would have seen on average".
Downstream action contract. When the model triggers an action (book, write, file, notify), the action is mediated by a typed tool surface — not raw model output. Each tool call records its arguments, the post-condition it claims, and the system that executed it. The downstream system's outcome is closed back to the audit ID.
Operational telemetry, not vibes. OpenTelemetry across every stage. Per-policy, per-model, per-tenant cost and latency attribution. Alerts on guardrail-refusal rate drift, hallucination-grader confidence drift, and unusual policy-version usage. The team running the system sees the shape of usage in real time, not at quarter end.
SIEM and incident integration. The audit log forwards to the firm's SIEM with the schema the security team already uses. ICT incident reporting under DORA's taxonomy is wired from the same telemetry, not improvised at the moment of an incident.
Architecture (one request)
Zero findings. Eight weeks. A control layer the firm's GenAI now runs through.
Compliance issues
The control layer passed its compliance review with zero findings. The audit trail, the guardrail decisions, and the exit-readiness documentation were what the reviewers asked for.
To production
Discovery to live in eight weeks, including the policy-versioning model, the audit schema, the guardrail library, and the model-agnostic envelope.
Audit trail
Identity, policy version, guardrails, retrieval evidence, model output, and downstream action are captured under one immutable audit ID per request. Reconstruction is one query, not an investigation.
From day one
Provider swap is a configuration change and an evaluation re-run. The firm rehearses it; it is not a slide in a deck.
Guardrails as architecture
PII, prompt injection, residency, grounding, citation validation — first-class stages with recorded decisions. Not a vendor add-on.
DORA incident-ready
The audit log forwards to the firm's SIEM in the schema the security team already uses. ICT incident reporting is wired, not improvised.
A regulated firm cannot run GenAI on top of a vendor SDK and call it a control. The supervisor's first questions are about reconstruction — who saw what, under which policy, on which model, with which guardrails, and how do you exit. We built the control layer so that the answer to every one of those questions is a single query against an audit envelope that the request flowed through by design.
Six decisions that came from designing for a supervisor, not a demo.
1. Governance is the architecture, not a wrapper. Every request flows through the control layer by design. There is no "fast path" that skips audit, no developer shortcut that omits policy. The path is the only path.
2. Per-request audit IDs before the model sees a token. Reconstruction is a property of ingress, not of post-processing. The supervisor's question — "show me request X" — is one query, not a forensic exercise.
3. Model agnosticism equals exit readiness. A typed envelope around every model provider makes switching a configuration change and an evaluation re-run. Exit readiness ceases to be a promise and starts being a property.
4. Guardrails on both sides of the model are non-negotiable. Input guardrails refuse, redact, or escalate before the model sees the request. Output guardrails check grounding, citations, and sensitive data before the response leaves the layer. Both decisions are recorded against the audit ID.
5. Policy is a versioned artefact, not a prompt comment. The policy that governed the request is referenced by version in the audit envelope. Drift is detectable. Rollback is a deployment, not a hope.
6. The evaluation harness gates every prompt change. No prompt change reaches production without passing the evaluation set the use case was scoped against. Quality and policy regressions are caught before the supervisor sees them.
Discovery → architecture → build → go live in eight weeks.
- Discovery (week 1)
Policies, jurisdictions, use cases, exit obligations
Worked with risk, compliance, and the business owners of the AI use cases to map applicable DORA articles, the EU AI Act risk classification per use case, jurisdictional data-residency rules, and the firm's exit obligations under existing outsourcing arrangements.
- Architecture (weeks 2-3)
Audit envelope, policy versioning, model envelope
Designed the per-request audit envelope, the typed policy-version model, the model-agnostic envelope, the guardrail library, the tool-surface contract, the SIEM integration, and the exit-readiness runbook.
- Build (weeks 4-7)
Control layer, guardrails, evaluation harness
Built the control layer in the client's own cloud estate. Implemented input and output guardrails as first-class stages. Wired Bedrock and Azure OpenAI behind the typed envelope. Stood up the evaluation harness and gated prompt changes through it. Forwarded the audit log into the firm's SIEM.
- Go live (week 8)
Production, compliance review, exit rehearsal
Production launch behind feature flags. Compliance review completed with zero findings. First exit-rehearsal run: provider swap as a configuration change with the evaluation harness re-run. Documented in the runbook.
Same engineering DNA, different problems.
We have already built the control layer your supervisor will ask about.
Bring us your use cases, your existing identity provider, and the policies that govern your AI work. We will come back with the architecture, the audit schema, the exit-readiness runbook, and what it costs to ship and run.