Most financial services firms start their agentic AI journey with a proof of concept. The agent completes tasks, executes multi-step workflows, and impresses stakeholders in a controlled demo. Then the compliance team reviews it. Within weeks, the project stalls: there are no audit logs, the decision path is opaque, the agent can trigger actions with no human checkpoint, and nobody can explain what it did or why.
This is not a technical failure. It is a sequencing failure. Governance was treated as a phase-two concern, and phase two never arrives.
Agentic AI in financial services cannot follow the same development path as a customer-facing chatbot or a recommendation engine. The stakes are different. An agent that books trades, processes claims, or authorises credit decisions is operating in a regulated environment where errors carry legal liability, not just reputational risk. Building trust into these systems from the start is not overcaution: it is the baseline for operating in this sector.
This article sets out a compliance-first implementation framework for CTOs and COOs in financial services who are moving agentic AI from pilot into production.
Why Agentic AI Creates a Different Risk Profile
Standard AI models are passive. They receive an input, return an output, and stop. An agentic system is different: it plans, takes actions across tools and systems, persists state, and may operate over extended time horizons with minimal human intervention.
That autonomy is what makes agents valuable. It is also what makes them harder to govern.
In regulated financial services environments, three properties of agentic systems require specific control mechanisms:
Multi-step decision chains. An agent performing a KYC workflow may access customer records, call an external data provider, apply a scoring model, and update a case management system. Each step is individually auditable, but the chain as a whole creates a compound decision that regulators will scrutinise as a unit.
Variable execution paths. Unlike a deterministic business rule engine, an agent can take different routes to the same outcome depending on context. This makes pre-certification difficult and post-hoc explanation necessary.
Tool and system access. Agents in production environments typically have write access to databases, APIs, and downstream services. An error does not just produce a wrong answer: it can modify data, trigger transactions, or affect customers.
The FCA, ECB, and other regulators are already examining how firms govern AI decision-making. MiFID II, SR 11-7, and the EU AI Act all have implications for how automated systems in financial services must be documented, tested, and monitored. Building a trustworthy agentic system in this context means treating auditability, explainability, and controllability as first-class engineering requirements.
The Compliance-First Framework
A compliance-first approach does not mean building slowly. It means defining governance architecture before writing agent logic, so that control and observability are structural, not retrofitted.
The framework has four implementation phases.
Phase 1: Define Boundaries Before You Build Agent Logic
Before writing a single agent prompt or selecting an orchestration library, define the operational envelope. What tasks is this agent authorised to perform? What systems can it access? What outputs trigger mandatory human review? What is the escalation path when confidence is low?
This is governance-by-design. In practice, it means producing a control specification alongside the technical design document. The control specification should cover:
- Permitted actions and explicit exclusions
- Data access scope, including personal and sensitive data categories under GDPR
- Thresholds that trigger human-in-the-loop review
- Logging requirements for each action category
- Rollback and correction procedures
Getting this document agreed by compliance, risk, and legal before development begins is not bureaucratic overhead. It eliminates the most expensive rework in agentic AI delivery: discovering that the system architecture cannot support an audit requirement after it has been built.
Phase 2: Start With Bounded Autonomy
The natural instinct is to build a capable agent first and add controls later. Invert this. Start with a tightly bounded agent that operates over a narrow task scope with explicit human checkpoints at every significant decision point.
Bounded autonomy serves two purposes. First, it is deployable: a system with genuine human oversight can enter a regulated production environment while a fully autonomous one often cannot. Second, it is instrumented: narrow scope means every execution path is observable, and edge cases surface in a lower-risk environment.
As confidence in the agent’s decision quality grows, the autonomy boundary can be extended incrementally. This requires a formal governance process: documented test results, compliance sign-off, and a clear record of which capability extensions were authorised and when. This audit trail becomes evidence of responsible deployment if the system is ever reviewed by a regulator.
Phase 3: Build Observability as a Core System Requirement
In a traditional software system, logging is infrastructure. In an agentic system deployed in financial services, it is a regulatory asset.
Every agent action should produce a structured log entry recording: the decision point, the inputs available at that point, the action taken, the confidence level or model output, and the timestamp. These logs need to be queryable, immutable, and retained in line with the firm’s data governance policies.
Beyond logging, agentic systems need active monitoring. This includes:
- Drift detection: identifying when agent behaviour diverges from expected patterns
- Anomaly alerting: flagging actions outside the normal operational envelope
- Cost monitoring: tracking token consumption and API call volume to detect runaway loops or unexpected execution paths
- Human escalation queues: ensuring that cases flagged for review reach the right person and are not silently dropped
The monitoring infrastructure is not optional. Without it, the firm cannot demonstrate ongoing oversight to a regulator, and it cannot detect and contain errors before they propagate downstream.
Phase 4: Govern the Agent Lifecycle, Not Just the Launch
Deploying a compliant agentic system is not a one-time event. The model it uses will be updated. The tools it calls will change. The regulatory environment will evolve. The task scope may be extended. Each of these changes potentially alters the system’s risk profile.
A compliance-first framework includes a lifecycle governance process: a formal change management procedure for any modification to the agent’s model, prompts, tools, data access, or decision logic. This is the same discipline applied to model risk management in traditional quantitative finance, applied to the agentic layer.
Firms that handle this well treat their agentic AI systems like financial models: subject to initial validation, ongoing performance monitoring, material change review, and periodic revalidation. Firms that do not tend to discover the gap when a regulator asks for documentation that does not exist.
What Breaks in Production
The failure modes in production agentic AI in financial services are consistent enough to be predictable.
The most common is context accumulation without pruning. Agents operating over long workflows accumulate state that can cause the model to weight earlier context inappropriately. In a multi-step compliance review, this can produce decisions that reflect outdated or irrelevant data. Context management is an engineering requirement, not an afterthought.
The second is tool failure handling. When an external API returns an error or a timeout, an agent without explicit fallback logic may retry indefinitely, produce a partial result silently, or fail in a way that is not recorded in the audit log. In a transaction processing environment, silent partial failures are a serious operational risk.
The third is prompt injection vulnerability. If an agent processes external data as part of its workflow, that data can contain instructions that alter the agent’s behaviour. In a financial context, this is not a theoretical concern: it is an attack vector with real implications for fraud, data exfiltration, and regulatory non-compliance.
Building against these failure modes requires explicit engineering effort. Defensive prompt writing alone is not sufficient.
What Trustworthy Deployment Actually Looks Like
The firms that successfully move agentic AI into regulated production environments share a common operating pattern. Governance and engineering move in parallel from the first sprint. The compliance team is a design input, not a gate at the end. The initial deployment is deliberately narrow, with a documented expansion roadmap tied to demonstrated performance thresholds. And the system is instrumented well enough that when something unexpected happens, the team can explain it within hours, not weeks.
None of this is beyond reach. But it requires treating compliance-readiness as an architecture decision, not a documentation task.
Where Zartis Fits in This Work
Zartis works with financial services firms at the point where agentic AI ambition meets the constraints of a regulated operating environment. That usually means three things among others: helping organisations design governance architecture before building, engineering agentic systems that are observable & controllable from the first deployment, and establishing the lifecycle management processes that keep those systems compliant as they scale.
The firms that succeed with agentic AI in financial services are not necessarily the ones who move the fastest. They are the ones who build trust into the system architecture, so that when the compliance team, the risk committee, or the regulator asks how a decision was made, the answer is already documented and verifiable.
If you are assessing how to move agentic AI from a controlled pilot into a production environment, speak to our team about what a compliance-first engagement looks like in practice.