Skip to main content

Finsight AI-Control

Governed AI decision-making for financial institutions

Regulators expect financial institutions to govern how AI is used: which models process which data, which tools an agent can invoke, when human approval is required, and how to prove — with auditable evidence — that controls were actually enforced. Most governance tools stop at documentation. They define policies. They can't prove a control ran and was enforced at the point of decision.

What AI-Control Provides

Core capabilities that turn governance requirements into active, evidence-bearing runtime controls.

📋
01

Regulatory Requirements Management

A structured, versioned catalogue for regulatory obligations, internal policies and client-defined requirements. Map them to AI use cases and control objectives — making governance intent explicit, traceable and auditable.

Governance
🎛️
02

Control Execution

Intercept AI calls at defined control points — before provider calls, tool invocations or external actions — resolve the active governance snapshot, evaluate bound controls, and return a binding decision. Approval gates ensure high-impact actions require human sign-off before they proceed.

Runtime
📡
03

Monitoring & Investigation

Capture execution telemetry, detect anomalies, create linked incident records, and support investigation with full audit trails — connecting observed behaviour back to the governance configuration that was active at the time.

Oversight
🧾
04

Evidence & Decision Lineage

Every decision carries the complete chain — which requirement informed which control, which control produced which outcome. Evidence is delivered to customer-owned storage through a pluggable evidence sink.

Audit

How It Works with AI-Foundry

AI-Foundry and AI-Control are independent products that integrate at arm's length through the public Python SDK and REST API.

How AI-Control works with AI-Foundry: AI-Foundry provides the governed semantic foundation and evidence-aware capabilities; AI-Control provides the independent governance and runtime-control layer

Architecture

Three layers — Application, Runtime, and Governance Foundation — connected by public APIs and bindings.

Finsight AI-Control architecture: Application layer (use case management, regulatory reference view, control configuration, decision and evidence review) → Runtime (snapshot resolver, binding resolver, executor, decision resolver, approval coordinator, obligation coordinator, enforcement processor, evidence builder) → Governance Foundation (regulatory reference catalogue, requirement catalogue, control template catalogue, mappings, use case configurations, snapshots)

Key Architectural Decisions

Six architecture decision records that define AI-Control's design constraints.

No Policy Layer

Controls execute directly. There is no Policy DSL, no REGO, no CEL, no visual rule builder. Control templates are parameterised; the platform owns the execution logic.

Immutable Snapshots

One evaluation = one governance snapshot. Configuration changes create new snapshots — they never affect in-flight evaluations. Every snapshot has a SHA-256 fingerprint.

Customer-Owned Evidence

AI-Control builds evidence records. The customer stores them via an EvidenceSink protocol — their Splunk, their Elastic, their object storage. No hosted multi-tenant evidence platform.

Three-Dimensional Decisions

Not a flat ALLOW/DENY. Every decision carries: outcome + approval requirements + obligations. A DENY with obligations says "blocked for now, but here's what must change."

Fail-Closed

Any governance error — unavailable configuration, broken snapshot, unreachable evidence sink — blocks the operation. Default is safety.

Zero Dependency on AI-Foundry

AI-Control is an independent product. Architecture tests verify zero imports from AI-Foundry across all 64 platform files.

Governance Foundation

Governance configuration is compiled into an immutable, fingerprinted snapshot before activation — one evaluation, one governance state.

Governance foundation chain: regulatory references → requirements → control templates → configured controls → control bindings → governance snapshot

The chain is explicit: a regulatory reference points to a requirement like "high-impact AI actions require human oversight." That requirement selects controls like "human approval required" and "segregation of duties." Those controls are bound to specific control points. When the snapshot is activated, the runtime evaluates controls against that active snapshot — and the evidence record captures every link in the decision chain.