7 controls your LLM demo needs before production

Yan — Fri, 06 Nov 2026 16:18:51 +0000

A demo proves the model can answer. It does not prove the system can be trusted with real users. The gap is not a better model. It is seven controls around the model, and a bare demo has none of them.

A working demo answers the wrong question

A demo answers one question: can the model produce a good response? For an internal chatbot built from a gateway, a model, and a response formatter, the answer is usually yes. That is why demos feel close to done.

Production asks different questions. Who is allowed to call this? How much can one caller use? What happens when the input is hostile or the output is wrong? When something breaks, can anyone see why? None of those are model questions. They are architecture questions, and the minimal path has no answer to any of them.

Here are the seven controls that answer them, in the order a request meets them. Each one comes with a test you can run against your own system today.

1. Auth: who is allowed to call the model?

Without auth, anyone who finds the endpoint can use your model, see whatever it can reach, and spend your budget. Internal tools are not exempt. "Internal" often just means nobody checked who can reach it.

The test: can you name every caller allowed to use the model, and does the system reject everyone else before the model runs?

2. Rate limiting: how much can one caller use?

Model calls are slow and expensive. One script stuck in a loop, one runaway agent, or one eager power user can starve everyone else and run up the bill. Without a rate limiter, your capacity plan is whatever your busiest caller decides it is.

The test: what happens when one caller sends a thousand requests in a minute? If the honest answer is "we would find out from the invoice", you need a limit.

3. Input guardrail: what reaches the model?

Every request is untrusted input. Some of it will try to override your instructions, pull out data, or push the model somewhere it should not go. A system prompt that says "ignore malicious requests" is a hope, not a control. An input guardrail inspects the request before the model sees it.

This is the gap LLM Architect marks as critical on a bare demo, because without it the system has no defense against prompt injection at all.

The test: if a user types "ignore your previous instructions", which component sees that before the model does?

4. Output guardrail: what leaves the system?

Clean input does not guarantee a safe answer. Models can leak personal data, invent a policy, or give advice your company would never give, and all of it looks like a normal response until someone reads it. An output guardrail checks the response before it reaches the user.

The test: what stops a bad answer after generation and before display? If nothing does, your users are your output filter.

5. Tracing: can you see what happened?

LLM systems are probabilistic. The same question can produce different answers, and failures rarely repeat on demand. Without traces, a user complaint turns into guesswork. You do not know what the request was, what context the model received, or which step went wrong.

A trace collector records the path each request took. Pair it with metrics for latency, errors, and cost, and debugging becomes reading instead of guessing.

The test: pick an answer a user complained about yesterday. Can you see the exact input, context, and output that produced it?

6. Evaluation: how do you know it is still good?

Prompts change. Models get upgraded. Documents get added. Any of those can quietly make answers worse, and without evaluation you find out from users. An eval engine scores outputs for factuality, groundedness, and safety, so a regression shows up as a number before it shows up as a complaint.

The test: if you changed the prompt today, how would you know whether the answers got better or worse?

7. Fairness checks: is it worse for some users?

Average quality can look fine while one group of users gets worse answers every day. Different languages, regions, or customer types can hit the model differently, and nobody notices because the overall score did not move. A fairness evaluator compares results across groups so those gaps become visible.

The test: do you measure answer quality by user group, or only on average?

Run the checklist on a real architecture

This list is not theory. It is exactly what LLM Architect reports when it evaluates the minimal internal chatbot path: API gateway, LLM worker, response formatter. The demo works. It scores 47 out of 100 and is missing seven controls.

That is the point. Most of what makes an AI system ready for production is not the model. It is the controls around it.

Challenge 1 is public and needs no signup. Run the evaluation, see the missing controls, and inspect what each one protects.

Try the public Challenge 1.

Originally published on LLM Architect.

DEV Community: Yan