Podłączenie asystenta AI do danych firmy to decyzja o uprawnieniach, a nie wdrożenie produktu. Zakładaj, że wszystko, co asystent może odczytać, może wydobyć każdy, kto może z nim rozmawiać, a wszystko, co potrafi zrobić, może wywołać każdy, kto jest w stanie wpłynąć na jego dane wejściowe. Zanim ruszy pilotaż, ustal pięć rzeczy: jakie dane są dozwolone, co asystent może robić, kto może z niego korzystać, co jest rejestrowane i kto odpowiada za ryzyko.
Uwaga o źródłach. Punkty zaczerpnięte z OWASP lub NIST są wskazane z nazwy i podlinkowane. Wszystko pozostałe w tej checkliście to nasze własne rekomendacje, a nie wymóg żadnej z tych organizacji.
Zdecyduj, jakie dane mogą trafić do asystenta
Zacznij od klasyfikacji, bo od niej zależy każda kolejna kontrola. Jeśli nie masz żadnego schematu, na początek wystarczą trzy poziomy. Muszą być spisane, zanim ktokolwiek podłączy skrzynkę pocztową, zasób plikowy czy CRM.
| Poziom | Typowa zawartość | Zasada dla asystenta |
|---|---|---|
| Publiczne | Opublikowane treści ze strony, karty produktowe | Dozwolone |
| Wewnętrzne | Polityki, notatki projektowe, wewnętrzne wiki | Dozwolone wyłącznie w zatwierdzonych narzędziach |
| Poufne | Dane osobowe, umowy, poświadczenia, kod źródłowy, dokumenty finansowe | Wyłączone, dopóki wskazany właściciel tego nie zatwierdzi |
Zespoły potykają się o dwie rzeczy. Po pierwsze, konektory zwykle pobierają całe repozytoria lub dyski, więc do indeksu trafia folder, o którego udostępnieniu nikt już nie pamięta. Uporządkuj udostępnianie przed podłączeniem, nie po. Po drugie, sekrety w dokumentach (klucze API na stronach wiki, hasła w zgłoszeniach) zamieniają wyszukiwarkę w wyciek poświadczeń.
Zakładaj, że asystent przeczyta wrogi tekst
Traktuj wszystko, co asystent czyta (przychodzące e-maile, strony WWW, udostępnione dokumenty, wgrywane pliki), jako treść, którą ktoś inny mógł napisać po to, by nim sterować. Zalecamy projektować wdrożenie tak, by takie sterowanie nie wyrządzało szkody, zamiast czynić prompt systemowy swoją jedyną kontrolą.
W praktyce:
- Daj asystentowi minimum narzędzi, których potrzebuje. Na początek dostęp tylko do odczytu.
- Wymagaj potwierdzenia przez człowieka dla każdej akcji z skutkami ubocznymi: wysyłki e-maila, zmiany rekordów, uruchomienia kodu, płatności.
- Trzymaj niezaufane treści z dala od asystentów, które mają też dostęp do danych poufnych.
- Traktuj wynik pracy asystenta jak niezaufane dane wejściowe dla tego, co go przetwarza. Jeśli system dalej wykonuje go lub renderuje, waliduj go tak jak dane od użytkownika.
Jako referencyjną listę ryzyk aplikacji opartych na LLM wykorzystaj OWASP Top 10 for Large Language Model Applications. Strona projektu opisuje OWASP GenAI Security Project jako globalną inicjatywę open source obejmującą ryzyka bezpieczeństwa generatywnej AI, w tym LLM, systemów agentowych i aplikacji opartych na AI. Zaznacza, że Top 10 pozostaje jego kluczowym elementem, i wymienia wersję z 2025 roku. Najnowszą listę strona wskazuje pod adresem genai.owasp.org/llm-top-10/. Przeczytaj ją i oprzyj model zagrożeń na jej kategoriach, zamiast wymyślać własne.
Kontrola dostępu i logowanie
Asystent powinien działać z uprawnieniami osoby, która o coś pyta, a nie z szerokiego konta serwisowego. Jeśli korzysta z jednej wspólnej tożsamości z dostępem do wszystkiego, młodszy pracownik może dobrze sformułowanym pytaniem wydobyć dokumenty zarządu. Sprawdź, jak konektor obsługuje uprawnienia per użytkownik, i przed uruchomieniem produkcyjnym przetestuj to na dwóch kontach o różnym poziomie uprawnień.
Następnie zdecyduj, co logować. Minimum to tyle, by dało się odtworzyć incydent:
timestamp, user id, assistant/tool name,
source documents retrieved, actions requested,
actions executed, confirmation (yes/no), result statusZ wyprzedzeniem ustal, jak długo przechowujesz te logi, kto może je czytać i czy same prompty zawierają dane osobowe. Logi rozmów to odrębny zasób danych i wymagają tej samej klasyfikacji co treści, które zawierają. Przekazuj je osobie lub zespołowi odpowiedzialnemu za monitoring, aby nietypowa liczba pobrań z jednego konta nie umknęła uwadze.
Oceń dostawcę przed podpisaniem umowy
Zadaj dostawcy bezpośrednie pytania i uzyskaj odpowiedzi na piśmie:
- Czy nasze prompty i dokumenty są używane do trenowania lub ulepszania modeli? Czy można to wyłączyć na poziomie umowy, a nie tylko ustawieniem?
- Gdzie dane są przetwarzane i przechowywane oraz którzy podwykonawcy przetwarzania są zaangażowani?
- Jak długo przechowywane są prompty, odpowiedzi i wgrane pliki i czy możemy je usunąć?
- Jakie są dostępne kontrolki administracyjne: single sign-on, dostęp oparty na rolach, eksport logów audytowych, listy dozwolonych konektorów?
- Jak i w jakim czasie dostawca powiadamia o incydentach bezpieczeństwa?
Sprawdź, czy odpowiedzi zgadzają się z rzeczywistą konsolą administracyjną. Strona z polityką i konfigurowalne ustawienie to dwie różne rzeczy. Jeśli narzędzie oferuje wtyczki lub konektory firm trzecich, oceniaj je jak osobnych dostawców.
Wyznacz właściciela ryzyka
Governance brzmi jak papierologia i nią jest, ale to właśnie ta część zatrzymuje wdrożenia w cieniu (shadow IT). NIST AI RMF Playbook zawiera sugerowane działania zgodne z czterema funkcjami AI Risk Management Framework: Govern, Map, Measure i Manage. NIST podkreśla, że Playbook nie jest ani checklistą, ani zestawem kroków do wykonania w całości, a jego sugestie są dobrowolne. Zaznacza też, że AI RMF 1.0 jest aktualizowany i Playbook pójdzie w ślad za nim, więc sprawdź, czy korzystasz z aktualnej wersji. Weź to, co pasuje do firmy twojej wielkości.
Rekomendujemy krótki rejestr wszystkich używanych narzędzi AI, z właścicielem, poziomami danych, których mogą dotykać, i datą przeglądu. Dodaj jeszcze jedną kolumnę: czy dział prawny potwierdził, że do danego przypadku użycia mają zastosowanie obowiązki wynikające z EU AI Act lub RODO, i jakie były jego wnioski. Nie oceniliśmy tych obowiązków w tym artykule, więc poproś o decyzję radcę prawnego lub doradcę ds. zgodności. Jeśli potrzebujesz pomocy w stworzeniu rejestru i procesu przeglądów, nasza usługa doradcza obejmuje oceny gotowości.
Od czego zacząć
- Wypisz wszystkie asystenty AI, które już są w użyciu, także darmowe konta założone przez pracowników na własną rękę, i wskaż właściciela każdego z nich.
- Spisz powyższą klasyfikację trzypoziomową i oznacz, do którego poziomu należy każde podłączone źródło danych. Wyłącz z zakresu źródła poufne.
- Uruchom pilotaż z dostępem tylko do odczytu, uprawnieniami per użytkownik i potwierdzeniem przez człowieka każdej akcji. Przetestuj go na dwóch kontach o różnym poziomie uprawnień.
- Włącz logowanie, ustal okres retencji i przekazuj logi osobie lub zespołowi monitorującemu twoje systemy.
- Wyślij dostawcy pytania, trzymaj pisemne odpowiedzi razem z umową i poproś dział prawny o potwierdzenie, czy obowiązują cię wymogi z EU AI Act lub RODO.
- Przed szerszym wdrożeniem zleć przetestowanie konfiguracji komuś, kto spróbuje ją zaatakować. Test penetracyjny ze scenariuszami zbudowanymi wokół twoich rzeczywistych konektorów pokaże to, czego model zagrożeń na papierze nie wychwyci.
