Release Gates for Regulated AI: Evaluation, Pre-Deployment Certification and Live Oversight for Customer-Facing Agents

Release Gates for Regulated AI: Evaluation, Pre-Deployment Certification and Live Oversight for Customer-Facing Agents

Most regulated firms can describe their AI agent's capabilities. Far fewer can say what evidence it must produce before it faces a customer, who decides that the evidence is enough, and what happens when something changes after launch. That gap is where agent projects stall between pilot and production. Our position is that a customer-facing agent should be released the way any consequential change to a regulated service is released: through a small number of gates, each with defined evidence, a named owner and the authority to say no. This article sets out five such gates and how to connect them to what regulators have said, without claiming more than the evidence supports.

Why release gates are becoming a product category and a regulatory question

Three developments make this topic urgent, and we describe each carefully.

First, suppliers are turning evaluation and assurance into products. Our competitor intelligence records one provider launching a service covering model evaluation and custom reinforcement-learning environments for generative AI and autonomous agents. Another sells pre-certification of customer-facing AI chatbots and agents, alongside real-time oversight. We have not named either provider, and the descriptions are vendor-authored. Their significance is the category: pre-release testing, certification and live monitoring are now being sold as distinct things.

Second, regulatory interpretation is being automated. An AI compliance platform has acquired a business that supplies machine-readable regulatory interpretation, which the market describes as "compliance as code". We use that single transaction only as a signal that the category exists.

Third, standards and regulators are moving.

• The FCA. In a speech on 19 October, the FCA published examples of good and poor practice in AI, said that AI providers should add disclaimers to AI financial advice and acknowledged agentic finance. According to the reporting and summary we rely on, it is applying existing frameworks, including Consumer Duty and senior-manager accountability, to AI rather than creating new rules for agents. We have not read beyond that summary, so a firm should read the speech and the practice examples itself.
• EN 18286:2026. The European Commission has reported that the first harmonised standard supporting the EU AI Act, on AI quality management, has been published in the Official Journal. The summary we hold says it creates a conformity route for high-risk AI providers, that credit scoring is explicitly in scope and that 2 December 2027 is the dated high-risk application date. We have not read the standard, and we do not summarise its requirements here. UK-only firms should ask their advisers whether and how it applies to them.

None of this tells you exactly what to test. That is the point of a release-gate framework: it gives you a structure that you can adjust as expectations become clearer.

The framework: five gates

The gates are our framework, not a standard and not a regulatory requirement. They are designed for customer-facing agents in regulated financial services, and they move from cheap, early checks to expensive, late ones. A failure at any gate sends the agent back, and a change after release sends it back through the gates that the change affects.

Gate 1: Define the job and the boundaries

Before any test is run, write down what the agent is for and what it must never do. This is the document every later gate refers to.

• the customer journeys it will handle, and those it will not
• the actions it may take, such as answering questions, collecting information or moving money, and the limits on each
• the behaviours that count as failure, for example giving a personal recommendation it is not authorised to give, mishandling a vulnerable customer or misdescribing a fee
• the accountable owner and the date the definition was approved

An agent that cannot be described in a page cannot be tested meaningfully.

Gate 2: Evaluation

Evaluation is the measured assessment of how the agent behaves across a representative set of cases. Three design points matter more than the tooling.

• Build the evaluation set from your own scenarios. Include ordinary requests, awkward ones, complaints, vulnerable-customer cues, attempts to push the agent outside its boundaries and cases where the correct response is to hand over to a person.
• Set thresholds before you test. Decide what pass means for each category of failure. A threshold chosen after seeing the results is a description, not a gate.
• Keep the set separate and versioned. If the team tunes prompts against the evaluation set, it stops measuring anything. Hold back a portion, record versions and re-run the full set after any change.

Evaluation should report by failure category, not as a single score. An average that hides a serious failure in a small category is the most common way a gate gives false comfort.

Gate 3: Sandbox testing

Evaluation tests responses. Sandbox testing tests the agent in the environment it will operate in, connected to realistic versions of your systems.

• Test the permissions the agent holds, and confirm that it cannot take actions outside them.
• Test adversarial behaviour: instructions hidden in customer messages or documents, attempts to extract information and attempts to bypass limits.
• Test failure paths: what happens when a downstream system is slow, wrong or unavailable, and whether the handover to a person works.
• Confirm that every action is logged in a way that lets you reconstruct what happened and why.

The output of this gate is an observed record of behaviour under stress, not a statement of intent.

Gate 4: Certification evidence and sign-off

This gate assembles the evidence into a pack that someone senior can read and sign.

• the approved definition from Gate 1
• evaluation results against the thresholds, by category
• sandbox findings and what was done about them
• known limitations, stated plainly
• the controls that will operate after release and who owns each
• the change history of the model, prompts, tools and data used

Sign-off should be by a named accountable person who has read the pack and who is not the person who built the agent. Risk and compliance should challenge the pack before it reaches that person, and their comments should be kept. Because the FCA is described as applying existing accountability frameworks, we suggest treating the sign-off as an accountability decision with a name attached, and putting the specific allocation to your compliance advisers.

A word on the word "certification". When a supplier sells pre-certification of an agent, it is a service with its own method. Nothing in the material we reviewed treats a supplier's certificate as equivalent to regulatory approval. Treat it as one input to your own evidence, and ask what was tested, on whose data and with what independence.

Gate 5: Staged release and live oversight

Release is the start of a monitored period, not the end of the process.

• Release in stages. Begin with a limited cohort or limited actions, and widen only when live behaviour matches the evidence.
• Monitor against the same measures. Use the categories and thresholds from Gate 2 so that live performance is comparable with what you tested.
• Sample real conversations. Have people review a sample regularly, with extra attention on complaints and vulnerable customers.
• Keep a stop mechanism. You should be able to restrict or switch off the agent quickly, and the person who can do so should be named.
• Re-run the gates on change. A new model version, a changed instruction, a new tool or a new data source can change behaviour. Define in advance which changes trigger which gates.

This article covers the route to release and the first live period. Ongoing operations after production, including governance of a live fleet of agents, is a related but separate subject.

Connecting the gates to FCA and EN 18286 expectations

It is tempting to claim that a framework "meets" a regulator's expectations. We do not, because we have not read the primary sources in depth and because neither the FCA nor the standard, as summarised, tells you to run these five gates. What we can do is show where the gates are likely to produce useful evidence.

• Consumer outcomes. Consumer Duty is an outcomes-focused framework, and the FCA has said it applies existing frameworks to AI. Evaluation categories for vulnerable customers, complaints and misleading explanations are a practical way to generate evidence about outcomes before release. Ask your compliance team how it maps to your own Consumer Duty evidence.
• Accountability. The sign-off in Gate 4 gives you a named decision-maker and a record. Whether and how that fits your firm's senior-manager responsibilities is a question for your compliance function.
• Disclosures. The FCA's comment on disclaimers for AI financial advice was directed at AI providers. If you build on a third-party assistant or model, confirm separately how your own customer communications are handled, and do not assume the provider's disclaimer discharges your duties.
• Quality management. EN 18286 is described as an AI quality management standard. If your firm provides high-risk AI into the EU, read it and map your gate evidence against it with advisers. Until you have done that, say only that your process is designed to be compatible with a quality-management approach, not that it conforms.

Who signs off, and who can say no

A gate with no authority to stop a release is a ceremony. A workable division of responsibility looks like this:

• The product owner proposes the release and owns the definition in Gate 1.
• Engineering owns the tests, the logs and the release switch.
• Risk and compliance challenge the evidence and record their view.
• An accountable senior person, independent of the build team, signs or declines.
• An independent reviewer checks the evidence where the risk justifies it.

Write the right to stop a release into the process, and make clear that declining is expected when the evidence is incomplete.

Compliance as code: automate the checks, keep the judgement

If the thresholds, tests and logs are defined, much of the evidence can be produced automatically as part of the delivery pipeline. A release that fails a threshold is blocked until someone resolves it, and the evidence pack is assembled from the pipeline rather than by hand. This is what we mean by designing compliance in from the start.

Automation has limits. It can check a threshold, but it cannot decide whether the threshold was the right one, and it cannot interpret an ambiguous regulatory expectation. The emergence of machine-readable regulatory interpretation as a product category is interesting for exactly this reason: it will make some checks cheaper, and it will not remove the need for human judgement on what to check.

Buying the tooling: questions for any supplier

If you are considering a supplier's evaluation, certification or monitoring service, treat it as one component of your gates and ask:

• What exactly is tested, on whose scenarios and against what thresholds?
• How independent is the supplier from the system being tested?
• Can you export the evidence and the evaluation sets, or are they locked in?
• Does the service work with your architecture and your data restrictions?
• What does it not cover?

What we do not know

The sources behind this article are a small number of vendor descriptions, one regulator speech as summarised, one standard reported as published and one acquisition. We have not read the FCA speech or EN 18286 in full. We have no measured evidence on how often gates of this kind prevent harm or what they cost. Treat the framework as a structure for your own work and check every regulatory point against the primary source and your advisers.

Where Innovify fits

Innovify is a technology partner with deep expertise in banking, financial services, fintech and insurance. We build for regulated clients rather than being a regulated firm ourselves, and we design compliance in from day one. For customer-facing agents that means the evaluation sets, logging, sign-off points and stop mechanisms in this framework are part of the build, not a late addition. Our AI and ML development work helps businesses build AI-native products with those controls designed in.

If you want to see how an agent behaves with real users before committing to a release, Innovify AI Labs lets enterprise teams run several proofs of concept in parallel, test with real users and finish with a business case ready for funding.

Frequently asked questions

How do you test an AI agent before release in a regulated firm?

Define what the agent may and may not do, then run it through staged gates: an evaluation on your own scenarios with thresholds set in advance, sandbox testing in a realistic environment, an evidence pack reviewed by risk and compliance, and sign-off by a named accountable person. Release in stages and monitor live behaviour against the same measures.

What is an AI agent release gate?

A release gate is a checkpoint that an agent must pass before it moves to the next stage of release. Each gate has defined evidence, a named owner and the authority to stop the release. Our framework uses five: scope, evaluation, sandbox testing, evidence and sign-off, and staged release with live oversight.

Is a supplier's pre-deployment certification enough?

No, treat it as one input. A supplier's certification reflects its own method, and nothing in the material we reviewed treats it as equivalent to regulatory approval. Ask what was tested, on whose data and with what independence, and keep your own evidence and sign-off.

Does the FCA require release gates for AI agents?

We are not aware of anything in the material we reviewed that prescribes release gates. According to the reporting we rely on, the FCA's 19 October speech applied existing frameworks, such as Consumer Duty and senior-manager accountability, to AI and published good and poor practice examples. Read the speech and take advice from your compliance function.

What does EN 18286 mean for UK firms?

It depends on whether you provide high-risk AI into the EU. EN 18286:2026 is reported as the first harmonised standard supporting the EU AI Act, on AI quality management. We have not summarised its requirements, so UK-only firms and EU-facing firms alike should read it with their advisers before drawing conclusions.

Conclusion

Customer-facing agents in regulated firms need a route to release that produces evidence and has a named person who can say no. Five gates provide that structure: define the job, evaluate against thresholds set in advance, test in a sandbox, assemble and sign an evidence pack, then release in stages with live oversight. Connect the gates to the FCA and EN 18286 only as far as the primary sources and your advisers support, automate the checks and keep the judgement, and re-run the gates whenever the agent changes.