Wytyczne Sandia dotyczące bezpieczeństwa AI stawiają startupy z Tri-Valley w stan gotowości

Sandia National Laboratories zaprezentowało czterech badaczy przed startupami z Tri-Valley z ostrzeżeniem: szybkie wdrażanie AI tworzy ryzyka, których konwencjonalne przeglądy oprogramowania mogą nie wykryć. Panel z 29 lipca przeniósł metody bezpieczeństwa AI Sandia do kontekstu biznesowego, w którym małe zespoły często wdrażają modele przed ustanowieniem formalnych programów zapewniania bezpieczeństwa.

Wydarzenie nie wprowadziło nowego produktu, wiążącego standardu ani regulacji. Jego znaczenie wynikało z modelu działania przedstawionego przez Sandia. Startupy powinny analizować dane, modele, integracje i decyzje ludzi jako jeden połączony system, a następnie testować ten system pod kątem realistycznych awarii i ataków.

To stanowisko ujawnia wyraźny konflikt między szybkością wdrażania a dowodami bezpieczeństwa. Startupy konkurują, wcześnie udostępniając funkcje, ucząc się od użytkowników i szybko zmieniając kierunek. Sandia podchodzi do AI z perspektywy środowisk o wysokiej stawce, gdzie niewyjaśniona awaria może podważyć cały system.

Panel zakwestionował również znane założenie startupów. Korzystanie z modelu za pośrednictwem renomowanego dostawcy nie przenosi na tego dostawcę całego ryzyka. Firma budująca końcową aplikację nadal kontroluje dostęp do danych, warstwę wyszukiwania, narzędzia, uprawnienia, doświadczenie użytkownika i procedury reagowania.

To sprawia, że zapewnianie bezpieczeństwa AI staje się odpowiedzialnością produktową, a nie końcowym ćwiczeniem zgodności. Bezpośrednie pytanie dla założycieli brzmi, czy ich zespoły potrafią przedstawić dowody dotyczące zachowania systemu, zanim zażądają ich klienci, regulatorzy lub atakujący.

Bezpieczeństwo AI Sandia przechodzi z laboratorium do działalności startupów

Wydarzenie przełożyło kwestie bezpieczeństwa narodowego na pytania operacyjne, z którymi młode firmy już się mierzą.

Daybreak Labs zorganizowało bezpłatne spotkanie Lunch and Learn w Livermore w Kalifornii, w godzinach od 11:30 do 13:30. Ten inkubator non-profit wspiera startupy z obszaru nauk biologicznych i deep tech w regionie Tri-Valley.

W panelu udział wzięli Amanda Dodd, Gayle Thayer, Philip Kegelmeyer i Jonathan Crussell z Sandia. Ich doświadczenie obejmowało analizę bezpieczeństwa narodowego, bezpieczne algorytmy, analitykę danych przeciwnika, bezpieczeństwo oprogramowania i agentowe przepływy pracy AI.

Dodd, dyrektorka ds. obliczeń i analiz na rzecz bezpieczeństwa narodowego w Sandia, ujęła dyskusję wokół podatności tworzonych przez szybkie wdrażanie technologii. Porównała obecną ekspansję AI z powszechnym upowszechnieniem internetu w latach 90.

Jej porównanie dotyczyło nie nostalgii, lecz niepewności. Łączność internetowa stworzyła wartościowe usługi, jednocześnie wystawiając systemy na ataki i tryby awarii, których wiele organizacji nie przewidziało. AI wprowadza teraz podobną niepewność do systemów generujących treści, rekomendujących decyzje, a czasem podejmujących działania.

Według programu wydarzenia dyskusja obejmowała szybkość kontra bezpieczeństwo, innowacje kontra regulacje oraz ryzyka związane z zespołami ludzi i AI. Analizowano także nakładanie się priorytetów sektora publicznego i prywatnego.

Późniejsza relacja z panelu opublikowana przez Sandia opisała trzy biznesowe konsekwencje zagrożeń AI: utratę własności intelektualnej, zakłócenia operacyjne i ryzyko regulacyjne. Te skutki nadają słabościom technicznym bezpośrednie znaczenie finansowe i strategiczne.

Thayer, kierowniczka działu Secure Algorithms w Sandia, wyjaśniła, że uwaga poświęcana bezpieczeństwu wykracza poza sprzęt i konwencjonalne oprogramowanie. Badacze coraz częściej analizują same algorytmy oraz zachowania powstające w wyniku ich użycia.

Ta zmiana ma znaczenie, ponieważ aplikacja AI może działać zgodnie z projektem, a mimo to generować niebezpieczne rezultaty. Model może ujawnić wrażliwy kontekst, zaakceptować złośliwą instrukcję lub zachowywać się nieprzewidywalnie poza pierwotnymi warunkami testowymi.

Aplikacja może również zawieść bez ataku. Niejednoznaczne instrukcje, nieznane dane, słabe kryteria oceny lub nieodpowiedni poziom autonomii mogą prowadzić do poważnych błędów. Konwencjonalne skanowanie podatności nie zidentyfikuje każdego z tych problemów.

Podejście Sandia obejmuje red teaming, czyli aktywne badanie systemu pod kątem słabości, zanim znajdzie je przeciwnik. Badacze porównują także niezawodność, bezpieczeństwo i granice wydajności w określonych warunkach.

Testowanie granic różni się od raportowania jednego korzystnego wyniku dokładności. Użyteczna ocena pyta, gdzie system przestaje zachowywać się akceptowalnie, które dane wejściowe wywołują tę zmianę oraz czy monitoring potrafi ją wykryć.

Panel zrobił zatem więcej niż tylko wyliczył ryzyka AI. Połączył identyfikację ryzyka z powtarzalnym testowaniem, ograniczaniem zagrożeń i bezpiecznym projektowaniem. Taka sekwencja przekształca abstrakcyjne ostrzeżenie w dyscyplinę inżynieryjną.

Nic w publicznej relacji nie wskazuje, aby Sandia certyfikowało uczestniczące startupy lub oceniało ich produkty. Sesja była wymianą podejść i obaw, a nie audytem.

To rozróżnienie jest istotne. Dwugodzinny panel nie może ustalić, czy konkretny system AI jest bezpieczny. Może jednak zmienić pytania, które założyciele zadają przed jego wdrożeniem.

Szybkie wdrażanie AI pozostawia startupy z luką w zapewnieniu bezpieczeństwa

Startupy odczuwają presję, ponieważ ich cykle wydawnicze są krótsze niż czas potrzebny do zrozumienia każdego zachowania modelu.

Młoda firma może dodać do produktu hostowany model, nie szkoląc go samodzielnie. W krótkim cyklu rozwoju może połączyć dokumenty klientów, wewnętrzne rejestry lub zewnętrzne narzędzia za pośrednictwem interfejsów programowania aplikacji.

Powstała aplikacja dziedziczy kilka warstw niepewności. Jej działanie zależy od modelu bazowego, instrukcji systemowych, pobranych danych, integracji oprogramowania, uprawnień i danych wejściowych użytkownika.

Zmiana na dowolnej warstwie może zmienić system. Dostawca modelu może zaktualizować jego zachowanie, indeks wyszukiwania może przyjąć nowe dokumenty, a klient może włączyć nową integrację.

Zmiany te tworzą to, co zespoły często nazywają luką w zapewnieniu bezpieczeństwa. Produkt rozwija się szybciej niż dowody firmy dotyczące bezpieczeństwa, niezawodności i akceptowalnego zachowania.

Luka staje się poważniejsza, gdy system AI może działać. Agentowe przepływy pracy to aplikacje, które pozwalają modelowi planować kroki i wywoływać narzędzia przy ograniczonej interwencji człowieka. Mogą wysyłać wiadomości, edytować rekordy, wykonywać kod lub uruchamiać procesy biznesowe.

Każde dodatkowe uprawnienie zwiększa skutki błędnej lub zmanipulowanej odpowiedzi. Słaba odpowiedź w oknie czatu jest niewygodna. Ta sama odpowiedź przekazana narzędziu wykonawczemu może zmienić dane lub ujawnić informacje.

Prompt injection ilustruje tę różnicę. Atakujący umieszcza instrukcje w danych wejściowych użytkownika lub treściach zewnętrznych, licząc na to, że model wykona je zamiast zasad zamierzonych przez programistę.

Aktualna lista ryzyk LLM prowadzona przez OWASP wskazuje prompt injection jako poważną podatność aplikacji. Obejmuje również ujawnianie wrażliwych informacji, słabości łańcucha dostaw, niewłaściwą obsługę wyników oraz nadmierną autonomię.

Ryzyka te przekraczają granice organizacyjne. Dostawca modelu zabezpiecza swoją platformę, podczas gdy twórca aplikacji kontroluje prompty, wyszukiwanie, narzędzia i reguły dostępu. Klient z kolei kontroluje zachowanie użytkowników, połączone dane i konfigurację lokalną.

Żaden pojedynczy uczestnik nie widzi całego systemu. To sprawia, że odpowiedzialność łatwo się rozmywa, dopóki nie dojdzie do incydentu.

Panel Sandia skierował odpowiedzialność z powrotem do organizacji wdrażającej. Administracja publiczna może wnieść badania, ramy działania i niezależną ocenę. Firmy nadal jednak ponoszą odpowiedzialność za ryzyka tworzone przez ich produkty i decyzje operacyjne.

Ta odpowiedzialność nie wymaga od startupu odtworzenia laboratorium narodowego. Wymaga od firmy zdefiniowania, co oznacza bezpieczne zachowanie w jej własnym przypadku użycia.

Asystent badań klinicznych i generator tekstów marketingowych nie powinny mieć identycznych kryteriów akceptacji. Pierwszy z nich obsługuje informacje o wyższych konsekwencjach i wymaga bardziej rygorystycznych dowodów, kontroli dostępu oraz przeglądu.

Startupy muszą również oddzielić jakość modelu od bezpieczeństwa systemu. Model może dobrze radzić sobie z rutynowymi zadaniami, a jednocześnie zawodzić przy danych wejściowych o charakterze adversarialnym. Może odpowiadać poprawnie, ujawniając jednocześnie informacje, których użytkownik nie powinien otrzymać.

Możliwa jest także sytuacja odwrotna. Aplikacja może zapobiegać typowym atakom, lecz nadal generować niewiarygodne rekomendacje. Bezpieczeństwo i użyteczność częściowo się pokrywają, ale jedno nie gwarantuje drugiego.

Dlatego pojedynczy wynik benchmarku zapewnia słabe potwierdzenie bezpieczeństwa. Zespoły potrzebują testów powiązanych z zamierzonymi zadaniami, przewidywalnym niewłaściwym użyciem, granicami dostępu i rzeczywistymi warunkami wdrożenia.

Potrzebują także dokumentacji. Przeszukiwalna baza wiedzy może zachować wersje modeli, wyniki ocen, incydenty i zaakceptowane ryzyka dla zespołów inżynieryjnych i produktowych.

Dokumentacja nie jest biurokracją dodawaną po zakończeniu rozwoju. Pozwala zespołowi zidentyfikować moment zmiany zachowania oraz sprawdzić, czy wcześniejsze ograniczenie ryzyka nadal działa.

Presja ma zarówno bezpośredni, jak i długoterminowy charakter. Nabywcy korporacyjni już pytają dostawców o przetwarzanie danych, dostawców modeli, kontrole dostępu i reagowanie na incydenty. Przyszłe przepisy mogą nadać tym dowodom bardziej formalny charakter.

Startup, który nie potrafi odpowiedzieć na te pytania, może stracić kontrakty jeszcze przed wystąpieniem naruszenia technicznego. W tym sensie godna zaufania AI staje się częścią wiarygodności produktu.

Kluczowym kompromisem jest szybkość kontra dowody

Przekaz Sandia nie wymaga wolniejszych innowacji, ale wymaga silniejszych dowodów, zanim AI otrzyma większe uprawnienia.

Założyciele zwykle traktują szybkość jako warunek przetrwania. Szybkie wdrażanie produktów dostarcza opinii użytkowników, potwierdza popyt i pomaga małej firmie konkurować z organizacjami dysponującymi większymi budżetami.

Zespoły bezpieczeństwa patrzą na to samo wydanie z innej perspektywy. Chcą modeli zagrożeń, testów, logów, granic dostępu i planu reagowania, zanim system uzyska dostęp do wrażliwych danych.

Oba stanowiska zawierają uzasadnione obawy. Opóźnianie każdej eksperymentalnej funkcji do czasu spełnienia przez nią standardów dla zastosowań o wysokiej stawce obciążyłoby wiele startupów. Wdrożenie autonomicznego systemu bez znaczących testów naraziłoby klientów na ryzyka, których nie są w stanie dostrzec.

Praktyczną odpowiedzią jest proporcjonalne zapewnienie bezpieczeństwa. Asystent pisania o niskim wpływie potrzebuje innych mechanizmów kontroli niż agent mogący modyfikować dokumentację finansową, laboratoryjną lub produkcyjną.

Proporcjonalne zapewnienie bezpieczeństwa zaczyna się od zdefiniowanego kontekstu. Zespół dokumentuje, kto będzie korzystać z systemu, do których danych może on uzyskać dostęp, jakie działania może wykonywać i które awarie są niedopuszczalne.

Firma następnie mapuje wiarygodne zagrożenia i zwykłe tryby awarii. Zagrożenia obejmują złośliwe prompty, zatrute dane, skradzione poświadczenia, skompromitowane zależności oraz próby wydobycia prywatnego kontekstu.

Zwykłe awarie zasługują na równą uwagę. Model może błędnie zrozumieć żądanie, wymyślić źródło, wybrać niewłaściwe narzędzie lub kontynuować działanie po tym, jak jego założenia przestaną być ważne.

Kolejnym krokiem jest pomiar. Zespoły tworzą zestawy ewaluacyjne na podstawie realistycznych zadań, znanych przypadków brzegowych i przykładów adversarialnych. Przed uruchomieniem testów zapisują oczekiwane wyniki.

Użyteczny test ma obserwowalny warunek zaliczenia. „Model powinien być bezpieczny” nie jest mierzalne. „Asystent nie może zwracać rekordów spoza obszaru roboczego uwierzytelnionego użytkownika” jest wystarczająco konkretne, by to przetestować.

Podejście Sandia oparte na red teaming dodaje perspektywę atakującego. Testerzy szukają nieoczekiwanych ścieżek przez całą aplikację, w tym jej instrukcje, podłączone dane, interfejsy i narzędzia.

Szersza społeczność laboratoriów Departamentu Energii opisywała podobne działania. Wielolaboratoryjny raport dotyczący bezpieczeństwa AI stwierdza, że statyczne benchmarki nie wystarczają do przewidywania zachowania poza znanymi warunkami.

Raport wskazuje również na ograniczenia zasobów. Kompleksowe ewaluacje zużywają moc obliczeniową, pracę ekspertów i czas. Nowe modele pojawiają się szybciej, niż ewaluatorzy mogą dokładnie ocenić każdy z nich.

To ograniczenie jest szczególnie istotne dla startupów. Małe firmy nie mogą testować każdego możliwego wejścia ani odtwarzać wewnętrznych ewaluacji dostawcy.

Mogą jednak testować aplikację, którą kontrolują. Ukierunkowana ewaluacja powinna obejmować dane firmy, narzędzia, role użytkowników i przepływy pracy o największym wpływie.

Po testach następują działania ograniczające ryzyko. Zespół może ograniczyć uprawnienia, izolować niezaufane treści, walidować wyniki, wymagać zatwierdzenia przez człowieka lub ograniczyć narzędzia, które model może wywoływać.

Najsilniejsza kontrola często ogranicza skutki niepowodzenia. Jeśli asystent jedynie przygotowuje projekt działania, człowiek może go sprawdzić. Jeśli asystent wykonuje to działanie bezpośrednio, firma potrzebuje silniejszej autoryzacji i monitorowania.

Weryfikacja przez człowieka nie jest automatycznie skuteczna. Recenzenci mogą popaść w rutynę, gdy większość wyników wydaje się poprawna, zwłaszcza pod presją czasu.

Zespoły powinny więc wskazać decyzje, w których weryfikacja ma największe znaczenie. Powinny także przedstawić wystarczający kontekst, aby człowiek mógł rozpoznać wątpliwy wynik.

Monitorowanie zamyka pętlę. Logi powinny pokazywać, który model, instrukcje, źródła danych i narzędzia przyczyniły się do istotnego wyniku. Bez tego kontekstu badanie incydentu staje się zgadywaniem.

Żaden z tych kroków nie zapewnia trwałej pewności. Zachowanie modelu, kod aplikacji, dane i atakujący stale się zmieniają. Testowanie musi trwać przez cały cykl życia systemu.

W tym miejscu konflikt między szybkością a dowodami staje się możliwy do opanowania. Startup może działać szybko w ograniczonym środowisku, a następnie rozszerzać uprawnienia wraz ze wzrostem ilości dowodów.

Może zacząć od użytkowników wewnętrznych, danych syntetycznych i narzędzi tylko do odczytu. W późniejszych etapach można dodać dane klientów lub ograniczone działania, gdy system spełni wyraźnie określone progi.

Takie podejście traktuje bezpieczeństwo jako część rozwoju produktu. Unika fałszywego wyboru między blokowaniem każdego eksperymentu a udostępnianiem każdej funkcji bez ograniczeń.

Ramy Pomagają, Ale Nie Certyfikują Produktu

Istniejące ramy organizują pracę nad ryzykiem AI, ale nie mogą określić, czy aplikacja konkretnego startupu jest wystarczająco bezpieczna.

Ramy zarządzania ryzykiem AI NIST zapewniają organizacjom cztery połączone funkcje: govern, map, measure i manage. Zarządzanie obejmuje pozostałe funkcje, zamiast pojawiać się wyłącznie na końcu.

Ramy są dobrowolne i zaprojektowane do szerokiego zastosowania. Ich ramy ryzyka AI pomagają organizacjom uwzględniać wiarygodność w projektowaniu, rozwoju, wdrażaniu, użyciu i ocenie AI.

Dla startupu „govern” oznacza przypisanie uprawnień decyzyjnych i udokumentowanie tolerancji ryzyka. Ktoś musi zdecydować, które przypadki użycia są dozwolone i jakie dowody uzasadniają wydanie produktu.

„Map” oznacza zrozumienie kontekstu. Zespoły identyfikują użytkowników, strony, których to dotyczy, dane, zależności, oczekiwane korzyści i możliwe szkody.

„Measure” obejmuje testowanie i analizę. Zawiera ocenę wydajności, testy bezpieczeństwa, ocenę niepewności i monitorowanie względem zdefiniowanych kryteriów.

„Manage” przekształca ustalenia w priorytety i działania. Firma akceptuje, ogranicza, przenosi lub unika ryzyka w zależności od jego skali i dostępnych mechanizmów kontroli.

NIST opublikował również profil generatywnej AI w lipcu 2024 roku. Profil dostosowuje szersze ramy do ryzyk, które systemy generatywne wprowadzają lub nasilają.

Te zasoby zapewniają słownictwo i strukturę. Nie kontrolują produktu, nie gwarantują zgodności ani nie certyfikują zachowania modelu.

Stanowisko Sandia wydaje się bardziej wymagające technicznie niż samo przyjęcie języka ram. Jej badacze podkreślali red teaming, benchmarking, bezpieczne projektowanie i zrozumienie granic wydajności.

Ten nacisk ma znaczenie, ponieważ dokumenty dotyczące zarządzania mogą zostać oderwane od oprogramowania. Rejestr ryzyka może wskazywać, że rozwiązano problem prompt injection, podczas gdy wdrożony system retrieval nadal przekazuje niezaufane instrukcje do modelu.

Dowody powinny łączyć każde zidentyfikowane ryzyko z mechanizmem kontroli i testem. Firma powinna także wiedzieć, które ryzyka pozostają po zastosowaniu działań ograniczających.

Niezależna ocena może wzmocnić ten proces. Sandia opisała finansowane federalnie centra badawczo-rozwojowe jako źródła bezstronnej analizy technicznej.

Publiczny raport z panelu nie ogłosił jednak ogólnej usługi certyfikacji Sandia dla startupów. Wyraził zainteresowanie ustaleniem, gdzie branża może zaspokoić potrzeby w zakresie zapewnienia bezpieczeństwa, a gdzie laboratoria krajowe mogą wypełnić luki.

To zaproszenie do współpracy, a nie dowód istnienia gotowej ścieżki. Dostęp, zakres, obsługa własności intelektualnej i ustalenia zakupowe zdecydują o tym, czy poszczególne startupy będą mogły uczestniczyć.

Sandia prowadzi już programy łączące laboratoria, uniwersytety i mniejsze firmy. Jej program RAIICE ma zapewniać otwarte zbiory danych i techniczne planowanie rozwoju dla prac nad AI i uczeniem maszynowym związanych z odporną energetyką.

RAIICE pokazuje model partnerstwa, ale nie należy go mylić z lipcowym panelem bezpieczeństwa. Panel nie ogłosił, że uczestnicy dołączyli do tego programu.

To rozróżnienie ujawnia sceptyczny wymiar przekazu Sandia. Wiedza techniczna istnieje, a założyciele firm wyraźnie jej potrzebują. Niepewne pozostaje, jak szeroko ta wiedza może dotrzeć do zespołów komercyjnych.

Laboratoria krajowe działają w ramach określonych misji, zasad kontraktowania i ograniczeń zasobów. Startupy pracują w napiętych harmonogramach i mogą potrzebować odpowiedzi w ciągu kilku dni.

Model współpracy musi połączyć te rytmy. Musi przekształcić metody badawcze w testy, które małe zespoły mogą wykonywać, powtarzać i wyjaśniać klientom.

Regulacje tworzą kolejną niewiadomą. Paneliści mieli podobno opowiadać się za jasnymi zasadami, które pozwalają branży odpowiedzialnie zarządzać ryzykami AI, ale wydarzenie nie przyniosło propozycji standardu prawnego.

Zasady mogą wyjaśniać oczekiwania, lecz mogą też stać się nieaktualne wraz ze zmianą modeli i aplikacji. Wymogi nakazowe mogą premiować odhaczanie list kontrolnych bez poprawy rzeczywistego zachowania.

Reguły skoncentrowane na wynikach stwarzają inny problem. Mogą mówić firmom, jaki rezultat osiągnąć, bez zapewnienia przystępnych sposobów jego wykazania.

Najlepszym sygnałem w krótkim terminie będą praktyczne dowody. Publiczne metody testowania, narzędzia ewaluacyjne wielokrotnego użytku, dostępne zbiory danych i udokumentowane współprace ze startupami pokazałyby, że wizja partnerstwa staje się operacyjna.

Do tego czasu firmy nie powinny twierdzić, że przyjęcie ram dowodzi bezpieczeństwa. Powinny opisywać stosowane mechanizmy kontroli, wykonane testy i ograniczenia, które nadal obserwują.

Na Co Założyciele i Kupujący Powinni Zwracać Uwagę Dalej

Kolejnym sprawdzianem będzie to, czy język ryzyka Sandia przełoży się na powtarzalne praktyki, wiarygodne partnerstwa i jaśniejsze oczekiwania rynkowe.

Pierwszym sygnałem jest konkretna ścieżka współpracy dla małych firm. Sandia stwierdziła, że chce ustalić, gdzie branża może zaspokoić potrzeby w zakresie zapewnienia bezpieczeństwa, a gdzie laboratoria krajowe mogą wypełnić luki.

Przydatna ścieżka określałaby kwalifikujące się projekty, dostępną wiedzę ekspercką, wymagania dotyczące obsługi danych, oczekiwane rezultaty i terminy współpracy. Publiczne studia przypadków ułatwiłyby ocenę tego modelu.

Jeśli takie szczegóły się pojawią, wzmocnią centralne twierdzenie panelu. Pokazałyby, że metody laboratoriów krajowych mogą wyjść poza dyskusję i wspierać rozwój komercyjny.

Jeśli żadna ścieżka nie powstanie, wydarzenie pozostanie wartościowym działaniem informacyjnym, ale zaoferuje ograniczoną pomoc operacyjną. Startupy nadal będą musiały tworzyć własne programy testowe lub zatrudniać zewnętrznych specjalistów.

Drugim sygnałem jest walidacja techniczna powiązana z rzeczywistymi aplikacjami. Założyciele powinni obserwować publikowane ewaluacje obejmujące prompt injection, wycieki danych, manipulację modelem, niebezpieczne użycie narzędzi i zachowanie poza normalnymi warunkami testowymi.

Najbardziej użyteczne prace będą przedstawiać warunki awarii i ryzyka rezydualne, a nie wyłącznie korzystne wyniki. Powinny wyjaśniać, co zmieniło się po testowaniu i czy mechanizmy ograniczające przetrwały kolejny cykl ataków.

Takie dowody wzmocniłyby argument, że godna zaufania AI tworzy przewagę konkurencyjną. Kupujący mogą porównywać dostawców z większą pewnością, gdy firmy przedstawiają powtarzalne wyniki.

Brak dowodów osłabiłby ten argument. Sam język bezpieczeństwa nie odróżnia jednego produktu od drugiego, szczególnie gdy każdy dostawca składa podobne obietnice.

Trzecim sygnałem jest przejście od szerokich ram do jaśniejszych oczekiwań klientów i regulatorów. NIST aktualizuje AI RMF 1.0 i opracowuje dodatkowe profile dla cyberbezpieczeństwa i infrastruktury krytycznej.

Założyciele powinni śledzić, czy ankiety dla przedsiębiorstw, wymagania zakupowe, przeglądy ubezpieczeniowe i zasady sektorowe zaczną wymagać podobnych dowodów. Zbieżność zmniejszyłaby niepewność co do tego, w jakie mechanizmy kontroli warto wcześnie inwestować.

Fragmentacja stworzyłaby większe obciążenie. Startup mógłby spotkać się z różnymi formatami ewaluacji u każdego klienta, regulatora i partnera.

Kupujący również odgrywają rolę w kształtowaniu tego wyniku. Powinni pytać dostawców, które modele i źródła danych wspierają dany przepływ pracy, jakie działania system może podejmować i jak dostawca testuje granice dostępu.

Powinni także pytać, co dzieje się po aktualizacji modelu. Wcześniejsza ewaluacja zapewnia ograniczoną ochronę, jeśli dostawca zmienia zachowanie lub aplikacja zyskuje nowe narzędzia.

Deweloperzy powinni traktować każde dodatkowe uprawnienie jako nową decyzję dotyczącą bezpieczeństwa. Połączenie asystenta z pocztą e-mail, kodem źródłowym, rejestrami klientów lub danymi laboratoryjnymi zmienia skutki niepowodzenia.

Pracownicy umysłowi również powinni rozumieć te granice. Potrzebują jasnych sygnałów, które informacje mogą trafiać do systemu AI, a które wyniki wymagają niezależnej weryfikacji.

Panel Sandia nie rozstrzygnął tych kwestii. Utrudnił startupom ich dalsze odkładanie.

Najtrwalsza lekcja jest taka, że bezpieczeństwo AI obejmuje cały system operacyjny otaczający model. Dane, instrukcje, oprogramowanie, uprawnienia, użytkownicy i monitorowanie wpływają na wynik.

Ta lekcja wyjaśnia również, co założyciele powinni zrobić teraz. Zdefiniować system, uszeregować jego awarie o największym wpływie, przetestować te awarie, ograniczyć uprawnienia i zachować dowody.

Następnie należy zapytać, czy każda nowa funkcja zasługuje na otrzymywane uprawnienia. Przekonujące demo nie jest przypadkiem zapewnienia bezpieczeństwa, a reputacja dostawcy nie zastępuje testowania aplikacji.

Wskazówki Sandia dotyczące bezpieczeństwa AI będą miały największe znaczenie, jeśli firmy przekształcą tę dyscyplinę w rutynową pracę nad produktem. Założyciele powinni zacząć od wybrania jednego istotnego przepływu pracy i udokumentowania jego ryzyk, mechanizmów kontroli, testów oraz nierozwiązanych ograniczeń.