Ustalenia IDC stawiają wyniki projektów AI pod lupą CIO
Badania IDC wywołały debatę w Google News na temat niepowodzeń projektów AI; jeden z nagłówków twierdził, że 45% projektów nie przynosi żadnych rezultatów.
Dane źródłowe wymagają jednak uważniejszej lektury. Badania powiązane z IDC wskazują, że średnio tylko 45% inicjatyw AI przynosi mierzalne rezultaty. W zależności od tego, jak organizacje definiują sukces, ustalenie to sugeruje większą lukę wartości, niż wynika z nagłówka.
To rozróżnienie ma znaczenie, ponieważ CIO nie są już oceniani według liczby uruchomionych pilotaży AI. Zarządy oczekują teraz mierzalnych zwrotów, bezpiecznych wdrożeń oraz zarządzania zdolnego kontrolować autonomicznych agentów po wejściu do produkcji.
To jest rzeczywisty konflikt kryjący się za nagłówkiem. Liderzy przedsiębiorstw chcą systemów AI, które wykonują więcej pracy z większą autonomią. Ta sama autonomia utrudnia jednak ograniczanie kosztów, decyzji, uprawnień i skutków awarii.
IDC opisuje zatem coś więcej niż kolejny rozczarowujący cykl technologiczny. Dokumentuje przeniesienie odpowiedzialności z eksperymentalnych zespołów AI na CIO, którzy muszą bronić wyników biznesowych i ryzyk operacyjnych.
Co faktycznie mówi twierdzenie IDC z Google News
Raportowany wskaźnik 45% dotyczy inicjatyw osiągających mierzalne rezultaty, a nie uniwersalnego wskaźnika porażek wszystkich projektów AI w przedsiębiorstwach.
Pierwotny nagłówek w Google News przedstawia 45% projektów AI jako takie, które nie dostarczają rezultatów. Materiały pomocnicze powiązane z IDC prezentują jednak tę statystykę inaczej.
Fujitsu analysis przytacza wrześniowy raport IDC Technology Investment and Innovation Monitor z 2025 roku. Wynika z niego, że średnio 45% inicjatyw AI na świecie osiąga mierzalne rezultaty.
Według cytowania Fujitsu badanie objęło 894 respondentów. Wykazało też, że jedynie 11% organizacji zgłosiło sukces w przypadku ponad trzech czwartych swoich projektów AI.
Pomiary te nie dowodzą, że dokładnie 45% projektów zakończyło się niepowodzeniem. Pokazują, że 45% przyniosło mierzalne rezultaty, pozostawiając 55% bez wykazanego efektu według przyjętego w badaniu podejścia pomiarowego.
Ta luka może obejmować kilka sytuacji. Projekt może nadal znajdować się w fazie testów, trafić do produkcji bez mierzalnej wartości, nie osiągnąć pierwotnego celu albo nie dysponować wystarczającymi danymi do oceny.
To różne rezultaty. Łączenie ich w jeden wskaźnik niepowodzeń tworzy bardziej chwytliwy nagłówek, ale mniej precyzyjny obraz wyników przedsiębiorstw.
Dostępne dowody nie potwierdzają również, że za każdy słaby wynik odpowiadały bazowe modele AI. Adaptacja biznesowa, projektowanie przepływów pracy, jakość danych, koszty operacyjne i niejasne metryki mogą osobno uniemożliwiać realizację wartości.
To rozróżnienie oddziela porażkę techniczną od porażki organizacyjnej. Model może generować akceptowalne wyniki, podczas gdy otaczający go projekt nadal nie realizuje celu biznesowego.
Wewnętrzny asystent może na przykład poprawnie odpowiadać na pytania pracowników. Nadal ponosi komercyjną porażkę, jeśli pracownicy go unikają, odpowiedzi przychodzą zbyt wolno lub koszty wsparcia przewyższają oszczędności.
Model prognostyczny może również dobrze działać w kontrolowanych testach. Przynosi niewielką wartość, jeśli menedżerowie nadal podejmują decyzje w starszym procesie, który ignoruje jego rekomendacje.
Szersze badania IDC wspierają tę interpretację. Firma wskazuje, że organizacje mają trudności z połączeniem eksperymentowania z mierzalnymi wynikami biznesowymi, zwłaszcza gdy nigdy nie zdefiniowano metryk bazowych.
Dlatego nagłówek zasługuje na weryfikację, ale nie na odrzucenie. Dokładny odsetek nadal zależy od definicji, lecz leżący u jego podstaw problem wartości jest dobrze udokumentowany.
Inne badania wskazują na podobny kierunek. Badanie CIO.com z 2026 roku wykazało, że jedynie 19% respondentów stwierdziło, iż ich inicjatywy AI osiągnęły lub przekroczyły cele biznesowe.
Badanie State of the CIO objęło 662 liderów IT i 249 użytkowników biznesowych. Wykazało, że 18% zgłosiło, iż mniej niż jedna trzecia ich przypadków użycia spełniła oczekiwania.
Badania wykorzystują różne próby i definicje, dlatego ich odsetków nie należy traktować jako bezpośrednich porównań. Łącznie pokazują, że mierzalna wartość dla przedsiębiorstw wciąż pozostaje rzadka.
Odpowiedzialny wniosek jest węższy niż wiralowe twierdzenie. Wiele organizacji nie potrafi wykazać konsekwentnych zwrotów z większości inicjatyw AI, a CIO muszą teraz wyjaśnić, dlaczego tak jest.
Ten wniosek jest wystarczająco poważny, bez naciągania liczby.
Eksperymentowanie z AI ustępuje miejsca mandatowi ROI
Kluczową zmianą nie jest spadek zainteresowania AI. To koniec finansowania eksperymentów bez określonych właścicieli, punktów odniesienia i wyników biznesowych.
Inwestycje przedsiębiorstw w AI trwają, choć zwroty nadal trudno udowodnić. Ta pozorna sprzeczność odzwierciedla presję konkurencyjną, a nie zaufanie do każdego projektu.
Zarządy obawiają się, że ograniczenie inwestycji pozostawi ich firmy w tyle. Chcą też, aby CIO wykazali, że obecne wydatki poprawiają przychody, koszty, obsługę klienta, odporność operacyjną lub szybkość podejmowania decyzji.
Tworzy to węższą ścieżkę dla liderów technologicznych. Muszą utrzymać tempo wdrażania, jednocześnie zamykając projekty, które nie potrafią uzasadnić swojego obciążenia operacyjnego.
IDC podaje, że 42% organizacji uznaje ROI z inwestycji cyfrowych i AI za trudny lub niemożliwy do oceny. Firma wskazuje niespójne wartości bazowe i ograniczoną długoterminową widoczność jako główne przeszkody.
Jej agentic ROI framework argumentuje, że systemy agentic utrudniają rozwiązanie tych problemów. Ich wartość i koszty zmieniają się wraz z ewolucją przepływów pracy, modeli i wzorców użytkowania.
Tradycyjne oprogramowanie często wspiera względnie stabilny przypadek biznesowy. Kupujący przed wdrożeniem szacują koszty implementacji, potrzeby licencyjne, oczekiwaną liczbę użytkowników i oszczędności procesowe.
Agentic AI działa inaczej. Agent to oprogramowanie, które może planować kolejne kroki, używać narzędzi i podejmować działania w kierunku celu przy ograniczonej interwencji człowieka.
Jego koszt operacyjny może się zmieniać wraz z liczbą wywołań modelu, rozmiarem kontekstu, użyciem narzędzi, ponownymi próbami i weryfikacjami przez ludzi. Jego wydajność może także ulegać zmianie, gdy zmieniają się warunki biznesowe lub dane źródłowe.
Udany pilotaż dostarcza więc niepełnych dowodów. Może wykorzystywać starannie dobrane dane, niewielką grupę użytkowników i intensywny nadzór techniczny, którego zespoły produkcyjne nie są w stanie utrzymać.
Po szerokim wdrożeniu ten sam system mierzy się z niespójnymi danymi wejściowymi, ograniczeniami dostępu, rzadkimi przypadkami i pracownikami, którzy korzystają z niego w nieoczekiwany sposób.
Dyrektor TIAA Sastry Durvasula opisał to napięcie w raporcie CIO.com. Stwierdził, że udany pilotaż może nadal mieć trudności z osiągnięciem realnego ROI po uwzględnieniu przez organizacje kosztów operacyjnych.
Koszty te obejmują zużycie tokenów, obsługę ruchu, utrzymanie integracji, ewaluacje, przeglądy bezpieczeństwa i wsparcie. Rzadko pojawiają się one we wczesnej demonstracji.
Nowy mandat CIO zaczyna się od zdefiniowania wartości przed rozpoczęciem budowy. Projekt potrzebuje mierzalnej wartości bazowej pokazującej, jak proces działa bez AI.
Potrzebuje także właściciela biznesowego, który korzysta z wyniku. Zespoły techniczne nie mogą samodzielnie poświadczać wartości biznesowej, gdy inny dział kontroluje wdrożenie i zmiany w przepływie pracy.
CIO.com ustalił, że 83% badanych liderów IT miało międzyfunkcyjne struktury AI lub planowało je wdrożyć w ciągu roku. Formalne zatwierdzanie i pomiar pozostawały jednak mniej dojrzałe.
Jedynie 53% miało oficjalny proces zatwierdzania projektów AI. Kolejne 28% planowało wprowadzić taki proces w ciągu następnych 12 miesięcy.
Formalne metryki istniały w 47% organizacji respondentów, a 34% planowało je ustanowić. Ta luka pomaga wyjaśnić, dlaczego wdrożenia i mierzalne zwroty często się rozchodzą.
Organizacje nie mogą udowodnić poprawy, jeśli nigdy nie zarejestrowały pierwotnego kosztu procesu, wskaźnika błędów, czasu realizacji ani wyniku dla klienta.
Rezultatem jest odwrócenie odpowiedzialności. Wcześniejsze programy AI nagradzały liczbę pilotaży i widoczne eksperymentowanie. Kolejny etap nagradza zdyscyplinowaną selekcję i powtarzalną wartość.
Ta zmiana modyfikuje również rozmowy z dostawcami. Twierdzenia o jakości modeli mają mniejsze znaczenie, gdy kupujący nie potrafi powiązać tej jakości z wynikiem operacyjnym.
CIO coraz częściej potrzebują dowodów obejmujących cały przepływ pracy. Muszą mierzyć, czy pracownicy korzystają z systemu, czy jakość wyników pozostaje stabilna i czy koszty mieszczą się w limitach.
Potrzebują również zasady zakończenia projektu. Projekty, które wielokrotnie nie osiągają progów wdrożenia, jakości lub finansowych, powinny stracić finansowanie, zanim staną się trwałą infrastrukturą.
Taka praktyka nie oznacza wrogości wobec AI. Traktuje wydatki na AI z taką samą dyscypliną, jaką stosuje się wobec innych strategicznych inwestycji.
Główny konflikt to obietnica AI kontra rzeczywistość operacyjna
Projekty AI w przedsiębiorstwach często zawodzą na granicy między przekonującą demonstracją a złożonym środowiskiem, w którym odbywa się rzeczywista praca.
Głównym przeciwnikiem w tej historii nie jest jeden dostawca AI walczący z drugim. Jest nim obietnica szybkiej wartości AI zderzona z rzeczywistością operacji przedsiębiorstwa.
Demonstracje zwykle izolują wąskie zadanie. Systemy produkcyjne muszą poruszać się wśród uprawnień, nieaktualnych zapisów, sprzecznych polityk, niepełnych danych i kilku zależnych aplikacji.
Każda dodatkowa zależność tworzy kolejną ścieżkę awarii. Model może zwrócić rozsądną odpowiedź, podczas gdy niedostępne narzędzie, nieaktualny zapis lub nieprawidłowe uprawnienie uniemożliwiają wymagane działanie.
Jakość danych stwarza podobny problem. Systemy AI potrafią podsumowywać, klasyfikować lub wyszukiwać informacje, ale nie mogą naprawić każdej sprzeczności ukrytej w repozytoriach przedsiębiorstwa.
Agent wsparcia może napotkać trzy wersje tej samej polityki zwrotów. Bez autorytatywnego źródła i historii wersji może z pełną pewnością wybrać niewłaściwą zasadę.
Praca oparta na wiedzy tworzy kolejne wyzwanie pomiarowe. Szybsze tworzenie wersji roboczych nie przekłada się automatycznie na wartość finansową, jeśli pracownicy poświęcają zaoszczędzony czas na sprawdzanie niewiarygodnych wyników.
Projekt musi mierzyć cały proces. Obejmuje to przygotowanie, generowanie, przegląd, korektę, eskalację oraz wszelkie błędy w dalszych etapach.
W tym miejscu istotne może stać się podejście knowledge blending. Łączenie zatwierdzonych źródeł z kontekstem roboczym może ograniczyć luki w wyszukiwaniu, lecz zarządzanie nadal określa, którym materiałom można zaufać.
Znaczenie ma również wdrożenie w przepływach pracy. Pracownicy często omijają nowy system, gdy dodaje kroki, wymaga nieznanych interfejsów lub zawodzi w rzadkich przypadkach.
Takie zachowanie może pozostać niewidoczne podczas sponsorowanego pilotażu. Uczestnicy otrzymują szkolenie i wsparcie, podczas gdy zwykli użytkownicy mierzą się z konkurującymi priorytetami.
Skuteczne wdrożenie wymaga zatem przeprojektowania procesu, a nie tylko dostępu do modelu. Zespoły muszą zdecydować, które zadania się zmieniają, które zatwierdzenia pozostają i kto obsługuje wyjątki.
Różnica między wsparciem a autonomią jeszcze bardziej podnosi stawkę. Asystent pisania proponuje tekst do sprawdzenia przez człowieka. Agent może tworzyć zgłoszenia, modyfikować rekordy, kontaktować się z klientami lub uruchamiać transakcje.
Niedokładna sugestia kosztuje czas potrzebny na weryfikację. Niedokładne autonomiczne działanie może zmienić rzeczywiste systemy, zanim człowiek je zauważy.
Badania IDC wskazują, że organizacje nie powinny stosować technologii agentic do każdego zadania. Deterministyczna automatyzacja nadal lepiej sprawdza się w stabilnych procesach z jasnymi regułami.
Systemy agentic mają więcej sensu, gdy praca wymaga kilku kroków, zmiennego kontekstu, osądu i orkiestracji między narzędziami. Nawet wtedy autonomia musi tworzyć wystarczającą wartość, aby uzasadnić dodatkowe ryzyko.
Ta dyscyplina w doborze przypadków użycia pomaga wyjaśnić debatę IDC dotyczącą niepowodzeń projektów AI. Niektóre słabe projekty zaczynają się od technologii szukającej problemu.
Zespoły najpierw wybierają model lub platformę agentową. Następnie szukają procesu, który mógłby uzasadnić zakup.
Taka sekwencja często prowadzi do interesujących prototypów o ograniczonym znaczeniu operacyjnym. Żadna jednostka biznesowa nie bierze odpowiedzialności za wynik, ponieważ projekt nie wynikał z mierzalnej potrzeby.
Silniejsza sekwencja zaczyna się od kosztownego lub ograniczonego procesu. Zespoły dokumentują jego punkt odniesienia, identyfikują związane z nim decyzje i sprawdzają, czy AI poprawia całościowy rezultat.
Porównanie powinno uwzględniać konwencjonalne oprogramowanie i zmiany procesowe. AI powinno wygrać dlatego, że pasuje do problemu, a nie dlatego, że kierownictwo zażądało inicjatywy AI.
Organizacje muszą także odróżniać produktywność od faktycznie przechwyconej wartości. Zaoszczędzenie pracownikowi kilku minut nie ma automatycznie znaczenia finansowego.
Firma przechwytuje wartość tylko wtedy, gdy ten czas poprawia wyniki, skraca czas odpowiedzi dla klienta, zwiększa przepustowość lub obniża zidentyfikowany koszt.
Doświadczenie pracowników i odporność organizacji również mogą mieć znaczenie. Liderzy muszą jednak określić, jak te korzyści będą mierzone, zamiast traktować je jako wygodne wyjaśnienia po niespełnieniu celów finansowych.
Z tego powodu IDC proponuje szersze mapowanie wartości. Jego ramy obejmują zaufanie klientów, odporność, zrównoważony rozwój i horyzonty czasowe obok konwencjonalnych miar finansowych.
Ten szerszy model nie powinien stać się wymówką dla nieprecyzyjnych twierdzeń o sukcesie. Każdy wymiar nadal potrzebuje właściciela, punktu odniesienia, metody pomiaru i daty przeglądu.
Rzeczywistość operacyjna jest zatem mniej dramatyczna niż załamanie modelu, ale trudniejsza do naprawienia. Wymaga koordynacji między zespołami technologii, finansów, bezpieczeństwa, prawa i biznesu.
Żadna aktualizacja modelu nie stworzy tej koordynacji automatycznie.
Zarządzanie agentową AI zmienia bezpieczeństwo w ograniczenie biznesowe
Zarządzanie agentową AI decyduje o tym, czy autonomia może skalować się bezpiecznie, ponieważ agenci przekształcają niepewne wyniki w działania w połączonych systemach.
Bezpieczeństwo od zawsze wpływało na decyzje dotyczące technologii w przedsiębiorstwach. Systemy agentowe zmieniają ten problem, łącząc niepewność modelu z poświadczeniami, narzędziami, pamięcią i dostępem operacyjnym.
Konwencjonalny chatbot zazwyczaj zwraca informacje. Agent może zinterpretować żądanie, stworzyć plan, wywołać aplikacje i kontynuować działanie po otrzymaniu nowych wyników.
Ta zdolność rozszerza powierzchnię ataku. Złośliwa treść może wpływać na instrukcje agenta, a nadmierne uprawnienia mogą przekształcić jedną błędną decyzję w większy incydent.
Jednym z przykładów jest prompt injection. Atakujący umieszcza instrukcje w treści odczytywanej przez model, próbując przekierować system z jego autoryzowanego zadania.
Zagrożenie rośnie, gdy agent może wysyłać wiadomości, modyfikować bazy danych, pobierać poufne rekordy lub wykonywać kod. Myląca odpowiedź staje się tylko jednym z możliwych rodzajów awarii.
IDC ostrzega przed niekontrolowanymi kaskadami decyzji, nieprzejrzystym zachowaniem i rozproszoną eskalacją. Jego analiza zarządzania opisuje zarządzanie jako infrastrukturę operacyjną, a nie końcowy przegląd zgodności.
Firma prognozuje, że do 20% organizacji z Global 1000 może do 2030 roku stanąć w obliczu pozwów, grzywien lub zwolnień CIO. IDC wiąże to ryzyko z głośnymi zakłóceniami spowodowanymi słabym zarządzaniem agentami AI.
To prognoza, a nie zaobserwowany wskaźnik niepowodzeń. Sygnalizuje skalę potencjalnej odpowiedzialności, a nie gwarantowany rezultat.
IDC zaleca identyfikowalność, zintegrowane zarządzanie i zdefiniowane pętle odpowiedzialności. Te mechanizmy pomagają zespołom odtwarzać decyzje i przerywać działania, zanim przekroczą ustalone granice.
Identyfikowalność oznacza rejestrowanie danych, modelu, instrukcji, wywołań narzędzi i wyników zaangażowanych w autonomiczną decyzję. Bez tych zapisów zespoły nie mogą badać błędów ani bronić rezultatów.
Zintegrowane zarządzanie łączy odpowiedzialność zespołów bezpieczeństwa, danych, prawa, ryzyka i biznesu w całym cyklu życia systemu. Komitet analizujący wyłącznie model nie może zarządzać kompletnym procesem.
Pętle odpowiedzialności określają, kiedy człowiek musi zatwierdzić, przejrzeć lub zatrzymać działanie. Próg powinien zależeć od możliwych konsekwencji, a nie wyłącznie od pewności modelu.
Działania niskiego ryzyka mogą otrzymać większą autonomię. Wysłanie wewnętrznego przypomnienia ma inne konsekwencje niż zatwierdzenie płatności lub zmiana konta klienta.
Równie ważne są mechanizmy kontroli tożsamości. Każdy agent potrzebuje własnej tożsamości, uprawnień, właściciela i celu, zamiast korzystać z nieograniczonych poświadczeń dewelopera lub współdzielonej usługi.
Uprawnienia powinny być zgodne z zasadą najmniejszych uprawnień. Agent otrzymuje wyłącznie dostęp potrzebny do przypisanego mu procesu, bez szerszych uprawnień.
Organizacje potrzebują również wiarygodnego rejestru. Zespoły bezpieczeństwa nie mogą chronić agentów, o których istnieniu nie wiedzą, zwłaszcza gdy działy mogą konfigurować ich w aplikacjach biznesowych.
Rejestr powinien obejmować informacje o właścicielu, połączonych systemach, zatwierdzonych danych, dostawcach modeli, wynikach ewaluacji i mechanizmach awaryjnych.
Po wdrożeniu konieczna staje się ciągła ewaluacja. Zachowanie agenta może się zmieniać, gdy aktualizowane są modele, ewoluują prompty, zmieniają się podłączone narzędzia lub dane biznesowe rozwijają nowe wzorce.
IDC zauważa, że wydajność może pogarszać się wraz ze zmianą kontekstu i narastaniem przypadków brzegowych. To sprawia, że agent staje się stale zarządzaną usługą, a nie zakończonym wdrożeniem.
Bezpieczeństwo i ROI zatem się łączą. Monitorowanie, ewaluacje, kontrola dostępu, reagowanie na incydenty i nadzór człowieka zwiększają koszty operacyjne.
Uzasadnienie biznesowe, które pomija te mechanizmy, przedstawia sztucznie korzystny zwrot. Usunięcie ich w celu ochrony prognozy przenosi presję finansową na ekspozycję bezpieczeństwa.
To kluczowy kompromis, którym muszą zarządzać CIO. Większa autonomia może zwiększać szybkość i przepustowość, ale zwiększa także koszt zapewnienia kontroli.
Odpowiedzią nie jest nieograniczony przegląd każdego działania. Wyeliminowałoby to efektywność, która uzasadniała użycie agenta.
Organizacje potrzebują autonomii opartej na ryzyku. Mogą automatyzować odwracalne, obserwowalne działania, wymagając jednocześnie zatwierdzenia przez człowieka dla decyzji o konsekwencjach prawnych, finansowych lub dotyczących bezpieczeństwa.
Zarządzanie agentową AI musi również obejmować procedury wyłączania. Zespoły potrzebują możliwości unieważniania poświadczeń, zatrzymywania procesów, izolowania pamięci i zabezpieczania dowodów podczas incydentu.
Bez tych możliwości agent może pozostać operacyjny, podczas gdy kilka zespołów debatuje nad odpowiedzialnością. To porażka kontroli organizacyjnej, nawet jeśli model działał zgodnie z założeniami.
Czego liczby nadal nie mogą udowodnić
Dostępne statystyki pokazują szeroki problem z tworzeniem wartości, ale nie potwierdzają jednego uniwersalnego wskaźnika niepowodzeń projektów AI.
Ujęcie tematu przez google news zachęca do binarnej interpretacji. Projekt albo odnosi sukces, albo ponosi porażkę, a jeden procent ma podsumować cały rynek.
Wdrożenia w przedsiębiorstwach rzadko pasują do tego modelu. Projekt może osiągnąć techniczny benchmark, nie osiągnąć celu adopcji, zmieścić się w budżecie, a mimo to nie generować mierzalnych przychodów.
Inny projekt może przekroczyć pierwotne koszty, tworząc jednocześnie strategicznie istotną wiedzę lub korzyści dla klientów. To, czy zostanie uznany za sukces, zależy od ram oceny.
Sformułowanie ankiety również zmienia wyniki. „Dostarczono mierzalne rezultaty” to coś innego niż „spełniono oczekiwania”, „wdrożono do produkcji” czy „wygenerowano zwrot finansowy”.
Znaczenie ma też dobór próby. Ankieta wśród liderów technologicznych może przynieść inne wyniki niż badanie użytkowników biznesowych, zespołów finansowych czy pojedynczych projektów.
Kolejny problem tworzy mianownik. Niektóre badania liczą każdy prototyp. Inne obejmują wyłącznie wdrożenia produkcyjne lub inicjatywy znane wyższemu kierownictwu.
Różnią się również horyzonty czasowe. System AI może potrzebować kilku kwartałów przeprojektowania procesu i adopcji, zanim pojawią się jego korzyści.
Ogłoszenie porażki po jednym kwartale może być przedwczesne. Kontynuowanie bezterminowo bez dowodów może zmarnować więcej kapitału.
Te ograniczenia nie unieważniają ustaleń IDC. Określają, co czytelnicy mogą odpowiedzialnie z nich wywnioskować.
Najsilniejszy wniosek jest taki, że przedsiębiorstwa mają trudności z mierzeniem i powtarzaniem wartości AI. Najsłabszy wniosek mówi, że stały odsetek wszystkich projektów definitywnie poniósł porażkę z tego samego powodu.
To rozróżnienie wpływa także na odpowiedzialność. Jeśli model jest automatycznie obwiniany, organizacje mogą zmieniać dostawców, zachowując jednocześnie problemy z procesem, danymi i zarządzaniem, które spowodowały słabe wyniki.
Jeśli każdy problem przypisuje się gotowości organizacyjnej, dostawcy mogą unikać odpowiedzialności za niewiarygodne produkty. Obie narracje zasługują na analizę.
Jakość modelu nadal ma znaczenie. Halucynacje, niespójne rozumowanie, opóźnienia, ograniczony kontekst i błędy w użyciu narzędzi mogą sprawić, że aplikacja nie nadaje się do środowiska produkcyjnego.
Znaczenie ma również projekt dostawcy. Nabywcy potrzebują użytecznych dzienników audytowych, kontroli uprawnień, powiadomień o zmianach modelu, narzędzi ewaluacyjnych i przewidywalnego działania usługi.
Organizacje pozostają odpowiedzialne za wybór właściwych przypadków użycia i bezpieczną konfigurację dostępu. Dostawcy pozostają odpowiedzialni za rzetelne opisywanie możliwości i ograniczeń.
Dyskusja IDC o niepowodzeniach projektów AI powinna zatem prowadzić do lepszych pytań, a nie do wskazania jednego wygodnego winowajcy.
Jaki punkt odniesienia projekt miał poprawić? Który właściciel biznesowy zaakceptował cel? Czy koszty bezpieczeństwa i operacyjne uwzględniono przed zatwierdzeniem?
Czy pracownicy korzystali z systemu po zakończeniu wsparcia pilotażowego? Czy jakość wyników pozostała akceptowalna w nietypowych przypadkach i przy zmieniających się danych?
Czy zespoły mogły odtworzyć działania agenta po błędzie? Czy mogły natychmiast zatrzymać proces bez wyłączania niezwiązanych systemów?
Te pytania przekształcają sporny nagłówek w przegląd operacyjny. Są też trudniejsze do odpowiedzenia niż pytanie, czy pilotaż uruchomiono zgodnie z harmonogramem.
Niezależne porównanie wzmacnia potrzebę ostrożności. Gartner podał, że 45% organizacji o wysokiej dojrzałości utrzymało projekty AI w działaniu przez co najmniej trzy lata.
Jego badanie dojrzałości AI powiązało długowieczność z dojrzałymi praktykami, ale sama długowieczność nie dowodzi wartości biznesowej.
Projekt może pozostać operacyjny z powodów strategicznych lub politycznych. Projekt może także zakończyć się po skutecznym przeniesieniu jego możliwości do innej platformy.
Żadna pojedyncza miara nie oddaje całego rezultatu. Organizacje potrzebują perspektywy portfelowej, która rozdziela wydajność techniczną, adopcję, wpływ finansowy, ryzyko i wartość strategiczną.
Ten portfel powinien obejmować nieudane projekty. Ukrywanie porzuconych pilotaży tworzy mylący obraz i uniemożliwia zespołom rozpoznanie powtarzających się przyczyn.
Powinien także odróżniać zdrowe anulowanie od niekontrolowanego niepowodzenia. Wczesne zakończenie słabego projektu może świadczyć o zdyscyplinowanym zarządzaniu, a nie o słabych wynikach.
Jedno źródło CIO.com opisało anulowanie około jednej trzeciej rozpoczętych projektów jako zdrowe działanie. Organizacja stosowała finansowanie etapowe i punkty kontrolne rezultatów, aby słabe prace nie pochłaniały stałych zasobów.
Takie podejście zmienia sposób postrzegania porażki. Niebezpieczny projekt nie zawsze jest tym, który się kończy. Może nim być ten, który trwa bez dowodów, ponieważ nikt nie jest właścicielem decyzji.
Trzy sygnały, które CIO powinni obserwować w następnej kolejności
Kolejnym testem będzie to, czy organizacje zastąpią liczbę pilotaży raportowaniem rezultatów, kontrolowaną autonomią i dowodami, że pracownicy korzystają z AI w rzeczywistych procesach.
Pierwszym sygnałem jest wdrażanie formalnych podręczników tworzenia wartości AI. IDC oczekuje, że do 2027 roku 60% CIO z Asia-Pacific 500 otrzyma zadanie ich opracowania.
Model wartości standaryzuje wybór przypadków użycia, wartości bazowe, modele kosztowe, odpowiedzialność i progi przeglądów. Pozwala liderom porównywać projekty na podstawie spójnych dowodów.
Ten sygnał wzmocniłby argumentację IDC, jeśli organizacje zaczną zamykać projekty bez mierzalnych rezultatów. Osłabiłby ją, gdyby formalne pomiary rozszerzały się bez poprawy wyników portfela.
Kluczową miarą nie jest liczba opublikowanych modeli. Jest nią udział inicjatyw produkcyjnych z przypisanymi właścicielami, wartościami bazowymi, pełnymi kosztami operacyjnymi i zaplanowanymi przeglądami wyników.
Rady nadzorcze powinny również obserwować, jak organizacje raportują pośrednie korzyści. Zaufanie klientów, odporność i szybsze podejmowanie decyzji mogą mieć znaczenie, lecz każde z nich wymaga możliwej do zaobserwowania metody pomiaru.
Drugim sygnałem jest wdrażanie egzekwowalnych mechanizmów kontroli agentów. Same polityki nie mogą zarządzać oprogramowaniem, które działa nieprzerwanie w systemach biznesowych.
CIO powinni śledzić, ilu agentów ma dedykowaną tożsamość, ograniczone uprawnienia, kompletne dzienniki działań, zasady eskalacji do człowieka i przetestowane procedury wyłączenia.
Zespoły ds. bezpieczeństwa powinny także raportować incydenty według ich wagi i przyczyny źródłowej. Rosnąca liczba incydentów może odzwierciedlać zarówno pogarszające się bezpieczeństwo, jak i lepszą widoczność wcześniej ukrytej aktywności.
Bardziej znaczącym trendem jest to, czy liczba poważnych incydentów spada wraz ze wzrostem wykorzystania agentów. Organizacje powinny porównywać wskaźniki incydentów z liczbą działań agentów, podłączonych systemów i poziomami ryzyka.
Prognoza IDC dla regionu Azji i Pacyfiku przewiduje poważne konsekwencje niewystarczającej kontroli agentów, w tym ryzyko prawne i odpowiedzialność kadry zarządzającej. Ta prognoza staje się bardziej wiarygodna, jeśli autonomiczne wdrożenia rosną szybciej niż nadzór techniczny.
Staje się mniej wiarygodna, jeśli organizacje wykażą, że mechanizmy kontroli oparte na ryzyku skalują się wraz z wykorzystaniem. Dowody powinny obejmować wyniki audytów, czasy powstrzymania, naruszenia uprawnień i skuteczne interwencje ludzi.
Trzecim sygnałem jest wdrożenie produkcyjne powiązane z wynikami przepływów pracy. Dokładność pilotażowa i entuzjazm pracowników nie mogą zastąpić trwałego wykorzystania w codziennych operacjach.
CIO powinni monitorować aktywne wykorzystanie, wskaźniki ukończenia, częstotliwość wyjątków, czas przeglądu oraz odsetek wygenerowanej pracy, która prowadzi do użytecznego rezultatu.
Powinni także mierzyć, co dzieje się po ograniczeniu wsparcia po wdrożeniu. System zależny od stałej interwencji swoich twórców nie osiągnął powtarzalnej gotowości produkcyjnej.
Jednostki biznesowe muszą raportować, czy AI skraca czasy cyklu, zwiększa zdolności operacyjne, ogranicza błędy lub poprawia wyniki dla klientów. Zespoły finansowe powinny weryfikować wszelkie deklarowane oszczędności.
Ten sygnał wzmocniłby narrację google news, gdyby wykorzystanie rosło, podczas gdy mierzalna wartość pozostawałaby niewielka. Pokazałby, że sama adopcja nie rozwiązuje problemu ROI.
Osłabiłby tę narrację, gdyby dojrzałe programy wykazały powtarzalne korzyści w kilku przepływach pracy po uwzględnieniu pełnych kosztów bezpieczeństwa i operacyjnych.
Te trzy sygnały są ze sobą powiązane. Lepsze modele wartości wybierają silniejsze przypadki użycia, silniejsze mechanizmy kontroli umożliwiają bezpieczną autonomię, a trwała adopcja przepływów pracy dostarcza mierzalnych dowodów.
Usunięcie jednego elementu tworzy niestabilny rezultat. Rentowny system bez mechanizmów kontroli niesie ukryte ryzyko. Bezpieczny system bez użytkowników nie tworzy wartości.
Popularny system bez pomiarów bazowych generuje imponującą aktywność, ale niepewne zwroty.
CIO powinni oprzeć się presji, by odpowiadać na debatę kolejnym ogólnym wskaźnikiem procentowym. Ich własne portfele dostarczają bardziej użytecznych dowodów niż zagregowany nagłówek.
Mogą zacząć od wybrania niewielkiej liczby istotnych przepływów pracy i udokumentowania obecnej wydajności. Każdy projekt powinien otrzymać właściciela biznesowego, właściciela technicznego, klasyfikację ryzyka i harmonogram przeglądów.
Zespoły powinny obliczać koszty wykraczające poza początkowy etap rozwoju. Obejmują one wykorzystanie modeli, utrzymanie integracji, monitorowanie, ewaluacje, bezpieczeństwo, wsparcie i przegląd przez człowieka.
Przed przyznaniem autonomii powinny zdefiniować niedopuszczalne rezultaty. Te granice mogą obejmować ujawnienie danych, limity finansowe, wpływ na klientów oraz zakazane działania narzędzi.
Na koniec powinny publikować wyniki wewnętrzne, w tym informacje o anulowanych projektach. Transparentne raportowanie utrudnia słabym projektom przetrwanie wyłącznie dzięki entuzjazmowi.
Sporny wskaźnik 45% jest więc użyteczny jako ostrzeżenie, a nie jako uniwersalna karta wyników. Pokazuje, jak łatwo nieprecyzyjny pomiar staje się pewnym siebie nagłówkiem o AI.
Lepszą odpowiedzią nie jest spór o jeden procent google news. Jest nią żądanie dowodów, że każdy system AI tworzy wartość po uwzględnieniu jego pełnych kosztów i ryzyk.
Które projekty przetrwałyby taki test w Twojej organizacji, a które nadal są finansowane, ponieważ nikt nie zdefiniował, co oznacza sukces?
