AI Orchestration Layer Without a Black Box: How Banks Log, Trace and Stop Agent Decisions

In a bank, an AI orchestration layer assigns tasks to domain agents, checks their results and hands over to people. We described the roles it needs in our article on routers, planners, domain agents and reviewers. This article answers a narrower question: how does a bank log what its agents decide, how does it reconstruct a decision after the fact, and how does it stop an agent? How much autonomy an agent should get in the first place is covered in a separate article in our series.

What the legal framework requires

For high-risk AI, the AI Act requires automatic logs and the ability to stop the system; DORA requires logging for all of a bank's ICT systems. Together, they define what an orchestration layer must be able to do technically.

High-risk AI systems must technically allow events to be logged automatically over their lifetime (AI Act, Art. 12). People must be able to intervene or interrupt the system "through a 'stop' button or a similar procedure that allows the system to come to a halt in a safe state" (AI Act, Art. 14). Deployers keep the logs for at least six months (AI Act, Art. 26). Under the Digital Omnibus, these obligations apply to stand-alone high-risk systems such as credit scoring from 2 December 2027 (European Parliament).

Most marketing and service agents are not high-risk systems. DORA still applies to them: the regulatory technical standards require defined events and retention periods, protection of logs against tampering and deletion, detection of logging failures and synchronised system clocks (Delegated Regulation (EU) 2024/1774, Art. 12).

Logging: what to record for every agent step

A useful log records not just the outcome but everything needed to replay the decision later. Five items belong to every step.

1. Trigger and mandate: which event started the agent, and under which mandate.

2. Context with version: which customer data, consents and rules the agent saw, with timestamp and version.

3. Model and instruction: model version, system instruction and the tools used.

4. Review result: what the reviewer role checked, with result and reasoning.

5. Approval and effect: who approved, what reached the customer, and when.

Tracing: reconstructing a decision after the fact

A decision is only traceable once a reviewer can rerun it with the data and versions that applied at the time. A list of events alone is not enough.

Hypothetical example: A customer of a cooperative bank complains that he received a loan offer two days after his overdraft was cancelled. The internal auditor and the head of marketing operations open the case in the log. They see that the agent used a context snapshot from before the cancellation. They decide that loan offers may only go out with context that is at most one day old, and add the rule to the reviewer.

For this to work, context, rules and models must be versioned. How context objects with validity periods are built is shown in our article on the five building blocks of an AI decision engine.

Stopping: criteria, levels, four-eyes principle

An agent must be stoppable at three levels: a single step, a use case and the agent as a whole. The criteria are set before go-live, not during an incident.

• Step: the reviewer role halts an action if consent, contact budget or context age do not fit.

• Use case: a threshold, such as an unusual complaint rate or a deviation from the control group, suspends the use case automatically.

• Agent: a named person can stop the agent completely; open cases pass to people.

Actions with external effect, such as an offer or a change of terms, are released by a second person under the four-eyes principle until the bank has enough experience. Why a stop switch alone is not enough is explained in our article A kill switch is not enough.

ACCELERAID logs data access, model calls and changes in exportable form and delivers explainable results. The platform runs in an ISO 27001 data centre in Frankfurt or on-premises on request, and is SOC 2 compliant (ACCELERAID).

Five takeaways

1. An AI orchestration layer without a black box logs trigger, versioned context, model, review result and approval for every agent step.

2. For high-risk AI, the AI Act requires automatic logs, a way to stop the system and at least six months of retention, from 2 December 2027 for stand-alone systems.

3. DORA requires logging, tamper protection and synchronised clocks for all ICT systems, including agents outside the high-risk class.

4. A decision is only traceable once it can be rerun with the data and versions that applied at the time.

5. Stop criteria for step, use case and agent are set before go-live; actions with external effect start with four-eyes approval.

Illustration: AI-generated. AI-assisted content: We use AI technologies and automated agents in the creation of our articles, including from Microsoft, Google, OpenAI, Anthropic and other providers. Topics, editorial direction and final approval remain with our team.