Review Date

What a Review date means

A review date is a date fixed in advance on which an AI tool, or the rule that governs it, is checked again. The important word is “advance”. The date is chosen before anything has gone wrong, and written down where it will be seen, so that the check happens whether or not anyone thinks of it.

The site’s ownership article puts the date on each tool’s one-page record, beside the tool’s purpose, its users and the data it can reach. The reason is in the definition: the check does not depend on anyone remembering. A reminder that lives in somebody’s head leaves with them. A date in a calendar, against a named owner, does not.

This page defines the term, sets out how often the site’s articles say a review should happen for different things, and explains what to check on the day. It makes no claim beyond what those articles state, and it promises no result.

Why set the Review date in advance?

Because without one, nothing forces a decision. The time-saving article says it directly: a tool that has no scheduled review tends to stay in use by default, whether or not it earns its place. The tool is already installed, people have got used to it, and stopping it takes a reason. A fixed review point turns that around. The call is made at a set time, with the evidence in front of you.

A second reason comes from the customer data article. Tools change their terms often, so last year’s safe setting may not be this year’s. A review date in the diary is how a business checks the settings and the contract again, instead of trusting a decision made once.

The same logic applies to anything that does not stand still. The ownership article says an AI tool keeps moving after it is installed: the vendor updates the model behind it, the documents it draws on change, new features switch on and staff find uses nobody planned. A review carried out at launch then describes a tool that no longer exists in quite that form. The checking has to keep moving because the tool does.

How often should a Review happen?

It depends on what is being reviewed, and the site’s articles give different intervals for different things. This table sets them out. They are the site’s recommendations and not one rule.

Two of these give no interval, only a date. The customer data article says to put a date in the diary to check settings and the contract again, and the training plan article says to set the next review date and name who owns the shared library. Neither says how far ahead.

Read together, the pages put a written policy on a longer interval than a tool, and an assistant’s content on the shortest. Every one of them also has an early trigger, which a later section covers.

What does a Review check?

The ownership page lists four jobs for a tool’s owner, and a review is where they come together. The owner keeps a one-page record of what the tool is for, who uses it and what data it reaches. The owner samples its outputs on a regular schedule. The owner checks its permissions and settings after any change from the vendor. And the owner knows who to tell, and in what order, if something goes wrong.

So a review has four questions to answer:

• Is the record still true? The purpose, the users, the data the tool can reach and the date of the next review.
• Are the outputs still good? Sample real ones. The ownership article says quality drifts when nobody samples outputs, and that staff then trust a tool because it usually works.
• Who can reach what? The article says access widens: permissions granted for a pilot stay in place, a tool connected to one folder gets connected to three, and a leaver’s account and connections outlive them.
• Do the rules still match how people use it? The article says a rule written at launch does not mention new features, new tools or new teams, and nobody is responsible for reading it against reality.

The owner’s fourth job, knowing who to tell and in what order, adds one more check: if an incident happened, did that route work? The drift page covers what happens to a tool nobody is checking.

What should trigger a Review Early?

A date is a floor, not a ceiling. The ownership article says to put a quarterly review in the calendar for each tool, and a second trigger whenever the vendor announces a change. The AI tool inventory page describes the change as one to the model, the features or the terms.

Other pages add triggers of their own:

• An incident or a new tool. The policy article says to review the policy after either.
• A change of plan, default or term. The connector article says plans, defaults and terms change, and gives an example of how far: the provider renamed connectors to apps, and later moved its directory to a plugin directory, so the menu you see may not match the article you read last quarter. The principle stays the same.
• A change in how people use the tool. The policy article asks the team what people actually use now, which is a way of noticing uses nobody planned.

The practical point is that the vendor’s calendar is not yours. A quarterly date catches slow change. The vendor trigger covers the rest, and it is one a business can miss: the ownership article says the vendor sometimes updates the model without an announcement that reaches the people using the tool.

What goes on the one-page record?

The record is short on purpose. The ownership article says it holds the purpose, the users, the data the tool can reach and the date of its next review, and that it should be short enough to be read. It is written in the third week of the article’s thirty-day route to naming owners.

The date is the last line, and it is what ties the record to a check: it says when the description will next be tested against the facts.

The AI tool inventory page describes the list the records sit against, with a review date on each row. That page makes the matching point that a list written once goes stale, and that the review date on each row is the answer.

What are the four verdicts at a Review?

The time-saving article gives the clearest picture of what a review is for. After the 30-day re-check, it says to make the call at a fixed review point, with one of four verdicts:

• Keep. The whole cycle is shorter at the same quality. Carry on, and assign the released hours to the use you named in advance.
• Scale. The saving is clear and the task is common elsewhere in the business. Extend the tool, and measure the first new task the same way.
• Switch. The tool shows promise but one part of the cycle, usually checking or re-prompting, is eating the gain. Try a different tool, tighter instructions or a narrower job.
• Drop. The whole cycle is no shorter, or quality has fallen. The article calls this a good result and not a failure, because a few weeks were spent to avoid paying indefinitely for a tool that does not earn it.

The article adds a check for the next review: whether the released hours went where you said. Without that, even a real saving never turns into business outcomes anyone can point to. A review date is where that question gets asked.

Who runs the Review?

The tool’s named owner. The ownership article defines an owner narrowly: one named person who can answer what the tool is used for, who can use it, what data it can reach, and when it was last checked. They do not have to do the technical work. They have to be the person the question goes to, and the article says they need the authority to pause the tool. The AI ownership page covers the role in full.

For a policy, the policy article names the same job. The owner keeps the approved tool list current, answers questions, receives incident reports and runs the review.

One caution comes from the time-saving article. Have someone other than the tool’s champion look at the results, because the person who proposed the tool is the person most hoping it works. The internal champion page covers why the two roles differ: a champion’s job ends with the project, and the owner’s has no end date.

Does a Rule need a Review date too?

Yes. The banning article applies the idea to the rule itself. A rule filed once goes stale within months, because new tools and new features keep arriving. Its advice is to name a person who owns the page, put a review date in the calendar and rerun the team conversations on that date. It also says to keep a short record of which tools and uses were approved and when, so you can show a client or regulator how the rule was decided.

The same point appears elsewhere. The risk classification page says a classification made once goes stale as new tools and new features arrive, so it needs a review date and an owner. The fine-tuning page says a tuned model is frozen until retrained, so it needs an owner and a review date like any other tool. The ban on AI tools page lists an owner and a review date among the things that stop a rule going stale.

The pattern is the same each time. Anything the business decided once, about a tool, a rule or a classification, is a decision about a moving target, and a date is how the decision is kept current.

What happens without one?

The drift the ownership article describes. Quality slips because nobody is sampling outputs. Access widens because permissions granted for a pilot stay in place. The written policy goes stale because nobody reads it against reality. And incidents have no route, so the conversation about what to do starts from nothing, under pressure.

The AI ownership page has a worked example, marked there as an illustration and not a real client, that shows the other side. A business names owners for four tools and puts review dates in the calendar. A month later, one record shows the vendor changed the meeting tool’s settings, and the owner catches it on the review date. Nothing dramatic happened, which is the point. The date turned a change that would have gone unseen into a note on a record.

The AI governance page describes the scale of this. At small and mid-sized scale, it says, governance does not need a compliance department. It needs an owner, a short written policy and a review point built into how work already gets done.

How is it Different from an AI Audit or a legal deadline?

A review date and an audit work together. The ownership article says an audit lists every tool in use, checks what each one handles and gives each one an owner and a review date. The audit sets the dates up. The reviews that follow are how they are kept.

A review date is also not a legal deadline. It is a date the business sets for itself. A date the law sets is a different thing, and the high-risk deadline page covers it on its own. The two can sit side by side, but one does not replace the other.

What to do first

Take the list of tools in use and put a date against each one before you finish the record. If you have no list yet, the AI tool inventory page covers the first step. For tools in daily use, the ownership article’s quarterly default is a sensible starting point, and the vendor-change trigger should go in beside it.

Then name who runs each review, and put the date in a calendar that person actually reads. For the written policy, set the six-month review before you finish writing it, as the policy article advises.

On the day, run the four questions: is the record true, are the outputs good, who can reach what, and do the rules match the use. End with a verdict and the next date. The full route is in what happens when nobody owns the AI you have rolled out, and the verdicts are in is your AI tool actually saving time.