Every AI governance framework I have seen worth using is built around a specific answer to a specific question: what can actually go wrong?
If you cannot answer that question with real precision, the rest of your framework will drift toward abstraction. Policies will describe what should happen without saying what they are guarding against. Approval processes will demand documentation without knowing what the documentation is supposed to demonstrate. Monitoring will collect metrics without knowing what to alert on. That is the pattern I want to help you avoid.
This article is a walk through the four categories of AI risk that dominate the current regulatory conversation and the current enterprise incident landscape. There are more than four categories in total, and I will note some of the others as we go, but these four (bias, hallucination, privacy, and security) are the ones you will find named in almost every major framework: the EU AI Act, the NIST AI Risk Management Framework, the MAS Guidelines, the APRA observations, the OWASP Top Ten for LLMs, and the OECD AI Principles. If you can govern these four well, the rest becomes much easier.
Bias
Start with bias, because it is the risk that has the longest regulatory history and the most developed control landscape.
Bias in AI is not a single phenomenon. It is at least three distinct things that are often confused. The first is representational bias in the training data: the data that trained the model does not reflect the population the model will be applied to. The second is measurement bias: what the training data measures is not what you actually care about. The third is aggregation bias: a model that performs well on average performs badly on specific groups, and the averages hide this.
All three produce the same visible symptom, which is different outcomes for different groups of people, in ways that may be unlawful, may be unethical, or may simply be commercially damaging even if legal. Bias is not just a compliance issue. A recruiting model that systematically screens out women is not just illegal under most anti-discrimination law. It is also, in a competitive labour market, actively destroying the value of the recruiting function.
The regulatory picture on bias is dense and getting denser. The EU AI Act names bias explicitly in its high-risk system requirements: providers must demonstrate that they have examined their training, validation, and testing data for biases likely to affect health, safety, or fundamental rights, and put mitigations in place. Under GDPR, automated decisions that produce legal or similarly significant effects on individuals give those individuals a right to a meaningful explanation and, in most cases, a right to human review. In Australia, the OAIC has been active on AI-driven decisions that affect privacy; ASIC has emphasised responsible lending and best-interests obligations; the Robodebt Royal Commission produced findings that materially changed the tolerance for automated adverse decisions. In Singapore, the MAS FEAT principles put fairness first, and the Veritas Toolkit provides specific fairness metrics that financial institutions are expected to use.
Two things about bias governance are worth flagging.
First, “bias” is not the same as “different outcomes for different groups.” Some differences in outcomes are lawful and even necessary. Actuarially sound insurance pricing produces different premiums for different risk groups. The regulatory question is not whether outcomes differ, it is whether the differences are justified, documented, and consistent with the legal and ethical constraints that apply to the specific use case. A bias assessment that does not distinguish these things will produce results that either scare the organisation into inaction or reassure it inappropriately.
Second, bias controls are not one-time. A model that is fair at deployment can become unfair as the underlying population shifts, as the ways the model is used evolve, or as feedback loops develop between the model’s outputs and the world it operates in. Continuous fairness monitoring is not a nice-to-have. It is the only way to know whether your controls are working over time.
Hallucination
Hallucination is the newer risk on this list. Five years ago, the AI risks people worried about were mostly about traditional machine learning models and their biases. Large language models introduced a category of risk that had not previously existed at scale: the generation of plausible-sounding text that is factually wrong.
I want to be careful about the language here, because “hallucination” is contested terminology. Some researchers argue it anthropomorphises the model in unhelpful ways. Some argue that “confabulation” or “fabrication” is more accurate. Some argue that from the model’s perspective there is no such thing as hallucination, because the model is doing exactly what it was trained to do, which is generate text that looks like the training distribution. All of those points have merit. I use the term “hallucination” because it is the term the industry has landed on, and because everyone in the room will know what it means.
What matters is the pattern: an LLM produces an output that is presented with normal fluency and confidence, but that contains factual claims that are wrong. Wrong citations. Wrong statistics. Wrong summaries of documents that exist. Descriptions of documents that do not exist. Attributed quotes that were never said. In legal, financial, medical, and safety-critical contexts, hallucinations can cause real harm.
The governance response has several layers.
At the model layer, retrieval-augmented generation reduces hallucination by grounding outputs in retrieved documents rather than the model’s parametric memory. It does not eliminate the risk, and RAG systems can hallucinate about the retrieved documents themselves, but it is a substantial mitigation.
At the workflow layer, human review is the fallback most organisations rely on for high-stakes generation. This is fine as far as it goes, but it depends critically on whether the humans are actually reviewing or are rubber-stamping. Review fatigue is real. Design the workflow so review is meaningful.
At the output layer, output filtering, citation verification, and confidence flagging can catch obvious errors before they reach a user or customer. These are technical controls, and they are useful, and they are not sufficient on their own.
At the governance layer, the question is what your policies say about generative AI use in specific contexts. Some contexts should be off-limits until the technology is more reliable. Some contexts should be limited to draft-and-review use only. Some are low enough stakes that the residual risk is acceptable. Getting this right requires the tiering discussion from the previous article, applied specifically to generative use cases.
Figure 1: The four risk categories
Figure 1 arranges the four risk categories along two dimensions. The horizontal dimension is how well-established the risk is: bias has decades of research and regulation behind it, hallucination and prompt injection are newer and less mature. The vertical dimension is the primary vector of harm: bias and privacy tend to affect individuals directly, while hallucination and security tend to affect them indirectly through the systems that consume AI outputs. Each risk needs its own controls, and no single control addresses all four.
Privacy
Privacy risk in AI has several distinct sources, and treating them as a single category has caused organisations real problems.
The first source is training data. Models are trained on large corpora, and those corpora often contain personal information. In some cases, that information was collected with consent; in many cases, it was not. Under GDPR and equivalent regimes elsewhere, this is a significant compliance question, particularly for organisations that fine-tune models on their own data. The question of whether model weights themselves contain personal data is legally unresolved in most jurisdictions and is being actively litigated.
The second source is inference. Modern AI models can infer sensitive attributes about people that were never explicitly provided. A model can infer likely health status from browsing behaviour, likely political affiliation from writing style, likely sexual orientation from social connections. These inferences are personal information under most privacy law, they are typically not what the individual consented to, and they can drive decisions that affect the individual without the individual ever knowing what was inferred or how.
The third source is generation. Generative AI can produce personal information about identifiable individuals, including information that is invented, that is combined from disparate sources without consent, or that constitutes a deepfake. The EU AI Act’s most recent amendments, effective December 2026, prohibit AI systems that generate non-consensual intimate imagery of identifiable individuals. That prohibition exists because the risk is real, current, and severe.
The fourth source is the operational data flow. When employees use consumer AI tools with organisational data, that data may leave the organisation’s control. This is the specific pattern that produced the well-documented incidents of confidential source code and internal documents being pasted into public AI services and, in some cases, ending up in the model’s training set. The APRA letter called this out specifically as a governance concern.
Privacy governance for AI needs to address all four sources. Training data provenance and consent. Inference limitations, particularly for high-stakes decisions. Output controls that prevent generation of personal information about real people without lawful basis. Employee use policies that prevent data leakage through consumer tools. Each of these is a distinct control set, and each is necessary.
Security
Security is the risk category that has moved fastest in the last twelve months, and it is the one the ASIC letter of 8 May 2026 was primarily concerned with.
The security landscape for AI has two sides. On one side is AI as target: the systems you build using AI have specific vulnerabilities that traditional software does not. On the other side is AI as weapon: attackers can use AI to conduct attacks with more speed, more scale, and more sophistication than they previously could.
On the target side, the OWASP Top Ten for LLMs is now the standard reference, and it names the main attack surfaces. Prompt injection, where an attacker crafts input that manipulates the model’s behaviour, is the vulnerability that has produced the most documented enterprise incidents. Insecure output handling, where model outputs are consumed by downstream systems without validation, has produced code injection and cross-site scripting risks in AI-augmented pipelines. Training data poisoning, where an attacker introduces malicious data into a training corpus, is harder to execute but potentially catastrophic. Model theft, denial-of-service through resource-intensive queries, and sensitive information disclosure round out the top of the list.
Agentic AI adds a layer. Systems that take actions across multiple applications, on behalf of users or autonomously, introduce authorization and authentication challenges that classical security models were not designed for. If an AI agent can send email, access files, and make purchases, the security question is not just “is the agent secure” but “what is the blast radius when the agent is compromised, and how is that blast radius contained.” Article 15 of this track will go into agentic AI risk in depth.
On the weapon side, the concern regulators are now voicing openly is that increasingly capable AI models change what defenders have to defend against. The ASIC letter referenced this directly, citing concerns about frontier model capabilities. APRA has engaged the sector on the same issue. What this means operationally is that security assumptions built around a certain baseline of attacker capability may no longer hold. Vulnerability discovery, exploit development, social engineering, and phishing are all improving on the attacker side. Defensive posture needs to keep pace.
Security governance for AI is not a separate discipline from cybersecurity. It is cybersecurity extended to account for AI-specific attack surfaces on the target side, and AI-augmented adversaries on the weapon side. The organisations that are handling this well are the ones whose CISO teams have taken AI security into their existing programs, rather than creating parallel structures.
The risks I have not covered here
For completeness, and because I would rather flag them than let them ambush you later, several other risk categories matter and will get their own treatment later in this track.
Model risk in the traditional sense (performance degradation, drift, and error) is covered in article 12 on model risk management for AI and LLMs. Third-party and supply chain risk gets its own article. Agentic AI risk gets its own article. Shadow AI gets its own article. Reputational risk, environmental risk (particularly around compute-intensive training), and workforce risk are real, but they are secondary in the sense that they typically materialise through the primary risks I have just covered.
Figure 2: How the risks propagate
Figure 2 shows how the risks propagate through a typical enterprise AI deployment. Bias enters at the data layer, propagates through training, and materialises at the decision layer. Hallucination is introduced at the generation layer and materialises at the user-facing layer. Privacy risk can enter at any layer where personal information is present. Security risk operates across all layers, and its exploitation typically produces one or more of the other risks as a downstream consequence. Understanding where each risk enters and where it materialises is what lets you place controls at the right point in the pipeline.
What this means for the rest of the track
You now have a working map of what AI governance is actually defending against. The rest of this track is going to build the specific frameworks, controls, and jurisdictional obligations that address these risks.
Article 4, next, is the jurisdictional map: what is in force where by late 2026. Articles 5, 6, 7, 8, and 9 dig into the EU, US, Australian, and APAC positions in more detail. Articles 10 and 11, in batch 2, cover the two frameworks (NIST AI RMF and ISO/IEC 42001) that most organisations are converging on for their internal control architecture. Article 12 is model risk management. Article 13 is documentation, which is what makes everything auditable. Article 14 is responsible AI in practice, covering fairness, explainability, and human oversight in operational depth. Articles 15, 16, and 17 are agentic AI, third-party and shadow AI, and incident response.
The rest of it makes more sense if you keep this article in mind. Every framework, every regulation, every control we will talk about, is trying to defend against one or more of the risks in the landscape you have just seen.
Everything else is engineering detail.