Przekroczenie budżetu AI przez Ubera ujawnia lukę między wdrożeniem a zwrotem

Uber miał podobno wyczerpać swój budżet na AI na 2026 rok już w kwietniu, ujawniając konflikt między zachęcaniem pracowników do korzystania z AI a kontrolowaniem kosztów tego wdrożenia. Historia budżetu AI Ubera wpisuje się teraz w szerszą debatę przedsiębiorstw: kiedy większe użycie staje się dowodem produktywności, a nie po prostu wyższych wydatków?

Business Standard powrócił do tego napięcia 8 listopada, opisując firmy zwracające się ku kontroli wydatków, mniejszym modelom i bardziej selektywnemu przydzielaniu zadań. Bloomberg informował już w czerwcu o limitach użycia wprowadzonych przez Ubera. Bezpośrednią kwestią jest więc trwająca korekta wydatków, a nie nowo ogłoszona polityka firmy.

Dla nabywców korporacyjnych kluczowa rywalizacja toczy się między celami wdrożeniowymi a mierzalnym zwrotem biznesowym. Claude Code od Anthropic znajduje się w samym centrum tego napięcia. Asystent programowania może stać się popularny, zanim jego nabywca ustali, czy dodatkowe wydatki przekładają się na szybsze wydania, lepsze oprogramowanie lub mniej pracy w innych obszarach.

Historia budżetu AI Ubera przeszła od wdrożenia do odpowiedzialności

Bloomberg podał 2 czerwca, że Uber wprowadził limity użycia AI po przekroczeniu budżetu na początku roku. Raport wskazywał konkretnie narzędzia, w tym Claude Code.

Ustanawia to wcześniejszy publiczny zapis problemu wydatków. Rozdziela też pierwotne wydarzenie w firmie od szerszej listopadowej dyskusji. Czytelnicy nie powinni interpretować najnowszych doniesień jako dowodu, że Uber wprowadził w tym tygodniu kolejną rundę ograniczeń.

Listopadowe omówienie Business Standard zestawia Ubera z innymi firmami ponownie oceniającymi koszty AI dla przedsiębiorstw. Relacja opisuje rosnące zainteresowanie mniejszymi modelami i systemami, które rozdzielają pracę między modele.

Udokumentowaną zmianą jest przejście do kontrolowania zużycia po tym, jak wdrożenie wyprzedziło pierwotne założenia dotyczące wydatków.

Publiczne doniesienia nie przedstawiają pełnego obrazu wewnętrznej ekonomiki Ubera. Nie ustalają, czy pierwotny budżet był adekwatny, jakie dokładnie wydatki obejmował ani jaka była wartość wszystkich ukończonych prac.

Te braki mają znaczenie. Wyczerpany budżet może odzwierciedlać marnotrawstwo, nieoczekiwanie użyteczne oprogramowanie, nierealistyczną prognozę lub kombinację tych czynników. Samo przekroczenie budżetu nie pozwala odróżnić tych wyjaśnień.

Budżet jest też decyzją organizacyjną podejmowaną, zanim rzeczywisty popyt stanie się jasny. Pracownicy odkrywający wartościowe zastosowania mogą przekroczyć ostrożną prognozę, nie podejmując przy tym ekonomicznie nieracjonalnych decyzji.

Odwrotność również jest prawdziwa. Powszechny entuzjazm nie dowodzi, że dodatkowe wydatki się zwracają. Użytkownicy mogą preferować narzędzie, jednocześnie pomijając czas weryfikacji, pracę integracyjną lub błędy, które muszą rozwiązywać współpracownicy.

Pozostawia to zarządowi trudniejsze pytanie niż to, czy pracownikom podoba się oprogramowanie. Istotne jest, czy jego korzyści przewyższają pełne obciążenie operacyjne.

To obciążenie wykracza poza wygenerowanie odpowiedzi. Proponowana zmiana kodu nadal wymaga przeglądu, testów, integracji i utrzymania. Szybsze tworzenie szkiców poprawia dostarczanie tylko wtedy, gdy późniejsze etapy zachowują tę korzyść.

Doniesienia uzasadniają więc kontrolę zarządzania wydatkami, a nie werdykt, że asystenci programowania ponieśli porażkę. Podważają także założenie, że wdrożenie stanowi wystarczający dowód sukcesu.

Rozróżnienie jest szczególnie istotne, gdy kierownictwo zachęca do eksperymentowania, zanim działy otrzymają jasną odpowiedzialność za wydatki. Indywidualne decyzje mogą wyglądać rozsądnie, podczas gdy ich łączny koszt przekracza oczekiwania.

Rozważmy przykładowy zespół inżynierów badający trudny defekt. Kilku deweloperów może niezależnie poprosić asystentów o przeanalizowanie tego samego repozytorium i zaproponowanie rozwiązań. Każda prośba służy uzasadnionemu celowi.

Firma nadal musi jednak wiedzieć, czy te nakładające się analizy tworzą odrębną wartość. Liczenie aktywnych użytkowników pokazałoby udział, ale nie wykryłoby powielonego wysiłku.

To jest luka odpowiedzialności, którą uwidacznia przypadek Ubera. Decyzja zakupowa i ocena produktywności nie mogą pozostawać oddzielone w nieskończoność.

Zespoły finansowe dziedziczą problem, na który panele użycia nie odpowiadają

Presja wydatkowa wykracza poza jedną firmę technologiczną. Badanie branżowe FinOps Foundation z 2026 roku wskazuje, że 98% respondentów zarządza obecnie wydatkami na AI, wobec 31% dwa lata wcześniej.

FinOps to praktyka łączenia wydatków technologicznych z odpowiedzialnością biznesową i wartością. Rosnący zakres AI w tej dziedzinie sugeruje, że koszty te coraz częściej wymagają koordynacji między finansami a inżynierią.

Badanie obejmuje 1 192 respondentów ze społeczności FinOps. To znacząca próba praktyków, ale nie reprezentuje każdego przedsiębiorstwa ani nie dowodzi powszechnych trudności finansowych.

Wyniki opisują również silne inwestycje w AI oraz organizacje poszukujące oszczędności optymalizacyjnych, aby finansować dalsze wdrażanie. Kontrola finansowa może więc wspierać ekspansję, zamiast sygnalizować odwrót.

Bezpośrednia presja spoczywa na liderach, którzy muszą wyjaśnić zarówno wydatki, jak i wynik biznesowy, który za nie uzyskują.

Menedżerowie inżynierii otrzymują sprzeczne instrukcje. Muszą umożliwić pracownikom odkrywanie użytecznych zastosowań, ale nie mogą traktować nieograniczonego eksperymentowania jako modelu operacyjnego.

Liderzy finansowi stoją przed innym problemem informacyjnym. Faktura pokazuje wydatek, ale rzadko wyjaśnia, czy asystent usunął pracę, przesunął ją czy stworzył dodatkowe obowiązki.

Zespoły zakupowe muszą oceniać zobowiązania handlowe wobec niepewnego popytu. Umowa może ułatwić zakup konsumpcji, nie ułatwiając pomiaru wynikającej z niej pracy.

Liderzy produktów odczuwają konsekwencje, gdy ograniczenia budżetowe przerywają użyteczną aktywność. Limit wydatków, który pojawia się niespodziewanie, może zmienić założenia dotyczące realizacji w połowie projektu.

Te presje zbiegają się wokół kosztu na zaakceptowany wynik, czyli pełnego wydatku związanego z rezultatem spełniającym zamierzony standard. Standard ten musi obejmować jakość.

Dla zespołów programistycznych zaakceptowanym wynikiem może być sprawdzona zmiana, która trafia na produkcję bez powodowania dodatkowych defektów. Wygenerowany kod jest artefaktem pośrednim.

W dziale obsługi klienta zaakceptowanym wynikiem może być prawidłowo rozwiązane zgłoszenie. Płynna odpowiedź, która wywołuje kolejny kontakt, nie dostarcza tej samej wartości.

Dla pracowników wiedzy użytecznym wynikiem może być rzetelny briefing z możliwymi do prześledzenia dowodami. Szybki szkic wymagający rozległej weryfikacji stanowi inną propozycję ekonomiczną.

Te przykłady pokazują, dlaczego uniwersalny cel użycia stwarza problemy. Różne zadania wiążą się z różną stawką, wymogami weryfikacji i możliwościami naprawienia błędów.

Dział, który obniża wydatki, jednocześnie zwiększając ręczne poprawki, niekoniecznie poprawił swoją ekonomię. Przeniósł koszt do mniej widocznej kategorii.

Prawdziwa jest też odwrotna sytuacja. Wyższe wydatki na modele mogą mieć sens, gdy usuwają wąskie gardło, które wcześniej pochłaniało ograniczoną uwagę pracowników.

To sprawia, że atrybucja staje się centralna dla debaty przedsiębiorstw. Firmy muszą łączyć zużycie z zespołem, procesem pracy i wynikiem, które są za nie odpowiedzialne.

Atrybucja nie wymaga traktowania każdej prośby pracownika jako wyjątku finansowego. Nadmierne tarcie związane z zatwierdzaniem może pochłaniać ten sam czas pracy, który oprogramowanie obiecuje oszczędzić.

Większa zmiana dotyczy momentu, w którym odpowiedzialność wchodzi do procesu. Założenia wydatkowe coraz częściej powinny należeć do decyzji produktowych i inżynieryjnych, zanim korzystanie stanie się księgową niespodzianką.

Dlatego zarządzanie AI w przedsiębiorstwie nie może kończyć się na panelu kontrolnym. Widoczność wskazuje, gdzie trafiły pieniądze; ocena pracy określa, czy powinny tam trafić.

Routing modeli zmienia ekonomikę, ale dodaje kolejną warstwę decyzji

Listopadowe doniesienia wskazują na orkiestrację modeli, czyli system kontroli koordynujący modele i narzędzia w ramach procesu pracy. Routing modeli wybiera, który model obsługuje konkretne zadanie.

Rozróżnienie ma znaczenie, ponieważ organizacja nie zawsze potrzebuje tych samych możliwości na każdym etapie. Sortowanie dokumentu i rozwiązywanie złożonego wyjątku stawiają różne wymagania.

Mniejszy model może odpowiednio obsłużyć wąskie zadanie klasyfikacyjne. Bardziej zaawansowany model może pozostać konieczny, gdy zadanie obejmuje niejednoznaczność lub trudne rozumowanie.

Selektywne użycie modeli stanowi wiarygodną odpowiedź na presję budżetową, lecz jego wartość zależy od całego procesu pracy.

Zmienia to porównanie dostawców takich jak Anthropic, Microsoft i Google. Nabywcy korporacyjni muszą ocenić, gdzie pasuje każda usługa, zamiast wybierać jeden model do każdej aktywności.

Nie ustanawia to uniwersalnego rankingu tych firm. Istotne porównanie dotyczy rzeczywistego obciążenia pracą nabywcy, wymagań integracyjnych i tolerancji na błędy.

Model, który dobrze wypada w odizolowanej ocenie, może nadal stwarzać problemy w procesie biznesowym. Jego wynik może wymagać więcej przeglądu lub pojawiać się zbyt wolno.

Routing wprowadza własną ocenę sytuacji. System musi zdecydować, które prośby są wystarczająco proste dla mniej wymagającej ścieżki, a które potrzebują dodatkowych możliwości.

Nieprawidłowe przypisanie może wymazać oczekiwane oszczędności. Trudne żądanie wysłane do niewystarczającego modelu może wymagać powtórzenia, eskalacji lub ręcznej naprawy.

Niepotrzebnie ostrożne przypisanie ma odwrotny problem. Kierowanie rutynowej pracy do opcji o najwyższym zapotrzebowaniu na zasoby zachowuje możliwości, ale osłabia finansowe uzasadnienie routingu.

Pytanie ekonomiczne wykracza zatem poza model wybrany dla początkowego żądania. Obejmuje to, co dzieje się, gdy ten wybór zawiedzie.

Przykładowy proces pracy z dokumentami konkretyzuje ten kompromis. System może najpierw rozpoznać typ dokumentu, następnie wyodrębnić informacje, a potem oznaczyć niejednoznaczne fragmenty do przeglądu.

Takie rozwiązanie pomaga tylko wtedy, gdy wczesne etapy niezawodnie rozpoznają własne ograniczenia. Niezauważony błąd klasyfikacji może zanieczyścić wszystko, co następuje później.

Organizacja dziedziczy również pracę utrzymaniową. Prompty, przykłady ewaluacyjne, reguły eskalacji i zachowanie modeli mogą zmieniać się z czasem.

Te obowiązki stanowią część porównania z prostszym wdrożeniem. Rozbudowany system nie staje się ekonomiczny tylko dlatego, że pojedyncze żądania wydają się tańsze.

W tym miejscu kontekst staje się istotny dla pracy opartej na wiedzy. Kontekst to informacje, które model otrzymuje, aby zinterpretować i wykonać żądanie.

Wysyłanie nieistotnych materiałów może obciążać proces pracy bez poprawy jego wyniku. Wysyłanie zbyt małej ilości informacji może zmuszać pracowników do powtarzania wyjaśnień lub korygowania nieporozumień.

Ten sam praktyczny problem pojawia się w przeszukiwalnej bazie wiedzy. Znalezienie właściwych materiałów źródłowych i wygenerowanie odpowiedzi są odrębnymi częściami pracy.

To powiązanie nie dowodzi oszczędności dla żadnego konkretnego produktu. Wyjaśnia, dlaczego nabywcy powinni analizować wyszukiwanie informacji równolegle z wyborem modelu.

Debata o budżecie AI w Uberze wykracza zatem poza limit wydatków. Stawia pytanie projektowe: które elementy pracy zasługują na dodatkowe zasoby obliczeniowe, a które nie?

Agenci mogą jednocześnie zwiększać możliwości i zużycie

Agent AI to system, który wielokrotnie wykorzystuje model i narzędzia do realizacji zadania. Ta powtarzalna aktywność zmienia relację między żądaniami a zużyciem zasobów.

Wymiana na czacie może zakończyć się po udzieleniu odpowiedzi. Agent może sprawdzać pliki, uruchamiać kontrole, ponownie oceniać swoje podejście i kontynuować pracę przed zwróceniem wyniku.

Opis systemu badawczego z wieloma agentami opublikowany przez Anthropic w czerwcu 2025 roku jasno przedstawia ten kompromis. Firma zgłosiła wyższe zużycie tokenów przy jednoczesnej poprawie wyników we własnych ewaluacjach.

Tokeny to jednostki tekstu przetwarzane lub generowane przez model. Anthropic podało, że jego agenci zazwyczaj zużywali około cztery razy więcej tokenów niż interakcje na czacie.

Systemy wieloagentowe firmy, które koordynują pracę kilku agentów, zużywały według jej danych około 15 razy więcej tokenów. Liczby te opisują jej system badawczy.

Nie stanowią uniwersalnej miary dla Claude Code, każdego produktu agentowego ani obecnych wdrożeń korporacyjnych. Bezpośrednie zastosowanie ich do Ubera zawyżałoby wagę tych dowodów.

Bardziej zaawansowana automatyzacja może wymagać większych zasobów obliczeniowych, więc niższe zużycie nie jest automatycznie właściwym celem.

Opis Anthropic wspiera węższy wniosek: niektóre architektury celowo wykorzystują więcej zasobów, aby ukończyć trudniejszą pracę. Ich uzasadnienie ekonomiczne zależy od uzyskanej wartości.

To użyteczna przeciwwaga dla narracji o przekroczeniu budżetu. Firma może racjonalnie zwiększać zużycie, gdy system realizuje pracę, której prostsze oprogramowanie nie potrafi obsłużyć.

Trudność polega na odróżnieniu produktywnej wytrwałości od nieproduktywnego powtarzania. Oba zjawiska mogą tworzyć długi rejestr aktywności i wysoki rachunek.

Przykładowy agent programistyczny może uruchomić testy po zaproponowanej poprawce, odkryć kolejną awarię i zmienić podejście. Ta dodatkowa praca może zapobiec wdrożeniu niekompletnej zmiany.

Inny agent może wielokrotnie modyfikować kod bez zidentyfikowania podstawowego problemu. Podobnie wyglądająca aktywność może przynieść zupełnie inny rezultat.

Rozróżnienie staje się trudniejsze, gdy kilka agentów działa równolegle. Praca równoległa może skracać czas realizacji, jednocześnie zwiększając łączne zużycie.

Menedżerowie muszą więc odróżniać uwagę pracownika od aktywności maszyny. System działający dłużej nie musi koniecznie angażować programisty przez cały ten okres.

Podobnie pozorna oszczędność czasu pracownika nie obejmuje pracy związanej z przeglądem przekazanej innemu zespołowi. Znaczenie mają obie strony przepływu pracy.

To komplikuje proste porównania między asystentami czatowymi, agentami programistycznymi i skoordynowanymi systemami agentowymi. Mogą one wykonywać różny zakres pracy przy pozornie podobnych żądaniach użytkownika.

Uzasadnienie biznesowe musi określać, co się zmieniło. Czy system zakończył wcześniej niepraktyczną analizę, ograniczył wąskie gardło pracownika, czy jedynie wygenerował dodatkowy materiał?

W tej ocenie należy uwzględnić również jakość. Droższe uruchomienie może być lepsze, jeśli pozwala uniknąć błędu o poważnych konsekwencjach w dalszych etapach.

Nie ma sprzeczności między uznaniem tych korzyści a analizowaniem rachunku. Sprzeczność pojawia się wtedy, gdy organizacje oczekują ambitnej automatyzacji, a budżetują tak, jakby pracownicy wymieniali wyłącznie krótkie wiadomości.

Prognozy budżetowe muszą odzwierciedlać pracę faktycznie wykonywaną przez produkt. W przeciwnym razie samo udane wdrożenie może stać się zapalnikiem dla nadzwyczajnego ograniczenia.

Dowody dotyczące produktywności nie pozwalają na prosty werdykt

Najmocniejszy zarzut wobec limitów wydatków jest prosty: mogą one ograniczać użyteczną pracę razem z marnotrawstwem. Ograniczenie nie potrafi odróżnić jednego od drugiego bez dodatkowych dowodów.

Najmocniejszy zarzut wobec nieograniczonych wydatków jest równie prosty: wrażenia pracowników mogą różnić się od zmierzonych wyników. Satysfakcja i produktywność odpowiadają na powiązane, lecz odrębne pytania.

METR, niezależna organizacja zajmująca się oceną AI, zilustrowała to rozróżnienie w badaniu wykorzystującym narzędzia z początku 2025 roku. Uczestniczący doświadczeni programiści open source potrzebowali o 19% więcej czasu, gdy zezwolono na pomoc AI.

Badanie objęło 16 programistów i 246 zadań. Jego wąski kontekst ma znaczenie, podobnie jak znajomość przez uczestników utrwalonych projektów oraz dostępne wtedy narzędzia.

Nie dowodzi ono, że obecne asystenty programistyczne spowalniają każdego programistę. Traktowanie starszego wyniku jako uniwersalnego, aktualnego werdyktu błędnie przedstawiałoby badania.

Aktualizacja pomiaru produktywności METR z 24 lutego 2026 roku dodaje kolejną komplikację. Badacze stwierdzili, że późniejsze dane eksperymentalne dawały niewiarygodne oszacowanie bieżącego wpływu na produktywność.

Część programistów unikała udziału, ponieważ nie chciała pracować bez AI. Uczestnicy wstrzymywali również niektóre zadania, co tworzyło problemy z doborem próby.

METR uznało, że programiści prawdopodobnie odnosili większe korzyści niż wcześniej, lecz podkreśliło niepewność co do ich skali. To dowód na trudność pomiaru.

Ani rosnące użycie, ani przekroczenie budżetu nie rozstrzygają, czy AI tworzy wartość netto.

Ta niepewność bezpośrednio wpływa na interpretację historii budżetu AI Ubera. Publicznie dostępne informacje potwierdzają problem kontroli wydatków, ale nie przedstawiają pełnego bilansu produktywności.

Wiarygodna ocena musiałaby badać porównywalną pracę, w tym czas i wymagania jakościowe związane z jej ukończeniem. Wybrane historie sukcesu nie mogą dostarczyć takiego porównania.

Wybrane porażki również go nie dostarczą. Trudne incydenty mogą ujawnić słabości, jednocześnie niewiele mówiąc o średnim efekcie w skali firmy.

Kolejną przeszkodą jest dobór zadań. Pracownicy często wybierają AI do pracy, przy której spodziewają się pomocy, co utrudnia porównania z pracą bez takiego wsparcia.

Wraz z rozwojem narzędzi może zmieniać się sama praca. Zespoły mogą podejmować ambitniejsze projekty zamiast szybciej kończyć identyczne projekty.

Może to tworzyć wartość bez wyraźnego skrócenia liczby godzin przypadających na zadanie. Może też zacierać obraz tego, czy większa ambicja przynosi użyteczny rezultat.

Rozróżnienie między zyskami indywidualnymi a organizacyjnymi tworzy dalszą niepewność. Programista może pracować szybciej, podczas gdy wspólna zdolność do przeglądu zmian staje się nowym wąskim gardłem.

Na przykład dodatkowe proponowane zmiany mogą zwiększyć kolejkę przed starszymi recenzentami. Firma musi wtedy oceniać całkowitą realizację, a nie wyłącznie szybkość tworzenia pierwszej wersji.

Są to możliwości analityczne, a nie opisane ustalenia dotyczące Ubera. Wyjaśniają, dlaczego dane o zużyciu nie mogą zastępować oceny dostarczania oprogramowania.

Sceptyczne podejście powinno dotyczyć kontroli finansowej tak samo jak twierdzeń dostawców. Niższy rachunek nie dowodzi, że polityka poprawiła produktywność.

Ograniczenia zasługują na ocenę względem wyników, tak samo jak ekspansja. W przeciwnym razie przedsiębiorstwa ryzykują zastąpienie celu wdrożeniowego celem wydatkowym i powtórzenie tego samego błędu pomiarowego.

Trzy sygnały pokażą, czy dyscyplina wydatkowa poprawia rezultat

Kolejny etap należy oceniać na podstawie obserwowalnych zmian, a nie kolejnej rundy szerokich twierdzeń o transformacji AI. Na szczególną uwagę zasługują trzy sygnały.

Pierwszym jest to, czy pracodawcy łączą polityki wydatkowe z wynikami realizacji. Publiczne wyjaśnienia ograniczeń stają się bardziej użyteczne, gdy odnoszą się również do jakości, ukończonej pracy i możliwości pracowników.

Firma wykazująca stabilną lub lepszą realizację po ograniczeniu niepotrzebnego zużycia wzmocniłaby argument za selektywnymi kontrolami. Sam spadek wydatków pozostawiłby pytanie o produktywność otwarte.

Z kolei dowody, że ograniczenia opóźniły wartościowe projekty, osłabiłyby argument za bezkrytycznymi limitami. Skutek polityki ma większe znaczenie niż jej pozorna surowość.

Drugim sygnałem jest sposób, w jaki dostawcy pakują i zarządzają aktywnością agentów. Kupujący powinni obserwować aktualizacje produktów, które pozwalają przypisać zużycie do konkretnych zadań i przepływów pracy.

Jaśniejsze kontrole nad powtarzanymi działaniami, eskalacją i kończeniem zadań pomogłyby przedsiębiorstwom zrozumieć, co kupują. Ich wartość nadal wymaga testowania w rzeczywistej pracy.

Twierdzenia dostawców o efektywności powinny odróżniać zmniejszone użycie zasobów od zmniejszonych możliwości. System, który wykonuje mniej pracy, niekoniecznie stał się bardziej efektywny.

Trzecim sygnałem są mocniejsze dowody dotyczące ukończonej pracy. Ewaluacje obejmujące przegląd, korektę i jakość na dalszych etapach wypełniłyby luki, których pulpity użycia nie rozwiązują.

Powtarzane obserwacje w porównywalnych zadaniach zwiększyłyby pewność. Wyniki ograniczone do wygenerowanych materiałów lub wrażeń pracowników zachowałyby dużą część obecnej niepewności.

Użytecznym kolejnym krokiem jest wyraźniejsze połączenie między zużyciem a zaakceptowaną pracą, a nie samo dalsze zwiększanie skali wdrożenia.

W nadchodzących miesiącach te sygnały oferują bardziej ugruntowany sposób oceny kontroli budżetów AI w przedsiębiorstwach. Pozostawiają też miejsce na odmienne wyniki w różnych działach.

Zespół programistyczny, grupa badawcza i dział wsparcia nie muszą dojść do identycznych wniosków. Różnią się ich zadania, koszty błędów i możliwości automatyzacji.

Kupujący w przedsiębiorstwach powinni zatem powstrzymać się od traktowania decyzji wydatkowej innej firmy jako gotowej odpowiedzi. Doświadczenie Ubera wskazuje pytanie, które każda organizacja nadal musi zbadać.

To samo dotyczy dostawców. Analiza budżetowa może nagradzać produkty, których korzyści łatwiej wykazać, nawet gdy wymagają znacznych zasobów obliczeniowych.

Może również ujawnić wdrożenia, których pozorny sukces zależy od mierzenia aktywności zamiast rezultatów. To rozróżnienie będzie miało znaczenie, gdy przepływy pracy oparte na agentach przejmą większą odpowiedzialność.

Kolejna użyteczna rozmowa w przedsiębiorstwie powinna połączyć właściciela budżetu z osobami odpowiedzialnymi za ukończoną pracę. Zacznij od przepływu pracy, którego wynik można ocenić. Zapytaj, co pracownicy ukończyli, co wymagało korekty i co zmieniło się po wprowadzeniu AI do procesu. Porównaj pełny wymagany wysiłek, w tym przegląd i działania następcze. Pozostaw pytanie otwarte, gdy dowody pozostają niepełne. Epizod z budżetem AI Ubera daje powód, by wymagać takiego rozliczenia, bez zakładania, że odpowiedź musi sprzyjać ekspansji albo ograniczeniom. Zanim uznasz kolejny etap wdrożenia za wynik biznesowy, zadaj bardziej konkretne pytanie: jaka użyteczna praca osiągnęła akceptowalny standard i ile organizacja wydała, aby do tego doprowadzić?