Do jakich danych agent AI naprawdę potrzebuje dostępu?

Agent powinien widzieć tylko informacje potrzebne do konkretnej sprawy i mieć prawo wykonać tylko uzgodnione działania. „Dostęp do CRM” jest zbyt szerokim opisem. Inne dane są potrzebne do przygotowania odpowiedzi na reklamację, inne do wyceny, a jeszcze inne do podsumowania spotkania. Właściciel procesu powinien ustalić potrzebę biznesową; IT przekłada ją na kontrolę techniczną.

Szersze zasady odpowiedzialności i utrzymania opisuje przewodnik po bezpieczeństwie i utrzymaniu AI.

Opisz dostęp pięcioma pytaniami

Zapytaj: po co agent potrzebuje danych, o jakiej sprawie, z jakiego okresu, do kiedy oraz co może z nimi zrobić? Przykład: agent przygotowujący szkic odpowiedzi dla klienta może odczytać jego umowę i historię tej reklamacji, ale nie musi przeglądać całej bazy klientów ani zmieniać warunków handlowych. Ograniczenie zakresu ułatwia również ocenę wyniku — wiadomo, na jakiej podstawie powstała propozycja.

Odróżnij odczyt, zapis wersji roboczej i skuteczne działanie, takie jak wysłanie wiadomości lub zmiana statusu. Każdy poziom wymaga osobnej decyzji. Nie zakładaj, że skoro pracownik ma szeroki dostęp do aplikacji, agent powinien dziedziczyć go w całości. Kto zatwierdza decyzję agenta opisuje granice działań na poziomie procesu.

Testuj niewygodne sytuacje

Sprawdź klienta należącego do kilku spółek, sprawę przejętą przez inny dział i dokument z ograniczonym dostępem. Czy agent odmówi odpowiedzi, gdy źródło jest poza jego zakresem? Czy w wyniku nie ujawni danych, których użytkownik nie może zobaczyć? Czy po zakończeniu sprawy uprawnienie zostanie cofnięte, jeżeli było czasowe? To konkretne pytania odbiorcze, nie abstrakcyjny spór o technologię.

Techniczne modele RBAC, ABAC i ReBAC pozwalają egzekwować różne rodzaje granic. Nie wybieraj jednak jednego z nich w sali zarządu na podstawie nazwy. Najpierw opisz, kto ma prawo zobaczyć i zrobić co w realnym procesie.

Uprawnienie do danych nie jest zgodą na każdą odpowiedź

Agent może mieć prawo odczytać dokument w celu obsługi sprawy, ale niekoniecznie przekazać jego pełną treść każdemu użytkownikowi. Rozróżnij dostęp do źródła od prawa ujawnienia wyniku. Przykładowo, pracownik obsługi może potrzebować informacji, że limit klienta został przekroczony, lecz nie szczegółów wewnętrznej oceny ryzyka. Odpowiedź agenta powinna respektować granice odbiorcy, nie tylko własne techniczne poświadczenie.

Sprawdź to na próbce pytań od osób o różnych rolach. Czy ten sam agent zwraca odpowiedni zakres informacji? Czy przy braku uprawnienia potrafi wskazać legalną drogę uzyskania decyzji, zamiast po prostu podać brakujące dane innymi słowami? Jeśli nie, problem może leżeć w projekcie procesu i widoku użytkownika, nie wyłącznie w konfiguracji dostępu.

Przegląd uprawnień powinien obejmować również historię działań. W razie sporu firma musi wiedzieć, jakie dane były dostępne w chwili odpowiedzi. Zmiana uprawnień dziś nie powinna zacierać podstawy decyzji podjętej wczoraj.

Wróć do decyzji, gdy proces się zmieni

Nowy produkt, zespół lub rodzaj klienta może zmienić potrzebny zakres danych. Przeglądaj go po takich zmianach i po incydentach. Samo nadanie dostępu raz na początku projektu nie jest planem utrzymania. Jeśli firma nie potrafi wskazać właściciela danych i procesu, zacznij od audytu i mapy danych, zanim agent otrzyma szerokie uprawnienia.