AI zrobi dokładnie to, co opiszesz. I właśnie w tym tkwi problem

Analitycy i architekci są dziś ostatnim bastionem ludzkości w procesie wytwarzania oprogramowania.

Model dostał zeskanowane pismo, przeczytał je i zwrócił wzorcowy JSON. Wszystkie pola były na miejscu, a składnia nie budziła zastrzeżeń. W polu z datą stał rok 3057.

Skan był zagięty, a nikt nie pomyślał, żeby sprawdzić, czy data w ogóle ma sens. System działał, tylko robił coś, co nie miało żadnej wartości.

Tę historię opowiedział Robert Buda z mBanku podczas konferencji „Analityk & Architekt w erze AI” zorganizowanej przez Andrzej Sobczak i Jan Maria Kowalski, MBA
Mówił bez marketingowych zachwytów, za to z perspektywy kogoś, kto widział, co dzieje się z projektami AI, kiedy zderzają się z rzeczywistością dużego, regulowanego banku. Kilka jego obserwacji warto zapamiętać, zanim następny prototyp trafi na produkcję.

Demo działa zawsze. Pytanie, co będzie potem

Na początku zapytał salę, kto bawił się już w vibe coding, czyli programowanie z AI na wyczucie, samymi promptami. Podniósł się las rąk. Potem zapytał, kto wdrożył coś takiego na produkcję w korporacji. Zostało kilka.

Ta różnica dobrze pokazuje, jak zwykle wygląda życie projektu z AI:

Demo. 15 minut i pięć starannie dobranych przykładów. Wszyscy są zachwyceni. PoC. Tysiąc przypadków na ręcznie oczyszczonych danych, bez integracji z czymkolwiek. „Mamy 90% skuteczności!” Średnie wyglądają dobrze i usypiają czujność. Produkcja. Brudne dane, nieaktualne repozytoria, padające integracje i użytkownicy, którzy pytają o rzeczy, których nikt nie przewidział. Tu każda pomyłka zaczyna kosztować.

Robert ujął to krótko: udane demo nie dowodzi, że system jest gotowy do działania. Na demie wszystko kontrolujemy. Na produkcji prawie nic.

Wąskie gardło właśnie się przesunęło

Przez lata projekty spowalniało tempo pisania kodu. Dziś z Claude'em, Cursorem czy Codexem da się, jak to ujął prelegent, „natrzepać” setki tysięcy linii w kilka godzin.

Tylko kto to wszystko przeczyta i sprawdzi? Człowiek nie nadąży za takim tempem.

Dlatego, wbrew obiegowej opinii, to programiści będą musieli szybciej przemyśleć swoją rolę niż analitycy. Praca analityków i architektów nie zniknie. Będzie jej więcej i będzie trudniejsza. Ktoś musi ustalić, co system ma robić. Ktoś musi też zbudować bezpieczne ramy wokół komponentu, który za każdym razem może odpowiedzieć trochę inaczej.

„Analitycy i architekci są dziś ostatnim bastionem ludzkości w procesie wytwarzania oprogramowania. Kod można wygenerować w kilka minut, ale linie kodu nie są dowodem na to, że rozwiązaliśmy właściwy problem biznesowy”.

Zakładaj, że model się pomyli

Najczęstszy błąd to wiara, że wystarczy dopracować prompt i model zacznie działać bezbłędnie.

„Największym ryzykiem nie jest to, że AI się pomyli. Każdy system ma prawo się pomylić. Największym ryzykiem jest projektowanie architektury tak, jakby AI miało się NIE pomylić”.

Z tego wynika prosty podział pracy.

Analityk odpowiada na pytanie, ile kosztuje pomyłka. Co się stanie, jeśli system błędnie coś zatwierdzi (false positive)? A co, jeśli błędnie coś odrzuci (false negative)? Na tej podstawie ustala, jakie ryzyko organizacja jest w stanie zaakceptować.

Architekt zamienia zaufanie do modelu w konkretne mechanizmy kontroli. Projektuje ścieżki awaryjne i wyłącznik bezpieczeństwa (kill switch), a także decyduje, w których miejscach procesu musi być człowiek.

100 tysięcy złotych dziennie za coś, czego nikt nie potrzebował

Wróćmy do roku 3057, bo cała historia jest jeszcze ciekawsza.

Zespół wymyślił digitalizację kancelarii. Każde przychodzące pismo miało przejść przez OCR, potem przez model językowy, a na końcu trafić do bazy jako uporządkowany JSON. Pomysł brzmiał świetnie i szybko okrzyknięto go sukcesem.

Dopiero gdy ktoś usiadł do porządnej analizy, wyszły trzy rzeczy:

Przetwarzanie kosztowałoby nawet 100 000 zł dziennie. Treść pism nie była nikomu potrzebna. Proces wymagał tylko sprawdzenia, z którego wydziału przyszło pismo, oraz wyciągnięcia imienia, nazwiska i numeru PESEL. Poprawna składnia JSON-a nic nie gwarantowała. Stąd rok 3057.

Prompt może zrealizować fragment wymagania, ale nie zastąpi pytania, czy to wymaganie w ogóle ma sens. To, że model coś potrafi przetworzyć, nie znaczy, że firma tego potrzebuje.

Najcenniejsza odpowiedź to „nie wiem”

RAG, czyli model odpowiadający na podstawie firmowych dokumentów, na etapie PoC wygląda jak magia. Zadajesz pytanie, dostajesz odpowiedź i źródło.

Na produkcji zaczynają się jednak pytania, których na demie nikt nie zadał:

Skąd model ma wiedzieć, że procedura z jednego folderu obowiązuje do kwietnia, a od maja zastępuje ją nowe zarządzenie? Co zrobi, gdy znajdzie dwa sprzeczne dokumenty? Co, jeśli odpowiedzi w bazie po prostu nie ma?

Model w takiej sytuacji zwykle chce pomóc za wszelką cenę, więc wymyśla odpowiedź, która brzmi bardzo przekonująco. Dlatego system trzeba zaprojektować tak, żeby umiał powiedzieć „nie wiem”. Jeśli nie ma wiarygodnego źródła, odmowa jest jedyną poprawną odpowiedzią.

Człowiek w pętli to nie przycisk „Akceptuj”

O human-in-the-loop mówi się chętnie. W praktyce często kończy się na tym, że pracownik klika „zatwierdź” pod kolejną podpowiedzią AI, nie bardzo wiedząc, co zatwierdza.

Robert Buda wyróżnił trzy poziomy autonomii:

System podpowiada. Daje propozycję i źródła, a człowiek sam analizuje i decyduje. System przygotowuje. Wykonuje całe zadanie, a człowiek je zatwierdza. Tu najłatwiej o bezrefleksyjne klikanie. System wykonuje. Działa samodzielnie, ale tylko w procesach powtarzalnych, odwracalnych i bezpiecznych.

Reguła jest prosta. Im poważniejsze skutki decyzji i im słabsza automatyczna kontrola, tym mniej swobody dla modelu. Przy decyzjach, których nie da się cofnąć, człowiek nie może być tylko formalnością na końcu procesu.

Czasem wystarczą trzy ify

Na koniec historia, która rozbawiła salę, choć jej bohaterom pewnie nie było do śmiechu.

Biznes przyszedł z pomysłem na zaawansowanego agenta AI, który miał automatyzować skomplikowany proces decyzyjny. Zespół przez trzy miesiące analizował ścieżki decyzyjne, reguły scoringowe, historię transakcji i wymogi prawne.

Wynik? Cały problem dał się rozwiązać trzema warunkami if/else. Działają w ułamku milisekundy, nie kosztują nic w tokenach i za każdym razem dają ten sam wynik.

Model językowy to tylko jedna z bibliotek w systemie, a nie cały produkt. Jeśli problem rozwiązuje prosta reguła, dokładanie do niego LLM-a tylko po to, żeby „mieć AI”, jest zwyczajnym błędem inżynierskim.

Sześć pytań przed wdrożeniem

Na koniec prelegent zostawił listę pytań, na które zespół powinien znać odpowiedź, zanim system z AI trafi na produkcję:

Czy cel i granice procesu są jasne? Wiemy, co model ma robić i czego nie wolno mu robić? Czy źródła danych mają właścicieli? Kto dba o to, żeby wiedza modelu była aktualna? Czy testujemy trudne przypadki? Uszkodzone dane, nietypowe pytania, próby oszukania systemu. Czy wiemy, jaka jakość jest wystarczająca? Nie ogólne „90% skuteczności”, tylko akceptowalny koszt pomyłki. Co się dzieje, gdy coś pójdzie nie tak? Czy błąd albo halucynacja mają bezpieczną ścieżkę obsługi? Kto odpowiada za system po starcie? Kto pilnuje jakości odpowiedzi i sprawdza, co się zmieniło po aktualizacji modelu?

Odpowiedź „nie” na któreś z tych pytań nie musi zatrzymywać projektu. Oznacza jednak, że trzeba od razu dobudować zabezpieczenia.

A gdyby biznes po prostu zapytał agenta?

W dyskusji po wystąpieniu Jan Maria Kowalski, MBA zadał przekorne pytanie: co, jeśli biznes sam weźmie agenta AI i odpowie sobie na te wszystkie pytania, bez analityka i architekta?

Odpowiedź dotyczyła czegoś, co zna każdy, kto pracował w dużej firmie. Najważniejsza wiedza o systemach nie siedzi w dokumentacji, tylko w głowach ludzi. To tak zwana wiedza plemienna (tribal knowledge).

Biznes wie, czego chce, ale zwykle nie zna zależności w starych systemach, powiązań między bazami ani ukrytych ograniczeń regulacyjnych. Agent, który dostanie tylko życzenia biznesu, zaproponuje rozwiązanie bez związku z tym, jak firma naprawdę działa. Analityk i architekt są po to, żeby zadać niewygodne pytania, zanim ktoś wyda 100 tysięcy dziennie na odczytywanie dat z przyszłości.

Ciekaw jestem Waszych doświadczeń:

Jak u Was wygląda przejście od efektownego PoC do produkcji? Czy Wasz system AI może powiedzieć „nie wiem”? Na którym poziomie autonomii działają Wasze wdrożenia AI?