The recurring pattern
For two years, I have been asking the same question to the CIOs, R&D directors and AI leads I meet across regulated industries:
"What is the last AI project your organisation stopped — and for what exact reason?"
The details vary. The structure is always the same: "The POC was impressive. The technical team was convinced. And then it got blocked — the CISO, the DPO, the Quality Director, the Regulatory Affairs Manager. And the project died."
This is not a technology problem. This is not a skills problem. It is a sequencing problem: production constraints were not built into the POC design.
The underlying problem
A POC optimised to convince maximises the impression of performance on demonstration questions, in a controlled environment, without the real constraints of production. That is rational — nobody funds a project that fails at the demonstration stage. But it creates a structural bias: you demonstrate what impresses, not what works under real conditions.
Teams that successfully reach production do the opposite. They design the POC as a mini-production: same target architecture, same level of constraints, reduced scope. The demonstration is less spectacular. The path to production is far smoother.
What a POC measures — and what it does not
A well-run AI POC generally measures:
- Performance on test questions (precision, recall, response time)
- Perceived ease of use by business users
- Technical feasibility on the target corpus
What it almost never measures:
- The traceability of each answer back to its primary source
- The consistency of answers across two sessions
- Compliance with data integrity frameworks (ALCOA+ in pharma)
- The data flow (where does it go? who accesses it? who can read it?)
These dimensions are not secondary constraints. They are the conditions for production deployment in a regulated environment.
The four most common blockers — and their real cause
What you hear: "We cannot send our data to an external cloud service."
The real cause: The POC was built on a cloud architecture (OpenAI API, Azure OpenAI, Google Vertex…) because it is the fastest path to demonstrating performance. The CISO is correctly applying data sovereignty rules — which existed before the POC and have not changed.
What should have been done: Start from an on-premise architecture at POC stage. Yes, it takes longer. No, that is not a reason to ignore it when you know it is a non-negotiable constraint.
What you hear: "We cannot use a system where we do not control the input and output data."
The real cause: An LLM in production leaves usage traces with the cloud provider. The organisation's GDPR policy prohibits this type of transfer without specific contractual guarantees — often impossible to obtain on the terms of major AI cloud providers.
What should have been done: On-premise architecture + internal audit trail of queries from the design stage.
What you hear: "An MHRA / NRC / EASA inspector will ask us where every piece of information in this report comes from. We cannot answer."
The real cause: The RAG system generates answers that synthesise several sources. It cannot guarantee that element X comes from document Y, section Z. Structurally incompatible with ALCOA+ and with the audit requirements of regulated sectors.
What should have been done: Choose an architecture that cites its sources in an exact and verifiable manner — not one that "synthesises with approximate references".
What you hear: "The same question asked twice can produce two different answers. We cannot submit that to a regulator."
The real cause: LLMs are probabilistic by nature. The same query with a slightly different context can produce a different answer. In a regulatory environment, an answer must be reproducible and identical regardless of who asks it and when.
What should have been done: Deterministic architecture (knowledge graph) for factual regulatory queries, LLM restricted to formatting if required.
How to design a POC that goes live
01Map production constraints before choosing the architecture
Is the data subject to ITAR? → on-premise mandatory. Will the system be audited? → exact traceability mandatory. Do responses engage compliance obligations? → deterministic architecture.
02Include the CISO, DPO and Quality Director in the design phase
These functions are not obstacles. They are guardians of constraints the organisation must respect. Involving them upstream allows you to design a compatible architecture — rather than running into a veto at the production deployment stage.
03Measure production criteria during the POC
In addition to the usual performance metrics, measure: can you cite the exact source document for each answer? Does the same question asked twice give the same answer? Can you trace the full chain during a simulated audit?
04Choose the architecture based on constraints, not deployment speed
A RAG deploys faster. A knowledge graph takes longer to build. If production constraints require a graph, deploying a RAG quickly only defers the problem — and adds a migration cost.
The four questions to ask at the next POC
- "Where do the models run? In whose cloud?" If the models run in the cloud, verify compatibility with your sovereignty rules before approving.
- "For each answer produced, can you cite the exact source document?" If not, ask how this will be resolved before production.
- "If you ask the same question twice, do you get the same answer?" If not, ask what consistency guarantee is offered.
- "Have the CISO, DPO and Quality Director validated the architecture — not just the results?" If not, ask that they be included before production deployment.
These questions do not slow down projects that can go live. They reveal early the ones that cannot.