Know Your Customers & Use Cases

Two questions, asked before launch

Both halves of this are about scope: who is allowed to use the thing, and what the thing is for. Neither is a model question, which is why they get skipped by teams treating safety as something the provider handles.

OpenAI lists both among its safety best practices, and the guidance is concrete enough to act on.

Make them sign in

An anonymous endpoint in front of a model is an abuse surface with no accountability. The recommendation is user registration and login, and the reason is leverage: a signed-in user can be warned, limited, or removed, and an anonymous one can only be blocked by IP.

Where the risk is higher, the documentation suggests raising the cost of getting an account. Linking to an existing account such as Gmail, LinkedIn or Facebook borrows an identity someone already invested in. Requiring "a credit card or ID card" raises it further.

Pick the level against what abuse would cost you, not against what is easiest to build. A free anonymous text generator and an internal tool behind SSO need different answers, and the middle case (a free tier that anyone can create in bulk) is where most incidents come from.

Authentication also gives you the stable per-user string that adding end-user IDs needs, so these two controls install together.

Decide what the feature is for, in writing

The second half is narrower than it sounds and more often skipped. The advice is to evaluate "whether the model is fit for your purpose" and to test across "a wide range of potential inputs" to find where performance falls off.

That means writing down the use case, including its edges. A support assistant that answers questions about your product is a scope. The same assistant when someone asks it for medical advice is out of scope, and what it does then is a decision you make now or discover later.

Three things to write down:

What it is for. The tasks you intend and will support.

What it refuses. The categories you will decline even though the model could answer. Legal, medical and financial advice are the usual three, and yours may include anything a wrong answer makes expensive.

Who it is for. Age, jurisdiction, internal against external. This decides which obligations apply before it decides anything technical.

Fitness is measured, not assumed

"Fit for your purpose" is a claim, and a claim needs evidence.

The evidence is an evaluation set drawn from your real inputs, which LLM evaluations argues for building before the feature. Test the range deliberately: long inputs, short inputs, inputs in other languages, inputs about neighbouring topics, and inputs from the edges of your user base rather than the middle.

What you are looking for is the boundary where quality falls off, because that boundary is your scope whether or not you wrote it down. Finding it in testing means you get to decide what happens there.

Enforce the scope somewhere it holds

A scope that exists only in a prompt is a suggestion.

Constraining inputs and outputs makes the general case, and the specific version here is that out-of-scope requests need a check that is not the model's own judgement. A classifier on the way in, a validated set of topics, or a moderation pass, depending on what you are excluding. Content moderation APIs covers the classifier option and what it is not for.

Then test that the enforcement holds against someone trying to get around it, which is what conducting adversarial testing is for.

Further reading

• OpenAI, Safety best practices: registration, identity linking, and testing fitness for purpose.
• Adding end-user IDs: the attribution that authentication makes possible.
• LLM evaluations: the evidence behind a fitness claim.
• Conducting adversarial testing: checking the scope holds under pressure.