How to make AI reliable in production: prompts, business rules, tests and quality control

Reliable AI is not a model that answers a handful of curated demos correctly. It is a system whose useful behaviour is defined, tested on representative and edge cases, monitored after deployment and stopped when a critical rule fails.

This definition does not promise the absence of errors. It makes errors detectable, attributable and manageable. It also separates four properties that are too often merged: format compliance, factual correctness, business compliance and permission to act.

A prompt guides a probabilistic system. It does not replace server-side authorisation, schema validation, a critical calculation, an allowlist of sources or regression testing. Nor should every company rule be buried in one long instruction: duplication makes rules difficult to own, version, review and test.

Anthropic’s evaluation guidance places measurable success criteria before prompt optimisation. OpenAI likewise documents datasets, criteria and evaluation runs. The prompt is one component of the loop, not its final proof.

The original eight pillars for building reliable AI—frame, structure, test, monitor and control sources, formats, rules and uses—become an operational architecture. Each layer has an owner, an artefact and a failure condition.

What a reliable AI project must produce therefore goes beyond a system prompt: business rules, a test set, a monitoring table, thresholds and a recovery procedure are the minimum. The simple method links request, context, rules and validation without merging their responsibilities.

“Answer carefully” is not testable. “If no approved source supports a price, output no amount and route the request to a person” is testable. The latter can become a case before anyone sees the model response.

The assistant receives a lead request, extracts explicitly present facts and prepares a summary. It may ask one clarification question. It cannot promise a date, calculate a price or send a proposal. Sales management keeps the final decision.

A useful test links an input, expected behaviour, scoring method and blocking rule. A case does not pass because an answer “looks good”. The set must reflect real requests, edge cases and plausible abuse.

The twelve-case JSONL evaluation set provides a reusable starting point. It is not a universal benchmark: adapt it to the task and add real incidents.

Fields, vocabularies, permissions and critical conditions are better checked by code. An LLM judge can complement evaluation for relevance or tone, but its rubric should be calibrated against a human sample.

This validator does not judge tone or semantic fidelity to a source. It demonstrates the boundary: a critical decision can be rejected without asking the model whether it believes it followed the rule.

OWASP ranks prompt injection first in its 2025 Top 10 for LLM applications and notes that no fool-proof prevention method is known. Risk reduction combines constrained capabilities, instruction/data separation, validated outputs, least privilege, human confirmation and monitoring.

The French data protection authority advises users to submit only information they are authorised to share. Production systems must turn that principle into data minimisation, pre-send filtering, permissions, retention rules and an incident procedure.

A 94% average can hide a critical failure on every sensitive request. Blocking criteria therefore remain separate from improvement metrics.

The NIST AI RMF recommends documented test, evaluation, verification and validation processes followed by production monitoring, using conditions that resemble real deployment.

Behaviour can change with model, parameters, tools, sources, prompt or rules. OpenAI notes that outputs are variable and recommends pinned model versions with evals for consistency. The tested configuration must be identifiable rather than assuming one commercial model name always behaves the same.

Signs that AI lacks reliability rarely appear in the nominal demo. They appear as rules that cannot be isolated, inconsistent refusals, missing sources, excessive permissions and unexplained behaviour changes.

Both resources use the Creative Commons Attribution 4.0 licence. Adapt, cite and redistribute them with attribution to Edikka and a link to this article.

Edikka designs AI integrations and is not an independent certification body. This method describes controls we consider necessary to make a system more observable and governable. It does not replace context-specific risk analysis, a security audit or legal advice.

The public set contains twelve reference cases. It publishes no model comparison, gain figure or “zero hallucination” claim. Performance evidence requires a defined task, representative sample, thresholds chosen before observation and disclosure of tested versions.

• Anthropic · Define success criteria and build evaluations.
• OpenAI Developers · Working with evals.
• OpenAI Developers · Structured Outputs.
• OpenAI API · Backward compatibility and model versions.
• OWASP GenAI · LLM01:2025 Prompt Injection.
• NIST · AI RMF Core, Measure function.
• NIST · AI Risk Management Framework.
• CNIL · Generative-AI systems Q&A.

Moving from AI that answers to AI that follows a controlled framework does not come from a magic formula. Prompt, business rules, data, output formats, tests and responsibilities remain separate. The model keeps its interpretive ability; the system keeps the power to verify, reject, escalate and roll back.