Getting an AI app to production-ready is mostly not a modelling problem. It is an evaluation, security and cost-control problem. A demo that impresses a room becomes a product when you can prove it does not regress, cannot be talked into doing something harmful, and does not quietly cost more per user than you charge. These are the ten steps that separate the two.<\/p>\n
This is the checklist we work through before we let an AI feature carry real customer traffic.<\/p>\n
Because a prototype is judged on its best output and a product is judged on its worst. MIT’s widely reported State of AI in Business research<\/a> found roughly 95% of generative AI pilots delivered no measurable impact on the P&L \u2014 and the differentiator it identified was not model quality but integration into real workflows.<\/p>\n The gap is operational. Prototypes have no evaluation harness, no adversarial testing, no cost ceiling and no observability. Every one of those is cheap to add early and expensive to retrofit.<\/p>\n Before any metric, name the specific failure mode that would actually hurt: a wrong price quoted to a customer, a leaked document, a fabricated policy, a booking made that cannot be honoured. Everything downstream \u2014 your evals, your guardrails, your human-in-the-loop design \u2014 should be built to catch that one thing first. Teams that skip this step end up measuring fluency instead of correctness.<\/p>\n A golden dataset is a curated set of inputs with known-good expected behaviour, and it is the single highest-leverage artefact in an AI codebase. Practitioner guidance on building golden datasets<\/a> recommends starting with around 50 genuine failures, having a domain expert grade them as a binary pass or fail with written critiques, then calibrating an automated judge against those human verdicts.<\/p>\n Fifty real failures beats a thousand synthetic ones. Harvest them from your own logs, your support queue and adversarial testing \u2014 not from your imagination.<\/p>\n Honest cost benchmarks, the hidden costs vendors don’t quote, and a 10-line scoping worksheet.<\/p>\n Get the free guide<\/a><\/div>\n Every change to a prompt, a model version or a retrieval configuration should trigger an evaluation run against the golden set, and a regression past your threshold should block the merge. Guidance on agent observability<\/a> describes exactly this pattern: offline evaluation against curated golden cases before deployment, with pull requests that regress quality failing to merge.<\/p>\n This is the discipline that makes an AI system maintainable by people who did not build it.<\/p>\n Instrument so that every request produces a trace covering each model call, tool invocation and retrieval step. When a customer reports a bad answer three days later, you need to reconstruct exactly what the system saw and did. Without tracing, debugging an AI system is guesswork.<\/p>\n Offline evaluation catches regressions you anticipated. Online evaluation catches drift you did not. The common production pattern is to sample roughly 5-10% of real traffic, score it with an automated evaluator, and alert on movement \u2014 quality problems then surface as they happen rather than in a quarterly review.<\/p>\n Prompt injection sits at the top of the OWASP Top 10 for LLM Applications<\/a> as LLM01, covering both direct injection through user input and indirect injection through content the model ingests from external sources such as web pages or documents. The 2025 revision also added system prompt leakage and vector and embedding weaknesses<\/a> as distinct categories.<\/p>\n Neither retrieval-augmented generation nor fine-tuning solves this class of problem. The defence is architectural: least-privilege tooling, strict input and output filtering, human approval for any high-consequence action, and regular adversarial testing. If your agent can send money, delete records or email customers, the injection surface is a business risk, not a technical curiosity.<\/p>\n The moment your app reads a PDF a user uploaded, scrapes a page, or pulls a record another system wrote, that content is adversarial input reaching your model. Sanitise it, mark provenance, and never let retrieved text carry instruction authority. Our guide to RAG vs. fine-tuning<\/a> covers the retrieval design decisions this constrains.<\/p>\n Token spend scales with usage in ways that traditional software does not. Set per-request, per-user and per-tenant budget caps in code, not in a spreadsheet. Log cost per request alongside latency. Then check the unit economics against your pricing before launch \u2014 an AI feature that costs more per active user than the plan it sits inside is a scaling liability, not a growth driver.<\/p>\n Choosing the right model for each path is most of the cost lever. Our guide on how to choose an AI model for your app<\/a> works through routing cheaper models to easy paths and reserving flagship models for the hard ones.<\/p>\n Model providers have outages, rate limits and deprecations. Decide in advance what happens when the primary model is unavailable: fail over to a secondary provider, fall back to a deterministic path, or fail loudly and gracefully. Abstract the provider behind your own interface so a model swap is a configuration change rather than a rewrite. Then rehearse it.<\/p>\n For any action that is expensive to reverse \u2014 money moving, contracts, irreversible deletions, external communication \u2014 put a human in the loop by design, not as a temporary measure. Then instrument the approval rate. When humans approve 99% of a given action for three months, you have earned the data to automate it. That is a far better basis for removing the human than a confident demo. Our guide to deploying agentic AI<\/a> goes deeper on where those boundaries should sit.<\/p>\n It means you can detect a quality regression before customers do, you know what the system did on any given request, an adversarial user cannot make it take a harmful action, cost per request is bounded and measured, and there is a defined behaviour when the model provider fails.<\/p>\n Start small and real rather than large and synthetic. Practitioner guidance suggests beginning with around 50 genuine failure cases graded by a domain expert as pass or fail with written critiques, then growing the set as new failure modes appear in production.<\/p>\n No. OWASP’s guidance treats it as a risk to be mitigated through defence in depth rather than eliminated \u2014 least-privilege tooling, input and output filtering, human approval for high-risk actions, and ongoing adversarial testing. The practical goal is to limit what a successful injection can reach.<\/p>\n A commonly used starting point is sampling roughly 5-10% of live requests for automated scoring, tuned up for high-risk paths and down for high-volume, low-consequence ones. The purpose is drift detection, so consistency of sampling matters more than volume.<\/p>\n Usually not at first. The golden dataset and the judge criteria are the parts that are specific to your product and worth your effort; the harness, tracing and dashboards are commodity. Buy or adopt the plumbing, own the test cases.<\/p>\n Whenever the action is expensive or impossible to reverse, carries regulatory consequence, or affects a customer relationship directly. Track the approval rate over time \u2014 a stable, very high approval rate on a low-consequence action is the evidence you need to automate it.<\/p>\nStep 1: Write down the failure that costs you the most<\/h2>\n
Step 2: Build a golden dataset from real failures<\/h2>\n
Free: The Australian AI MVP Cost Guide 2026<\/h4>\n
Step 3: Gate deployments on evaluation, not on vibes<\/h2>\n
Step 4: Trace every request in production<\/h2>\n
Step 5: Score a sample of live traffic continuously<\/h2>\n
Step 6: Treat prompt injection as your primary security risk<\/h2>\n
Step 7: Assume every retrieved document is untrusted input<\/h2>\n
Step 8: Put a cost ceiling on every path<\/h2>\n
Step 9: Design the degraded state before you need it<\/h2>\n
Step 10: Decide where the human sits<\/h2>\n
Frequently asked questions<\/h2>\n
What does production-ready actually mean for an AI application?<\/h3>\n
How big does a golden dataset need to be?<\/h3>\n
Can prompt injection be fully prevented?<\/h3>\n
How much of production traffic should be evaluated automatically?<\/h3>\n
Should you build your own evaluation tooling?<\/h3>\n
When should a human stay in the loop permanently?<\/h3>\n