Logi audytowe bez treści: jak dowodzimy, co zrobił model, nie przechowując promptów

Każde działanie administracyjne w AI Suite generuje wiersz audytu w formacie JSONL. Wiersz rejestruje znacznik czasu, adres e-mail aktora, czasownik działania, zasób, którego dotyczy, nagłówek X-App-Id klienta inicjującego oraz stabilny hash, który pozwala recenzentowi powiązać wiersz z późniejszymi zdarzeniami. Wiersz nie rejestruje żadnych danych wejściowych ani wyjściowych modelu. Żadnego tekstu promptu, żadnego tekstu uzupełnienia, żadnej treści dokumentu, żadnych wyodrębnionych encji. Ten wybór — bez treści z założenia — czyni wiersz audytu użytecznym dla recenzentów zakupowych i ds. zgodności, i warto wyjaśnić, dlaczego.

Co zawiera wiersz audytu, a czego w nim nie ma

Reprezentatywny wiersz, w nieznacznie zredagowanej postaci:

{"ts":"2026-06-05T09:14:22Z","actor":"[email protected]","action":"license.assign",
 "subject":"[email protected]","tier":"commercial","x_app_id":"ai-admin-console",
 "ip":"10.4.1.22","ua_hash":"a17c…","seq":48211}

Co zawiera: wystarczającą ilość metadanych, aby odpowiedzieć na pytania dotyczące obowiązków podmiotu stosującego, które zadają audytorzy — kto co zrobił, kiedy, wobec którego zasobu, z którego klienta. Czego nie zawiera: jakiegokolwiek ładunku z procesu AI. Gdyby działanie wywoływało model (w tym przykładzie tak nie było, ale mogłoby), istniałby wiersz rejestrujący zdarzenie wywołania, lecz bez zapisu promptu ani odpowiedzi w naszej infrastrukturze.

Rozdzielenie to jest zamierzone. Wiersz audytu stanowi dowód, że działanie miało miejsce. Treść tego działania — prompt wysłany do modelu, odpowiedź zwrócona — pozostaje na sprzęcie podmiotu stosującego, podlegając jego własnej polityce retencji. My jej nigdy nie widzimy.

Dlaczego treść pozostaje poza wierszem

Dwa powody, jeden regulacyjny i jeden operacyjny.

Regulacyjny: EU AI Act wymaga, aby podmioty stosujące AI wysokiego ryzyka prowadziły logi „przez odpowiedni okres”, monitorowały działanie systemu i wykazywały zgodność na żądanie ^[1]. Obowiązek wykazania, co się wydarzyło, spoczywa na podmiocie stosującym. Chmurowe API LLM odpowiadają na to, przechowując prompt i odpowiedź w infrastrukturze dostawcy, co przenosi problem postępowania z danymi na dostawcę — i tworzy drugi perymetr zgodności, którego podmiot stosujący nie kontroluje. Lokalny audyt bez treści odpowiada na to samo pytanie regulacyjne bez owego przeniesienia: to podmiot stosujący przechowuje treść, w swojej własnej pamięci, według własnych reguł retencji.

Operacyjny: każdy bajt treści modelu, który jest przechowywany, to bajt, który trzeba szyfrować, obejmować kontrolą dostępu, retencjonować, kasować zgodnie z harmonogramem i wytwarzać w toku e-discovery. Wiersze bez treści są małe (kilkaset bajtów), o stałym kształcie, dopisywane na koniec (append-only) i trywialnie serializowalne do istniejącego SIEM podmiotu stosującego. Stanowią one najmniejszą jednostkę dowodową, która wciąż spełnia obowiązek.

Jak odwzorowuje się to w głównych ramach regulacyjnych

NIST AI RMF 1.0 wskazuje audytowalność jako podstawowy wymiar godnej zaufania AI i wymaga od podmiotów stosujących utrzymywania „zapisów działań systemu w stopniu wystarczającym do odtworzenia decyzji” ^[2]. „W stopniu wystarczającym do odtworzenia” jest tu frazą operacyjną: wiersz musi pozwolić recenzentowi odtworzyć to, co się wydarzyło. Wiersz bez treści realizuje to dla działań administracyjnych (wydano licencję, zmieniono politykę, włączono serwer) bez zachowywania treści wnioskowania. W odniesieniu do strony treściowej obowiązku odpowiedzi udziela lokalna pamięć podmiotu stosującego.

Wytyczne ENISA dotyczące cyberbezpieczeństwa AI ujmują to z perspektywy modelowania zagrożeń ^[3]: każdy prompt i każda odpowiedź przechowywane w infrastrukturze dostawcy poszerzają powierzchnię ataku podmiotu stosującego o powierzchnię dostawcy. Usunięcie treści modelu po stronie dostawcy zawęża tę powierzchnię do tego, co podmiot stosujący już kontroluje.

Kształt, w którym dostarczamy nasze produkty — interfejs AI Admin Console, audyt JSONL demona aisuite-server oraz hak przekierowujący zdarzenia do SIEM na poziomie organizacji — realizuje to wprost. Każde zdarzenie administracyjne trafia do wiersza czytelnego dla podmiotu stosującego; żadna treść promptu ani odpowiedzi nigdy nie opuszcza jego perymetru.

Jak to wygląda w przeglądzie zakupowym

Pytanie zakupowe, na którym grzęzną dostawcy chmurowej AI, brzmi: „gdzie znajduje się treść wnioskowania i czy nasz zespół ds. zgodności jest w stanie wytworzyć ją na żądanie?”. Pytanie zakupowe, na które odpowiada audyt bez treści, to to samo pytanie, z dwiema klarownymi odpowiedziami: treść znajduje się na Państwa sprzęcie, a Państwa zespół ją wytwarza, ponieważ już ją posiada. Wiersz audytu po naszej stronie dowodzi, że działanie miało miejsce; treść po Państwa stronie dowodzi, co to działanie zrobiło.

Szersze ujęcie zakupowe — w tym jak rozpoczynać kwestionariusz dostawcy od tych właściwości, a nie od certyfikatów po stronie dostawcy — znajduje się w artykule Dlaczego wdrożenia AI on-prem grzęzną na etapie zakupów oraz w artykule o zgodności z EU AI Act.

Co pozostaje odpowiedzialnością podmiotu stosującego

Audyt bez treści jest strukturalną właściwością wdrożenia, a nie kompleksowym rozwiązaniem zgodności. Na podmiocie stosującym wciąż spoczywa:

• Zdefiniowanie, co oznacza „w stopniu wystarczającym do odtworzenia” dla jego własnych procesów — okres retencji, reguły maskowania, postawa wobec e-discovery.
• Operowanie lokalną pamięcią treści (cokolwiek wybierze podmiot stosujący — system plików, baza dokumentowa, szyfrowany blob store) oraz przekazywanie wierszy audytu z naszej strony do SIEM, w którym koreluje je z własnymi logami.
• Sporządzenie memorandum dotyczącego obowiązków podmiotu stosującego, które wskazuje na tę architekturę podczas postępowania zakupowego.

Po naszej stronie dostarczamy architekturę i format wiersza audytu. Wszystko, co znajduje się dalej — w tym polityka retencji treści — jest miejscem, w którym zespół ds. zgodności podmiotu stosującego stosuje własne reguły.

Źródła

1. European Commission. „AI Act — Regulatory framework on AI.” digital-strategy.ec.europa.eu. Dostęp: 2026-06-03.
2. NIST. „AI Risk Management Framework (AI RMF 1.0).” nist.gov/itl/ai-risk-management-framework. Dostęp: 2026-06-03.
3. ENISA. „Artificial Intelligence Cybersecurity.” enisa.europa.eu/topics/iot-and-smart-infrastructures/artificial-intelligence. Dostęp: 2026-06-03.

Powiązane artykuły

• AI Admin Console: co naprawdę robi każda z sześciu funkcji
• Zero nieudanych projektów od 2007 r. — reguły inżynierskie, na których opiera się ten bilans
• EU AI Act w 2026 r.: co wdrożenie on-prem zmienia w zakresie zgodności
• Dlaczego wdrożenia AI on-prem grzęzną na etapie zakupów (i ujęcie, które to rozwiązuje)
• Wszystkie artykuły →