Routing API AI uwzględniający przechowywanie danych: wymuszanie zasad ZDR, miejsca zamieszkania i rejestrowania na bramce

Zespoły ds. bezpieczeństwa muszą nie tylko wiedzieć, który model jest najtańszy, najszybszy i najbardziej wydajny. Muszą wiedzieć, czy określone żądanie można zgodnie z prawem i operacyjnie wysłać do określonego dostawcy, punktu końcowego, regionu, funkcji i trybu rejestrowania.

To trudniejsze, niż się wydaje. Model może być akceptowalny w przypadku zwykłego czatu wewnętrznego, ale nie w przypadku informacji umożliwiających identyfikację klienta. Dostawca może zaoferować zerowe przechowywanie danych dla jednej ścieżki API, natomiast funkcja oparta na wyszukiwaniu przechowuje monity i dane wyjściowe przez ustalony okres. Region może obsługiwać miejsce przechowywania, ale nie oczekiwany tryb przetwarzania. Dzienniki należące do programisty można konfigurować, natomiast dzienniki monitorowania nadużyć dostawcy podlegają innym zasadom.

Praktycznym rozwiązaniem jest przeniesienie decyzji o przechowywaniu z poszczególnych aplikacji do bramy AI API. Brama powinna klasyfikować żądanie, oceniać je w oparciu o macierz możliwości dostawcy, blokować niezgodne funkcje, kierować tylko do zatwierdzonych profili modeli i rejestrować decyzję polityczną bez domyślnego przechowywania nieprzetworzonych monitów.

Problem czytelnika: warunki prywatności dostawcy nie stanowią kontroli w czasie wykonywania

Większość zespołów zaczyna od arkusza kalkulacyjnego lub przeglądu bezpieczeństwa, który określa, którzy dostawcy sztucznej inteligencji są zatwierdzeni. Jest to przydatne, ale nie wystarczy do routingu produkcji.

Aplikacje wybierają czas działania:

• Który identyfikator modelu powinien obsłużyć to żądanie?
• Czy żądanie powinno wykorzystywać podstawy wyszukiwania, przesyłanie plików, wykonywanie kodu, przetwarzanie wsadowe, buforowanie podpowiedzi czy przechowywane konwersacje?
• Który region lub punkt końcowy powinien przetworzyć żądanie?
• Czy system może zarejestrować nieprzetworzony monit o debugowanie?
• Czy routing rezerwowy może wysłać to samo żądanie do innego dostawcy?

Każda z tych opcji może zmienić profil przechowywania. Żądanie, które było zgodne w zwykłym trybie czatu, może stać się niezgodne, gdy programista włączy uziemienie lub trwałe przechowywanie konwersacji. Reguła awaryjna zaprojektowana z myślą o niezawodności może przypadkowo skierować regulowane dane do ścieżki dostawcy, która nie została zatwierdzona pod kątem zerowego przechowywania danych, przechowywania danych ani kontroli monitorowania nadużyć.

Zalecenie: traktuj zachowanie związane z przechowywaniem jako pierwszorzędne ograniczenie routingu, a nie jako dokumentację dołączoną do konta dostawcy.

Fakty do zakodowania przed zaprojektowaniem polityki

Dokładne warunki różnią się w zależności od dostawcy, produktu, umowy, regionu, punktu końcowego i funkcji. Nie polegaj na pamięci ani jednorazowym przeglądzie. Zbuduj macierz należącą do źródła i aktualizuj ją, gdy zmienią się warunki.

Kilka aktualnych dokumentów dostawców publicznych ilustruje, dlaczego jest to konieczne:

• OpenAI: miejsce przechowywania danych API jest udokumentowane jako skonfigurowane w projekcie, a żądania regionalne wymagają prefiksów domen specyficznych dla regionu. OpenAI odróżnia także obsługę pamięci masowej od obsługi przetwarzania według regionu i zwraca uwagę na dodatkowe wymagania dla regionów spoza USA. OpenAI stwierdza, że przechowywanie danych API poza USA wymaga zgody na kontrolę monitorowania nadużyć oraz poprawki dotyczącej zmodyfikowanego przechowywania.
• Anthropic: Anthropic dokumentuje zerowe przechowywanie danych w przypadku zastosowań komercyjnych związanych z interfejsem API, zauważając jednocześnie, że niektóre powiązane produkty lub pliki danych dotyczące zgodności mają osobne modele przechowywania, w tym dłuższe przechowywanie źródła aktywności i transkrypcji sesji zdalnych.
• Google Gemini: terminy API Gemini rozróżniają usługi bezpłatne i płatne. W przypadku usług bezpłatnych Google może wykorzystywać przesłane treści i wygenerowane odpowiedzi w celu ulepszenia produktów; w przypadku usług płatnych Google twierdzi, że monity i odpowiedzi nie służą do ulepszania produktów. Dokumentacja Gemini Developer API ZDR mówi, że dzienniki monitorowania nadużyć w usługach płatnych zwykle przechowują monity i odpowiedzi przez ograniczony czas, podczas gdy zatwierdzone projekty ZDR usuwają zawartość użytkownika i możliwe do zidentyfikowania metadane przed zalogowaniem.
• Przechowywanie specyficzne dla funkcji: dokumentacja Gemini stwierdza, że Grounding with Google Search i Grounding with Google Maps przechowują monity, informacje kontekstowe i wygenerowane dane wyjściowe przez 30 dni, bez możliwości wyłączenia tego magazynu, gdy używane są te funkcje.
• Dzienniki należące do programistów: Dokumentacja rejestrowania interfejsu API Gemini mówi, że dzienniki interfejsu API należące do programisty mogą być domyślnie przechowywane do 55 dni w przypadku projektów z włączoną funkcją rozliczeń oraz że programiści mogą wybierać krótsze okna, np. 7, 14 lub 28 dni.
• Zarządzanie ryzykiem: Profil Generative AI firmy NIST zaleca monitorowanie treści generowanych przez AI pod kątem zagrożeń prywatności i łączenie zasad generatywnej AI z istniejącymi danymi, oprogramowaniem, procesami prawnymi, zgodnością i zarządzaniem ryzykiem.

To są fakty, które należy sprawdzić w aktualnej dokumentacji dostawcy przed wdrożeniem. Lekcja architektury jest stabilna: przechowywanie nie jest jedną wartością logiczną na poziomie dostawcy.

Architektura: silnik zasad bramy w ścieżce żądań

Brama uwzględniająca przechowywanie składa się z pięciu podstawowych elementów:

1. Klasyfikator czułości żądań: oznacza obciążenie przed routingiem.
2. Macierz możliwości dostawcy: opisuje dostawcę, model, punkt końcowy, region, przechowywanie, rejestrowanie i zachowanie funkcji.
3. Reguły polityki jako kodu: przekształcają wymagania bezpieczeństwa w decyzje dotyczące zezwolenia, odmowy lub przeglądu w czasie wykonywania.
4. Warstwa bramki funkcji: blokuje funkcje zmieniające przechowywanie, chyba że wyraźnie na to zezwolono.
5. Warstwa audytu i analityki: rejestruje przydatne metadane bez domyślnego przechowywania surowych podpowiedzi.

Brama nie musi rozumieć wszystkich niuansów prawnych. Musi egzekwować decyzje zatwierdzone przez zespoły prawne, bezpieczeństwa, zgodności i platformy.

Krok 1: sklasyfikowaj wrażliwość żądań przed wyborem modelu

Zacznij od małej taksonomii klasyfikacji. Powinien być wystarczająco prosty w użyciu dla programistów, ale wystarczająco wyrazisty, aby kierować polityką.

Przykładowe etykiety czułości:

• publiczny: dokumentacja publiczna, tekst marketingowy, publiczna zawartość witryny internetowej.
• wewnętrzne: niepubliczne informacje o firmie o niskiej wrażliwości.
• poufne: strategia, umowy, kontekst klienta, niepublikowane szczegóły produktu.
• customer_pii: nazwiska, adresy e-mail, adresy, identyfikatory kont, transkrypcje wsparcia.
• regulowane: dane chronione dotyczące opieki zdrowotnej, finansów, prawa, edukacji lub jurysdykcji.
• kod_źródłowy: zastrzeżony kod, konfiguracja, pliki architektury.
• poświadczenia: sekrety, tokeny, hasła, klucze prywatne. W większości systemów powinno to być blokowane, a nie kierowane.

Klasyfikacja może pochodzić z wielu źródeł:

• Nagłówek dostarczany przez aplikację, taki jak X-Data-Class:customer_pii.
• Zasady dzierżawy, zgodnie z którymi cały ruch od regulowanego klienta jest traktowany jako regulowany, chyba że zostanie obniżony przez zatwierdzoną regułę.
• Zasady dotyczące punktów końcowych, gdzie domyślne podsumowanie biletów pomocy technicznej to customer_pii.
• Niewielkie skanowanie treści pod kątem danych uwierzytelniających, oczywistych informacji umożliwiających identyfikację lub naruszeń zasad.

Zalecenie: nie polegaj wyłącznie na automatycznym wykrywaniu. Wymagaj od aplikacji zadeklarowania zamierzonej klasy danych, a następnie użyj skanowania, aby wychwycić oczywiste rozbieżności lub wymusić bezpieczniejszą klasę.

Krok 2: zbuduj matrycę możliwości dostawcy

Macierz możliwości jest źródłem prawdy ocenianym przez router. Należy go wersjonować, przeglądać i testować podobnie jak konfigurację produkcyjną.

Przykładowe pola:

{
  "profile_id": "provider_x.chat.eu.zdr",
  "dostawca": "dostawca_x",
  "model": "model-duży",
  "api_family": "zakończenia_czatu",
  "endpoint": "https://eu.example-provider.com/v1",
  "region": "eu",
  „processing_residency”: [„eu”],
  „storage_residency”: [„eu”],
  „zdr_eligible”: prawda,
  „zdr_contract_required”: prawda,
  "training_use": "not_used_for_training_on_paid_api",
  "abuse_monitoring": "approved_modified_retention_required",
  "developer_log_retention_days": 0,
  „raw_prompt_logging_allowed”: fałsz,
  „obsługiwane_funkcje”: {
    „plain_chat”: prawda,
    „streaming”: prawda,
    „tool_calls”: prawda,
    „search_grounding”: fałsz,
    „maps_grounding”: fałsz,
    „file_upload”: fałsz,
    „partia”: fałsz,
    „stored_conversations”: fałsz
  },
  "last_reviewed": "2026-08-01",
  „source_refs”: [„przegląd-bezpieczeństwa-123”, „wersja-dokumentu-dostawcy-abc”]

Używaj profili modeli, a nie surowych identyfikatorów modeli. Profil łączy model, dostawcę, punkt końcowy, region, zestaw funkcji i stan przechowywania. Programiści żądają model_profile: zgodne_summarizacja, a nie tylko model: najszybszy-duży-model.

Zalecenie: uwzględnij w matrycy warunki wstępne umowy. Trasa nie jest zatwierdzona przez ZDR tylko dlatego, że sprzedawca oferuje gdzieś ZDR. Jest zatwierdzany tylko wtedy, gdy Twoje konto, projekt, region i punkt końcowy spełniają wymagane warunki.

Krok 3: napisz reguły w formie kodu

Zasady zasad powinny być jasne, możliwe do przetestowania i czytelne dla zespołów ds. bezpieczeństwa i platformy.

Przykładowe reguły w pseudokodzie:

odmów, jeśli data_class == "poświadczenia"
  powód „poświadczenia_must_not_be_sent_to_model”
zezwól tylko wtedy, gdy klasa_danych w ["regulated", "customer_pii"]
  i profile.zdr_eligible == true
  i profile.zdr_contract_required_satisfied == true
  powód_on_failure "model_profile_not_zdr_eligible"
odmów, jeśli rezydencja_wymagana == „eu”
  i „eu” nie jest w profile.processing_residency
  powód „region_processing_not_supported”
odmów, jeśli klasa_danych w ["poufne", "klient_pii", "regulowane"]i request.raw_prompt_logging == true
  powód „raw_prompt_logging_not_allowed”
odmów, jeśli request.features.search_grounding == true
  i policy.requires_zdr == true
  i profile.feature_storage.search_grounding_days > 0
  powód „grounding_requires_retained_content”
odmów, jeśli profil_powrotny.poziom_retencji 

{
  „błąd”: {
    "type": "policy_denied",
    "code": "grounding_requires_30_day_storage",
    "message": "Podstawa wyszukiwania nie jest dozwolona w przypadku obciążeń oznaczonych require_zdr, ponieważ ta funkcja dostawcy przechowuje monity, kontekst i treść wyjściową.",
    "request_id": "req_123",
    "policy_version": "polityka-przechowywania-2026-08-01",
    „dozwolone_akcje”: [
      "wyłącz_uziemienie_wyszukiwania",
      "wybierz_profil:zdr_plain_chat",
      „wyjątek_żądania”
    ]
  }