Banking & AI · An operational perspective
When AI Can Act: What Banks Need to Control
A customer-onboarding example shows why model quality, action permissions and recovery need separate design decisions.
A banking assistant that reads an onboarding file and one that changes a customer record may use the same model. They require different controls. The second system has authority to alter something the bank relies on, and its mistakes can travel into later decisions.
Accuracy remains necessary. An apparently well-supported recommendation can also exceed the system’s permitted role, use stale evidence or be applied to the wrong record. Bank leaders need to assess both the quality of the answer and the consequences of the action the system can take.
What the OCC document does and does not establish
On November 4, 2026, the US Office of the Comptroller of the Currency (OCC) issued an examiner framework addressing AI under the term Super Intelligence, or SI. The terminology encompasses technologies previously called artificial intelligence. It does not establish that the systems being discussed have superhuman intelligence or general intelligence.
The bulletin is a resource for examiners, creates no new regulatory expectations or enforceable standards, and says banks are not expected to use it to assess their own systems. It should not be presented as a new bank compliance checklist.
I read it as a prompt for an architecture discussion: what authority has the bank delegated, and what could happen if it is misused? The framework connects these questions to existing risk disciplines. The implementation choices below are my recommendations, informed by that discussion. They are not OCC requirements, and this article is not legal advice.
Sources: OCC Bulletin 2026-54: Super Intelligence, Supervisory Framework (November 4, 2026) · OCC framework §§1 and 1.1: Executive Summary and Overarching Principle
Follow the authority through one onboarding process
Consider an illustrative corporate-customer onboarding assistant. It first assembles evidence from approved records and documents. It then recommends correcting the registered business address in the customer profile, showing the proposed value and supporting sources. A reviewer can assess, reject or escalate that recommendation. Finally, an authorized reviewer grants scoped approval for the specific change and a controlled service executes it.
Start by specifying what the assistant is allowed to accomplish. For this example, preparing a proposed profile correction does not include approving onboarding, resolving a legal ownership dispute or changing a customer’s risk classification. Those decisions may involve other owners and policies. If the product later adds one of them, revisit the design and its permissions before treating it as an ordinary feature release.
During evidence assembly, the main concerns include access to sensitive information, source selection and faithful extraction. A missing ownership document or a mistaken entity match can compromise the recommendation before any write occurs. The assistant should expose missing evidence and conflicting records rather than produce a complete-looking profile.
At recommendation, the bank needs to know which customer and field would change, why the evidence supports it, and which uncertainty remains. At execution, the question expands: is this exact action permitted, approved and still valid? A technically correct recommendation does not itself grant permission to update the record.
These are distinct stages even when the interface presents a single conversation. Record the transition between them. Giving the evidence-reading identity write access from the start collapses a boundary that the business may believe still exists.
Make the permission boundary enforceable
For this onboarding example, I would separate the model’s proposal from the service that writes to the customer system. Give the evidence service read access only to the sources and customer scope required for its task. Keep write credentials outside the model context and outside retrieved documents.
The execution service should accept a constrained request containing the target customer, permitted field, proposed value and approval reference. Deterministic code should check that request against an allowlist of operations, the requesting service’s authority, the approver’s entitlement and the bank’s applicable business rules. Apply maker-checker or other segregation of duties where bank policy requires it. The model should have no route to expand those permissions by rewriting its instructions.
Documents and external tool results are evidence inputs. Instructions embedded in them must not authorize a tool call or change the operating policy. Test this directly with a document that asks the assistant to bypass review, access another customer or substitute an execution destination.
Least privilege also applies to duration and scope. Limit credentials to the necessary service and operation, revoke them when access ends, and make failures deny the write. Where several agents participate, inspect their combined permissions. A restricted reader that can persuade a broadly privileged executor may still create an unauthorized path.
Approve a defined change using current evidence
Human approval needs a defined object. In this design, the reviewer sees the customer identifier, current field value, proposed replacement, evidence references and unresolved exceptions. The reviewer must have the authority and enough subject knowledge to reject the request. A screen that offers only a fluent explanation and an Approve button gives them too little to assess.
Bind approval to that proposal and the relevant record version. If the customer record changes before execution, stop and request a fresh review. If the supporting document has expired or a newer source contradicts it, return the case for investigation. Approval should not become a reusable permission for whatever change the assistant suggests next.
Use execution identifiers to prevent a retry from applying the same request twice. Check the result against the intended change, including the possibility that the downstream service accepted a request but did not complete it. An uncertain outcome belongs in a reconciliation queue rather than an automatic repeat.
Plan for review capacity. Decide which cases need specialist escalation and what happens when reviewers cannot keep up. Monitor overrides and repeated approvals without evidence inspection. A human checkpoint only reduces risk when someone can perform the judgment the process assigns to them.
Sources: OCC framework §§2.1, 2.3, 2.6 and 2.10: Permitted use, human oversight, data governance and recovery
Keep an audit trail without copying the customer everywhere
For a material profile update, retain enough evidence to reconstruct the proposal and the executed action. That can include the source versions, model and configuration versions, prior field value captured at execution, proposed field change, policy-check results, approving identity, tool request and downstream receipt. Record rejected actions and overrides as well as successful ones.
A generated explanation is not proof that the cited document supports the change. Preserve traceable references to the evidence the reviewer could inspect. Where reproduction is limited by model variability or a vendor update, document that limit and retain the observable inputs, outputs and action records needed for investigation.
Logging creates its own privacy exposure. Avoid sending full identity documents, credentials or unrestricted customer content to general application telemetry. Separate operational events from protected evidence, restrict who can retrieve each, and define retention and deletion with the bank’s data and records owners. Include prompts, caches and vendor-held data in that review.
Access reviews should cover the people who operate this evidence store as well as the assistant. Support staff may need a case identifier and failure code without needing the underlying customer file. Make exceptional access attributable and reviewable. Review whether the evidence store creates another route to sensitive records.
Vendor arrangements should support the evidence and intervention the bank actually needs. Establish who can access customer data, what the provider retains, how changes are communicated, and what records remain available after an incident or service exit. Confirm these arrangements against the records available from the running service.
Sources: OCC framework §§2.5–2.7, 2.9 and 2.14: Model risk, data, privacy, vendors and auditability
Prepare for correct-looking failure
An available service can still be applying incorrect profile changes. Monitor rejected writes, stale-source detections, unusual tool use, approval patterns and discrepancies between requested and completed actions. Connect those signals to an accountable operator who can stop execution. Model-response quality and service uptime alone will miss parts of this failure.
I would test recovery with an incorrect update that has already reached the customer system. Can the bank suspend the affected write path, identify other cases using the same source or configuration, and move pending work into a controlled manual process? Can staff distinguish completed actions from requests whose status is unknown?
Correcting a field must use the controlled approval and write path, using the recorded prior value as evidence while accounting for intervening legitimate updates rather than blindly restoring it. Record correction may still leave harm behind. The wrong profile could already have informed another workflow or caused a customer to receive an unnecessary request. Trace those dependencies, assess affected customers and assign remediation to the relevant business owner. Keep containment, record correction and customer remediation visible as separate tasks.
Include provider and configuration changes in this exercise. A different model version, retrieval source or tool description may alter which actions the assistant proposes even when the customer interface looks unchanged. Decide which changes require renewed testing and restrict release until the responsible owners have reviewed the resulting evidence.
Before restarting, verify the repaired control using the failure scenario and related cases. Define who authorizes restart and which restrictions remain. Keep the restart decision and its supporting evidence available for review.
Sources: OCC framework §§2.10–2.14: Resilience, cybersecurity, monitoring, testing and auditability
Ask for the action path in the design review
My perspective comes from banking work across customer onboarding and KYC profiling, data lineage, and treasury operations. In onboarding delivery, evidence has to connect to an identifiable customer and a usable operational process. In lineage work, the route from a source to a downstream decision matters. Treasury work adds the discipline of knowing who may act within which limits.
That experience shapes the questions I would bring to this illustrative design. It is not a claim that I have deployed the assistant described here. For a bank leader reviewing a proposal, the following questions make delegated authority easier to inspect:
- Which records can the assistant read, and which exact fields can the execution service change?
- Which controls deny an unauthorized action even when the model requests it confidently?
- What evidence and proposed change does the reviewer approve, and what invalidates that approval?
- How are stale data, conflicting sources and uncertain execution outcomes handled?
- Can an investigator reconstruct the action without granting broad access to customer documents?
- Who stops the process, reconciles downstream effects and owns customer remediation?
- What evidence supports restart, and who accepts the remaining risk?