How to Run a Pre-Deployment AI Safety Review for a Small Team

The week before launch is the worst time to ask whether a feature is safe to ship. The demo is polished, the deadline is close, and the person who raised a concern three weeks ago has gone quiet. A pre-deployment review exists to break that silence. It does not need a compliance department or a six-week audit. It needs a scope you can argue about, three to five honest reviewers, and enough time left to change the answer while changing it is still cheap.

Start With a Scope You Can Argue About

Before anyone opens a test harness, write one page. Not a specification — a short description that a busy colleague could read in four minutes and disagree with. Cover the basics:

• What the feature does, in plain language, without marketing adjectives.
• Who touches it, directly and indirectly. Include the people who never see the screen but feel the result.
• What data it reads, what it stores, and what it produces.
• What decisions or actions it influences, and whether anyone can override it.
• What it is explicitly not allowed to do.

Then add the question most teams skip: what does a bad day look like? Be concrete. "It gives a wrong answer" is not a failure mode; "it tells a customer their refund was approved when it wasn't, and nobody notices for a week" is. If you cannot describe the bad outcome in one sentence, you do not yet understand the risk.

Three columns worth filling in

Draw a table with three headings: Failure, Who notices, How bad. Fill it in as a group. The middle column is where teams get honest, because a failure nobody notices is usually worse than one that triggers an alert.

Pick Three to Five Reviewers, Including One Skeptic

The builder should be in the room but should not chair the meeting. The chair's job is to pull out dissent, not to defend the timeline. Beyond that, aim for one person who will use the feature daily, one person from a different discipline who can keep asking "why", and the person accountable for the release — the one who can actually say no.

Keep the group small and the session to 60 or 90 minutes. A dozen attendees turns a risk conversation into a presentation. And if everyone agrees within the first ten minutes, you have invited the wrong room.

List Failure Modes Before You Test Anything

Write the list first, because it decides what you test. Most teams find their real risks fall into a handful of recurring categories:

• Confidently wrong output. The system states something false with no hedging, and the user has no way to tell.
• Right answer, wrong context. Accurate information delivered to the wrong person, at the wrong moment, or without the caveat that made it safe.
• Data exposure. Internal documents, another user's content, or identifying details surfacing in an output.
• Over-reliance. People treating a suggestion as an authority, especially when they are rushed or new.
• Silent degradation. Quality drops after a data or configuration change and no alarm fires, because nothing technically broke.
• Boundary creep. A feature reviewed for one purpose gets quietly repurposed for another.
• Cost and rate blowups. Traffic spikes push the system into a degraded fallback nobody tested.

Score each one for likelihood and impact, then sort. You will not fix everything; you are choosing where to spend the next two days.

Test With Cases You Didn't Invent for the Demo

Demo inputs are chosen to work. Go find the inputs that were not. Pull real examples from support tickets, sales calls, operations notes, and the messages people send when they are frustrated. Build a fixed set of 30 to 50 cases, each with an expected behaviour written down in advance, and run the same set before every change. That set becomes your regression suite, and it is worth more than any one-off review.

Include at least a few hostile and awkward ones: attempts to make the system ignore its instructions, empty or malformed inputs, very long inputs, ambiguous requests with no correct answer, and anything in a language or format your team rarely checks. Record outputs verbatim. Impressions drift; transcripts don't. Keep a "known bad" file and add to it every time something slips through — an incident you can reproduce is an incident you can prevent twice.

Decide on Guardrails, Monitoring, and Stopping Power

Now translate what you learned into concrete controls. For any action that is hard to reverse, a person reviews before it happens. Define what the system should do when it is unsure or when a request falls outside its purpose — refusing cleanly beats guessing. If a request touches money, health, employment, or legal matters, this internal review is not a substitute for qualified professional advice; bring in the right expert before launch.

Roll out in stages: internal users, then a small share of real traffic, then wider. Write the numbers down beforehand — which metric matters, what value triggers a pause, and who makes that call. Give someone a way to switch the feature off at two in the morning without hunting for permission. And make sure your logs let you reconstruct a bad interaction from the input through to the output, because you will need that before you need anything else.

Write Down What You Decided

Keep one page per release. Scope, reviewers, what you tested, what you found, what you fixed, what you accepted, who signed off, and when you will look again. The "what you accepted" section matters most — it is the honest part, and it is what stops the same gap from being rediscovered in six months. Store it somewhere the next person will actually find.

The Ninety-Minute Version

When time is short, run this compressed sequence. It covers most of the value:

1. Read the one-page scope aloud. Argue until it is accurate.
2. List failure modes in the seven categories above. Circle the top three.
3. Run the existing regression set against the current build. Note anything new.
4. Decide the guardrails and the rollback trigger on the spot.
5. Write the one-page record and name the person who can stop the release.

Make the full review a habit for anything touching personal data, money, safety, or a decision someone cannot easily appeal. Use the short version for everything else. And schedule it two weeks out, not the day before — a review that cannot change the plan is just a meeting. Your advantage as a small team is speed. A short, structured review does not slow that down; it keeps the fast decision an informed one.

Photo: borevina / Pixabay