Każda akcja administracyjna w AI Suite generuje wiersz audytu w formacie JSONL. Wiersz zawiera znacznik czasu, e-mail aktora, czasownik akcji, zasób, którego dotyczy, X-App-Id pochodzącego klienta oraz stabilny hash, który pozwala recenzentowi powiązać wiersz z późniejszymi zdarzeniami. Wiersz zawiera żadnych danych wejściowych ani wyjściowych modelu. Brak tekstu promptu, brak tekstu odpowiedzi, brak treści dokumentu, brak wyodrębnionych encji. Ten wybór — bez treści z założenia — sprawia, że wiersz audytu jest użyteczny dla przeglądających z działów zakupów i zgodności, i warto wyjaśnić dlaczego.

Co jest w wierszu audytu, a czego nie ma

Przykładowy wiersz, lekko zredagowany:

{"ts":"2026-06-05T09:14:22Z","actor":"jane@bank.example","action":"license.assign",
 "subject":"user@bank.example","tier":"commercial","x_app_id":"ai-admin-console",
 "ip":"10.4.1.22","ua_hash":"a17c…","seq":48211}

Co zawiera: wystarczające metadane, by odpowiedzieć na pytania audytorów dotyczące obowiązków wdrażającego — kto co zrobił, kiedy, wobec jakiego zasobu, z jakiego klienta. Czego nie zawiera: żadnej treści z przepływu AI. Gdyby akcja wywołała model (w tym przykładzie nie wywołała, ale mogła), pojawiłby się wiersz rejestrujący zdarzenie wywołania, ale bez zapisu promptu czy odpowiedzi w naszej infrastrukturze.

To rozdzielenie jest celowe. Wiersz audytu to dowód, że akcja miała miejsce. Zawartość działania — wysłane do modelu polecenie, zwrócona odpowiedź — pozostaje na sprzęcie własnym wdrażającego, zarządzana zgodnie z jego polityką retencji. My nigdy tego nie widzimy.

Dlaczego zawartość pozostaje poza wierszem

Dwa powody, jeden regulacyjny, drugi operacyjny.

Regulacyjny: unijna ustawa o AI wymaga od wdrażających wysokiego ryzyka AI prowadzenia dzienników „przez odpowiedni okres”, monitorowania działania systemu oraz wykazywania zgodności na żądanie [1]. Obowiązek wykazania, co się wydarzyło, spoczywa na wdrażającym. Chmurowe API LLM rozwiązują to przez przechowywanie polecenia i odpowiedzi na infrastrukturze dostawcy, co przenosi problem przetwarzania danych na dostawcę — i tworzy drugi obszar zgodności, którego wdrażający nie kontroluje. Audyt lokalny bez zawartości odpowiada na to samo pytanie regulacyjne bez takiego przeniesienia: wdrażający przechowuje zawartość we własnym magazynie, zgodnie z własnymi zasadami retencji.

Operacyjny: każdy bajt przechowywanej zawartości modelu to bajt, który trzeba zaszyfrować, kontrolować dostęp, przechowywać, usuwać zgodnie z harmonogramem i udostępniać w ramach e-discovery. Wiersze bez zawartości są małe (kilkaset bajtów), o stałym kształcie, tylko do dopisywania i łatwo serializowalne do istniejącego SIEM wdrażającego. Są najmniejszą jednostką dowodową, która nadal spełnia obowiązek.

Co to odpowiada w głównych ramach

NIST AI RMF 1.0 wymienia audytowalność jako kluczowy wymiar godnej zaufania AI i wymaga od wdrażających utrzymywania „rejestrów działań systemu wystarczających do odtworzenia decyzji” [2]. „Wystarczających do odtworzenia” to kluczowe wyrażenie: wiersz musi pozwolić recenzentowi odtworzyć, co się wydarzyło. Wiersz bez zawartości robi to dla działań administracyjnych (wydano licencję, zmieniono politykę, zarejestrowano serwer) bez przechowywania zawartości wniosku. W przypadku obowiązku dotyczącego zawartości wniosku, lokalny magazyn wdrażającego jest odpowiedzią na to pytanie.

Wytyczne ENISA dotyczące cyberbezpieczeństwa AI przedstawiają to z perspektywy modelowania zagrożeń [3]: każde polecenie i odpowiedź przechowywane na infrastrukturze dostawcy poszerzają powierzchnię ataku wdrażającego o powierzchnię dostawcy. Usunięcie zawartości modelu z infrastruktury dostawcy zawęża tę powierzchnię do tego, co wdrażający już kontroluje.

Kształt, który dostarczamy — AI Admin Console interfejs użytkownika, aisuite-server demon JSONL audytu oraz hak do przekazywania do SIEM na poziomie organizacji — implementują to bezpośrednio. Każde zdarzenie administracyjne trafia do wiersza czytelnego dla wdrażającego; na lokalnej lub klienta ścieżce inferencji, zawartość promptu i odpowiedzi nie trafia do płaszczyzny kontrolnej Software Tailor.

Jak to wygląda podczas przeglądu zamówienia

Pytanie zakupowe, które blokuje dostawców chmurowej AI, brzmi: „gdzie przechowywana jest zawartość inferencji i czy nasz zespół ds. zgodności może ją na żądanie wygenerować?” Pytanie, na które odpowiada audyt bez zawartości, jest takie samo, z dwoma jasnymi odpowiedziami: zawartość znajduje się na Twoim sprzęcie, a Twój zespół ją generuje, ponieważ już ją posiada. Wiersz audytu z naszej strony potwierdza, że akcja miała miejsce; zawartość z Twojej strony potwierdza, co ta akcja zrobiła.

Dla szerszego kontekstu zakupowego — w tym jak prowadzić kwestionariusz dostawcy z tymi właściwościami zamiast opierać się na certyfikatach dostawcy — zobacz Dlaczego wdrożenia AI on-premises blokują się w procesie zakupowym oraz artykuł o zgodności z EU AI Act.

Co pozostaje w gestii wdrażającego

Audyt bez zawartości to właściwość strukturalna wdrożenia, a nie kompleksowe rozwiązanie zgodności. Wdrażający nadal odpowiada za:

  • Definiowanie, co oznacza „wystarczające do odtworzenia” dla własnych procesów — okres przechowywania, zasady maskowania, podejście do e-discovery.
  • Obsługę lokalnego magazynu zawartości (cokolwiek wybierze wdrażający — system plików, baza dokumentów, zaszyfrowany magazyn blobów) oraz przekazywanie wierszy audytu z naszej strony do SIEM, gdzie są one korelowane z własnymi logami.
  • Pisanie notatki o obowiązkach wdrożeniowca wskazującej na tę architekturę podczas zamówienia.

Nasza strona dostarcza architekturę i format wiersza audytu. Wszystko, co następuje dalej — w tym polityka przechowywania treści — to obszar, gdzie zespół ds. zgodności wdrożeniowca stosuje własne zasady.

Bibliografia

  1. Komisja Europejska. „AI Act — Ramy regulacyjne dotyczące AI.” https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai. Dostęp 2026-06-03.
  2. NIST. „AI Risk Management Framework (AI RMF 1.0).” https://www.nist.gov/itl/ai-risk-management-framework. Dostęp 2026-06-03.
  3. ENISA. „Cyberbezpieczeństwo sztucznej inteligencji.” https://www.enisa.europa.eu/topics/iot-and-smart-infrastructures/artificial-intelligence. Dostęp 2026-06-03.