Platform · AI Governance

AI Governance.scaleAI Governance & Model / Agent Oversight

Your models and agents are infrastructure now, and they get governed like the rest: inventoried, evaluated, monitored, and connected to the same graph, with a kill switch your risk team holds.

The product, at a glance

What AI Governance is made of.

6 capabilities, and the part of the mechanism this product carries. Every box opens right here, with its full story one tap deeper.

tap any box, or any circle in the mechanism, and it answers right herecontrol what changes

What changes

What changes when this is running.

Not promises of speed, but mechanisms: each of these happens because of how the product works, not because we say so.

The model inventory stops drifting from production, because deployed models, agents, and prompts are discovered through connectors, not self-reported.

Runaway agents stop being a standing fear, because risk holds a kill switch sealed like every other decision.

Data problems reach model owners first, because training data is traced as lineage and drift is watched continuously.

who lives hereModel riskAI teamsanswers toSR 11-7

The product

Govern. Assure. Monitor. Intervene. Prove.

End-to-end, practical governance for AI models, agents and agentic systems. Across the entire lifecycle, from design to retirement, with continuous runtime assurance.

Trust and Scale

Business outcomes

Reduce AI risk and exposure

Increase model and agent reliability

Faster and more confident adoption

Lower cost of incidents and remediation

Stronger regulatory readiness and audit outcomes

Trusted decisions and responsible outcomes

Continuous improvement and resilience

At a glance

AI Governance unifies policy, controls, observability and automation to govern traditional AI, GenAI, and next-generation agentic AI systems.

Govern

Establish policies, standards, roles and risk-based guardrails.

Assure

Evaluate models and agents for safety, quality, fairness and robustness.

Monitor

Continuously observe runtime behaviour, data, tools and outcomes.

Intervene

Detect issues in real time, apply guardrails, escalate or kill.

Prove

Generate immutable evidence and regulatory audit packs.

Trigger events

When an institution reaches for this.

No single inventory of the AI actually running in productionAn agent that can act, with no record of what it was allowed to doDrift found by the business rather than by the team that owns the modelA GenAI copilot approved once and never re-evaluatedAn examiner asking how a model decision was reached, months later

What it does

Seven stages from a use case somebody proposed to a model retired with its evidence intact. Each stage names what has to happen inside it before the next one is allowed to start.

01 · Plan and intakeNothing enters the estate without a use case, an owner and a risk rating.

Use case intake
Risk classification
Data classification
Preliminary impact assessment

Hover, click or use the arrow keys to walk the lifecycle.

The AI control plane

Continuous, independent oversight of AI models, agents and tools in production. Guardian agents sit between what your AI systems try to do and what actually reaches a customer, a system or a ledger. They observe, evaluate and control behaviour while it happens, and write down what they decided.

AI systems and platforms we govern

LLMs and foundation models
Fine-tuned models
RAG systems and vector databases
AI agents, autonomous and semi-autonomous
Copilots and assistants
Tools and functions
MCP servers and APIs
Workflows and orchestrations
Edge and IoT

AI inputs

User or human
Applications
Data sources
APIs and services
Knowledge bases, RAG
Prompts
Tools and functions
External systems

Guardian agents, the independent AI control layerObserveEvaluateChallengeConstrainEscalateInterveneEvidence

Input guards
Output guards
Content filters
PII and secrets detection
Tool and API allow or deny
Data access controls
Grounding requirements
Rate and budget limits
Approval checkpoints
Human in the loop
Policy as code

AI outputs and actions

Responses
Recommendations
Transactions
Automated actions
System updates
API calls
Notifications
Agent-to-agent calls
Reports

Business impact

Customers
Employees
Systems
Financial impact
Operational impact
Regulatory impact
Reputation impact

Audit and evidence, immutable and traceable

Logs and traces
Prompts and responses
Tool calls and actions
Data and retrieval evidence
Evaluations and scores
Decisions and approvals
Incidents and interventions
Lineage and provenance
Evidence packages
Attestations

Pick a guardian to see what it watches and what it can stop.

Twelve independent watchers, each responsible for one thing. A guardian can challenge an action, constrain it, escalate it to a person, or stop it. They are independent of the system they watch, which is the only arrangement an auditor accepts.

Kill switch and intervention

Intervention is multi-level, not a single switch. Impact decides how far up it goes, most incidents stop near the bottom, and every rung is recorded.

Severity

01 · Detect anomaly

A guardian raises something: a breach, an anomaly, an unsupported answer.

Every intervention starts here. Most stop here too.

Climb with the arrow keys, or pick a rung.

AI lineage and provenance

End-to-end lineage of every AI decision and output. A decision traces back through what it affected, the tool it called, the data it read, the retrieval that ran, the prompt it was given and the model that answered, to the use case that was approved in the first place.

01 · Use case

The business purpose the system exists to serve, with its risk rating and its owner.

A chain is a conjunction. Take one link out and see what is left.

This is the thread an examiner walks, and it is a by-product of having been built this way rather than a report anyone runs afterwards.

Key capabilities

AI asset and inventory

Model and agent registry
Use case catalog
Owners and stakeholders
Tool and MCP registry
Risk classification

Risk and classification

AI risk taxonomy
Inherent and residual risk
Impact assessment
Controls and mitigations
Risk register

Evaluation and assurance lab

Quality, safety and robustness
Bias and fairness testing
Red teaming and adversarial tests
Jailbreak and prompt injection tests
Benchmarking and regression

Observability and monitoring

Model and agent health
Inputs, outputs and drift
Retrieval and grounding
Cost, latency and usage
Anomaly detection and alerts

Agent governance

Agent registry and identity
Autonomy and permissions
Tools and memory
Delegation and authority
Agent performance and behaviour

AI supply chain governance

Provider and model risk
Dataset and licence management
Open source risk
Third-party tools and APIs
Vulnerabilities and compliance

Policy and controls

Policy library and standards
Control catalog
Control effectiveness
Segregation of duties
Manual override rules

Incident command centre

Signal correlation
Triage and investigation
Containment and recovery
Root cause analysis and remediation
Post-incident review

Reporting and compliance

Regulatory mapping
Evidence collection
Audit dashboards
Exam-ready packs
Attestations and sign-offs

Where AI governs AI

AI-powered, and every one of them a recommendation rather than a decision.

Guardian agents evaluate behaviour independently of the system they watch

Hallucination checks compare an answer against its own retrieved sources

Anomaly detection on prompts, responses, tool calls and cost

Drift detection on models and on the data beneath them

Signal correlation across incidents that look unrelated

Evidence gaps surfaced before an examiner finds them

Manual and AI-assisted

The same work, split. Everything on the left is something a person does; everything on the right is something the platform proposes, with evidence, for a person to accept. Nothing crosses the line on its own.

Manual

A person does this.

Set purpose, authority and autonomy level for an agent
Write the policies and approval thresholds
Review evaluation and red team results
Approve a release, and hold the kill switch
Investigate an incident and decide the remediation
Attest to control effectiveness

AI-assisted

The platform proposes. A person accepts.

Discover AI assets across the estate
Propose a risk classification and the obligations that apply
Generate evaluation suites and adversarial tests
Watch runtime behaviour and detect anomalies and drift
Challenge an unsupported answer against its sources
Recommend a containment step and assemble the evidence

Principles we live by

The seven

Human oversight
Safety first
Fairness and inclusivity
Privacy by design
Transparency and explainability
Accountability and auditability
Security and resilience

Common use cases

Where institutions start

Governing GenAI copilots and chatbots
Governing autonomous and semi-autonomous agents
Prompt and tool risk management
Preventing hallucinations and unsafe outputs
Data privacy, personal data and intellectual property protection
Bias, fairness and inclusive AI
AI supply chain and third-party model risk
Incident response and kill switch
AI change management and re-certification

Regulatory reporting against

EU AI Act
SR 11-7, model risk management
BCBS 239
NIST AI RMF
ISO/IEC 42001
OSFI guidelines

End-to-end workflow

01Use case intake
02Risk classification
03Guardrail design
04Evaluation and red team
05Approval and release
06Runtime observation
07Guardian evaluation
08Intervention
09Root cause and remediation
10Re-certification
11Retire with evidence

What gets measured

Against your own baseline.

AI governance scoreModels and agents monitoredHigh-risk issues openGuardrail effectivenessCritical controls effectiveEvidence artefacts heldTime to resolve an AI incident

Who it is for

AI and ML model owners and developersAgent owners and stewardsRisk, compliance and legalData owners and stewardsSecurity and privacy teamsAudit and internal auditBusiness users and operatorsExecutives and boards

Integrations

OntaVera CatalogOntaVera LineageOntaVera QualityOntaVera GovernanceOntaVera PrivacyOntaVera RegulatoryOntaVera Trust IntelligenceOpenAI, Anthropic, Llama, MistralBedrock, Azure OpenAI, Vertex AIMLflow, SageMakerDatabricks, SnowflakeLangChain, LlamaIndex, MCP serversServiceNow, JiraEmail, Teams, Slack

Built on the OntaVera platform

Shared by every product in the suite.

Financial ontology and knowledge graph

Metadata fabric and connectors

Policy and rules engine

Workflow and approvals

Audit and evidence, immutable and encrypted

APIs and events: REST, GraphQL

AI and ML services, and model ops

Why OntaVera

Purpose-built for financial services and regulated industries
Governs traditional AI, GenAI and next-generation agentic AI
Guardian agents provide independent, real-time protection
Kill switch and intervention at every level
End-to-end evidence for auditors and regulators
AI-native, policy-driven, automated and explainable

Trust every prompt.Control every action.Prove every decision.

Try it yourself

See AI Governance do real work.

A model reaches production through one gate, and the gate has one key: a current sealed evaluation pass. The kill switch stays with your risk team.

setting the stage…

Inside AI Governance6 sub-modules

You cannot govern AI you have not counted. The registry inventories every model, agent, and prompt across your systems as a governed asset, each with a named owner, a stated purpose, and a risk tier, on the same knowledge graph that already holds your data. When an examiner asks for your model inventory, you point at the graph and the evidence behind every entry.

What you get

One inventory covers every model, agent, and prompt, and each entry carries a named owner, a stated purpose, and a risk tier.

Connector-based discovery reconciles the inventory against deployment evidence, so an unregistered model surfaces as a finding rather than staying invisible.

Risk tiers are derived from what the asset actually touches, including customer data, regulatory numbers, and money movement, and they are never set by hand.

Imported inventories land as claims and are checked against deployment evidence, and an entry with nothing behind it shows as unverified.

Lineage links connect each model to the CDEs and data sets that feed it, on the same graph as the rest of your governance.

Every registration, edit, and retirement is sealed on the hash-chained ledger.

How it works

Discover

Connectors scan your systems for deployed models, agents, and prompts. They read metadata only, and nothing is copied.

Register

Each asset lands on the knowledge graph with an owner, a purpose, and a derived risk tier.

Reconcile

Existing inventory records import as claims and are checked against evidence, so gaps and orphans surface as findings.

Seal

Every change to the inventory is sealed on the hash-chained ledger.

Questions buyers ask

When software gets authority to act9 pillars

Nine pillars hold when software acts.

Model governance asks whether an output is accurate. An agent acts, so the controls have to hold around the run: the identity it borrows, the data it reads, the tools it touches, the changes it quietly accumulates. We pressure-tested this set against the frameworks your risk team already reads: NIST's AI RMF, the OWASP agentic top ten, ISO 42001, and the EU AI Act. We also tested it against the questions a head of model risk actually asks. Nine pillars survived.

01Do we know every agent, and what each may do?

Mandate, inventory & tiering

A registry that finds agents, including the ones business units stand up themselves
A risk tier per agent, set by materiality and autonomy, so scrutiny is proportional, not uniform
Permitted tools and data enforced in the platform and reconciled daily against what was declared
Actions that always need a person, named before the agent ever runs

e.g. A business unit spins up a copilot on a SaaS platform. The registry sweep finds it in days, and it gets a tier before it gets traffic.

02Who is acting, and on whose behalf?

Identity & delegation

A first-class identity per agent, never a shared service account
Short-lived, scoped credentials: nothing standing, nothing stored in a config file
A delegated agent can only end up with less authority than the person it works for, never more
Credentials die when the agent does

e.g. An agent working a steward's queue borrows that steward's scope for exactly one run. Nothing is shared, and nothing outlives the job.

03Is it acting on data it should trust?

Grounded knowledge

An approved corpus with owners and freshness rules, so the agent's reading list is governed
Retrieval that respects the caller's permissions, not the agent's
Provenance on everything it reads and remembers, with memory screened for poisoning
No confident answer from an unowned source

e.g. An agent quotes a policy PDF that was superseded in March. The corpus check catches the stale source before the answer ships.

04Would you defend how it behaves?

Accountable conduct

Declared limits: calls an agent must not make, however well it performs
Fairness tested across the whole trajectory of actions, not just the final output
Explanations a business reviewer can follow, proportionate to consequence
Agent involvement disclosed, with a person reachable behind it

e.g. A triage agent quietly deprioritizes one region's exceptions. Every single call looks defensible. Only the trajectory test sees the pattern.

05Does it do the job right, and does it still?

Proven competence

Every tool and step tested alone, then the whole path end to end
A second-line holdout set, refreshed from production and never used for tuning
The path judged too: right sources, no fabricated figures
Model-as-judge only after the judge is validated against humans

e.g. Two extraction errors cancel out and the total comes out right. The outcome test passes. The step test still fails the run.

06If it's hijacked, how bad is the worst day?

Assume-breach security

A written blast-radius answer per agent: worst case with the credentials and tools it holds
Injection treated as containment, not filtering, including what arrives inside documents
Tools and models pinned and vetted; an updated dependency waits for review
Code execution sandboxed, secrets vaulted, fallback and safe shutdown rehearsed

e.g. The worst-day question is answered in writing: fully hijacked, the most this agent can move is a draft into a review queue.

07Can you stop it, and is oversight still real?

Live control

Consequential steps hold for a person who accepts, edits, or rejects
The checkpoint itself is watched: approval speed and rates that look like rubber-stamping get flagged
Stopping at three scopes: one run, one agent class, one whole domain
Loop, retry, and spend budgets, with circuit-breakers so one agent's failure doesn't cascade

e.g. Approvals start clearing in four seconds flat. That's a latency tax, not oversight, and it's flagged before your auditor finds it.

08Can you replay any run, and trust the replay?

The sealed run record

Traces written by the platform, never by the agent, append-only and tamper-evident
Every step, tool call, human decision, output, and cost, per run
Multi-agent chains stitched into one causal record
Production runs sampled and re-scored, with drift thresholds per agent

e.g. The examiner asks why Tuesday's entry changed. You replay the run from a record the agent couldn't touch: prompt, tools, and sign-off.

09Is what's running the thing you approved?

Change & lifecycle integrity

An agent is a composite of model, prompt, tools, corpus, and guardrails, and every part is version-pinned
A substantial change to any part goes back through approval, with autonomy reset until evidence
Bought agents held to the same bar as built ones, with telemetry and exit in the contract
Retirement is a decision: credentials revoked, record archived

e.g. The vendor swaps the base model overnight. The pinned version keeps running. The new one goes back through approval.

The run record

Authority is stamped into the record. Evaluation is scored against it. Runtime controls write to it. Assurance reads from it.

On OntaVera, the run record lives on the same sealed ledger as the rest of your governance, so you answer an auditor by querying the record, not by reconstructing what happened.

Count them first

You can't govern agents you haven't found. The registry comes before the controls.

Autonomy is earned

An agent runs at the tier its evidence supports. Widening that tier is a governed change, not a config flip.

Know where coverage ends

An honest map of what isn't covered yet beats a comfortable assumption that it is.

The AI governance framework9 domains

Nine domains keep your AI inside its authority.

This is the operating framework the AI Governance module implements. It works for any business function that runs on AI, from risk and operations to the front office. Control depth scales with use-case risk, autonomy, data sensitivity, and business impact.

FoundationAccountabilityRisk appetitePolicies & standardsData & privacyModel & agent governanceOperating model & culture

Governance, inventory & accountability

Executive ownership and three lines of defense
Every AI, model, and agent inventoried
Decision rights, exceptions, attestations

Use-case intake & risk tiering

One front door for every AI use case
Risk tiers by materiality and autonomy
Restricted and prohibited uses named up front

Data, knowledge & privacy controls

Trusted data, quality, and lineage under every model
Retrieval, memory, and records controls
Access, confidentiality, and retention

Model & agent lifecycle

Design, build, buy, or procure: one process
Testing, validation, and red teaming
Versioning, change, and re-approval

Agentic action controls

Identity, least privilege, and allowlists
Action limits, approvals, and segregation
Human checkpoints, kill switch, rollback

Security & operational resilience

Prompt injection, secrets, supply chain
Sandboxing, incident response, fallback
Continuity, recovery, safe shutdown

Observability, monitoring & evidence

Prompt, data, model, and action traces
Quality, drift, anomalies, and outcomes
Replayable evidence and immutable logs

Human oversight & business controls

Maker-checker, limits, and approvals
Reconciliation and post-action validation
Override, escalation, accountability

Third-party & regulatory readiness

Provider and open-source due diligence
Concentration, portability, and exit
Control mapping, evidence, and audit

The operating loop: every use case, cradle to retirement

1Intake2Classify3Design or procure4Test & validate5Authorize6Deploy7Observe & control8Reapprove & improve9Retire

Why it matters

Protects the decisions, reports, and customers your business runs on
Keeps AI and agents inside approved authority before they act
Catches errors, drift, and incidents before they reach the business
Gives risk, audit, and regulators end-to-end evidence
Scales trusted AI without giving up speed or control

Try it yourself

Where would your agent land?

Answer four questions, and see how the platform would score them. The tier derives from the answers. That is the whole idea.

Autonomy tier finder · four questions · illustrativeautonomy is earned, not configured

01What does the agent's work touch?

02If it gets one wrong, how hard is the undo?

03What data does it read?

04How much freedom does the use case want?

0 / 4 answered

Answer all four and the tier derives itself, the same way it would in the product.

Asked about AI Governance

5 questions

Most model risk programs live in documents and a hand-maintained inventory, and they were built before agents and prompts existed. This module puts models, agents, and prompts on the same knowledge graph as your data, discovers what is actually deployed through connectors, and gates serving on current evidence, so the inventory stops drifting from reality. Your SR 11-7 process is not replaced; it gets a live evidence base underneath it.

See the AI Governance module →

It connects to the systems where your models and agents already run and reads metadata only, so nothing is copied and nothing is retained. Deployment records, production signals, and lineage arrive through connectors, and the platform derives everything else from that evidence. The architecture page walks through exactly what moves and what stays put.

Read the architecture →

Both work in it, and the roles are explicit. Model owners keep their entries current and respond to findings, and the second line reviews validations and holds the kill switch. Because every model links by lineage to the CDEs and datasets that feed it, the data office sees model exposure on the same graph it already governs, and nobody retypes anyone else's work.

Agents do the watching and the proposing, never the deciding. They surface drift, raise stop proposals when monitoring breaches a threshold, and propose responses to findings, but they cannot approve a validation, stop or restart a model, or change a prompt, because each of those takes a named person acting through the one decision door. They cannot close an issue either, since closure requires evidence that the problem was actually fixed.

The module fails closed rather than assuming the best. An unregistered model surfaces as a finding, an entry without evidence shows as unverified, a lapsed evaluation blocks serving, and a model that goes quiet loses standing automatically. Missing is treated as a defect to resolve, never as a quiet pass.

Stronger together

One shared record, so products compound.

Every product you add makes this one smarter, because they read and write the same governed record. Start where it hurts most; nothing you adopt later starts from zero.

AI Governance + Lineage

Add lineage and every model traces to the exact datasets and critical elements that feed it.

AI Governance + Regulatory

Add evidence and model validations, approvals, and kill decisions land in the same exam-ready record.

Getting started

Start small, and prove it on your own systems.

Most banks start with one priority report and five source systems, live in 90 days, then bring in more of the platform behind exit gates they approve. AI Governance is part of that first conversation.

Keep exploring

← Data Productsavailable now Reference Data →arriving The engines underneatharchitecture How decisions workframework

The next step

Start with proof, not a promise.

There are three ways in, and each one earns the next. You approve the exit criteria before we spend any more of your time or budget.

A 60-minute working session

Bring one report that is expensive to prove. We walk the mechanism against it. Nothing is required from your side.

A two-week guided sandbox

Your team works hands-on against a synthetic sample bank. It requires zero access to your systems and zero procurement.

A six-week proof on your systems

We use read-only metadata across five systems and one priority report, scored against criteria both sides sign first. The decision it produces is yours.

Book a working session See the adoption path