An LLM cannot be made auditable enough for a financial regulator.
Two things break at once — and they’re the two questions a regulator actually asks.
A — Security
Can you trust what it did?
The failure surface is broad and structural:
Prompt injection — hidden text becomes instructions the model follows.
Hallucination — it fabricates facts with no signal that it did.
Non-determinism — the same input gives different outputs; the same audit can’t be reproduced.
Poisoning — defects baked in upstream at the vendor, invisible to you.
The EU AI Act, Article 15(5), names five cybersecurity threats to high-risk AI — different in shape, identical in trust assumption: you cannot audit what is inside the model.
B — Evidence
Can you prove why it decided?
Every decision is one a regulator can make you justify:
The reason — why the system approved this customer, flagged this transaction, declined this credit.
Reproducible — the same decision re-derived after the fact, on demand, sometimes months later.
As proof, not a log — a record of what happened doesn’t show why it was allowed.
Mapped to the rule — tied to the specific DORA, EU AI Act, or MiCA article you answer to.
Across these frameworks the burden is identical: show the reason behind each decision. A well-aligned model isn’t an answer.
Myth-buster
Running on AI doesn’t make you compliant. Every defence built inside the model — alignment, RLHF, guardrails, system prompts — lowers a probability; none proves a bound. And a probability is neither security a CISO can sign nor evidence a regulator accepts.
The position
The only architecturally honest move: treat the model as untrusted by default, put the trust boundary outside it — in deterministic gates you can read line by line — and sign the result. We don’t make the model safe. We make what it can do bounded, and what it did provable. That answers both questions at once.
Trust the gates, not the model.
§ 02 — HOW IT WORKS
How it works
Inline in your perimeter. Verify every request. Sign the proof.
Operanta runs in your own perimeter, right next to your model — inline on the path of every request. It checks each request before the model sees it and each answer before it ships, then seals the decision as a signed record. Not a container, not a sandbox, not a gateway — a layer between your app and your model. The model isn’t a gate: it’s invoked inside the layer, under a control-flow lock.
your perimeter · your server
your productionapp · workflow
request
verified answer
OPERANTA · checks & signs7 deterministic gates
01Input screeningData ≠ commands
Every external input is authenticated, schema-validated, and separated from instructions before it reaches the model. Data ≠ commands, at the protocol level.
verified request
answer
your AImodel · API
not a container · not a sandbox · not a gateway
signed Evidence Pack
Auditor · verifies offline
§ 03 — WHY IT WORKS
Why it works when others don’t
Most AI security lowers a probability and hopes. We change the structure.
In two ways a regulator and a CISO can both check.
Move 1
Verified before execution, not filtered after.
The checks and the capability lock run before the model acts. The decisions that govern execution — which tool, which endpoint, which tenant — come only from trusted sources, never from the prompt or the model’s output. Untrusted input can pick among already-permitted routes, but can’t introduce a new one — the unsafe path simply isn’t in the set.
A guardrail filters probabilistically and leaks one in a hundred; here the unsafe route is structurally absent — and a gate that can’t run its check blocks the action rather than guessing.
Move 2
Signed evidence by default, not logs after the fact.
Every decision produces a tamper-evident, offline-verifiable Evidence Pack — sealed as the decision is made, not reconstructed later from logs. It carries the checks that ran, the policy that governed them, and a proof it wasn’t altered after the fact, all mapped to the specific regulator article you answer to.
A log records what happened and proves nothing. An attestation vendor signs the output — but never verified it before the action.
No one has the whole: verification before execution + capability control of the flow + signed evidence + fintech regulation covered as one — over any model, in your own perimeter.
What this lets you do
Let AI into regulated workflows without opening a new attack surface
Process untrusted documents — KYC packets, attachments — without assuming they’re clean
Swap the model without re-auditing the controls
Stay sovereign by design — it runs on your own server, and the evidence never leaves
The agent can go where you wouldn’t deploy it today.
§ 04 — SEE IT
See it
The product, not a promise.
What the layer actually gives your team — you set it up on the platform, then it runs in your own perimeter.
Pick a self-hosted runner or the API you call into, and the inbound port.
Any model behind the layer — self-hosted or an API you call into. One setup per system; it runs entirely in your own perimeter, evidence stays local, and every new build redeploys — so every request and every new agent inside is covered.
§ 05 — PROOF, NOT LOGS
Proof, not logs
Evidence a regulator verifies without us.
Every decision leaves a cryptographically signed Evidence Pack: what was checked, by which gate, against which policy, plus an integrity proof it wasn’t altered after the fact. Your regulator verifies it offline, on their own — the vendor-independent trail DORA Article 28/29 concentration-risk asks for. It’s your proof, not ours.
Cybersecurity-of-high-risk-AI mappings, technical documentation — much auto-generated from runtime.
MiCAArt. 38, 43, 45
CASP operational governance and conduct evidence.
SAMACyber Security Framework · Phase 3
KSA-domiciled banking control evidence.
§ 06 — SEE IT ON YOUR WORKFLOW
See a signed Evidence Pack on your own workflow.
Bring a model and a request you actually run — we’ll walk the pipeline and the proof end to end, and tell you straight where Operanta fits and where it doesn’t.