Gorset czy egzoszkielet? Agenci AI w projekcie, którego nie wolno zepsuć

Dostarczcie system cztery razy szybciej niż zwykle.

Bez nowych ludzi, bo samo ich wdrożenie trwałoby dłużej niż cały projekt. W farmacji, gdzie nie ma dróg na skróty, bo każdy błąd może wpłynąć na zdrowie i życie pacjentów. I w systemie, który trzeba w całości zwalidować.

Takie zadanie dostali Marta Wołkowska i Marcin Dybowski z Roche. Na konferencji „Analityk & Architekt w erze AI” opowiedzieli, jak je wykonali.

Zapowiadając ich, przyznałem, że sam ciągle szukam odpowiedzi na pytanie, jak wdrażać AI w branżach regulowanych. To nie jest oczywiste ani proste.

Wóz z jednym koniem

Marta pokazała to obrazowo. Zwykły proces wytwarzania oprogramowania jest jak wóz z jednym koniem: dowiezie towar, ale ma swoje ograniczenia. Żeby jechać cztery razy szybciej z tym samym ładunkiem, potrzeba więcej koni, czyli kwadrygi.

Nowych ludzi zespół zatrudnić nie mógł. Zatrudnił więc cyfrowych asystentów, którzy stali się dodatkowymi końmi pociągowymi.

Była w tym też, jak to ujęła Marta, „malutka incepcja”: zespół użył agentów AI do zaprojektowania i zbudowania systemu, który sam jest systemem agentowym.

Co budowali

Projekt dotyczył zarządzania odchyleniami (deviation management). W farmacji to obszar kluczowy. Pytanie o niego pada na każdym audycie i każdej inspekcji.

Marta wyjaśniła dlaczego. Wszystko działa świetnie, dopóki idzie zgodnie z planem. To, jak firma radzi sobie, kiedy dzieje się coś nieprzewidzianego, pokazuje prawdziwy stan jej procesów.

Zespół dostał na to cztery miesiące. A ponieważ to proces GxP, cały system musiał przejść walidację.

Gorset, który stał się egzoszkieletem

GxP to zbiór zasad i dobrych praktyk, których celem jest bezpieczeństwo pacjentów i integralność danych. Trzeba udowodnić, że system zawsze daje prawidłowe wyniki, cokolwiek się dzieje.

Łatwo pomyśleć o tym jak o gorsecie, który uciska, nie daje oddychać i spowalnia. Zespół podszedł do tego inaczej. Potraktował zasady GxP jak egzoszkielet: coś, co chroni przed potknięciem i pozwala poruszać się po nieznanym terenie. A nieznanym terenem były właśnie systemy agentowe.

Granice, których nie można przekroczyć:

• Plan testów: zanim cokolwiek się wdroży i przetestuje, zakres testów musi być formalnie zatwierdzony.
• Ślad audytowy: przy każdej czynności w systemie wiadomo, kto, kiedy i dlaczego ją wykonał.
• Identyfikowalność: pełna ścieżka od wymagania biznesowego, przez wdrożenie, po testy i ich dowody.
• Kontrolowana zmiana: niczego nie można zmienić bez formalnego zatwierdzenia.
• Dowody z testów: trzeba udowodnić i zarchiwizować, że wszystko zostało przetestowane.

Zespół miał przy tym wsparcie eksperta od walidacji.

ADR-y jako tory

Marcin wrócił do metafory kwadrygi. Woźnica, czyli on i programiści, pracuje naraz z kilkoma agentami. To szybka jazda z wiatrem we włosach, ale wymaga umiejętności i dobrego zaprzęgu. A ważniejszy od prędkości jest właściwy kierunek.

Kierunek wyznaczało dość stare narzędzie, o którym mówili już wcześniejsi prelegenci: rejestr decyzji architektonicznych (ADR).

Marcin użył drugiej metafory. Cały proces wytwarzania oprogramowania jest jak pociąg, a ADR-y to tory. Jeśli tory są dobrze zbudowane, pociąg nie ma jak zjechać z nich i wjechać w pole. Jeśli decyzje architektoniczne są zatwierdzone przez człowieka, wyniki pracy agentów są powtarzalne i dobrej jakości.

Każdy ADR miał uzasadnienie: dlaczego wybrano takie rozwiązanie i w jakim kontekście. To był bardzo dobry materiał dla agentów. ADR-y powstawały na dwóch poziomach: związane ze strategią firmy i związane z konkretną aplikacją.

Zasada jest jedna:

„Agent nie wymyśla architektury. Porusza się w granicach zatwierdzonych przez człowieka”.

Skille na każdym etapie

Samo pisanie ADR-ów też zajmuje sporo czasu. Pomogły w tym gotowe i własne rozszerzenia dla agentów (skille). Jedno z nich, GrillMe, prowadziło Marcina za rękę: zadawało pytania i zapisywało kluczowe ustalenia, które potem przeglądał.

Na każdym etapie projektu agenci mieli odpowiednie skille:

• wymagania: uporządkowana rozmowa o wymaganiach, ustalanie priorytetów, planowanie,
• projekt: doprecyzowanie dziedziny, specyfikacja funkcjonalna i prototyp w trzy dni,
• implementacja: testy pisane przed kodem, dzielenie zadań, przekazywanie kontekstu między agentami,
• przegląd: sprawdzanie kodu pod kątem testów, diagnozowanie błędów, automatyczny raport.

Całość działała w chmurze AWS.

Pętla czy uprząż

Najważniejsze rozróżnienie architektoniczne, jakie zespół musiał wprowadzić, dotyczyło tego, jak działa sam agent.

Pętla agenta (agent loop): agent sam decyduje o kolejnych krokach. Każde uruchomienie może wyglądać inaczej, trudno to zaaudytować, a człowieka w procesie nie ma. To świetne do eksperymentów, ale w walidowanym systemie nie do przyjęcia.

Uprząż (agent harness): człowiek ustala z góry kroki w wyznaczonym obszarze. Przebieg jest powtarzalny, wszystko jest zapisywane (kto, kiedy, co weszło i co wyszło), a po drodze są punkty, w których człowiek musi zatwierdzić wynik.

W farmacji pętla to zbyt duże ryzyko. Agent w uprzęży nie zrobi kroku, którego człowiek wcześniej nie zaprojektował.

Najpierw model myślowy, potem prompt

Do weryfikowania architektury Marcin używa modeli myślowych, inspirowanych książką Shane’a Parrisha The Great Mental Models. Zamiast zaczynać od promptu, zaczyna od sposobu myślenia:

• Drzwi jedno- czy dwukierunkowe? Jeśli decyzję łatwo odwrócić, nie trzeba tracić czasu, agent może po prostu wygenerować kod jeszcze raz. Jeśli nie da się jej odwrócić, trzeba się zatrzymać i przemyśleć ją głębiej.
• Myślenie drugiego rzędu: jakie konsekwencje przyniesie ta decyzja za jakiś czas, a nie tylko teraz?
• Inwersja: co mogłoby pójść nie tak? Trzeba znaleźć przyczyny potencjalnej katastrofy i usunąć je zawczasu.

Te modele zespół zamienił w wytyczne dla agentów. Dzięki temu mniej ryzykuje, że projekt polegnie na audycie.

Kiedy w połowie zmienia się zakres

Marcin opowiedział o trzech wyzwaniach.

Pierwsze to przekonanie zespołu. Pomógł model akceptacji technologii (TAM) Freda Davisa. Ludzie zaczynają korzystać z nowego narzędzia, kiedy widzą, że jest użyteczne i łatwe w użyciu. Jeśli programista widzi, że agent naprawdę zdejmuje z niego żmudną robotę, zaczyna z niego korzystać.

Drugie to awarie. Agenci potrafią nagle przestać działać, więc trzeba mieć gotowe rozwiązania zastępcze.

Trzecie to zmiana zakresu w trakcie projektu. Marta przyznała, że nie ma projektu bez takich zmian. W zwykłym procesie GxP zmiana na tym etapie oznaczałaby koniec projektu, bo formalne przepisanie dokumentacji zjadłoby cały pozostały czas.

Tym razem agent szybko przeanalizował wpływ zmiany na wymagania, znalazł zmienione przypadki użycia i powiązane zadania, a potem zaktualizował dokumentację, macierz identyfikowalności i scenariusze testów. Programiści wdrożyli zmianę zgodnie ze zaktualizowanymi ADR-ami.

Z dokumentalisty weryfikator

Marta opowiedziała, jak zmieniła się jej praca:

„Z dokumentalistów staliśmy się weryfikatorami”.

Agent przejął „archeologię systemową”, generowanie formalnej dokumentacji, pilnowanie spójności i aktualizowanie macierzy identyfikowalności. Marta przyznała, że nie cierpiała tej części pracy i cieszy się, że agent ją przejął.

Przy człowieku zostały relacje, empatia, czytanie między wierszami i odkrywanie potrzeb, których biznes nie wypowiedział. I przede wszystkim sprawdzenie wyniku i ostateczny podpis.

Żeby pokazać, dlaczego to takie ważne, Marta zacytowała fragment listu ostrzegawczego amerykańskiej agencji FDA do innej firmy farmaceutycznej. Inspektorzy wykryli brak walidacji procesu produkcyjnego. Firma tłumaczyła się, że do tworzenia dokumentacji użyła agenta AI, a ten nie powiedział jej, że taki krok walidacji jest wymagany. Według Marty firma została zamknięta.

Wniosek jest prosty: tłumaczenie „model mi nie powiedział” w branży regulowanej to droga do katastrofy. Człowiek musi wziąć pełną odpowiedzialność i podpisać się pod wynikiem.

Architekt projektuje granice

Według Marcina architekt staje się projektantem granic. Ustala ramy technologiczne: ADR-y, dozwolone biblioteki i wzorce. Dba o środowisko pracy: prompty, zabezpieczenia, pipeline’y. Sprawdza też wyniki, między innymi z pomocą modeli, które oceniają pracę innych agentów (LLM-as-a-judge), przeglądów kodu i kontroli zgodności z architekturą.

Sama aplikacja staje się „żywym systemem”. Ma pełny ślad audytowy, nocne testy automatyczne, modele oceniające pracę agentów, pętle informacji zwrotnej i przełączniki funkcji. Wyniki nocnych testów rano trafiają do agentów jako materiał do kolejnych poprawek.

Trzy rzeczy do zapamiętania

Marcin zostawił salę z trzema radami:

1. Zapisuj ADR-y. Zanim wpuścisz agenta do kodu, wyznacz mu granice w zatwierdzonych decyzjach architektonicznych.
2. Nazwij swój sposób myślenia. Korzystaj z modeli myślowych: drzwi jedno- i dwukierunkowych, myślenia drugiego rzędu, inwersji.
3. Zamień model myślowy w skill. Powtarzalny sposób myślenia przekształć w narzędzie dla agenta.

„Zacznij nie od promptu, tylko od modelu myślowego. Potem zamień go w skill. Wtedy dobre myślenie staje się powtarzalne”.

Pytania z sali

„No dobra, wdrażajcie AI w chmurze publicznej”? Marcin wyjaśnił, że zespół korzysta z modeli językowych uruchomionych w odizolowanej infrastrukturze firmy, wyłącznie na jej potrzeby.

A co na to compliance? Marta przyznała, że byli w firmie „królikami doświadczalnymi”. Najpierw wdrożyli pierwsze zwalidowane rozwiązanie z asystentem AI, a potem, jako pierwsi w firmie, pierwsze zwalidowane rozwiązanie agentowe. Compliance było dla nich prawdziwym partnerem. Na ich przykładzie wspólnie budowali zasady walidacji AI i pisali procedury. Kosztowało to dziesiątki spotkań, ale obie strony zrozumiały, że nie mogą być dla siebie wrogami.