Dlaczego pilotażowe projekty sztucznej inteligencji w przedsiębiorstwach nie osiągają produkcji: to nie model, ale oprzyrządowanie

Model nigdy nie był trudnym elementem. Od wewnątrz budowy, produkcja jest wygrana lub przegrana w warstwie wokół niego: pobieranie, ugruntowanie, routing i ocena.

Każde duże badanie sztucznej inteligencji w przedsiębiorstwach opisuje ten sam problem: organizacje mają dostęp do modeli, prowadzą pilotażowe projekty i prezentują coś imponującego, ale prawie nic z tego nie dociera do produkcji. Raporty opisują tę lukę z zewnątrz, poprzez odpowiedzi wykonawców na ankiety. To jest widok z drugiej strony: z wnętrza budowy, gdzie pilotażowe projekty albo przechodzą do produkcji, albo cichaczem umierają.

Luka, którą wszyscy mierzą

Liczby stały się znajome. Raport Deloitte o stanie sztucznej inteligencji w przedsiębiorstwach wykazał, że dostęp do sztucznej inteligencji jest już prawie powszechny, ale tylko około jednej czwartej organizacji udaje się wprowadzić do produkcji co najmniej 40% swoich eksperymentów, a około jedna na pięć raportuje dojrzałą governance dla autonomicznych agentów. Raport MIT Project NANDA stwierdził bardziej dosadnie: spośród setek wdrożeń, ogromna większość nie wygenerowała żadnych mierzalnych korzyści finansowych. Gartner przewiduje, że duża część projektów sztucznej inteligencji zostanie porzucona po etapie proof-of-concept, powołując się na słoką jakość danych, rosnące koszty i niejasną wartość biznesową.

Układając te wyniki razem, wyłania się jeden kształt. Wąskie gardło nie leży w dostępie do zdolnych modeli. Ten problem jest już rozwiązany. Wąskie gardło leży w odległości między modelem, który działa w demo, a systemem, który działa w produkcji, zawsze, dla każdego użytkownika, pod rzeczywistym obciążeniem, z rzeczywistymi konsekwencjami za błędy.

Warto zauważyć, że wiele pilotażowych projektów nie jest wdrożonych z powodów, które nie mają nic wspólnego z inżynierią: brak rzeczywistego przypadku biznesowego, brak użytecznych danych, brak sponsora wykonawczego lub całkowity koszt, który nikt nie oszacował. Odrzućmy te przypadki. To, co następuje, dotyczy dużej i frustrującej grupy pilotażowych projektów, które są technicznie realne, prezentują coś przekonywującego w demo i mają za sobą rzeczywisty przypadek biznesowy, a mimo to zatrzymują się w drodze do produkcji. Dla tych projektów decydującym czynnikiem jest prawie nigdy nie model.

To, czego nie mogą powiedzieć dane z ankiety, to co tak naprawdę zamyka tę lukę. Odpowiedź na to nie mieszka w ankiecie. Mieszka w decyzjach inżynieryjnych podejmowanych po tym, jak demo wszystkich imponuje, a przed tym, jak system jest ufań zaufany z prawdziwymi klientami.

Wzorzec: decydująca poprawka jest prawie nigdy modelem

Przez wszystkie zaangażowania w sztuczną inteligencję w przedsiębiorstwach, które możemy omówić, utrzymuje się jeden wzorzec: gdy zatrzymany pilotażowy projekt w końcu osiąga produkcję, zmiana, która go tam doprowadziła, rzadko jest lepszym modelem. Jest to warstwa wokół modelu: jak informacje są pobierane i ugruntowane, jak dane wyjściowe są sprawdzane przed tym, jak dotrą do użytkownika, jak praca jest kierowana do odpowiedniego modelu, a nie do najpotężniejszego, i jak całość jest oceniana w sposób ciągły.

Nazywamy to warstwą oprzyrządowania. Agent, w praktycznym sensie, jest modelem z dostępem do narzędzi, a oprzyrządowanie jest wszystkim, co rządzi tym, jak model pobiera kontekst, używa tych narzędzi i jest traktowany za to, co produkuje: pobieranie, ugruntowanie, routing i ocena. Te komponenty nie działają w izolacji. Trzeba je połączyć, celowo, dla konkretnego przypadku użycia. Ta połączona dyscyplina to to, co nazywamy ugruntowaniem agenta, i to jest miejsce, gdzie rzeczywista gotowość do produkcji jest wygrana lub przegrana.

To zmienia pułapkę proof-of-concept. Zespoły zatrzymują się, bo ciągle optymalizują część, która już działa. Zamieniają jeden model na nowszy, przebudowują prompty i czekają na następną wersję, podczas gdy prawdziwe punkty awaryjne siedzą warstwę dalej, w częściach systemu, które demo nigdy nie naraża.

Ugruntowanie, a nie mądrzejszy model, to to, co sprawia, że agent jest wystarczająco bezpieczny, aby go wysłać

Rozważmy asystenta rekomendacyjnego i doradczego, którego zbudowaliśmy w sektorze ubezpieczeń, dziedzinie, w której pewna, ale błędna odpowiedź nie jest błędem, ale odpowiedzialnością. Pierwsza odruch w takich przypadkach jest sięgnięcie po najbardziej zdolny dostępny model i założenie, że zdolność kupuje bezpieczeństwo. Nie robi tego. Bardziej płynny model produkuje bardziej przekonywujące halucynacje, co w regulowanym kontekście jest gorsze, a nie lepsze.

To, co sprawiło, że system był gotowy do wysłania, to było oprzyrządowanie: projekt pobierania, który pobrał tylko z zarządzanych, bezpiecznych źródeł; ugruntowanie, które zweryfikowało wygenerowane twierdzenia wobec tych źródeł przed tym, jak cokolwiek dotarło do użytkownika; i krok weryfikacji, który wolał się powstrzymać niż twierdzić coś niewspartego. Wynikiem było zmierzone zmniejszenie halucynacji o 80 do 90 procent w porównaniu z modelem LLM, z dokładnością ugruntowania powyżej 95 procent, przy zachowaniu czasu odpowiedzi poniżej dwóch sekund, tak aby warstwa bezpieczeństwa nigdy nie sprawiła, że system wydawał się wolny.

Przeciwnie do oczekiwań lekcja dla wszystkich, którzy nadal łączą bezpieczeństwo z wyborem modelu: warstwa ugruntowania i weryfikacji jest rządzeniem. Dokumenty polityczne i komitetów zatwierdzających mają znaczenie, ale nie powstrzymują modelu przed wymyślaniem faktów w czasie inferencji. Warstwa pobierania i weryfikacji oprzyrządowania tak. W naszych wdrożeniach techniczna warstwa ugruntowania jest prawdziwym mechanizmem rządzenia: miejscem, w którym „AI nie może wymyślać rzeczy” przestaje być zasadą i staje się wymuszonym właściwością systemu.

Routing modelu, a nie wybór modelu, to miejsce, w którym decyduje się o koszcie AI

Drugim miejscem, w którym pilotażowe projekty umierają, jest przegląd budżetu. System może działać pięknie i nadal być anulowany, gdy ekonomia na token, pomnożona przez tysiące użytkowników i dziesiątki przypadków użycia, staje się problemem całkowitego kosztu posiadania, którego nikt nie modelował wcześniej.

Tu również odruch, wybór jednego silnego modelu i routing wszystkiego przez niego, jest błędem. Większość obciążeń przedsiębiorstw jest mieszanką: duża część żądań jest rutynowa, a niewielka część jest prawdziwie trudna. Wysyłanie każdego żądania do modelu frontier oznacza płacenie cen frontier za pracę triażu, którą mniejszy, tańszy model obsługuje doskonale.

W migracji, którą przeprowadziliśmy z trzeciego API LLM na Amazon Bedrock , zyski pochodziły z przebudowy warstwy modelu, a nie z wymiany modelu. Routing każdego zadania do odpowiedniej warstwy modelu, połączony z kontrolami kosztów i zarządzania Bedrock, dał 42-procentową redukcję kosztów infrastruktury AI i 60-procentową szybszą generację zgodnego contenu, bez odbudowy aplikacji.

Rozszerzając ten wzorzec, staje się on kumulatywny. Architektura „doradcy” warstwowego, tanich modeli triażowych i obsługujących większość żądań, modeli frontier zarezerwowanych dla przypadków, które ich naprawdę potrzebują, zmienia routing z jednorazowego oszczędności w strukturalne.

Ten wzorzec spowodował obniżenie kosztów sztucznej inteligencji w przedsiębiorstwach o 60 do 80 procent dla operacji agenta, a nawet o 85 procent w niektórych wdrożeniach. Punktem nie jest nagłówek procentowy; jest to, że koszt systemu sztucznej inteligencji jest ustawiany przez jego architekturę, a nie przez wybrany model.

Dlaczego to jest niewidoczne w danych ankiety

Żadne z tego nie pojawia się czysto w ankiecie, bo ankiety pytają wykonawców o wyniki, a nie inżynierów o mechanizmy. „Czy Twój pilotażowy projekt osiągnął produkcję?” to pytanie, na które wykonawca może odpowiedzieć. „Co konkretnie go tam doprowadziło?” to pytanie, na które tylko zespół budowlany może odpowiedzieć, a odpowiedź jest rzadko „znaleźliśmy lepszy model”. Jest to prawie zawsze jakaś wersja „naprawiliśmy warstwę wokół modelu”.

To niezgodność wyjaśnia dziwną trwałość pułapki proof-of-concept. Przemysł nadal diagnozuje problem modelu i kupuje rozwiązania modelu, podczas gdy prawdziwe ograniczenie leży w pobieraniu, ugruntowaniu, routingu i ocenie: nieglamurującym rurach, które demo nie pokazuje i które nie są reklamowane przez żadne wprowadzenie modelu.

To również wyjaśnia, dlaczego governance i szybkość dostarczania nie są przeciwieństwami, jakimi się wydają. Powszechny narracja traktuje governance jako hamulec na wysyłanie. W naszym doświadczeniu jest to bliżej przeciwieństwa: praca ugruntowania i weryfikacji, która sprawia, że system jest zarządzalny, jest tą samą pracą, która sprawia, że jest wystarczająco godny zaufania, aby umieścić go przed prawdziwymi użytkownikami. Zrobione na poziomie oprzyrządowania, governance nie jest tym, co spowalnia budowę. Jest tym, co pozwala budowie się udać.

Co to oznacza, jeśli Twój pilotażowy projekt jest zatrzymany

Jeśli masz pilotażowy projekt sztucznej inteligencji, który siedzi w limbie proof-of-concept, najbardziej użyteczną rzeczą, którą możesz zrobić, jest oprzeć się odruchowi, aby spojrzeć na model pierwszy. Model jest częścią, która najprawdopodobniej już jest wystarczająco dobra. Spójrz zamiast tego na warstwę wokół niego:

• Pobieranie i ugruntowanie: czy system odpowiada z zarządzanych, weryfikowalnych źródeł, czy improwizuje ze swojego szkolenia?
• Weryfikacja: czy coś sprawdza dane wyjściowe przed tym, jak użytkownik je zobaczy, czy zaufanie modelu idzie prosto przez?
• Routing: czy każde żądanie płaci ceny frontier, czy praca jest dopasowana do najtańszego modelu, który może to zrobić dobrze?
• Ocena: czy jakość jest mierzona w sposób ciągły wobec własnych benchmarków, czy była zwalidowana raz w demo i nigdy więcej?

Organizacje, które przechodzą z pilotażu do produkcji w 2026 roku, nie są tymi, które mają dostęp do najlepszych modeli. Każdy ma to. Są to te, które zrozumiały, że model nigdy nie był trudnym elementem, i które położyły swój wysiłek inżynieryjny w oprzyrządowanie, gdzie produkcja jest rzeczywiście wygrana.