Write down what the AI feature is not allowed to do before it ships

The launch review for an internal assistant runs long, and every minute of it is about how good the answers are. Somebody has a sheet of sample questions with a tick or a cross beside each one, and the argument is about where the acceptable line sits and whether the failures are the embarrassing kind or the forgivable kind. It is a reasonable argument. It is also the wrong one to spend the whole meeting on, because there is a second question that nobody in the room can answer: what is this thing not allowed to do, and how would we know if it did it.

That second question is the one that comes back. It comes back as a support agent letting the assistant issue a credit because the workflow offered a button and the model filled it in. It comes back as a customer's details surfacing in a summary generated for a different account, because the retrieval step was scoped by relevance and not by permission. It comes back as a security reviewer asking, six weeks after go-live, which controls exist and what evidence there is that they were ever tested. At that point the accuracy sheet is not much help.

The fix is unglamorous and mostly clerical. Before the feature ships, write down the things it is not permitted to do, in language specific enough that a test can fail. One page. Short enough that the people who sign it off will actually read it.

Quality is a spectrum, refusal is a boundary

Quality arguments do not end, because quality has no natural edge. There is no point at which an answer becomes correct in the way a build becomes green. You can measure it, and you should, but every threshold you pick is a negotiated opinion, and the negotiation reopens every time somebody senior reads a bad output.

Refusal behaves differently. Either the assistant produced a figure for an account the user cannot see, or it did not. Either it placed the order without a human confirming, or it did not. Either it repeated the full card number back into the chat transcript, or it did not. These are binary, they are observable from outside the model, and they do not require anyone to agree about tone or helpfulness. That is what makes them the part of an AI feature you can genuinely sign off, rather than the part you approve while hoping.

Quality has no natural edge to test against. Refusal does, which is why refusal is the part you can actually sign off.

The pattern, stated plainly

The three lists worth writing

In practice the useful document splits into three, and each one has a different owner. Keeping them separate matters, because a single list of good intentions tends to get written by whoever is least busy and reviewed by nobody.

• Questions it must decline The territory where a plausible answer is worse than no answer. Diagnosis and dosage for a clinical tool. Anything that reads as personalised financial or legal advice. Eligibility decisions in a public service context, where a confident wrong answer becomes a decision a citizen relies on. The test is not whether the model knows, it is whether the organisation is prepared to stand behind the sentence.
• Actions it must never take without a person Payments, refunds, credit limits, cancellations, deletions, anything that sends an external message under your name, anything that writes to a system of record. Write this as a list of tool calls and API endpoints, not as a category of intent. The moment an agent has the tool in its schema, it will eventually call it.
• Data it must never repeat back Identifiers, health details, salary figures, anything covered by a residency commitment, anything belonging to a different tenant. This one has to be tested at the retrieval layer as well as the output layer, because a model that never says the wrong thing while still reading the wrong rows into its context has already failed.

The fastest way to fill these in is to ask the people who would be blamed. The compliance lead, the head of support, the person who fields the regulator's email. They have the list already. It is usually in their head, phrased as a worry rather than a requirement, and it takes an afternoon to write down.

Write each line as a test, not as a principle

"The assistant must not give financial advice" is a principle. It cannot fail a build, it cannot be handed to an engineer, and two people will read it differently on the same morning. What you want instead is a small set of cases with an expected behaviour attached, so that the prohibition runs on every change and reports a number that someone is accountable for.

The list is what survives the model changing

This is the part that earns the effort. The model underneath your feature will change, whether you upgrade deliberately or a provider retires a version and moves you along. Your prompt will change. Your retrieval index will be rebuilt with different chunking, and someone will add a tool to the agent's schema on a Thursday because a customer asked for it.

Every one of those changes can quietly move the boundary, and none of them will show up in a quality score, because the quality score is measuring something else. A refusal suite is the only artefact in the stack that is written against the behaviour rather than the implementation, which means it keeps its meaning across all of those changes. It is also, not coincidentally, the thing that makes a model upgrade a normal engineering task instead of a leap of faith.

Where this is the wrong answer

Two honest limits. The first is that a refusal suite measures nothing about usefulness. A feature that declines everything scores perfectly, and over-refusal is a real harm rather than a safe default, particularly in healthcare and public service work, where the user who gets stonewalled has no other route to the answer. The boundary set has to be paired with a set that checks the feature still does its job, and the pairing is not optional.

The second is that plenty of AI features do not warrant any of this. If the thing drafts marketing copy, touches no customer records, and takes no action a person does not review before it leaves the building, then the whole apparatus is process for its own sake. The test for whether you need a written boundary is simple: can this feature reach data or take an action that would require an incident report if a junior employee did it by mistake. If not, ship it and spend the afternoon on something else.

When the answer is yes, the document you produce is also, conveniently, most of the pre-deployment assessment a reviewer will ask for. Assurance regimes differ in their vocabulary, but underneath they ask the same three things: what could go wrong here, what stops it, and what evidence do you have that the thing which stops it works. A one-page list of prohibitions, a test suite that runs on every change, and a record of the results answers all three in the order they were asked.

The reason to write it before launch is not the reviewer, though. It is that the list is genuinely hard to write, and writing it forces the argument about scope that everyone has been postponing. Teams routinely discover, in the hour it takes, that nobody had agreed whether the assistant was allowed to act on a customer's behalf at all. Better to find that out in a meeting than in a transcript.