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.

Each layer has an owner, an artefact and a failure condition. Together, they connect the incoming request, the prepared output and the decisions the application actually permits.

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. Request, context, rules and validation remain connected, with distinct responsibilities.

“Answer carefully” is not testable. “Every amount must exactly match an application-approved price and cite its allowed source” is. Without an approved price, the amount remains null. The model may prepare clarification when scope is missing; the commercial decision stays with a human.

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

decision proposes; status reports the control result. All eight fields are required. A proposed refusal may await review; malformed output is rejected.

The application supplies permissions, the approved price and the original message. Its content remains untrusted. The schema accepts send to test rejection; no sending is authorized.

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.

Each test targets its component. EVAL-001 to EVAL-008 describe model behaviour; EVAL-009 and EVAL-010 require integration evidence; EVAL-011 checks malformed output; EVAL-012 compares versions. expected.output is a partial expectation, never a complete candidate for the validator. Missing human grades and untested tools remain unassessed.

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.

22 of 22 controls produce the expected result, including rejections. This checks control behaviour on synthetic outputs, without a model call.

Hostile input can redirect model behaviour: OWASP LLM01 describes the risk without claiming fool-proof prevention. OWASP LLM06 addresses excessive functions, permissions and autonomy: enforce authorization in the service performing the action and require human approval for high-impact actions.

The ANSSI guide covers architecture security across its lifecycle, not model business performance. The CNIL warns against excessive trust without verification. Also define purpose, data minimisation, permissions, retention and incident handling.

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.

To count a claim as supported, a reviewer compares its meaning against a relevant excerpt from an allowed source and records the verdict. Unverified claims do not enter the numerator. Citation coverage is a different measure. A zero denominator makes a rate undefined.

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.

The protocol and evaluation sets use the Creative Commons Attribution 4.0 licence. Adapt, cite and redistribute them with attribution to Edikka and a link to this article.

Kit code is MIT-licensed; prompts, schemas, rules and scenarios use CC BY 4.0. The twelve evaluation scenarios and twenty-two control outputs are two distinct sets. No API key is required.

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.