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.

Osobne badanie dorzuca czas cyklu: według komunikatu Gartnera z 7 maja 2024 roku 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 samym komunikacie, 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: tak wysoki odsetek pilotaży bez mierzalnego wpływu wypada w momencie, gdy modele bazowe poprawiają się co kwartał. Raport jest jednym zdjęciem, nie serią, więc o samym trendzie nie mówi nic. Nawet jako zdjęcie pokazuje jednak, że postęp modeli nie przekłada się sam z siebie na przejście pilotażu do produkcji — a to przesuwa podejrzenie na to, jak buduje się pilotaże.

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.