Clicksov
Book a call

From pilot to production: why most AI projects stall, and what one workflow in production really takes

Published · 6 min read

Most regulated organisations have AI pilots. Few have AI in production. The gap is not a lack of models or ambition. It is three practical problems that a pilot never has to solve, and that nobody budgets for until go-live.

This article describes where projects stall, what changes when you narrow the scope to one workflow and one KPI, and what to ask a vendor before you sign.

The pattern: pilots everywhere, production rare

Vendor surveys from 2026 point in the same direction. Most organisations run AI pilots. A small share reach production. After go-live, running the system costs more than building it did. Treat these as indicative; the surveys differ in method and sample, and the exact percentages matter less than the pattern.

In insurance, DNB (the Dutch central bank) published in January 2026 that most large and medium-sized insurers have at least one AI application in regular business processes. DNB also noted that documentation of choices and ongoing monitoring after deployment often lags. Production is possible. Keeping it under control is the harder part.

Where it stalls: three places

1. Data and access rights

A pilot runs on an export. Someone pulls a sample of documents into a folder, and the model performs well. Production runs on live systems, with live access rights. The workflow must fetch a file and the policy terms from the core system, and it must do so with the rights of the user who triggered it, not with a service account that sees everything.

That means connectors with access rights, agreed with security and the data owner. It is usually the first point where a pilot team finds out it never had a mandate.

2. Integrations and rules buried in code

A pilot has a prompt and a demo screen. A production workflow has thresholds, routing rules and exceptions. In most pilots these end up inside the prompt or in application code. Nobody outside the team can read them, and changing a threshold means a release.

In production, decision rules belong in configuration that the business owner can read and change, such as a decision table (DMN). The model reads and classifies; the rule decides what happens next.

3. Day-2: the part nobody budgeted

Day-2 is everything after go-live. Monitoring. Updates. Re-evaluation when a model is swapped. Cost reporting per department. Someone has to own it, and the pilot budget rarely includes it. This is the point where projects quietly stop: the team that built the pilot moves on, and nobody is on call.

What changes when you scope one workflow with one KPI

Narrow scope sounds modest. In practice it is what makes production reachable.

  • One process means one data owner, one set of access rights, one core system to connect.
  • One KPI, measured as a baseline in week one, means you know whether the workflow works before anyone argues about it.
  • One workflow fits in one versioned repository: spec and prompts, domain model, evaluation set, deployment, policy, runbook. That repository is what you operate, test and hand over.

The evaluation set is the quiet centre of this. It is a collection of golden examples with thresholds. Every build is tested against it. Every model swap starts with it. If the result stays within the thresholds, the change ships. If not, it does not.

A worked example: document and claims intake

A claims department receives files by email, portal and API. Today a handler opens each one, finds the policy, reads the documents and decides what to do. The KPI is lead time per case.

The workflow in production looks like this:

  1. Trigger. A claim arrives by email, portal or API.
  2. Fetch. The workflow retrieves the file and the policy terms from the core system, using the handler's access rights.
  3. Read. An open-weight model running on EU infrastructure reads, summarises and classifies the documents.
  4. Rule. A decision table applies thresholds and routing: straightforward cases go one way, exceptions another.
  5. Human check. The handler sees the summary, the classification and the proposed action, and approves or corrects.
  6. Action. The file is prepared in the core system.

Nothing in this chain is exotic. The work is in steps 2, 4 and the operations behind them. The model is one component, and it is replaceable: the workflow asks for a role such as "extractor" through an AI gateway, not for a specific brand.

The data stays in the EU. The keys stay in the insurer's own key management. No training happens on customer data. That is what people mean by sovereign; the benefit comes first, the label after.

What to ask a vendor: six questions

  1. Which process, and which KPI? If the answer is "the platform", there is no production plan yet.
  2. How does the workflow get data? Ask for connectors with access rights, not an export.
  3. Where do the rules live? In configuration the business can read, or in code only the vendor can change?
  4. How is quality tested? Ask to see the evaluation set and the thresholds.
  5. Who runs it after go-live, and what does that cost? Day-2 should be a line in the offer, not a surprise.
  6. What do we get if we leave? Repository, images, model references, data export. In writing.

How Clicksov does it in eight weeks (indicative)

Clicksov takes one workflow at a time into production and keeps it running. The timeline below is indicative; it depends on the state of your systems and the availability of your data owner.

  • Week 1. Pick the process and one KPI. Measure the baseline.
  • Weeks 2 to 3. Unlock data and systems: connectors with access rights, rules moved into configuration.
  • Weeks 4 to 6. Build and test against the evaluation set.
  • Weeks 7 to 8. Go live. Day-2 starts: monitoring, evaluations at every model swap, updates, cost per department. All included in the run fee.

The workflow runs on European partner infrastructure or on your own premises. Clicksov builds no data centres and no models; it builds and runs the workflow on top of them. Pricing is outcome-based: a one-off onboarding (indicative from €25,000) and a monthly result fee per completed case (indicative €4 to €8, capped), with partner infrastructure passed through at cost.

Want to know which workflow qualifies first? Book a conversation.

Sources

Which process do you want to take live?

Book a call