TL; DR
Każda komisja pyta teraz o ryzyko związane ze sztuczną inteligencją, a większość zespołów ds. bezpieczeństwa odpowiada przymiotnikami zamiast liczbami. Ramy zarządzania wskazują, czym należy zarządzać. Nie wskazują jednak, co należy liczyć. Wszystkie te wskaźniki ryzyka AI pochodzą z tego samego źródła: kodu, który Twoja organizacja już dostarcza.
- Strategia sztucznej inteligencji opartej na agentach składa się z trzech warstw, a tylko jedna z nich stanowi model. Co agent pisze, do czego jest podłączony i co pobiera. Większość programów mierzy pierwsze i ignoruje dwa pozostałe.
- Model nie uwzględnia promienia wybuchu. Znajduje się on w pliku umiejętności, konfiguracji MCP, zakresie narzędzia i poświadczeniach, z którymi agent pracuje. Czysta ocena modelu i agent z nadmierną liczbą uprawnień swobodnie współistnieją.
- Dziewięć wskaźników ryzyka związanego ze sztuczną inteligencją, z których każdy jest liczbą, a nie przymiotnikiem. Niezatwierdzone zasoby sztucznej inteligencji, szybkie ścieżki wstrzykiwania, które docierają do ujścia narzędzia, sekrety w
.mcp/servers.json, zależności dodane przez agenta zostały oznaczone przed powstaniem podpisu. - Jeśli nie możesz podać takiej liczby w tym kwartale, problem nie leży w metryce. Inwentaryzacja jest. Zacznij od trzech liczeń, a nie od programu.
Co tak naprawdę oznacza ryzyko związane ze sztuczną inteligencją, kiedy to Ty dostarczasz oprogramowanie?
Zapytaj dziesięć osób, co oznacza ryzyko związane ze sztuczną inteligencją, a otrzymasz dziesięć odpowiedzi. Błąd modelu. Halucynacja. Wyciek danych. Narażenie na regulacje. Zmiana pracy. Wszystkie te rzeczy są prawdziwe, wszystkie warte uwagi i żadna z nich nie podlega ocenie zespołu bezpieczeństwa we wtorkowe popołudnie.
Istnieje węższa wersja pytania, na które może odpowiedzieć zespół ds. bezpieczeństwa: jaką sztuczną inteligencję wykorzystujemy w oprogramowaniu, które tworzymy, jaki jest jej zasięg i co się dzieje, gdy ktoś nią manipuluje. Ta wersja ma odpowiedź, która znajduje się w Twoich repozytoriach i pipelinea nie w dokumencie politycznym.
To jest wersja ryzyka związanego ze sztuczną inteligencją, o której mowa w tym poście. Nie dlatego, że pytania dotyczące zarządzania nie mają znaczenia, ale dlatego, że nie można na nie odpowiedzieć, dopóki nie zostanie ono rozwiązane. Framework wymaga inwentaryzacji systemów sztucznej inteligencji. Nie informuje, że inwentaryzacja znajduje się w… .mcp/servers.json plik, którego nikt nie otwierał od czasu jego powstania commitprzetrząsać.
Dlaczego większość programów ryzyka związanego ze sztuczną inteligencją mierzy niewłaściwe rzeczy?
Istnieją trzy schematy błędów. Większość organizacji stosuje co najmniej dwa z nich.
- Pomiar adopcji zamiast ekspozycji. „72% naszych programistów korzysta z narzędzi AI” to wskaźnik produktywności opatrzony plakietką bezpieczeństwa. Nie mówi on nic o tym, co te narzędzia potrafią osiągnąć.
- Pomiar modelu, a nie systemu. Red-teaming punktu końcowego odpowiada na pytanie, czy model da się namówić do powiedzenia czegoś, czego nie powinien. Nie odpowiada jednak na pytanie, co stanie się dalej, ponieważ promień rażenia znajduje się w zakresie narzędzia, w danych uwierzytelniających, z którymi agent działa, oraz w plikach konfiguracyjnych, które definiują oba te elementy. Czysta ewaluacja modelu i agent z nadmierną liczbą uprawnień współistnieją bardzo wygodnie.
- Mierzenie tego, co łatwo policzyć. Liczba opublikowanych polityk dotyczących sztucznej inteligencji. Liczba pracowników, którzy ukończyli szkolenie z zakresu sztucznej inteligencji. Liczby te niezawodnie rosną i nie mają żadnej korelacji.
Ramy zarządzania ryzykiem NIST AI wyraźnie wskazuje, że pomiar jest jedną z czterech podstawowych funkcji, obok zarządzania, mapowania i rządzenia. Ramy te są celowo oparte na wynikach, a nie na normach, co jest prawidłowe w przypadku standard i nieprzydatne we wtorek. Nadal musisz zdecydować, co liczyć.
Które wskaźniki ryzyka związanego ze sztuczną inteligencją faktycznie coś mówią?
Dziewięć metryk. Każda z nich jest liczbą, każda zmienia się wraz ze zmianą ekspozycji i każdą można wygenerować z kodu, a nie z ankiety.
| metryczny | Dlaczego jest to ważne | Skąd pochodzi ta liczba |
|---|---|---|
| 01Łączna liczba odkrytych zasobów sztucznej inteligencji i zmiana od zeszłego miesiąca | Nie możesz raportować ryzyka związanego ze sztuczną inteligencją, którego nigdy nie policzyłeś. Trend jest ważniejszy niż liczba bezwzględna. | Ciągłe odkrywanie modeli, struktur, zestawów danych, punktów końcowych wnioskowania, agentów, serwerów MCP, umiejętności i narzędzi do kodowania AI |
| 02Niezatwierdzone zasoby AI jako procent całości | To Twój wskaźnik cienia AI. To najbardziej wiarygodny wskaźnik ryzyka AI dla zarządu. | Monitorowanie stanu zatwierdzenia dla każdego zasobu w oparciu o Twoją polisę |
| 03Zasoby sztucznej inteligencji bez wskazanego właściciela | Aktywa, których nikt nie posiada, to aktywa, których nikt nie naprawi. Zwykle jest to najbrzydsza liczba w zestawie. | Własność śledzona w odniesieniu do aktywów |
| 04Szybkie ścieżki wtrysku docierające do zlewu narzędzia | Niepewne dane wejściowe docierające do monitu systemowego mają znaczenie tylko wtedy, gdy po drugiej stronie znajduje się coś niebezpiecznego | Wykrywanie ryzyka AI zmapowane na OWASP Top 10 dla aplikacji LLM |
| 05Używane serwery MCP i liczba wyników przenoszenia | Konfiguracja MCP to miejsce, w którym agent przyjmuje polecenia. To również miejsce, w którym gromadzą się dane uwierzytelniające. | Analiza konfiguracji serwera MCP jako artefaktu bezpieczeństwa |
| 06Sekrety odkryte w plikach konfiguracyjnych AI | Badania przeprowadzone w 2026 roku wykazały, że w plikach konfiguracyjnych MCP w publicznym serwisie GitHub znajduje się ponad 24 000 sekretów, z czego ponad 2,000 jest nadal ważnych | Wykrywanie sekretów przez kod, konfiguracje, kontenery i pipelines |
| 07Zależności dodane przez agenta zostały oznaczone przed powstaniem podpisu publicznego | Agenci szybko pobierają pakiety, a nazwa wymyślona przez Twój model jest podatną na ataki powierzchnią | Wczesne ostrzeganie przed złośliwym oprogramowaniemwykrywanie dowodów, a następnie walidacja za pomocą sztucznej inteligencji |
| 08Udział ustaleń dotyczących sztucznej inteligencji, które są osiągalne i znajdują się w aktywnie rozwijanym kodzie | Oddziela zaległości, których nigdy nie uda Ci się usunąć, od pracy, która zmienia Twoje narażenie | Lejek priorytetyzacji sztucznej inteligencji |
| 09Procent autorstwa agenta pull requests połączone z zatwierdzeniem ludzkim | Wskaźnik zarządzania, o który poprosi organ regulacyjny, a którego nikt nie śledzi | Pull request analiza i bramy zatwierdzające |
Jeśli bierzesz tylko jedną, weź metrykę 02. Stosunek niezatwierdzonych zasobów AI do całkowitych zasobów AI to liczba, która przetrwa tłumaczenie z zespołu ds. bezpieczeństwa na audyt committee, i porusza się, gdy faktycznie coś robisz.
Co powinna obejmować strategia sztucznej inteligencji opartej na agentach?
Trzy warstwy. Błąd, który popełnia prawie każdy, to zaczynanie od pierwszej i kończenie na niej.
- Warstwa pierwsza: co pisze agent. Wygenerowany kod jest podatny na te same klasy podatności, co kod ludzki, a badania prowadzone od 2022 roku konsekwentnie wykazują, że znaczna część programów generowanych przez sztuczną inteligencję zawiera luki w zabezpieczeniach. Ta warstwa jest najbardziej znana i właśnie dlatego pochłania całą uwagę.
- Warstwa druga: to, do czego podłączony jest agent. Pliki umiejętności, pliki reguł, konfiguracje serwera MCP, zakresy narzędzi, dane uwierzytelniające, z którymi działa agent. To warstwa, która określa zasięg skutecznego ataku i jest niewidoczna dla wszystkich, którzy testują model za pośrednictwem jego punktu końcowego. ATLAS MITROWY Kataloguje ten obszar bezpośrednio: studium przypadku „Backdoor w pliku reguł”, AML.CS0041, opisuje znaki o zerowej szerokości w pliku reguł, które przekształcają dokumentację w instrukcje, których agent przestrzega w milczeniu. Recenzent czytający pull request nic nie widzi.
- Warstwa trzecia: to, co agent pobiera. Zależności, modele, zestawy danych, narzędzia zewnętrzne. Badania zaprezentowane na konferencji USENIX Security w 2025 roku wygenerowały 2.23 miliona próbek kodu w 16 modelach i wykazały, że 19.7% rekomendowanych pakietów nie istniało, generując ponad 205 000 unikalnych, halucynacyjnych nazw. Atakujący nie muszą już atakować administratora. Rejestrują nazwę wymyśloną przez agenta i czekają.
Strategia agentowa AI obejmująca tylko warstwę pierwszą generuje czysty raport i niezmieniony profil ryzyka AI. OWASP Top 10 dla aplikacji LLM odzwierciedla to w swojej własnej strukturze: nadmierna agencja znajduje się na szczycie listycisponieważ jest to problem z okablowaniem, a nie modelem.
Jak wdrożyć to rozwiązanie, nie spowalniając pracy agentów?
Instynkt podpowiada, żeby wszystko blokować. To się nie sprawdza, bo cała idea agenta to przepustowość, a kontrola, która zmniejsza przepustowość o połowę, zostaje usunięta w ciągu jednej czwartej.
Trzy zasady wdrażania, które są aktualne:
- Pomiar ciągły, bramka selektywna. Wszystkie dziewięć metryk ryzyka AI można zbierać podczas każdego skanowania bez blokowania czegokolwiek. Zarezerwuj twarde bramki dla niewielkiego zestawu, w którym awaria jest nieodwracalna: złośliwa zależność, aktywny sekret, niezatwierdzony model przetwarzający regulowane dane.
- Umieść zabezpieczenia tam, gdzie agent już jest. Agent połączony przez MCP łączy się z platformą bezpieczeństwa podczas generowania, skanowania tego, co właśnie zapisał, i iteruje poprawki, aż kod spełni Twoje progi. Na tym etapie nie ma żadnego człowieka w pętli i niczego do zainstalowania w miejscu działania agenta. To jedyny punkt interwencji, który skaluje się wraz z przepustowością agenta, a nie w jej przeciwieństwie.
- Utrzymaj człowieka na pierwszym miejscu pull request. Wszystko, co trafia do kodu produkcyjnego, jest zatwierdzane. To nie jest przestroga, to stanowisko projektowe, do którego i tak nakłania nas unijna ustawa o sztucznej inteligencji, a znacznie taniej jest wdrożyć je teraz niż modernizować pod presją audytu. Jest to również metryka 09, dlatego warto śledzić ją od samego początku.
Drugim rzędem, który w większości organizacji pozostaje nieprzypisany, jest rząd. Pliki konfiguracyjne znajdują się pomiędzy bezpieczeństwem aplikacji, które traktuje je jako infrastrukturę, a inżynierią platformy, która traktuje je jako dokumentację. To właśnie ta luka jest miejscem, w którym trafiają interesujące ataki.
Jak rozpocząć pomiar ryzyka związanego ze sztuczną inteligencją w tym kwartale?
Nie twórz całego programu. Podaj trzy liczby. Policz swoje zasoby sztucznej inteligencji. Policz, ile z nich nikt nie zatwierdził. Policz, ile sekretów znajduje się w plikach konfiguracyjnych sztucznej inteligencji. Te trzy mieszczą się na jednym slajdzie; wszystkie są do obrony i będą gorsze, niż ktokolwiek o nie prosił.
Następnie wybierz ten, który jest najgorszy i napraw go przed kolejnym posiedzeniem zarządu. To jest działający program zarządzania ryzykiem związanym ze sztuczną inteligencją. Wszystko inne to tylko dopracowywanie.
Organizacje, które będą zmagać się z ryzykiem związanym ze sztuczną inteligencją w 2027 roku, to nie te, które działały szybko. To te, które spędziły 2026 rok na opracowywaniu polityk dotyczących sztucznej inteligencji i nigdy niczego nie policzyły. Polityka, której nikt nie jest w stanie zmierzyć, to dokument. Mierniki ryzyka związanego ze sztuczną inteligencją to właśnie one przekształcają je w narzędzie kontroli.
Zobacz swoje własne liczby. Podłącz repozytorium, a Xygeni zwróci Ci inwentarz sztucznej inteligencji, niezatwierdzone zasoby, ryzyka przypisane do ram używanych przez audytorów oraz listę zasobów AI-BOM, którą możesz wyeksportować. Zacznij za darmo or zarezerwować demo.
FAQ
Jaka jest różnica między ryzykiem związanym ze sztuczną inteligencją a bezpieczeństwem związanym ze sztuczną inteligencją?
Bezpieczeństwo sztucznej inteligencji (AI) opiera się przede wszystkim na tym, co model robi: czy zachowuje się zgodnie z przeznaczeniem, czy jego wyniki są szkodliwe, czy można nim manipulować w celu odrzucenia czegoś, co powinno zostać zablokowane. Ryzyko AI, w kontekście bezpieczeństwa, dotyczy tego, co zainfekowany lub nieprawidłowo działający system AI może osiągnąć w środowisku użytkownika. Te dwa zagadnienia nakładają się na siebie, ale są one nadzorowane przez różne zespoły i mierzone za pomocą innych narzędzi. Zespół ds. bezpieczeństwa może działać już dziś w tym drugim przypadku.
Ile wskaźników ryzyka związanego ze sztuczną inteligencją powinniśmy przedstawić zarządowi?
Od trzech do pięciu. Zarząd nie może działać na podstawie dziewięciu liczb, a talia z dziewięcioma liczbami zazwyczaj ukrywa tę, która ma znaczenie. Podaj całkowitą liczbę zasobów AI, odsetek niezatwierdzonych i jeden wskaźnik narażenia, taki jak osiągalne wyniki AI w aktywnym rozwoju. Resztę zachowaj do przeglądu operacyjnego.
Czy potrzebujemy AI-BOM, skoro nie ma jeszcze przepisów, które by to wymagały?
Obecnie żadne przepisy nie nakładają obowiązku sporządzania AI-BOM, dlatego jego utworzenie jest tanie teraz, a kosztowne w przyszłości. Obecnie istnieją dwa formaty nadające się do odczytu maszynowego i audytor zaakceptuje każdy z nich. Wartość nie tkwi w zgodności; chodzi o to, że wygenerowanie pliku wymusza posiadanie inwentarza, a od inwentarza zależy każda metryka ryzyka AI.
Nasi programiści korzystają z narzędzi AI, których nigdy nie zatwierdziliśmy. Od czego zacząć?
Licz, zanim zaczniesz działać na policji. Ogłoszenie polityki dotyczącej narzędzi, których nie widać, prowadzi do ich nielegalnego wykorzystania i niszczy potrzebną widoczność. Najpierw przeprowadź dochodzenie, opublikuj wewnętrznie liczbę bez podania źródła i wykorzystaj ją do uzgodnienia zatwierdzonej listy, która odzwierciedla rzeczywiste potrzeby ludzi. Egzekwowanie prawa jest o wiele skuteczniejsze, gdy następuje po dowodach, niż gdy je poprzedza.
