Enterprise AI uległo zmianie. Kilka lat temu przekonanie kierownictwa do choćby przetestowania uczenia maszynowego było walką z wiatrakami. Teraz budżety istnieją. Projekty pilotażowe otrzymują zielone światło. Przypadki użycia piętrzą się w mapach drogowych. Mimo to zbyt wiele z tych projektów kończy się jako kosztowne eksperymenty, które nigdy nie zmieniają sposobu, w jaki faktycznie działa biznes. Modele są w porządku. Problemem jest wszystko inne.

Gdzie umierają projekty pilotażowe

Każdy uwielbia demo. Prototyp przewiduje odejścia klientów (churn) z niezwykłą precyzją. Zarząd przytakuje. Fundusze płyną. Potem zapada cisza. Proof of concept zostaje zatwierdzony, ale postęp staje w miejscu. Co się stało?

Zespoły biznesowe wpatrują się w pulpit nawigacyjny i nie potrafią zrozumieć, jak pasuje on do ich codziennej pracy. Potok danych (data pipeline), który zasilał model, był jednorazowym, ręcznym wyciągiem danych, nad którym nikt nie sprawuje kontroli. Zasady zgodności (compliance) zmieniają się w połowie drogi. System wymaga czystych danych wejściowych, których system CRM nigdy nie wygenerował. AI działa w notatniku (notebook). Organizacja nie wie, co z tym zrobić.

To porażka wdrożeniowa. Model o 95-procentowej dokładności może wygrać hackathon. Ale jeśli pozostałe pięć procent wywoła koszmary audytowe lub naruszenia zasad bezpieczeństwa, operacje go wyłączą. Inżynierowie świętują kamienie milowe technologii. Jednostki biznesowe czekają na rezultaty, które nigdy nie nadchodzą. Luka między nimi to miejsce, w którym umierają projekty.

Luka translacyjna

Nazwijmy to po imieniu. Kadra zarządzająca chce wzrostu przychodów lub redukcji kosztów. Operacje chcą szybkości bez chaosu. Zespoły danych chcą schematów, które mają sens. Inżynierowie chcą niezawodności (uptime) i czystych API. Żadne z tych pragnień nie pokrywa się naturalnie z innymi.

Pozostawione same sobie, każda grupa optymalizuje coś innego. Inżynier może spędzać tygodnie na skracaniu opóźnień (latency) punktu końcowego predykcji, podczas gdy zespół sprzedaży wciąż eksportuje wszystko do Excela, bo interfejs użytkownika ich dezorientuje. Naukowiec danych może obsesyjnie analizować czwarty znak po przecinku wskaźnika AUC, podczas gdy zespół magazynowy od sześciu miesięcy loguje wartości null w krytycznym polu. Nikt nie jest w błędzie. Oni po prostu mówią różnymi językami.

To niedopasowanie jest głównym powodem, dla którego AI utyka po fazie pilotażowej. To nie brak procesorów GPU. To nie brak doktorów nauk. To brak kogoś, kto potrafi usiąść między tymi grupami i zbudować wspólną rzeczywistość.

Czym właściwie zajmują się Forward Deployed Engineers

Forward Deployed Engineers są tym mostem. Nie zastępują oni Twoich naukowców danych ani inżynierów platformy. Pracują na styku biznesu, inżynierii, danych i zespołów produktowych, aby naprawić tarcie organizacyjne, które zabija technologię, zanim ta zostanie wdrożona.

Kiedy FDE wchodzi w projekt, zaczyna od zadawania niewygodnych pytań. Jak wygląda udany wtorkowy poranek osoby korzystającej z tego narzędzia? Które trzy systemy legacy faktycznie zasilają ten strumień danych? Co stanie się z procesem, jeśli model się pomyli? Przekładają odpowiedzi na decyzje techniczne, dzięki czemu zespoły nie marnują miesięcy na budowanie niewłaściwego rozwiązania.

W ramach typowego zaangażowania, FDE będzie:

  • Wyjaśniać cele z interesariuszami zamiast przyjmować niejasne wytyczne
  • Schodzić na "teren" procesu, aby znaleźć wąskie gardła, których nie wychwyci żaden bilet w Jira
  • Identyfikować zależności danych, o których zapomniała istniejąca dokumentacja
  • Przekładać te wymagania na konkretne decyzje techniczne
  • Wcześnie weryfikować założenia, często poprzez dołączenie do rozmowy z zespołem operacyjnym, który przejmie wynik pracy

FDE rozwiązują problemy organizacyjne, a nie tylko techniczne. Mogą zauważyć, że menedżer operacyjny nie ufa modelowi, ponieważ nigdy nie brała udziału w wyborze danych treningowych. W takim przypadku budują pętlę zwrotną, którą ta osoba faktycznie rozumie. Mogą dostrzec, że przepływ pracy wymaga dwóch zatwierdzeń, które nowy system ignoruje, i przeprojektowują przekazywanie zadań, zamiast na siłę wtłaczać narzędzie w wadliwy proces.

Mierz adopcję, a nie tylko dokładność

Najbardziej udane programy AI śledzą inny zestaw wskaźników. Metryki modelu wciąż są ważne, ale prawdziwe wskaźniki znajdują się dalej w procesie. Czy ludzie używają