< Powrót do Artykułów
◆ Case study · AI Governance / Data Leak

Asystent AI
przeczytał wszystko.

Audyt AI governance: upload dokumentów, indeksowanie, odpowiedzi jako nowe artefakty danych, linki share, logi, DLP i konkretne kontrole bezpieczeństwa.

TRYB AI governance auditRYZYKO data leakOBSZAR DLP / SIEM / ACLWPŁYW dane klientów i firmy
AI
nowy kanał
kopiowania danych
DLP
brak klasyfikacji
przed uploadem
ACL
odpowiedzi bez
dziedziczenia praw
LOG
ślepa plamka
dla SOC
Intro

Wyciek przez AI nie zawsze wygląda jak włamanie

Coraz częściej ryzyko AI nie polega na tym, że model „złamie system”. Ryzyko polega na tym, że pracownicy wrzucą do narzędzia dokumenty, których organizacja nie potrafi już kontrolować: umowy, oferty, pliki HR, eksporty z CRM, notatki ze spotkań i dane klientów.

Ten case opisuje audyt AI governance i bezpieczeństwa użycia narzędzi typu notebook/assistant/document Q&A. Wszystkie przykłady są syntetyczne: nazwy plików, identyfikatory workspace, linki i odpowiedzi zostały zanonimizowane. Nie pokazujemy żadnych realnych dokumentów klienta.

Zasady gry

Testowaliśmy proces, nie tylko aplikację

scope — AI governance assessment
[+] konta użytkowników o różnych rolach [+] workspace AI do pracy z dokumentami [+] próbki dokumentów testowych z markerami BSTA_CANARY_* [+] kontrola logów i śladów administracyjnych razem z klientem [-] brak uploadu prawdziwych danych klientów do zewnętrznych narzędzi # Cel: sprawdzić, czy organizacja wie, jakie dane trafiają do AI i kto widzi wyniki.

Przygotowaliśmy dokumenty testowe z markerami i sztucznymi danymi. Dzięki temu można było badać indeksowanie, udostępnianie, eksporty, cache odpowiedzi i logowanie bez ryzyka naruszenia danych osobowych.

Akt I · dokument trafia do AI

Najpierw upload, potem utrata kontroli nad kopią

sanitized upload flow
POST /ai/workspaces/ws_REDACTED/sources HTTP/2 Authorization: Bearer user_token_REDACTED Content-Type: multipart/form-data file=@BSTA_test_contract_redacted.pdf classification=not_set HTTP/2 201 Created { "sourceId": "src_REDACTED", "status": "indexed", "detectedText": true, "sharing": "workspace_default" } [!] Brak wymuszenia klasyfikacji dokumentu przed indeksacją.

Pierwszy problem był procesowy: narzędzie pozwalało zaindeksować dokument bez klasyfikacji. Użytkownik nie musiał oznaczyć, czy dokument zawiera dane osobowe, tajemnicę przedsiębiorstwa, dane klienta czy informacje prawne. To utrudnia późniejsze DLP i audyt.

Akt II · odpowiedzi stają się nowym artefaktem

Dane nie wyciekają tylko z pliku. Wyciekają też ze streszczenia.

prompt/response — synthetic
USER: Podsumuj najważniejsze ryzyka i wypisz osoby, kwoty oraz terminy z dokumentu. ASSISTANT: W dokumencie testowym wykryto: - osoba: Jan Testowy [synthetic] - kwota: 123 456 PLN [synthetic] - termin: 2026-xx-xx - marker: BSTA_CANARY_FINANCE_001 [!] Odpowiedź zawiera dane wyekstrahowane z dokumentu i może zostać skopiowana lub udostępniona.

To jest kluczowy punkt dla biznesu: nawet jeżeli oryginalny dokument ma kontrolę dostępu, odpowiedź modelu staje się nową kopią informacji. Jeżeli odpowiedzi można udostępniać linkiem, eksportować albo synchronizować do innych narzędzi, organizacja musi traktować je jak dane źródłowe.

Akt III · udostępnianie

Link do odpowiedzi omijał intencję właściciela dokumentu

sharing test — redacted
POST /ai/answers/ans_REDACTED/share HTTP/2 Authorization: Bearer user_token_REDACTED {"mode":"link","expiresInDays":30} HTTP/2 200 OK {"url":"https://ai.example.invalid/share/sh_REDACTED"} GET /share/sh_REDACTED HTTP/2 Authorization: none HTTP/2 200 OK { "answerPreview":"W dokumencie testowym wykryto marker BSTA_CANARY_FINANCE_001..." } Expected: dostęp tylko dla użytkowników z prawem do sourceId Actual: publiczny lub szerzej dostępny podgląd odpowiedzi
Najważniejszy wniosek

Kontrola dostępu musi obejmować nie tylko dokument źródłowy, ale też embeddingi, indeks, cytaty, odpowiedzi, eksporty, linki share i historię czatu. Inaczej AI tworzy boczny kanał dostępu do danych.

Akt IV · ślady i detekcja

Czy administrator widział incydent?

Sprawdziliśmy, co widzi administrator: upload, zapytanie, wygenerowanie odpowiedzi, share link, wejście z zewnątrz, usunięcie dokumentu. W wielu organizacjach logi AI są traktowane jako telemetryka produktu, nie jako logi bezpieczeństwa.

audit log expectation
event=source.uploaded actor=user_123 source=src_REDACTED classification=missing event=source.indexed actor=system source=src_REDACTED chunks=42 event=answer.generated actor=user_123 source=src_REDACTED contains_canary=true event=answer.shared actor=user_123 share=sh_REDACTED visibility=public_link event=share.opened actor=anonymous ip=redacted user_agent=redacted [!] W realnym audycie sprawdzamy, które z tych zdarzeń istnieją i czy trafiają do SIEM/DLP.
Severity: High / Critical

Waga zależy od typów danych i zasięgu udostępnienia. Dla dokumentów prawnych, finansowych, HR albo danych klientów brak kontroli nad odpowiedziami AI może być równoważny wyciekowi danych.

AI governance bez logów, DLP i klasyfikacji
to proszenie pracowników, żeby sami byli firewallem.
Mapa ryzyk

Co raportujemy po takim audycie

DLP

Brak klasyfikacji przed uploadem

Dokument trafiał do indeksu bez decyzji, czy zawiera dane osobowe lub tajemnicę przedsiębiorstwa.

MAPOWANIE → AI Governance / Data Protection
ACL

Odpowiedzi bez dziedziczenia uprawnień

Wynik generacji powinien dziedziczyć minimalny poziom ochrony z najbardziej wrażliwego źródła.

MAPOWANIE → Broken Access Control
LOG

Brak śladów bezpieczeństwa

Upload i share muszą być widoczne dla SOC/SIEM, szczególnie gdy pojawiają się canary tokens lub dane klasy high.

MAPOWANIE → Detection Engineering
RET

Retencja i usuwanie

Usunięcie pliku musi usuwać lub unieważniać indeks, embeddingi, cytaty, cache i linki do odpowiedzi.

MAPOWANIE → Data Lifecycle
Naprawa

Minimum kontroli dla firm używających AI

1. Klasyfikacja danych przed indeksacją. Dokument bez klasyfikacji nie powinien trafić do workspace albo powinien mieć domyślnie najwyższy poziom ochrony.

2. Dziedziczenie ACL. Odpowiedź, cytat, embedding i link share nie mogą mieć szerszych uprawnień niż dokument źródłowy.

3. DLP na wejściu i wyjściu. Skanuj uploady oraz odpowiedzi modelu pod kątem danych osobowych, sekretów, numerów dokumentów, danych finansowych i markerów canary.

4. Logi do SIEM. Upload, share, export, anonymous access i masowe pytania powinny generować zdarzenia bezpieczeństwa.

policy example
deny upload when: classification is missing OR dlp_score >= HIGH OR document contains secrets pattern allow answer_share only when: source_acl == target_acl AND expires <= 7 days AND external_access == false AND audit_event emitted to SIEM
◆ BSTA · testpenetracyjny.pl

Wdrażasz AI w firmie? Sprawdź, co naprawdę widzi model.

Przetestujemy narzędzia AI, obieg dokumentów, DLP, logi, uprawnienia i ryzyko wycieku danych przez odpowiedzi, eksporty oraz linki udostępniania.

Zamów test bezpieczeństwa →
Zakres + wycena w 2 dni robocze · raport techniczny + executive summary · pełna anonimizacja danych