Fable 5 Wrócił. Problem Nie Zniknął. AI Lock-In W Cyberbezpieczeństwie - Security Bez Tabu

Fable 5 Wrócił. Problem Nie Zniknął. AI Lock-In W Cyberbezpieczeństwie

Model Znika. Co Dzieje Się Z Procesem?

Wyobraź sobie, że przez kilka miesięcy budujesz proces bezpieczeństwa wokół konkretnego modelu AI.

Nie kolejne demo dla zarządu. Nie chatbota, który poprawia styl polityki bezpieczeństwa albo przygotowuje podsumowanie publicznego raportu. Model zaczyna wykonywać prawdziwą pracę.

SOC używa go do wstępnego triage alertów. AppSec prosi go o analizę pull requestów. PSIRT wykorzystuje go do weryfikowania zgłoszeń podatności. Detection engineer generuje z nim pierwsze wersje reguł Sigma i KQL. Zespół vulnerability management podaje mu advisory, dane o assetach i informacje o ekspozycji, żeby szybciej zdecydować, co trzeba załatać w pierwszej kolejności.

Na początku model jest tylko asystentem. Później staje się częścią workflow. Jeszcze później ludzie przestają zauważać, że bez niego proces wyglądałby zupełnie inaczej.

A potem model znika.

Nie dlatego, że padło API. Nie dlatego, że region chmurowy zaliczył awarię. Nie dlatego, że ktoś zgubił klucz albo zapomniał odnowić subskrypcję. Model znika, ponieważ rząd państwa, w którym znajduje się dostawca, uznał, że dostęp do niego należy ograniczyć z powodów bezpieczeństwa narodowego.

Kilka tygodni później model wraca. Ma zmodyfikowane zabezpieczenia, część zapytań może zostać obsłużona przez inny model, a jego mniej ograniczony odpowiednik nadal pozostaje dostępny tylko dla zatwierdzonych organizacji.

Na pierwszy rzut oka wszystko dobrze się kończy. Fable 5 znowu działa. Użytkownicy odzyskali dostęp. Można zamknąć temat i przejść do kolejnego modelu.

Tylko że właśnie wtedy przeoczylibyśmy najważniejszą lekcję z całej tej historii.

Problemem nigdy nie było wyłącznie to, że Fable 5 został wyłączony. Problemem było to, że mógł zostać wyłączony, później przywrócony i po drodze zmienić sposób, w jaki obsługuje zadania organizacji.

Według aktualnej dokumentacji Claude Fable 5 jest ponownie modelem ogólnie dostępnym przez Claude API, Amazon Bedrock, Claude Platform on AWS, Google Cloud i Microsoft Foundry. Claude Mythos 5 nadal nie jest dostępny w trybie self-service. Pozostaje modelem oferowanym zatwierdzonym partnerom Project Glasswing. Oba modele są sklasyfikowane przez Anthropic jako Covered Models, co wiąże się między innymi z obowiązkową 30-dniową retencją promptów i odpowiedzi oraz brakiem możliwości zastosowania Zero Data Retention.

Historia Fable 5 nie jest więc już opowieścią o chwilowej blokadzie jednego produktu.

To jest case study pokazujące, czym stanie się AI w cyberbezpieczeństwie, gdy przestanie być eksperymentem.

Stanie się dostawcą.

A dostawca oznacza zależność.

To Jest Trzecia Część Historii O Glasswing I Mythos

W pierwszym artykule o Project Glasswing pisałem, że nie chodzi o sam model. Chodzi o zmianę zasad gry.

Anthropic nie uruchomił zwykłego produktu pod tytułem „Claude dla pentesterów”. Firma stworzyła program kontrolowanego dostępu do Claude Mythos Preview i przekazała model organizacjom utrzymującym część najważniejszego oprogramowania oraz infrastruktury cyfrowej na świecie.

Model trafił do partnerów, którzy mieli wykorzystać go do defensywnego vulnerability research. Nie do odpowiadania na pytania z OWASP Top 10, tylko do analizy rzeczywistych repozytoriów, zależności, protokołów, komponentów systemowych i potencjalnych ścieżek ataku.

Później Anthropic rozszerzył Project Glasswing o około 150 kolejnych organizacji z ponad 15 państw. Wśród uczestników znalazły się podmioty związane między innymi z energetyką, wodą, ochroną zdrowia, komunikacją i sprzętem. Firma twierdziła również, że pierwsi partnerzy znaleźli łącznie ponad 10 tysięcy podatności ocenianych jako high lub critical. Trzeba uczciwie zaznaczyć, że są to dane publikowane przez Anthropic, a nie niezależny benchmark całego rynku.

Wtedy najważniejsze pytanie brzmiało:

Co się stanie, gdy AI zacznie znajdować podatności szybciej, niż organizacje potrafią je zweryfikować, zrozumieć i naprawić?

W drugiej części historii pojawił się Cloudflare.

Firma skierowała Mythos Preview na ponad 50 własnych repozytoriów i sprawdziła model nie na czystym benchmarku, lecz na rzeczywistym środowisku produkcyjnym. Analizowany był kod runtime, edge data path, control plane, stosy protokołów i zależności open source.

Cloudflare zauważył, że Mythos nie tylko wskazuje pojedyncze błędy. Potrafi łączyć kilka pozornie mniej istotnych problemów w pełniejszy exploit chain. Inne modele również znajdowały część tych samych prymitywów, ale częściej zatrzymywały się przed połączeniem ich w całość i potwierdzeniem praktycznego wpływu.

Jednocześnie Cloudflare bardzo wyraźnie pokazał, że sam model nie wystarcza.

Wokół niego musiał powstać cały harness: reconnaissance, równoległy hunting, niezależna walidacja, gap analysis, deduplikacja, analiza zależności, sprawdzanie reachability i generowanie ustrukturyzowanych raportów. W późniejszym opisie architektury Cloudflare pokazał nawet rozdzielenie discovery i validation między dwa różne modele, dzięki czemu wynik jednego systemu był podważany przez drugi. Firma pisała wprost, że chce traktować dostawców modeli jak wymienne komponenty i projektować harness tak, aby absorbował zmiany ich zachowania.

To była druga lekcja.

AI może być bardzo dobre w generowaniu hipotez. Może przygotować proof of concept i pomóc w potwierdzeniu podatności. Ale bez procesu równie dobrze może zasypać organizację technicznie brzmiącym hałasem.

W poprzednim artykule nazwałem to triage DoS.

Nie chodzi o atak na infrastrukturę. Chodzi o przeciążenie uwagi. Model generuje setki findingów. Każdy brzmi trochę niepokojąco. Pojawiają się „possible RCE”, „potential authentication bypass”, „critical memory corruption”. Tylko ktoś nadal musi sprawdzić, czy input jest kontrolowany przez atakującego, czy podatny kod jest osiągalny, czy problem występuje w konfiguracji produkcyjnej i czy w ogóle można go odtworzyć.

Glasswing pokazał więc, że discovery przestaje być jedynym bottleneckiem.

Cloudflare pokazał, że nowymi ograniczeniami stają się walidacja, triage, reachability, deduplikacja i remediacja.

Fable 5 dokłada trzecią część.

Nawet jeśli masz dobry model i dobry proces, nadal możesz nie kontrolować tego, czy jutro będziesz mieć dostęp do tego modelu.

I właśnie tutaj AI Security spotyka się z Vendor Risk Management.

Co Właściwie Wydarzyło Się Z Fable 5?

Claude Fable 5 i Claude Mythos 5 zostały udostępnione 9 czerwca 2026 roku.

Oba produkty bazują na tym samym modelu i oferują ten sam podstawowy poziom capability. Różnica dotyczy przede wszystkim zabezpieczeń i sposobu dystrybucji. Fable 5 został wyposażony w klasyfikatory bezpieczeństwa pozwalające blokować część zapytań. Mythos 5 nie ma tych samych klasyfikatorów i został przeznaczony dla ograniczonej grupy partnerów Project Glasswing. Oba modele oferują milion tokenów kontekstu i obsługują między innymi zadania agentowe, wykonywanie kodu oraz programmatic tool calling.

Trzy dni później, 12 czerwca, rząd Stanów Zjednoczonych wydał dyrektywę eksportową nakazującą wstrzymanie dostępu do obu modeli dla cudzoziemców — zarówno znajdujących się poza USA, jak i przebywających na terenie Stanów Zjednoczonych.

Anthropic nie miał mechanizmu pozwalającego wiarygodnie zweryfikować obywatelstwo każdego użytkownika w czasie rzeczywistym. W rezultacie firma wyłączyła Fable 5 i Mythos 5 dla wszystkich klientów. Pozostałe modele Claude działały dalej.

Według późniejszego opisu Anthropic interwencja nastąpiła po tym, jak badacze Amazona znaleźli sposób obejścia części zabezpieczeń Fable 5. Model miał zostać skłoniony do identyfikowania podatności w oprogramowaniu, a w jednym przypadku do przygotowania kodu demonstrującego sposób wykorzystania jednego z błędów.

Anthropic utrzymywał, że przedstawione zadania nie ujawniły unikalnych możliwości klasy Mythos. Firma przeprowadziła testy porównawcze i stwierdziła, że te same podatności oraz demonstrację wykorzystania błędu były w stanie wygenerować również słabsze i powszechnie dostępne modele. To stanowisko Anthropic, a nie niezależna ocena całej sprawy. Nie mamy dostępu do pełnych materiałów widzianych przez administrację USA, dlatego nie da się uczciwie rozstrzygnąć, czy reakcja rządu była technicznie proporcjonalna.

Wiemy natomiast, co wydarzyło się później.

Anthropic przygotował nowy klasyfikator bezpieczeństwa, który — według firmy — blokuje opisaną technikę w ponad 99% przypadków. Firma przyznała jednocześnie, że bardziej agresywna klasyfikacja zwiększa liczbę false positives, czyli może blokować również zwykłe, defensywne zadania programistyczne i security research. Zablokowane zapytanie może zostać przekazane do Claude Opus 4.8.

30 czerwca ograniczenia eksportowe zostały zdjęte. Od 1 lipca Fable 5 zaczął wracać globalnie do usług Anthropic. Dostęp do Mythos 5 został początkowo przywrócony wybranym organizacjom ze Stanów Zjednoczonych, a aktualna dokumentacja nadal opisuje ten model jako dostępny wyłącznie dla zatwierdzonych partnerów.

Cała historia trwała niecałe trzy tygodnie.

To wystarczyło, aby pokazać, że lifecycle modelu frontier może wyglądać zupełnie inaczej niż lifecycle klasycznej usługi SaaS.

Fable 5 Wrócił. Czyli Problem Został Rozwiązany?

Można powiedzieć: skoro model wrócił, ryzyko było przejściowe.

To byłby zły wniosek.

Gdyby Fable 5 został wyłączony na zawsze, mielibyśmy prostą historię o utracie usługi. Dostawca znika, klient migruje, temat zamknięty.

Tymczasem wydarzyło się coś znacznie bardziej reprezentatywnego dla przyszłości AI.

Model nie zniknął na zawsze. Model zmienił stan.

Najpierw był dostępny. Później został wyłączony. Następnie wrócił z nowym klasyfikatorem, większym prawdopodobieństwem blokowania legalnych zapytań i mechanizmem fallbacku do innego modelu. Jego mniej ograniczony wariant wrócił na innych zasadach niż wariant publiczny.

Dla indywidualnego użytkownika najważniejsza może być odpowiedź na pytanie:

Czy mogę znowu wybrać Fable 5?

Dla organizacji to za mało.

Organizacja musi wiedzieć, jaki model rzeczywiście wykonał zadanie, jaka polityka była aktywna, czy uruchomił się fallback, czy zmienił się sposób retencji danych, czy użytkownicy we wszystkich regionach mają ten sam dostęp oraz czy nowe zabezpieczenia nie wpłynęły na jakość procesu.

Dostępność AI nie jest wartością binarną.

Model może być formalnie dostępny, ale odmawiać większej liczby legalnych zadań. Może być dostępny przez jedno API, lecz nie przez inną platformę. Może przekazywać część zapytań do słabszego modelu. Może być dostępny dla jednej części globalnego zespołu, a niedostępny dla innej. Może też wymagać retencji danych niezgodnej z modelem bezpieczeństwa, który organizacja przyjęła wcześniej.

Dashboard może pokazywać zielony status.

Proces może już działać inaczej.

Powrót Fable 5 nie osłabia więc głównej tezy tego artykułu.

On ją wzmacnia.

Największym ryzykiem nie jest to, że model raz zniknie. Największym ryzykiem jest założenie, że jego dostępność, zachowanie i polityka pozostaną stałe.

AI Lock-In To Nie Jest Tylko Przywiązanie Do Jednego API

Kiedy słyszymy vendor lock-in, zwykle myślimy o chmurze.

Firma wykorzystuje specyficzną bazę danych jednego dostawcy, jego kolejki, IAM, serverless, storage, monitoring i własne rozszerzenia. Po kilku latach migracja przestaje oznaczać zmianę endpointu. Staje się osobnym projektem, który trzeba zaplanować, sfinansować i przeprowadzić bez zatrzymania biznesu.

Z AI jest podobnie, ale dochodzą nowe warstwy zależności.

Pierwszą warstwą jest oczywiście interfejs: konkretne API, format wiadomości, narzędzia, obsługa kontekstu, cache, structured outputs, mechanizmy agentowe i biblioteki SDK.

To jednak najprostsza część.

Dużo trudniejsza jest zależność semantyczna.

Prompt przygotowany pod jeden model może działać gorzej na innym. Instrukcja, która w Fable 5 generuje dobry raport z incydentu, w Opus 4.8 może pominąć część kontekstu. Model alternatywny może inaczej rozumieć krytyczność assetu, inaczej ważyć poszczególne sygnały i częściej dopowiadać brakujące informacje.

Nawet jeśli oba modele zwracają poprawny JSON, nie oznacza to, że wynik ma tę samą wartość.

Jeszcze trudniejsza jest zależność procesowa.

Po kilku miesiącach zespół nie tylko korzysta z modelu. Zespół zmienia sposób pracy wokół modelu. Playbooki zaczynają zakładać obecność automatycznego summary. Tickety zawierają pola uzupełniane przez AI. SLA zostaje wyliczone przy założeniu, że pierwsza analiza trwa kilkadziesiąt sekund. Analitycy L1 przestają ręcznie wykonywać część enrichmentu. Manager raportuje poprawę MTTA i wykorzystuje ją do planowania obsady.

Wtedy zmiana modelu nie jest już zmianą technologiczną.

Jest zmianą procesu operacyjnego.

Cloudflare zauważył podobny problem podczas testów Mythos Preview. Semantycznie podobne zadania potrafiły prowadzić do zupełnie innych rezultatów. Model w jednym kontekście odmawiał przeprowadzenia legalnego vulnerability research, a po nieistotnej zmianie środowiska zgadzał się wykonać to samo zadanie. W innym przypadku znajdował i potwierdzał poważne błędy pamięci, ale odmawiał przygotowania demonstracyjnego exploita. Po zmianie sformułowania odpowiedź była inna.

To nie jest zarzut wyłącznie wobec Anthropic.

To cecha systemów probabilistycznych, na którą dodatkowo nakładamy klasyfikatory, guardrails i polityki dostawcy.

W klasycznym systemie wywołanie tej samej funkcji z tym samym wejściem powinno zwykle dać ten sam wynik. W systemie opartym na LLM-ie rezultat zależy od modelu, wersji, kontekstu, promptu, parametrów, aktywnych zabezpieczeń, historii rozmowy i czasami od decyzji zewnętrznego klasyfikatora.

Dlatego AI lock-in nie polega tylko na tym, że trudno zmienić endpoint.

Polega na tym, że trudno zagwarantować równoważność zachowania po zmianie modelu.

Najbardziej Niebezpieczna Awaria Może Zwrócić HTTP 200

Tutaj dochodzimy do jednego z najciekawszych technicznych elementów Fable 5.

Jeżeli klasyfikator bezpieczeństwa odrzuci zapytanie, Claude API nie musi zwrócić błędu HTTP 4xx ani 5xx. Odpowiedź może mieć kod 200 OK i jednocześnie zawierać:

{
  "model": "claude-fable-5",
  "content": [],
  "stop_reason": "refusal",
  "stop_details": {
    "type": "refusal",
    "category": "cyber",
    "explanation": "This request was declined because it could enable cyber harm."
  }
}

Z punktu widzenia warstwy transportowej wszystko zadziałało.

TLS działał. API odpowiedziało. Latencja jest w normie. Nie pojawił się błąd serwera. Dashboard oparty na liczbie odpowiedzi 4xx i 5xx nadal świeci się na zielono.

Tylko zadanie nie zostało wykonane.

Dokumentacja Anthropic wprost opisuje odmowę Fable 5 jako poprawną odpowiedź HTTP z stop_reason: "refusal". Jednocześnie zaznacza, że kategoria cyber może zostać uruchomiona również przez legalne zadania bezpieczeństwa.

To jest ważna różnica.

W klasycznym monitoringu usługa albo działa, albo nie działa. W AI może działać infrastruktura, ale nie być dostępne capability, którego potrzebuje proces.

Anthropic umożliwia skonfigurowanie fallbacku. Jeśli Fable 5 odmówi odpowiedzi, to samo zapytanie może zostać przekazane do innego modelu, obecnie na przykład do Opus 4.8. Odpowiedź wskazuje, który model ostatecznie wygenerował wynik.

Server-side fallback jest obecnie funkcją beta dostępną na natywnym Claude API i Claude Platform on AWS. Nie jest dostępny bezpośrednio na Amazon Bedrock, Google Cloud ani Microsoft Foundry; w tych środowiskach trzeba zastosować mechanizm client-side lub własną logikę ponowienia. Co istotne, fallback uruchamia się po odmowie klasyfikatora, a nie po rate limicie, overloadzie czy błędzie serwera.

Poniższy przykład odpowiada wersji beta API udokumentowanej 21 lipca 2026 roku. Przed wdrożeniem należy sprawdzić aktualną nazwę nagłówka, obsługiwane modele fallback oraz format odpowiedzi.

import json
import logging
from typing import Any

from anthropic import Anthropic

logger = logging.getLogger("ai-security-gateway")
client = Anthropic()


def analyze_security_case(prompt: str, case_id: str) -> Any:
    response = client.beta.messages.create(
        model="claude-fable-5",
        max_tokens=2_000,
        messages=[
            {
                "role": "user",
                "content": prompt,
            }
        ],
        fallbacks=[
            {
                "model": "claude-opus-4-8",
            }
        ],
        betas=[
            "server-side-fallback-2026-06-01",
        ],
    )

    iterations = response.usage.iterations or []

    fallback_ran = any(
        iteration.type == "fallback_message"
        for iteration in iterations
    )

    served_by_fallback = (
        fallback_ran
        and response.stop_reason != "refusal"
    )

    audit_event = {
        "case_id": case_id,
        "requested_model": "claude-fable-5",
        "served_model": response.model,
        "stop_reason": response.stop_reason,
        "fallback_ran": fallback_ran,
        "served_by_fallback": served_by_fallback,
        "refusal_category": (
            response.stop_details.category
            if response.stop_details
            else None
        ),
    }

    logger.info(json.dumps(audit_event))

    if response.stop_reason == "refusal":
        raise RuntimeError(
            "All configured models refused the request"
        )

    return response

Technicznie wygląda to rozsądnie.

Problem zaczyna się wtedy, gdy aplikacja sprawdza wyłącznie, czy otrzymała odpowiedź.

Wyobraźmy sobie, że Fable 5 był wykorzystywany do analizy podatności w dużych repozytoriach. Po aktualizacji klasyfikator zaczyna odrzucać część zapytań, które wcześniej wykonywał. Fallback przejmuje Opus 4.8. Użytkownicy nadal dostają odpowiedzi, API nadal zwraca 200, a dashboard dostępności nadal pokazuje 99,99%.

Proces nie korzysta już jednak z tego samego modelu.

Może spaść recall. Może wzrosnąć liczba false negatives. Raporty mogą stać się mniej szczegółowe. Model może gorzej zrozumieć długi kontekst albo nie połączyć prymitywów w ścieżkę ataku, którą wcześniej był w stanie przeanalizować Fable.

Jeśli organizacja nie loguje requested_model, served_model, stop_reason, informacji o fallbacku i wersji promptu, może w ogóle nie zauważyć tej zmiany.

Dokumentacja Anthropic wprost ostrzega, że monitoring oparty na error rate i odpowiedziach 5xx nie wykryje odmów Fable 5. Zaleca emitowanie osobnych zdarzeń dla odmów i odpowiedzi obsłużonych przez fallback.

To jest bardzo dobra lekcja wykraczająca poza jeden produkt.

Monitoring AI nie może kończyć się na dostępności API. Musi mierzyć dostępność capability.

Zielony Dashboard Nie Oznacza, Że Proces Działa Tak Samo

Klasyczne monitorowanie usług odpowiada na kilka prostych pytań.

Czy endpoint działa? Jaka jest latencja? Ile mamy timeoutów? Czy wzrósł error rate? Czy mieścimy się w limicie? Czy dostawca dotrzymuje SLA?

W przypadku AI te metryki nadal są potrzebne, ale już nie wystarczają.

Załóżmy, że aplikacja wykonała tysiąc zapytań do Fable 5. Wszystkie zakończyły się kodem 200. Dostępność wyniosła 100%.

Jeżeli jednak 30% z tych zapytań zostało odrzuconych przez klasyfikator, a następnie obsłużonych przez słabszy model, techniczna dostępność niewiele mówi o rzeczywistej jakości usługi.

Gateway obsługujący modele powinien emitować przynajmniej takie metryki:

llm_requests_total
llm_refusals_total
llm_fallback_attempts_total
llm_fallback_served_total
llm_fallback_failed_total
llm_requested_model
llm_served_model
llm_policy_category
llm_prompt_template_version
llm_eval_score

Szczególnie ważna jest relacja między odmowami a skutecznymi fallbackami.

Jeśli liczba odmów rośnie, ale fallback nadal zwraca tekst, użytkownicy mogą nie zgłosić żadnego incydentu. Właśnie dlatego taka degradacja jest niebezpieczna. Nie jest głośna. Nie zatrzymuje aplikacji. Powoli zmienia właściwości procesu.

W SOC może to oznaczać gorsze klasyfikowanie alertów.

W AppSec — pomijanie bardziej złożonych ścieżek autoryzacji.

W PSIRT — mniej trafną ocenę exploitable versus not exploitable.

W detection engineeringu — prostsze i bardziej hałaśliwe reguły.

Dobrą praktyką jest więc przechowywanie własnego zestawu evals i uruchamianie go za każdym razem, gdy zmienia się model, wersja, prompt template, polityka bezpieczeństwa albo konfiguracja fallbacku.

Nie po to, żeby wygenerować kolejny raport dla komitetu.

Po to, żeby odpowiedzieć na praktyczne pytanie:

Czy nasz proces po zmianie nadal działa wystarczająco dobrze?

Zobaczmy, Co To Znaczy W SOC

Weźmy typowy alert.

Word uruchamia PowerShella. PowerShell otrzymuje -EncodedCommand, a później nawiązuje połączenie z zewnętrznym adresem IP. Taki alert może oznaczać phishing, złośliwe makro, działania red teamu, automatyzację administratora albo false positive wynikający z nietypowego procesu biznesowego.

W AI-assisted SOC kontekst może zostać pobrany z EDR, IAM, DNS, proxy, CMDB, threat intelligence i historii wcześniejszych incydentów. Model otrzymuje zestaw zdarzeń, buduje narrację, sugeruje severity i proponuje działania.

Przykładowe zdarzenie mogłoby wyglądać tak:

{
  "event_id": "sec-2026-07-21-88421",
  "source": "edr",
  "host": "fin-ws-023",
  "user": "anna.kowalska",
  "alert": "Suspicious PowerShell spawned by Office",
  "process": {
    "parent": "WINWORD.EXE",
    "image": "powershell.exe",
    "command_line": "powershell.exe -ExecutionPolicy Bypass -EncodedCommand <redacted>"
  },
  "network": {
    "destination_ip": "198.51.100.24",
    "destination_port": 443
  },
  "asset": {
    "criticality": "high",
    "owner": "finance"
  },
  "identity": {
    "mfa": true,
    "last_login_country": "PL",
    "privileged_account": false
  }
}

Model może zwrócić:

Severity: High

Reasoning summary:
Microsoft Word spawned PowerShell with an encoded command.
The process initiated an outbound TLS connection to an
external IP. The affected host belongs to the finance
department and has high business criticality.

Recommended actions:
1. Isolate the endpoint.
2. Preserve volatile evidence.
3. Retrieve and decode the PowerShell payload.
4. Search for the same destination and process chain
   across the environment.

To jest użyteczne.

Analityk nie musi zaczynać od pustej kartki. Dostaje hipotezę, streszczenie i listę działań. Jeśli model ma dobry kontekst, może skrócić pierwszy triage z kilkunastu minut do kilkudziesięciu sekund.

Ten sam mechanizm może jednak stworzyć automation bias.

Jeżeli model od początku ustawi narrację jako „wysokie ryzyko, prawdopodobny phishing”, analityk będzie szukał dowodów potwierdzających tę hipotezę. Może nie zauważyć, że proces został uruchomiony przez zatwierdzone makro finansowe albo legalne narzędzie wykorzystywane przez dział księgowości.

Jeszcze gorzej, jeśli po cichu zadziałał fallback.

Analityk widzi odpowiedź. Nie wie, że model, który zwykle analizował podobne przypadki, odmówił. Nie wie, że wynik przygotował model o innych właściwościach. Nie wie też, że dzień wcześniej zmieniono klasyfikator albo konfigurację routingu.

Dlatego wynik AI nie może być przechowywany wyłącznie jako tekst w tickecie.

Potrzebujemy provenance.

{
  "case_id": "IR-2026-07-21-0442",
  "workflow": "soc-ai-triage-v4",
  "requested_model": "claude-fable-5",
  "served_model": "claude-opus-4-8",
  "fallback_ran": true,
  "fallback_reason": "classifier_refusal",
  "prompt_template_id": "soc-triage-2026-07-03",
  "input_data_classification": [
    "security_logs",
    "internal_metadata"
  ],
  "output_hash": "sha256:7db9b7f7e4...",
  "ai_suggested_severity": "high",
  "analyst_final_severity": "medium",
  "analyst_decision": "reclassified",
  "human_approval_required": true,
  "action_taken": "enhanced_monitoring",
  "timestamp": "2026-07-21T11:42:11Z"
}

To nie jest compliance theater.

Taki zapis pozwala później sprawdzić, czy po zmianie modelu wzrosła liczba błędnych klasyfikacji. Czy fallback częściej podnosi severity. Czy analitycy częściej zmieniają rekomendację AI. Czy określona wersja promptu powoduje więcej false positives. Czy incydent został obsłużony przez model główny, czy zastępczy.

Bez tych danych organizacja nie zarządza AI.

Organizacja tylko konsumuje odpowiedzi.

AppSec: Ten Sam JSON Nie Oznacza Tej Samej Analizy

W AppSec problem wygląda trochę inaczej.

Klasyczne narzędzia dobrze radzą sobie z określonymi wzorcami. Semgrep znajdzie niebezpieczne wywołanie. CodeQL przeanalizuje przepływ danych. SCA wskaże podatną zależność. DAST spróbuje zaatakować działającą aplikację.

Model AI może natomiast czytać kod bardziej kontekstowo.

Załóżmy, że w pull requeście pojawia się taki endpoint:

+ @PostMapping("/api/v1/admin/users/{id}/role")
+ public ResponseEntity<?> updateRole(
+     @PathVariable String id,
+     @RequestBody RoleUpdate request
+ ) {
+     userService.updateRole(id, request.role());
+     return ResponseEntity.ok().build();
+ }

Dobry model nie powinien automatycznie ogłosić krytycznej podatności.

Powinien zauważyć, że endpoint wygląda na operację administracyjną, ale w pokazanym fragmencie nie widać jawnej kontroli autoryzacji. Następnie powinien zasugerować sprawdzenie zabezpieczeń na poziomie klasy, filtra, service layer, API gateway i testów integracyjnych.

To jest hipoteza.

Jeszcze nie finding.

A już na pewno nie potwierdzona podatność.

Problem w tym, że różne modele mogą ocenić ten sam fragment inaczej. Jeden zidentyfikuje potencjalny Broken Function Level Authorization. Drugi uzna, że nazwa ścieżki wystarcza do założenia, iż endpoint jest zabezpieczony gdzieś indziej. Trzeci wygeneruje ogólny komentarz o walidacji danych wejściowych i całkowicie pominie autoryzację.

Wszystkie trzy odpowiedzi mogą spełniać ten sam JSON Schema.

Tylko jedna będzie rzeczywiście użyteczna.

Dlatego fallback w AppSec nie może działać według zasady:

Jeżeli główny model odmówi, wyślij to do dowolnego innego modelu i uznaj zadanie za wykonane.

Model zastępczy musi przejść własne evals.

Trzeba sprawdzić, jak radzi sobie z IDOR-em, BOLA, JWT, tenant isolation, SSRF, deserializacją, command injection, race conditions, błędami logicznymi i wzorcami autoryzacji używanymi w konkretnej organizacji.

Dobrą bazą nie jest zestaw publicznych zadań CTF.

Lepszą bazą jest kilkadziesiąt historycznych pull requestów z własnego środowiska: prawdziwe podatności, bezpieczne zmiany, trudne false positives i przypadki, w których znalezienie problemu wymagało zrozumienia architektury.

Przykładowy eval może wyglądać tak:

eval_id: appsec-pr-review-2026-07
owner: application-security

models:
  primary: claude-fable-5
  fallback: claude-opus-4-8
  local: internal-sec-model

test_cases:
  - id: idor-basic-controller
    language: java
    expected_findings:
      - broken_object_level_authorization
    must_not_claim:
      - sql_injection
      - remote_code_execution

  - id: safe-admin-endpoint-with-policy
    language: kotlin
    expected_findings: []
    must_recognize:
      - authorization_policy_present

  - id: jwt-alg-none-regression
    language: nodejs
    expected_findings:
      - jwt_verification_misconfiguration

metrics:
  min_critical_recall: 0.85
  max_false_positive_rate: 0.20
  evidence_required: true
  confidence_required: true

Następnie porównujemy modele nie tylko po tym, czy coś znalazły.

Sprawdzamy, czy finding był poprawny, czy wskazał evidence, czy właściwie ocenił confidence, czy nie wymyślił nieistniejącej ścieżki oraz ile czasu człowiek potrzebował, żeby podjąć decyzję.

Bo końcową metryką AppSec nie jest liczba komentarzy wygenerowanych przez AI.

Metryką jest liczba prawdziwych problemów znalezionych i naprawionych bez zalania developerów hałasem.

PSIRT: Fallback Nie Może Oznaczać „Czekamy, Aż Model Wróci”

Project Glasswing pokazał, że AI może dramatycznie przyspieszyć vulnerability discovery. Cloudflare pokazał natomiast, że znalezienie błędu bez potwierdzenia reachability i exploitable conditions daje ograniczoną wartość.

W PSIRT ten problem staje się wyjątkowo praktyczny.

Do organizacji trafia zgłoszenie:

Critical RCE in image parser.
An attacker may be able to execute arbitrary code.
Please fix immediately.

Technicznie brzmi poważnie.

Nadal jednak nie wiemy, jaka wersja jest podatna, skąd pochodzi input, czy parser jest dostępny bez uwierzytelnienia, czy błąd można odtworzyć, czy mamy crash, kontrolę przepływu, czy tylko teoretyczną możliwość oraz czy problem dotyczy konfiguracji produkcyjnej.

AI może bardzo przyspieszyć pierwszy triage. Może przeczytać zgłoszenie, przeanalizować kod, zbudować reproducer, sprawdzić historię zmian i poszukać duplikatów.

Jeżeli model znika albo odmawia wykonania zadania, PSIRT nie może jednak odpowiedzieć:

Wstrzymujemy triage do czasu przywrócenia Fable 5.

Proces bezpieczeństwa produktu musi mieć wersję manualną.

Nie tak wydajną.

Nie tak szybką.

Ale działającą.

W trybie normalnym AI może wykonywać enrichment i generować hipotezy. W trybie ograniczonym zadanie może przejąć drugi model. Jeśli on również nie jest dostępny albo nie osiąga minimalnego progu jakości, proces powinien wrócić do kryteriów deterministycznych: reproducer, reachability, kontrola inputu, exposure, krytyczność komponentu, dostępność exploita, obecność zabezpieczeń kompensujących i wpływ biznesowy.

Przykładowa uproszczona reguła fallbackowa dla vulnerability management może wyglądać tak:

from typing import Literal, TypedDict


class VulnerabilityContext(TypedDict):
    exploited_in_the_wild: bool
    internet_exposed_asset: bool
    asset_criticality: Literal["low", "medium", "high", "critical"]
    cvss: float
    auth_required: bool
    compensating_controls: bool


def prioritize_vulnerability(
    vulnerability: VulnerabilityContext
) -> str:
    score = 0

    if vulnerability["exploited_in_the_wild"]:
        score += 50

    if vulnerability["internet_exposed_asset"]:
        score += 25

    if vulnerability["asset_criticality"] == "critical":
        score += 20

    if vulnerability["cvss"] >= 9.0:
        score += 15

    if not vulnerability["auth_required"]:
        score += 10

    if vulnerability["compensating_controls"]:
        score -= 10

    if score >= 70:
        return "P1 - patch or mitigate immediately"

    if score >= 45:
        return "P2 - patch in accelerated window"

    if score >= 25:
        return "P3 - normal patch cycle"

    return "P4 - monitor"

To nie jest zamiennik za dobry model.

I bardzo dobrze.

Fallback nie ma być równie dobry jak proces główny. Generator prądu też nie jest lepszy od sieci energetycznej. Ma utrzymać najważniejszą funkcję do czasu przywrócenia normalnych warunków.

Detection Engineering: AI-Generated Nie Znaczy Production-Ready

Modele świetnie generują tekst.

Reguły Sigma, KQL, SPL, YARA, EQL, Suricata i osquery również są tekstem. Nic dziwnego, że detection engineering stał się jednym z najbardziej oczywistych zastosowań AI w SOC.

Podajesz technikę. Wskazujesz źródło logów. Prosisz o mapping do MITRE ATT&CK, false positives i propozycję tuningu. Kilka sekund później masz gotową regułę.

Tylko że reguła wyglądająca poprawnie nie musi być dobrą detekcją.

Może wykorzystywać pola, których nie ma w naszym pipeline. Może zakładać obecność Sysmona, choć organizacja zbiera tylko standardowe logi Windows. Może być poprawna składniowo, ale generować tysiące alertów dziennie. Może wykrywać dokładnie jeden przykład z promptu i nic więcej.

Dlatego output modelu należy traktować jak niezaufany kod.

Powinien przejść przez walidację składni, testy na złośliwych zdarzeniach, testy na danych benign, review detection engineera, staging i obserwację po wdrożeniu.

Przykładowy pipeline może wyglądać tak:

sigma check rules/generated/office-powershell.yml

sigma convert \
  --target splunk \
  --pipeline splunk_windows \
  rules/generated/office-powershell.yml \
  > build/office-powershell.spl

python tests/replay_detection.py \
  --rule build/office-powershell.spl \
  --malicious tests/logs/office-powershell-malicious.jsonl \
  --benign tests/logs/office-powershell-benign.jsonl

Jeśli organizacja zmienia model albo uruchamia fallback, reguły powinny zostać porównane na tym samym zestawie danych.

Możemy wtedy zobaczyć, że model główny osiągał recall 92% przy false positive rate 4%, a model zastępczy osiąga 78% i 19%.

Oba wygenerowały poprawny YAML.

Tylko jeden wynik nadaje się do procesu produkcyjnego.

Model To Również Decyzja O Retencji Danych

W dyskusji o capability łatwo pominąć coś znacznie mniej efektownego.

Dane.

Anthropic klasyfikuje Fable 5 i Mythos 5 jako Covered Models. Według aktualnej dokumentacji prompty i odpowiedzi tych modeli są przechowywane przez co najmniej 30 dni. Zero Data Retention nie jest dla nich dostępne. Wymóg podąża za modelem również wtedy, gdy jest oferowany przez zewnętrzne platformy chmurowe, choć miejsce przechowywania danych może zależeć od konkretnej platformy.

Z punktu widzenia dostawcy to element defense in depth.

Niektóre formy nadużyć można rozpoznać dopiero po przeanalizowaniu wzorca obejmującego wiele zapytań, a nie pojedynczy prompt.

Z punktu widzenia organizacji security jest to jednak istotna decyzja architektoniczna.

Wyobraźmy sobie, że model otrzymuje:

  • surowe logi EDR zawierające nazwy użytkowników,
  • fragmenty pamięci procesu,
  • konfigurację infrastruktury,
  • kod źródłowy,
  • dane z wewnętrznego CMDB,
  • pełny timeline incydentu,
  • informacje o niezałatanych podatnościach,
  • treść zgłoszenia od klienta,
  • IOC, które nie zostały jeszcze upublicznione.

Wysłanie tych danych do modelu z obowiązkową retencją jest inną decyzją niż wysłanie ich do usługi objętej ZDR.

To nie oznacza automatycznie, że nie można używać Fable 5 do zadań security.

Oznacza, że nie można podejmować tej decyzji wyłącznie na podstawie jakości modelu.

Model selection staje się elementem data governance.

Czasami lepszym rozwiązaniem będzie lokalne usunięcie PII i sekretów przed wysłaniem kontekstu. Czasami do modelu powinno trafić streszczenie, a nie surowe logi. Czasami można przesłać fragment kodu bez wewnętrznych nazw i konfiguracji. Czasami właściwą odpowiedzią będzie użycie innego modelu albo rozwiązania lokalnego.

A czasami trzeba powiedzieć:

Tych danych nie wysyłamy do tego modelu.

Nie dlatego, że AI jest złe.

Dlatego, że retencja jest częścią architektury bezpieczeństwa.

AI Jako Dostawca, Nie Tylko Aplikacja

Wiele firm nadal traktuje AI jak kolejny SaaS.

Kupujemy licencję. Tworzymy konto. Podpinamy API. Dodajemy bota do Slacka. Przeprowadzamy krótkie PoC i uznajemy, że temat został wdrożony.

Problem polega na tym, że dostawca AI może pełnić kilka ról jednocześnie.

Jest właścicielem modelu. Dostawcą infrastruktury inferencyjnej. Operatorem API. Podprocesorem danych. Twórcą klasyfikatorów bezpieczeństwa. Właścicielem polityki określającej, które zapytania zostaną wykonane, a które odrzucone. Często jest również dostawcą warstwy agentowej, narzędzi, pamięci, code execution i integracji z innymi usługami.

Jeśli taki system zaczyna wspierać SOC, AppSec, vulnerability management albo incident response, nie można oceniać go wyłącznie pytaniem:

Czy narzędzie działa?

Trzeba zapytać również, jakie procesy od niego zależą, jakie dane do niego trafiają, czy output wpływa na decyzje bezpieczeństwa, czy brak modelu wpływa na SLA, czy możemy wymusić konkretną wersję, czy wiemy o uruchomieniu fallbacku, czy istnieje plan migracji i czy umowa uwzględnia ograniczenia regionalne albo eksportowe.

To nie jest korporacyjny bełkot.

To klasyczne zarządzanie dostawcą, tylko zastosowane do nowej kategorii technologii.

DORA daje tutaj dobrą analogię. Unijne rozporządzenie ustanowiło ramy nadzoru nad krytycznymi zewnętrznymi dostawcami ICT dla sektora finansowego. Logika jest prosta: jeśli wiele ważnych procesów zależy od ograniczonej liczby dostawców, ich awaria albo zmiana sposobu działania może zagrozić odporności całego sektora.

Nie oznacza to, że każdy model AI automatycznie jest krytycznym dostawcą w rozumieniu DORA.

Oznacza, że sposób myślenia jest już gotowy.

Patrzymy na znaczenie wspieranej funkcji, poziom zastępowalności, koncentrację ryzyka, governance dostawcy i wpływ niedostępności na odporność operacyjną.

NIS2 również podnosi znaczenie bezpieczeństwa łańcucha dostaw i vulnerability management. NIST AI RMF dodaje do tego język zarządzania ryzykiem AI: Govern, Map, Measure i Manage. W 2026 roku NIST rozpoczął również prace nad profilem AI RMF dla infrastruktury krytycznej.

Przekładając to z frameworków na praktykę:

Model używany do poprawienia maila nie jest krytyczny.

Model używany do klasyfikowania alertów, priorytetyzacji patchingu albo generowania produkcyjnych detekcji może już taki być.

Nie dlatego, że jest AI.

Dlatego, że wpływa na ważną funkcję.

Geopolityka Właśnie Weszła Do Architektury Security

Fable 5 pokazał jeszcze jedną zmianę.

Najbardziej zaawansowane modele AI przestają być zwykłym produktem SaaS.

Zaczynają być traktowane jak zasób strategiczny.

To samo capability, które pozwala obrońcom szybciej znajdować podatności, może pomóc atakującym w budowie exploit chainów. Model przydatny do analizy malware może być przydatny do jego rozwijania. Model wspierający threat hunting może również pomóc w analizowaniu sposobów ominięcia detekcji.

Nie jest więc zaskoczeniem, że państwa zaczynają pytać, kto ma dostęp do takich modeli.

Bardziej interesujące jest to, jak szybko odpowiedź na to pytanie może się zmienić.

W czerwcu dostęp do Fable 5 i Mythos 5 został objęty ograniczeniem skierowanym do cudzoziemców. Później ograniczenie cofnięto, a dostęp przywrócono po aktualizacji zabezpieczeń i negocjacjach między firmą a administracją. Reuters opisał sprawę jako część szerszego wzrostu nadzoru nad premierami modeli frontier. W piśmie cytowanym przez Reutersa amerykański Departament Handlu zastrzegł także możliwość ponownej oceny decyzji i przywrócenia wymogu licencji, jeśli zmienią się okoliczności lub Anthropic nie dotrzyma swoich zobowiązań.

To ważny detal.

Zniesienie ograniczenia nie oznacza, że ryzyko zniknęło.

Oznacza, że dzisiejsza dostępność pozostaje zależna od warunków, których klient końcowy nie kontroluje.

Nie musi to być ostatni taki przypadek.

Możemy wejść w świat, w którym dostęp do określonego capability zależy od państwa, obywatelstwa, branży, programu trusted access, regionu inference, polityki eksportowej i oceny konkretnego zastosowania.

Dla globalnej firmy rodzi to bardzo praktyczne pytania.

Czy analitycy w Polsce, USA, Indiach i Singapurze używają tego samego modelu? Czy te same playbooki działają w każdym regionie? Czy partner zewnętrzny może otrzymać dostęp do workflow? Czy follow-the-sun SOC może przekazywać sprawę między lokalizacjami bez zmiany capability? Co się stanie, gdy jedna część zespołu traci dostęp, a druga nadal go ma?

Do tej pory geopolityka była dla wielu zespołów security przede wszystkim kontekstem threat intelligence.

Teraz może stać się parametrem architektury.

Nie jest to wyłącznie amerykańska dyskusja. 7 lipca 2026 roku Komisja Europejska zaprezentowała plan działań dotyczący AI i cyberbezpieczeństwa. Komisja wskazała, że zaawansowane modele mogą identyfikować podatności, automatyzować ataki i zwiększać skalę oraz szybkość incydentów, a jednocześnie powinny zostać wykorzystane do wzmacniania cyberobrony.

To pokazuje, że problem nie zostanie rozwiązany jednym globalnym regulaminem dostawcy.

Stany Zjednoczone mogą patrzeć na frontier AI przez pryzmat eksportu i bezpieczeństwa narodowego. Unia Europejska będzie łączyć AI governance, ochronę danych, cyber resilience, NIS2 i sektorowe regulacje. Inne państwa mogą rozwijać własne mechanizmy trusted access, sovereign AI albo obowiązki lokalnego przetwarzania.

Dla organizacji oznacza to kolejną warstwę zależności.

Nie wystarczy ocenić model.

Trzeba ocenić model w konkretnym regionie, przy konkretnych danych, na konkretnej platformie i w konkretnym zastosowaniu.

Open Source I Modele Lokalne Nie Są Religią. Są Ubezpieczeniem

W dyskusjach o AI szybko powstają dwa obozy.

Pierwszy twierdzi, że tylko zamknięte modele frontier mają sens, ponieważ oferują najwyższą jakość.

Drugi odpowiada, że jedyną właściwą drogą są modele otwarte i uruchamiane lokalnie.

W cyberbezpieczeństwie takie podejście niewiele daje.

Nie chodzi o ideologię.

Chodzi o odporność.

Model lokalny może być słabszy od Fable 5. Może gorzej analizować duże repozytorium, mieć mniejszy kontekst, słabsze reasoning i wymagać większego nakładu pracy przy utrzymaniu. Może też posiadać własne podatności, problemy z supply chainem i błędy konfiguracji.

Ma jednak jedną bardzo ważną właściwość.

Nie znika dlatego, że dostawca SaaS zmienił politykę dostępu.

Dlatego model lokalny może być dobrym fallbackiem dla części zadań: podstawowego streszczania logów, klasyfikacji niskiego ryzyka, lokalnej redakcji danych, prostego enrichmentu czy utrzymania ograniczonego trybu pracy podczas niedostępności głównego dostawcy.

Nie musi zastępować modelu frontier w każdym zadaniu.

Ma utrzymać minimalną zdolność operacyjną.

Dojrzała architektura może wyglądać tak:

Security workflow
        |
        v
Policy and data classification layer
        |
        v
AI gateway / model router
        |
        +----> Frontier model
        |
        +----> Secondary provider
        |
        +----> Local model
        |
        +----> Deterministic workflow
        |
        +----> Manual playbook

Taki diagram wygląda prosto.

Implementacja już taka nie jest.

Każdy model trzeba przetestować. Każda ścieżka musi respektować klasyfikację danych. Trzeba wiedzieć, czy model lokalny ma wystarczającą jakość, czy drugi dostawca nie wprowadza innej retencji, czy fallback nie łamie wymagań regionalnych i czy proces manualny nadal jest aktualny.

Cloudflare opisał bardzo podobne założenie w swoim vulnerability harness. Discovery i validation zostały rozdzielone między różne modele, a architektura miała absorbować zmiany dostawców i zachowania modeli zamiast zakładać ich stałość.

Nawet niedoskonała ścieżka awaryjna jest lepsza niż architektura oparta na założeniu, że jeden model zawsze będzie dostępny.

Najgorszym Skutkiem AI Lock-In Może Być Utrata Kompetencji

Technologię można zmienić.

Trudniej odbudować zespół, który przestał umieć pracować bez niej.

Jeżeli analityk SOC przez rok zaczyna każdy przypadek od gotowego podsumowania, inaczej rozwija swoje kompetencje. Rzadziej samodzielnie buduje timeline. Rzadziej porównuje logi z kilku źródeł. Rzadziej musi wyjaśnić, dlaczego jedna hipoteza jest bardziej prawdopodobna od innej.

Jeżeli junior AppSec przez rok dostaje listę potencjalnych błędów od modelu, może nauczyć się weryfikowania sugestii, ale niekoniecznie samodzielnego znajdowania trust boundaries.

Jeżeli detection engineer generuje reguły z promptu, może przestać zwracać uwagę na normalizację pól, jakość telemetry i ograniczenia konkretnego SIEM-a.

Jeżeli malware analyst od razu otrzymuje opis pseudokodu, może rzadziej ćwiczyć mozolną pracę, która pozwala zauważyć, że model źle zinterpretował fragment próbki.

To nie jest argument przeciwko AI.

Kalkulator również nie jest argumentem przeciwko matematyce.

Problem pojawia się wtedy, gdy człowiek nie potrafi zweryfikować wyniku.

W security weryfikacja jest wszystkim.

Dlatego zespoły korzystające z AI powinny okresowo wykonywać AI-off drills.

Nie chodzi o teatralne wyłączenie dostępu na tydzień. Wystarczy wybrać jeden proces i przeprowadzić kontrolowane ćwiczenie. SOC może obsłużyć jedną zmianę bez automatycznego triage. AppSec może ręcznie przeanalizować krytyczny moduł. PSIRT może wykonać pełną ocenę zgłoszenia bez modelu. Detection engineering może przygotować i przetestować regułę bez generatora.

Następnie mierzymy różnicę.

Jak zmienił się czas triage? Ile alertów trafiło do eskalacji? Czy wzrosła liczba błędnych decyzji? Które playbooki były nieaktualne? Które kompetencje istnieją tylko u jednej osoby? Jak długo proces może działać w trybie manualnym?

Lepiej poznać te odpowiedzi podczas ćwiczenia niż podczas prawdziwego incydentu.

Jedna Mapa Ryzyka, Którą Warto Zbudować

Nie potrzeba kilkunastu tabel. Jedna wystarczy, żeby zobaczyć, że AI vendor risk nie jest pojedynczym problemem.

RyzykoJak wygląda w praktycePrzykład w cyberbezpieczeństwieSensowna kontrola
Niedostępność modeluModel zostaje wyłączony lub ograniczonySOC traci automatyczny triagemodel alternatywny, manualny playbook, AI-off drill
Policy driftDostawca zmienia klasyfikatory lub guardrailslegalne zadania AppSec zaczynają być odrzucanemonitoring refusals, testy regresyjne promptów
Capability driftPo aktualizacji model odpowiada inaczejspada jakość CVE triage lub detekcjiwewnętrzne evals, wersjonowanie modeli i promptów
Ukryty fallbackZapytanie obsługuje inny model, ale API nadal działaFable odmawia, Opus zwraca odpowiedźlogowanie requested model, served model i fallback reason
Retencja danychPrompt i odpowiedź muszą być przechowywanelogi incydentu trafiają do 30-dniowej retencjiklasyfikacja, minimalizacja, redakcja, alternatywny model
JurysdykcjaDostęp zależy od państwa i decyzji regulatoraczęść globalnego zespołu traci dostępanaliza regionów, plan migracji, rozwiązanie lokalne
KoncentracjaKilka procesów opiera się na jednym dostawcySOC, AppSec i PSIRT używają jednego modelumodel router, drugi dostawca, manualny fallback
Utrata kompetencjiLudzie przestają ćwiczyć proces bez AIL1 nie potrafi samodzielnie zbudować timeline’uszkolenia, ręczne review, okresowe AI-off drills
Brak audytowalnościNie wiadomo, skąd wzięła się decyzjaIR wykonał izolację na podstawie niezapisanej odpowiedziprovenance, output hash, human approval
Ryzyko kosztoweModel lub fallback zmienia ekonomię procesuautomatyczny triage przestaje się opłacaćbudżety, routing, limity, FinOps dla AI

Ta tabela nie powinna zostać wypełniona raz i odłożona do audytu.

Model może zmieniać się częściej niż typowy dostawca SaaS. Ocena powinna być więc powiązana z realnymi zdarzeniami: nową wersją modelu, zmianą retencji, zmianą guardrails, nowym fallbackiem, zmianą regionu albo istotnym incydentem.

Rejestr Użycia AI Powinien Być Nudny

Najbardziej praktyczna rzecz, jaką można zrobić po historii Fable 5, jest mało efektowna.

Zbudować rejestr użycia AI.

Nie taki, którego zaprojektowanie zajmuje sześć miesięcy. Nie taki, w którym każda komórka musi przejść przez trzy komitety. Na początek wystarczy wiedzieć, jaki model jest używany, do czego, przez kogo, na jakich danych i co się stanie, gdy przestanie być dostępny.

Przykładowy wpis może wyglądać tak:

ai_usage_register:
  - id: ai-soc-triage-001

    provider: anthropic
    requested_model: claude-fable-5
    fallback_model: claude-opus-4-8

    process: SOC alert triage

    owners:
      business: Head of Security Operations
      technical: SOC Automation Lead

    input_data:
      - edr_alerts
      - identity_context
      - asset_metadata

    data_classification:
      - internal
      - security_sensitive

    output:
      - alert_summary
      - recommended_severity
      - next_steps

    decision_impact: advisory
    human_approval_required: true
    criticality: high

    data_retention:
      minimum_days: 30
      zero_data_retention_available: false

    fallback:
      enabled: true
      manual_playbook: SOC-PB-014

    monitoring:
      log_requested_model: true
      log_served_model: true
      log_refusals: true
      log_fallbacks: true

    evals:
      last_run: 2026-07-15
      critical_recall: 0.91
      false_positive_rate: 0.14

    jurisdiction_risk: medium
    exit_plan: AI-EXIT-SOC-001

To nie jest najbardziej ekscytujący YAML, jaki zobaczysz w życiu.

Ale po kilku miesiącach może być różnicą między kontrolowaną migracją a panicznym przepisywaniem procesu podczas incydentu.

Bez takiego rejestru organizacja nie wie, od czego zależy.

A jeśli nie wie, od czego zależy, nie zarządza ryzykiem.

Ma tylko nadzieję.

Dlaczego To Ma Znaczenie

Dla CISO

CISO nie powinien pytać wyłącznie, gdzie AI może zwiększyć produktywność.

Powinien również wiedzieć, które procesy zaczynają od niego zależeć.

Jeżeli brak modelu wpływa na czas reakcji, zdolność wykrywania, patching, obsługę zgłoszeń albo komunikację podczas incydentu, mamy do czynienia z ryzykiem operacyjnym. Taki model powinien znaleźć się w rejestrze dostawców, posiadać właściciela, plan awaryjny i mierzalne wymagania jakościowe.

Historia Fable 5 pokazuje też, że warunki dostępu do frontier AI mogą być ustalane poza relacją klient–dostawca. Umowa z dostawcą nie daje pełnej kontroli nad prawem eksportowym, decyzją państwa ani zmianą klasyfikacji ryzyka modelu.

CISO nie musi przewidywać każdej decyzji politycznej.

Musi zadbać, żeby pojedyncza decyzja polityczna nie zatrzymała kluczowego procesu.

Dla SOC

SOC musi uważać, żeby AI nie stało się niewidzialną warstwą decyzyjną.

Model może przygotowywać summary, korelować dane i sugerować działania. Trzeba jednak logować, jaki model faktycznie odpowiedział, czy zadziałał fallback, jaką wersję promptu wykorzystano i czy analityk zmienił rekomendację.

Jeżeli 99% sugestii jest automatycznie zatwierdzanych przez człowieka, formalnie mamy human-in-the-loop.

Operacyjnie decyzję podejmuje model.

To różnica, którą warto mierzyć.

Dla AppSec I PSIRT

AI powinno być traktowane jako bardzo szybki generator hipotez i narzędzie wspierające walidację, nie jako wyrocznia.

Finding powinien posiadać evidence, warunki reachability, reproducer, ocenę confidence i jasne ograniczenia. Model zastępczy powinien przejść ten sam zestaw evals co model główny.

Największym ryzykiem nie jest to, że AI raz się pomyli.

Największym ryzykiem jest automatyczne skalowanie pomyłki na setki repozytoriów i tysiące zgłoszeń.

Dla Zarządu

Zarząd nie musi rozumieć różnicy między stop_reason: "refusal" a błędem HTTP 503.

Powinien natomiast rozumieć zależność.

Jeżeli firma wykorzystuje zewnętrzny model w procesach mających wpływ na bezpieczeństwo, musi wiedzieć, jak długo może działać bez niego, jaka jest alternatywa oraz kto odpowiada za decyzję o przełączeniu.

To ten sam poziom rozmowy, który od lat prowadzimy o chmurze, operatorze telekomunikacyjnym, dostawcy tożsamości czy systemie płatniczym.

AI nie jest wyjątkiem.

Co Sprawdzić W Tym Tygodniu

Ta checklista ma sens tylko wtedy, gdy ktoś rzeczywiście wykona te kroki.

  1. Zidentyfikuj procesy security korzystające z AI. Nie tylko oficjalne integracje. Zapytaj SOC, AppSec, PSIRT, GRC, detection engineering i incident response o narzędzia używane również nieformalnie.
  2. Sprawdź logi gatewaya i aplikacji. Poszukaj pól requested_model, served_model, stop_reason, fallback_ran i refusal_category. Jeśli tych danych nie ma, nie wiesz, jaki model wykonuje realną pracę.
  3. Policz refusal rate i fallback rate. Oddziel odmowę klasyfikatora od 429, timeoutów i błędów 5xx. To różne tryby degradacji i wymagają różnych reakcji.
  4. Zweryfikuj retencję. Sprawdź, czy do Covered Models trafiają dane, dla których 30-dniowa retencja jest akceptowalna.
  5. Uruchom własne evals. Weź historyczne alerty, pull requesty, CVE i reguły detekcyjne. Porównaj model główny z fallbackiem na tych samych przypadkach.
  6. Zdefiniuj minimalny akceptowalny poziom jakości. Nie wystarczy, że model odpowiada. Określ maksymalny false positive rate, minimalny recall i przypadki, w których wymagane jest ręczne review.
  7. Zbuduj tryb degradacji. Ustal, co robi SOC, AppSec i PSIRT bez modelu głównego, bez wszystkich modeli zewnętrznych i bez dostępu do internetu.
  8. Sprawdź umowę oraz polityki dostawcy. Interesują Cię deprecation, regiony, retencja, subprocessors, fallback, export controls, incident notification i warunki rozwiązania usługi.
  9. Przeprowadź AI-off drill. Wyłącz jeden workflow na stagingu albo podczas kontrolowanej zmiany i zmierz rzeczywisty wpływ.
  10. Sprawdź kompetencje ludzi. Jeśli proces manualny istnieje tylko w dokumentacji, ale nikt nie wykonywał go od roku, prawdopodobnie nie jest prawdziwym fallbackiem.

Przykładowe zapytanie KQL do sprawdzenia, czy Fable jest zastępowany innym modelem:

AIGatewayLogs
| where Timestamp > ago(30d)
| where RequestedModel == "claude-fable-5"
| summarize
    Requests = count(),
    Refusals = countif(StopReason == "refusal"),
    Fallbacks = countif(FallbackRan == true),
    ResponsesFromDifferentModel =
        countif(ServedModel != RequestedModel)
  by bin(Timestamp, 1d), ServedModel
| order by Timestamp asc

Jeżeli nie jesteś w stanie wykonać podobnego zapytania we własnym środowisku, właśnie znalazłeś pierwszy problem do naprawy.

Podsumowanie

Project Glasswing pokazał, że AI może przyspieszyć vulnerability discovery.

Mythos pokazał, że model może wykonywać pracę, którą jeszcze niedawno kojarzyliśmy z bardzo doświadczonym researcherem: analizować duże repozytorium, budować hipotezy, łączyć kilka prymitywów w exploit chain i przygotowywać materiał ułatwiający potwierdzenie podatności.

Cloudflare pokazał, że sam model nie wystarcza. Potrzebne są reconnaissance, niezależna walidacja, deduplikacja, analiza reachability, formalny triage i proces remediacji.

Fable 5 pokazał trzecią lekcję.

Nawet najlepszy model nie jest stabilnym fundamentem bezpieczeństwa, jeśli organizacja nie kontroluje jego dostępności, polityki i sposobu przetwarzania danych.

Fable 5 wrócił.

To dobra wiadomość dla użytkowników.

Nie zmienia jednak faktu, że został wyłączony trzy dni po premierze, później przywrócony po interwencji państwa i aktualizacji zabezpieczeń, a jego mniej ograniczony odpowiednik nadal pozostaje usługą kontrolowanego dostępu.

Ten przypadek nie powinien prowadzić do wniosku, że nie warto używać AI w cyberbezpieczeństwie.

To byłby absurd.

AI będzie wspierać SOC, AppSec, PSIRT, threat intelligence, malware analysis, detection engineering, vulnerability management i incident response. Będzie pozwalać mniejszym zespołom wykonywać więcej pracy. Będzie skracać czas analizy i zdejmować z ludzi część powtarzalnych zadań.

Trzeba tylko przestać udawać, że AI jest magicznym asystentem, który po prostu zawsze będzie.

AI staje się dostawcą.

Dostawców się ocenia, monitoruje i testuje. Dla dostawców buduje się fallback oraz exit plan. A ludzi szkoli się tak, żeby potrafili działać również wtedy, gdy dostawca przestaje być dostępny.

Najważniejsze pytanie po historii Fable 5 nie brzmi więc:

Który model jest dziś najlepszy?

Brzmi inaczej:

Czy nasz proces bezpieczeństwa przetrwa dzień, w którym najlepszy model zostanie wyłączony, zmieni politykę albo po cichu przekaże swoją pracę komuś innemu?

Jeżeli nie znasz odpowiedzi, nie masz problemu z AI.

Masz problem z procesem.

Bibliografia