AI proposes, deterministic logic disposes: the pattern that keeps AI production-ready

Yann Gilliot — Fri, 02 Oct 2026 10:30:00 +0000

TL;DR

Three layers: AI proposes with a confidence score, deterministic business rules validate, a human settles what is left.
AI never writes to the database directly. A hallucination becomes a rejected proposal, not wrong data in production.
The useful question is not which model is used, it is what happens when that model gets it wrong.

AI in production does not decide. It proposes, to a system that has the right to say no. Every AI system I have put into production shares this same three-layer pattern.

The three layers of the pattern

AI proposes. OCR, a language model, extraction: it reads the document or the input data, detects, extracts, and attaches a confidence score to every proposal it makes. It never writes directly to the database.

Business rules validate. A deterministic layer, made of ordinary code, testable and auditable, checks every proposal the AI makes: expected formats, consistency against existing reference data, business thresholds. What passes these checks gets accepted. What fails is blocked before it reaches the system.

A human decides. A confidence score that is too low, a business rule that gets violated, a case never seen before: the proposal goes into a validation queue, and a person decides. Every human decision is stored and fed back into the system, which improves with use this way, without heavy model retraining.

What this pattern actually changes

In this architecture, a model's hallucination is no longer a diffuse, uncontrollable risk. It is an explicitly handled case. An AI that gets something wrong becomes a proposal rejected by the validation layer, never wrong data reaching a production database directly.

This is exactly how the document pipeline I delivered in a demanding industrial context runs day to day. It holds up over time not because the AI never makes a mistake, but because its mistakes structurally have nowhere to go without passing through a check.

A detail that is not really a detail

In a system like this, the part actually occupied by artificial intelligence is small. Everything that makes the system trustworthy comes down to ordinary software engineering: tested .NET code, a structured SQL database, explicit business rules, automated tests. That is what I build in a .NET AI integration: AI inside the existing code, under its rules.

The question worth asking

I am often asked which model I use for a given project. That is almost never the most useful question. The question that actually matters is: what happens when this AI gets it wrong? Sometimes the answer allows full automation, as on the Convention Online AI chain, where a mistake is fixed on the next pass. If the answer is not clear before the first deployment, the system is not yet ready for production.

Originally published on gilabs.fr.

I'm Yann Gilliot, founder of GiLabs. GiLabs helps SMEs, mid-caps and professional firms succeed in their AI transformation: process mapping, a costed roadmap, then building the agents and applications that run in production, wired into what you already have.

RAG on an existing .NET estate: three decisions that change everything

Yann Gilliot — Wed, 30 Sep 2026 12:34:53 +0000

TL;DR

The source of truth for permissions already lives in the estate: a vector index inside SQL Server, or an Azure AI Search next to the database, avoids recreating a diverging copy.
Chunking should follow business structure, clauses, sections, paragraphs, not a token window. A fragment cut in half produces an answer off target.
Orchestration stays in the .NET service layer that is already audited, otherwise a second authorization system quietly appears.

Most RAG tutorials start from an empty notebook and a fresh database: a brand new Postgres instance, clean documents already chunked, no access constraints to respect. A client running a Microsoft IT estate starts from somewhere else entirely: a fifteen year old SQL Server, an application in production, permissions already in place, and a security audit that does not forgive shortcuts. In that context, the real question is not which large language model to pick. It is where and how to wire retrieval in without breaking what already holds up.

Three decisions change everything when integrating a RAG pipeline into a .NET / SQL Server context.

Vector storage does not need to live outside the existing estate

The most common reflex is to provision a dedicated vector database, usually outside the existing application boundary. That choice duplicates a problem already solved elsewhere in the estate: who is allowed to see which document. A vector index directly inside SQL Server, or a service like Azure AI Search sitting next to the existing database, lets you reuse the access rules already in place instead of recreating a diverging copy of them. The first question is not the performance of the similarity engine, it is where the source of truth for permissions already lives.

Chunking follows business structure, not a token window

Most RAG guides split documents into fixed size chunks, sized to whatever token window the model accepts. That generic chunking ignores the structure of the document. A contract clause cut in half, a report section truncated mid table: the model receives an incomplete fragment and answers off target, even with the best LLM on the market. Chunking should follow the business structure that is already known: the clauses of a contract, the sections of a report, the paragraphs of a procedure. This is often the least visible part of the work, and the one that most determines answer quality.

Orchestration stays in the .NET service layer

The third reflex to avoid: pulling the retrieval logic into a separate Python microservice, bolted on next to the existing application. That architecture looks technically neutral, but it quietly recreates a second authorization system, with its own rules, usually less audited than the ones already governing the main application. With Semantic Kernel, orchestration stays in the .NET service layer that is already in place: the same access checks, the same logging, the same deployment cycle as the rest of the application. RAG becomes one more capability inside a system that is already governed, not a parallel project with its own rules.

What I would not do again

Treat RAG as a project on its own: its own database, its own access rules, decoupled from the rest of the IT estate. That setup works well in a demo. It becomes a security and maintenance problem the moment it touches production, right when nobody remembers exactly who has access to what anymore. It is the usual gap between what works in a demo and what holds up in production.

RAG does not require rebuilding the existing estate. It requires respecting it: reuse the permissions already in place, respect the business structure of the documents, keep orchestration in the layer that is already audited. It is an architecture question before it is a model question, and that is how I set it up in a .NET AI integration.