AI Governance for Financial Services: Controls for Banks Using ChatGPT, Claude, and Copilot

Last reviewed: 6 September 2026

Banks already have an AI usage problem. It is the gap between the tools employees use and the controls the institution can demonstrate.

In its Banking on trust research, Deloitte reports that 63% of bank employees use AI weekly, while only 13% of banks in its governance assessment reach the leading maturity stage. These are findings from that research, not a census of every bank. They nevertheless illustrate why adoption and governance need to advance together.

An acceptable-use policy is a necessary starting point. It becomes useful operationally when the bank can show which tools were approved, what information could be shared, which controls ran, and who owned the decision.

Why AI Governance Is Different in Financial Services

A prompt containing customer account information can create confidentiality and privacy exposure. An inaccurate answer used in lending or customer servicing can affect a person's financial position. An agent with excessive permissions can turn an incorrect recommendation into an unauthorized action. These risks connect AI governance to existing security, operational risk, third-party oversight, and consumer protection processes.

The U.S. Treasury released the Financial Services AI Risk Management Framework in February 2026 as a sector-specific resource. It should not be presented as a new binding rulebook for every bank. Similarly, the NIST AI RMF is voluntary; it provides a structure for organizing risk management rather than a compliance certificate.

Be precise about model-risk guidance, too. SR 26-2 replaced SR 11-7 in April 2026. The Federal Reserve has clarified that the revised guidance does not apply to generative or agentic AI. Banks can still apply proportionate evaluation and validation practices to those systems, but should distinguish internal policy from a supervisory requirement that applies to a particular model.

Assign ownership across the business, security, privacy, compliance, and technology teams. A tool that drafts internal correspondence needs a different approval process from a system that influences credit decisions or executes transactions.

The Five AI Risks Banks Need to Control First

These controls work together. Masking does not establish whether an answer is correct. Logging does not stop an unauthorized transfer. Human review needs trained reviewers, sufficient context, and the authority to intervene.

The Control Stack Banks Actually Need

1. Centralized Policy Enforcement

Define which tools, accounts, data classes, and use cases are allowed. Connect those decisions to enforcement points: application gateways, managed browsers, endpoint controls, identity systems, and vendor-native administration. Decide what happens when a rule fails or a service is unavailable.

A common policy model reduces inconsistent decisions across teams. It does not require every product to share the same technical integration. Test both approved routes and plausible bypasses, including file uploads, mobile clients, developer tooling, and agent connections.

2. Sensitive Data Masking and Classification

Protect regulated information alongside commercially sensitive material: client portfolios, deal terms, internal credit models, board documents, source code, and credentials. Minimize the data a task requires before applying detection and redaction.

For suitable workflows, replace detected sensitive values with placeholders before calling an external model. Keep any re-identification mapping inside the approved environment and restore values only for an authorized recipient. For other workflows, blocking the request or using an approved internal model is more appropriate.

Reversible tokenization is not the same as anonymization. Context can still reveal identity, detectors can miss information, and a token vault needs its own access and retention controls. Validate performance on representative bank data, including scanned documents, uncommon identifiers, and multilingual text.

Payment data needs special handling: card verification values such as CVVs are sensitive authentication data, not simply another field to retain in a prompt log. PCI DSS generally prohibits retaining sensitive authentication data after authorization, even if encrypted, with specific treatment for issuers and issuing services. Exclude such data from general AI workflows and apply the requirements relevant to the institution's role.

3. Role-Based Access and Least Privilege

Restrict access by job function, business unit, use case, and data sensitivity. Separate permission to use an assistant from permission to retrieve customer records, reveal masked values, or execute a payment. Service accounts and agents need explicit permissions as well.

RBAC supports this design, but it does not by itself prevent privilege escalation. Enforce authorization at the underlying data and tool boundaries, review permissions regularly, and record privileged changes.

4. Model Usage Monitoring and Evaluation

Track approved tools and investigate unexpected destinations, policy violations, abnormal usage, and failed controls. Record model versions where available and assess changes that could alter workflow behavior.

Evaluate the actual task: accuracy, harmful or biased outcomes, prompt injection resistance, and the reliability of any tool actions. Use proportionate review for material workflows, with clear escalation and rollback paths. An external model provider does not assume the bank's responsibility for its application.

5. Audit Logs and Compliance Reporting

Capture enough information to reconstruct control decisions: timestamp, user or service identity, use case, model endpoint and version where available, policy version, classification results, allowed or blocked status, and outcome. Include retrieval-source references and human approval records when relevant.

Do not automatically retain every raw prompt, response, or document. Use redacted content or metadata where sufficient, restrict access, and establish justified retention and deletion rules. Dataset lineage is relevant when the bank trains, fine-tunes, or retrieves from datasets; it is not information a generic chat log can always supply.

Protect evidence against undetected alteration through appropriate storage controls and integrity checks. Logs support traceability, but do not alone prove explainability, fairness, or legal compliance. See our guide to AI audit evidence for the operational context.

6. Processing Location and Deployment Controls

Map where prompts, attachments, embeddings, logs, backups, and support access are processed. Review subcontractors, retention terms, approved regions, and failover behavior. The location advertised for a service is only one part of its data flow.

Avoid assuming that every banking or privacy framework requires domestic hosting. GDPR and UK GDPR regulate international transfers through mechanisms including adequacy and safeguards; Singapore's PDPA requires comparable protection for overseas transfers. ICO transfer guidance and the PDPC's transfer obligation describe those distinctions. Sector-specific rules and contracts may impose additional restrictions.

On-premises deployment can support strict boundaries. If it calls an external LLM, however, the transmitted payload still leaves the premises. A no-egress requirement needs an architecture that keeps all relevant processing local.

One Policy Model Across ChatGPT, Claude, Copilot, and Internal LLMs

Apply common control objectives while documenting the capabilities and gaps of each integration. Consumer accounts, enterprise workspaces, APIs, and cloud deployments can have different retention, training, access, and location terms. Approve the actual service configuration.

Microsoft documents that Microsoft 365 Copilot respects users' existing content permissions. Excessive permissions can therefore expose excessive content. A generic external proxy should not be assumed to intercept every internal Microsoft 365 interaction. Microsoft 365 Copilot, GitHub Copilot, and other Copilot-branded products also require separate assessment.

Mapping Controls Across Financial Services Frameworks

The table below is an implementation guide, not a declaration that a product satisfies a regulation. Reuse control evidence where appropriate, then document the requirements, responsible entity, scope, and effective dates for each jurisdiction.

EU timing matters: the European Commission's current timeline places Annex III high-risk requirements at 2 December 2027 and high-risk systems embedded in Annex I products at 2 August 2028. The general application date was 2 August 2026, with earlier dates for prohibitions, AI literacy, and GPAI obligations. It is inaccurate to say the entire high-risk regime is already in force.

Under Annex III of the AI Act, evaluating natural persons' creditworthiness or establishing their credit scores is a listed high-risk use, subject to the Act's classification provisions. That entry explicitly excepts financial-fraud detection. A customer-facing chatbot is not automatically high-risk simply because it communicates with customers; transparency obligations may apply separately. Article 26's high-risk deployer logging provision concerns automatically generated logs under the deployer's control, with at least six months' retention unless other applicable law provides otherwise.

For the UK, consult the PRA's SS1/23 scope and principles. In India, use MeitY's DPDP rules and enforcement timeline to plan implementation. Neither a fixed number of documents per AI model nor a blanket domestic-hosting requirement should be inferred from a framework summary.

Vendor Evaluation Checklist for Banks

Ask vendors to demonstrate controls against a representative workflow and a realistic failure case. Record both coverage and limitations.

How WalledAI Supports Financial Services AI Governance

WalledAI brings data protection, policy enforcement, and governance visibility into supported AI workflows. The starting point is a deployment map: which applications connect, where enforcement runs, what remains outside coverage, and which teams own exceptions.

Mask Before Transmission, Restore for Authorized Users

Walled Redact describes a mask-and-unmask workflow: detect sensitive values, replace them with placeholders before the model call, then restore values in the response within the approved environment. This can reduce exposure of detected information while preserving useful context.

Validate supported formats, custom entity detection, restoration behavior, and false negatives against your data. Avoid treating a single accuracy percentage or latency number as a guarantee across all workloads. For highly sensitive inputs, use a blocking policy or an approved local model when masking cannot provide sufficient protection.

Connect Policy, Access, and Evidence

Evaluate enterprise access controls alongside governance reporting and the bank's existing identity and security systems. In a proof of concept, demonstrate a permitted request, a blocked request, a masking event, an unauthorized retrieval attempt, and an evidence export.

On-premises deployment can keep the control components and re-identification mapping within the bank's environment. External model calls still transmit their approved payloads. Confirm processing boundaries, network egress, and log storage for the selected configuration.

The WalledAI financial services page provides the product context. Discuss a deployment using a concrete workflow, sample data classes, and the controls your security and compliance teams need to verify.

Frequently Asked Questions

How should banks govern employee use of ChatGPT?

Approve the account type and use cases, define permitted data, enforce access and data controls through supported integrations, and monitor exceptions. Cover browser and API paths separately and keep evidence proportionate to the risk.

What AI governance controls do financial institutions need?

A practical baseline includes a use-case inventory, accountable ownership, data protection, least-privilege access, monitoring, protected audit records, vendor assessment, and human oversight for consequential workflows. Tailor the controls to the applicable obligations and deployment.

Can masking guarantee that customer data never reaches an LLM?

No. Masking reduces exposure of detected information, but detectors can miss data and context can reveal identity. Combine minimization, tested detection, access controls, and blocking or local processing when required.

Should banks log every raw prompt and response?

Not by default. Capture enough evidence to reconstruct decisions while minimizing sensitive content. Define access, integrity, retention, and deletion controls, and retain raw content only when justified and permitted.

Does one governance platform establish regulatory compliance?

No. Shared controls can support evidence across frameworks, but compliance also depends on legal scope, governance processes, documentation, validation, and effective operation. Each institution remains responsible for its obligations.