Metodologia. Co mierzymy i co uznajemy za dowód.

Nie prosimy, żebyście nam wierzyli. Prosimy, żebyście to sprawdzili.

Portal, który publikuje incydenty bezpieczeństwa, ma dwie możliwe strategie. Pierwsza — budować autorytet na tym, że brzmi się pewnie. Druga — budować go na tym, że każdy wpis można sprawdzić, zakwestionować i — jeśli jest błędny — wycofać publicznie.

Wybieramy drugą. Nie dlatego, że jest wygodniejsza — nie jest. Dlatego, że pierwsza jest tym samym, co zarzucamy większości rynku AI: pewność bez pomiaru, autorytet bez weryfikacji, przekonanie bez dowodu.

Każdy wpis w tym laboratorium ma identyfikator, status dowodowy i poziom confidence. Każdy zawiera wyraźne rozdzielenie tego, co potwierdzone, od tego, co wywnioskowane. Każdy zawiera źródła z datą dostępu. Jeżeli któryś okaże się błędny — publikujemy sprostowanie zamiast go ukrywać.

Co trafia do rejestru. I dlaczego nie tylko modele językowe.

Rejestr obejmuje zdarzenia w Polsce (lub z polską jurysdykcją), w których zautomatyzowany system generował treść albo podejmował lub przygotowywał decyzję, a brak kontroli nad nim wyrządził szkodę lub stworzył realne ryzyko. Wymagamy publicznie dostępnego materiału źródłowego.

Do rejestru trafiają więc nie tylko modele generatywne, lecz także klasyfikatory uczenia maszynowego i algorytmy deterministyczne — bo ta sama brakująca warstwa kontroli zawodzi w nich w ten sam sposób. Żeby nie mieszać tych przypadków, każdy wpis ma pole typ systemu: model generatywny, klasyfikator ML albo algorytm deterministyczny. Kto szuka wyłącznie incydentów z udziałem AI w wąskim sensie, może je odfiltrować.

Obserwacje własne (seria OBS). Osobno publikujemy obserwacje z sesji prowadzonych przez autora z publicznie dostępnymi modelami. Nie spełniają kryterium rejestru — nie są zdarzeniami, które wyrządziły szkodę, i nie mają zewnętrznego źródła — dlatego mają własną numerację (OBS-RRRR-NNN) i własny status: OBSERWACJA, czyli pojedyncza sesja z transkryptem dostępnym na życzenie. Po udokumentowanym powtórzeniu protokołu obserwacja może otrzymać status REPRODUCED. Pojedyncza obserwacja nigdy nie jest podstawą twierdzeń o częstości zjawiska.

Lista rzeczy, które nie są dowodem — nawet jeżeli brzmią jak dowód.

Większość „analiz bezpieczeństwa AI" w polskim internecie opiera się na materiałach z tej listy. Nasza metodologia zabrania ich używania. Nie dlatego, że są bezwartościowe — dlatego, że są nieodróżnialne od twierdzeń wiarygodnych, jeżeli nie postawi się ich w kontekście.

• Twierdzenie dostawcy o własnym produkcie. Marketing, whitepaper, prezentacja — to materiał o tym, co dostawca chce, żeby było prawdą, nie o tym, co jest. Oznaczamy jako VENDOR CLAIM i nigdy nie podnosimy do VERIFIED.
• Pojedynczy output modelu bez reprodukcji. Jeżeli jeden użytkownik raz zapytał ChatGPT i dostał odpowiedź X — to anegdota, nie incydent.
• Screenshot bez kontekstu. Może być prawdziwy, wygenerowany, z innej sesji, przetworzony. Publikujemy tylko jako uzupełnienie do innych źródeł.
• Anonimowe oskarżenie. „Osoba zbliżona do projektu twierdzi…" — bez nazwiska, bez dokumentu. To nie dowód, to plotka.
• Analiza marketingowa jako fakt. „Badania rynkowe pokazują, że 89%…" — jeżeli za liczbą nie stoi metodologia i podmiot badawczy, to nie dana, to teza.
• Wnioskowanie z samych objawów. „System zachował się niespójnie, więc na pewno został zaatakowany prompt injection." Bez logów to INFERENCE, nie VERIFIED.
• Film na YouTube bez materiałów źródłowych. Nawet jeżeli nagranie jest autentyczne — bez danych wejściowych i wyjściowych to materiał publicystyczny.
• „Eksperci twierdzą". Bez nazwisk i afiliacji. To nie źródło — to figura retoryczna.

Każdy wpis ma tę samą strukturę. Pola obowiązkowe oznaczone gwiazdką.

Ujednolicony format pozwala porównywać wpisy między sobą bez względu na to, czy dotyczą modelu językowego, algorytmu rekomendacji czy bota telefonicznego.

Twierdzenia i źródła mają własne identyfikatory. Każde twierdzenie z karty dostaje stały numer (np. PL-AI-2024-002-T01) i własny status — fakt ze źródłem albo wniosek (INFERENCE). Każde źródło ma identyfikator EVID i listę twierdzeń, które na nim opieramy. Pełne listy: rejestr twierdzeń i rejestr źródeł; całość jako plik: dane do pobrania. Pojęcia używane w kartach wyjaśnia słownik.

Uwaga o brakującej kontroli. To miejsce, w którym metodologia łączy się z fundamentem teoretycznym laboratorium — Perceptual Control Theory i Reference Signal Engineering. Pytanie „jakiej kontroli brakowało” to w istocie pytanie, które PCT zadaje systemom od 1960 roku.

Czego ta metodologia nie robi.

Metodologia, która nie definiuje własnych granic, jest zaproszeniem do nadużyć. Poniżej lista rzeczy, które są poza zakresem tego laboratorium.

• Nie oceniamy intencji. Nie piszemy, że ktoś „wiedział", „chciał", „ukrywał". Analizujemy architekturę i mechanizmy, nie motywacje osób.
• Nie publikujemy rankingów firm. Polish AI Failure Index to indeks klas awarii, nie lista „najgorszych dostawców".
• Nie wykonujemy testów na systemach bez zgody właściciela. Audyty robimy wyłącznie na systemach z formalnym dostępem.
• Nie publikujemy danych klientów. Audyty komercyjne są poufne. Publiczny rejestr zawiera wyłącznie przypadki ze źródeł publicznych.
• Nie sprzedajemy godzin. Każdy audyt ma stały zakres i stałą cenę, ustalone pisemnie przed rozpoczęciem pracy.
• Nie gwarantujemy bezpieczeństwa. Audyt identyfikuje granice zaufania i brakujące warstwy kontroli — nie gwarantuje, że system jest bezpieczny.
• Nie zastępujemy regulatora ani sądu. Nasza klasyfikacja zdarzeń nie ma mocy prawnej.
• Nie uznajemy twierdzeń modelu o sobie samym. Jeżeli system AI opisuje własną architekturę, traktujemy to jak deklarację dostawcy (VENDOR CLAIM), nigdy jako dowód.