Jak zweryfikować narzędzie AI, zanim je zatwierdzisz

stanowisko: dopasuj narzędzie do klasy danych

Zacznij od właściwego ujęcia sprawy, bo zmienia ono każdą kolejną kontrolę. Nie weryfikujesz narzędzia względem absolutnego standardu. Decydujesz, którą z Twoich klas danych narzędzie jest w stanie obsłużyć i na jakich warunkach, więc wynikiem jest mapowanie, a nie pojedyncza ocena.

Przydatny zestaw klas danych, od najmniej do najbardziej wrażliwych: publiczne lub o niskiej wrażliwości (treści marketingowe, treści publiczne, ogólne pytania bez specyfiki firmy; większość narzędzi radzi sobie tu dobrze, a weryfikacja może być lekka); wewnętrzne, niewrażliwe (notatki wewnętrzne, podsumowania spotkań, wersje robocze zawierające kontekst firmy, ale nic regulowanego ani poufnego); poufne (kod źródłowy, niepubliczne dane finansowe, roadmapy, strategia, wszystko objęte NDA); oraz dane osobowe (dane klientów lub pracowników, wszystko objęte RODO). To samo narzędzie może być zatwierdzone dla pierwszej klasy, ograniczone do drugiej i zakazane dla ostatniej. To normalny wynik, nie porażka weryfikacji. Każda kontrola poniżej pyta w gruncie rzeczy o to samo z innej strony: jak wysoko w klasach danych można temu narzędziu zaufać i jakie warunki przesuwają tę granicę.

co sprawdzić

Osiem kontroli. Pierwszych sześć dotyczy tego, co dzieje się z danymi po dotarciu do dostawcy; ostatnie dwie dotyczą tego, do czego narzędzie ma dostęp po Twojej stronie i jak zachowuje się dostawca.

Umowa powierzenia (DPA). Zgodnie z RODO, jeśli narzędzie przetwarza w Twoim imieniu dane osobowe, potrzebujesz podpisanego DPA; brak DPA oznacza, że nie możesz zgodnie z prawem puszczać przez narzędzie danych osobowych. Dobra odpowiedź to DPA, które można podpisać bez teatru sprzedażowego enterprise i które nazywa po imieniu przetwarzanie, jakie narzędzie faktycznie wykonuje. DPA, które istnieje, ale wyklucza funkcję AI, nie jest realnym DPA dla Twojego zastosowania.

Trenowanie na Twoich danych. Jeśli dostawca trenuje swoje modele na Twoich promptach, Twoje dane wymykają się spod kontroli w sposób nieodwracalny, więc prompt z nazwiskiem klienta albo fragmentem kodu staje się częścią modelu, o który pytają inni ludzie. Dobra odpowiedź to plan bez trenowania albo jasny opt-out włączony domyślnie dla kont biznesowych, z warunkami, które wprost stwierdzają, że prompty i odpowiedzi nie są używane do trenowania. Darmowe plany konsumenckie zwykle tego nie spełniają.

Retencja danych. To, jak długo dostawca przechowuje Twoje prompty i odpowiedzi, decyduje o oknie ekspozycji na wypadek naruszenia oraz o Twojej zdolności do spełnienia żądania usunięcia danych. Dobra odpowiedź to zadeklarowany okres retencji, sposób na usunięcie danych na żądanie i najlepiej opcja zerowej albo krótkiej retencji dla API lub planu biznesowego.

Subprocesorzy. Dostawca rzadko robi wszystko sam: działa na infrastrukturze chmurowej, korzysta z innych dostawców AI i kieruje dane przez narzędzia, których nie weryfikowałeś, a każde z nich jest częścią ścieżki Twoich danych. Dobra odpowiedź to aktualna, publiczna lista subprocesorów z powiadomieniem o zmianach. Dostawca, który nie potrafi wymienić swoich subprocesorów, nie zna własnych przepływów danych.

Hosting i rezydencja danych. Miejsce przetwarzania danych decyduje o tym, jakie prawo obowiązuje i czy dochodzi do transferu poza UE; dla części Twoich danych hosting w UE jest wymogiem, nie preferencją. Dobra odpowiedź to jasna dokumentacja, gdzie odbywa się przetwarzanie, opcja hostingu lub rezydencji w UE tam, gdzie jej potrzebujesz, oraz legalny mechanizm transferu dla wszystkiego, co opuszcza UE.

Certyfikaty bezpieczeństwa. Certyfikat SOC 2 Type II albo ISO 27001 to dowód, że niezależna strona sprawdziła kontrole dostawcy; to nie gwarancja, ale jego brak u dostawcy obsługującego wrażliwe dane to realna luka. Dobra odpowiedź to aktualny raport dostępny na żądanie, którego zakres faktycznie obejmuje weryfikowany produkt.

Model dostępu. Samodzielne narzędzie, do którego wklejasz tekst, to jedna decyzja; narzędzie, które prosi o połączenie z Twoim Google Workspace albo Microsoft 365 i czytanie poczty, plików czy kalendarzy, to decyzja o wiele większa, bo grant OAuth utrzymuje się w czasie, a jego zakres jest często szerszy, niż wymaga tego funkcja. Dobra odpowiedź to najwęższy zakres, który wykonuje zadanie, widoczne i wyjaśnione scope'y oraz szeroki dostęp do odczytu uzasadniony funkcją, a nie wygodny dla dostawcy.

Postawa bezpieczeństwa dostawcy i historia incydentów. Młody dostawca, który szybko się rozwija, może mieć nieduże praktyki bezpieczeństwa i krótką historię, a przeszłe incydenty pokazują, jak zachowuje się pod presją. Dobra odpowiedź to opublikowana strona bezpieczeństwa, sposób na zgłaszanie podatności, brak wzorca nieujawnionych albo źle obsłużonych naruszeń oraz dostawca na tyle dojrzały, żeby odpowiadać na pytania o bezpieczeństwo bez oporu.

Uwaga o kontroli dostępu, bo jest to ta najczęściej pomijana. Narzędzie AI, które widzi wyłącznie to, co ktoś do niego wklei, ma ograniczony blast radius. Narzędzie AI z grantem OAuth do Twojej poczty czy dysku ma blast radius stały: może sięgnąć po dane, którymi nikt nie chciał się z nim dzielić, i zachowuje ten zasięg długo po tym, jak osoba, która je zatwierdziła, zmieniła stanowisko czy pracę. Traktuj prośbę o połączenie jako kategorię wyższą niż narzędzie do wklejania tekstu i patrz na scope'y tak, jak patrzyłbyś na każdy inny stały dostęp. Dwie z tych kontroli pokrywają się z ogólnym due diligence dostawców, więc jeśli już prowadzisz kwestionariusz bezpieczeństwa dostawców przy zakupach oprogramowania, weryfikacja AI to ten sam odruch zawężony do pytań, które mają znaczenie, gdy w grze jest model.

punktacja

Kontrole mówią Ci, na co patrzeć. Punktacja zamienia to, co znalazłeś, w decyzję, więc dwie osoby weryfikujące to samo narzędzie dochodzą do w miarę tego samego miejsca. Oceń każdą z ośmiu kontroli w skali trzypunktowej: 2 spełnione (dobra odpowiedź jest na miejscu, jasna i udokumentowana), 1 częściowe (coś tam jest, ale warunkowo, np. DPA wykluczające funkcję AI, hosting w UE tylko na planie enterprise albo opcja braku trenowania wyłączona domyślnie) i 0 brak lub nieznane (brak odpowiedzi, brak dokumentacji albo jasne nie).

Wynik zasila decyzję per klasa danych, a nie pojedynczą ocenę. Zatwierdzasz dla danej klasy danych, gdy każda kontrola istotna dla tej klasy ma 2, a reszta 1 lub więcej; dla danych o niskiej wrażliwości istotnych kontroli jest niewiele, największą wagę mają model dostępu i postawa dostawcy, więc narzędzie może zostać zatwierdzone do treści publicznych nawet przy słabej historii DPA. Ograniczasz, gdy narzędzie wypada ogólnie dobrze, ale jedna albo dwie kontrole są częściowe w sposób, który wyklucza wyższe klasy danych; narzędzie z mocnym produktem, hostingiem w UE i planem bez trenowania, ale z DPA dostępnym tylko w rocznym planie enterprise, zostaje ograniczone do danych nieosobowych, dopóki plan i DPA nie będą na miejscu, a ograniczenie to najczęstszy i najbardziej użyteczny werdykt. Zakazujesz dla zgłoszonego zastosowania, gdy kontrola kluczowa dla żądanej klasy danych ma 0 bez ścieżki naprawy, na przykład narzędzie, które trenuje na promptach bez opcji opt-out, poproszone o obsługę kodu źródłowego; to samo narzędzie może dostać spokojne zatwierdzenie do pisania treści publicznych. Dwie kontrole działają jak bramki, a nie punkty: jeśli narzędzie będzie dotykać danych osobowych, a nie ma DPA, nie może zostać zatwierdzone dla danych osobowych niezależnie od tego, jak wypada w pozostałych kontrolach, a jeśli prosi o szeroki grant OAuth do poczty czy dysków i nie potrafi uzasadnić zakresu, to ogranicza klasy danych, na jakie może zostać zatwierdzone, dopóki zakres nie zostanie zawężony. Wysoki wynik w pozostałych kontrolach nie odkupuje nieprzejścia bramki.

jak to robić bez wąskiego gardła

Metoda weryfikacji, która zajmuje tydzień na narzędzie, będzie omijana, a pomijana weryfikacja jest gorsza niż lekka weryfikacja, bo ukrywa ryzyko zamiast je wycenić. Rozwiązaniem jest dopasowanie głębokości kontroli do ryzyka zgłoszenia, poprzez dwie ścieżki. Szybka ścieżka, dla narzędzi niskiego ryzyka, obejmuje samodzielne narzędzie bez połączenia z Twoimi systemami, używane do danych o niskiej wrażliwości albo wewnętrznych niewrażliwych: potwierdź trzy rzeczy, że nie łączy się z Twoją pocztą czy dyskiem, że ma opcję braku trenowania albo zastosowanie jest na tyle niskiej wrażliwości, że trenowanie nie tworzy ekspozycji, oraz że samo zatwierdzenie ogranicza je do klasy danych, do której się nadaje. To piętnastominutowa kontrola i obejmuje zdecydowaną większość zgłoszeń. Głębsza kontrola, dla narzędzi dotykających danych wrażliwych albo proszących o szeroki dostęp, przechodzi przez pełną punktację: każde narzędzie, które zobaczy dane poufne lub osobowe, albo prosi o grant OAuth, dostaje ocenę wszystkich ośmiu kontroli, zastosowane bramki i zapisany werdykt z warunkami. Reguła kierowania to jedno pytanie zadane na początku: czy narzędzie łączy się z naszymi systemami, albo czy zobaczy dane poufne lub osobowe? Nie na oba pytania to szybka ścieżka; tak na jedno z nich to głębsza kontrola. Dwie praktyki nie pozwalają całości się zestarzeć: zapisuj każdy werdykt z datą, warunkami i klasą danych, żeby lista zatwierdzeń była zarazem śladem audytowym, i wracaj do niego cyklicznie, co kwartał dla narzędzi dotykających danych wrażliwych i raz w roku dla reszty, bo dostawcy zmieniają warunki.