Dane w projekcie AI: co przekazać dostawcy modelu?

Asystent AI ma streścić zgłoszenie klienta. W wiadomości znajduje się opis problemu, numer zamówienia, stopka z telefonem i wcześniejsza korespondencja. Które z tych informacji rzeczywiście muszą trafić do dostawcy modelu? Odpowiedź zależy od zadania, sposobu działania usługi i ustaleń firmy. Sam fakt, że dane są dostępne w systemie, nie oznacza jeszcze, że wszystkie są potrzebne do wygenerowania podsumowania.

Przed uruchomieniem projektu AI warto prześledzić drogę danych od źródła do odpowiedzi. Trzeba wiedzieć, kto je zbiera, co wysyła do zewnętrznej usługi, gdzie pojawiają się kopie i jak długo mają być potrzebne. Takie ustalenia obejmują również dzienniki techniczne, załączniki i późniejsze wykorzystanie wyniku. Nie zastępują analizy prawnej ani weryfikacji umowy, ale pomagają przygotować do niej konkretne pytania.

Jeśli planujesz asystenta lub automatyzację, wyślij brief z opisem zadania i rodzajami informacji, z których system miałby korzystać. Na tym etapie nie przesyłaj haseł, kluczy API, rzeczywistych danych klientów ani dokumentów poufnych. Wymyślony przykład sprawy pozwoli omówić proces bez przekazywania wrażliwej zawartości.

Zacznij od celu, a potem wybierz dane

Wyobraźmy sobie zespół obsługujący reklamacje. Pracownik potrzebuje krótkiego podsumowania sprawy i listy pytań, na które klient jeszcze nie odpowiedział. Możliwe, że do przygotowania szkicu wystarczą opis problemu oraz historia działań. Pełne dane płatnicze lub dokument tożsamości nie stają się potrzebne tylko dlatego, że znalazły się w tej samej wiadomości. To przykład projektowy, który trzeba ocenić dla własnego procesu.

Dla każdego zadania zapiszcie, jaki wynik ma powstać i jaka informacja jest niezbędna do jego przygotowania. Jeśli model ma rozpoznać rodzaj urządzenia, potrzebuje opisu lub odpowiedniego fragmentu dokumentu. Jeżeli ma napisać odpowiedź do konkretnej osoby, system może dodać adresata dopiero na etapie wysyłki, bez umieszczania adresu w treści przekazywanej modelowi. Decyzja zależy od architektury i powinna zostać sprawdzona na przykładach.

Następnie ustalcie, skąd pochodzą dane i kto odpowiada za ich poprawność. Dokument przesłany przez klienta, rekord w systemie sprzedaży i notatka pracownika mogą zawierać różne wersje tej samej informacji. Zanim zaczniecie usuwać pola albo łączyć źródła, ustalcie, które z nich jest właściwe dla danego zadania. W artykule o porządkowaniu danych przed wdrożeniem AI opisujemy, jak zacząć taką inwentaryzację.

Ograniczanie zakresu danych powinno dotyczyć także odpowiedzi. Jeśli wynik ma zawierać kategorię sprawy i uzasadnienie, nie musi automatycznie powtarzać całej wiadomości wejściowej. Krótszy wynik może ułatwić pracownikowi ocenę, ale nie powinien usuwać kontekstu niezbędnego do sprawdzenia propozycji. Zespół powinien wiedzieć, jak wrócić do źródła, jeżeli podsumowanie budzi wątpliwości.

Narysuj drogę informacji

Prosta mapa zaczyna się od miejsca, w którym informacja powstaje. Dalej zaznaczcie formularz lub skrzynkę, aplikację firmową, ewentualną usługę pośredniczącą, dostawcę modelu, system zapisujący wynik oraz osoby, które mogą go zobaczyć. Przy każdym etapie zapytajcie, jakie pola są przesyłane i czy powstaje kopia. Dobrze uwzględnić również systemy monitoringu i pomocy technicznej, które mogą otrzymać fragment żądania podczas diagnozy błędu.

Przejście przez pośrednika ma znaczenie. Aplikacja może korzystać z platformy integracyjnej albo dostawcy, który z kolei korzysta z innego podmiotu. Nie zakładajcie, że nazwa usługi widoczna na fakturze opisuje wszystkich uczestników przepływu. Ustalcie, jakie informacje udostępnia dokumentacja i umowa dotycząca wybranej konfiguracji, a nie dowolnego produktu tej samej firmy.

W mapie warto zaznaczyć osobno dane testowe i produkcyjne. Środowisko demonstracyjne może mieć inne konta, integracje i zasady niż system używany przez pracowników. Wykorzystanie rzeczywistych zgłoszeń podczas testów zwiększa liczbę miejsc, w których trzeba kontrolować dostęp i retencję. Zamiast kopiować pierwszą lepszą bazę, przygotujcie przykłady syntetyczne lub zanonimizowane w sposób oceniony przez osoby odpowiedzialne za dane.

Nie zakładajcie przy tym, że usunięcie imienia zawsze wystarczy do anonimizacji. Połączenie innych szczegółów może nadal wskazywać osobę albo firmę. Jeśli do testu potrzebna jest historia działania, można stworzyć fikcyjne rekordy zachowujące układ i typowe trudności procesu. Weryfikujcie je pod kątem użyteczności: zestaw zbyt idealnych przykładów nie pokaże, jak system zachowa się przy brakach i sprzecznościach. O sposobach sprawdzenia, co pomija filtr, piszemy w tekście o usuwaniu danych z tekstu przed analizą AI.

Sprawdź usługę i konkretne ustawienia

Dokumentacja dostawcy powinna odpowiadać na pytania o rodzaj przechowywanych danych, cel przechowywania, dostępne ustawienia oraz ograniczenia poszczególnych funkcji. Warto sprawdzić, czy opis dotyczy używanego API, konkretnego produktu i wybranego sposobu wdrożenia. Warunki dotyczące jednego narzędzia nie muszą automatycznie obejmować innego, nawet jeśli oba mają tę samą markę.

Przykładem źródła jest dokument OpenAI o kontroli danych w platformie API. Opisuje on różne kategorie przechowywania i ustawienia, których dostępność zależy od funkcji oraz warunków usługi. Nie należy przenosić tych zasad na dowolnego dostawcę ani zakładać, że każda opcja jest włączona na koncie. Przed podjęciem decyzji sprawdźcie aktualną dokumentację, konfigurację oraz uzgodnienia dla własnego projektu.

Zapytajcie o miejsce przetwarzania i przechowywania, podmioty uczestniczące w obsłudze, okresy retencji oraz sposób usuwania danych. Jeżeli potrzebujecie określonych gwarancji, powinny wynikać z odpowiednich dokumentów i rzeczywistej konfiguracji. Samo pole wyboru regionu nie odpowiada na każde pytanie o drogę danych, kopie pomocnicze czy usługi dodatkowe. W razie niejasności warto uzyskać wyjaśnienie od dostawcy przed uruchomieniem procesu.

Istotne są również zmiany po wdrożeniu. Nowa funkcja przeszukiwania, dołączenie plików lub integracja z innym modelem może zmienić zakres przesyłanych informacji. Dlatego osoba odpowiedzialna za system powinna wiedzieć, jakie zmiany wymagają ponownej oceny, a zespół techniczny powinien móc wskazać aktualną konfigurację. Dokument zapisany przed startem nie opisze sam kolejnych wersji produktu.

Ogranicz zakres bez psucia zadania

Usuwanie danych jest skuteczne wtedy, gdy nie pozbawia procesu potrzebnego kontekstu. Jeśli system ma sprawdzić zgodność terminu z umową, musi otrzymać odpowiedni fragment umowy albo dane wynikające z wiarygodnego źródła. Wysłanie samego zdania „czy termin jest poprawny?” nie zapewni dobrej odpowiedzi. Trzeba zatem dobrać minimalny użyteczny zestaw, a następnie sprawdzić jakość na różnych przypadkach.

W niektórych procesach można zastąpić identyfikatory roboczymi oznaczeniami. System wewnętrzny przechowuje powiązanie ze sprawą, a model otrzymuje np. oznaczenie klienta i opis problemu. Po otrzymaniu propozycji aplikacja może powiązać wynik z właściwym rekordem. Takie rozwiązanie wymaga zabezpieczenia mapowania oraz oceny, czy pozostała treść nadal nie ujawnia tożsamości.

Innym sposobem jest wybór fragmentów dokumentu zamiast przesyłania całego archiwum. Mechanizm wyszukiwania powinien uwzględniać uprawnienia osoby zadającej pytanie. Jeśli użytkownik nie może otworzyć konkretnego pliku, asystent nie powinien ujawniać jego treści przez odpowiedź. Granice opisujemy w artykule o uprawnieniach do dokumentów w systemie RAG. Warto sprawdzić zarówno wynik końcowy, jak i materiały pobierane po drodze.

Zmniejszenie ilości danych nie usuwa potrzeby kontroli dostępu. Odpowiedź nadal może zawierać informacje handlowe lub wnioski dotyczące klienta. Ustalcie, kto widzi wynik, kto może go poprawić oraz czy wolno go przekazać dalej. Przy systemach obejmujących kilka oddziałów znaczenie ma także to, czy dane przechodzą do wspólnego raportu i na jakich zasadach. Jeżeli system może używać narzędzi, osobno ustalcie zakres działań i uprawnienia agenta AI.

Dzienniki, korekty i usuwanie

Zespół utrzymujący system potrzebuje informacji o błędach, ale nie zawsze potrzebuje pełnej treści żądania. Do ustalenia, że integracja odrzuciła żądanie, mogą wystarczyć czas, identyfikator sprawy, typ błędu i wersja użytej konfiguracji. Zakres zależy od przyczyny, którą trzeba wyjaśnić. Hasła i klucze nie powinny trafiać do dzienników tylko dlatego, że są częścią konfiguracji połączenia.

Uzgodnijcie okresy przechowywania i procedurę usuwania dla poszczególnych miejsc, w których znajdują się dane. Może być ich więcej niż jedno: baza spraw, historia rozmowy, kopia dokumentu oraz log techniczny. Przy każdym miejscu trzeba ustalić odpowiedzialną osobę, dostępną metodę usunięcia i sposób potwierdzenia wykonania. Warunki dostawcy oraz wymagania dotyczące danego procesu trzeba ocenić osobno.

Warto opisać także obsługę korekty. Jeśli pracownik poprawi błędne podsumowanie, gdzie zapisuje się poprawiona wersja? Czy wcześniejszy wynik pozostaje w historii i kto ma do niego dostęp? Czy jest przekazywany do dalszych analiz jakości? Odpowiedzi wpływają na praktyczną kontrolę danych, więc nie należy odkładać ich do momentu, w którym użytkownik zgłosi pierwszy błąd.

Sprawdź przepływ na przykładach

Przed uruchomieniem przygotujcie kilka reprezentatywnych spraw: zwykłą, niepełną, zawierającą nadmiarowe dane oraz taką, do której użytkownik nie powinien mieć dostępu. Obejrzyjcie rzeczywisty zakres informacji przekazywanych na każdym etapie, zgodnie z możliwościami testowego środowiska. Następnie sprawdźcie, czy wynik pozwala wykonać zadanie i czy pracownik potrafi wrócić do właściwego źródła.

Dobrze uwzględnić też sytuację, w której model nie ma wystarczających danych. Oczekiwana odpowiedź może polegać na wskazaniu braku i przekazaniu sprawy człowiekowi, zamiast domyślania się treści dokumentu. W artykule o testowaniu asystenta AI opisujemy tworzenie zestawu pytań i kryteriów oceny, które pomagają sprawdzić takie zachowanie.

Przy wyborze dostawcy porównujcie potrzebne funkcje, warunki i możliwość kontroli w kontekście konkretnego procesu. Sam wynik demonstracji nie pokaże, jak zarządzane są dostęp, przechowywanie i zmiany konfiguracji. O doborze narzędzia na podstawie zadania piszemy także w tekście o wyborze modelu AI do procesu firmowego.

W testach przyjrzyjcie się również sytuacji awaryjnej. Jeżeli odpowiedź dostawcy nie nadejdzie, komunikat dla pracownika nie powinien ujawniać pełnej treści żądania osobom, które nie mają do niej dostępu. Ustalcie, czy problem trafi do kolejki, kto sprawdzi jego przyczynę i kiedy można bezpiecznie ponowić operację. Więcej o doborze informacji do dzienników i reakcji zespołu przeczytasz w artykule o monitorowaniu automatyzacji i obsłudze błędów.

Wyniki takiej próby zapiszcie w sposób pozwalający odtworzyć decyzję. Przyda się nazwa używanej funkcji, zakres danych, osoba odpowiedzialna za ocenę i data sprawdzenia dokumentacji. Nie trzeba kopiować całych warunków usługi do notatki, ale warto zachować odnośnik do właściwej wersji oraz ustalenia, na których opiera się konfiguracja. Jeżeli któryś punkt pozostaje niewyjaśniony, wpiszcie pytanie i osobę odpowiedzialną za odpowiedź. W kolejnej wersji systemu będzie wiadomo, co trzeba sprawdzić ponownie.

Taki rejestr przyda się również wtedy, gdy projekt przejmie nowa osoba. Może ona sprawdzić uzgodnione ograniczenia i ich powód, zanim doda następne źródło danych lub zmieni dostawcę.

Na koniec ustalcie właściciela decyzji i termin jej przeglądu. Dostawca może zmienić dokumentację, firma może uruchomić nową integrację, a zadanie asystenta może się rozszerzyć. Dobrze zapisane pytania pozwalają ponownie ocenić zakres bez odtwarzania całej historii projektu. Przy planowaniu rozwiązań opartych na AI ta praca powinna towarzyszyć projektowaniu funkcji od początku.