Anthropic RSP 3.4: nowe progi ryzyka i governance AI

Anthropic Responsible Scaling Policy 3.4 obowiązuje od 8 lipca 2026 r. i opisuje sposób zarządzania ryzykami, które mogą pojawić się wraz ze wzrostem capabilities modeli. Aktualizacja zmienia próg dotyczący automatycznego R&D, reguły publikacji Risk Reports i sposób ich zewnętrznego przeglądu.

RSP jest dobrowolną polityką jednego dostawcy, a nie standardem ani dowodem bezpieczeństwa konkretnego wdrożenia. Może jednak dostarczyć użytecznego wzorca governance opartego na progach i dowodach.

Co zmieniła wersja 3.4

Anthropic wymienia pięć zmian:

1. rewizję progu automated R&D, aby lepiej odzwierciedlał konkretny threat model;
2. zmianę dystrybucji pełnych Risk Reports wewnątrz firmy — co najmniej 200 pracowników zamiast całej grupy regular-clearance;
3. możliwość raportowania ryzyka według jawnej daty granicznej coverage;
4. obowiązek wskazania miejsc redakcji w wersji publicznej;
5. dopuszczenie kilku zewnętrznych reviewerów, jeśli każdy fragment pełnego raportu oceni przynajmniej jedna osoba.

Zmiany pokazują napięcie między aktualnością, poufnością i niezależnym nadzorem.

Capability threshold zamiast jednej oceny modelu

Próg powinien być związany ze scenariuszem szkody. Model może być bardzo dobry w kodowaniu, ale nie przekraczać progu automatyzacji badań albo ryzyka biologicznego. Jedna etykieta „high risk” ukrywa te różnice.

W organizacji definiuj progi per domena: autonomia w produkcji, dostęp do danych, zdolność wykonywania operacji finansowych, cyber capability i wpływ na decyzje człowieka.

Risk Report jako artefakt decyzji

Raport powinien określać wersję systemu, coverage date, scenariusze, testy, wyniki, niepewność, zabezpieczenia i ownera ryzyka resztkowego. Musi prowadzić do decyzji: wdrożyć, ograniczyć, ponownie przetestować lub zatrzymać.

Zaznaczanie redakcji pozwala odbiorcy zobaczyć, że dowód istnieje, ale nie został ujawniony. Nie umożliwia jego weryfikacji, dlatego krytyczne fragmenty wymagają zaufanego przeglądu pod NDA lub innej kontrolowanej formy.

Model wielu reviewerów

Podział raportu między ekspertów ma sens, gdy chemik nie powinien oceniać exploit development, a red teamer — metodologii bio. Warunkiem jest pełne pokrycie i osoba integrująca sprzeczne wnioski.

Zbuduj macierz: sekcja, wymagane kompetencje, reviewer, konflikt interesów, data i wynik. Brak review jednego krytycznego załącznika nie może zostać ukryty w średnim statusie „zatwierdzono”.

Off-cycle review po zmianie

Wcześniejsze wersje 3.2 i 3.3 wzmacniały zewnętrzny review oraz aktualizacje ryzyka pojedynczego modelu. Praktyczna lekcja: kalendarz kwartalny nie wystarczy. Nowy model, tool, źródło RAG, poziom autonomii lub zmiana retencji może wymagać oceny natychmiast.

Połącz rejestr zmian z rejestrem modeli AI. Każda zmiana powinna mieć próg uruchamiający odpowiedni zestaw ewaluacji.

Jak wdrożyć podobny model w firmie

1. Zdefiniuj scenariusze szkody i mierzalne progi.
2. Przypisz ownera biznesowego oraz technicznego.
3. Ustal zestawy testów przed progiem i po nim.
4. Twórz wersjonowany Risk Report z coverage date.
5. Wymagaj review odpowiednich ekspertów.
6. Zapisuj redakcje i miejsce pełnego dowodu.
7. Ustal kontrolki wymagane po przekroczeniu progu.
8. Monitoruj zmianę i uruchamiaj off-cycle assessment.

Ograniczenia podejścia

Polityka nie zapobiega incydentowi sama w sobie. Próg może zostać źle skalibrowany, ewaluacja może nie odwzorować produkcji, a reviewer może nie mieć pełnego kontekstu. Potrzebne są również logi, incident response, red teaming i niezależna obserwacja rzeczywistych efektów.

RSP 3.4 jest wartościowy jako przykład jawnego mechanizmu aktualizacji. Najważniejsza lekcja dla firm brzmi: governance musi reagować na capabilities i zmianę systemu, a nie wyłącznie na nazwę modelu lub roczną ankietę.

---

Jak czytać deklarację governance

RSP jest polityką konkretnej firmy, nie niezależnym standardem ani gwarancją bezpieczeństwa modelu. Analizuj dokładną wersję, definicje progów, wymagane ewaluacje, uprawnienia decyzyjne i mechanizm wyjątków. Oddziel zobowiązanie publiczne od kontroli technicznej możliwej do sprawdzenia we własnym wdrożeniu.

Dla klienta istotne są przełożenia na praktykę: jaka wersja modelu działa, jakie zabezpieczenia są aktywne, gdzie dostępne są wyniki ewaluacji i jak wygląda reakcja na zmianę poziomu ryzyka. Zachowuj kopię dokumentu użytego w ocenie dostawcy, bo polityki ewoluują. Własny risk assessment nadal obejmuje dane, narzędzia, użytkowników i skutki błędu aplikacji.

Źródła: Anthropic RSP, RSP Version 3.4, Frontier Safety Roadmap.