What an AI feature needs besides a model

The model is the decision that matters least

Most conversations about building an AI feature start with which model to use, and that is close to the least consequential choice available. Models are largely interchangeable for ordinary tasks, they are swapped with a configuration change on a well built system, and whichever one is best today will not be in a year. Designing around a specific model is designing around the part guaranteed to change.

The parts that decide whether a feature works are the same parts that decide whether any other software works, and they are unglamorous. What it can reach. What it does when it is wrong. What it costs when the traffic is real. Whether anyone would notice it degrading. None of those are model questions, and all four are where this work goes wrong.

A demo proves the model can do the task once, on an input somebody chose, with a person watching. Nothing about that predicts behaviour on the hundredth real input from somebody who does not know what it expects. The gap between those two situations is the entire engineering problem.

What it can reach, which is the real design decision

An AI feature is only interesting when it can see your data, and that is exactly when it becomes a question about access rather than about intelligence. The moment a model can read records, the question is not what it knows. It is whose records it can read, and on whose authority.

The failure to avoid is a feature that queries with the application's own permissions instead of the user's. It works perfectly in testing, because whoever is testing is usually allowed to see everything. It fails the first time somebody asks a question slightly outside their remit and gets a correct, well written answer drawn from data they should never have seen.

• Decide whose permissions a request runs under before writing any of it, and make that the identity the data layer actually enforces rather than a filter applied afterwards.
• Assume anything the model can reach can end up in its output. Retrieval that pulls a whole record to answer a question about one field has widened the blast radius for no benefit.
• Treat text arriving from a user, a document or a web page as untrusted input, because a model reading it will follow instructions it finds there. This is prompt injection, and it leads the OWASP list for large language model applications.
• Log what was retrieved, not only what was answered. When somebody asks why the system said something, the retrieval is the part you need and the part nobody keeps.

Our own write-up of how authentication, sessions and access rules fit together is the same argument in a different setting, including two defects of our own where the layers did not line up. An AI feature does not need a new security model. It needs the one you should already have, applied at the point of retrieval.

What happens when it is confidently wrong

Models produce fluent text whether or not they have grounds for it. That is not a defect awaiting a later version, it is how they work, and a feature built on the assumption that output will be correct rests on an assumption that will not hold. The useful question is not how to stop it being wrong. It is what a wrong answer costs.

Being able to say nothing is an underrated feature. A system that answers every question will answer the ones it has no basis for, and a confident wrong answer costs far more than a visible gap. Design the decline path deliberately and test it, because it will not appear on its own.

What it costs when the traffic is not the demo

AI features carry a per-use cost, which most software does not. That changes the shape of the problem rather than only its size: usage that would be a minor traffic spike on an ordinary page is a directly billable event here, and whoever generates it is not necessarily a customer.

• Anything reachable without a login is reachable by everybody, including automated traffic, and each request costs you money. Rate limiting on an AI endpoint is a cost control before it is a security control.
• Rate limit on something the caller cannot choose. We published a finding of our own where a limiter keyed on a header a client could set was defeatable by setting it, which is the kind of mistake that reads as correct in review.
• Cache the repeated work. A surprising share of real questions are the same question, and the cheapest request is the one you never make.
• Put a ceiling on spend that is enforced somewhere other than good intentions, and alert on the trend rather than only on the limit.
• Long inputs cost more than short ones. A feature that passes an entire document on every request pays for the whole document every time.

There are no prices on this page on purpose. Model pricing changes several times a year, and a number written today is misinformation by the time somebody plans against it. Get current pricing from the provider on the day you need it, and treat any figure in an article, including ours, as out of date until you check.

How anyone would know it still works

This is the part that is almost always missing. Ordinary software fails loudly: something throws, a page breaks, a test goes red. An AI feature degrades quietly. It keeps returning fluent, plausible, well formatted answers that are worse than they were last month, and nothing in the system objects.

The change can come from anywhere. The provider updates the model. Somebody edits a prompt. The underlying data drifts. A retrieval step starts returning slightly the wrong documents. In each case the output still looks exactly like working output, which is why the absence of an evaluation set is the most common gap in this work.

1. Write down twenty to fifty real inputs with the answer you would accept for each. Real ones, drawn from actual use, not invented examples that flatter the system.
2. Run them whenever anything changes: the model, the prompt, the retrieval, the data.
3. Score whatever you can mechanically and read the rest. Partial automation beats the fully manual review that stops happening after three weeks.
4. Keep the failures. They are the regression suite, and the ones that came from real users are worth more than anything you would think to write.
5. Log real usage and read it periodically. The inputs people actually send differ from the ones you designed for, and that gap is where the next set of cases comes from.

This is the same discipline as any other test suite, applied to a system whose outputs are not exactly reproducible. That makes it harder and it does not make it optional. Without it, nobody can tell the difference between a feature that works and one that used to.

The questions worth asking before any of it is built

Short list, in the order that saves the most work. Most of them have nothing to do with AI, which is the point of the page.

1. What decision or task does this actually change? A feature that impresses and changes nothing is a demo with a maintenance cost.
2. Whose data does it read, and under whose permissions does that read happen?
3. What does a wrong answer cost, and who finds out?
4. Can it decline, and has anyone tested that path?
5. What stops one visitor generating unlimited billable requests?
6. How would we know next month that it got worse?
7. What happens when the provider deprecates the model, changes its pricing, or has an outage?

If the answers to two, three and six do not exist yet, the model choice is not the thing holding the project up.

What this does not cover

• There are no prices here, and no model comparison. Both date faster than this page can be revised, and a stale figure is worse than an absent one because somebody plans against it.
• It assumes you are building on a hosted model rather than training or running your own. Almost everything about cost, evaluation and failure changes if you are, and none of that is covered.
• It is not a security review. It names the shape of the access problem and points at the OWASP list; it does not tell you whether your system is safe, and no article can.
• Data protection obligations differ by jurisdiction and by what the data is. Whether you may send a particular record to a third-party provider at all is a legal question, and we are not lawyers.
• The evaluation advice is the practice we would apply rather than a measured result. We have not run a study comparing teams that keep an evaluation set against teams that do not, and we are not aware of one worth citing.
• Nothing here covers how to signal uncertainty to a reader in an interface, which is a real and unsolved design problem deserving its own treatment.

Sources

• whatscene.in authentication, access rules and rate limiting. The access and rate limiting arguments are the ones we run and have published, including two defects of our own that are fixed and covered by named regression tests: a storage rule that never fired because the platform classified an overwrite as a create, and a limiter keyed on a client-settable header. Run: /guides/authentication-sessions-and-access-rules and /research/a-rate-limiter-one-header-could-defeat, published 2026-08-24.
• OWASP Top 10 for Large Language Model Applications, OWASP. Retrieved 26 August 2026.
• AI Risk Management Framework, NIST. Retrieved 26 August 2026.

Revisions

• 26 August 2026 First published, as the anchor for the ai area, which had 63 pieces and no depth.

This page is revised in place rather than replaced, so its address does not change.