Six controls to establish before AI scales

Financial institutions often discover AI through tools rather than through policy: an employee adopts a general assistant, a supplier adds a model-driven feature, or a team tests an automated decision. The control challenge is to make those uses visible and govern them in proportion to their effect on customers, operations, and obligations.

Technology-neutral does not mean control-light

FINMA’s Guidance 08/2024 says that Switzerland had no AI-specific legislation at the date of the guidance, while technology-neutral, principle-based financial-market requirements already covered risks arising from AI. It expects supervised institutions to consider how AI changes their risk profile and align governance, risk management, and control systems accordingly.¹

The guidance identifies model risks such as robustness, correctness, explainability, and bias; data-security, quality, and availability risks; IT and cyber risks; third-party dependencies; and legal and reputational risks.¹ FINMA later summarised its technology-neutral approach as same business, same risks, same rules.²

That principle is a useful design test: governance should follow the business effect of the use, not the novelty of the model.

Maintain an inventory that describes the real use

Record more than the model or vendor name. A useful inventory identifies the business purpose, process, accountable owner, users, affected customers or employees, input and output data, provider and deployment model, jurisdictions, decision influence, integrations, and current lifecycle state.

Include embedded and indirect AI: vendor features, analytics tools, employee assistants, code-generation tools, fraud models, document processing, and customer-facing systems. If a material use is not visible, it cannot be classified, reviewed, monitored, or retired coherently.

Assign an accountable owner and decision rights

Each material use needs a business owner who can explain its purpose, accept its residual risk, fund its controls, and decide whether it remains suitable. Technical, data, security, legal, compliance, model risk, procurement, and operational teams may contribute, but shared contribution should not obscure decision ownership.

Define who may approve a pilot, production use, material change, exception, suspension, and retirement. Higher-impact uses should have stronger independence between development, validation, approval, and monitoring.

Trace data, model, and provider provenance

Document where inputs originate, whether their use is permitted, how quality is assessed, which model or service version is used, what the provider may retain, where processing occurs, and which downstream components influence the output. The organisation also needs a process for provider and model changes.

This is especially important for general-purpose and externally hosted models, where data handling, model updates, subcontractors, technical restrictions, and monitoring evidence may sit outside the institution’s direct control.

Validate the use—and define human authority

Validation should test the system in its intended context, not only a benchmark. Depending on materiality, that can include accuracy, robustness, harmful bias, explainability, privacy, security, reproducibility, failure modes, override, and performance across relevant customer or transaction conditions.

“Human in the loop” is not a complete control. Specify what the person sees, what they are qualified to assess, whether they have time and authority to disagree, how overrides are recorded, and when a decision must be escalated or made without the AI output.

Monitor operation, incidents, and change

Agree indicators before launch: input drift, output quality, exceptions, overrides, complaints, incidents, security events, provider changes, and control failures. Define thresholds, reporting frequency, escalation, suspension, recovery, and revalidation triggers.

The NIST AI Risk Management Framework organises its voluntary core around four functions—Govern, Map, Measure, and Manage—and treats governance as cross-cutting across the lifecycle.⁴⁵ The framework is not sector-specific and is not a substitute for applicable financial regulation, but its lifecycle logic is useful for turning policy into operating practice.

Make literacy specific to role and use

Article 4 of the EU AI Act requires providers and deployers to take measures, to their best extent, to ensure a sufficient level of AI literacy for staff and others operating or using AI on their behalf. It expressly connects literacy to knowledge, experience, education, training, context, and affected persons.³

A general awareness course is therefore only one layer. A board member, procurement lead, model developer, customer-service user, validator, and control owner need different competencies. Training should cover the actual system, its limits, acceptable use, data handling, human responsibilities, escalation, and incident response.

A concise approval record before scale

Before a material AI use moves beyond controlled testing, the approving body should be able to answer:

• What business purpose and decision does the system support?
• Who owns the outcome, control environment, and residual risk?
• Which data, models, providers, versions, and locations are involved?
• What validation supports the intended use and affected population?
• Where does human judgment enter, and can it change the result?
• How will operation, change, incidents, and retirement be managed?
• What role-specific literacy is required before access is granted?

The control set should remain proportionate. The objective is not to apply the heaviest process to every assistant or experiment. It is to make low-impact use easy to govern, material use hard to approve without evidence, and changing risk visible throughout operation.