Agent AI z dostępem do firmowych systemów to nie chatbot z dodatkowymi uprawnieniami. To nowy typ konta w organizacji - takie, które czyta cudze instrukcje, działa szybciej niż człowiek zdąży zareagować i domyślnie nie zostawia śladu. Poniżej pięć ryzyk, które widzimy najczęściej, i to, co z nimi robimy.
1. Nadmiarowe uprawnienia
Najczęstszy błąd i zarazem najprostszy do uniknięcia. Agent dostaje dostęp do całej bazy, bo „tak jest szybciej”, chociaż do zadania potrzebuje trzech tabel. Skutek jest taki sam jak przy każdym innym koncie z nadmiarem uprawnień, tylko trudniej zauważalny - agent nie narzeka na to, że widzi za dużo.
Co robimy: agent dostaje własne konto z zakresem wyliczonym z zadania, nie z wygody. Operacje zapisujące są wymienione z nazwy - nie „dostęp do bazy”, tylko lista konkretnych czynności.
2. Wstrzyknięcie instrukcji przez dane
Ryzyko specyficzne dla agentów i wciąż niedoceniane. Model przetwarzający treść z zewnątrz - maila, faktury, strony internetowej, opisu produktu od dostawcy - nie ma wbudowanego rozróżnienia między danymi do przetworzenia a poleceniem do wykonania. Zdanie ukryte w PDF-ie potrafi zmienić zachowanie agenta.
To nie jest teoretyczne. Jeśli agent czyta skrzynkę firmową i ma prawo wysyłać maile, wystarczy jedna wiadomość z odpowiednio sformułowaną treścią.
Co robimy: oddzielamy treść niezaufaną od instrukcji, ograniczamy uprawnienia agenta przetwarzającego dane z zewnątrz do odczytu, a każdą operację wychodzącą na świat przepuszczamy przez punkt akceptacji.
3. Cichy błąd
Człowiek, który nie wie, jak coś zrobić, pyta. Model generuje odpowiedź wyglądającą na poprawną. Jeśli system nie ma mechanizmu sygnalizowania niepewności, błąd przechodzi dalej i wychodzi na jaw dopiero przy zamknięciu miesiąca.
Co robimy: zasada „cytuj albo się wstrzymaj”. Jeżeli model nie potrafi wskazać podstawy w dokumencie źródłowym, nie wydaje rozstrzygnięcia - oznacza sprawę do decyzji człowieka. Lepiej mieć dziesięć przypadków w kolejce niż jeden zaksięgowany źle.
4. Brak rozliczalności
Pytanie „dlaczego system to zrobił” pada zwykle trzy tygodnie po fakcie. Bez dziennika decyzji nie ma na nie odpowiedzi - a przy audycie, kontroli albo sporze z klientem jest to problem poważniejszy niż sam błąd.
Co robimy: każda decyzja agenta trafia do dziennika razem z danymi wejściowymi i uzasadnieniem. Dziennik jest przeglądalny bez znajomości kodu - inaczej nikt do niego nie zajrzy.
5. Dane wychodzące poza organizację
Pytanie „co właściwie wysyłamy do modelu” pada zwykle za późno. Regulamin mówiący, że nie wolno wysyłać danych wrażliwych, nie jest zabezpieczeniem - jest deklaracją.
Co robimy: zakres danych wychodzących ustalamy przed startem i egzekwujemy technicznie: filtrowanie po stronie systemu, oddzielenie identyfikatorów od treści, a tam gdzie ryzyko jest wysokie - model działający lokalnie. Różnica między „nie wolno” a „nie da się” jest tu całą różnicą.
Trzy zabezpieczenia, bez których nie oddajemy agenta na produkcję
- Twardy limit kompetencji. Lista operacji, których agent może dokonać - wszystko poza nią jest niemożliwe technicznie, nie tylko zabronione.
- Punkt akceptacji przed krokiem nieodwracalnym. Przelew, wysyłka, publikacja, zmiana w systemie zewnętrznym.
- Możliwość natychmiastowego zatrzymania. Jeden przycisk, dostępny dla operatora, działający bez udziału programisty.
A co z przepisami
Dla większości firm istotne są dwa obszary. RODO - jeśli do modelu trafiają dane osobowe, potrzebna jest podstawa prawna, informacja dla osób, których dane dotyczą, i umowa powierzenia z dostawcą modelu. AI Act - obowiązki zależą od klasyfikacji zastosowania; typowa automatyzacja back-office trafia do kategorii niskiego ryzyka, ale systemy wspierające decyzje kadrowe czy kredytowe już nie.
Warto to przejrzeć przed wdrożeniem, a nie po. Przegląd istniejącego wdrożenia zakończony pisemnym raportem to jedna z rzeczy, które robimy - razem ze szkoleniem dla zespołu z tych samych zagadnień.