Banks are adopting AI before they can fully see the risks

Written by Russell Pereira

Jul 1, 2026
11 min

David Gee, former chief information security officer at HSBC Asia Pacific and global head of technology, cyber and data risk at Macquarie Group, argues that banks need to treat AI security as an operating discipline built on visibility, ownership and risk-based intervention as adoption spreads through internal systems, third parties and automated threat activity.

Artificial intelligence (AI) has not created the risks that have occupied bank security teams for decades. Phishing, social engineering, ransomware and impersonation all existed before AI, and they remain active threats across financial services. AI changes the economics, speed and credibility of those attacks, while adding another layer of exposure that many banks have not yet mapped.
The result is not only a larger cyber problem, but also a visibility problem. Banks are adopting AI across business processes, software development, vendor platforms and internal workflows faster than they can see, classify and control it. An institution cannot secure AI systems that it cannot identify, monitor or assign to accountable owners.
David Gee, former chief information security officer at HSBC Asia Pacific and global head of technology, cyber and data risk at Macquarie Group, now advises boards and financial institutions on cyber, technology and AI governance. After a year of conversations with peers, regulators and board members across the region, he said many institutions still face gaps in readiness. "I'm not filled with confidence that we're ready for this."
Banks are not ignoring AI risk, but many are pursuing AI productivity gains without matching investment in safety. Gee’s concern lies in the order of execution, as institutions move towards AI-enabled operating models before they have built the governance, monitoring and control architecture needed to make adoption safe. The challenge is not whether banks should use AI, but whether they can govern it at the speed at which it is entering the organisation.

The first risk is the exposure banks have not measured
Most large banks already run complex cyber security environments. Gee estimated that a typical large organisation may operate 85 to 90 separate cyber security systems and more than 100 individual controls. Many of those controls were already under pressure before AI entered the mainstream, with risks such as ransomware, identity compromise, data leakage and third-party exposure often sitting at amber rather than green in risk appetite terms.
AI does not remove those weaknesses. It creates a second attack surface alongside them, while most banks continue to rely on the same budgets, people and control sets. AI systems also introduce vulnerabilities such as prompt injection, model drift, model corruption and unsafe agent behaviour, which require controls that traditional cyber frameworks were not built to provide.
The gap becomes most visible where AI systems communicate beyond the bank’s traditional control points. Data loss prevention (DLP) tools usually monitor sensitive information leaving the organisation through established channels such as email, file transfer or web uploads. AI creates new routes for data movement, especially when models connect through application programming interfaces or protocols that allow AI systems to interact with enterprise tools and data sources.
"Very few banks have got DLP ready for AI," Gee argued. "If AI is sending information out through APIs... it's not being checked right now." A bank may therefore have strong controls over human data leakage while leaving AI-generated or AI-mediated data flows insufficiently observed. That blind spot becomes more material as AI agents gain access to internal tools, data sets and operational workflows.

Automated attacks test human response models
The visibility problem becomes more serious when attacks unfold quickly. A bank may discover an unauthorised data flow, malicious prompt or compromised agent only after an AI system has already acted. Security operations centres were built to detect, triage and respond to threats across the enterprise, but many still depend on human review and escalation.
Gee cited the incident involving McKinsey’s internal AI platform, Lilli, as a warning about automated security risk. CodeWall, a cybersecurity firm, described an autonomous security-research agent that identified exposed interfaces and exploited a vulnerability in the platform. McKinsey said it fixed the issue within hours and found no evidence that client data or confidential information had been accessed.
Gee described the episode in shorthand as one AI system attacking another. "An AI agent hacked an AI agent," he noted. "It was minutes. It happened really, really quickly." A human-led security response, even one staffed around the clock across multiple regions, cannot always match an attack that executes, adapts and escalates at machine speed.
AI agents also raise a second concern because they may operate with elevated access rights. Inside a bank, an AI agent might access customer records, query internal systems or trigger workflow actions. If the bank treats that agent as a tool rather than as a powerful digital user, it may miss the need for expiring credentials, privileged access management, activity logging, access limits and escalation controls.
Banks should treat AI agents and the systems around them as active participants in the control environment. The more authority an agent carries, the more important it becomes to define what it can do, how long it can do it and who can override it.

Inventory only matters when it becomes live visibility
Gee’s framework centres on five controls: a dynamic AI model inventory, pre-deployment governance, prompt injection defences, privileged access management for AI agents and AI monitoring and detection. That framework shifts the discussion from broad concern about AI towards specific questions boards can ask. Which AI models do we use, who owns them, what data can they access, and how are they monitored?
The first of those controls, the AI inventory, addresses a long-standing weakness in banks: shadow technology. AI has made that problem more urgent because employees and developers can now use external models, open-source tools and embedded AI functions with limited friction. A static spreadsheet of approved AI use cases will not capture that reality, so banks need an inventory that changes as their AI estate changes.
Gee’s thinking has therefore moved towards observability rather than inventory alone. "Rather than building an AI inventory tool," he explained, "I would try to get what's called observability, which is the monitoring detection to sort of find when things are happening that are bad, and the inventory is the means to an end." In that model, the bank does not treat inventory as a one-off governance exercise, but builds continuous monitoring that shows where AI is operating, how it behaves, what data it touches and where abnormal activity appears.
That shift changes what boards should ask. The question is not simply whether management has produced a list of AI models, but whether the institution can continuously see AI activity across the enterprise and its external dependencies. Gee linked that visibility directly to protection: "Once you know it, you can then protect it. If you don't know what they are, you can't protect it."

Governance has to follow the risk of the action
Visibility only solves part of the problem. Once banks know where AI is operating, they must decide how much autonomy those systems should have. That decision cannot follow a single governance template because AI use cases vary widely across the bank.
Gee drew a distinction between a human being in the loop and one who is on the loop. A person on the loop monitors activity as it passes and may intervene after detecting a problem. A person in the loop holds the authority and mechanism to approve or stop an action before it happens.
This distinction matters because banks often refer broadly to human oversight without defining whether the human can actually prevent the AI system from acting. High-value wealth management transactions provide one example where the in-the-loop model makes sense, because the bank can justify added friction if a large transfer, sensitive client instruction or high-risk action requires human review before execution. A real-time AI-on-AI cyber attack requires a different response.
"If I'm being attacked by another robot, which doesn't sleep, doesn't have holidays... I need to have a bot to detect that bot and make action," Gee observed. Waiting for a human approval cycle in that context may mean the bank has already lost the contest. Banks should therefore design AI governance by transaction class, risk level and response speed, allowing low-risk tasks to proceed with sampling and review while reserving human approval or automated containment for higher-risk actions.

The blind spot extends beyond the bank
The same lack of visibility becomes more acute when AI sits outside the bank’s direct control. Banks rely heavily on cloud providers, technology vendors and outsourced service partners, many of which are embedding AI into their products and operations. Even where contracts restrict the use of bank data for model training, the practical challenge remains: the bank must know whether those restrictions are being followed and whether fourth-party providers introduce additional exposure.
Traditional third-party risk management does not always match this speed of change. Annual assessments, questionnaires and procurement attestations can still play a role, but they do not provide continuous assurance over AI tools that may change frequently. A vendor may update a model, add an AI feature, change a dependency or introduce a new data processing flow between assessment cycles.
Open-source AI adds another layer of difficulty. Developers can download and experiment with models from public repositories in ways that bypass formal procurement routes. Public repositories such as Hugging Face host enough models that even a small malicious share becomes material.
At that scale, blocking entire platforms becomes a blunt and often ineffective response. Gee argued in favour of controlled freedom over blanket prohibition. A bank can allow innovation while using enterprise browsers, sandboxed environments, behavioural monitoring, model scanning and data movement controls to prevent staff from exposing sensitive information or importing unsafe models.
Policies alone will not give banks enough assurance over how employees, developers and vendors use AI. Financial institutions need technical visibility into what is actually happening, especially where shadow AI, open-source models and third-party platforms intersect with bank data. That visibility also needs to extend beyond formal procurement channels.

Supervisors are converging on evidence of control
Regulatory frameworks for AI in banking remain uneven across markets, but the direction of travel is becoming clearer. Supervisors are moving from broad principles towards evidence that institutions can identify AI use, assign accountability, manage third-party dependencies and monitor risks throughout the lifecycle of AI systems. The emphasis differs by jurisdiction, but the common question is whether banks can demonstrate control rather than simply approve AI use cases.
In the European Union, the AI Act frames risk management for high-risk AI systems as a continuous process across the lifecycle of the system, rather than a one-time approval. In the United States, the National Institute of Standards and Technology’s AI Risk Management Framework gives organisations a voluntary structure for governing, mapping, measuring and managing AI risks. In Asia, the Hong Kong Monetary Authority and other financial regulators have used generative AI sandboxes to test responsible adoption in areas such as risk management, anti-fraud and customer experience, while Australia has sharpened expectations on cyber resilience, board accountability and AI risk management through existing regulatory powers.
Gee recommended a model based on a lesson from quantum-readiness planning. The lesson from post-quantum planning is that supervisors can require institutions to map exposure and show a credible plan before the threat fully materialises. The AI equivalent begins with a basic supervisory question: show us your inventory.
"That's the first step," Gee argued, "because once you know it, you can then protect it." Such a requirement would give boards, regulators and management teams a common baseline for accountability. It would also force a more practical discussion about whether the bank understands its AI footprint before it claims to manage the risk.
For banks, that plan should go beyond a registry of approved use cases to address who owns each AI model, what data it can reach, whether it has been tested for vulnerabilities, how third-party dependencies are tracked and how governance differs for low-risk automation versus high-value or high-speed decisions. It should also show how the institution monitors changes after approval. Without that evidence, an inventory risks becoming a compliance record rather than a control mechanism.

Banks need a control model that moves with AI
Banks will not secure AI by treating it as another technology project added to an already crowded cyber agenda. The next phase of AI governance has to connect cyber security, fraud, data governance, resilience, model risk, compliance and third-party management around a shared view of exposure. That requires banks to move beyond static inventories and annual attestations towards control models that update as AI use, model behaviour and third-party dependencies change.
The immediate way forward is not to choose between innovation and restraint, but to define the conditions under which AI can operate safely. Banks that can see their AI estate, assign clear ownership, distinguish between low-risk automation and high-risk autonomous action and monitor behaviour across internal and external environments will have a clearer basis for scaling AI. Those that cannot yet explain what AI they are running, what authority it carries and how it is being watched will face a wider assurance gap as adoption accelerates.