Przejdź do głównej zawartości

Polityka compliance — allowlist + audyt + scrubbery PII + DPA + GDPR/HIPAA

Q21 — Org enablement. Czy masz politykę dotyczącą PII / sekretów / compliance w promptach AI?

Odpowiedź na maks. wynik: Allowlist + audyt logów + scrubbery PII + DPA z dostawcami + mapowanie GDPR/HIPAA.

Dlaczego to ma znaczenie: Regulatorzy szybko nadrabiają zaległości. Zanim będziesz tego potrzebować, na retrofit będzie już za późno — ślad audytowy zaczyna się w momencie włączenia polityki.

Jeśli inżynierowie wklejają dane klientów, sekrety lub treści regulowane do Claude’a, Cursora, Codeksa, ChatGPT, Copilota albo dowolnego agent runnera — a ty nie umiesz odpowiedzieć “tak” na każdą warstwę poniżej — ryzyko po cichu się kumuluje. Promptu bez DPA, który opuścił laptop, nie da się “cofnąć”. Wersja ciebie z przyszłości chce logów zaczynających się przed incydentem.

Każda warstwa poniżej jest do wdrożenia w dwa tygodnie z właścicielem — głównie jednorazowa konfiguracja plus runtime’owa hydraulika.

Dlaczego to ma znaczenie w 2026 (tempo regulatorów, ból retrofittingu)

Dział zatytułowany „Dlaczego to ma znaczenie w 2026 (tempo regulatorów, ból retrofittingu)”

W 2026 zbiegły się trzy siły:

  1. Regulatorzy dogonili rzeczywistość. Egzekwowanie GDPR wobec procesorów AI stało się rutynowe. Obowiązki transparentności GPAI z EU AI Act zaczęły gryźć. Stanowe ustawy prywatności w USA (Kolorado, Kalifornia, Teksas) potwierdziły, że dostawcy LLM są procesorami. HIPAA OCR potwierdziła, że PHI w promptach bez BAA to ujawnienie podlegające zgłoszeniu. Obrona “nie wiedzieliśmy” wygasła.
  2. Warunki dostawców zmieniły się pod twoimi nogami. Odświeżenie warunków komercyjnych Anthropic weszło w życie 1 stycznia 2026 z DPA dla GDPR włączonym przez referencję. Od 7 stycznia 2026 Microsoft 365 Copilot zaczął domyślnie routować do Anthropic dla większości tenantów komercyjnych — twój tenant może już uderzać w nowego procesora pod parasolowym DPA Microsoftu. DPA OpenAI pokrywa API i Enterprise, ale wyklucza ChatGPT Free/Plus.
  3. Retrofit jest trudny. Gdy regulator zapyta “pokaż każdy prompt z danymi osobowymi UE z ostatnich 12 miesięcy”, nie zrekonstruujesz tego z pamięci. Albo to zalogowałeś, albo nie. Albo masz DPA, albo nie. Planu B nie ma.

Koszt opóźnienia rośnie liniowo z miesiącami niezalogowanego użycia.

Jak naprawdę wygląda “maks. wynik” (model 5-warstwowy)

Dział zatytułowany „Jak naprawdę wygląda “maks. wynik” (model 5-warstwowy)”

Maks. wynik w Q21 to stos. Każda warstwa zawodzi w sposób otwarty (fail-open), jeśli nie ma nad nią tej wyższej.

Warstwa 1 — Allowlista modeli

Tylko modele objęte DPA dotykają danych klientów. Wszystko inne idzie przez bramkę, która odrzuca regulowane payloady.

Warstwa 2 — DPA z dostawcami

Podpisane (lub automatycznie inkorporowane) DPA z Anthropic, OpenAI, Microsoft, Cursorem, GitHubem oraz dostawcą bramki. BAA tam, gdzie w grze jest PHI.

Warstwa 3 — Scrubbery PII

Inline redakcja PII / PHI / sekretów zanim prompt opuści twój perymetr. Lokalnie, gdzie to praktyczne.

Warstwa 4 — Audyt na poziomie promptu

Każdy prompt, odpowiedź, model, użytkownik, projekt, decyzja scrubbera i znacznik czasu zalogowane. Polityka retencji dopasowana do oczekiwań regulatora.

Warstwa 5 — Mapowanie GDPR/HIPAA

Spisana, wersjonowana mapa: które modele są w zakresie którego reżimu, jaka podstawa prawna obowiązuje, jaka jest ścieżka praw podmiotu danych.

Jeśli zatrzymasz się na Warstwie 2, masz “przyzwoite papiery, zero egzekwowania”. Jeśli zatrzymasz się na Warstwie 3, masz “scrubowane, ale niepoznawalne”. Maks. wynik to cały stos działający razem.

Allowlista klas modeli (tylko modele objęte DPA dotykają danych klientów)

Dział zatytułowany „Allowlista klas modeli (tylko modele objęte DPA dotykają danych klientów)”

Allowlista to serwerowa lista krotek (dostawca, model-id, region, klasa danych), którą bramka AI akceptuje. Wszystko inne to twarde odrzucenie. Model mentalny jak egress sieciowy: domyślnie odmawiamy.

Startowa allowlista dla SaaS na Series A:

  • Tier A — dopuszczone dla danych klientów. Modele pod DPA dostawcy, w regionie, który kontrolujesz. 2026: Anthropic Claude przez API Anthropic (DPA auto-inkorporowane od 1 stycznia 2026), Claude przez Amazon Bedrock eu-central-1 pod twoim DPA AWS, OpenAI GPT przez Enterprise API z DPA + Zero Data Retention, Azure OpenAI w regionie EU pod DPA Microsoftu.
  • Tier B — tylko wewnętrzne. Akceptowalne do kodu i publicznych dokumentów — nigdy do payloadów klienckich. Mogą to być te same model ID, ale routowane ścieżką, która strippuje identyfikatory.
  • Tier C — tylko użytek osobisty. ChatGPT Free/Plus osobisty, Claude.ai osobisty, Gemini osobisty. Żadnych danych biznesowych. Egzekwowanie przez szkolenia i DLP.

Allowlista musi żyć w sposób umożliwiający przegląd — plik YAML w repo policy/, albo moduł Terraforma. “W czyjejś głowie” zawodzi. Bez diffu między dwiema datami nie ma audytu.

DPA z dostawcami (Anthropic, OpenAI, Cursor — stan na 2026)

Dział zatytułowany „DPA z dostawcami (Anthropic, OpenAI, Cursor — stan na 2026)”

Stan na 2026 dla dostawców, których deweloperzy faktycznie używają:

  • Anthropic. Warunki komercyjne odświeżone 1 stycznia 2026. DPA auto-inkorporowane przy akceptacji Commercial Terms — bez osobnego podpisu. Anthropic to procesor; ty administrator. I/O API retencjonowane 30 dni dla trust & safety, potem usuwane. Dane API nie trenują modeli. Lista sub-procesorów opublikowana; 15 dni wyprzedzenia przy zmianach. SCC włączone.
  • OpenAI. DPA samoobsługowo przez Platform → Settings → Organization. Pokrywa API i Enterprise — nie ChatGPT Free ani Plus. Zero Data Retention dostępne na żądanie dla kwalifikujących się klientów API. BAA dostępne na Enterprise.
  • Cursor / Anysphere. Privacy Mode (domyślny dla nowych organizacji) — prompty i kod nieretencjonowane poza zapytanie i nieużywane do treningu. DPA na tier Business. Subtelność: Cursor routuje do wielu upstreamowych dostawców — twoje DPA z Cursorem jest konieczne, ale niewystarczające.
  • GitHub Copilot. DPA Microsoftu przez Product Terms pokrywa Business i Enterprise. Tier Individual nie w zakresie — blokuj na SSO.
  • Microsoft 365 Copilot. Od 7 stycznia 2026 większość tenantów komercyjnych zaczęła domyślnie routować do Anthropic pod parasolowym DPA Microsoftu. Admini mogą zrobić opt-out; większość tego nie zrobi. DPA to pokrywa, ale mapowanie musi odzwierciedlać fakt, że bazowy model może się przesunąć bez twojej akcji.
  • Google Gemini. DPA Workspace pokrywa Gemini for Workspace. Konsumencki Gemini poza zakresem.

Utrzymuj vendor-dpas.md w repo compliance z kolumnami dostawca | tier | URL DPA lub hash PDF | data wejścia w życie | data przeglądu | właściciel. Przegląd kwartalny.

Scrubbery PII (Presidio, Cloudflare AI Gateway, custom)

Dział zatytułowany „Scrubbery PII (Presidio, Cloudflare AI Gateway, custom)”

Scrubowanie dzieje się na trzech możliwych warstwach; zwykle chcesz co najmniej dwie.

  • Klient / IDE. Hook pre-prompt wykrywający i redagujący, zanim klawisz opuści laptop. Dla Cursora i Claude Code wepnij jako pre-tool-use hook. Najlepsze do sekretów (klucze AWS, JWT, URL-e DB), gdzie wartość jest jednoznaczna.
  • Bramka. Inline filtrowanie. Open source: Microsoft Presidio (dojrzałe, konfigurowalne recognizers, regex + detektory ML), pii-codex, scrubadub. Komercyjne: Cloudflare AI Gateway, plugin PII sanitization w Kong AI Gateway, PII Filtering Policy w Gravitee. Bramka jest właściwym miejscem na egzekwowanie polityki — co redagować, co blokować, co przepuszczać z ostrzeżeniem.
  • Lokalny SLM (“AI firewall”). Mały lokalny model preprocesujący prompty. Przydatny w przypadkach rozmytych (notatki klienta wolnym tekstem z PHI), gdzie regex nie wystarczy. Dodaje latencję.

Konfiguracja, która zwraca się pierwszego dnia:

  • Wykrywaj i blokuj: żywe credentiale, URL-e bazy klientów, klucze prywatne, pełne numery kart, pełne PESEL/odpowiedniki.
  • Wykrywaj i redaguj: emaile, IP, imiona w kontekstach rekordów klienta, telefony, daty urodzenia.
  • Wykrywaj i oznacz (przepuść, ale zaloguj): częściowe identyfikatory, wzorce IP-podobne w logach, terminologia medyczna na modelach bez BAA.

Decyzja scrubbera sama jest zdarzeniem audytowym — wpychaj ją do Warstwy 4.

Audyt logów (każdy prompt zalogowany z proweniencją, polityka retencji)

Dział zatytułowany „Audyt logów (każdy prompt zalogowany z proweniencją, polityka retencji)”

Minimalny schemat wiersza logu promptu:

  • ID zapytania
  • Znacznik czasu (UTC, monotoniczny, podpisany, jeśli się da)
  • ID użytkownika i metoda uwierzytelnienia
  • Projekt / workspace / repo
  • Aplikacja źródłowa (Cursor, Claude Code, wewnętrzny agent, web)
  • Dostawca docelowy i ID modelu
  • Klasyfikacja danych w zapytaniu (brak / wewnętrzne / klient / PHI / płatności)
  • Werdykt scrubbera i digest zastosowanych redakcji
  • Hash promptu (albo pełny prompt, zgodnie z twoją polityką retencji)
  • Hash odpowiedzi (albo pełna odpowiedź)
  • Liczba tokenów
  • Referencja DPA (które DPA dostawcy pokryło to wywołanie)

Reguły retencji, które wytrzymają audyt:

  • Minimum 13 miesięcy dla ogólnych logów użycia AI (jeden pełny roczny cykl przeglądu plus miesiąc).
  • 6 lat dla ruchu objętego HIPAA (zgodne z wymaganiami retencji HIPAA).
  • 5 lat dla ruchu istotnego z perspektywy SOX, jeśli jesteś spółką publiczną lub na ścieżce audytowej.
  • Szyfrowane at rest; dostęp logowany; redakcja dostępna dla żądań usunięcia danych przez podmiot.

Cloudflare AI Gateway, Langfuse, Helicone i PostHog LLM observability oferują tu rozsądne defaulty. Wybierz jedno, wepnij, zanim ktokolwiek napisze feature, który na tym polega. Koszt retrofitu jest wysoki.

Mapowanie GDPR / HIPAA (jak wygląda użycie AI w każdym z nich)

Dział zatytułowany „Mapowanie GDPR / HIPAA (jak wygląda użycie AI w każdym z nich)”

Jedna strona na reżim, wersjonowana, z imiennym właścicielem.

Mapowanie GDPR powinno odpowiadać na:

  • Kto jest administratorem dla każdego przypadku użycia AI (prawie zawsze: ty)?
  • Kto jest procesorem (Anthropic, OpenAI, Microsoft, Cursor)?
  • Podstawa prawna (uzasadniony interes dla produktywności wewnętrznej; zgoda często wymagana dla agentów dotykających danych klienta)?
  • Geograficzny przepływ danych (EU → US pod SCC default; addendum UK IDTA dla podmiotów z UK)?
  • Ścieżka praw podmiotu danych: przy żądaniu usunięcia jak scrubujesz logi promptów, ścieżki audytu scrubbera i cache’y pochodne od agenta?
  • Pokrycie DPIA: które przypadki użycia wyzwoliły DPIA, gdzie żyją dokumenty?

Mapowanie HIPAA powinno odpowiadać na:

  • Które workflow dotykają PHI? Zwykle: agenty wsparcia, narzędzia EHR-adjacent, wszystko ingestujące rekordy medyczne.
  • Które modele są pod BAA? (2026 typowo: Claude przez AWS Bedrock z BAA, OpenAI Enterprise z BAA, Azure OpenAI z BAA.)
  • Zasada minimum-necessary stosowana do promptów? (Scrubbery redagują MRN, pełne imię, DOB tam, gdzie nie są wymagane.)
  • Runbook reakcji na breach: jeśli prompt z PHI trafi do modelu bez BAA, jak jest wykrywany, ograniczany, zgłaszany?

Wpnij kwartalny przegląd w cykl review bezpieczeństwa.

  1. Wyznacz właściciela. Jedna imiennie wskazana osoba — zwykle CTO, Head of Security lub DPO — która może powiedzieć “to jest finalne”. Bez właściciela każda warstwa się rozjeżdża.

  2. Zinwentaryzuj aktualne użycie AI. Tygodniowa pasywna obserwacja: zdarzenia PostHog, logi SSO, telemetria rozszerzeń przeglądarki, analytics użycia IDE. Znajdź każdy model, każde konto, każdy shadow-IT subskrypcję. Spodziewaj się niespodzianek.

  3. Zrób draft allowlisty. Zacznij rygorystycznie. Tier A = dwa albo trzy model ID, których możesz bronić na piśmie. Wszystko inne idzie do Tier B lub C. Opublikuj.

  4. Podpisz i odłóż DPA. Anthropic auto-inkorporuje; OpenAI to formularz samoobsługowy; Microsoft jest w adminie tenanta; Cursor Business to manualny krok. Przechowuj hashe PDF i daty wejścia w życie w compliance/vendor-dpas.md.

  5. Postaw bramkę AI. Cloudflare AI Gateway, Kong AI Gateway albo własne cienkie proxy. Routuj 100% ruchu Tier A i Tier B przez nią. Tier C blokowany na warstwie SSO / DLP.

  6. Wepnij scrubbery. Presidio na bramce plus hook pre-prompt w Claude Code i Cursorze dla detekcji klasy sekretów. Przetestuj na syntetycznym korpusie PII przed włączeniem egzekwowania.

  7. Włącz logowanie audytowe. Każde wywołanie bramki → wiersz logu. Wepnij w Langfuse, Helicone lub własną tabelę D1/Postgres. Zweryfikuj, że polityka retencji działa.

  8. Spisz mapy GDPR i HIPAA. Po jednej stronie. Niech DPO, dział prawny i lead inżynierii podpiszą. Wpnij kwartalny przegląd w kalendarz.

  9. Wykonaj rollout szkoleniowy. 30-minutowa sesja dla całej organizacji: oto allowlista, oto co łapią scrubbery, oto co robić, jeśli przypadkiem wkleisz sekret. Powtarzaj co pół roku.

  10. Przeprowadź próbę alarmową. Syntetyczny incydent: inżynier wkleja fałszywy rekord pacjenta do modelu bez BAA. Czy logi to pokazują? Czy scrubber to złapał? Czy bramka zablokowała? Jak szybko się o tym dowiedziałeś? Napraw to, co zawiodło.

  • Brak scrubberów. “Powiedzieliśmy ludziom, żeby nie wklejali danych klientów” to nie jest kontrola. Ludzie wklejają. Zbuduj szynę.
  • Brak logu audytowego. Bez logów per-prompt nie odpowiesz regulatorowi i nie poprowadzisz response na incydent. Pierwsze 30 dni użycia, których nie zalogujesz, przepadły na zawsze.
  • Brak DPA. Free-tier ChatGPT i konta osobiste Claude.ai nie mają DPA. Blokuj je na warstwie SSO i DLP, nie uprzejmym slackiem.
  • Zmiana dostawcy bez re-DPA. Microsoft 365 Copilot po cichu włączył modele Anthropic w styczniu 2026 pod swoim parasolowym DPA. Takie zmiany routingu dzieją się stale. Twoje mapowanie musi odzwierciedlać bazowych procesorów, nie tylko powierzchniowego dostawcę.
  • Jeden scrubber do wszystkiego. Regex łapie sekrety; ML łapie imiona; żaden sam nie łapie wszystkiego. Warstwy.
  • Logi bez polityki retencji. Przechowywanie promptów na zawsze to własna odpowiedzialność pod GDPR. Wybierz okno retencji per klasa danych i egzekwuj usunięcie.
  • Brak BAA tam, gdzie PHI jest w grze. Anthropic, OpenAI, Azure OpenAI i Bedrock — wszyscy oferują BAA na właściwym tier. Jeśli obsługujesz PHI bez BAA, każdy prompt jest podlegającym zgłoszeniu incydentem czekającym na wykrycie.
  • Traktowanie tego jako jednorazówki. Listy sub-procesorów się zmieniają, warunki dostawców się odświeżają, twój produkt dotyka nowych typów danych. Kwartalny przegląd to podłoga.

Praktyczna lista kontrolna, którą przerobisz w 30 minut:

  • Czy umiesz wyprodukować, z jednego źródła, listę ID modeli dopuszczonych do danych klientów w tym tygodniu? Tak / nie.
  • Wybierz losowy model z allowlisty. Czy umiesz wyprodukować podpisane DPA, jego datę wejścia w życie i listę sub-procesorów, do której się odnosi? Tak / nie.
  • Wybierz losowy prompt wysłany wczoraj. Czy umiesz wyprodukować użytkownika, projekt, werdykt scrubbera, zastosowane redakcje, model, region i datę wygaśnięcia retencji? Tak / nie.
  • Test syntetyczny: wklej fałszywy klucz AWS access do Cursora. Czy jest zablokowany na warstwie pre-prompt, na bramce, czy na obu? Tak / nie.
  • Test syntetyczny: wklej fałszywe imię pacjenta do modelu bez BAA przez API. Czy jest zredagowane? Zalogowane? Czy uruchomiło alert? Tak / nie.
  • Otwórz dokument mapowania GDPR. Czy był przeglądany w ciągu ostatnich 90 dni? Tak / nie.
  • Otwórz dokument mapowania HIPAA (albo “nie dotyczy” ze spisanym uzasadnieniem). Czy był przeglądany w ciągu ostatnich 90 dni? Tak / nie.
  • Zapytaj losowego inżyniera, gdzie żyje allowlista. Czy wie? Tak / nie.

Osiem odpowiedzi “tak” to maks. wynik. Cokolwiek mniej — masz znaną lukę, spisz ją i zamknij.