The Risk Taxonomy 2026 names the nine canonical classes of risk that legal AI introduces or amplifies. The Taxonomy is the inventory side of the Defensibility framework. Where Defensibility describes the response capability a legal function must demonstrate, the Taxonomy describes what must be responded to.
Generic enterprise risk frames, covering cybersecurity, vendor, and operational risk, are necessary but insufficient for legal AI. Hallucination, data leakage, model drift, vendor lock-in, regulatory non-compliance, professional conduct exposure, client confidentiality breach, shadow AI proliferation, and accountability dilution each carry distinct mechanisms, distinct evidence requirements, and distinct mitigation patterns that legal functions must operationalise individually.
The Taxonomy is binding canon. Risk Registers maintained by legal functions should map each entry to one of the nine classes. Vendor evaluations should be scored against the classes. Incident reviews should classify root cause against the same nine. Consistency of language across these three artefacts is what makes governance discussable at board level.
Each class is defined with its mechanism, legal-context manifestation, warning signs visible inside a legal function, and the Defensibility element that addresses it. The Taxonomy is versioned at 2026.1; new classes may be added at quarterly review.
Why a Risk Taxonomy now
Legal functions adopting AI inherit an existing risk vocabulary built for other domains. Cybersecurity risk, vendor risk, operational risk, regulatory risk, and reputational risk are mature categories with established frameworks and committee structures. AI use cases get registered against these existing categories, and the function moves on.
The problem is that the existing categories do not capture the shape of legal AI risk with enough specificity to drive action. A hallucinated case citation is technically an "operational risk" and an "AI accuracy issue" and a "vendor reliability issue" depending on how you frame it, but none of those framings identifies the actual mechanism, none surfaces the specific evidence required to defend against it, and none names the control that reduces it. The risk register entry reads "AI accuracy" and the mitigation reads "user verifies output," and the function congratulates itself for having registered the risk while remaining structurally unprepared for any of the failure modes that the entry actually covers.
The Risk Taxonomy 2026 names the nine classes that constitute legal AI risk with enough specificity to make response operationalisable. Each class has a distinct mechanism, a distinct evidence base, a distinct mitigation pattern, and a distinct accountable owner. None collapses into another. None is captured by a generic enterprise risk category at the level of resolution legal governance requires.
The Taxonomy is the inventory companion to the Defensibility standard. Defensibility describes the response capability a legal function must demonstrate. The Taxonomy describes what must be responded to. The two artefacts pair: a Risk Register that uses the Taxonomy plus an Evidence Register that anchors Defensibility together constitute the minimum governance posture for institutional AI use in a legal function.
What makes a risk class
A risk is a candidate for inclusion in the Taxonomy if it satisfies four criteria. It must have a distinct mechanism (how does it manifest in practice, distinguishable from other classes). It must have distinct evidence (what specific signals indicate it is present or has occurred, beyond what the other classes would produce). It must have distinct mitigation (what control or process reduces it, that is not the mitigation for another class). And it must have distinct accountability (which named role inside the function owns reducing it, even when other roles contribute).
A candidate that collapses to the same four answers as an existing class is a variant of that class, not a new one. A candidate that has distinct mechanism but the same mitigation as an existing class is a variant. A candidate that has distinct evidence but no distinct accountable owner is a description, not a class.
By this test, several frequently-named "AI risks" do not constitute classes in the Taxonomy. "AI bias" is a description of mechanisms that surface variously as hallucination (output of false-positive patterns), data leakage (training corpus reflects historical patterns), or regulatory non-compliance (output influences decisions about individuals in protected categories). "AI explainability" is a property of evaluation methodology that gates two existing classes (methodology transparency and decision traceability) rather than a class itself. "AI safety" is the umbrella under which the Taxonomy sits, not a class inside it.
This discipline is the reason the Taxonomy stays at nine rather than expanding indefinitely. Every governance vocabulary needs to be small enough that the board can hold the whole list in working memory.
The nine classes
1. Hallucination
Mechanism. The AI system generates content that is plausible, coherent, and authoritative-sounding but factually wrong. In legal contexts, the wrong content is often a citation to a case that does not exist, a regulation that does not say what the AI claims it says, a clause attributed to a precedent that the precedent does not contain, or a synthesised summary of a doctrine that diverges materially from the doctrine itself.
Legal-context manifestation. A research memo cites three cases. Two are real. The third is fabricated, complete with a plausible citation, plausible holding, and plausible parties. A contract drafting tool inserts a clause modelled on what similar contracts contain, including a defined term that the underlying contract does not define. A regulatory summary describes an obligation under the EU AI Act that does not exist in the Act's text but is consistent with the Act's spirit.
Warning signs visible inside the function. Citations appearing in work product that no one on the team recognises. Definitions in contract output that are not anchored to the rest of the document. Confidence in AI-generated summaries that exceeds the reviewer's own familiarity with the underlying source.
Defensibility element that addresses it. Decision traceability. The function must be able to reconstruct, for any AI-assisted output of consequence, what the input was, what the model returned, and which human reviewer validated each citation, definition, or claim against primary sources.
2. Data leakage
Mechanism. Information that should have remained inside the function reaches a model provider, a vendor's broader infrastructure, or another vendor customer through the AI system's data pathways. The leakage can be deliberate-by-design (the vendor uses customer prompts to train its base model unless customer opts out), inadvertent (a prompt contains privileged information that the vendor's logging captures and retains beyond the customer's expectation), or operational (vendor support staff access prompt history during a customer support ticket without restricting visibility to authorised individuals).
Legal-context manifestation. A partner pastes a draft brief into an AI tool to refine the language. The vendor's terms of service permit prompt content to enter training; the next iteration of the model contains echoes of the brief's strategy. A paralegal uploads a deposition transcript for summarisation; the vendor's data residency is unclear and the transcript transits servers outside the jurisdictions the matter's protective order permits. A vendor's customer support team accesses prompt logs to debug an issue and observes content covered by attorney work-product doctrine.
Warning signs visible inside the function. Vendor terms of service that permit prompt-to-training use by default. Vendor documentation that does not specify data residency. Vendor support flows that grant employee access to customer prompt content without per-incident customer authorisation. Absence of an Evidence Register entry confirming data isolation for any deployed AI system.
Defensibility element that addresses it. Data handling. The function must maintain contemporaneous proof per AI system in use that customer data is isolated from model training by default, residency is documented and configurable, retention is bounded, and vendor employee access to prompt content is controlled.
3. Model drift
Mechanism. The vendor's underlying model changes behaviour between versions without proportionate notice to the deployer. A tool that produced one set of outputs in January produces materially different outputs in March on the same inputs. The change can be a vendor-deliberate model upgrade, a vendor-undeclared training data refresh, or a downstream behaviour change in a third-party model the vendor depends on.
Legal-context manifestation. A contract-review tool flags a clause as high-risk in one matter and identical-language as low-risk in a later matter. A research tool returns different case summaries for identical queries asked two months apart. A drafting tool's house style shifts between versions without notification, and previously-signed-off template language stops generating consistently.
Warning signs visible inside the function. Vendor change logs that are absent, vague, or describe model upgrades only after the fact. Reviewer reports of inconsistent output behaviour. Workflow exception rates that fluctuate without obvious cause. Vendor pricing or tier changes coinciding with quiet capability adjustments.
Defensibility element that addresses it. Lifecycle and methodology transparency. The function must require vendors to publish change logs, model upgrade notices with customer-impact assessment, and deprecation policies with notice SLAs. Internally, the function must version its methodology against the version of the model in use and reassess at every vendor upgrade.
4. Vendor lock-in
Mechanism. Workflows, data, and methodology become deeply embedded in one vendor's tooling such that the switching cost to exit the vendor (whether for commercial reasons, security reasons, or because the vendor's posture has degraded) is disproportionate to the value extracted. Lock-in can be technical (proprietary data formats, vendor-specific APIs), workflow (training programmes, established review patterns), commercial (multi-year contracts with steep early-termination penalties), or regulatory (the function's compliance posture references the vendor's specific certifications).
Legal-context manifestation. Five years of contract review history sits inside one vendor's proprietary format with no portable export. The function's AI literacy programme is built around one vendor's product training; switching vendors requires re-training every lawyer. The function's data processing agreements and EU AI Act conformity assessments reference the vendor's specific SOC 2 reports and ISO certifications, and a vendor exit triggers re-papering with successor and potentially re-assessment.
Warning signs visible inside the function. Vendor's data export options are limited or proprietary. Methodology documentation references the vendor by name in places that should reference capabilities. AI literacy materials are vendor-specific rather than capability-general. Multi-year contract terms with no off-ramp clauses.
Defensibility element that addresses it. Methodology transparency and lifecycle. The function should be able to articulate its methodology in terms of capabilities required rather than vendors deployed. Vendor contracts should include data portability, exit-assistance, and continuity terms. The Evidence Register should anchor to capabilities, not vendor logos.
5. Regulatory non-compliance
Mechanism. The deployment of an AI system, or the function's governance around it, violates a current regulatory obligation or fails to anticipate a near-term emerging one. The obligation can be a specific Article of the EU AI Act, an ICO guidance requirement under UK GDPR, a sectoral regulator's AI expectations (FCA, OCC, FDA, professional conduct authorities), or a court rule on AI disclosure in filings.
Legal-context manifestation. A contract analytics tool processes employment contracts in a way that meets the EU AI Act's "high-risk" criteria but the function has not completed the conformity assessment the Act requires. An AI-assisted decision support tool used in regulated-industry advisory work falls under sectoral AI guidance that the function has not mapped. AI use in court filings is not disclosed where the court's local rules require disclosure.
Warning signs visible inside the function. Risk Register entries for regulatory exposure that name "EU AI Act" abstractly rather than naming specific Articles or obligations. Absence of a documented mapping from AI use case to applicable regulatory regime. Sectoral guidance updates that arrive without the function's compliance committee assessing impact.
Defensibility element that addresses it. Governance posture and methodology transparency. The function must maintain a current mapping of AI use cases to applicable regulations and an audit trail showing that each obligation has been assessed and addressed. ISO/IEC 42001's management-system requirements provide the structural template.
6. Professional conduct exposure
Mechanism. AI use creates exposure under the professional conduct rules that govern lawyers individually, separately from regulatory exposure on the function or organisation. The exposure typically involves competence (using a tool whose limitations the lawyer does not understand), candour (not disclosing AI assistance where required), confidentiality (the lawyer's individual duty as well as the function's), supervision (a lawyer is responsible for AI-assisted work by non-lawyer team members), or misrepresentation (presenting AI-generated content as the lawyer's own analysis without acknowledgement).
Legal-context manifestation. A solicitor signs a written opinion that includes AI-generated analysis without verifying the AI's methodology or output, and the opinion turns out to rest on a hallucinated case. A litigator submits a brief containing AI-generated argument structure without disclosing AI use to a court whose practice rules now require disclosure. A senior counsel supervises a paralegal using an AI research tool and is professionally accountable for the paralegal's failure to verify the tool's output.
Warning signs visible inside the function. Absence of a documented standard for AI-assisted work product attribution. Lack of training on jurisdiction-specific AI disclosure rules for court filings. Supervision frameworks that do not contemplate AI-mediated tasks. Individual lawyers expressing uncertainty about whether their use of a given tool meets competence obligations.
Defensibility element that addresses it. Decision traceability and continuous learning. The function must maintain attribution standards for AI-assisted work, jurisdiction-specific disclosure protocols, supervision frameworks updated for AI-mediated tasks, and a feedback loop that captures professional-conduct close calls before they become incidents.
7. Client confidentiality breach
Mechanism. Information protected by attorney-client privilege or matter confidentiality reaches a third party (a model provider, a vendor's broader infrastructure, another customer, or a vendor employee) through an AI system in a way that compromises privilege or breaches the function's confidentiality obligations to clients. This class is adjacent to data leakage but distinct: data leakage covers any sensitive information; client confidentiality breach covers specifically privileged or contractually confidential matter content with downstream legal consequences for the function and its clients.
Legal-context manifestation. Privileged communications enter prompts to a vendor whose terms of service permit training use, potentially waiving privilege. A matter's protective order requires data to remain in-jurisdiction, and the AI vendor's processing crosses jurisdictions in a way that breaches the order. Client-specific outside counsel guidelines prohibit use of unapproved AI tools, and a partner uses an unapproved tool on the client's matter.
Warning signs visible inside the function. Absence of a documented client-by-client AI policy that maps each client's outside counsel guidelines to AI tool approval status. Vendor approval workflows that consider security and operational risk but not client-specific consent. Matter intake processes that do not capture AI restrictions from protective orders or engagement letters.
Defensibility element that addresses it. Data handling and governance posture. The function must maintain matter-level and client-level AI policy mapping, vendor approval workflows that consider client-specific consent, and matter intake processes that surface AI restrictions before tooling is deployed on the matter.
8. Shadow AI proliferation
Mechanism. Individuals inside the function use AI tools the function has not approved, the governance framework does not know about, and the Evidence Register cannot account for. The use can be a lawyer using a consumer AI assistant on a personal account for client work, a paralegal using a free research tool the function's vendor list does not include, or a partner pasting sensitive content into an uncontrolled chatbot for quick summarisation. Shadow AI is the structural condition that creates every other class in the Taxonomy without governance visibility.
Legal-context manifestation. A senior associate uses a consumer AI assistant on their personal account to summarise a deposition transcript, putting matter content through an unvetted vendor with unclear terms. A team adopts a free AI research tool informally because the function's procurement process is slow, and the tool produces inconsistent results no one tracks. Partners share AI-generated content in informal channels without methodology transparency, and junior lawyers absorb the practice without realising the governance gap.
Warning signs visible inside the function. A vendor list that no one uses as a working reference. AI tool usage rates that diverge between the function's monitored systems and informal observation. Junior lawyers who can name AI tools their seniors use but cannot point to the function's approved list. Conversations about AI capability that reference tools the function has not formally evaluated.
Defensibility element that addresses it. Governance posture. The function must maintain an actively-curated approved-vendor list, a fast-path approval process for new tools (such that the slow path does not push usage underground), AI literacy programmes that name the approved list explicitly, and a non-punitive disclosure mechanism so existing shadow use can be brought into the framework rather than driven further underground.
9. Accountability dilution
Mechanism. When AI is in the decision loop, the question of who decided becomes structurally blurry. The lawyer signed the work product, so the lawyer is accountable. The AI suggested the analysis the lawyer accepted, so the vendor is implicated. The function approved the AI, so the function is accountable. The board approved the AI programme, so the board is implicated. The blurriness itself, independent of any specific failure, is the risk: when accountability is diffuse, no single party invests in the discipline that any single accountable party would invest in if accountability sat with them clearly.
Legal-context manifestation. A regulator inquires about an AI-influenced decision. The investigation produces multiple accountability candidates (lawyer, function, vendor) but no single party that can be held fully accountable, and the resulting remediation is diffuse. A board asks who is accountable for the function's AI posture overall. The General Counsel says they are. The Chief AI Officer says they are. The Chief Risk Officer says it is shared. The board concludes that no one is, and asks the CEO to assign clearly.
Warning signs visible inside the function. No named individual accountable for the function's overall AI posture. Accountability framings that describe AI governance as "shared," "matrixed," or "cross-functional" without naming an individual ultimately answerable. Risk Register entries for AI use cases that name the function rather than a person as owner. Board materials that describe AI accountability in committee structure terms rather than in individual-name terms.
Defensibility element that addresses it. Governance posture and continuous learning. The function must have a named individual accountable for AI overall, with the authority and the documented mandate to enforce the governance framework. The accountability must be articulable: the named owner can describe, without preparation, what AI systems are in use and what controls are in place. Diffuse accountability is the failure mode the Defensibility framework is structurally designed to prevent.
How the Taxonomy is used
The Taxonomy is a vocabulary for three artefacts that legal functions maintain.
Risk Register. Every AI-related entry in the function's Risk Register maps to one of the nine classes. Entries that do not map cleanly are reclassified. The function does not create off-Taxonomy entries; if the candidate risk does not fit, either the Taxonomy needs expansion (proposed at quarterly review) or the candidate is a description rather than a class.
Evidence Register. Per AI system in use, the function records the evidence it holds against each of the nine classes. Hallucination evidence is the per-system evaluation history. Data leakage evidence is the data processing agreement and the residency confirmation. Vendor lock-in evidence is the export and exit-assistance terms. The Evidence Register is the operational substrate for Defensibility.
Vendor Index scoring. The Advanta Vendor Index scores vendors against six dimensions (Governance, Evaluation, Security, Data Handling, Transparency, Lifecycle) that align to the Taxonomy: a vendor that scores poorly on Evaluation introduces hallucination risk; a vendor that scores poorly on Data Handling introduces data leakage and confidentiality risk; a vendor that scores poorly on Lifecycle introduces drift and lock-in risk. The Vendor Index methodology and the Risk Taxonomy share an underlying logic.
Consistency of vocabulary across these three artefacts is what makes AI governance discussable at board level. A board that hears "AI risk" abstractly cannot govern it; a board that hears the nine classes named with their specific manifestations and their specific evidence positions can.
Drift, versioning, and revision
The Taxonomy is versioned. This release is 2026.1. The version label travels with the Risk Register entries and Evidence Register entries that reference the Taxonomy, so a function reviewing its Risk Register in 2027 can identify which version of the Taxonomy each entry was filed against.
Revision cadence:
- Quarterly review. The Editorial Council examines the Taxonomy against the prior quarter's incident reports, regulatory developments, and vendor ecosystem shifts. New classes may be proposed for addition if they meet the four-criteria test. Patch updates (rubric refinement, additional warning-sign examples) may be applied without Council vote.
- Annual major revision. A major version (2027.1) may be issued if the Council determines that the structure of the Taxonomy needs realignment. Major revisions trigger re-mapping of all Risk Register entries.
- Removal. Removing a class requires founder and unanimous Editorial Council approval. The bar is high because once removed, historical incidents classified against the removed class become harder to compare against future incidents.
The Council documents every revision in the public change log of this essay.
The Advanta position
The Risk Taxonomy 2026 is canon because it makes AI governance specific. A legal function that registers "AI risk" against generic enterprise categories has nothing actionable to defend with. A function that registers each AI risk against one of nine named classes, holds evidence against each, and can name the accountable owner for each, has the structural prerequisites of Defensibility.
The Taxonomy and the Defensibility framework are not separate products. They are the two sides of the same governance posture: what must be responded to (the Taxonomy) and what response capability must be demonstrated (Defensibility). A function that adopts one without the other is exposed.
Advanta publishes both because the standards become credible only when documented, contested, and refined in public. The Vendor Index applies them to the vendor ecosystem. The Diagnostic measures them inside the legal function. The Annual Index, beginning in 2027, will publish aggregate maturity distribution against them.
A function that operates against the Risk Taxonomy 2026 has the vocabulary. A function that pairs it with the Defensibility framework has the response capability. The two together constitute institutional readiness for AI at scale.