The demonstration worked. The principal nodded, the team applauded, and there was talk of “rolling it out next quarter”. Six months later, the prototype lies dormant in a browser tab nobody opens anymore. This scenario is not bad luck: it is the default trajectory. It is estimated that nearly 80% of proofs of concept in Artificial Intelligence never make it past the production threshold. And in almost every case we see in Monaco, the cause is not the model. It lies upstream, in the way the project was conceived.
The thesis of this article is simple and somewhat uncomfortable: a POC that dies has not failed technically, it was optimised for the wrong thing. It was built to succeed at a demonstration, not to survive in production. Yet these are two different objects, with opposing requirements. Understanding that gap already means knowing why your last prototype led nowhere, and how to keep the next one from meeting the same fate.
The demo and production are two opposing disciplines
A demonstration is designed to impress in fifteen minutes. You pick the three cleanest files, you steer the question, you avoid the awkward cases. The result is genuine, but it answers an artificial question: “can this work?” The answer is almost always yes. That is precisely why a demo proves nothing useful.
Production answers a different question: “does it hold, every day, on the thousandth file, the one that is badly scanned, bilingual, with a handwritten clause in the margin, processed on a Friday at 6 p.m. by a member of staff who has no time to check?” This is no longer a question of capability, it is a question of robustness, integration and trust. The leap between the two is not a 10% technical leap. It is a change in nature. Here are the five precise places where the project goes off the rails.
The 5 real reasons for failure
1. No prioritised use case, let alone a quantified one
The original sin. A feat was demonstrated (“look, it summarises a contract!”) without answering the only question that matters: what costly business problem does this summary make disappear, and how many hours or errors does that represent per month? Without that figure, the project has no champion when budget arbitration comes around. A POC without a quantified use case is not a project, it is a curiosity. And a curiosity never survives an executive committee.
2. The real data is dirtier than the sample
The prototype was running on thirty hand-picked documents. Reality has twelve thousand of them, including PDFs scanned askew, letters in two languages, amounts written out in words, attachments that are in fact photos taken on a phone. Performance collapses, not because the model is poor, but because it was trained to run on a smooth track before being released into the mud. The quality of an AI system is never higher than the quality of the data it is given to read. For a family office, that means position statements that differ from one custodian bank to another; for a managing agent, decades of general meeting minutes in inconsistent formats; for a shipowner, class certificates and manifests that have never twice known the same layout.
3. Zero integration with the information system
The prototype lives in a separate interface. To use it, you have to copy and paste a document, read the answer, then copy it out again somewhere else. Nobody does this by the third day. A tool that does not write into the software your teams already use (the practice's document management system, the core banking platform, the co-ownership software, the mailbox) is not a working tool, it is a permanent demonstration. Integration is not an end-of-project detail: it is what turns an answer into a completed business action.
4. Adoption neglected, as if the tool were enough
The technology was delivered and it was assumed that people would use it. But a legal assistant with twenty years of experience does not take a machine's word on trust, and she is right not to. Without change management (showing where the tool gets it wrong, defining who validates what, granting the right to contradict it), teams revert to their habits within a few days. Adoption cannot be decreed, it is earned by making visible what the tool knows and what it does not.
5. Compliance discovered too late
The most Monégasque of failures. Everything works, you are ready to deploy, and someone asks the question: where is the data hosted? Has it passed through an American service? Do we have a legal basis for this processing within the meaning of law n°1.565? The DPO discovers the project at the end and, unable to audit it, freezes it. A project designed without compliance is not corrected: it is rebuilt. That is why, in a marketplace where professional secrecy is an asset, compliance cannot be a final milestone. It is an architectural constraint, from the very first line.
The method in 4 milestones
Industrialising is not “improving the prototype”. It is reversing the order of the work: deciding before coding, measuring against reality before investing, building compliance into the foundations rather than onto the top. Four milestones, each with a concrete deliverable and a trap it neutralises.
Milestone 1 · Quantified scoping (compliance included)
No code is touched. We conduct business interviews, we map a real process end to end, we select one high-impact use case and we quantify the expected gain in hours, in lead times or in errors avoided. In parallel, and this is where everything is decided, we map the data concerned and its sensitivity: nature, origin, legal basis, hosting required, who has access. Deliverable: a one-page scoping note with a measurable objective, and a first compliance reading (data residency, legal basis, level of sensitivity in light of law n°1.565 and, where applicable, AML/CFT obligations). Trap avoided: the project with no champion and the compliance surprise. As an order of magnitude to bear in mind, the McKinsey 2024 estimate puts the share of administrative tasks potentially automatable at between 60 and 70%, and the time that could be freed up at around 5 hours per week per member of staff; these are only bounds to be confirmed by your own audit, never a promise.
Milestone 2 · Prototype measured on real data
Now we build, but on your real data, the dirty kind, and with success indicators defined in advance. This is the non-negotiable point. We do not ask “is it impressive?” but “on 200 real files, does the correct-extraction rate reach the threshold set at milestone 1?” This is where the real technical building blocks come into play. RAG (retrieval-augmented generation) makes the model answer solely from your documents, citing its sources, instead of inventing. Structured extraction turns a letter into verifiable fields (amount, date, counterparty). Human-in-the-loop enforces human validation on at-risk cases, rather than letting the machine decide alone. Deliverable: a prototype tested on a representative sample, with an honest table of measurements, including the cases where it fails. Trap avoided: the showcase performance that collapses in production.
Milestone 3 · Progressive, sovereign and integrated go-live
We deploy, but in stages and starting with the safest uses (a suggestion submitted for review before any autonomous action). We connect the tool to the existing software. We choose a sovereign architecture: hosting with a local provider (Monaco Cloud, Monaco Telecom, Telis), a European private cloud or on-premise depending on sensitivity. We activate client compartmentalisation (one principal's data never crosses another's) and the logging of every access and every decision. Tool-use agents (capable of acting, not just answering) are introduced only with explicit safeguards. Deliverable: a service in production over a restricted perimeter, integrated, hosted in a controlled jurisdiction, traceable. Trap avoided: the big-bang deployment that turns the slightest error into a general incident.
Milestone 4 · Measurement and handover
The tool is live, but it must be proven to deliver on its milestone 1 promises and made independent of its designers. We compare the real gains against the promised gains, we train the teams, we document, we install a continuous improvement loop fed by human corrections. Deliverable: a gains dashboard, operating documentation, trained teams that no longer need the expert to keep the tool running. Trap avoided: dependence on the provider and the project that, a year on, nobody can say whether it earns anything.
An AI project is not judged on the day of the demo, when everyone is smiling. It is judged on the day a member of staff, alone, under pressure, trusts the machine's answer for the file of a client who matters. All the work consists in earning that moment.
The checklist before the first line of code
If you were to keep only one page, it would be this one. Four questions to settle before funding anything at all:
- Is the problem quantified? How many hours, lead times or errors does this use case make disappear per month? If the answer is vague, the project is not ripe.
- Does the data really exist, and in what form? Available, accessible, usable? Have you looked at the worst files, not just the finest?
- Is compliance settled upstream? Data residency, legal basis within the meaning of law n°1.565, professional secrecy, AML/CFT obligations where applicable. Was the DPO involved from the outset?
- Who will use it, and who keeps the decision? Where does the boundary fall between what the machine proposes and what a human validates?
Answering these four questions clearly already means joining the 20% of projects that succeed.
Why Monaco fails, or succeeds, differently
Monégasque structures play this game with particular cards. Size first: a notarial practice, a family office, a wealth management firm often number fewer than twenty people. This is an underestimated asset. No interminable governance committee, a decision taken around a table, a perimeter tight enough for a well-chosen use case to genuinely touch daily work. A project that would take six months in a large group can here be scoped in a few weeks.
Sensitivity next. The data handled is among the most confidential there is: estates, holding structures, files of wealthy clients, health data for a clinic. This rules out certain mass-market architectures and demands sovereignty from day one, which is a constraint but also a healthy discipline. Finally secrecy, the pillar of the marketplace's reputation. In Monaco, a leak is not repaired with a press release: it damages an asset that took decades to build. That is what makes logging, compartmentalisation and human decision-making not comfort options, but conditions of the project's very existence.
Let us be honest about the limits, because that is what separates an expert from a salesperson. Generative AI gets things wrong, and it gets them wrong with assurance: it can produce a false answer phrased in a perfectly credible way. It is weak on exact figures, on fine legal reasoning, on anything that demands certainty rather than plausibility. That is why no serious architecture entrusts it with a final decision on a sensitive matter: it prepares, it proposes, it accelerates, a human decides. A project that claims to remove that boundary does not deserve your signature.
This is the logic we follow at Minervia: audit before building, anchor compliance in the architecture rather than bolting it on at the end, and leave the decision to the men and women of the trade. If a POC lies dormant somewhere in your organisation, it is often better to reopen it with these four milestones in mind than to launch a new one. The technology, almost always, was not the problem.