Przejdź do treści
Wróć do bloga
AIAgenci AIAutomatyzacjaCase Study

30+ ról AI w firmie. Czego ta liczba jeszcze nie udowadnia

|10 min czytania|Mateusz Dudek

Mam w firmie system ponad 30 wyspecjalizowanych ról i workflow AI. To brzmi dobrze w prezentacji, tylko że sama liczba nie odpowiada na najważniejsze pytanie: czy firma dzięki temu działa lepiej i rzadziej wraca po ratunek do właściciela?

Te role wspierają sprzedaż, maile, dokumenty, zamówienia, realizację, finanse i serwis w Sundek Energia. Część z nich analizuje dane, część przygotowuje materiał do decyzji, a część pilnuje kolejnych kroków. Mówienie o 30 autonomicznych pracownikach byłoby nadużyciem, bo są to opisane zakresy odpowiedzialności, instrukcje, skrypty i bramki działające w konkretnym procesie firmy.

Przez długi czas patrzyłem głównie na to, co udało mi się zbudować. Teraz interesuje mnie trudniejszy pomiar: co działa bez mojego udziału, co wraca do mnie jako wyjątek i czy system potrafi bezpiecznie się zatrzymać, gdy źródła są niepełne.

Liczba agentów jest inwentarzem, a nie wynikiem biznesowym

Można zbudować efektowną mapę agentów, automatyczne raporty i dziesiątki integracji, a właściciel nadal będzie zatwierdzał każdą ważną sprawę. W takim układzie technologia przyspiesza przygotowanie pracy, ale zależność firmy od jednej osoby pozostaje.

Dlatego oddzielam dziś trzy poziomy dowodu:

  1. System istnieje: role mają zakres, źródła, logi i testy.
  2. System podejmuje poprawne decyzje: wynik jest sprawdzany na realnych przypadkach, także tych problematycznych.
  3. Firma działa lepiej: spada liczba spraw wracających do właściciela, czas obsługi wyjątków albo liczba spraw bez ownera i następnego kroku.

Pierwszy poziom mam dobrze udokumentowany. Drugi mierzę coraz dokładniej. Trzeci wymaga porównywalnego punktu wyjścia i czasu. Nie chcę dopisywać oszczędności godzin, których jeszcze nie zmierzyłem.

Contract Gate: mała bramka przed dużą automatyzacją

Jednym z procesów, które ostatnio zbudowałem, jest Contract Gate. To bramka sprawdzająca, czy pakiet po podpisaniu umowy ma wystarczająco spójne dane i dokumenty, aby można było bez zgadywania uruchomić kolejne procesy.

Gate sprawdza między innymi projekcję danych, potwierdzenie podpisu, wymagane pola, zgodność podstawowych danych z PDF oraz gotowość dla kolejnych obszarów. Pracuje w trybie read-only. Nie zmienia statusów, nie wysyła wiadomości, nie wystawia faktur, nie składa zgłoszeń i nie zamawia materiałów.

Pilot objął 50 historycznych przypadków: 29 lokalnych projekcji i 21 spraw odczytanych z ClickUp. Wynik wyglądał tak:

MetrykaWynikCo oznacza
Przypadki50Zamknięty zbiór historyczny, bez czekania na 50 nowych umów
PASS4Pakiet przeszedł ogólną bramkę techniczną; gotowość CRM, finansów, OSD i zakupów jest oceniana osobno
BLOCK46System znalazł brak lub niespójność i odmówił dalszego działania
Działania zewnętrzne0Cały pilot pozostał w trybie obserwacji

Wysoka liczba blokad nie znaczy, że 46 umów było nieważnych. Oznacza, że w 46 przypadkach system nie miał wystarczająco spójnego, udokumentowanego stanu, żeby kolejny automat mógł bezpiecznie ruszyć dalej.

Najcenniejszą odpowiedzią bywa BLOCK

W automatyzacji łatwo nagradzać system za to, że coś zrobił. W realnej firmie równie ważna jest odmowa działania. Brak ulicy, niejednoznaczny podpis, sprzeczna wersja zakresu albo brak kanonicznej projekcji to sygnały, przy których system powinien poprosić człowieka o uzupełnienie danych.

W osobnym wewnętrznym audycie sprawdziłem wszystkie 4 przypadki oznaczone jako PASS oraz warstwową próbę 10 przypadków BLOCK. W tej próbie audyt potwierdził 4/4 prawdziwe PASS i 10/10 prawdziwe BLOCK, bez fałszywej zgody i bez fałszywej blokady. To dobry wynik dla tej konkretnej próbki. Nie traktuję go jako gwarancji na każdy przyszły przypadek, dlatego system nadal działa w trybie obserwacji.

Sam przegląd wykrył też błędy w mapowaniu historycznych pól, na przykład różne formaty kwot, VAT i adresów. Decyzje PASS/BLOCK były poprawne, ale część kodów diagnostycznych była nadmiarowa. Poprawiłem mapowanie, dodałem wersję silnika do fingerprintu i przeliczyłem lokalne pakiety. Testowanie systemu ujawniło więc także problem w samym systemie.

Sześć spraw pokazało problem większy niż model AI

Kolejny test odtworzył pełną ścieżkę dla 6 istniejących zadań: pobranie taska, subtasków, komentarzy, odpowiedzi i załączników z ClickUp, zbudowanie pakietu oraz decyzję gate.

Contract Gate poprawnie ocenił dane, które pobrał: 2 przypadki były prawdziwym PASS, a 4 prawdziwym BLOCK. Jednocześnie porównanie z lokalnym Atlasem pokazało coś ważniejszego:

  • tylko 3 z 6 statusów zgadzały się z lokalną referencją,
  • 0 z 6 projekcji biznesowych było identycznych,
  • tylko 1 z 6 zestawów PDF był identyczny.

Logika gate działała, ale źródła opisywały różne wersje tej samej sprawy. Agent nie powinien wtedy sam zgadywać, czy wygra Atlas, ClickUp, nowszy plik albo ostatni komentarz. Potrzebny jest jawny alarm o rozjechaniu źródeł i człowiek odpowiedzialny za rozstrzygnięcie.

To doświadczenie zmieniło moje podejście. Coraz częściej największym problemem automatyzacji nie jest jakość odpowiedzi modelu. Problemem jest brak jednej, aktualnej wersji prawdy.

Pięć zasad, których trzymam się po tym teście

  1. Najpierw definiuję stan gotowy. PASS musi oznaczać konkretną gotowość danych, a nie ogólne wrażenie, że „chyba jest dobrze”.
  2. Shadow mode poprzedza zapis. System najpierw czyta, buduje pakiet i raportuje. Write-back, wysyłka, pieniądze oraz zobowiązania dostają osobną bramkę.
  3. Brak danych jest wynikiem. Agent ma pokazać, czego nie wie, zamiast wypełniać lukę najbardziej prawdopodobną odpowiedzią.
  4. Źródła mają właścicieli. Trzeba ustalić, gdzie żyje dana informacja i kto odpowiada za jej aktualność.
  5. Wartość mierzę poza liczbą agentów. Liczą się sprawy bez ownera, powroty do właściciela, czas obsługi wyjątku, jakość danych i wynik procesu.

Co sprawdzam przez kolejne 90 dni

Contract Gate jest pierwszym dowodem technicznym, ale nie zamyka pytania o autonomię firmy. W kolejnym etapie wybieram jeden proces i mierzę, ile spraw wraca do mnie po decyzję, ratunek albo ręczne szukanie informacji. Chcę też zobaczyć, czy ten sam sposób pracy da wartość w firmie spoza Sundek.

Plan jest prosty: dokończyć pomiar we własnej firmie, przeprowadzić rozmowy z właścicielami firm instalacyjnych i usługowo-technicznych, zrobić maksymalnie kilka audytów beta, a potem wdrożyć jeden proces u zewnętrznego klienta z zapisanym stanem przed i po.

Jeżeli wynik będzie słaby, pokażę go razem z przyczyną. Budowanie publicznie ma dla mnie sens tylko wtedy, gdy obejmuje też blokady, błędy i rzeczy, których system jeszcze nie potrafi.

Masz firmę, w której większość wyjątków nadal wraca do Ciebie?

W Systemie Właściciela zaczynam od jednego wąskiego gardła, źródeł prawdy i następnego mierzalnego kroku. Nie trzeba od razu budować agentów. Czasem pierwszym wdrożeniem jest poprawa statusów, odpowiedzialności albo danych w ClickUp.

Więcej o architekturze znajdziesz w artykule jak połączyć ClickUp z AI bez oddawania kontroli, a zakres działających systemów i ich ograniczenia opisuję w case studies.


MD

Mateusz Dudek

Przedsiębiorca i builder. Firmy oraz produkty wspierane przez AI

Prowadzę Sundek Energia i współtworzę MasterZone. Buduję oraz sprawdzam systemy AI na realnych procesach firmy, a publicznie pokazuję wyniki, błędy i granice automatyzacji. W Systemie Właściciela pomagam wybrać pierwszy proces, który ma sens operacyjny.