Most AI governance programs govern one moment: the approval. A use case arrives, gets assessed, gets a decision, and then disappears into production where nobody looks at it again until something goes wrong or a regulator asks.

That’s not lifecycle governance. That’s a gate with nothing behind it.

The AI lifecycle runs from the first idea to the day the model is switched off and its data is disposed of — and each stage needs an owner, an artifact, and an exit criterion. Here’s how I’d build it, stage by stage, with attention to the two stages nearly everyone under-builds: intake and retirement.

Stage 1 — Intake: make the front door easier than the workaround

The purpose of intake is not to assess. It’s to know. Every AI use case in the organization should enter through a single front door, and the design goal is that using the front door is easier than avoiding it.

Practically:

Keep the initial form short. Ten to twelve questions, five minutes. Who’s the owner, what’s the business problem, what data does it touch, does it make or influence decisions about people, is it build or buy, is there a vendor, when do you want to go live. That’s enough to triage.

Put it where work already happens. A form in a portal nobody visits collects nothing. Embed intake triggers into the workflows that already catch new initiatives: the procurement intake form, the architecture review board, the project initiation process, the change advisory board. Procurement is the highest-yield of these by a wide margin, because most enterprise AI arrives as a purchased feature rather than a built system.

Catch embedded AI. The hardest intake problem isn’t the team that wants to build a model — they know they’re doing AI. It’s the HR system that quietly ships an AI screening feature in its next release, or the CRM that adds a summarization panel. A single screening question in procurement — does this product use, embed, or send data to an AI or machine-learning model? — plus a periodic sweep of your SaaS estate through your CASB, closes most of that gap. I’ve written separately about the shadow AI side of this problem.

Publish the SLA and meet it. “Low-risk use cases get an answer in three business days” is what buys you compliance with the process. Governance functions that take six weeks to respond train the organization to stop asking.

Artifact: an inventory record. Exit criterion: a risk tier assigned.

Stage 2 — Triage and risk tiering

Tiering is what makes the whole program affordable. Assess everything deeply and you’ll be the bottleneck; assess nothing deeply and you’ll miss the one that matters.

Tier on two axes:

  • Consequence — what happens to a person, the business, or a regulatory position when the system is wrong? Systems affecting employment, credit, access to services, health, safety, or legal rights sit at the top regardless of technical sophistication.
  • Autonomy — does it suggest to a human who decides, or does it act? An agent with tool access and write permissions is categorically different from a drafting assistant, and should be tiered accordingly. This is where the agentic governance questions get hard.

Add modifiers that bump the tier: personal or special-category data, use in a regulated process, external/customer-facing exposure, or a model the vendor can change without telling you.

Then define what each tier costs the requester in process. Tier 3 (low): self-service attestation against the acceptable use policy, logged, no committee. Tier 2 (moderate): impact assessment, security review, governance lead approval. Tier 1 (high): full impact assessment, legal review, evaluation evidence, committee approval, executive risk acceptance, defined monitoring plan.

Publish the tiering criteria. A tiering decision the business can’t predict feels arbitrary, and arbitrary governance gets escalated around.

Artifact: a documented tier with rationale. Exit criterion: assessment path determined.

Stage 3 — Impact assessment and design review

For anything above the lowest tier, this is where the real analysis happens. The AI system impact assessment — a requirement in ISO/IEC 42001 and the substance of the MAP function in the NIST AI RMF — asks what the system could do to people, not just what could be done to the system.

Core questions worth insisting on:

  • Who is affected, including people who aren’t users? (A candidate screened by an HR tool is affected and is not a user.)
  • What does failure look like, and who absorbs it?
  • What are the foreseeable misuse cases, not just the intended use?
  • Is there meaningful human oversight, or is a human nominally in the loop with no real ability or incentive to override?
  • Can we explain an individual decision to the person it affected?
  • What data trains or grounds it, where did that data come from, and were we permitted to use it that way?
  • What’s the fallback when it’s unavailable or wrong?

Run this in parallel with privacy (DPIA/PIA) and security review rather than in sequence — sequencing these three is what turns a four-week process into a four-month one. Reuse evidence across all three assessments.

Artifact: a completed impact assessment with identified risks and proposed treatments. Exit criterion: risks documented and treatment agreed.

Stage 4 — Build and evaluate

Governance’s role during build is to define the evidence bar and then get out of the way. Set it at tiering time so the team can build toward it rather than discovering it at the gate.

Evidence typically includes: documented evaluation against defined acceptance criteria; testing for the failure modes identified in the impact assessment; adversarial testing and red-teaming for high-tier and generative systems; bias and fairness testing where the system affects people; security testing including prompt injection resistance for anything with tool access; and documented system information for users.

Artifact: evaluation results. Exit criterion: acceptance criteria met, or exceptions explicitly accepted.

Stage 5 — The launch gate

One decision point, one set of criteria, one accountable approver. The principle I hold to across every AI deployment I’ve run: no rollout without evidence. Not “we’re confident” — demonstrated.

The gate checks: evidence bar met, residual risks accepted by a named executive with an expiry date, monitoring in place before go-live (not “in the next sprint”), the incident path defined and tested, user disclosure and feedback channel live, rollback plan documented, and the inventory record complete with a review date.

That last item is what connects this stage to the ones nobody builds.

Artifact: a signed approval in the decision log. Exit criterion: production.

Stage 6 — Production monitoring

This is where AI governance departs from traditional IT governance most sharply. An access control either works or it doesn’t. A model degrades quietly.

Monitor at minimum: performance against the acceptance criteria used at the gate; drift in inputs and outputs; human override rates, which are the best early warning you’ll get; user-reported issues; incidents; usage volume against the approved scope (a tool approved for internal drafting that’s now customer-facing is a scope change, not growth); and vendor model changes.

The vendor change item deserves emphasis. When a provider updates the underlying model, your evaluation evidence is stale and your risk position has changed without any action on your part. Contractual notification rights help; a periodic re-evaluation trigger helps more, because notification clauses are frequently honoured loosely.

Artifact: monitoring records and an issue log. Exit criterion: continuous.

Stage 7 — Periodic review

Review cadence by tier — annually for high, biennially for moderate, on-change for low. The review asks: is it still doing what it was approved to do, has the risk changed, is the evidence current, is the accepted residual risk still accepted, and — the question worth asking every time — is anyone still using this?

A surprising share of reviews conclude that a system should be retired. That’s a successful review, not a failure.

Artifact: an updated inventory record and a re-affirmed or revised approval.

Stage 8 — Retirement: the stage everyone skips

I have never seen an AI governance program that started with a decommissioning process, and I’ve seen several that discovered the need for one the expensive way.

Retiring an AI system properly means:

  • Announce and transition. Users depending on it need a path off.
  • Revoke access. API keys, service principals, connector credentials, agent identities. Orphaned agent credentials are a real and growing exposure — an agent nobody owns, still holding permissions to production data, is exactly the kind of finding that ends up in an audit report.
  • Handle the data. Training sets, fine-tuning data, embeddings and vector stores, cached outputs, prompt and interaction logs. Vector databases in particular tend to retain derived representations of source data long after anyone thinks the data is gone.
  • Establish the vendor’s deletion obligations — which is why the exit clause needed to be in the contract at Stage 1.
  • Preserve records. Retention obligations may outlive the system. Decisions the model made about people may need to be explainable for years. Retain the audit trail even when you delete the model.
  • Check downstream dependencies. Other systems, reports and processes may consume its outputs.
  • Close the inventory record with a retirement date, and keep it — a retired-systems register is what lets you answer questions about a decision made three years ago.

Artifact: a decommissioning record. Exit criterion: access revoked, data disposed, records retained.

What makes it stick

Three things separate lifecycle governance that works from a flowchart in a policy document:

Proportionality. If every stage applies at full depth to every system, teams will route around the process and you’ll govern less than you did before.

A single record that travels the whole lifecycle. One inventory entry, enriched at each stage, from intake to retirement. Governance spread across a form tool, a spreadsheet, a ticketing queue and a shared drive cannot answer basic questions about itself.

Evidence generated as a by-product of the workflow, not assembled at audit time. If your team spends three weeks pulling evidence together before an audit, the process isn’t producing evidence — it’s producing activity.

If you’re building an AI lifecycle process and want to pressure-test the stage gates, I’d be glad to compare notes.