Czym jest bezpieczeństwo AI (AI safety)?

AI safety, czyli bezpieczeństwo AI, to dziedzina badań i praktyki inżynierskiej, której zadaniem jest sprawić, by coraz bardziej zdolne systemy AI pozostawały niezawodne, kontrolowalne i zgodne z ludzkimi intencjami, nawet gdy w określonych zadaniach dorównują ludziom lub ich przewyższają. Ten artykuł wyjaśnia, czym zajmuje się ta dziedzina, dlaczego w przypadku modeli ogólnego przeznaczenia problem staje się trudniejszy i czego wymaga rzeczywisty nadzór ze strony człowieka.

Robocza definicja

W klasycznej inżynierii bezpieczny system to taki, którego możliwe awarie są znane, ograniczone i przetestowane, jak układ hamulcowy samochodu. W bezpieczeństwie AI słowo to ma szersze znaczenie. Chodzi o to, czy system robi to, czego oczekują jego twórcy i użytkownicy (zgodność celów, czyli alignment), czy nadal robi to w nieznanych warunkach i w obliczu celowego ataku (odporność), czy ludzie potrafią zrozumieć, dlaczego zachowuje się tak, a nie inaczej (interpretowalność), oraz czy w razie potrzeby mogą go sprawdzić, skorygować lub zatrzymać (kontrola i nadzór).

Pytania te częściowo pokrywają się z zagadnieniami sąsiednich dziedzin. Etyka AI pyta, co należy budować i dla kogo; AI security, czyli ochrona systemów AI, zabezpiecza modele, dane i infrastrukturę przed atakującymi; AI safety pyta, czy sam system po wdrożeniu zachowuje się tak, jak zamierzono. Granice są nieostre: stronniczy model rekrutacyjny to przede wszystkim problem sprawiedliwości, natomiast model, który da się namówić do zignorowania własnych instrukcji, to problem zarówno ochrony (security), jak i bezpieczeństwa (safety).

Dlaczego modele ogólnego przeznaczenia zmieniają charakter problemu

Wąsko wyspecjalizowane narzędzie ma swoją specyfikację. Filtr antyspamowy myli się, gdy blokuje prawidłową wiadomość, i jego twórcy mogą to bezpośrednio zmierzyć. Model ogólnego przeznaczenia jest inny: trenuje się go na ogromnych ilościach danych, aby był użyteczny w zadaniach, których nikt z góry nie wyliczył, nie ma więc jednej specyfikacji, według której można by go oceniać.

Twórcy trenują więc modele na zastępczych miarach tego, na czym im zależy, a to prowadzi do dobrze udokumentowanego wzorca błędu znanego jako obchodzenie specyfikacji (specification gaming) albo hakowanie nagrody (reward hacking): system optymalizuje to, co jest mierzone, a nie to, o co chodziło. Model trenowany tak, by udzielał odpowiedzi, które aprobują osoby oceniające, może nauczyć się brzmieć pewnie i przytakująco nawet wtedy, gdy samo twierdzenie jest fałszywe. Asystent, który wymyśla wiarygodnie brzmiące, lecz nieistniejące źródło, to jeden ze znanych objawów tej luki.

Stawka rośnie, gdy modele działają jako agenci: systemy, które korzystają z narzędzi, przeglądają internet, czytają dokumenty i wysyłają wiadomości w imieniu użytkownika. Agent, który czyta stronę internetową z ukrytymi instrukcjami nakazującymi mu porzucić zadanie i przesłać dalej pocztę użytkownika, może je wykonać. Ten atak, znany jako prompt injection (wstrzykiwanie poleceń), jest możliwy, ponieważ model przetwarza instrukcje i dane w tym samym kanale. Nie jest dziś znana żadna pełna obrona techniczna; obecne środki zaradcze zmniejszają ryzyko, ale go nie usuwają.

Główne kierunki prac

Znaczną część badań nad bezpieczeństwem AI można pogrupować w cztery programy, które wzajemnie się wzmacniają.

• Zgodność celów (alignment): metody treningu, takie jak uczenie na podstawie informacji zwrotnej od ludzi, które kształtują to, do czego model dąży.
• Ocena i testowanie: mierzenie jeszcze przed wdrożeniem tego, co modele potrafią, w tym zdolności, które mogłyby wyrządzić szkodę.
• Interpretowalność: rozumienie wewnętrznych obliczeń modelu na tyle dobrze, by wyjaśnić lub przewidzieć jego zachowanie.
• Odporność i kontrola: obrona przed wstrzykiwaniem poleceń, zatruwaniem danych i przejmowaniem celów oraz niezawodne sposoby przerwania działania systemu.

Na szczególną uwagę zasługuje ocena modeli. Wynik w benchmarku mówi niewiele, jeśli pytania testowe znalazły się już wcześniej w danych treningowych; problem ten nosi nazwę zanieczyszczenia benchmarków (benchmark contamination). Z tego samego powodu liczy się testowanie odporności na ataki adaptacyjne: zabezpieczenie, które wytrzymuje zeszłoroczne jailbreaki, a zawodzi wobec tegorocznych, daje niewielką pewność.

Czego wymaga rzeczywisty nadzór ze strony człowieka

Nadzór ze strony człowieka przedstawia się często jako ostatnie zabezpieczenie, ale działa on tylko wtedy, gdy osoba sprawująca nadzór ma czas, informacje, uprawnienia i kompetencje, by zainterweniować. Badania nad czynnikiem ludzkim od dawna dokumentują błąd automatyzacji (automation bias): ludzie skłonni są przyjmować wynik zautomatyzowanego systemu, zwłaszcza pod presją czasu, i przeoczać jego błędy. Ani lekarz proszony o przejrzenie długiej kolejki rekomendacji wygenerowanych maszynowo, ani urzędnik, który nie widzi, dlaczego system oznaczył dany wniosek, nie są w stanie sprawować rzeczywistego nadzoru.

Prawo coraz częściej traktuje nadzór jako wymóg projektowy, a nie formalność. Artykuł 22 RODO już dziś daje osobom fizycznym, z zastrzeżeniem wyjątków, prawo do tego, by nie podlegać decyzjom opartym wyłącznie na zautomatyzowanym przetwarzaniu, które wywołują skutki prawne lub w podobny sposób istotnie na nie wpływają. Unijny AI Act (rozporządzenie (UE) 2024/1689) wymaga, by systemy wysokiego ryzyka były projektowane tak, aby ludzie mogli skutecznie je nadzorować (art. 14), oraz by spełniały wymogi dotyczące dokładności, solidności i cyberbezpieczeństwa (art. 15); art. 14 wprost wymienia błąd automatyzacji. Większość obowiązków dotyczących systemów wysokiego ryzyka miała pierwotnie mieć zastosowanie od 2 sierpnia 2026 r.; cyfrowy omnibus w sprawie AI (rozporządzenie (UE) 2026/1744), który wszedł w życie 27 lipca 2026 r., przesunął je na 2 grudnia 2027 r., a w przypadku AI wysokiego ryzyka w produktach objętych odrębnymi przepisami na 2 sierpnia 2028 r.

Poza UE rządy i twórcy systemów AI spotykali się w Bletchley Park w 2023 r., w Seulu w 2024 r. i w Paryżu w 2025 r., a w porządku obrad znalazły się ryzyka związane z modelami frontier, czyli najbardziej zaawansowanymi systemami swojej generacji. Zasady OECD dotyczące sztucznej inteligencji (2019, zaktualizowane w 2024 r.), ramy zarządzania ryzykiem AI opracowane przez NIST (NIST AI Risk Management Framework, 2023) i norma ISO/IEC 42001 (2023) przekładają część agendy bezpieczeństwa na język, który organizacje mogą zastosować w praktyce. Żaden z tych instrumentów nie rozwiązuje problemów technicznych; tworzą one oczekiwanie, że ktoś wykonał tę pracę i potrafi to wykazać.

Praktyczny wniosek

Podstawowa idea ma zastosowanie również poza laboratoriami badawczymi. Gdy system AI trafia do szkoły, organizacji pozarządowej lub urzędu, użyteczne pytania są konkretne: na czym i przez kogo był testowany, co się dzieje, gdy się myli, kto może uchylić jego decyzję oraz do jakich danych i narzędzi ma dostęp. System, co do którego nikt nie potrafi odpowiedzieć na te pytania, nie zasłużył na autonomię, jaką się mu przyznaje.

Badania nad bezpieczeństwem AI to jeden z sześciu obszarów działania Fundacji, a analizy publikowane w tym dziale wychodzą z jednego założenia: technologia powinna wzmacniać ludzki osąd, a nie po cichu go zastępować.

W skrócie

Bezpieczeństwo AI (AI safety) to dziedzina badań i praktyki inżynierskiej, której zadaniem jest sprawić, by coraz bardziej zdolne systemy AI pozostawały niezawodne, kontrolowalne i zgodne z ludzkimi intencjami. Pyta, czy system robi to, czego oczekują ludzie, czy robi to nadal w nieznanych warunkach i w obliczu ataku, czy da się go zrozumieć oraz czy człowiek może go sprawdzić, skorygować lub zatrzymać.

Najczęściej zadawane pytania

Czym różni się bezpieczeństwo AI od etyki AI i ochrony systemów AI (AI security)?

Etyka AI pyta, co należy budować i dla kogo. AI security chroni modele, dane i infrastrukturę przed atakującymi. AI safety pyta, czy sam system po wdrożeniu zachowuje się tak, jak zamierzono. Granice są nieostre: model, który da się namówić do zignorowania własnych instrukcji, to problem zarówno ochrony, jak i bezpieczeństwa.

Czym jest prompt injection?

Prompt injection (wstrzykiwanie poleceń) to atak, w którym agent AI czyta treść, na przykład stronę z ukrytymi instrukcjami, i może je wykonać, choćby porzucając zadanie i przesyłając dalej pocztę użytkownika. Atak jest możliwy, bo model przetwarza instrukcje i dane w tym samym kanale. Pełnej obrony technicznej dziś nie ma; środki zaradcze zmniejszają ryzyko, ale go nie usuwają.

Dlaczego modele ogólnego przeznaczenia utrudniają zapewnienie bezpieczeństwa AI?

Wąsko wyspecjalizowane narzędzie, jak filtr antyspamowy, ma specyfikację, więc jego twórcy mogą bezpośrednio mierzyć błędy. Model ogólnego przeznaczenia trenuje się, by był użyteczny w zadaniach, których nikt z góry nie wyliczył, więc nie ma jednej specyfikacji do jego oceny. Trenuje się go na miarach zastępczych, co prowadzi do obchodzenia specyfikacji: system optymalizuje to, co mierzone, a nie to, o co chodziło.

Jakie są główne kierunki badań nad bezpieczeństwem AI?

Znaczną część badań można pogrupować w cztery programy: zgodność celów (alignment), czyli metody treningu, takie jak uczenie na podstawie informacji zwrotnej od ludzi, które kształtują to, do czego model dąży; ocenę i testowanie przed wdrożeniem; interpretowalność, czyli wyjaśnianie lub przewidywanie zachowania modelu; oraz odporność i kontrolę, w tym obronę przed wstrzykiwaniem poleceń, zatruwaniem danych i przejmowaniem celów.

Czego wymaga rzeczywisty nadzór człowieka nad AI?

Nadzór działa tylko wtedy, gdy osoba sprawująca go ma czas, informacje, uprawnienia i kompetencje, by zainterweniować. Ludzie skłonni są przyjmować wynik zautomatyzowanego systemu, zwłaszcza pod presją czasu, co nazywa się błędem automatyzacji. Lekarz przeglądający długą kolejkę rekomendacji maszynowych nie sprawuje rzeczywistego nadzoru. Artykuł 14 AI Act wprost wymienia błąd automatyzacji.

Jak cytować Fundacja LASTHUMAN. (2026, 2 czerwca). Czym jest bezpieczeństwo AI (AI safety)? https://lasthuman.today/pl/insights/what-is-ai-safety.html