Rejestr incydentów jest tyle wart, ile reguły, którymi się go buduje. Ta strona definiuje te reguły — hierarchię statusów dowodowych, model confidence, format karty dowodowej i zasadę falsyfikowalności.
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ć.
„Bezpieczeństwo systemu AI" to nie jedna właściwość. To kilka od siebie niezależnych warstw, z których każda może zawieść osobno i każda wymaga osobnego pomiaru. Nasz rejestr i nasze audyty patrzą na każdą z nich.
Co system faktycznie robi w odpowiedzi na bodziec, a nie co deklaruje w system prompcie. Sycophancy, konfabulacje, skłonność do potwierdzania fałszywej premisy.
Jakie komponenty istnieją, jak są połączone, gdzie przebiegają granice zaufania między użytkownikiem, modelem, retrievalelem i warstwą wykonawczą.
Gdzie trafiają dane wejściowe, jakie integracje mają do nich dostęp, co jest logowane, co jest przechowywane i przez kogo może być odzyskane.
Czy agent może zrobić więcej niż powinien. Zasada minimalnych uprawnień, bramy zatwierdzeń, eskalacja uprawnień, brak rozdzielenia ról.
Co jest retrievowane, jak jest rankowane, czy odpowiedź jest rzeczywiście ugruntowana w źródle, czy tylko nim podparta w narracji.
Czy istnieje niezależny komparator między twierdzeniem systemu a niezależnie uzyskanym zapisem. Jeżeli nie — to jest pytanie tej warstwy.
Co system faktycznie wykonuje — nie co planuje, nie co opisuje. Logi wykonania, efekty uboczne, ślady w systemach zewnętrznych.
Każdy wpis w rejestrze ma jeden — i tylko jeden — status dowodowy. Status nie jest opinią. Jest deklaracją tego, jakiego rodzaju materiał za wpisem stoi.
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.
Confidence to nie ozdoba. To deklaracja o sile dowodów, z których zbudowany jest wpis. Każdy wpis ma jednoznacznie przypisany poziom i jednozdaniowe uzasadnienie.
Opiera się na materiale, który można sprawdzić niezależnie — dwa niezależne źródła, dokument regulatora, prawomocny wyrok.
Opiera się na materiale częściowo potwierdzonym lub pojedynczym źródle wysokiej jakości bez drugiego potwierdzenia.
Opiera się na materiale niepotwierdzonym lub pojedynczych świadectwach bez dokumentacji technicznej.
Ujednolicony format pozwala porównywać wpisy między sobą bez względu na to, czy dotyczą modelu językowego, algorytmu rekomendacji czy bota telefonicznego.
Uwaga o CONTROL FAILURE. To miejsce, w którym metodologia łączy się z fundamentem teoretycznym laboratorium — Perceptual Control Theory i Reference Signal Engineering. Pytanie „jakiej kontroli brakowało" jest tym samym pytaniem, które PCT zadaje systemom od 1960 roku.
Wpis, którego nie można obalić, nie jest wpisem dowodowym — jest manifestem. Dlatego przy każdym przypadku publikujemy warunki, po spełnieniu których wycofamy lub istotnie zmienimy wniosek.
Jak wygląda wycofanie. Wpis nie jest usuwany. Otrzymuje adnotację z datą i powodem. Jeżeli wniosek zostaje istotnie zmieniony — publikujemy osobną notatkę, nie edytujemy po cichu.
Metodologia, która nie definiuje własnych granic, jest zaproszeniem do nadużyć. Poniżej lista rzeczy, które są poza zakresem tego laboratorium.