Zamiast pytać ogólnie, czy AI jest bezpieczne, opisujesz przepływ danych, uprawnienia, możliwe nadużycia i konkretne zabezpieczenia. Dla eksperta budującego automatyzację jest to praktyczny krok, który pozwala ograniczyć ryzyko wycieku, błędnej akcji i kosztownej pomyłki bez zatrzymywania całego projektu.
Modelowanie zagrożeń, po angielsku threat modeling, to proces opisania systemu przez pryzmat tego, co chronisz, kto lub co może zaszkodzić oraz jak ograniczysz skutki. W systemie AI nie chodzi wyłącznie o sam model. Zakres obejmuje też prompt systemowy, pliki przekazywane do modelu, integracje, narzędzia, konta techniczne, bazę wiedzy, webhooki i człowieka zatwierdzającego wynik. Efektem nie ma być formalny dokument dla dokumentu, lecz krótka lista ryzyk oraz decyzji, które da się wdrożyć i sprawdzić.
To pojęcie jest szersze niż test bezpieczeństwa i inne niż ocena ryzyka systemu AI. Ocena ryzyka pomaga oszacować prawdopodobieństwo oraz wpływ problemu. Modelowanie zagrożeń zaczyna wcześniej: mapuje granice systemu i scenariusze, w których problem może powstać. OWASP proponuje cztery proste pytania: nad czym pracujemy, co może pójść źle, co z tym zrobimy i czy wykonaliśmy pracę wystarczająco dobrze. Ten schemat działa również dla małego workflowu z formularzem, CRM i agentem.
Dla automatyzacji sprzedaży wiedzy zacznij od prostego diagramu. Zaznacz źródła wejścia, na przykład formularz i skrzynkę e-mail, następnie workflow, model, CRM oraz punkt wyjścia, taki jak zapis kontaktu lub szkic follow-upu. Przy każdej strzałce zapisz dane, uprawnienie i właściciela decyzji. Potem zadaj pytania: czy treść od leada może przejąć instrukcje agenta, czy agent może wysłać wiadomość bez akceptacji, czy token API ma szerszy dostęp niż potrzebuje oraz czy potrafisz odtworzyć wykonaną akcję.
Typowy scenariusz: agent czyta brief przesłany przez klienta, streszcza go i przygotowuje propozycję odpowiedzi w CRM. Zagrożeniem jest prompt injection ukryty w briefie, który próbuje skłonić agenta do ujawnienia instrukcji lub użycia narzędzia poza celem zadania. Rozsądne ograniczenia to traktowanie treści klienta jako danych, zakres narzędzia tylko do zapisu szkicu, oddzielny token dla integracji oraz zatwierdzenie człowieka przed wysyłką. Nie trzeba rezygnować z automatyzacji. Trzeba ograniczyć jej władzę do konkretnego kroku.
W systemach agentowych warto osobno rozpatrzyć ryzyka związane z narzędziami. Opis narzędzia, wynik wyszukiwania albo dokument może zawierać wrogą instrukcję. Agent może też popełnić błąd, bo otrzymał zbyt szerokie uprawnienia, nieprawidłowo zinterpretował wynik API albo wykonał akcję drugi raz po ponowieniu zadania. Dlatego model zagrożeń powinien wskazywać granice zaufania, operacje nieodwracalne i miejsca, w których potrzebne są walidacja danych, idempotencja, log oraz zgoda człowieka.
Nie istnieje jedna uniwersalna lista zagrożeń dla wszystkich firm. STRIDE może pomóc przejść przez klasyczne ryzyka techniczne, a materiały OWASP dla agentów AI wskazują zagrożenia specyficzne dla modeli i narzędzi. NIST AI RMF traktuje zarządzanie ryzykiem jako stałą praktykę przy projektowaniu, użyciu i ocenie systemu. Dla małego biznesu ważniejsza od pełnej metodyki jest regularność: zrób model przed uruchomieniem nowej integracji, a potem wróć do niego po zmianie dostępu, narzędzia lub procesu.
Najczęstszy błąd to mylenie modelowania zagrożeń z jednorazowym checklistem compliance. Lista bez realnego diagramu i decyzji nie mówi, co naprawić. Drugi błąd to próba przewidzenia wszystkiego, która paraliżuje wdrożenie. Wystarczy zacząć od jednego procesu o realnej stawce, na przykład obsługi leada albo dostępu agenta do dokumentów. Wybierz trzy najpoważniejsze scenariusze, przypisz właściciela i test potwierdzający zabezpieczenie. To daje lepszy efekt niż deklaracja, że system jest bezpieczny.
Najczęstsze pytania
Kiedy zrobić modelowanie zagrożeń dla automatyzacji AI?
Zrób je przed włączeniem nowego agenta, narzędzia lub dostępu do danych klientów. Wróć do modelu po zmianie architektury, uprawnień, dostawcy modelu albo po incydencie. Dla małego workflowu wystarczy krótka sesja z diagramem przepływu danych i listą trzech najważniejszych ryzyk.
Czy modelowanie zagrożeń jest potrzebne, gdy agent tylko tworzy szkice?
Tak, ale zakres może być mały. Nawet agent tworzący szkice czyta dane i może zostać zmanipulowany przez treść dokumentu lub przekazać poufne informacje do niewłaściwego narzędzia. Jeśli nie może sam wysyłać wiadomości ani zmieniać rekordów, ryzyko skutku jest niższe, lecz granice danych i źródła instrukcji nadal warto opisać.
Czym modelowanie zagrożeń różni się od prompt injection?
Prompt injection to jeden konkretny scenariusz ataku, w którym nieufna treść próbuje zmienić zachowanie modelu. Modelowanie zagrożeń jest szerszym procesem, który pozwala wykryć prompt injection obok zbyt szerokich uprawnień, wycieku klucza API, błędnej automatycznej wysyłki czy braku logów.
