Pilot purgatory: where AI projects go to die

Somewhere between the demo that impressed the room and the system that never shipped, most AI initiatives quietly die. The average organisation now scraps close to half of its proofs-of-concept before they reach production, and the survivors take the better part of a year to cross. The comfortable reading is that the technology was not ready, or the team was not good enough. The uncomfortable one, which is this essay's thesis, is that the pilot was designed — rationally, by competent people — so that it could not cross.

That is a claim about optimisation, not talent. A demo is optimised to impress; a product is optimised to survive contact with reality. Those are different objectives, and the gap between them is engineered in at the start, then paid for at the end.

A metaphor on loan from the factory floor

The phrase "pilot purgatory" did not come from AI. The World Economic Forum and McKinsey coined it in their Global Lighthouse Network work, for manufacturers stuck between a promising Industry 4.0 pilot and a factory that actually ran on it. In that literature only about 30% of digital-manufacturing pilots reached scale across the organisation, and the rest leaked their value away.

One caution before the metaphor does any load-bearing work. Those 30%/70% figures are about smart-factory pilots, not AI proofs-of-concept, and it would be sloppy to launder them into the AI debate. I use "pilot purgatory" as a label for a shape — activity that never reaches the bottom line — not as a source of numbers. Borrow the word; leave the arithmetic on the factory floor.

The AI numbers come from elsewhere. S&P Global Market Intelligence ran a survey it calls Voice of the Enterprise: AI & Machine Learning, Use Cases 2025. It polled 1,006 senior IT and line-of-business professionals across North America and Europe. The headline: the average organisation scrapped 46% of its PoCs before they reached production. In the same study, the share of firms abandoning the majority of their AI initiatives jumped from 17% to 42% year over year. The top obstacles were cost, then privacy and data-security risk.

Two honesty notes, because the numbers travel loosely. First, 46% and 42% are not the same statistic and must never be merged. 46% is the average share of PoCs scrapped per organisation. 42% is the share of firms walking away from most of their AI work. Different numerators, different denominators, different sentences. Second, S&P's own page blocks automated access, so the wording here is the one CIO Dive quoted verbatim. I flag that because exact phrasing matters and I have not read it on the primary page.

Secondary readings of the same survey add a cycle time: roughly 48% of AI projects reach production, and getting there takes about eight months. I have only seen that pair in aggregation, not on S&P's own report, so treat the eight months as directional rather than settled — the 46% and 42% are the firmer figures. Even directionally, the shape is clear. Getting to production is slow, and most attempts do not.

Then the forecast. In July 2024, Gartner's Rita Sallam predicted that at least 30% of generative-AI projects would be abandoned after proof of concept by the end of 2025. The named causes: poor data quality, inadequate risk controls, rising costs, or unclear business value. The same release put the cost of a GenAI business-model transformation at 5 to 20 million dollars. Read that as a prediction made in mid-2024, not a measurement taken afterward — Gartner's newsroom is also behind a 403, so the content here is the version carried by trade press. I dismantled the methodology behind figures like these in a companion essay; the short version is that every one of them counts something slightly different. Here I use them as data, not as objects of a teardown, and the teardown lives at /blog/gartner-28-percent.

The last frame is the oldest. Steve Blank, in the Harvard Business Review in October 2019, named the pattern innovation theater. Faced with a threat, organisations produce more process instead of a new answer: hackathons, workshops, innovation pods. Meanwhile procurement, security, and legal quietly make deployment impossible. Blank wrote it before the current wave, and it describes the PoC-as-performance precisely. The demo is the show. The theater is the point.

Why a demo and a product are different animals

The cleanest statement of the gap is one practitioners keep rediscovering: a PoC prioritises velocity, and production prioritises reliability. Those two goals pull in opposite directions, and the pull is structural rather than a matter of care. Optimise hard for one and you build in a debt against the other.

Work it out from first principles, because the authority version explains nothing. A demo runs on a sample of inputs drawn from the easy part of the distribution: clean data, curated cases, fixed prompts, a cooperative operator, no cost ceiling, no clock. That is not cheating — it is what a demo is for. It shows that the thing can work when everything around it is arranged to let it. The trouble is that the arrangement is the result you are measuring, not the model.

Production is the whole distribution, heavy tail and all. It brings data drift, adversarial and confused users, latency and cost budgets, upstream systems that change without warning, and the long list of edge cases that a curated sample was built to exclude. A metric that reads 92% on the demo set can fall far lower on the live one, and that drop is a different problem wearing the same interface, not a bug you patch. The demo answered "can this ever work?" Production asks "does this keep working, cheaply, unattended, when I stop arranging the inputs?"

Most of what closes that gap is not the model. It is the layer around it: data pipelines and the contracts that keep them stable, drift and latency monitoring, versioning and rollback, access control, lineage, human-in-the-loop design, capacity planning, and cost control. Add security, privacy, audit, and a service-level agreement that someone is on the hook for. The operational thesis, in the practitioners' phrase, is that most of the risk in an AI system lives outside the model — in the data flows, the operational decisions, and the feedback loops. A PoC touches none of it. That is why a PoC is cheap, and also why it is not a product.

Name the five things production adds that a PoC never has to carry, because they are the exact five a demo is allowed to assume away. Edge data: the inputs outside the curated sample, where accuracy quietly collapses. Integration: the live upstream and downstream systems the model must read from and write to without breaking them. Maintenance: retraining, drift correction, and the on-call rotation for the day it degrades. An SLA: a signed promise about latency, uptime, and accuracy that someone is measured against. Governance: access control, audit, lineage, and the approval a regulated function will demand before the model touches a real decision. A PoC can skip all five and still demo. A product can skip none of them and still exist.

Make it concrete. A team builds a contract-review assistant that extracts the key clauses from a stack of agreements. On demo day it is flawless. The demo stack was thirty clean, machine-readable PDFs someone selected the night before. Production hands it the real intake: scanned faxes, a merged three-contract file, a language the pilot never saw, a clause phrased in a way no example covered. Accuracy that read 94% on the curated set now reads a number the team is afraid to measure. Nothing about the model changed. The input distribution did, and that distribution was the thing the demo was quietly holding constant. Fixing it is not a tuning pass. It is data contracts, an exception path, a human-in-the-loop review queue, and monitoring to catch the next unseen clause — the whole non-model apparatus the pilot was scoped to skip. The team did not fail. They proved the concept. They just proved it in the one environment where proving it was easy.

This is where the costs get omitted, and not out of laziness: the non-model work is invisible from inside a demo. You cannot see the missing rollback path when nothing has yet gone wrong. You cannot price the data contract when you hand-fed the data yourself. The pilot budget covers the model and the show. The industrialisation budget, often several times larger, is a line item nobody wrote — because nobody owned the day the thing was supposed to ship.

There is a tell that this is a design problem, not a technology problem. MIT's NANDA initiative, in The GenAI Divide (2025), found that roughly 95% of enterprise GenAI pilots produced no measurable impact on profit and loss. The number is contested and easy to over-read — it counts pilots without measurable P&L, not "95% of firms," and I treat it directionally. But the direction is the point: that failure rate held, or rose, across a period when the underlying models improved every quarter. If the models got better and the pilots did not, the defect is in how pilots are structured, not in what the models can do.

The adoption data says the same thing from the other end. McKinsey's State of AI 2025, as cited secondarily, reports that 88% of organisations use AI in at least one function while only 39% report enterprise-level EBIT impact. Starting is easy and nearly universal. Crossing to value is where the population thins out. The bottleneck is the bridge, not the near bank.

The pilot that cannot fail is not an experiment

If the technology is not the cause, the incentives are the obvious suspect, and they do not disappoint. Three structural forces keep pilots alive past the point of usefulness, and all three are rational for the people inside them.

The first is that organisations reward activity, not outcomes. A launched pilot, a fine-tuned model, a slide showing "AI in production" — these are legible and celebrated. Revenue moved and cost removed are slower and harder to attribute to any one person. So the incentive gradient points at starting things, and the career reward lands on the champion who kicked off an expensive initiative, not on the invisible operator who would have had to keep it running. Worse, naming the theater is often career-negative. The sponsor of a costly pilot that delivered nothing gets promoted for "strategic thinking." The person who says it should be killed looks like the one who lacks vision.

The second is that most pilots have no production owner at all. There is a champion who launches it and a vendor who runs it. But no one owns the day it ships, the SLA it must hold, or the metric it must move. The first symptom of purgatory is exactly this: pilots multiplying without a single owner who can state the production criteria out loud. When no one owns the crossing, the crossing does not happen, and no one is accountable for its not happening.

The third force is the sharpest, and it comes from a vendor whitepaper — QueryNow's, which I flag because the diagnosis is a setup for their offer. Their framing, useful even so: a typical pilot has no executable success criteria. It runs in a sandbox against vague goals like "demonstrate value" or "validate feasibility," which means nothing can objectively fail. And a pilot that cannot fail is not an experiment. It is a subscription. The incentives around it conspire to keep it that way. The vendor extends the engagement. The systems integrator bills monthly regardless of outcome. And the sponsor avoids the embarrassment of a verdict by calling the open-endedness "optionality."

Under all three sits an economic asymmetry. The pilot is cheap; industrialising it is not. Some of the cost is data debt — the plumbing needed before a model can even reach production data, which one practitioner estimate puts at three to five times the model budget itself. Treat that multiple as an order-of-magnitude illustration from a blog, not a measured figure, but the direction is right: the model is the cheap part. And at the top of the range sits Gartner's 5-to-20-million-dollar cost of a full GenAI business-model transformation. Cheap to start, expensive to finish, and the expensive part unowned at kickoff. That is a machine for producing pilots that never cross.

Designing a PoC that can cross

The fix is production criteria applied from day zero, before the demo is built, when they are still cheap to insist on — not more rigour applied later. A pilot designed to cross looks different from a pilot designed to impress, and the differences are specific enough to check against.

Name the production owner before the pilot starts. Not the champion who will present it — the person who will answer for the SLA, the cost line, and the metric it must move. If no one will take that role at kickoff, that is your answer about the pilot, and you have it for free before spending a cent.

Set an executable definition of success, numeric and agreed before the first run. Borrow the useful parts of the vendor framing and strip the sales pitch. Use a held-out dataset the buyer owns, so the vendor cannot tune to the test. Fix a numeric pass threshold before starting, so the goalposts cannot move. Run in the buyer's environment, not a curated sandbox. Log reproducible artifacts a skeptic can rerun. Success becomes "a metric that matters moved, in my environment, reproducibly." Not "the demo worked."

Concretely: say the contract assistant must clear 90% extraction accuracy on a two-hundred-document held-out set the buyer sealed before the vendor arrived, and it clears 71%. The pilot has a verdict, and a cheap one, reached before anyone budgeted the rollout. The threshold is there so the answer cannot be renegotiated after the fact by whoever has the most to lose from a "no." It is not there to be kind.

Write the kill criteria at the same time as the plan, not after the sunk cost accrues. CIOs who do this converge on a recognisable list. Kill the pilot when:

• success is undefined or unmeasurable;
• the same milestone slips repeatedly and the status report loops;
• there is no production owner;
• production accuracy sits materially below pilot accuracy, with no path to close the gap;
• no sponsor will commit a deployment budget;
• the business assumption was wrong, and a working model moves no metric that counts;
• adoption stays poor despite enthusiasm;
• the vendor folds the capability into the platform's core and commoditises your edge.

The framing matters as much as the list. Killing on these signals is rational reallocation, not failure.

None of this is expensive. It is a page of decisions taken before the code, and its whole function is to force the questions that a demo is otherwise built to avoid. The cost of skipping it is not visible in the pilot. It arrives eight months later, as a system that impressed everyone and shipped to no one.

When killing the pilot is the right answer

Here the thesis has to defend its own flank, because the obvious misreading of everything above is that a dead PoC is a failure. Often it is the opposite — the intended result of a cheap test working exactly as designed.

A proof of concept is, properly used, a question with a budget. If it returns "no" — this does not clear the threshold, the data is not there, the value is not real — then the process succeeded. It bought a cheap answer to an expensive question before the expensive commitment. Healthy organisations treat a well-run shutdown as a learning win: they archive what was found, document the barrier that killed it, and move the capital. A cheap test that returned "no" is a positive outcome of a decision process, not a scar.

The right unit to optimise, in that light, is not the success rate but the cost of an experiment. Some buyers now ask it directly: how much does a reproducible, safe, useful answer cost — fast enough to still matter when it arrives? Framed that way, many pilots are abandoned not because the idea was bad but because the learning was too expensive relative to what it taught. That is a rational verdict, and it has nothing to do with the model's quality.

There is a portfolio logic under this that a founder already knows. Cheap, reversible probes are options: small premium, capped downside, occasional large upside. The right response to an option that expires worthless is to have paid little for it, not to regret it. A discipline that treats every expired option as a loss to be avoided will stop buying options, which is the same as refusing to explore. So the metric to protect is not how many pilots reached production. It is how cheaply the ones that should have died were allowed to die, and how fast their "no" arrived.

Which is exactly why production-first can be a trap of its own. Impose the full production apparatus on every idea from day zero — SLA, governance, held-out set, named owner, kill criteria — and you raise the price of the cheap exploratory test. Past some point it is no longer cheap. You will kill the fast, disposable probe whose entire value was a quick "no" for a hundred dollars. Loss aversion already pushes the other way, producing zombie pilots that are neither scaled nor killed because ending one feels like admitting waste. The discipline cuts both directions: most experiments should fail, and the ability to end them cheaply is worth as much as the ability to scale them.

And sometimes the eight months is simply correct. When the pilot's real target is integration with a critical system, or a governance regime you are not allowed to shortcut, a long, careful cycle is not purgatory — it is the work. The thesis is narrower than "slow pilots are bad." It is about proofs of concept that were meant to reach production and were designed, by optimisation and incentive, so that they could not. That is a different animal from the exploratory test that was always allowed to die.

The honest test between the two is a single question asked at kickoff: was this pilot supposed to cross? If yes, and it has no owner, no executable success criterion, and no kill switch, it is not exploring. It is performing. If no, then leave it cheap, leave it fast, and let it fail without ceremony.

The number to be afraid of

The 46% is not the scandal. Scrapping PoCs is what a functioning experiment budget looks like, and a firm that killed none of them would be failing in a quieter, more expensive way. The scandal is hidden underneath the number. Ask how many of those PoCs were built by capable people who knew, on day one, that no one owned the day they were meant to ship — and who built the demo anyway.

Purgatory is not where projects go to die by accident. It is where they are sent, fully funded, by an organisation that rewards the sending. Design the crossing before you build the demo — or admit that the demo was the product all along.

Sources

1. primaryS&P Global Market Intelligence, Voice of the Enterprise: AI & Machine Learning, Use Cases 2025 — 1,006 respondents; 46% of PoCs scrapped before production; firms abandoning most AI initiatives up from 17% to 42%. (Primary page returns 403; figures quoted verbatim by CIO Dive.)
2. primaryGartner, "Gartner Predicts 30% of Generative AI Projects Will Be Abandoned After Proof of Concept By End of 2025," press release, 29 July 2024 (Rita Sallam) — the 30% forecast and the 5–20 million dollar transformation cost. (Newsroom 403; content via trade press.)
3. primarySteve Blank, "Why Companies Do 'Innovation Theater' Instead of Actual Innovation," Harvard Business Review, October 2019.
4. primaryMcKinsey & Company / World Economic Forum (Global Lighthouse Network), "How digital manufacturing can escape 'pilot purgatory'" — origin of the term; ~30% of manufacturing pilots reaching scale (not an AI figure).
5. primaryMIT NANDA, The GenAI Divide: State of AI in Business 2025 — ~95% of GenAI pilots without measurable P&L impact (used directionally; unit-of-analysis teardown in the companion essay).
6. primaryMcKinsey & Company, State of AI 2025 — 88% of organisations using AI in at least one function; 39% reporting enterprise-level EBIT impact (accessed here via secondary citation; verify against the primary before hard quotation).
7. secondaryCIO Dive, "AI project failure rates are on the rise: report" — verbatim 46% / 42% / 17% from the S&P survey.
8. secondaryODSC / Medium, "Why AI POCs Fail: The Real Gap Between Pilot and Production" — velocity vs reliability; the risk that lives outside the model.
9. secondaryQueryNow, "The enterprise AI pilot paradox: Why pilots multiply while production stalls" — vendor whitepaper; the "pilot with no failure condition is a subscription" framing and the held-out-set proposal.
10. secondaryInformationWeek, "The Red Flags That Signal an AI Project Isn't Worth Pursuing" — the CIO kill-criteria list.
11. secondaryForbes (Jason Snyder), "MIT Finds 95% Of GenAI Pilots Fail Because Companies Avoid Friction" — reporting on the MIT NANDA figure.
12. secondaryEntrepreneur, "The One Metric That Explains Why So Many AI Pilots Never Get Off the Ground" — the cost-of-experiment framing.

Czyściec pilotaży: gdzie umierają projekty AI

Gdzieś między demem, które zrobiło wrażenie na sali, a systemem, który nigdy nie ruszył, po cichu umiera większość inicjatyw AI. Przeciętna organizacja kasuje dziś blisko połowę swoich PoC, czyli dowodów wykonalności, zanim dojdą do produkcji, a te, które przechodzą, potrzebują na przeprawę większej części roku. Wygodna interpretacja mówi, że technologia nie była gotowa albo zespół za słaby. Niewygodna, która jest tezą tego eseju, mówi, że pilotaż zaprojektowano racjonalnie, rękami kompetentnych ludzi, tak żeby nie mógł przejść.

To twierdzenie o optymalizacji, nie o talencie. Demo buduje się po to, żeby zrobiło wrażenie; produkt po to, żeby wytrzymał zderzenie z rzeczywistością. To dwa różne cele. Przepaść między nimi jest wpisana w projekt na starcie, a płaci się za nią na końcu.

Metafora pożyczona z hali fabrycznej

Zwrot „czyściec pilotaży" nie wziął się z AI. Ukuły go World Economic Forum i McKinsey w pracach nad Global Lighthouse Network. Chodziło o producentów, którzy utknęli między obiecującym pilotażem Przemysłu 4.0 a fabryką, która naprawdę na nim działa. W tamtej literaturze skalę w całej organizacji osiągało tylko około 30% pilotaży cyfrowej produkcji, a reszta gubiła po drodze swoją wartość.

Jedno zastrzeżenie, zanim metafora cokolwiek udźwignie. Te liczby 30/70 dotyczą pilotaży inteligentnej fabryki, nie PoC z AI. Przemycanie ich do debaty o AI byłoby niechlujstwem. „Czyściec pilotaży" biorę jako etykietę pewnego kształtu — aktywności, która nigdy nie dochodzi do wyniku finansowego — nie jako źródło liczb. Pożycz słowo. Arytmetykę zostaw na hali.

Liczby o AI pochodzą skądinąd. S&P Global Market Intelligence przeprowadził ankietę Voice of the Enterprise: AI & Machine Learning, Use Cases 2025. Przepytał 1006 wyższych menedżerów IT i linii biznesowych w Ameryce Północnej i Europie. Najgłośniejszy wynik: przeciętna organizacja skasowała 46% swoich PoC, zanim doszły do produkcji. W tym samym badaniu odsetek firm porzucających większość swoich inicjatyw AI skoczył rok do roku z 17% do 42%. Największą przeszkodą okazał się koszt. Zaraz za nim badani wskazali ryzyko związane z prywatnością i z bezpieczeństwem danych.

Dwie uwagi o uczciwości, bo te liczby krążą w oderwaniu od kontekstu. Pierwsza: 46% i 42% to nie ta sama statystyka i nie wolno ich zlewać. 46% to przeciętny odsetek PoC skasowanych w jednej organizacji. 42% to odsetek firm, które odpuszczają większość swojej pracy z AI. Inne liczniki, inne mianowniki, inne zdania. Druga: strona S&P blokuje dostęp automatyczny, więc sformułowania pochodzą z CIO Dive, które zacytowało je dosłownie. Zaznaczam to, bo dokładne brzmienie ma znaczenie, a nie czytałem go na stronie pierwotnej.

Wtórne odczyty tej samej ankiety dorzucają czas cyklu: mniej więcej 48% projektów AI dochodzi do produkcji, a dojście zajmuje około ośmiu miesięcy. Tę parę widziałem tylko w agregacji, nie w raporcie samego S&P, więc osiem miesięcy traktuj jako kierunek, nie jako pewnik — twardsze są 46% i 42%. Nawet kierunkowo kształt jest jasny. Do produkcji idzie się wolno, a większość prób nie dochodzi.

Teraz prognoza. W lipcu 2024 Rita Sallam z Gartnera przewidziała, że co najmniej 30% projektów generatywnej AI zostanie porzuconych po fazie proof of concept do końca 2025. Wskazane przyczyny: słaba jakość danych, niewystarczające kontrole ryzyka, rosnące koszty albo niejasna wartość biznesowa. Ten sam komunikat wycenił transformację modelu biznesowego wokół GenAI na 5 do 20 milionów dolarów. Czytaj to jako prognozę z połowy 2024, nie jako pomiar zrobiony później — newsroom Gartnera również zwraca 403, więc treść pochodzi z prasy branżowej. Metodologię takich liczb rozebrałem w osobnym eseju; w skrócie każda z nich liczy coś nieco innego. Tu używam ich jako danych, nie jako obiektów rozbiórki, a rozbiórkę znajdziesz pod /blog/gartner-28-percent.

Ostatnia rama jest najstarsza. Steve Blank w Harvard Business Review z października 2019 nazwał ten wzorzec innovation theater, czyli teatrem innowacji. W obliczu zagrożenia organizacje produkują więcej procesu zamiast nowej odpowiedzi: hackathony, warsztaty, komórki innowacji. Tymczasem zakupy, bezpieczeństwo i dział prawny po cichu czynią wdrożenie niemożliwym. Blank pisał to przed obecną falą, a PoC odgrywany jako spektakl opisał precyzyjnie. Demo jest przedstawieniem. Teatr jest celem.

Przepaść między demem a produkcją

Najkrócej tę przepaść ujmuje zdanie, do którego praktycy dochodzą wciąż od nowa, każdy osobno: PoC stawia na szybkość, produkcja na niezawodność. Te dwa cele ciągną w przeciwne strony, a napięcie jest strukturalne, nie wynika z niedbałości. Zoptymalizuj mocno pod jeden, a wpiszesz dług wobec drugiego.

Wyprowadź to od pierwszych zasad, bo wersja „bo autorytet tak mówi" nie wyjaśnia nic. Demo działa na próbce wejść wziętych z łatwej części rozkładu: czyste dane, wyselekcjonowane przypadki, sztywne prompty, chętny do współpracy operator, brak sufitu kosztowego, brak zegara. To nie oszustwo — po to jest demo. Pokazuje, że rzecz umie działać, gdy wszystko wokół ustawiono tak, by mogła. Kłopot w tym, że to ustawienie jest wynikiem, który mierzysz, a nie model.

Produkcja to cały rozkład, z grubym ogonem włącznie. Przynosi dryf danych. Przynosi też użytkowników, jakich nikt nie wyselekcjonował: wrogich, zdezorientowanych. Nakłada budżety na opóźnienia i na koszt. Systemy zasilające zmieniają się bez ostrzeżenia, a do tego dochodzi długa lista przypadków brzegowych, które wyselekcjonowana próbka miała wykluczać. Metryka, która pokazuje 92% na zbiorze demo, na żywym potrafi spaść znacznie niżej. Ten spadek to inny problem w tym samym interfejsie, nie błąd do załatania. Demo odpowiadało na pytanie „czy to w ogóle umie działać?". Produkcja pyta: „czy to działa dalej, tanio, bez opieki, gdy przestanę ustawiać wejścia?".

Większość tego, co domyka tę przepaść, siedzi poza modelem. Domyka ją warstwa wokół niego: pipeline'y danych i kontrakty, które trzymają je stabilnie, monitoring dryfu i opóźnień, wersjonowanie i rollback, kontrola dostępu, śledzenie pochodzenia danych, projekt z człowiekiem w pętli, planowanie przepustowości, kontrola kosztu. Dołóż bezpieczeństwo, prywatność, audyt i umowę o gwarantowanym poziomie usług (SLA), za którą ktoś odpowiada głową. Praktycy ujmują tezę operacyjną tak: większość ryzyka w systemie AI leży poza modelem, w przepływach danych, decyzjach operacyjnych i pętlach sprzężenia zwrotnego. PoC nie dotyka niczego z tego. Dlatego PoC jest tani. I dlatego nie jest produktem.

Nazwij pięć rzeczy, które produkcja dokłada, a których PoC nigdy nie musi udźwignąć, bo dokładnie tę piątkę demo może z góry uznać za niebyłą. Dane brzegowe: wejścia spoza wyselekcjonowanej próbki, gdzie trafność po cichu się załamuje. Integracja: model musi czytać z żywych systemów, które go zasilają, i pisać do tych, które sam zasila, tak żeby żadnego nie zepsuć. Utrzymanie: model trzeba dotrenowywać i korygować jego dryf, a na dzień, gdy jakość spadnie, ktoś musi trzymać dyżur pod telefonem. SLA: ktoś podpisuje się pod konkretnym opóźnieniem i konkretną dostępnością. Podpis obejmuje też trafność, a z całej obietnicy ten ktoś jest potem rozliczany. Governance: kontrola dostępu, audyt, śledzenie pochodzenia i zgoda, której funkcja regulowana zażąda, zanim model dotknie realnej decyzji. PoC może pominąć wszystkie pięć i wciąż zrobić demo. Produkt nie może pominąć żadnej i wciąż istnieć.

Ujmijmy to konkretnie. Zespół buduje asystenta do przeglądu umów, który wyciąga kluczowe klauzule ze stosu kontraktów. W dniu dema jest bezbłędny. Stos dema to trzydzieści czystych, maszynowo czytelnych PDF-ów, które ktoś wybrał poprzedniego wieczoru. Produkcja podaje mu realny wsad: zeskanowane faksy, sklejony plik z trzech kontraktów, język, którego pilotaż nigdy nie widział, klauzulę sformułowaną tak, jak nie ujmował żaden przykład. Trafność, która na wyselekcjonowanym zbiorze czytała 94%, teraz pokazuje liczbę, którą zespół boi się zmierzyć. W modelu nie zmieniło się nic. Zmienił się rozkład wejść, a to właśnie jego demo po cichu utrzymywało na stałym poziomie. Naprawa wykracza daleko poza przebieg dostrajający: trzeba kontraktów danych, ścieżki wyjątków, kolejki przeglądu z człowiekiem w pętli i monitoringu, który wyłapie następną niewidzianą klauzulę — całego pozamodelowego aparatu, który wycięto z zakresu pilotażu. Zespół nie zawiódł. Udowodnił koncepcję. Tyle że udowodnił ją w jedynym środowisku, gdzie dowód był łatwy.

Tu właśnie gubi się koszty, i nie z lenistwa: praca pozamodelowa jest z wnętrza dema niewidzialna. Nie zobaczysz brakującej ścieżki rollbacku, gdy jeszcze nic nie poszło źle. Nie wycenisz kontraktu danych, gdy sam karmiłeś model danymi z ręki. Budżet pilotażu pokrywa model i przedstawienie. Budżet industrializacji, często kilka razy większy, to pozycja, której nikt nie wpisał, bo dzień wdrożenia nie miał właściciela.

Jedna poszlaka wskazuje, że to problem projektu, nie technologii. Inicjatywa NANDA z MIT w raporcie The GenAI Divide (2025) ustaliła, że mniej więcej 95% firmowych pilotaży GenAI nie dało mierzalnego wpływu na rachunek zysków i strat. Liczba jest sporna i łatwa do nadinterpretacji — liczy pilotaże bez mierzalnego P&L, nie „95% firm", i biorę ją kierunkowo. Ale w kierunku tkwi sedno: ten wskaźnik porażki utrzymał się, a nawet rósł, w okresie, gdy modele bazowe poprawiały się co kwartał. Skoro modele się poprawiały, a pilotaże nie, wada siedzi w tym, jak buduje się pilotaże, nie w tym, co potrafią modele.

Dane o adopcji mówią to samo z drugiego końca. McKinsey w State of AI 2025, cytowany wtórnie, podaje, że 88% organizacji używa AI w co najmniej jednej funkcji, a tylko 39% raportuje wpływ na EBIT na poziomie całej firmy. Zacząć jest łatwo i robi to niemal każdy. Przejście do wartości to miejsce, gdzie populacja się przerzedza. Wąskim gardłem jest sam most; brzeg, z którego się wchodzi, nie zatrzymuje prawie nikogo.

Bodźce, które trzymają pilotaż przy życiu

Jeśli technologia nie jest przyczyną, oczywistym podejrzanym są bodźce. I nie zawodzą. Trzy strukturalne siły przedłużają życie pilotażu długo po tym, jak przestaje on być komukolwiek potrzebny, a wszystkie trzy są racjonalne dla ludzi w środku.

Pierwsza: organizacje nagradzają aktywność, nie wyniki. Uruchomiony pilotaż, dostrojony model, slajd z napisem „AI na produkcji" — to rzeczy czytelne i chwalone. Przychód, który drgnął, i koszt, który zniknął, ujawniają się wolniej i trudniej je przypisać jednej osobie. Gradient bodźców wskazuje więc na zaczynanie rzeczy, a nagroda w karierze ląduje u championa, który odpalił kosztowną inicjatywę, nie u niewidzialnego operatora, który musiałby ją potem utrzymać. Gorzej: nazwanie teatru po imieniu bywa złe dla kariery. Sponsor kosztownego pilotażu, który nie dał nic, dostaje awans za „myślenie strategiczne". Ten, kto mówi, że trzeba go zabić, wygląda na pozbawionego wizji.

Druga: większość pilotaży nie ma w ogóle właściciela produkcyjnego. Jest champion, który go uruchamia, i dostawca, który go prowadzi. Ale nikt nie odpowiada za dzień wdrożenia, za SLA, które pilotaż ma utrzymać, ani za metrykę, którą ma ruszyć. Pierwszy objaw czyśćca jest właśnie taki: pilotaże mnożą się bez jednego właściciela, który wypowie na głos kryteria produkcyjne. Bez właściciela nikt nie przeprowadza przejścia i nikt nie tłumaczy się z tego, że go nie ma.

Trzecia siła jest najostrzejsza i pochodzi z whitepaperu dostawcy — firmy QueryNow, co zaznaczam, bo diagnoza jest wstępem do ich oferty. Rama i tak użyteczna: typowy pilotaż nie ma wykonalnych kryteriów sukcesu. Działa w sandboksie, a cele ma mgliste, w rodzaju „pokazać wartość" albo „potwierdzić wykonalność", co znaczy, że nic nie może obiektywnie zawieść. A pilotaż, który nie może zawieść, nie jest eksperymentem. Jest subskrypcją. Bodźce wokół niego spiskują, żeby tak zostało. Dostawca przedłuża zaangażowanie. Integrator rozlicza się co miesiąc bez względu na wynik. A sponsor unika wstydu werdyktu, nazywając tę otwartość „opcjonalnością".

Pod wszystkimi trzema leży asymetria ekonomiczna. Pilotaż jest tani; industrializacja nie. Część kosztu to dług danych: hydraulika, którą trzeba położyć, zanim model w ogóle dosięgnie danych produkcyjnych. Jedno oszacowanie praktyka wycenia ten dług na trzy- do pięciokrotności samego budżetu modelu. Tę wielokrotność traktuj jak ilustrację rzędu wielkości wziętą z bloga, nie jak pomiar. Kierunek i tak się zgadza. Model jest tu tanią częścią. Drogie jest wszystko, co stoi wokół niego. Górną granicę wyznacza wycena Gartnera: od 5 do 20 milionów dolarów za pełną transformację modelu biznesowego wokół GenAI. A na starcie ta droga część nie ma właściciela. To maszyna do produkcji pilotaży, które nigdy nie przechodzą.

Jak zaprojektować PoC, który przejdzie

Lekarstwem są kryteria produkcyjne przyłożone od pierwszego dnia, zanim powstanie demo, kiedy naleganie na nie jest jeszcze tanie. Więcej rygoru dołożonego później tego nie zastąpi. Pilotaż zaprojektowany, by przejść, wygląda inaczej niż pilotaż zaprojektowany, by zrobić wrażenie. Różnice są dość konkretne, żeby dało się je sprawdzić.

Wskaż właściciela produkcyjnego, zanim pilotaż ruszy. Nie championa, który go zaprezentuje — osobę, która odpowie za SLA, linię kosztu i metrykę, którą trzeba ruszyć. Jeśli na starcie nikt nie weźmie tej roli, masz odpowiedź w sprawie pilotażu, i to za darmo, przed wydaniem grosza.

Ustaw wykonalną, liczbową definicję sukcesu, uzgodnioną przed pierwszym przebiegiem. Pożycz użyteczne części ramy dostawcy i odetnij sprzedaż. Użyj zbioru odłożonego (held-out), który należy do kupującego, żeby dostawca nie mógł dostroić się pod test. Ustal liczbowy próg zaliczenia przed startem, żeby nikt później nie przestawiał poprzeczki. Uruchom w środowisku kupującego, nie w wyselekcjonowanym sandboksie. Zapisuj odtwarzalne artefakty, które sceptyk może puścić ponownie. Sukces staje się zdaniem: „metryka, która się liczy, ruszyła, w moim środowisku, odtwarzalnie". Nie „demo zadziałało".

Konkretnie: powiedz, że asystent do umów musi osiągnąć 90% trafności ekstrakcji na dwustudokumentowym zbiorze odłożonym, który kupujący zapieczętował, zanim zjawił się dostawca, a asystent osiąga 71%. Pilotaż ma werdykt, i to tani, wydany, zanim ktokolwiek zabudżetował wdrożenie. Próg jest po to, żeby odpowiedzi nie dało się renegocjować po fakcie przez tego, kto najwięcej traci na „nie". Nie jest po to, żeby było miło.

Napisz kryteria zabicia razem z planem, nie po tym, jak narośnie koszt utopiony. CIO, którzy tak robią, dochodzą zwykle do tej samej, łatwo rozpoznawalnej listy. Zabij pilotaż, gdy:

• sukces jest niezdefiniowany albo niemierzalny;
• ten sam termin w harmonogramie obsuwa się raz za razem, a raport statusu chodzi w pętli;
• nie ma właściciela produkcyjnego;
• trafność na produkcji leży istotnie poniżej trafności z pilotażu, bez ścieżki na domknięcie luki;
• żaden sponsor nie zobowiąże się do budżetu wdrożenia;
• założenie biznesowe było błędne, a działający model nie rusza żadnej metryki, która się liczy;
• adopcja zostaje słaba mimo entuzjazmu;
• dostawca wciela tę funkcję do rdzenia platformy, a twoja przewaga staje się towarem.

Rama waży tu tyle, co sama lista. Zabicie pilotażu na któryś z tych sygnałów jest racjonalną realokacją; organizacja niczego nie przegrywa.

Nic z tego nie jest drogie. To kilka decyzji podjętych przed napisaniem pierwszej linijki kodu, a ich cała funkcja to wymusić pytania, których demo ma unikać. Kosztu ich pominięcia nie widać w pilotażu. Rachunek przychodzi osiem miesięcy później, w postaci systemu, który zrobił wrażenie na wszystkich i nie trafił do nikogo.

Kiedy zabicie pilotażu jest właściwą odpowiedzią

Tu teza musi osłonić własną flankę, bo oczywisty błąd odczytu tego wszystkiego brzmi: martwy PoC to porażka. Często jest odwrotnie — to zamierzony wynik taniego testu, który zadziałał dokładnie tak, jak go zaprojektowano.

Proof of concept, użyty poprawnie, to pytanie z budżetem. Jeśli odpowiedź brzmi „nie", bo wynik nie osiągnął progu, danych nie ma albo wartość jest pozorna, to proces się udał. Kupił tanią odpowiedź na drogie pytanie przed drogim zobowiązaniem. Zdrowe organizacje traktują dobrze poprowadzone wygaszenie jako zdobytą wiedzę: archiwizują, co znaleziono, opisują barierę, która zabiła projekt, i przenoszą kapitał. Tani test, który zwrócił „nie", to pozytywny wynik procesu decyzyjnego, nie blizna.

Właściwą jednostką do optymalizacji jest w tym świetle nie wskaźnik sukcesu, lecz koszt eksperymentu. Część kupujących pyta o to dziś wprost: ile kosztuje odtwarzalna, bezpieczna i użyteczna odpowiedź, która przychodzi dość szybko, żeby jeszcze się liczyła? W tej ramie wiele pilotaży porzuca się nie dlatego, że pomysł był zły, lecz dlatego, że wiedza z nich kosztowała więcej, niż była warta. To racjonalny werdykt i nie ma nic wspólnego z jakością modelu.

Pod tym leży logika portfela, którą founder już zna. Tanie, odwracalne sondy to opcje: mała premia, ograniczony downside, sporadyczny duży upside. Opcja, która wygasła bezwartościowo, kosztowała mało i na tym kończy się rozliczenie. Dyscyplina, która każdą wygasłą opcję traktuje jako stratę do uniknięcia, przestanie opcje kupować, czyli przestanie eksplorować. Chroń więc nie liczbę pilotaży, które doszły do produkcji, lecz to, jak tanio umierały te, które umrzeć powinny, i jak szybko przychodziło ich „nie".

Dlatego właśnie „produkcja przede wszystkim" bywa własną pułapką. Nałóż pełny aparat produkcyjny na każdy pomysł od pierwszego dnia — SLA, governance, zbiór odłożony, wskazanego właściciela, kryteria zabicia — a podniesiesz cenę taniego testu rozpoznawczego. Za pewnym progiem nie jest już tani. Zabijesz szybką, jednorazową sondę, której cała wartość to prędkie „nie" za sto dolarów. Niechęć do straty już pcha w drugą stronę i produkuje zombie-pilotaże, ani nieskalowane, ani niezabite, bo ten, kto zamyka, czuje, że przyznaje się do marnotrawstwa. Dyscyplina tnie w obie strony: większość eksperymentów ma zawieść, a umiejętność taniego ich kończenia jest warta tyle, co umiejętność ich skalowania.

A czasem osiem miesięcy jest po prostu słuszne. Gdy realnym celem pilotażu jest integracja z krytycznym systemem albo reżim governance, którego nie wolno skracać, długi, ostrożny cykl nie jest czyśćcem, tylko właśnie tą pracą, którą trzeba wykonać. Teza jest węższa niż „wolne pilotaże są złe". Dotyczy proof of concept, które miały dojść do produkcji, a zaprojektowano je, przez optymalizację i bodziec, tak żeby nie mogły. To inne zwierzę niż test rozpoznawczy, któremu zawsze wolno było umrzeć.

Jedno pytanie zadane na starcie rozstrzyga, z którym z dwóch pilotaży mamy do czynienia: czy ten pilotaż miał dojść do produkcji? Jeśli nie miał, zostaw go tanim i szybkim, i pozwól mu zawieść bez ceremonii. Jeśli miał, a brakuje mu właściciela, wykonalnego kryterium sukcesu i wyłącznika, to taki pilotaż odgrywa badanie, którego nie prowadzi.

Liczba, której trzeba się bać

Te 46% to nie jest skandal. Organizacja, która kasuje połowę swoich PoC, pokazuje, że ma działający budżet na eksperymenty; ta, która nie zabiłaby żadnego, zawodziłaby ciszej i drożej. Skandal siedzi pod liczbą. Policz, ile z tych PoC zbudowali zdolni ludzie, którzy już pierwszego dnia wiedzieli, że dzień wdrożenia nie ma właściciela, i mimo to zbudowali demo.

Do czyśćca projekty nie trafiają przez przypadek. Wysyła je tam organizacja, z pełnym finansowaniem, i nagradza samo wysyłanie. Zaprojektuj przejście, zanim zbudujesz demo. Jeśli nie zamierzasz, przyznaj przynajmniej, że demo od początku było produktem.

Bibliografia

1. primaryS&P Global Market Intelligence, Voice of the Enterprise: AI & Machine Learning, Use Cases 2025 — 1006 respondentów; 46% PoC skasowanych przed produkcją; odsetek firm porzucających większość inicjatyw AI wzrósł z 17% do 42%. (Strona pierwotna zwraca 403; liczby cytowane dosłownie przez CIO Dive.)
2. primaryGartner, „Gartner Predicts 30% of Generative AI Projects Will Be Abandoned After Proof of Concept By End of 2025", komunikat prasowy, 29 lipca 2024 (Rita Sallam) — prognoza 30% i koszt transformacji 5–20 milionów dolarów. (Newsroom 403; treść przez prasę branżową.)
3. primarySteve Blank, „Why Companies Do 'Innovation Theater' Instead of Actual Innovation", Harvard Business Review, październik 2019.
4. primaryMcKinsey & Company / World Economic Forum (Global Lighthouse Network), „How digital manufacturing can escape 'pilot purgatory'" — źródło terminu; ~30% pilotaży produkcyjnych osiągających skalę (nie jest to liczba o AI).
5. primaryMIT NANDA, The GenAI Divide: State of AI in Business 2025 — ~95% pilotaży GenAI bez mierzalnego wpływu na P&L (użyte kierunkowo; rozbiórka jednostki analizy w eseju towarzyszącym).
6. primaryMcKinsey & Company, State of AI 2025 — 88% organizacji używa AI w co najmniej jednej funkcji; 39% raportuje wpływ na EBIT na poziomie całej firmy (dostęp tutaj przez cytat wtórny; zweryfikuj wobec źródła pierwotnego przed dosłownym cytowaniem).
7. secondaryCIO Dive, „AI project failure rates are on the rise: report" — dosłowne 46% / 42% / 17% z ankiety S&P.
8. secondaryODSC / Medium, „Why AI POCs Fail: The Real Gap Between Pilot and Production" — szybkość vs niezawodność; ryzyko mieszkające poza modelem.
9. secondaryQueryNow, „The enterprise AI pilot paradox: Why pilots multiply while production stalls" — whitepaper dostawcy; rama „pilotaż bez warunku porażki to subskrypcja" i propozycja zbioru odłożonego.
10. secondaryInformationWeek, „The Red Flags That Signal an AI Project Isn't Worth Pursuing" — lista kryteriów zabicia od CIO.
11. secondaryForbes (Jason Snyder), „MIT Finds 95% Of GenAI Pilots Fail Because Companies Avoid Friction" — doniesienie o liczbie z MIT NANDA.
12. secondaryEntrepreneur, „The One Metric That Explains Why So Many AI Pilots Never Get Off the Ground" — rama kosztu eksperymentu.