Agent Administracyjny AI — scenariusz wdrożenia w małej firmie

Czynności administracyjne w kilkunastoosobowej firmie rzadko mają jednego właściciela. Faktura trafia na skrzynkę, ktoś ją otwiera, ktoś inny przepisuje kwoty do arkusza, a informacja o kończącym się badaniu okresowym albo uprawnieniu żyje w kalendarzu jednej osoby. Dopóki wszyscy są na miejscu, układ działa. Rozsypuje się przy urlopie, zwolnieniu albo zmianie osoby odpowiedzialnej: nikt nie widzi całości, a terminy wychodzą po fakcie, zwykle w momencie, w którym dokument już stracił ważność. Naszym zdaniem to nie jest kwestia niestaranności ludzi, tylko rozproszenia danych między skrzynką pocztową, komunikatorem, arkuszami i cudzą pamięcią — i dlatego apele o większą uważność niczego tu nie zmieniają. Osoba, która trzyma w głowie piętnaście dat, prędzej czy później przegapi szesnastą, niezależnie od tego, jak bardzo się stara.

Większość rozmów o automatyzacji administracji zaczyna się od pytania, jakiego narzędzia użyć. Uważamy, że to odwrotna kolejność. Dopóki nie wiadomo, kto jest właścicielem każdego procesu i co ma się stać z dokumentem, którego automat nie rozpozna, wybór narzędzia jest wyborem opakowania dla nierozwiązanego problemu — i stąd bierze się tyle wdrożeń, które działają technicznie, a po miesiącu nikt do nich nie zagląda. Kolejny program nie scala rozproszonych danych, tylko dokłada im jedno miejsce więcej. U nas narzędzie jest ostatnią decyzją w projekcie, a nie pierwszą, i jeżeli okaże się, że wystarczy poprawić obieg dokumentów bez żadnego agenta, powiemy to wprost, zanim wystawimy jakąkolwiek wycenę.

• Ta sama informacja jest wpisywana ręcznie w dwóch lub trzech miejscach
• Dane o czasie pracy powstają w e-mailach i na komunikatorze, a nie w systemie
• Terminów ważności dokumentów i uprawnień pilnuje pamięć konkretnej osoby
• Rozliczenie delegacji zaczyna się od ustalania, kto gdzie i kiedy był
• Księgowość dostaje materiał w ostatniej chwili, w formacie za każdym razem trochę innym
• Przy nieobecności jednej osoby część spraw zatrzymuje się do jej powrotu

Zakres, który proponujemy, obejmuje wąski wycinek administracji — taki, w którym reguły da się zapisać i sprawdzić. Wolimy wąsko i nudno niż szeroko i efektownie, bo wąski zakres da się zweryfikować w kilka tygodni, a szeroki broni się dopiero po pół roku, kiedy na korektę jest już za drogo. Taki agent może odbierać dokumenty ze wskazanej skrzynki, odczytywać z nich dane, zapisywać je w ustalonej strukturze arkusza i pilnować dat. Nie chodzi o inteligentne biuro — to hasło, które dobrze się sprzedaje i nic nie znaczy — tylko o to, żeby jedna osoba widziała w jednym miejscu, co wpłynęło, czego brakuje i co kończy się w najbliższym czasie. Zakres ustalamy przed startem: które procesy wchodzą do pilotażu, jakie pola są obowiązkowe i co ma się stać wtedy, gdy agent czegoś nie rozpozna.

1. 01Zebranie regułSpisujemy, skąd wpływają dokumenty, jakie pola trzeba z nich wyciągnąć i kto odpowiada za każdy proces. Bez tego kroku agent powiela istniejący bałagan, tylko szybciej.
2. 02Odczyt dokumentówAgent pobiera załączniki ze wskazanej skrzynki, rozpoznaje typ dokumentu i wyciąga dane: sprzedawcę, numer, daty, kwoty, pozycje.
3. 03Zapis do arkuszaDane trafiają do arkusza Google w ustalonej strukturze, z odnośnikiem do oryginalnego pliku, żeby dało się sprawdzić źródło każdego wiersza.
4. 04Pilnowanie terminówAgent porównuje daty ważności dokumentów i uprawnień pracowników z kalendarzem i wysyła przypomnienie z wyprzedzeniem uzgodnionym z klientem.
5. 05Kolejka wyjątkówWszystko, czego agent nie rozpoznał albo co odbiega od reguły, trafia na osobną listę do decyzji człowieka. Ta lista jest częścią rozwiązania, nie objawem awarii.

Do zbudowania takiego agenta wystarczają narzędzia, których używamy na co dzień: Make albo n8n jako warstwa przepływów, Google Sheets i Workspace jako miejsce, w którym dane są widoczne dla zespołu, Node.js i TypeScript tam, gdzie logika przestaje mieścić się w gotowych blokach, oraz panel w Next.js i Reakcie hostowany na Vercelu, jeśli arkusz przestaje wystarczać. Między własnym kodem a gotową platformą wybieramy platformę tak długo, jak się da. Własny kod jest przyjemniejszy do pisania i droższy w utrzymaniu, a rachunek za to utrzymanie płaci klient, nie my. Dobór narzędzi wynika z tego, czym firma już się posługuje: jeśli księgowość pracuje na arkuszu, agent pisze do arkusza, a nie do nowego systemu, którego nikt nie będzie otwierał. Panel z logowaniem wygląda poważniej i właśnie dlatego bywa gorszym pomysłem — dokłada zespołowi jedno narzędzie do nauczenia w zamian za estetykę.

Spotykamy się z oczekiwaniem, że dobrze zrobiony agent to taki, który nie oddaje spraw człowiekowi. Jesteśmy zdania odwrotnego: agent bez kolejki wyjątków nie jest pewniejszy, on po prostu zgaduje po cichu. Błędnie odczytana kwota, która trafiła do arkusza z pełnym przekonaniem, kosztuje więcej niż pole zostawione puste z adnotacją „do sprawdzenia”, bo pustego pola nikt nie przeoczy, a błędnego owszem. Dlatego liczbę wyjątków traktujemy jako wskaźnik do obserwowania, a nie jako wstyd do ukrycia, i pokazujemy ją klientowi co tydzień od pierwszego dnia pilotażu.

Wdrożenie bez pomiaru jest kwestią wiary, dlatego wskaźniki ustalamy przed startem, razem z punktem odniesienia. Punkt odniesienia zbieramy z tego, co firma już ma: dat w skrzynce, historii arkusza, kalendarza. Poniższa tabela to zestaw, od którego zaczynamy rozmowę — konkretny wybór zależy od procesów objętych pilotażem. Świadomie nie wpisujemy tu żadnych wartości: nie mamy uruchomionego wdrożenia agenta administracyjnego, więc każda liczba w tym miejscu byłaby zmyślona. Publikujemy pustą tabelę zamiast case study z procentami, bo uważamy to za mocniejszy sygnał wiarygodności — każdy czytelnik widział już dziesiątki zdań o skróceniu obsługi o kilkadziesiąt procent i żadnego z nich nie mógł sprawdzić. Tego, co i skąd zamierzamy liczyć, sprawdzić się da, jeszcze przed podpisaniem umowy. Wartości pojawią się dopiero po pierwszym okresie pracy agenta i to one rozstrzygną, czy zakres rozszerzać, czy ciąć.

Ta sama tabela służy do czegoś jeszcze: pokazuje próg, poniżej którego takiego wdrożenia po prostu nie warto robić. Jeżeli do firmy wpływa kilkanaście dokumentów miesięcznie, a terminów do pilnowania jest kilka, odradzimy projekt na pierwszej rozmowie i powiemy, że tańszym rozwiązaniem jest wspólny kalendarz i jeden uporządkowany arkusz. Nie jest to skromność, tylko rachunek — wdrożenie od 10 000 zł musi się z czegoś zwrócić, a przy takiej skali nie ma z czego. Wolimy stracić zlecenie, niż mieć w portfolio projekt, którego klient po roku nie umie obronić przed samym sobą.

Agent AI nie zastąpi osoby od administracji i nie zamierzamy tego obiecywać. Zabierze kilkanaście minut jej dnia, powtarzanych kilkadziesiąt razy w miesiącu — i to jest cała różnica między wdrożeniem, które się broni, a pokazem na konferencji. Agent administracyjny nie jest ani księgowym, ani kadrową. Odczytuje dokument i zapisuje dane, ale nie decyduje o kwalifikacji kosztu, nie interpretuje przepisów i nie zatwierdza rozliczenia. Naliczenie diety wykonuje według reguł, które dostał na piśmie — jeśli reguła jest sporna, sprawa idzie do człowieka, a nie do własnej interpretacji modelu. Dane kadrowe i dane z faktur to dane osobowe i dane finansowe, więc zakres dostępu, miejsce przechowywania i lista osób uprawnionych są ustalane przed pierwszym uruchomieniem, a nie po nim. Odczyt bywa też zawodny przy skanach słabej jakości i pismach odręcznych; trzeba to założyć z góry, zamiast odkrywać w trzecim tygodniu pilotażu.

• Nie zatwierdza płatności i nie wykonuje przelewów
• Nie kwalifikuje kosztów podatkowo i nie zastępuje biura rachunkowego
• Nie podejmuje decyzji kadrowych ani nie ocenia pracowników
• Nie rozstrzyga spornych przypadków — odkłada je do kolejki wyjątków
• Nie działa na dokumentach, do których firma nie chce dawać dostępu automatowi
• Nie zastępuje polityki ochrony danych, tylko musi się w nią wpisać

Do własnych ograniczeń przyznajemy się w tym samym miejscu, w którym opisujemy ograniczenia agenta. Opublikowanego wdrożenia AI jeszcze nie mamy — Wataha Media działa od 2021 roku i ma w portfolio strony, sklepy i aplikacje, a nie agentów administracyjnych. Skuteczności odczytu dokumentów w naszym stosie nie mamy przetestowanej na realnym zbiorze, więc pierwszy projekt tego typu będzie pouczający dla obu stron. Dla klienta oznacza to zaletę i ryzyko naraz: rozmawia bezpośrednio z osobą, która pisze kod, i jednocześnie z wykonawcą, który tego konkretnego wdrożenia nie ma jeszcze za sobą. Mówimy o tym przed umową, a nie po niej, i właśnie dlatego proponujemy pilotaż z wyraźnym punktem, w którym można się wycofać.

Najczęstszy sposób, w jaki takie wdrożenie się psuje, nie jest techniczny. Agent działa, odczytuje dokumenty poprawnie, a i tak nikt z niego nie korzysta, bo nie ustalono, kto ma przeglądać kolejkę wyjątków i w jakim rytmie. Drugi scenariusz porażki to rozjazd formatów: dostawca zmienia układ faktury, reguła przestaje pasować, nikt tego nie zauważa przez kilka tygodni i do arkusza wpada seria pustych pól. Trzeci to ambicja — zakres rośnie w trakcie, bo skoro agent już czyta faktury, to niech przy okazji zrobi jeszcze cztery rzeczy; kończy się to projektem bez daty końca. Wszystkie trzy da się ograniczyć, żadnego nie da się wykluczyć i wolimy napisać to tutaj, niż tłumaczyć na trzecim miesiącu współpracy.

• Wolumen dokumentów jest tak mały, że oszczędność czasu nie pokryje kosztu utrzymania — mówimy to na pierwszej rozmowie, nie po podpisaniu umowy
• Nikt po stronie klienta nie ma czasu ani mandatu, żeby przeglądać kolejkę wyjątków
• Reguły procesu nie istnieją, a oczekiwaniem jest, że agent sam się ich domyśli
• Celem wdrożenia ma być redukcja etatu, a nie zdjęcie powtarzalnej pracy z konkretnej osoby
• Dokumenty są niemal wyłącznie słabymi skanami lub pismem odręcznym, a klient nie godzi się na kontrolę człowieka
• Zakres ma być ustalany na bieżąco, bez spisanej listy procesów wchodzących do pilotażu

Odmowa nie jest u nas gestem ani grą negocjacyjną. Jednoosobowa firma nie ma zapasu ludzi do gaszenia projektów, które od początku stały na złych założeniach, więc jedyną sensowną obroną jest powiedzenie „nie” przed umową. Jeśli po rozmowie o procesie uznamy, że problem rozwiązuje zwykły przepływ w Make albo n8n bez modelu językowego, zaproponujemy przepływ — jest tańszy, pewniejszy i łatwiejszy w utrzymaniu niż cokolwiek, w czym coś trzeba rozumieć. Model dokładamy tam, gdzie naprawdę trzeba odczytać nieustrukturyzowany tekst, a nie tam, gdzie ładnie brzmi w ofercie.