To nie jest projekt IT

Struktura projektowa ma wpisaną datę końca i zamknięty zakres. Wartość z AI powstaje dopiero w ciągłej adaptacji procesu, więc projekt kończy się mniej więcej w tygodniu, w którym praca zaczyna się na dobre, i zostawia działający system bez właściciela. Decyzja zapada przed startem, nie po pilotażu. Albo nazywasz osobę, która w dniu 400 odpowiada za ten wynik swoim rachunkiem zysków i strat (P&L), albo godzisz się, że w dniu 400 takiej osoby nie będzie. Trzeciej możliwości nie ma.

Tryb projektowy i tryb produktowy

Zacznijmy od rozróżnienia, które w większości firm nie istnieje na papierze, choć rozstrzyga o wyniku. Sriram Narayan opisał je w Products over Projects (martinfowler.com, 2018) jako różnicę między trybem projektowym a produktowym, i rozłożył na sześć wymiarów. Każdy z tych wymiarów zachowuje się inaczej po dniu odbioru.

Ostatni wiersz jest tym, na którym cała sprawa się łamie. Projekt uznaje się za udany, gdy dowiózł zadeklarowany zakres w zadeklarowanym terminie za zadeklarowane pieniądze. Narayan zauważa przy tym, że w trybie projektowym zwykle nie ma w ogóle mechanizmu weryfikacji rzeczywistych korzyści po dostawie. Zła wola nie ma z tym nic wspólnego. Sprawdzać nie ma kto i nie ma z jakiego budżetu, bo jednostka organizacyjna powołana do tej pracy przestała istnieć w dniu podpisania protokołu.

Drugą połowę tego układu opisał Mik Kersten w Project to Product (IT Revolution, 2018). Zarządzanie projektowe finansuje kamienie milowe przy zakresie zdefiniowanym z góry, więc każda nowa potrzeba wymaga powołania nowego projektu. Wygląda to na uciążliwość administracyjną. Jest ustawieniem przepustowości adaptacji: jeśli zmiana procesu wymaga nowego wniosku budżetowego, tempo uczenia się systemu równa się tempu komitetu inwestycyjnego, który obraduje raz na kwartał. Kersten opiera to na doświadczeniu z klientami, nie na badaniu kontrolowanym, więc traktuję jego ramę jako model, nie jako dowód. Model wystarczy, bo dalej da się go wyprowadzić od pierwszych zasad.

Prawo Conwaya i data rozwiązania zespołu

Melvin E. Conway sformułował swoją obserwację w artykule How Do Committees Invent? (Datamation, kwiecień 1968). Brzmi ona tak: każda organizacja projektująca system wytworzy projekt, którego struktura jest kopią struktury komunikacyjnej tej organizacji. Zwykle cytuje się to w sporach o mikroserwisy. Tymczasem prawo Conwaya odpowiada wprost na pytanie, dlaczego inicjatywa AI ginie w strukturze projektowej, i robi to bez jednej liczby o porażkach.

Rozłóżmy to na czynniki. Zespół projektowy jest organizacją komunikacyjną o jednej niezwykłej właściwości: ma datę rozwiązania wpisaną w akt założycielski. Skoro organizacja odciska swój kształt w systemie, to system zbudowany przez organizację z datą rozwiązania dziedziczy tę datę. Nie dziedziczy jej w kodzie. Dziedziczy ją w tym, kto rozumie, dlaczego kod wygląda tak, a nie inaczej, oraz w tym, kto ma prawo i pieniądze, żeby go zmienić. Po rozwiązaniu zespołu nie istnieje już żadna organizacja o kształcie odpowiadającym kształtowi systemu. To jest ta bezpańskość.

Sam Conway cytował korolarz przypisywany Brooksowi: skoro pierwszy projekt prawie nigdy nie jest najlepszy, koncepcja systemu i tak będzie musiała się zmieniać, a zatem elastyczność organizacji jest warunkiem skutecznego projektowania. Elastyczna ma być organizacja, nie architektura. Organizacja projektowa jest elastyczna do dnia odbioru i ani dnia dłużej.

Czterdzieści lat później ktoś to zmierzył. Nagappan i współautorzy opublikowali na konferencji ICSE 2008 studium The Influence of Organizational Structure on Software Quality. Materiał obejmował 3404 binaria Windows Visty i ponad 50 milionów linii kodu, nad którymi pracowało kilka tysięcy inżynierów. Autorzy zbudowali osiem metryk opisujących wyłącznie organizację, bez zaglądania do kodu, i sprawdzili, jak dobrze przewidują podatność komponentu na awarie.

Metryki organizacyjne pobiły wszystkie klasyczne metryki kodu. Dla naszego tematu najciekawsza jest druga z nich, nazwana przez autorów NOEE, czyli liczba inżynierów, którzy pracowali przy danym komponencie i odeszli z firmy przed dniem wydania. Uzasadnienie autorów jest wprost o transferze wiedzy: ten, kto przejmie komponent, nie zna uzasadnienia decyzji projektowych ani powodu konkretnych poprawek. Ktoś policzył cenę rozejścia się zespołu i pokazał, że widać ją w awariach. A rozejście się zespołu jest w projekcie zaplanowane od pierwszego dnia.

Dwa zastrzeżenia, bo bez nich ta liczba jest za mocna. To studium jednego produktu w jednej firmie, model predykcyjny na danych historycznych, a nie eksperyment przyczynowy; sami autorzy zgłaszają ograniczoną trafność zewnętrzną. Prawo Conwaya nie zostało tym dowiedzione przyczynowo. Twierdzę mniej i wystarczająco dużo: tam, gdzie ktoś zadał sobie trud pomiaru, kształt organizacji okazał się lepszym predyktorem jakości systemu niż sam system.

Cztery rzeczy, które giną na granicy projektu

Teraz konkretnie. Dzień odbioru przecina cztery rzeczy naraz, a każda z nich jest potrzebna dopiero po tym dniu.

Ginie właściciel. Nie znika stanowisko, tylko odpowiedzialność za wynik. Model trafia pod opiekę utrzymania IT, które odpowiada za dostępność usługi, a nie za to, czy dział obsługi klienta rzeczywiście skrócił czas reakcji. Nikt nie ma tej rzeczy w celach rocznych. Nikt nie traci premii, gdy jakość spada z 91% do 74%, bo nikt tej liczby nie raportuje na żadne ciało kolegialne. Sponsor projektu, który mógłby o to zapytać, ma już w harmonogramie następny projekt.

Ginie budżet, i to ten właściwy. W 2015 roku zespół Sculleya z Google opublikował na konferencji NIPS pracę Hidden Technical Debt in Machine Learning Systems. Najczęściej reprodukowany rysunek z tej pracy pokazuje kod uczenia maszynowego (ML) jako mały prostokąt w rzeczywistym systemie ML. Całą resztę zajmują zbieranie danych, ekstrakcja cech, infrastruktura serwująca, zarządzanie konfiguracją, monitoring, narzędzia analityczne i zarządzanie zasobami. Autorzy nazywają też zasadę CACE, czyli changing anything changes everything: w systemie uczącym się każda zmiana wejścia zmienia zachowanie całości, bo model nie ma granic modularnych, które można by uszanować. Zestawmy dwie rzeczy. Dług techniczny z definicji nie jest spłacany przy budowie, tylko przy utrzymaniu. Projekt finansuje budowę i kończy się przed pierwszą ratą, a zasada CACE mówi, że w tym systemie nie ma tanich drobnych poprawek robionych przy okazji. Opieka pogwarancyjna wykonywana „w ramach bieżącego utrzymania” jest w systemach ML fikcją księgową. Umowa utrzymaniowa, którą podpisano razem z projektem, obejmuje zwykle dostępność usługi i naprawę awarii, a nie ponowne trenowanie modelu na świeżych danych ani rewizję progu decyzyjnego po zmianie regulacji. Tych dwóch pozycji w niej nie ma.

Ginie pętla uczenia się z błędów. Model postawiony w produkcji nie stoi w miejscu, bo świat pod nim się przesuwa. Vela i współautorzy zmierzyli to w pracy Temporal quality degradation in AI models (Scientific Reports, 2022). Wzięli 32 zbiory danych z czterech dziedzin: pogodę, operacje szpitalne, opóźnienia lotów i kursy akcji. Cztery standardowe algorytmy dały na tym materiale 128 kombinacji model–zbiór. Degradację czasową zaobserwowali w 91% z nich. Ważniejszy od odsetka jest kształt zjawiska: model potrafił trzymać jakość długo, a potem załamać się nagle, więc płaski wykres przez rok nie jest dowodem, że jest dobrze. Autorzy traktują to starzenie jako zjawisko odrębne od dryfu danych i zalecają stały pomiar błędu z automatycznym alarmem po przekroczeniu progu. Zastrzegają przy tym, że bezrefleksyjne ciągłe dotrenowywanie ma własne koszty. Badali klasyczne modele predykcyjne, nie duże modele językowe, więc na modele generatywne przenoszę mechanizm, a nie liczbę 91%. To wystarczy do wniosku organizacyjnego: ktoś musi patrzeć na ten wykres w dniu 400, a zespół rozwiązano w dniu 120. Pętla uczenia wymaga przy tym kogoś, kto co miesiąc ogląda przypadki, w których system się pomylił, i ma prawo zmienić na tej podstawie zarówno model, jak i procedurę wokół niego. Projekt nie kupuje takiej osoby.

Ginie mandat do zmiany procesu. To jest najgłębsza z tych czterech strat i najrzadziej nazywana. Kierownik projektu dostaje mandat na narzędzie: ma dowieźć system, przeszkolić użytkowników i zamknąć budżet. Nie dostaje mandatu na to, żeby zlikwidować etap akceptacji, przenieść decyzję o poziom niżej albo powiedzieć dyrektorowi sprzedaży, że jego proces ofertowania nie ma już sensu w dotychczasowym kształcie. Raport RAND The Root Causes of Failure for Artificial Intelligence Projects (2024) stawia na pierwszym miejscu rozjazd między tym, co projekt optymalizuje, a tym, czego organizacja naprawdę potrzebuje. To jest właśnie luka mandatu, opisana od strony zespołu technicznego. Czwarta przyczyna z ich listy brzmi jeszcze dosłowniej: niedoinwestowanie infrastruktury wdrożeniowej, przez które pilotaż nie ma gdzie zamieszkać.

Krążąca wokół tego raportu liczba „ponad 80% projektów AI upada” jest w nim cudzym szacunkiem cytowanym w akapicie wstępnym, a nie wynikiem RAND; własnym wkładem autorów jest analiza jakościowa 65 wywiadów. Skąd biorą się takie liczby i co każda z nich naprawdę liczy, rozbieram w wojnie liczb o porażki AI.

Co mówią dane o tym, komu się udaje

Wchodzą tu dwa badania ankietowe, pod warunkiem że nie bierzemy ich za audyt. Gartner przepytał 782 liderów infrastruktury i operacji (I&O) w listopadzie i grudniu 2025. Co jego 28% naprawdę mierzy i jak ma się do liczb MIT i RAND, rozbieram w wojnie liczb o porażki AI. Tu interesuje mnie wyłącznie atrybucja: ci, którym się udało, przypisują sukces integracji AI z istniejącymi przepływami pracy i systemami oraz pełnemu poparciu strony biznesowej, a nie jakości modelu. Gartner formułuje z tego zalecenie, żeby łączyć AI z biznesem na etapie wykonania, a nie wyłącznie planowania, i to zdanie jest w gruncie rzeczy opisem różnicy między mandatem projektowym a mandatem właściciela procesu. McKinsey w edycji The State of AI z 2025 roku (1993 respondentów) dokłada drugą połowę obrazu. Tylko 21% organizacji korzystających z generatywnej AI fundamentalnie przeprojektowało choć część przepływów pracy, a właśnie ta praktyka wykazuje najsilniejszy związek z wpływem AI na wynik operacyjny (EBIT). To korelacja z samooceny, nie dowód, ale jest spójna z wyprowadzeniem: największa zidentyfikowana dźwignia leży w obszarze, do którego kierownik projektu nie ma uprawnień.

Nie buduję jednak tego eseju na żadnym odsetku porażek, i nie z ostrożności retorycznej. Magne Jørgensen i Kjetil Moløkken-Østvold rozebrali raporty CHAOS Standish Group, czyli najczęściej cytowaną statystykę niepowodzeń projektów IT. Znaleźli nieujawniony plan badania i nieopisane kryteria doboru próby. Definicje sukcesu okazały się chwiejne, więc te liczby nie nadają się do porównań. Ta sama wątpliwość dotyczy świeższych liczb krążących wokół AI. Argument o strukturze musi stać na mechanizmie, a nie na wskaźniku, bo wskaźnik da się podważyć w jednym akapicie.

Test rozstrzygający: dzień 400

Przejdźmy do procedury. Chcesz przed startem wiedzieć, czy masz przed sobą projekt, czy zmianę modelu operacyjnego. Nie pytaj o technologię ani o wielkość budżetu, bo oba odpowiadają na inne pytanie. O tym, czy pilotaż w ogóle ma przejść do produkcji, czy zostać zamknięty, pisałem osobno w Czyśćcu pilotaży; tu zakładam, że ma przejść, i pytam, kto go potem utrzyma. Zadaj trzy pytania o dzień 400, licząc od startu, czyli o moment dawno po zamknięciu projektu. Ta data leży poza okresem gwarancji i poza cyklem premiowym sponsora, czyli w miejscu, w którym organizacja zdążyła już zapomnieć, po co w ogóle zaczynano.

Pytanie pierwsze: kto w dniu 400 jest właścicielem? Nie sponsorem, nie opiekunem systemu ze strony IT, tylko osobą z imieniem i nazwiskiem, która odpowiada za to, czy ta rzecz nadal daje wynik. Jeśli odpowiedź brzmi „utrzymanie”, „zespół danych” albo „to będzie ustalone po wdrożeniu”, masz odpowiedź na cały test.

Pytanie drugie: w czyim rachunku wyników siedzi ten wynik? Właściciel bez własnego P&L jest recenzentem, nie właścicielem. Korzyść z AI prawie zawsze pojawia się w rachunku jednostki biznesowej, a koszt w rachunku IT, i ta asymetria sama w sobie generuje bezpańskość. Jeżeli nie umiesz wskazać linii, w której korzyść i koszt spotykają się u jednej osoby, nie zbudowałeś własności.

Pytanie trzecie: co się dzieje w dniu, w którym model się zdegraduje? Odpowiedź musi zawierać próg liczbowy, nazwisko osoby, do której idzie alarm, i budżet, z którego opłaci się dotrenowanie albo wycofanie. Brak któregokolwiek z tych trzech elementów oznacza, że degradację zauważy klient.

Zauważmy, czego w tym teście nie ma. Nie ma pytania o jakość modelu ani o wybór dostawcy. Piszę o tym osobno w ROI nie siedzi w modelu; tutaj wystarczy konsekwencja praktyczna: test na własność rozstrzyga się w całości poza warstwą techniczną.

Jeżeli w prawej kolumnie masz mniej niż trzy odpowiedzi, prowadzisz projekt i dostaniesz wynik projektu, niezależnie od tego, co napisano w uzasadnieniu biznesowym.

Przeniesienie z budowy na utrzymanie

Z testu wynika jedna operacja, którą dyrektor finansowy rozumie bez tłumaczenia. Zestawienia branżowe powołujące się na dane Gartnera podają, że firmy wydają rzędu dwóch trzecich budżetu IT na utrzymanie, a resztę na wzrost i transformację. Nie stoi za tym jedno cytowalne badanie [DO UZUPEŁNIENIA: źródło proporcji dwóch trzecich budżetu IT], więc biorę tę proporcję jako rząd wielkości. Ważny jest sam podział, bo linia transformacji ma z definicji datę końca, a linia utrzymania jej nie ma. Przeniesienie inicjatywy AI z budowy na utrzymanie nie jest metaforą organizacyjną, tylko konkretną zmianą wiersza w budżecie. Ta zmiana ma dwa skutki. Koszt staje się powtarzalny i ląduje w jednostce, która ma swojego właściciela. Projekt traci przy tym prawo do zamknięcia tematu protokołem odbioru.

W praktyce oznacza to kilka bardzo przyziemnych ruchów. Nazwij właściciela przed pierwszą linijką kodu i wpisz mu tę rzecz do celów, zanim zobaczy demo. Zaplanuj budżet drugiego i trzeciego roku razem z budżetem pierwszego, w tym samym wniosku, bo wniosek rozbity na dwa nigdy nie dostanie drugiej części. Zdefiniuj miarę wyniku biznesowego, nie miarę techniczną, i zmierz ją przed startem, żeby w dniu 400 było z czym porównywać. Ustal, kto ma prawo zmienić proces, i sprawdź, czy ta osoba siedzi w tym samym pionie co właściciel systemu. Gdy te dwie role siedzą w różnych pionach, działający model nie zmienia niczego w wyniku.

Gdzie ustawodawca już to rozstrzygnął

Dla części zastosowań dyskusja o trybie pracy jest zamknięta, i to nie opinią konsultanta. Akt o sztucznej inteligencji, czyli rozporządzenie UE 2024/1689, nakłada na dostawcę systemu AI wysokiego ryzyka dwa obowiązki, które są w istocie zakazem traktowania wdrożenia jako projektu.

Artykuł 72 wymaga ustanowienia i udokumentowania systemu monitorowania po wprowadzeniu do obrotu. Ten system ma przez cały cykl życia aktywnie i systematycznie zbierać dane o działaniu systemu AI. Zebrane dane dostawca dokumentuje i analizuje, żeby móc oceniać ciągłą zgodność z wymogami. Plan monitorowania jest elementem dokumentacji technicznej. Artykuł 17 idzie dalej i wymaga udokumentowanego systemu zarządzania jakością obejmującego cały cykl życia, od projektowania po monitorowanie po wprowadzeniu do obrotu, z procesami kontroli zmian i ciągłego doskonalenia.

Czytając to jak dokument organizacyjny, a nie prawniczy, widzimy dwa wymagania: stałego właściciela i stały pomiar. Jedno i drugie kosztuje w każdym roku, więc pociąga za sobą stałą linię w budżecie. Struktura z datą zamknięcia nie spełnia żadnego z tych warunków. W tych zastosowaniach traktowanie wdrożenia jako projektu przestaje być nieskuteczne i staje się niezgodne z prawem.

Granica tego argumentu jest jednak ostra i trzeba ją trzymać. Oba przepisy wiążą dostawcę systemu wysokiego ryzyka w rozumieniu rozporządzenia. Zdanie „prawo wymaga stałego monitorowania każdego wdrożenia AI” jest po prostu nieprawdziwe i nie wolno go używać jako argumentu w firmie, która wdraża asystenta do wyszukiwania w dokumentacji wewnętrznej. Wartość tych przepisów dla pozostałych przypadków jest inna: ustawodawca opisał minimalny kształt organizacji, która utrzymuje działający model, i zrobił to językiem, który przechodzi przez komitet inwestycyjny. Ten szablon możesz skopiować dobrowolnie.

Kiedy to jednak jest projekt IT

Najsilniejszy zarzut wobec całej tej tezy nie brzmi „projekty działają”. Jest niewygodniejszy: zdanie „to nie jest projekt IT” bywa w praktyce wnioskiem o zwolnienie z dyscypliny, a nie diagnozą.

Bent Flyvbjerg i Dan Gardner opisali w How Big Things Get Done (2023) wyniki z bazy ponad 16 tysięcy dużych przedsięwzięć zbudowanej i kurowanej przez Flyvbjerga. W budżecie i harmonogramie jednocześnie mieści się 8,5% z nich. Gdy do tych dwóch warunków dołożyć dowiezienie obiecanych korzyści, zostaje 0,5%. Autorzy nazywają to żelaznym prawem megaprojektów, a jako przyczyny wskazują skrzywienie optymizmu oraz strategiczne zafałszowanie, czyli celowe zaniżanie kosztów i zawyżanie korzyści po to, żeby przedsięwzięcie w ogóle ruszyło. Dane o korzyściach pochodzą tam z wyraźnie węższego podzbioru niż dane o koszcie i czasie, więc liczba 0,5% stoi na cieńszej podstawie niż 8,5% i tak ją traktuję.

Rzecz w tym, jaką receptę z tego wyprowadzają. Nie brzmi ona „znieście projekty”. Brzmi „myśl wolno, działaj szybko”, a obok niej stoi postulat budowania modularnego. Obie domagają się jeszcze więcej dyscypliny przed startem i jeszcze krótszego okna wykonania. Jeżeli największym zabójcą dużych przedsięwzięć jest zafałszowane uzasadnienie i rozlewający się zakres, to program bez daty końca i bez rozliczenia nie jest lekarstwem na tę chorobę. Jest tą chorobą w postaci czystej, z lepszym słownictwem. Program transformacji, który co kwartał raportuje postęp w slajdach i nigdy nie raportuje wyniku, przeżyje w firmie dłużej niż nieudany projekt, bo nie ma bramki, na której mógłby polec.

Do tego dochodzi argument klasyfikacyjny, który uczciwie zamyka zakres tezy. Część inicjatyw AI naprawdę jest projektami IT. Wymiana silnika optycznego rozpoznawania znaków na model językowy ma skończony zakres i jasne kryterium odbioru. Tak samo podmiana dostawcy API na tańszego albo przepięcie rekomendacji na nowszą wersję biblioteki. Takie prace dzieją się w systemie, który już ma właściciela i już siedzi w linii utrzymania. Podnoszenie takiej wymiany do rangi zmiany modelu operacyjnego kosztuje dwa kwartały uzgodnień i nie kupuje niczego. Sam Narayan robi to rozróżnienie: w budownictwie tryb projektowy ma sens, bo kompetencje budowania i utrzymywania naprawdę się różnią, a w oprogramowaniu różnią się mniej, więc rozdział budowy i utrzymania kosztuje więcej, niż daje. Tryb produktowy nie jest zatem uniwersalnie lepszy; jest właściwy dla pracy, która nie ma naturalnego końca, a błąd klasyfikacji kosztuje w obie strony.

Gdzie zatem przebiega granica? Przebiega tam, gdzie przebiega mandat. Jeżeli inicjatywa wymaga zmiany czyjegoś procesu, przesunięcia decyzji między stanowiskami albo zmiany tego, za co ludzie dostają premię, żaden kierownik projektu nie ma uprawnień, żeby to dowieźć, i struktura projektowa jest błędem klasyfikacji. Jeżeli inicjatywa nie rusza niczyjego procesu i ma właściciela z dnia przed startem, prowadź ją jak projekt, postaw twarde bramki i zamknij ją w terminie. Test na to jest jednozdaniowy: sprawdź, czy sukces inicjatywy wymaga, żeby ktoś poza zespołem wdrożeniowym zaczął pracować inaczej.

Obie dyscypliny naraz

Najgorsze, co można zrobić z tym rozróżnieniem, to zamienić je w hasło i przestać stawiać bramki. Trzymaj więc oba narzędzia naraz: rozliczaj jak projekt to, co ma koniec, a to, co końca nie ma, oddaj komuś, kto w dniu 400 straci premię, gdy wykres pójdzie w dół. Jeśli nie umiesz dziś podać tego nazwiska, budujesz coś, czego nikt nie przejmie.

Bibliografia

1. primaryMelvin E. Conway, How Do Committees Invent?, Datamation, kwiecień 1968 — sformułowanie kanoniczne prawa Conwaya oraz korolarz o elastyczności organizacji przypisywany Brooksowi.
2. primaryNagappan, Murphy, Basili, The Influence of Organizational Structure on Software Quality: An Empirical Case Study, ICSE 2008 — 3404 binaria Windows Visty; metryki organizacyjne, w tym NOEE; studium przypadku korelacyjne, ograniczona trafność zewnętrzna zgłoszona przez autorów.
3. primarySriram Narayan, Products over Projects, martinfowler.com, 20 lutego 2018 — sześć wymiarów różnicy między trybem projektowym a produktowym; brak mechanizmu weryfikacji korzyści po dostawie; własne rozróżnienie autora co do prac o skończonym zakresie.
4. primarySculley i in., Hidden Technical Debt in Machine Learning Systems, NIPS 2015 — udział kodu ML w rzeczywistym systemie, zasada CACE, dług spłacany w utrzymaniu.
5. primaryVela, Sharp, Zhang, Nguyen, Hoang, Pianykh, Temporal quality degradation in AI models, Scientific Reports, 2022 — starzenie modeli jako zjawisko odrębne od dryfu danych; 128 kombinacji model–zbiór, degradacja w 91%; klasyczne modele predykcyjne, nie modele językowe.
6. primaryRyseff, De Bruhl, Newberry, The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed, RAND RR-A2680-1, 2024 — badanie jakościowe, 65 wywiadów; liczba „ponad 80%” jest w tym raporcie cytowanym cudzym szacunkiem, nie wynikiem RAND.
7. primaryRozporządzenie Parlamentu Europejskiego i Rady (UE) 2024/1689 (akt w sprawie sztucznej inteligencji), art. 17 i art. 72 — system zarządzania jakością obejmujący cały cykl życia oraz monitorowanie po wprowadzeniu do obrotu; obowiązki dostawcy systemu wysokiego ryzyka.
8. primaryJørgensen, Moløkken-Østvold, krytyka raportów CHAOS Standish Group [DO UZUPEŁNIENIA: tytuł pracy, czasopismo i rok] — nieujawniony plan badania, nieopisane kryteria doboru i chwiejne definicje sukcesu; statystyki niepowodzeń projektów IT nie nadają się do porównań.
9. secondaryGartner, komunikat prasowy z 7 kwietnia 2026 o badaniu 782 liderów infrastruktury i operacji (I&O) przeprowadzonym w listopadzie i grudniu 2025 — 28% zastosowań w pełni udanych, 20% nieudanych; samoocena respondentów, jednostką analizy jest zastosowanie w I&O. Liczby za relacjami prasowymi, ponieważ newsroom Gartnera nie udostępnia komunikatu do pobrania automatycznego (stan na 12 września 2026).
10. secondaryMcKinsey / QuantumBlack, The State of AI, edycja 2025, n = 1993 — 21% organizacji deklaruje fundamentalne przeprojektowanie części przepływów pracy; najsilniejszy związek tej cechy z wpływem na EBIT; ankieta samoopisowa, korelacja.
11. secondaryMik Kersten, Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework, IT Revolution, 2018 — finansowanie kamieni milowych przy zakresie zdefiniowanym z góry; rama praktyczna oparta na doświadczeniu autora.
12. secondaryBent Flyvbjerg, Dan Gardner, How Big Things Get Done, 2023 — żelazne prawo megaprojektów, 8,5% i 0,5%, skrzywienie optymizmu i strategiczne zafałszowanie; baza własna autora, dane o korzyściach na węższym podzbiorze.