From request to retirement: a lifecycle for every AI system you run

Ask a governance team for a list of the AI running in production today and watch what happens. Someone opens the register. Someone else opens a spreadsheet. A third person checks Slack for the tool finance started using in the spring. The register says 40 systems. Nobody is sure how many of them still run, and nobody can say when the old chatbot was switched off.

An AI register is only useful if it describes the present. Most registers describe the day each entry was created.

The next VerifyWise release closes that gap. Every use case and every AI app now moves through a lifecycle, from the first request to retirement. Owners confirm on a schedule you set that their live systems are still in use. The intake process in front of it is clearer for the people asking.

Four stages, one glance

The Use cases page now has four tabs: In review, Planned, Live and Retired. Each tab shows a count, so the shape of your AI estate is visible before you click anything.

When a use case goes into production, its owner marks it as live and records the go-live date. When it is switched off, they retire it. A retired use case stays in the inventory with its full history, so you can still show an auditor what ran last year and when it stopped.

Stages move on their own where the meaning is clear. A use case waiting on an approval sits in In review. It moves to Planned when the decision is made. The status field keeps doing its old job of tracking the work.

A register that stays true

Admins choose how often owners must confirm their live systems: every 30, 90 or 180 days. If nobody confirms a live use case in time, it gets a Stale marker. Its owner gets an email asking them to confirm it or retire it, once per interval until someone acts.

This answers the question every auditor eventually asks: how do you know your inventory is current? With hundreds of entries, no central team can check each one by hand. The still-live check puts that work on the people who know each system. One click confirms it. One click retires it.

The lifecycle on the dashboard

The dashboard picks all of this up. It shows how many use cases sit in each stage and what went live or was retired this quarter. It breaks live use cases down by department, risk tier or regulation. A separate card lists the stale entries.

The Time in review card gives the median and average number of days intake requests waited for approval over the last 12 months. If your process is slow, you will see it here first. If it is fast, you have the number to prove it.

Requests show up the moment they arrive

Shadow AI often starts with a request nobody saw. Requests sent through an intake form now appear at the top of the In review tab, next to the use cases waiting for a decision. Each one shows who sent it, when it arrived and how many days it has waited.

No use case is created until a reviewer approves the request. Approved requests arrive in Planned with the requester's answers filled in. Rejected requests never clutter the inventory.

Requesters know who is looking and by when

When a request seems to vanish, people stop asking and start using AI tools anyway. So the confirmation email now names the reviewers and the date to expect a decision, for example "Ann Lee will review your submission within 3 business days, by Thursday, November 5, 2026."

Each form has its own review time, from 1 to 30 business days. With reviewer assignment on, the email waits until the request has a review level and names the right reviewers. If the email cannot be sent, VerifyWise tries again with growing waits between attempts. A named person and a date also hold the governance team to a response time.

The risk level, before anyone hits submit

Most intake forms ask the requester to pick a risk tier. Many of them guess "minimal". Now they answer short questions based on the EU AI Act instead. The form suggests a risk level on the spot, with the reasons and the legal references.

The suggestion comes from the same fixed rules that classify the submission. The same answers always give the same result. Every reference points at a real article. That makes it easy to explain to an auditor. Under Why this matters, the requester sees what the Act asks of them at that level, for their role as provider or deployer.

Requesters can accept the suggestion or add context for the reviewer. The governance team still makes the final call, and it sees how the requester responded. A plain-language explanation is one click away when the form has an AI model connected. Answers go to that model only when the requester asks for it.

By the time your team opens the request, the person asking already knows it is probably high risk under Annex III. They also know why.

Reviewer assignment you can set up alone

Intake forms can send each request to expert or regular reviewers based on its risk score. The settings are a threshold, a close-call margin and a second review share. Each one now has an info icon that explains what it does, the 0 to 100 score scale and the score band for each risk level.

A summary line under the settings spells out the result in plain words: "Scores of 60 or more, prohibited practices and scores less than 5 points from 60 go to expert reviewers." Form owners can set this up without a call to support.

New use cases start with your regulations

An admin can now set a default region and default frameworks for the organization, for example Europe with the EU AI Act. Every new use case opens with them filled in. People can still change both before they save.

It is a small change that removes a common mistake: a new use case with no framework attached at all.

The same lifecycle for the AI tools your staff use

Use cases cover the AI you build. AI apps cover the tools your employees use, such as ChatGPT Enterprise or Microsoft 365 Copilot. AI apps now get the same four tabs, go-live dates and still-live check.

Employees can request an app through an intake form of the new AI app type. Pending requests appear at the top of the In review tab. Approving one creates the app with the requester's answers. Banning an app moves it to Retired on its own.

An AI app must be Approved or Restricted before anyone can mark it as live. A Draft app can't show up as live in your inventory.

What this adds up to

Put together, every AI system in your organization now has an owner, an approval and a go-live date. Someone confirms on a schedule that it still runs. When it stops, it is retired with its history intact. Requests are visible from the minute they arrive. Requesters get a name, a date and a likely risk level. Reviewers get better requests to start from.

These features are coming in an upcoming VerifyWise release. If you want to see them on your own data first, book a demo and we will walk you through it.