The previous article discussed Finsight AI-Foundry and the foundations required to make financial meaning, evidence and reusable capabilities available to AI applications.

This article focuses exclusively on Finsight AI-Control.

As with the previous article, it is not intended to be a user guide or a detailed product manual. Formal documentation covering configuration, APIs, administration and integration will be published separately on the Finsight Technologies website.

Instead, this article discusses the problem AI-Control is intended to solve, the principles behind its design and why its main components have been separated in the way they have.

The central question is:

How can governance remain active when an AI system is actually executing?

Governance intent does not automatically govern execution

Financial institutions already have substantial governance structures. They assess risks, approve use cases, assign accountable owners, establish requirements, record controls and retain evidence.

These activities are essential, and AI-Control is not intended to replace them. However, much of this governance exists outside the systems that execute AI workloads.

A governance document may state that sensitive information must not be sent to an unapproved external model provider. But the document does not inspect the request immediately before the provider call takes place.

A risk assessment may conclude that a particular external action requires human approval. But the assessment does not automatically prevent the action while that approval is still outstanding.

A control register may require evidence retention. But the register does not necessarily preserve the precise execution context, active governance version, control results, approval outcome and enforcement decision associated with each operation.

This creates a gap between:

governance as documented

and

governance as executed

The problem is not that institutions lack governance intent. The problem is that governance intent is often not represented in a form that can participate directly in runtime execution.

Finsight AI-Control is designed to address this gap.

It turns governance requirements into configured controls, evaluates those controls at defined moments in the execution lifecycle and returns decisions that the calling system can enforce.

The core flow is:

Regulatory and internal references
→ Requirements
→ Controls
→ Control points
→ Runtime decisions
→ Enforcement
→ Evidence

This flow is the central organising principle of AI-Control.

AI governance should remain active at runtime

Traditional governance processes often concentrate on what happens before deployment. A use case is documented. Risks are assessed. Controls are agreed. Approval is granted. The system is then allowed to operate.

But AI execution is dynamic.

The model provider may change. Different information may be included in individual requests. A tool may be invoked for an unexpected purpose. A workflow may progress from internal analysis to an external action. The evidence available at runtime may be weaker than expected.

A use case that was appropriately approved in principle may therefore still propose an operation that should not be permitted in a particular context.

This is why governance cannot stop at approval. It must remain capable of influencing execution.

AI-Control places controls at explicit points where the risk or consequence of an operation can materially change. It evaluates the actual provider, tool, action, data classification, caller, environment and available evidence rather than relying only on the original description of the use case.

The objective is not to make every AI operation bureaucratic. It is to ensure that important governance requirements remain connected to the operations they are intended to govern.

The use case is more important than the model alone

A common approach to AI governance is to organise everything around a model.

Which model is being used? Has the model been approved? What are its limitations? When was it last reviewed?

These questions remain relevant, but a model by itself is not the complete unit of risk.

The same model may be used to summarise an internal document, investigate a failed payment, recommend a corrective action or initiate a change in an operational system.

The underlying model may be identical, while the purpose, data, users, potential consequences and required controls are completely different.

AI-Control therefore treats the AI use case as the primary governance context.

The use case establishes why the AI system exists, who owns it, which information it may access, which providers and capabilities it may use, which actions it may propose and in which environments it is permitted to operate.

This allows requirements and controls to be applied to the actual purpose and operating context rather than to the model in isolation.

The approach also supports change more effectively. A provider can be replaced without redefining the entire use case. A new capability can be added and governed within the existing context. A production environment can apply stronger enforcement than a development environment.

The governance boundary remains centred on what the system is trying to accomplish.

Requirements must become executable controls

A requirement describes what must be achieved. For example, sensitive data must only be processed by approved providers, high-impact external actions must receive human approval, or specified evidence must be retained after execution.

But a requirement does not automatically explain how it should be evaluated at runtime. AI-Control therefore connects requirements directly to controls.

A control represents an executable governance decision pattern. It receives a defined runtime context, evaluates that context and returns a structured result.

In the AI-Control design, most controls are parameterised templates rather than arbitrary executable code.

For example, an institution can configure which providers are approved, which regions are permitted, which classifications require masking and which actions require approval. The underlying control behaviour remains a stable part of the product.

This is deliberately narrower than building a general-purpose policy engine. AI-Control is not intended to support an unlimited expression language through which every form of business logic can be embedded in governance configuration. That would increase flexibility, but it would also make the product more difficult to validate, secure, explain and operate.

Instead, AI-Control uses focused control templates for common governance requirements, composite controls where several results must be combined, and trusted client handlers where institution-specific logic is genuinely necessary.

This preserves a clear distinction between configurable governance and arbitrary application code.

Reusable governance meaning and client configuration should remain separate

Some governance requirements are broadly reusable.

Expectations relating to human oversight, data protection, provider approval, access control, evidence retention and segregation of duties are not unique to one use case or one institution.

However, their application is institution-specific. Different organisations may select different providers, classify information differently, assign different approval roles or apply different controls in development and production.

AI-Control therefore separates the reusable governance foundation from client governance configuration.

The governance foundation contains references, requirements and control templates. It describes the reusable meaning and behaviour from which governance can be configured.

Client configuration selects the requirements relevant to a particular use case, configures the necessary control parameters and binds the controls to runtime control points.

This separation allows reusable definitions to evolve without embedding one institution’s organisational structure or technology choices in the product core. It also avoids the opposite problem: copying common requirements into every use case and allowing them to drift independently.

Shared governance meaning remains reusable. Client-specific application remains explicit.

Governance state must be stable during evaluation

Governance configuration changes over time. Approved providers change. New restrictions are introduced. Control parameters are updated. Requirements become effective or expire. Use cases move between development, testing and production.

Runtime evaluation should not operate against a changing collection of draft definitions.

If governance configuration changed halfway through an execution, different steps could be evaluated under different rules. It would then become difficult to reproduce why a decision was made or determine which requirements actually applied.

AI-Control therefore compiles validated configuration into an immutable GovernanceSnapshot.

A snapshot represents one resolved governance state for a particular use case and environment. It contains the requirements, configured controls, bindings and versions needed for runtime evaluation. Once activated, that snapshot becomes the stable governance basis for the use case.

Each evaluation uses one immutable snapshot. This supports consistency and reproducibility. It also makes controlled activation, rollback and effective-time handling possible. Most importantly, every material decision can identify exactly which governance state was active when the decision was made.

This is the governance equivalent of using a stable semantic snapshot in AI-Foundry. Draft configuration remains editable. Active runtime state remains immutable.

Control should be applied where risk becomes concrete

Governance becomes operational only when it can intervene at meaningful moments.

AI-Control defines standard control points, such as:

• BEFORE_AI_PROVIDER_CALL
• BEFORE_TOOL_INVOCATION
• BEFORE_EXTERNAL_ACTION
• AFTER_EXECUTION

These control points do not represent arbitrary stages in a generic workflow. They correspond to different kinds of risk.

Before an AI provider call, the important questions concern the provider, model, region, information being sent and whether masking or approval is required.

Before a tool invocation, the focus shifts to whether the capability is permitted, whether the caller can access the target resource and whether the request remains within the approved scope of the use case.

Before an external action, the consequences become more significant. The operation may modify data, update a workflow, communicate externally or trigger a downstream process. Human approval, stronger identity checks or segregation of duties may therefore be required.

After execution, the concern is whether required obligations were satisfied, whether the expected evidence was produced and whether the outcome requires review or escalation.

The control point determines what context is relevant and what form of decision is needed. This is more precise than applying a single generic “AI safety check” to every operation.

A provider call, a data query and an external action are not equivalent. They should not be governed as though they create the same risk.

A governance decision is more than pass or fail

A simple boolean response is often insufficient for runtime governance.

An operation may be permitted but require a warning. It may be safe only after approval. It may be allowed on the condition that additional evidence is retained. It may need to fail closed because the control could not reach a reliable conclusion.

AI-Control therefore returns a structured runtime decision.

Depending on the evaluated controls, the decision may permit the operation, permit it with a warning, require approval, impose an obligation or block execution. The decision describes what the calling system is allowed or required to do next.

This is an important distinction. A control result reports what a control found. A runtime decision determines the consequence of those findings.

Several controls may contribute to one decision. A provider may be approved while the region is prohibited. A tool may be permitted but the caller may lack the required role. An external action may be valid in principle but still require human authorisation.

AI-Control resolves these results into one binding outcome for the calling system. The aim is not simply to classify risk. It is to make governance operational.

Uncertainty must have an explicit outcome

AI systems operate in environments where information can be incomplete.

A control handler may be unavailable. An identity service may not respond. A data classification may be missing. Evidence may be insufficient to determine whether an operation is safe.

In these situations, treating the absence of a negative result as permission would be dangerous. AI-Control therefore requires failure behaviour to be explicit.

For some controls, an unavailable result may produce a warning. For more critical controls, the correct outcome may be to block the operation because a safe decision cannot be made. This is often described as failing closed.

The principle is broader than technical error handling.

Uncertainty should itself have a governed consequence.

The system should not silently downgrade a control, bypass it or simulate a successful result simply because the expected dependency is unavailable.

The decision must reflect what is actually known.

Human judgement remains part of governance

Not every material operation can or should be decided automatically. Some actions require accountability, contextual judgement or formal authority that cannot be delegated to a control template.

AI-Control treats approval as a first-class runtime outcome rather than an informal process outside the decision model. When approval is required, the proposed operation remains unresolved until the appropriate response is available.

The approval can be associated with a defined role, scope, expiry time and evidence package. The result then becomes part of the final decision lineage. This avoids reducing human oversight to a user-interface button placed in front of an otherwise uncontrolled process.

The approval is connected to the specific operation, the active governance snapshot, the evidence available at the time and the identity of the approving party.

Human involvement therefore becomes part of the governed execution record.

Evidence is part of governance, not an afterthought

Governance is credible only when its decisions can be explained and reconstructed.

A record stating that an operation was permitted or blocked is not enough. An institution may need to know which use case was active, which governance snapshot applied, which control point was evaluated, what execution context was provided, which controls contributed to the outcome, whether approval was required and whether the final decision was enforced.

AI-Control therefore treats decision evidence as a first-class runtime product.

The evidence establishes a lineage from the use case and active snapshot through the control evaluations, runtime decision, approval or obligation and final enforcement outcome. This makes it possible to answer questions such as:

• Why was this provider call permitted?
• Which control caused the operation to be blocked?
• What information was available when the decision was made?
• Who approved the exception?
• Was the decision enforced?
• Were the resulting obligations completed?

These are not merely audit questions asked after an incident. The ability to answer them is part of operating an accountable AI system.

AI-Control should remain independent of the AI platform

AI-Control can govern operations initiated through Finsight AI-Foundry, but it is not an internal subcomponent of AI-Foundry.

This independence is deliberate.

A system responsible for exposing and executing AI capabilities should not necessarily be the sole authority deciding whether its own operations are permitted.

An independent control boundary provides clearer responsibility and allows the same governance mechanism to apply across multiple AI platforms. A financial institution is unlikely to use one model provider, agent framework or application architecture for every AI use case.

AI-Control can therefore govern external assistants, third-party copilots, model platforms, workflow tools and institution-specific AI applications, provided that they can submit the necessary execution context and enforce the returned decision.

The product boundary is not defined by where the AI workload was built. It is defined by whether the operation can be governed through a structured runtime decision.

AI-Control does not replace the wider governance estate

AI-Control is not a complete enterprise governance, risk and compliance platform. It does not replace policy-management processes, model-risk governance, data governance, identity and access management, security monitoring, operational-risk systems or human accountability.

Those responsibilities already exist and remain necessary. AI-Control addresses a narrower but important problem:

How do approved governance requirements remain connected to actual AI execution?

It provides a runtime bridge between governance definitions and operational behaviour. Existing systems can continue to define ownership, maintain risk assessments, manage identities, store evidence and operate approval workflows. AI-Control makes their relevant decisions and information available at the point where an AI operation is about to occur.

Its value comes from connecting the governance estate to execution, not from attempting to replace the entire estate.

From documented governance to governed execution

The central principle behind Finsight AI-Control is straightforward:

AI governance should not stop at documentation and approval. It should remain active during execution.

Reusable governance references and requirements describe what must be achieved.

Configured controls translate those requirements into executable decision patterns.

Bindings place the controls at the points where risk becomes concrete.

Immutable governance snapshots ensure that each evaluation uses a stable and identifiable governance state.

Structured decisions tell the calling system what may happen next.

Approvals and obligations make human judgement and conditional permission explicit.

Enforcement outcomes show whether the decision was applied.

Evidence preserves the complete decision lineage.

Together, these elements turn governance intent into governed execution. Finsight AI-Control does not attempt to eliminate judgement, uncertainty or institutional responsibility. It provides a structured way to represent them, apply them and retain evidence of how they influenced AI behaviour.

That is the role of Finsight AI-Control.

• *AI-Native Financial Data Foundation