Why does 90% of the cost of an internal AI project come after the POC?

In brief.
In internal AI projects, the POC (proof of concept, the demonstration prototype) is misleading by design: it is built to succeed, on a chosen scope, with clean documents and a cooperative user. A production system is built not to fail: access rights, edge cases, model updates, support, audit. This second life of the project, invisible in a demonstration, accounts for around 90% of the effort and cost.

Anatomy of the 90%

Security and rights: propagating permissions into the search index, checking them on every query, maintaining them as people move within the organisation. Connectors: plugging in document management, email and the CRM, and plugging them in again every time they change. Reliability: annotated test sets, coverage and precision measurement, benchmarks replayed after every change. Robustness: scanned documents, complex tables, 300-page files, everything the POC had avoided. Operations: monitoring, logging, incidents, version upgrades. People: training, support, documentation.

An ongoing undertaking, not a one-off task

Rights change every week, models every quarter, regulation every year: the build never stops, and it turns a project expense into a permanent team. Many organisations discover this in month twelve, when the star prototype becomes a maintenance ticket nobody wants to own any more. A test before sign-off: ask for the plan and budget for the 90%, line by line. If they fit on one slide, they do not exist.

The Optivalue.ai approach

This 90% is a software vendor’s core business: Optivalue.ai pools it across all its customers, whereas each internal project pays for it again on its own, in full.

Why is the POC misleading?
Because it lives within a scope chosen to succeed; production lives in the cases the POC avoided.

‍What is the first item in the 90%?
Measured reliability: annotated sets, evaluation benchmarks, continuous non-regression testing.