Polityka danych i compliance AI — zweryfikuj konkretną usługę

Polityka danych AI musi zatwierdzać konkretny produkt, plan, trasę wdrożenia, region, konfigurację i use case — nie logo dostawcy. Usługi konsumenckie i komercyjne mogą mieć inne warunki; opcjonalne funkcje mogą dodawać podprocesorów lub retencję; lokalne agenty mogą wysyłać dane repo przez narzędzia. Zbuduj weryfikowalny rejestr przepływów, minimalizuj input, ogranicz dostęp i zleć review właściwego prawa prawnikowi.

Q21 · Enablement organizacji Dowód na maksymalny wynik: rejestr usług z review, klasyfikacja danych, mapowanie celu i podstawy prawnej, least privilege, minimalizacja, retencja, audyt, obsługa incydentu i cykliczna re-akceptacja.

Ten artykuł opisuje wzorzec kontroli inżynierskich, a nie poradę prawną. Wymagania zależą od jurysdykcji, roli, danych, sektora, umów i wdrożenia. Przegląd AI Act Komisji Europejskiej pokazuje, że obowiązki wchodzą w różnych terminach i zależą od kategorii ryzyka oraz zastosowania. Sprawdź aktualny tekst źródłowy i uzyskaj review prawne dla swojej sytuacji.

Zarejestruj każdą zatwierdzoną usługę

Dla każdej konfiguracji Claude Code, Cursora, Codexa, API, serwera MCP, gatewaya modeli lub cloud agenta zapisz:

• podmiot prawny, produkt i plan;
• role controller/processor i podpisane warunki lub DPA;
• klasy danych, cel, podstawę prawną i dane zabronione;
• regiony, podprocesorów, providerów modeli, integracje opcjonalne i trasy danych;
• użycie do treningu, retencję, usuwanie, eksport i zachowanie audytu;
• tożsamość, dostęp, offboarding i kontakty incydentowe;
• ownera, datę approval, linki do dowodów, następne review i triggery zmiany.

Deklaracje vendora są wejściem do review. Na przykład obecne warunki komercyjne Anthropic inkorporują DPA i stwierdzają, że Customer Content z objętych usług nie służy do treningu modeli; OpenAI publikuje osobne zobowiązania dla danych biznesowych; Cursor opisuje wpływ Privacy Mode na trening. Potwierdź konkretną zakontraktowaną usługę i bieżącą konfigurację zamiast rozszerzać te stwierdzenia na konta konsumenckie lub wszystkie integracje.

Zastosuj workflow kontroli danych

1. Klasyfikuj przed użyciem. Zdefiniuj kategorie public, internal, confidential, personal, regulated, secret i prohibited z przykładami z pracy inżynierskiej.
2. Zmapuj pełną trasę. Uwzględnij klienta, vendora, wybranego providera modelu, MCP, narzędzia browser, logi, telemetrię, storage i ludzkich odbiorców.
3. Minimalizuj i izoluj. Wysyłaj tylko potrzebne pliki i pola, redaguj test data, blokuj sekrety, ogranicz retencję i oddziel tożsamości production od development.
4. Autoryzuj use case. Dopasuj dane i cel do zatwierdzonego rekordu usługi. Nieznana usługa, trasa, region lub warunek oznacza stop i review.
5. Weryfikuj i audytuj. Testuj kontrole fixtures, próbkuj logi pod kątem kompletności i minimalizacji, ćwicz usuwanie oraz incydenty i ponawiaj review po zmianie vendora lub feature.

Prompty do utrzymania polityki

Zmapuj przepływ danych tego workflow AI od repo i inputu użytkownika przez providerów modeli, MCP, logi, artefakty i reviewerów. Oznacz nieznane trasy i nie zakładaj warunków vendora.

Porównaj proponowane użycie z rejestrem zatwierdzonych usług. Wskaż klasy danych, cel, region, procesorów, retencję, dostęp i wymagania usuwania bez aktualnego dowodu. Zwróć „wymagane review prawne” tam, gdzie potrzebna jest interpretacja.

Wygeneruj niewrażliwe fixtures do testu blokowania sekretów, wykrywania prohibited data, least-privilege access, minimalizacji logów, usuwania, offboardingu i korelacji incydentu. Nie używaj realnych danych klientów.

Dowody akceptacyjne

• Polityka jest egzekwowana na granicy tożsamości, endpointu, permission i danych — nie tylko przez zapis w handbooku.
• Logi wspierają dochodzenie przy minimalnej retencji promptów i source code.
• Wyjątki mają cel, ownera, scope, expiry i approval.
• Zmiana vendora, planu, routingu, podprocesora, warunku, retencji lub feature uruchamia ponowne review.
• Incident response obejmuje ekspozycję przez prompty, tool calls, generowane artefakty, logi i akcje zewnętrzne.

Wzorzec awarii: approval marki

„Mamy DPA z vendorem” nie wystarcza, jeśli inżynierowie używają innego planu, routują przez kolejnego providera, włączają integrację bez review albo wysyłają dane do MCP poza zatwierdzonym flow. Zweryfikuj rzeczywistą trasę runtime i konfigurację konta, a potem powiąż z tym rekordem dostęp.

Dalej: kontrole narzędzi

Zastosuj Bezpieczeństwo MCP do tool calls i Zarządzanie ryzykiem dostawcy do zmian usług oraz odtwarzania.

Q8 · Bezpieczeństwo MCP Kontroluj tożsamość, dane i side effects każdego toola.

Q25 · Ryzyko vendora Testuj fallback, eksport i reakcję na zmianę umowy.