The AI Lifecycle is the temporal frame for institutional AI use in legal functions. Every AI capability the function deploys moves through five canonical stages: Concept, Build, Deploy, Operate, Sunset. Each stage applies different governance disciplines, exposes different Risk Taxonomy classes, requires different Defensibility evidence, and produces different ROAI return.
The vendor-centric conversation about AI in legal functions treats AI as a procurement event: select a vendor, deploy the tool, capture the productivity. The Lifecycle frame treats AI as an operating discipline that begins before procurement and continues through retirement. Functions that operate the Lifecycle compound governance posture over years. Functions that treat AI as a procurement event repeat the same governance failures on each new tool.
Each stage is defined with its operational tasks, the governance cadence that applies, the Risk Taxonomy classes most exposed during that stage, the Defensibility elements most active, and the Advanta Module Library modules and advisory engagements that support the function through it.
The Lifecycle is versioned at 2026.1. The five stages have been stable across major professional AI governance frameworks and are unlikely to require structural revision. The Lifecycle is the temporal frame on which the rest of the operating cluster depends.
Why a Lifecycle frame
Most conversations about AI in legal functions treat AI as a procurement event. The function identifies a need, evaluates vendors, selects one, deploys the tool, and absorbs the result into the workflow. Governance attention concentrates at procurement and dissipates afterward. Twelve months later the tool is in production, the vendor has shipped two model upgrades, the function's risk register entry has not been refreshed, and the original procurement-stage governance has nothing to say about the current operating state.
The Lifecycle frame rejects the procurement-event model. AI capabilities are not procurement events. They are operating disciplines that have stages. Each stage requires distinct attention, distinct evidence, and distinct accountability. The function that recognises the stages and applies the correct governance at each compounds posture over time. The function that treats AI as procurement repeats the same governance failures on every new tool.
The Lifecycle is also the temporal frame that the other anchor essays in this cluster need. Defensibility names the response capability that the function must demonstrate. Risk Taxonomy 2026 names the nine classes of risk that must be responded to. ROAI names the four quadrants of return that must be measured. None of these is uniform across the life of a capability. The Concept stage exposes different risks than the Operate stage. The Build stage requires different Defensibility evidence than the Sunset stage. ROAI's productivity quadrant peaks in Operate and goes to zero in Sunset; the Defensibility quadrant runs throughout.
The Lifecycle is the structural answer to the question "what governance applies when?" without which the rest of the framework is timeless and therefore harder to operationalise.
The five stages
Stage 1: Concept
What it is. The function identifies a candidate AI use case. The trigger can be internal (a workflow the function wants to improve, a risk the function wants to reduce, a strategic capability the function wants to build) or external (a vendor demo, a peer function's published case, a regulatory development that makes AI capability newly relevant). The Concept stage ends with a decision: pursue or do not.
Operational tasks. Define the problem. Specify the success criteria in advance, including which quadrants of ROAI matter most for this capability and what the Defensibility posture target is. Identify which Pillars are touched (the audit's canonical 8-Pillar framework names them). Map the candidate against the Risk Taxonomy 2026 to surface which risk classes the use case will introduce or amplify. Document the named accountable owner for the use case if pursued.
Governance cadence. Concept-stage decisions are made by the governance committee at its regular cadence, not ad hoc. The committee reviews each candidate against a structured intake (problem statement, success criteria, ROAI hypothesis across the four quadrants, anticipated Risk Taxonomy exposure, proposed named owner). Concept decisions are recorded in the committee's minutes with the rationale.
Risk Taxonomy classes most exposed. Hallucination becomes a Concept-stage concern when the use case requires the AI to produce output the lawyer will rely on. Shadow AI proliferation becomes a Concept-stage concern when the use case is being driven by existing informal AI use rather than by deliberate planning. Accountability dilution can take root at Concept if the named owner is not clearly assigned.
Defensibility elements most active. Governance posture (the committee is the structural mechanism) and methodology transparency (the Concept memo articulates why this use case at all).
Advanta support. The Free Baseline Diagnostic produces the baseline against which Concept-stage candidates should be evaluated (does this candidate close a gap the diagnostic surfaced?). The Module Library's Concept-stage modules cover use case identification, problem framing, and committee intake templates.
Stage 2: Build
What it is. The function commits to the use case and builds toward production deployment. Build covers vendor selection, contracting, configuration, integration with existing workflows, pilot design, and training. The Build stage ends with a pilot that meets pre-defined acceptance criteria, or with a decision to abandon.
Operational tasks. Score candidate vendors against the Vendor Index methodology's six dimensions (Governance, Evaluation, Security, Data Handling, Transparency, Lifecycle). Negotiate contracting that includes data isolation, residency, exit-assistance, and notice SLAs on model upgrades. Configure the tool against the function's data handling standards. Design the pilot with cohort-controlled methodology so the post-pilot evaluation produces credible numbers. Build the training programme. Update the Risk Register with the new entries this capability introduces, mapped to the Risk Taxonomy.
Governance cadence. Vendor selection requires committee approval. Material configuration choices (data residency, training opt-out, retention) require committee approval. Contract execution requires the function's standard procurement governance plus AI-specific committee sign-off. Pilot results are reviewed by the committee before promotion to Stage 3.
Risk Taxonomy classes most exposed. Vendor lock-in becomes a Build-stage concern in contract negotiation: every clause about data formats, exit assistance, and continuity is a lock-in concern. Data leakage becomes a Build-stage concern in configuration: the difference between data-isolation-by-default and data-flows-to-training-by-default is set during Build. Regulatory non-compliance becomes a Build-stage concern when the use case meets EU AI Act high-risk criteria and the conformity assessment must be completed before deployment.
Defensibility elements most active. Methodology transparency (the vendor scoring documentation), governance posture (committee approvals at each gate), evidence framework (initial entries to the Evidence Register).
Advanta support. The Vendor Index methodology and the Vendor Index itself score candidate vendors. The Module Library's Build-stage modules cover vendor evaluation frameworks, contract clause libraries, configuration checklists, and pilot design templates. The Programme Design engagement supports Build for functions building their first institutional AI capability.
Stage 3: Deploy
What it is. The function moves from pilot to production. Deploy covers cutover from the pre-AI baseline, workflow updates, user training rollout, and the initial weeks of production operation when teething issues surface. The Deploy stage ends when the function declares the capability is in steady-state operation.
Operational tasks. Cutover from baseline to AI-assisted workflow. Update operating procedures and training materials. Roll out training to the user population. Operationalise the audit trail (decision traceability is no longer hypothetical at Deploy; it is producing logs). Monitor for early-stage issues (lawyers using the tool incorrectly, exceptions arising at higher than expected rates, output quality below pilot baseline).
Governance cadence. The committee receives weekly status reports during the first month of Deploy and shifts to monthly cadence once the capability is stable. Any material exception in the first month is reviewed by the committee directly rather than handled at the function's operational layer.
Risk Taxonomy classes most exposed. Professional conduct exposure becomes a Deploy-stage concern as lawyers adapt to AI-assisted work and the function's supervision frameworks are tested in production. Shadow AI proliferation becomes a Deploy-stage concern in the opposite direction: if the official tool fails to meet user needs early in deployment, informal alternatives proliferate quickly. Hallucination becomes a Deploy-stage concern as production volume surfaces edge cases the pilot did not.
Defensibility elements most active. Decision traceability (now operationalised), continuous learning (early Deploy-stage incidents feed back into the framework), governance posture (visible committee engagement reassures the user population).
Advanta support. The Module Library's Deploy-stage modules cover cutover playbooks, exception triage procedures, training rollout sequences, and committee status report templates. The Strategic Retainer engagement supports Deploy for functions that want named-advisor partnership through the cutover period.
Stage 4: Operate
What it is. The function operates the AI capability in steady-state production. Operate is the longest stage by duration: most capabilities spend years here. The stage covers ongoing measurement of ROAI across the four quadrants, ongoing evidence collection per the Evidence Register cadence, ongoing risk monitoring against the Risk Taxonomy, incident handling, model drift detection, vendor relationship management, and continuous learning loop closure.
Operational tasks. Quarterly refresh of the Evidence Register entries for this capability. Quarterly review of the Risk Register entries for this capability. Quarterly review of the capability's ROAI performance against the original Concept-stage hypothesis. Annual vendor relationship review. Incident logging and root-cause analysis when failures occur. Model upgrade impact assessment whenever the vendor ships a new version.
Governance cadence. Quarterly committee review of each capability in Operate. Annual committee deep-dive on the capability against its original Concept memo. Out-of-cycle review triggered by incident, regulatory development, or material vendor change.
Risk Taxonomy classes most exposed. Model drift is the dominant Operate-stage concern: it is the risk class that only surfaces in production over time. Data leakage continues as an Operate-stage concern through ongoing vendor contact, support tickets, and configuration changes that erode initial Build-stage settings. Accountability dilution becomes an Operate-stage concern when capabilities age and the original named owner has moved on without explicit succession.
Defensibility elements most active. Continuous learning (the Operate stage produces most of the function's learning), evidence framework (the Evidence Register is most actively maintained here), decision traceability (running steadily), methodology transparency (refreshed as model versions change).
Advanta support. The Module Library's Operate-stage modules cover quarterly evidence refresh, incident response, model upgrade assessment, and ROAI measurement templates. The Strategic Retainer is the primary Advanta engagement for capabilities in Operate.
Stage 5: Sunset
What it is. The function retires the AI capability. Sunset can be triggered by vendor failure (commercial collapse, security incident, capability degradation), by capability replacement (a better tool, an in-house build), by use case obsolescence (the underlying workflow no longer exists), or by regulatory change (the use case no longer compliant under current regime). Sunset is structured retirement, not abandonment.
Operational tasks. Notify the user population. Migrate workflows to the successor capability or to the pre-AI baseline. Export data in portable format. Archive the Evidence Register for the capability (Defensibility evidence retains relevance after retirement). Capture lessons learned for the Continuous Learning loop. Decommission the technical integration. Close the vendor relationship per the contract's exit terms.
Governance cadence. Sunset decision requires committee approval, including a written assessment of why the capability is being retired and what successor (if any) takes its place. Post-sunset, the committee receives a final ROAI report for the capability comparing realised return against the original Concept-stage hypothesis.
Risk Taxonomy classes most exposed. Vendor lock-in becomes acute at Sunset: contractual terms negotiated at Build either enable clean exit or constrain it materially. Client confidentiality breach becomes acute at Sunset around data egress: the function's data must leave the vendor's environment cleanly, and the vendor's continuing access to historical prompt logs must be addressed. Accountability dilution can take root if the original named owner has moved on and Sunset is run without clear ownership.
Defensibility elements most active. Lifecycle (the Defensibility element named for this stage is literally about lifecycle discipline), evidence framework (final archive), continuous learning (the post-mortem feeds the next Concept stage).
Advanta support. The Module Library's Sunset-stage modules cover exit playbooks, data egress checklists, vendor closeout, archival standards, and post-mortem templates. The Executive Diagnostic engagement is appropriate for high-stakes Sunsets (regulatory-driven, security-incident-driven) where the function needs board-ready written assessment of the retirement.
How the Lifecycle is operationalised
The Lifecycle frame becomes operational when it informs three artefacts the function maintains.
The Capability Portfolio. Every AI capability the function operates is registered with its current Lifecycle stage. A function with twelve capabilities in production might have one in Concept, two in Build, one in Deploy, seven in Operate, and one in Sunset at any given time. The Portfolio view surfaces stage-balance: a function with twelve capabilities all in Operate and none in Concept is not actively renewing; a function with eight capabilities in Build and only three in Operate is over-extending governance attention.
The Governance Cadence. The committee's calendar reflects the Lifecycle. Concept-stage candidates are reviewed at the standing intake meeting. Build-stage approvals (vendor selection, configuration sign-off, pilot promotion) populate the committee's working cycle. Operate-stage capabilities populate the quarterly review cadence. Sunset decisions are scheduled with the same gravity as Concept approvals: both are structural decisions about the function's AI posture.
The Defensibility Posture Statement. The Statement (named in the Defensibility essay) lists capabilities by Lifecycle stage. A reader of the Statement can see at a glance which capabilities are in Operate (the function's current production AI surface), which are in Build (the function's near-term AI roadmap), and which are in Sunset (the function's retirement queue, which often signals security or commercial concerns about a vendor).
How the Lifecycle interacts with the other clusters
Defensibility. Each of the five Defensibility elements applies across the Lifecycle but peaks at different stages. Decision traceability is established at Build, operationalised at Deploy, runs steadily at Operate, and archives at Sunset. Methodology transparency is established at Concept and Build, maintained at Operate, and refreshed at every model upgrade. Evidence framework collection begins at Build, runs continuously at Operate. Governance posture is most visible at the stage-transition gates. Continuous learning is fed by Operate-stage incidents and Sunset post-mortems.
Risk Taxonomy 2026. Each of the nine classes has a Lifecycle exposure profile. Hallucination exposure is highest during early Operate when production volume surfaces edge cases the pilot did not. Data leakage exposure is highest at Build (in configuration) and at Sunset (in egress). Model drift exposure is highest at Operate. Vendor lock-in exposure crystallises at Build (in contracting) and is paid at Sunset (in exit). Each class can be plotted across the five stages — a Lifecycle-Risk view that surfaces where committee attention concentrates.
ROAI. The four quadrants of ROAI run on different Lifecycle clocks. Productivity value accumulates during Operate and goes to zero at Sunset. Defensibility value accumulates throughout the Lifecycle and persists post-Sunset (the function retains the Defensibility posture the capability helped build). Institutional value compounds across the Lifecycle as the function's overall posture matures. Category positioning value rewards early Concept-stage action: the function that enters Concept first captures the most positioning return regardless of how long the capability stays in Operate.
Vendor Index. Each of the six scoring dimensions in the Vendor Index methodology has a stage at which it matters most. Governance and Evaluation matter most at Concept and Build (selection). Security and Data Handling matter most at Build and Operate (configuration and running). Transparency matters across the Lifecycle (Operate-stage queries need transparency; Sunset-stage exit needs transparency). Lifecycle (the dimension) matters most at Operate (the stage where the vendor's lifecycle discipline directly affects the function's lifecycle discipline) and at Sunset (the exit terms).
The Advanta position
The AI Lifecycle frame is canon because it makes AI governance temporally specific. A function that names its governance disciplines without naming the stages at which they apply is operating on a timeless model that does not survive contact with production. A function that maps each governance discipline to the Lifecycle stages at which it applies has the structural prerequisite for sustained AI posture.
The five stages have been stable across the major professional AI governance frameworks and across the iterations of Advanta's own canon. They are unlikely to require structural revision. The Lifecycle frame is the longest-lived element of the operating canon.
The Defensibility cluster of essays (Defensibility, Risk Taxonomy 2026, ROAI, AI Lifecycle, and Agentic Tier when published) together constitute the operating canon for institutional legal AI. Defensibility names the response capability. Risk Taxonomy names what must be responded to. ROAI names what returns must be measured. The Lifecycle names when each applies. Agentic Tier (forthcoming) will name how the framework adapts when the AI is operator rather than augmentation.
A function that operates against the full cluster has the framework. A function that operates against the Lifecycle alone has the temporal frame without the other dimensions. A function that operates against the other essays without the Lifecycle has the dimensions without the temporal frame. The cluster is the unit.