Dlaczego projekty Agentic AI zatrzymują się w skali i co przedsiębiorstwa muszą najpierw naprawić

Agentic AI staje się coraz bardziej istotnym elementem wszystkich przedsiębiorstw. Firmy włączają pilotażowe projekty do swoich operacji, środowiska demonstracyjne imponują kierownictwu, a plany są przebudowywane wokół autonomicznych przepływów pracy AI.

Jednak dla wielu z tych projektów coś się łamie między kontrolowanym demo a wdrożeniem produkcyjnym. Projekt zatrzymuje się, wdrożenia rozciągają się z miesięcy na lata, a zespoły odpowiedzialne za dostarczanie są zmuszone wyjaśniać, dlaczego agent, który działał idealnie w teście, zachowuje się nieprzewidywalnie w świecie rzeczywistym.

W niemal każdym przypadku odpowiedź nie leży w samym modelu, ale w danych, warstwie orkiestracji, ramach zarządzania i infrastrukturze dziedzictwa, której większość przedsiębiorstw nie zmodernizowała przed zbudowaniem inteligentnych agentów na jej podstawie. Dopóki te podstawy nie zostaną naprawione, agentic AI będzie nadal produkował demo, które imponuje, i wdrożenia, które zawodzą.

Środowisko POC to pułapka

Większość przedsiębiorstw ocenia modele. O wiele mniej ocenia zachowanie agenta od początku do końca. Model może być bardzo dokładny, a agent zbudowany na jego podstawie może nadal zawieść. Jest to spowodowane tym, że agenci łączą wywołania narzędzi sekwencyjnie, a jeden zły krok powoduje błędną odpowiedź, którą następny krok traktuje jako poprawne dane wejściowe, powodując błąd w dół strumienia przed tym, jak ktokolwiek zauważy.

Środowisko proof-of-concept jest zaprojektowane, aby ukryć to. Dane wejściowe są kontrolowane, zakres jest wąski, a ktoś obserwuje dane wyjściowe. Żadne z tych warunków nie istnieje w produkcji. Agent, który uzyskał dobre wyniki w teście, teraz obsługuje niejednoznaczne instrukcje, napotyka błędy uprawnień i podejmuje decyzje sekwencyjne na podstawie danych, których nie testowano. Zespół, który go zbudował, odkrywa, że ramy oceny zaprojektowane dla wydajności modelu nie mówią, czy agent eskalował poprawnie, obsłużył przypadki brzegowe w sposób elegancki, czy wiedział, kiedy przestać.

Według raportu McKinsey’s State of AI 2025, 88% organizacji używa już AI w co najmniej jednej funkcji biznesowej, jednak tylko około jednej trzeciej z nich udało się skalować ją w całym przedsiębiorstwie. Przełom między przyjęciem a skalą zaczyna się od tego, jak przedsiębiorstwa definiują i oceniają swoje pilotażowe projekty. Zespoły, które skalują się pomyślnie, traktują analizę trybu awaryjnego jako wymóg projektowy. Przed wdrożeniem budują katalog, w jaki sposób agent ma zawieść i jaka jest odpowiedź, gdy tak się stanie. To brzmi oczywiście. Bardzo niewiele przedsiębiorstw tak naprawdę to robi.

Śmieciowe dane, śmieciowi agenci

Przedsiębiorstwa ciągle pytają, dlaczego ich agenci nie radzą sobie w produkcji. Odpowiedź niemal zawsze sprowadza się do danych. Stan danych nie był gotowy. Źródła były rozproszone po dziesiątkach systemów zbudowanych w różnym czasie i dla różnych celów. Definicje były niejednolite w różnych jednostkach biznesowych. Nie było warstwy semantycznej. Nie było jednego źródła prawdy. Było tylko lata nagromadzonych długów danych, których nikt nie priorytetował, bo stare systemy działały wystarczająco dobrze.

Ten dług nie zniknie, gdy zbudujesz agenta na jego podstawie. Staje się on rzeczywistością operacyjną agenta. Agent nawigujący po fragmentowanych źródłach danych nie powoduje rozumnego obrazu biznesu. Robi wszystko, co może, z tym, co znajdzie, godząc sprzeczności na bieżąco i produkując dane wyjściowe, które wyglądają prawdopodobnie, dopóki ktoś, kto zna biznes, nie spojrzy bliżej. Agent nie jest uszkodzony. Dane, które otrzymał, były uszkodzone przed rozpoczęciem projektu.

Dryft danych i dryft pojęć jeszcze to pogarszają z czasem. Gdy rozkład danych wejściowych w świecie rzeczywistym odbiega od tego, na którym model został wyszkolony, agent nie generuje błędu. Kontynuuje działanie i zaczyna generować błędne dane wyjściowe, pewnie i na dużą skalę. Bez potoku MLOps lub AIOps zintegrowanego z warstwą orkiestracji agenta, nie ma mechanizmu, aby to złapać, zanim szkoda się skumuluje. Agent, który działał akceptowalnie przy starcie, cicho degraduje przez tygodnie, zanim ktoś połączy jakość danych wyjściowych z problemem danych, który był od samego początku.

Modernizacja danych i modernizacja AI są często traktowane jako równoległe strumienie pracy, sekwencjonowane niezależnie i finansowane oddzielnie. Nie są one równoległe. Nie można zbudować godnego zaufania agenta na podstawie architektury danych, która była uszkodzona przed rozpoczęciem projektu. Kolejność jest ogromnie ważna, a pominięcie warstwy danych, aby szybciej ruszyć z warstwą AI, jest jednym z najczęstszych i najdroższych błędów, jakie popełniają przedsiębiorstwa.

Błędny dashboard daje komuś błędną liczbę. Błędna akcja agenta może spowodować uruchomienie procesu w dół strumienia, zanim ktoś zauważy, zatwierdzając fakturę, która nie powinna być zatwierdzona, kierując flagę zgodności w sposób nieprawidłowy lub dostosowując ceny poza zamierzonym zakresem. Systemy agenticzne potrzebują specjalnie zaprojektowanej obserwowalności, a nie ponownie wykorzystywanych dashboardów z ogólnego monitorowania aplikacji.

Zaleta zjednoczonej platformy danych

Przedsiębiorstwa, które przeniosły się do zjednoczonej platformy danych przed rozpoczęciem swoich programów agentic AI, skalują szybciej niż te, które tego nie zrobiły. Gdy Lakehouse, magazyn danych, model semantyczny i potoki wszystkie mieszczą się w jednym środowisku, jak to ma miejsce w Microsoft Fabric, agenci mają jedną spójną powierzchnię do zapytania. To usuwa całą klasę błędów, które pochodzą od agentów skaczących między systemami o różnych schematach, różnych cyklach odświeżania i różnych definicjach tego samego wskaźnika biznesowego.

To jest powodem, dla którego platformy, które przedsiębiorstwa wybierają do ujednolicenia danych, mają tak duże znaczenie dla wyników ich agentic AI. Zjednoczone podejście Microsoft Fabric łączy Lakehouse, magazyn danych, model semantyczny i potoki w jednym środowisku, dając przedsiębiorstwom zorientowanym na Microsoft (MSFT ) strukturalną przewagę przy przechodzeniu od eksperymentowania do prawdziwego użycia operacyjnego.

Databricks dostarcza to samo założenie poprzez architekturę Lakehouse i Unity Catalog, dając zespołom danych i AI ujednoliconą warstwę zarządzania na strukturalnych i niestrukturalnych danych z integracją MLflow do śledzenia zachowania modelu w produkcji. Snowflake wykorzystuje Cortex AI i ścisłe powiązanie między chmurą danych a inferencją AI, pozwalając przedsiębiorstwom na uruchamianie obciążeń agentów bezpośrednio na zarządzanych, żywych danych bez opóźnień i ryzyka spójności, które pojawiają się przy przenoszeniu danych między systemami.

Każda z tych platform reprezentuje inny ścieżkę do tego samego wyniku. Warstwa danych, która jest spójna, obserwowalna i godna zaufania, aby wspierać podejmowanie decyzji przez agenta na dużą skalę. Prawidłowy wybór zależy od istniejącego stosu przedsiębiorstwa. To, co nie jest opcjonalne, to podjęcie tego wyboru i zaangażowanie się w niego przed zbudowaniem warstwy agenta na górze. To, co różni zespoły, które robią postępy, od tych, które wciąż są zakleszczone w pilotażu, nie jest tym, którą platformę wybrali. To to, że najpierw naprawili warstwę danych.

Zarządzanie przed, a nie po

Zarządzanie zbudowane po fakcie nie jest zarządzaniem w ogóle. Gdy agent ma władzę podejmowania decyzji w dół strumienia i barierki są dodawane sześć miesięcy po wdrożeniu, przedsiębiorstwo już nagromadziło sześć miesięcy nieaudytowanych decyzji. Ślad audytowy musi być zaprojektowany przed wdrożeniem agenta, a nie przerobiony po pierwszym incydencie.

To samo zasada dotyczy bezpieczeństwa AI, kontroli dostępu opartej na rolach i określania uprawnień. Agent bez właściwie określonych uprawnień może uzyskać dostęp do danych, których nie powinien, wykonać akcje poza zamierzonym zakresem lub stać się aktywną powierzchnią ataku. To są ryzyka, które muszą być rozwiązane na etapie rozwoju, a nie odkryte podczas przeglądu wdrożenia.

Jeśli zarządzanie nie jest wbudowane przed zbudowaniem potoków szkoleniowych, niepoprawne lub wrogie dane mogą wejść do procesu szkolenia niezauważone. Model wyszkolony na kompromitowanych danych radzi sobie dobrze w benchmarkach, ale dryfuje w produkcji, dokładnie ten rodzaj cichej awarii, który jest najbardziej niebezpieczny, gdy decyzje agenta mają realne konsekwencje biznesowe.

Unijny akt AI i rosnące ramy regulacyjne wokół odpowiedzialności AI sprawiają, że trudniej jest to ignorować, a przedsiębiorstwa, które nie zbudowały zarządzania w swoich architekturach agentów, gromadzą ekspozycję zgodności, która będzie znacznie droższa do rozwiązania później.

Od pilota do produkcji: Co to naprawdę wymaga

Przedsiębiorstwa, które zamykają lukę produkcyjną, są tymi, które naprawiają warstwę danych przed zbudowaniem warstwy agenta. Wbudowują zarządzanie w projekt, a nie po szkodzie. Budują obserwowalność w architekturze orkiestracji i prowadzą zarządzanie zmianą w parze z dostawą techniczną. Traktują analizę trybu awaryjnego jako ważny wymóg projektowy.

Badanie Deloitte na temat przedsiębiorstw AI pokazuje, że dostęp pracowników do AI wzrósł o 50% w 2025 roku samym i udział firm, które uruchamiają ponad 40% swoich projektów AI w pełnej produkcji, ma się podwoić w ciągu najbliższych sześciu miesięcy. Przedsiębiorstwa, które teraz wygrywają, nie są tymi z najbardziej zaawansowanymi modelami. Są to te, które zbudowały infrastrukturę operacyjną do uruchamiania AI w sposób niezawodny i zrobiły to przed zbudowaniem agentów.

Każde przedsiębiorstwo, które wciąż prowadzi rozłączone pilotaże, powinno się skoncentrować na zapewnieniu, że inwestycja w modele i interfejsy jest proporcjonalna do inwestycji w gotowość danych i architekturę zarządzania, które określą, czy ci agenci kiedykolwiek wyjdą poza środowisko demonstracyjne. To jest miejsce, w którym wiele przedsiębiorstw zawodzi.

Dopóki się to nie zmieni, wiele projektów agentic AI, w które firmy zainwestowały środki i liczyły, że przyniosą owoce, umrze na korzeniach.