Ta strona używa plików cookies, aby zapewnić najlepszą jakość korzystania z naszego serwisu oraz do celów analitycznych. Klikając "Akceptuję", wyrażasz zgodę na używanie wszystkich plików cookies. Możesz również odrzucić zgodę, co spowoduje zablokowanie plików cookies analitycznych. Więcej informacji znajdziesz w naszej Polityce Prywatności.
Microsoft i NVIDIA proponują wspólne podejście do ryzyka modeli open-weight
Otwartość wag nie przesądza sama o poziomie ryzyka modelu AI.
Ocena powinna obejmować model, zastosowanie, środowisko wdrożenia i zabezpieczenia.
Wspólna taksonomia obejmuje cyberbezpieczeństwo, ochronę danych, treści, interakcję człowiek AI i uprzedzenia.
Przy samodzielnym wdrożeniu przedsiębiorstwo może przejąć część zabezpieczeń zapewnianych wcześniej przez dostawcę usługi.
Sponsorowane
Odkryj rewolucyjną metodę nauki języków
Sprawdź jak w 30 dni opanować podstawy dowolnego języka obcego bez wychodzenia z domu.
Microsoft i NVIDIA opublikowały dokument Risk Management for Open-Weight Models in Enterprise, poświęcony zarządzaniu ryzykiem modeli AI z dostępnymi wagami, wykorzystywanych przez przedsiębiorstwa. To pierwsza publikacja z planowanej serii wspólnych materiałów, które mają pomóc firmom odpowiadać na trzy podstawowe pytania: do czego model będzie używany, co może pójść nie tak w danym zastosowaniu oraz jakie dowody i zabezpieczenia są potrzebne, aby ograniczyć ryzyko. Autorzy odchodzą przy tym od prostego podziału na modele open-weight i closed-weight. Ich zdaniem sama dostępność wag nie określa poziomu bezpieczeństwa całego systemu.
Ryzyko zależy od wdrożenia, nie tylko od modelu
Modele open-weight dają organizacjom większą możliwość sprawdzania, modyfikowania i uruchamiania modeli we własnych środowiskach. Ta elastyczność zmienia jednak także sposób rozkładania odpowiedzialności za zabezpieczenia. Firma musi nie tylko wybrać model, lecz także ustalić, w jakim procesie zostanie on użyty, kto będzie jego użytkownikiem, do jakich danych uzyska dostęp i jakie narzędzia zostaną z nim połączone. Ten sam model może stwarzać inne wyzwania, gdy pomaga pracownikowi przygotować dokument, a inne, gdy działa w procesie obsługi klienta. Różnicę robi również architektura systemu. Samodzielny punkt dostępu do modelu nie jest tym samym co rozwiązanie połączone z zewnętrznymi danymi, narzędziami lub dodatkowymi usługami. Dlatego ocena powinna uwzględniać pochodzenie modelu, przeznaczenie, użytkowników, warunki wdrożenia oraz kontrole działające wokół niego.
Model open-weight może być uruchamiany samodzielnie albo używany za pośrednictwem zarządzanej platformy.
Słownik artykułu
Pojęcia, które warto znać
Krótkie objaśnienia terminów występujących w tekście. Każde hasło prowadzi do szerszej definicji i przykładów użycia.
Ryzyko może powstać na poziomie modelu, ale skuteczna kontrola może znajdować się w aplikacji, środowisku wnioskowania lub procesach operacyjnych.
Ocena modelu nie wystarcza do potwierdzenia bezpieczeństwa agenta lub aplikacji korzystającej z tego modelu.
Odpowiedzialność za zabezpieczenia zależy od konfiguracji usługi i sposobu wdrożenia.
Wspólny język dla zespołów odpowiedzialnych za AI
Wspólne opracowanie Microsoftu i NVIDIA porządkuje ryzyka w pięciu szerokich kategoriach: cyberbezpieczeństwo, ochrona danych, treści, interakcja człowiek AI oraz uprzedzenia. Autorzy odwołują się przy tym do uznanych standardów i ram, w tym standardów International Organization for Standardization oraz NIST AI Risk Management Framework. Taksonomia nie ma być gotową polityką ani uniwersalną listą kontrolną do odhaczania. Przedsiębiorstwa powinny dopasować ją do własnych systemów, zastosowań i kryteriów ryzyka, a następnie połączyć rozpoznane problemy z odpowiednimi testami, działaniami ograniczającymi oraz konkretnymi właścicielami odpowiedzialności. Taki sposób pracy ma ułatwić współpracę między inżynierami, zespołami bezpieczeństwa, prawnikami, specjalistami do spraw bezpieczeństwa AI i biznesem. Bez wspólnego słownika te grupy mogą inaczej opisywać ten sam problem, a w konsekwencji inaczej oceniać jego wagę i sposób obsługi.
Ewaluacje mają dostarczyć dowodów
Sama lista potencjalnych zagrożeń nie mówi jeszcze, czy konkretny model nadaje się do danego zastosowania. Dlatego dokument łączy wybrane ryzyka z ewaluacjami, które mogą dostarczyć zespołom dowodów potrzebnych do podjęcia decyzji. Podejście zaczyna się od problemu istotnego dla danego wdrożenia, a następnie prowadzi do testu pozwalającego sprawdzić zachowanie systemu w odpowiednim kontekście. Wyniki nie powinny być interpretowane w oderwaniu od architektury i celu użycia. Ten sam rezultat może mieć inne znaczenie dla wewnętrznego narzędzia wspierającego pracownika, a inne dla aplikacji dostępnej bezpośrednio dla klientów. Microsoft i NVIDIA zapowiadają rozwijanie wspólnego repozytorium, w którym będą udostępniać kolejne ewaluacje oraz wskazywać istniejące zasoby pomocne przy ocenie konkretnych zagrożeń. Z czasem materiały mają być uzupełniane wraz z pojawianiem się nowych modeli, sposobów wdrażania i nowych rodzajów ryzyka.
Model to tylko jedna warstwa całego systemu
Pierwszy dokument koncentruje się przede wszystkim na warstwie modelu. Autorzy podkreślają jednak, że sprawdzenie modelu nie ustanawia automatycznie bezpieczeństwa całego agenta ani aplikacji. Zespół wdrożeniowy powinien osobno ocenić uprawnienia, dostęp do danych, wykorzystywane narzędzia, środowisko uruchomieniowe oraz kontrole operacyjne. Ma to znaczenie zwłaszcza wtedy, gdy model może wykonywać działania poza samym generowaniem odpowiedzi. W zależności od rodzaju ryzyka zabezpieczenia mogą obejmować zmiany w modelu, kontrolę dostępu, filtrowanie danych wejściowych i wyjściowych, monitoring albo udział człowieka w procesie decyzyjnym. Nie wszystkie zabezpieczenia muszą znajdować się w tej samej warstwie. Ryzyko wynikające z modelu może być ograniczane przez konfigurację aplikacji, a problem związany z dostępem do danych przez uprawnienia i procesy operacyjne. Najważniejsze jest przypisanie każdego rozpoznanego ryzyka do kontroli, która rzeczywiście działa w danym systemie.
Kto odpowiada za zabezpieczenia
Dostęp do wag i sposób wdrożenia modelu to dwie odrębne decyzje. Model open-weight może być używany za pośrednictwem zarządzanej platformy, więc sama otwartość wag nie oznacza, że przedsiębiorstwo musi samodzielnie obsługiwać każdy element infrastruktury. Zakres odpowiedzialności zależy od konkretnej usługi i konfiguracji wdrożenia. Jeżeli firma uruchamia model we własnym środowisku, może przejąć część kontroli, które w przypadku usługi zarządzanej zapewnia dostawca. Dotyczy to między innymi kontroli dostępu, filtrowania, monitorowania i reagowania na problemy. Podział odpowiedzialności powinien zostać opisany przed uruchomieniem systemu, a nie dopiero po wystąpieniu niepożądanego zdarzenia. Zabezpieczenia również nie są rozwiązaniem ustawianym raz na zawsze. Gdy zmieniają się model, aplikacja, dane, narzędzia lub sposób użycia, organizacja powinna ponownie sprawdzić, czy przyjęte kontrole nadal odpowiadają rozpoznanym zagrożeniom.
Narzędzia do testowania i dalszy rozwój wytycznych
Microsoft wskazuje, że Microsoft Foundry pomaga przedsiębiorstwom oceniać jakość, ugruntowanie odpowiedzi i bezpieczeństwo z użyciem wbudowanych oraz własnych ewaluacji, a także automatycznego red teamingu. Konfigurowalne mechanizmy bezpieczeństwa treści mają wykrywać i ograniczać szkodliwe dane wejściowe, szkodliwe odpowiedzi oraz ataki na prompty. Producent zaznacza jednak, że zespoły powinny potwierdzić dostępność konkretnych kontroli dla wybranego modelu i wdrożenia, w tym sprawdzić, czy dana funkcja nie jest jeszcze w fazie preview. Narzędzia dostawcy powinny być łączone z testami specyficznymi dla aplikacji, monitoringiem i nadzorem człowieka. Kolejne prace Microsoftu i NVIDIA mają rozszerzyć obecne podejście poza warstwę modelu, na środowisko uruchomieniowe, warstwę harness oraz aplikację. Wspólne repozytorium ma służyć także do publikowania dodatkowych zasobów ewaluacyjnych, w tym materiałów tworzonych przez szerszą społeczność.
