AI risk is becoming an increasingly broad label for problems that have relatively little in common beyond the technology involved.
September’s RiskBusiness Newsflashes included a reported €95 million fraud involving an AI-cloned voice. They also covered an experimental AI model accessing government systems without authorisation, a customer data breach involving AI-generated code and disruption affecting several major AI providers.
Each presents a different problem for the organisations concerned.
Grouping them under a single AI risk category may be convenient for reporting purposes. But it tells management surprisingly little about the nature of the exposure or whether the right controls are in place.
As AI becomes part of more business activities, organisations need to understand how it is changing risks they already manage, as well as recognising exposures that existing frameworks may not fully address.
What the recent incidents tell us
More recently, the disclosure of critical vulnerabilities in PHP has shown another way AI may affect established cyber risks. On 21 October, PHP developers released emergency fixes for two flaws that could allow attackers to execute code on affected web servers. AI-assisted security research helped uncover the vulnerabilities, while Amazon reported attempts to exploit them beginning four days before the public disclosure.
The risk here is familiar: attackers exploiting weaknesses in software. But the growing use of AI to find vulnerabilities and help develop exploits may shorten the time organisations have to identify affected systems and apply patches.
On 25 September, Reuters reported that fraudsters had used AI-assisted impersonation in a scheme involving Fideuram, the private banking arm of Intesa Sanpaolo.
According to sources familiar with the matter, the fraudsters sent a message appearing to come from Intesa Sanpaolo’s chief executive, followed by a telephone call using an AI-generated imitation of a senior lawyer’s voice. The deception resulted in transfers totalling approximately €95 million, although more than half the funds were subsequently recovered.
The underlying exposure was financial fraud. AI made the impersonation more convincing, potentially undermining the reliability of familiar methods of confirming identity and authority.
A very different incident came to light when OpenAI disclosed that an experimental model undergoing internal training and evaluation had accessed Australian government systems without authorisation.
During a research task in June, the model gained non-public access to Services Australia’s Medicare Statistics Reporting Service and retrieved internal technical information. OpenAI said it found no evidence that individual medical records had been accessed.
The model was experimental and not intended for public release. Nevertheless, the incident raises questions about how autonomous systems operate within authorised boundaries, particularly where they can interact with external services.
There was also a more conventional control failure involving AI-generated code.
In September, Singapore’s Personal Data Protection Commission published findings concerning retailer Bee Cheng Hiang. An employee had used generative AI to create a script for sending marketing emails, but the resulting code exposed the email addresses of 95,364 customers to other recipients.
The regulator attributed the April incident to human error and insufficient checking, rather than a malfunction of the AI tool.
This was a data protection failure involving inadequate testing of code before use. The organisation remained responsible for checking the output, regardless of how it had been produced.
On 3 September, ChatGPT, Claude and Grok experienced overlapping service disruptions. The incidents were not established to have a common cause. OpenAI subsequently attributed its own disruption to a routing configuration change that prevented some requests from reaching available services.
For organisations relying on external AI capabilities, such incidents raise familiar questions about supplier dependency and operational resilience.
Taken together, these examples show why identifying an incident as AI-related is only the beginning of understanding the risk.
Classifying the technology is not the same as understanding the exposure
AI governance has become an increasingly prominent part of organisational risk management.
Dedicated oversight arrangements can help establish accountability for adoption, development and use. An enterprise-level AI risk category can also provide a view of exposure across the organisation.
The difficulty arises when that category becomes a substitute for understanding the underlying risks.
The Fideuram case involved impersonation and fraudulent payment instructions. The Singapore incident concerned the handling of personal data and inadequate software testing. Neither exposure becomes less recognisable because AI contributed to the circumstances.
The technology changes how a risk might materialise, and can affect whether existing controls remain reliable.
For example, payment verification arrangements that previously placed considerable reliance on recognising a familiar voice may require reassessment as convincing voice impersonation becomes easier.
In software development, AI can change how quickly code is produced and who is producing it. Yet the need to test that code before deployment remains.
Other applications create more unfamiliar problems, particularly where autonomous agents are authorised to carry out activities that would previously have required direct human intervention.
The distinction should influence how organisations classify their exposures.
Recording AI as a contributing factor alongside the underlying risk category would allow management to retain visibility of familiar risks while recognising how the technology is changing them.
It would also make it easier to compare incidents that involve similar underlying failures, even where AI is used in very different ways.
What should the risk register show?
An organisation may have a comprehensive AI policy and a clearly defined risk appetite, yet still struggle to explain where AI has materially changed its exposure.
One reason is that the use of AI does not always fit neatly within the boundaries of a single function.
An employee may introduce an AI tool into an established process without changing the formal ownership of that process. A business team may begin using an external model without fully understanding the dependency it creates. An application may be given additional permissions as its capabilities develop, changing the potential consequences of an error.
Risk assessments need to reflect those developments.
A more informative approach would distinguish between the underlying exposure and the role AI plays in creating or influencing it.
The first establishes the type of risk being managed. The second helps explain what has changed and whether the controls designed for the original process remain appropriate.
This would allow AI-related exposures to be recognised across existing risk categories without losing sight of their common technological characteristics.
For firms using established risk taxonomies, that approach also supports more meaningful aggregation.
Management could identify concentrations of AI-related exposure while retaining the detail needed to understand the causes, consequences and control requirements of individual risks.
That is considerably more informative than a single enterprise-level rating which combines unrelated exposures under the same heading.
AI governance needs clear ownership
Classification is only one part of the problem. Organisations also need clarity about who is responsible for managing the exposure.
Dedicated AI governance committees can provide oversight, establish standards and challenge how new applications are being introduced.
But their existence should not weaken accountability within the business functions using the technology.
Where AI is used to support a customer-facing process, the relevant business owner still needs to understand the effect on customer outcomes. A technology function deploying AI-generated code remains responsible for applying appropriate development controls.
Autonomous agents may introduce additional questions about authority.
Before an agent is permitted to act within a business system, the organisation needs to understand what it can access and the consequences if it behaves unexpectedly. Those permissions can change the risk considerably, even where the underlying model remains the same.
This creates a potential gap between responsibility for the AI technology and responsibility for the business activity it supports.
Without clear ownership, each function may assume that another has assessed the relevant risks.
AI governance therefore needs to remain connected to existing decision-making and control responsibilities, rather than developing into a parallel structure that operates separately from them.
Assurance should examine what has changed
The breadth of AI adoption also has implications for risk assurance and internal audit.
An organisation may be able to demonstrate that it has approved AI policies, defined governance arrangements and established processes for assessing new applications.
Those measures provide a foundation, but they cannot establish whether the controls governing individual activities remain effective.
The starting point for assurance should be the exposure being managed.
Where AI-generated code is introduced into business processes, reviewers should examine whether existing testing and approval requirements have been followed. For autonomous systems, the effectiveness of access restrictions and monitoring may require particular attention.
Existing controls may also need to be reconsidered where AI changes the assumptions on which they were originally designed.
This does not necessarily mean creating new controls for every application. In some cases, adapting established arrangements may be sufficient.
The objective is to understand whether those arrangements continue to provide an appropriate level of protection.
External incident intelligence can contribute to that assessment.
Looking across reported incidents and regulatory findings helps organisations recognise how AI is influencing different types of failure. It can also reveal weaknesses that may already exist within their own control environments.
For RiskBusiness, this is one reason why examining incidents across different industries and jurisdictions is valuable. Similarities in the underlying control failures may become apparent even when the technologies and business activities involved are quite different.
A clearer view for boards and risk leaders
Boards do not need every AI-related exposure presented as a separate emerging risk.
They do need confidence that management understands where the technology is changing the organisation’s risk profile and whether responsibility for those exposures is clear.
That requires more than knowing how many AI applications are being used or receiving a consolidated AI risk rating.
Reporting should help decision-makers understand where existing controls may no longer be sufficient, particularly as AI becomes more deeply embedded in business operations.
It should also allow them to distinguish between risks that require different responses.
The incidents reported in September illustrate the breadth of that challenge. AI can strengthen established forms of fraud, introduce new possibilities for autonomous activity and change the circumstances in which familiar operational failures occur.
The common technology does not mean the risks should be managed in the same way.
An organisation can have AI risk on its register and still lack a clear view of the risks AI is actually changing.
Stay up to date with the latest news and views from the world of governance, risk, audit and compliance >>>
