Platform Platform
System
ConceptsEnginePolicy as codeDeclarationsSafe changeGatewaysIntegrationsObservabilityAdministrationSecurityHuman reviewAudit and evidenceData retentionSecrets and data classification
Controls
Registries and documentationAuthentication and authorizationInjection detectionData redactionCode fingerprintingRole and judge checksContent classificationSpend and loop limitsBusiness rules
Solutions Solutions
By what you do
Sell into the enterpriseControl the AI you run
By industry
Financial servicesDigital assetsInsuranceHealthcareLegalUser-generated content
By discipline
AI governanceTrust and safetyRisk and compliance
Cases Cases Embedded control planeSource-code leakTrading agents over MCPLive firehoseRefund assistant
Compare Compare LiteLLMNVIDIA NeMo GuardrailsOPAROOSTAgent Governance Toolkit
Resources Resources
Guides
Enterprise review questionsPrompt injectionAgent and control layerAgent architecturesDecision system mapAI control maturity model
Standards
Standards OWASP Agent Control StandardEU AI ActPMI AI standardNIST AI RMFERC-8004
Book a demo
Solutions · By discipline

Risk and compliance

The risk comes from the consequence. Money moves, a claim is denied, a sanction is breached, a limit is passed. Not every business rule belongs in a central engine; most are fine where they are. These are the ones where being wrong costs something you cannot get back.

You have run this discipline for twenty years

Write a candidate rule, test it against history, run it beside the rule in force, compare, get it approved, promote it, and show an examiner every step. Model risk management has worked this way since long before anyone deployed an agent.

What has changed is that the thing making the decision is now an agent, and your existing framework does not reach it. Supervisory guidance on model risk was written for models that score.

The Federal Reserve's SR 26-2, which replaced SR 11-7 and SR 21-8 in April 2026, states in footnote 3 that generative and agentic AI models "are not within the scope of this guidance" — and in the same footnote that your own practices "should guide the determination of appropriate governance and controls for any tools, processes, or systems not covered in this document."

We bring the practice your risk team already runs to the layer where the agent acts.

The part your framework cannot reach

A decision here runs on one of three things: a rule, a model's judgment, or a person. You already know how to govern the first and the third. The second is the one your framework was never written for.

We do not validate the model. We stop it from being the decision.

A classifier or a judge produces a signal — a number, a label, a yes or no. That signal arrives attached to the event, and is recorded with the value it had. What acts on it is a rule: a threshold, a combination, a route to a person. The rule is deterministic, versioned and frozen, and it is what decided.

How much determinism you get is your choice, made per rule rather than per product.

You sendThe rule doesWhat you get
everything on the event, scores includedreads only what arrivedfull determinism: the rule reads only what the record already holds
the event alonefetches a score, a classifier, or a model through a function you writefreshness and reach; the decision is proven by its record rather than by re-running it
a mix, which is most systemsboth, rule by rulefull determinism where it is worth paying for, and capability everywhere else

That choice is a materiality judgment, and it is yours. For the decision an examiner will read back to you, it is worth putting every input on the event. A rule deciding whether a support reply sounds rude is not. Your risk function already makes this call about its own models; here it is explicit, per rule, and recorded.

Either way the record holds the value that was used, so the question "what did it see when it decided" always has an answer, even where the answer cannot be recomputed.

What you can test before promoting

The changeHow you validate it
A threshold on a model scorebacktest the candidate against the recorded signals: same model outputs, new rule, every decision that flips
Two competing thresholdschampion and challenger on a deterministic traffic split, or one as a shadow arm that acts on nothing
Swapping the classifier itselfrun it in shadow beside the classifier you use today and compare the decisions the two produce, not the scores
The classifier's own accuracy and driftyours. That is model validation, it belongs to your model risk function, and we do not do it

For that last row we give you the evidence: every signal value recorded beside the decision it produced, across your whole history, exportable. Your validation team has been asking for that dataset about their existing models for years.

An examiner asking "how do you govern the generative part" gets a straight answer: it is an input, here is what it said on every request, here is the versioned rule that acted on it, and here is what changed the last time we moved that rule.

What the discipline is made of

Controls. Business rules for thresholds, counters and external scores. Limits and stops. Authorization for the chain where every action is permitted on its own and the sequence is not. Registries and documentation for what exists and what governs it.

System. Safe change — the backtest against your own recorded history is the center of this discipline. Human review for approvals and referrals. Audit and evidence for the record that has to survive being questioned.

Where it applies

Financial services, digital assets, insurance, and legal.

Book a demo