nyami.fr

/ en / work / trustworthy-rag-patterns

A RAG demo is 20 lines. A trustworthy AI system is 20 decisions.

An interactive pattern map for governed GenAI systems

→ Key learning: Turns a list of AI tools into an inspectable architecture with explicit controls, evaluation gates and operating boundaries.

Context
Independent knowledge note
Contribution
Author & reference architect
Period
2026
Status
published

The provocative version

A RAG demo is usually a neat chain: chunk → embed → retrieve → generate. It can fit in a notebook and look convincing after one afternoon.

A trustworthy AI system is different. The difficult work is not calling the model. It is deciding what the model may see, which tools it may use, how claims are tested, and what happens when quality, latency or cost drifts.

This note is an independent architecture pattern. It does not describe an employer, client, internal platform or production deployment.

The five control planes

Reference map showing five control planes around a grounded AI system

The architecture becomes easier to reason about when the twenty decisions are grouped into five control planes.

1. Purpose and data boundary

  1. Purpose — what decision or task is the system allowed to support?
  2. Data classification — which sources are public, internal, confidential or prohibited?
  3. Identity — who is asking, and how strong must authentication be?
  4. Authorization — which documents may this identity retrieve before any model call?

2. Retrieval and evidence

  1. Ingestion contract — who owns freshness, deletion and source quality?
  2. Chunking strategy — which semantic units preserve meaning and access metadata?
  3. Retrieval policy — lexical, vector or hybrid; filters before ranking, never after.
  4. Evidence contract — every important claim must point to an inspectable source.

3. Agents and tools

  1. Workflow boundary — use deterministic code when the path is known; use an agent only when a choice is genuinely needed.
  2. Tool contract — MCP can expose typed capabilities, but each tool still needs narrow inputs, outputs and permissions.
  3. Approval boundary — consequential actions require deterministic validation or a human checkpoint.
  4. Failure semantics — timeouts, partial results and retries must be visible rather than silently improvised by the model.

4. Evaluation and release

  1. Task-specific eval set — representative questions, difficult negatives and policy-sensitive cases.
  2. Groundedness gate — evidence quality is measured separately from writing quality.
  3. Adversarial tests — prompt injection, data exfiltration and tool misuse are release criteria.
  4. Regression policy — a model, prompt or index change ships only when it stays inside defined thresholds.

5. Operations and accountability

  1. Observability — trace retrieval, tool calls, model output, latency and cost without logging secrets.
  2. Budget and latency SLOs — caps are checked before spend, with graceful degradation when limits are reached.
  3. Rollout and rollback — version prompts, indexes and policies; canary changes and keep a fast reversal path.
  4. Human accountability — define ownership, escalation, retention and incident response before launch.

Where the named technologies fit

The technology names are useful only when attached to a responsibility:

  • RAG grounds answers in controlled evidence.
  • Agentic AI handles bounded choices and decomposes uncertain tasks.
  • MCP provides typed tool access; it does not provide authorization by itself.
  • LangChain and CrewAI are orchestration options, not the architecture.
  • Kubernetes can provide workload isolation, rollout and operational controls when that complexity is justified.
  • MLOps / LLMOps owns evaluation, versioning, monitoring, incident response and rollback.
  • Dataiku DSS can be understood as one governed data-science platform option within the wider control environment.

Three anti-patterns

“We added citations.” Citations do not help if retrieval ignored document permissions.

“The agent has an MCP server.” A protocol is not a security model; tool permissions and approval boundaries still matter.

“The answer looked good in the demo.” A good demo answer is an anecdote. A release gate needs a dataset, thresholds and regression history.

The practical takeaway

Do not start by asking which framework to use. Start by making the twenty decisions explicit. Then choose the smallest stack that can enforce them and produce evidence that the controls actually work.

The Pattern Lab in Ask Nyami turns this note into an interactive map: select a control plane, inspect its four decisions, and challenge the trade-offs.

Disclosure

This article shares general technical knowledge for educational and community use. It contains no employer or client identity, internal system name, proprietary implementation detail or confidential metric. It is not a claim that the reference architecture is deployed by any company.

🚧 V-next — already in the works

This system ships continuously — the next stages are already on the bench. Come back to check the status, or ask the agent where it stands.

  • This is a reference pattern, not a claim about a company deployment.
  • Controls must be adapted to the data classification, jurisdiction and risk appetite of each context.
  • Framework names are implementation options, not substitutes for architecture decisions.
Follow the progress live →