What an AI agent actually changes in a banking operation

A bank does not fail an AI project because the model cannot write a sentence. It fails because nobody named the operation the agent was allowed to touch, the record it had to leave, and the person who could stop it. The demo looks like a conversation. The production system is a set of permissions.

S·CORP treats an agent in banking as an operator with a narrow job. It can draft, retrieve, route, or recommend. It does not become the system of record, and it does not inherit every entitlement the service account happened to have on the day someone connected it. If that sentence is uncomfortable, the project is not ready for a customer, a teller, or a credit analyst.

Start from the operation, not the model

Pick one operation that already has a name, an owner, and a definition of done. Good candidates are narrow: assembling a credit-file summary from documents the bank already stores, preparing a response to a routine service request, or checking whether a case file has the attachments a policy requires before a human reviews it. Poor candidates are anything described as "the whole contact center" or "autonomous lending."

Write the operation in the unit the business already uses. A case. A file. A payment exception. A suspicious-activity narrative that a person still files. If the team cannot say what "finished" looks like for one of those units, the agent will invent a finish line, and the audit trail will not match the way the bank already explains its work.

Then write what the agent is not allowed to do. In a bank that list is usually more important than the feature list. It should say whether the agent may move money, change a limit, open or close a product, talk to a customer without a person on the line, or send anything outside the bank. "We will decide later" is a decision to let the integration choose.

Name the tools before you name the prompt

An agent is only as contained as its tools. A prompt that says "do not reveal customer data" is not a control if the tool returns a full core-banking record and the model is free to quote it. List every system the agent can call: core, CRM, document store, ticketing, payments, card processor, identity provider. For each one, write the action (read, draft, create, update), the fields in scope, and the fields that must never appear in a prompt or a log.

This is where PCI DSS becomes a design question rather than a slogan. If the operation can be done without the primary account number, do not put the primary account number in the tool. If a card number must be referenced, keep it in the system that is already in scope for PCI DSS and pass a token or a last-four reference into the agent. Do not discover this after a transcript review.

The same discipline applies to employee data, sanctions lists, and credit files. The agent should receive the smallest slice that lets it do the named operation. A retrieval index that was built from "everything in the share drive" is not a banking control. It is an unreviewed copy of the bank.

Keep a person on the decision that affects funds or reputation

There is a clean line. The agent may prepare. A person accountable for the operation may decide. That person needs three things on one screen: what the agent used, what it proposes, and how to reject it without losing the case. If the only way to reject the agent is to ignore a chat window, staff will either rubber-stamp or route around it.

For customer-facing use, disclosure is part of the operation, not a footnote in a privacy policy nobody opens. The customer should be able to tell that they are dealing with an agent, and they should have a path to a person that does not depend on guessing a magic phrase. The EU AI Act, where it applies, cares about transparency for certain systems. Even where it does not, a bank that hides the agent is borrowing a complaint.

Fraud and financial-crime operations deserve a harder version of the same rule. An agent can assemble a timeline from alerts the bank already holds. It should not close an alert, file a report, or tell a customer the outcome. The narrative a person files has to be theirs. If the agent drafted language, the file should say so.

Log the work the way an examiner can read it

A transcript is not an audit trail. For each unit of work, keep the case identifier, the tools called, the data classes touched, the output shown to a person, the human decision, and the identity of that person. Retain it for as long as the bank retains the underlying operation. Do not retain full customer payloads in a prompt log if the core system is already the record.

Access to that log is itself a privileged action. Model vendors, integrators, and the team running the agent do not automatically get a feed of production prompts. If a vendor needs a sample to fix a defect, take a redacted sample under the bank's usual third-party process. ISO 27001 is useful here only as a reminder: the control is an access rule and a record, not a certificate on a slide.

NIST's AI Risk Management Framework is a reasonable map for the conversation with risk, compliance, and internal audit. Govern, Map, Measure, Manage. Use the words if they help those teams. Do not pretend that naming the functions is the same as having an owner for each one. The owner of "measure" needs a small set of checks the bank can actually run: share of cases a person rejected, share of tool calls that failed, and a periodic review of a sample of transcripts against the written scope. Those are operational measures. They are not a claim about industry benchmarks, because we are not publishing one.

Put the change in the rollout, not after it

Banking programs stall when the model is treated as the product and the branch, the operations center, and the control functions are treated as the audience for a launch email. The people who will accept or reject the agent's output should see it on their own cases before it is allowed to touch a live queue. They should be able to say, in their own words, what they are now responsible for that they were not responsible for last month.

That is change management, and it belongs in the same plan as the integration. A pilot that runs beside the real process, on real cases, with a named supervisor, will teach the bank more than a proof of concept on invented files. When the pilot ends, either the scope is tight enough to operate or it is not. Both answers are useful. A vague success story is not.

If the first operation is still fuzzy, start with an assessment of the agents, tools, data, and oversight already in motion. The point of that work is a scope and a control map, not a tour of models.