By Philip Allas, Senior GRC Consultant, Tecala | Follow me on LinkedIn
Someone in your organisation used an AI assistant this week to summarise a contract, draft a tender response or clean up a spreadsheet. Nobody formally approved that tool, nobody recorded what went into it, and nobody has been named as the person who answers for the outcome
The first two are mainly governance problems and the third is mainly a risk problem, and together they point at a much wider set of issues that is rarely dealt with and increasingly the centre of political, regulatory and commercial attention.
Who owns AI risk? A cost is already being carried whenever that question cannot be answered quickly and completely. It could be an insurer asking it at renewal. It should be asked by a director enquiring how the organisation is controlling AI use. It will be asked by a client in its security questionnaire before they sign a contract extension.
Before debating policy, look at what is already in flight. Sales staff paste pipeline data into ChatGPT to draft follow-ups. Developers accept Copilot suggestions into production code. Marketing runs client briefs through generative image tools. Finance uses AI features baked into Excel and Power BI.
Most organisations cannot produce a list of the AI tools in use, cannot say what data has been sent to them, and cannot identify who authorised any of it.
AI risk resists the categories most registers were built around. A single AI use case can simultaneously create a privacy risk (personal information sent offshore), a security risk (data leaving the tenancy), a legal risk (IP ownership of outputs), an operational risk (hallucinated content in a client deliverable) and a conduct risk (biased or discriminatory decisions). Force these all into one row and the other four are lost.
Most registers also assume a stable control environment, whereas AI models, vendors and features change monthly. And by "risk", I mean the set of AI risks: there are six to ten separately identifiable risks any GRC practitioner could pick out. That is what complicates ownership.
IT, or a dedicated AI practice, typically owns the tooling and the tenancy. Legal, if you have a team, may own the contracts and the privacy position. The business unit owns the outcome the tool was used to produce. None of them, in most organisations, owns the decision to use AI in the first place, and that decision is where a key risk originates.
When something goes wrong, each function can legitimately point at the other two. The absence of a single accountable owner is not a gap in the org chart. It is the mechanism by which AI risk goes unmanaged.
Start with best risk practice. Under ISO 31000, a risk owner is a single named individual with the authority to accept, treat or escalate the risk, and the accountability for the outcome. The business owner of an AI use case should own its purpose, expected benefit, operational impact and the consequences of decisions made using it.
Risks are also governed. The board and executive leadership remain accountable for risk appetite, oversight and ensuring appropriate policies and processes exist. Technology, security, privacy, legal, procurement and risk functions provide specialist assessment, controls and challenge, but should not automatically become the owner of every AI risk.
In practice as an example, that could mean naming one executive as the accountable owner enterprise-wide, with documented delegations to business-line owners for specific use cases.
The regulatory posture in Australia has shifted from watching to acting.
The Australian Voluntary AI Safety Standard sets ten guardrails that regulators are already treating as a reasonableness benchmark. Privacy Act reforms will tighten obligations on automated decisions affecting individuals. APRA CPS 230 brings AI-enabled processes into operational resilience scope for regulated entities. The EU AI Act reaches any organisation whose outputs are used in the EU. And ISO 42001 sets a global standard for management of AI operations, with a strong information security risk undercurrent.
The commercial channel is moving at the same time. Enterprise procurement and vendor risk teams are updating their security questionnaires now, and they are asking who your accountable owner is, what your inventory of AI tools looks like, what data those tools are permitted to process, and whether any AI-related incidents have occurred in the past twelve months.
Your board may have already asked for an AI risk briefing. If it has not, you should be encouraging one. A small set of concrete questions will do the work.
Who is the named accountable owner of AI risk?
What is our inventory of AI tools in use, and how current is it?
What is our AI governance policy, and when was it last reviewed?
What is our exposure, financial, regulatory and reputational, from current use?
What would we tell a regulator, an insurer or a major client today if they asked?
If management cannot answer these cleanly and quickly, that is your signal for GRC change.
You likely have a raft of other GRC-related issues to consolidate into a broader information security strategy or roadmap. That usually starts by benchmarking where your governance actually sits against a recognised standard, whether that is NIST CSF, the Essential Eight, CIS18 or the policy set you already run to. Tecala offers expedited reviews to kickstart the process.
👉 Contact us to book a free GRC consultation.
Share this article
Bought an OCR tool and still processing invoices by hand? Straight Through Processing shows the real gap, and how to close it.
Password spray attacks are still compromising Microsoft 365 accounts. The issue is rarely one failed control. It is the gap between what organisations believe is protected and what is actually enforced.
