Production Ready AI Playbook

A production AI system is mostly not AI. The architecture checklist: data governance, POPIA, GDPR, guardrails, and LLM observability.

Anyone can call a model. You send some text, you get some text back, you ship a demo, and everyone claps. The gap between that demo and a production-ready AI system you’d actually put in front of customers is where most of the real engineering lives, and almost none of it is about prompting.

This is the thought process to run through before calling an LLM-powered system production-ready.

1. Choose models that are fit for purpose

Pick models that are fit for purpose, not fit for your ego. Bigger, newer models earn their cost on genuinely hard reasoning. The bulk of real workloads, classification, extraction, routing, short transformations, run perfectly well on something smaller and an order of magnitude cheaper. Most production systems should be a mix of models, and the routing logic between them is part of the architecture, not an afterthought.

Then stop thinking about models. The model is one component. Everything below matters more.

2. Understand your token economics before launch

You should be able to estimate your expected token consumption rate before you go live, and you should have rate limiting configured with your provider that matches it. “We’ll see how it goes” is not a capacity plan; it’s an outage with a delay timer on it.

Two related concerns sit alongside this:

• Context overflow handling. If your system can plausibly ingest more tokens than your model accepts in a single pass, you need a defined strategy, chunking, summarisation, or retrieval*, before* a user pastes a novel into your input box.
• Token abuse protection. Without per-client limits, one bad actor or one buggy loop can run up a catastrophic bill on your account. Treat token spend like any other metered resource: cap it, attribute it, and alert on it.

3. Treat data governance as a design input, not a compliance checkbox

Data governance is one of the most underestimated parts of AI system design, and it is foundational rather than something you bolt on later. Every territory you operate in is a hard constraint on your architecture.

If you serve users in South Africa, you are subject to POPIA — the Protection of Personal Information Act, which governs how personal information is processed and carries penalties of up to R10 million or up to 10 years imprisonment for serious violations. If you touch EU residents’ data, the General Data Protection Regulation (GDPR) applies regardless of where your company is based, and POPIA was closely modelled on GDPR — so the two share core principles like lawful processing, data minimisation, and breach notification. Other African regimes, including Kenya’s Data Protection Act and Nigeria’s NDPR, follow the same pattern.

For an AI system specifically, this translates into concrete architectural decisions:

• Heavy obfuscation of identifiable information by default. Personally identifiable information should be stripped or masked before it ever reaches a third-party model endpoint. Under POPIA, even identifiers like IP addresses and cookie IDs can constitute personal information, so the bar for what counts as “sensitive” is low.
• Data residency where the law demands it. POPIA restricts transfers of personal information outside South Africa, and GDPR governs transfers outside the EU/EEA. In stricter cases. This means infrastructure that keeps data physically inside the network from which it originated. You cannot retrofit that; it changes where compute lives, which is a foundational decision.

The official legal texts are worth bookmarking: POPIA and the GDPR full text. Treat them as architecture inputs, not legal-team homework.

4. Guardrails are where your business risk concentrates

This is the big one. System prompts and tool definitions are not guardrails, they are suggestions the model is free to ignore under the right pressure. Real protection is explicit input validation and output sanitisation wrapped around the model. This is the layer that stops the LLM from responding in a way that creates legal, financial, or reputational risk for your product. If you under-invest anywhere on this list, do not let it be here.

5. Verify responses with structured testing

If you can’t test it, you can’t trust it. You need response verification across a spectrum of inputs: the expected, the weird, and the actively hostile. Tools like Promptfoo are built for exactly this; if your system is deterministic enough, traditional automated tests apply too. Behaviour you haven’t tested against adversarial input is behaviour you’re discovering in production.

6. Design for the model being unavailable

LLMs are not 100% available, and many are subject to surge throttling even on paid tiers. Fallbacks, retries, and redundancy are not nice-to-haves; they are the difference between a degraded experience and a dead one. Design for your provider to have a bad day, because they undoubtedly will.

7. Build observability in from day one

You can’t operate what you can’t see. LLM observability means tracking inputs, outputs, token counts, and failure cases as first-class signals. This is simultaneously your cost dashboard and your behavioural monitor. It’s how you notice the system drifting, getting expensive, or quietly failing a class of requests before a customer tells you.

8. Put a hard boundary between the model and anything it can break

We all want to give AI more leverage. But free rein over your systems, data, and processes does not scale in the model’s current state. Define narrow, explicit interfaces and let the model act only through them. That boundary is what neutralises whole categories of failure, prompt injection, unintended deletions, scope creep, by construction rather than by hope.

9. Make model swaps boring

Models change, update, and get deprecated at a brutal pace. Your system needs a low-friction path to switch models that’s gated by your validation suite (see section 5). The goal: swapping a model is a routine, confidence-backed operation, not a multi-week migration where you find out post-deploy that behaviour shifted underneath you.

The takeaway

A production AI system is mostly not AI. It’s capacity planning, data governance, guardrails, testing, redundancy, observability, and clean boundaries with a model plugged into the middle. The teams that internalise this ship things that survive contact with real users and real regulators. The ones that don’t ship demos.

---

Further reading: POPIA official text · GDPR official text · South Africa’s Information Regulator & penalties · Promptfoo