Routing API AI sensibile alla conservazione dei dati: applica policy ZDR, residenza e registrazione al gateway

I team di sicurezza non hanno solo bisogno di sapere quale modello è più economico, più veloce o più potente. Devono sapere se una richiesta specifica può essere inviata legalmente e operativamente a un provider, endpoint, regione, funzionalità e modalità di registrazione specifici.

È più difficile di quanto sembri. Un modello può essere accettabile per la normale chat interna, ma non per le PII del cliente. Un provider può offrire una conservazione dei dati pari a zero per un percorso API, mentre una funzionalità di base della ricerca memorizza richieste e output per un periodo fisso. Una regione potrebbe supportare la residenza di archiviazione, ma non la modalità di elaborazione prevista. I registri di proprietà degli sviluppatori possono essere configurabili, mentre i registri di monitoraggio degli abusi del provider seguono una politica diversa.

La risposta pratica è spostare le decisioni sulla fidelizzazione dalle singole applicazioni al gateway API AI. Il gateway dovrebbe classificare la richiesta, valutarla rispetto a una matrice di capacità del fornitore, bloccare le funzionalità incompatibili, instradarla solo ai profili del modello approvati e registrare una decisione politica senza archiviare richieste non elaborate per impostazione predefinita.

Il problema del lettore: i termini sulla privacy del provider non sono controlli di runtime

La maggior parte dei team inizia con un foglio di calcolo o una revisione della sicurezza che indica quali fornitori di intelligenza artificiale sono approvati. Questo è utile, ma non è sufficiente per il routing della produzione.

Le applicazioni effettuano scelte di runtime:

• Quale ID modello dovrebbe gestire questa richiesta?
• La richiesta deve utilizzare la ricerca, il caricamento di file, l'esecuzione di codice, l'elaborazione batch, la memorizzazione nella cache dei prompt o le conversazioni archiviate?
• Quale regione o endpoint dovrebbe elaborare la richiesta?
• Il sistema può registrare il prompt non elaborato per il debug?
• Il routing di fallback può inviare la stessa richiesta a un altro provider?

Ognuna di queste scelte può modificare il profilo di conservazione. Una richiesta conforme in modalità chat semplice potrebbe diventare non conforme quando lo sviluppatore attiva l'archiviazione di base o persistente delle conversazioni. Una regola di fallback progettata per garantire l'affidabilità potrebbe instradare accidentalmente i dati regolamentati a un percorso del provider che non è stato approvato per la conservazione dei dati zero, la residenza dei dati o i controlli di monitoraggio degli abusi.

Raccomandazione: considera il comportamento di conservazione come un vincolo di instradamento di prima classe, non come documentazione allegata all'account di un fornitore.

Fatti da codificare prima di progettare la politica

I termini esatti variano in base al fornitore, al prodotto, al contratto, alla regione, all'endpoint e alla funzionalità. Non fare affidamento sulla memoria o su una revisione una tantum. Costruisci una matrice di proprietà della fonte e aggiornala quando i termini cambiano.

Diversi documenti attuali dei fornitori pubblici illustrano perché ciò è necessario:

• OpenAI: la residenza dei dati API è documentata come configurata dal progetto, con richieste regionali che richiedono prefissi di dominio specifici della regione. OpenAI distingue inoltre il supporto di archiviazione dal supporto di elaborazione per regione e rileva requisiti aggiuntivi per le regioni non statunitensi. OpenAI afferma che la residenza dei dati API non statunitensi richiede l'approvazione per i controlli di monitoraggio degli abusi e un emendamento sulla conservazione modificata.
• Anthropic: Anthropic documenta una conservazione dei dati pari a zero per i casi d'uso commerciali correlati alle API, sottolineando al contempo che alcuni prodotti correlati o feed di conformità hanno modelli di conservazione separati, inclusa una conservazione più lunga per il feed attività e le trascrizioni delle sessioni remote.
• Google Gemini: i termini dell'API Gemini distinguono i servizi non a pagamento da quelli a pagamento. Per i servizi non a pagamento, Google potrebbe utilizzare i contenuti inviati e le risposte generate per migliorare i prodotti; per i servizi a pagamento, Google afferma che i messaggi e le risposte non vengono utilizzati per migliorare i prodotti. La documentazione ZDR dell'API Gemini Developer afferma che i registri di monitoraggio degli abusi dei servizi a pagamento normalmente conservano richieste e risposte per un periodo limitato, mentre i progetti ZDR approvati cancellano i contenuti utente e i metadati identificabili prima della registrazione.
• Archiviazione specifica delle funzionalità: la documentazione di Gemini afferma che Grounding with Google Search e Grounding with Google Maps memorizzano istruzioni, informazioni contestuali e output generato per 30 giorni, senza alcun modo di disabilitare tale archiviazione quando vengono utilizzate tali funzionalità.
• Log di proprietà dello sviluppatore: la documentazione di registrazione dell'API Gemini afferma che i log API di proprietà dello sviluppatore possono essere conservati fino a 55 giorni per impostazione predefinita per i progetti abilitati alla fatturazione e che gli sviluppatori possono scegliere finestre più brevi come 7, 14 o 28 giorni.
• Gestione del rischio: il profilo di intelligenza artificiale generativa del NIST consiglia di monitorare i contenuti generati dall'intelligenza artificiale per i rischi per la privacy e di collegare le politiche di intelligenza artificiale generativa ai processi esistenti di dati, software, legali, conformità e gestione dei rischi.

Questi sono fatti da verificare rispetto alla documentazione attuale del fornitore prima dell'implementazione. La lezione architetturale è stabile: la conservazione non è un valore booleano a livello di provider.

Architettura: un motore di policy del gateway nel percorso della richiesta

Un gateway sensibile alla conservazione ha cinque componenti principali:

1. Classificatore di sensibilità della richiesta: etichetta il carico di lavoro prima del routing.
2. Matrice delle capacità del provider: descrive il provider, il modello, l'endpoint, la regione, la conservazione, la registrazione e il comportamento delle funzionalità.
3. Regole policy-as-code: converte i requisiti di sicurezza in decisioni di autorizzazione, rifiuto o revisione in fase di esecuzione.
4. Livello funzionalità gate: blocca le funzionalità che modificano la conservazione a meno che non siano esplicitamente consentite.
5. Livello di controllo e analisi: registra metadati utili senza archiviare suggerimenti non elaborati per impostazione predefinita.

Non è necessario che il gateway comprenda ogni sfumatura legale. È necessario applicare le decisioni approvate dai team legali, di sicurezza, di conformità e della piattaforma.

Passaggio 1: classificare la sensibilità della richiesta prima di selezionare un modello

Inizia con una piccola tassonomia di classificazione. Dovrebbe essere abbastanza semplice da poter essere utilizzato dagli sviluppatori, ma abbastanza espressivo da guidare le politiche.

Esempi di etichette di riservatezza:

• pubblico: documentazione pubblica, testo di marketing, contenuto del sito web pubblico.
• interno: informazioni aziendali non pubbliche con bassa sensibilità.
• confidenziale: strategia, contratti, contesto del cliente, dettagli del prodotto inediti.
• customer_pii: nomi, email, indirizzi, identificatori di account, trascrizioni di supporto.
• regolamentati: dati protetti sanitari, finanziari, legali, educativi o specifici della giurisdizione.
• source_code: codice proprietario, configurazione, file di architettura.
• credenziali: segreti, token, password, chiavi private. Nella maggior parte dei sistemi questo dovrebbe essere bloccato, non instradato.

La classificazione può provenire da più fonti:

• Un'intestazione fornita dall'applicazione, ad esempio X-Data-Class: customer_pii.
• Politica del tenant, in base alla quale tutto il traffico proveniente da un cliente regolamentato viene trattato come regolamentato a meno che non venga declassato da una regola approvata.
• Policy endpoint, dove il riepilogo dei ticket di supporto per impostazione predefinita è customer_pii.
• Scansione leggera dei contenuti per credenziali, informazioni personali evidenti o violazioni delle norme.

Raccomandazione: non dipendono interamente dal rilevamento automatico. Richiedi alle applicazioni di dichiarare la classe di dati prevista, quindi utilizza la scansione per individuare evidenti discrepanze o forzare una classe più sicura.

Passaggio 2: creare una matrice delle capacità del fornitore

La matrice di capacità è la fonte di verità valutata dal router. Dovrebbe essere sottoposto a versione, revisionato e testato come la configurazione di produzione.

Campi di esempio:

{
  "profile_id": "provider_x.chat.eu.zdr",
  "fornitore": "fornitore_x",
  "model": "modello-grande",
  "api_family": "chat_completions",
  "endpoint": "https://eu.example-provider.com/v1",
  "regione": "ue",
  "processing_residency": ["ue"],
  "storage_residency": ["ue"],
  "zdr_eligged": vero,
  "zdr_contract_required": vero,
  "training_use": "not_used_for_training_on_paid_api",
  "abuse_monitoring": "approved_modified_retention_required",
  "developer_log_retention_days": 0,
  "raw_prompt_logging_allowed": falso,
  "funzioni_supportate": {
    "plain_chat": vero,
    "streaming": vero,
    "tool_calls": vero,
    "search_grounding": falso,
    "maps_grounding": falso,
    "file_upload": falso,
    "lotto": falso,
    "stored_conversations": falso
  },
  "last_reviewed": "2026-08-01",
  "source_refs": ["revisione-sicurezza-123", "vendor-doc-versione-abc"]
}

Utilizza i profili del modello anziché gli ID modello non elaborati. Un profilo combina modello, provider, endpoint, regione, set di funzionalità e comportamento di conservazione. Gli sviluppatori richiedono model_profile: Compliance_summarization, non solo model: Fastest-Large-model.

Raccomandazione: includere i prerequisiti contrattuali nella matrice. Un percorso non è approvato ZDR semplicemente perché un venditore offre ZDR da qualche parte. Viene approvato solo quando il tuo account, progetto, regione ed endpoint soddisfano le condizioni richieste.

Passaggio 3: scrivere le regole policy-as-code

Le regole delle policy dovrebbero essere esplicite, testabili e leggibili dai team di sicurezza e piattaforma.

Regole di esempio in pseudocodice:

nega se data_class == "credenziali"
  motivo "credentials_must_not_be_sent_to_model"
consenti solo se data_class in ["regulated", "customer_pii"]
  e profile.zdr_eligged == true
  e profile.zdr_contract_required_satisfied == vero
  motivo_su_guasto "modello_profile_non_zdr_idoneo"
nega se residenza_required == "eu"
  e "eu" non in profile.processing_residency
  motivo "region_processing_not_supported"
nega se data_class in ["confidenziale", "customer_pii", "regolamentato"]e request.raw_prompt_logging == true
  motivo "raw_prompt_logging_not_allowed"
nega se request.features.search_grounding == true
  e policy.requires_zdr == true
  e profile.feature_storage.search_grounding_days > 0
  motivo "grounding_requires_retention_content"
nega se fallback_profile.retention_level < primario_profile.retention_level
  motivo "fallback_weakens_retention_policy"

Queste regole dovrebbero essere eseguite prima della selezione del fornitore e di nuovo prima del fallback. Il routing di fallback è una fonte comune di deviazioni accidentali delle policy: il percorso principale potrebbe essere conforme, mentre il percorso di fallback è semplicemente disponibile.

Passaggio 4: tratta gli strumenti e le funzionalità come capacità di modifica della fidelizzazione

Non considerare la conservazione del modello come una proprietà del solo modello di base. Le funzionalità spesso modificano il comportamento di archiviazione, registrazione o revisione.

Assegna a ciascuna funzionalità i propri flag di politica:

• Base della ricerca: può memorizzare prompt, contesto recuperato e output generato in base ai termini del fornitore.
• Mappe o localizzazione: possono introdurre registri o regole di conservazione specifici della posizione.
• Caricamento file: può archiviare file separatamente dalle richieste e dalle risposte.
• Esecuzione del codice: può creare file temporanei, log di esecuzione o artefatti sandbox.
• Lavori batch: potrebbero avere comportamenti diversi di conservazione, accodamento e archiviazione dei risultati rispetto alle chiamate API sincrone.
• Conversazioni archiviate: mantengono intenzionalmente i contenuti e non dovrebbero mai essere nascosti dietro un'opzione di chat generica.
• Dashboard di valutazione o revisione: possono creare flussi di lavoro di revisione umana o set di dati di più lunga durata.

Raccomandazione: attiva le funzionalità che modificano la conservazione a livello di tenant e percorso. Se uno sviluppatore abilita grounding_search=true, il gateway dovrebbe rivalutare la richiesta rispetto alle regole di archiviazione delle funzionalità prima di inviarla a monte.

Passaggio 5: preserva l'analisi senza archiviare i prompt non elaborati

Il routing sensibile alla conservazione non dovrebbe accecare il team della piattaforma. Puoi mantenere utili analisi sull'utilizzo dell'intelligenza artificiale riducendo al minimo l'archiviazione dei contenuti.

Campi di telemetria predefiniti sicuri:

• ID tenant e ID progetto
• ID chiave API interna o con hash
• ID profilo modello e ID fornitore
• richiedi data e ora e regione
• I token di input, output, memorizzati nella cache e di ragionamento vengono conteggiati quando disponibili
• latenza, codice di stato, conteggio dei tentativi e decisione di fallback
• costo stimato e liquidato
• etichetta di classificazione dei dati
• Versione della politica e motivo della decisione della politica
• flag di funzionalità richiesti e flag di funzionalità consentiti

Evita di archiviare prompt non elaborati e output del modello per impostazione predefinita per il traffico riservato. Se il debug richiede contenuti, utilizza un flusso di lavoro controllato:

• Approvazione del cliente o dell'affittuario
• finestra temporale ristretta
• limite di campionamento
• passaggio di redazione
• controllo accessi separato
• scadenza breve
• registro di controllo di chi lo ha abilitato e perché

Si tratta di un compromesso. Il blocco dei registri dei prompt non elaborati rende più difficili il debug, il supporto, il controllo della qualità e le indagini sugli abusi. Ma archiviare tutto per impostazione predefinita crea una maggiore superficie di privacy, violazione e conformità.

Passaggio 6: restituire motivi di rifiuto utilizzabili

Un 403 vietato generico frustra gli sviluppatori e incoraggia soluzioni alternative. Restituisce un motivo stabile leggibile dalla macchina e una spiegazione leggibile dall'uomo.

Esempio di risposta:

{
  "errore": {
    "tipo": "policy_denied",
    "code": "grounding_requires_30_day_storage",
    "message": "La ricerca di base non è consentita per i carichi di lavoro contrassegnati require_zdr perché questa funzionalità del provider memorizza prompt, contesto e contenuto di output.",
    "request_id": "req_123",
    "policy_version": "policy-2026-08-01",
    "azioni_permesse": [
      "disable_search_grounding",
      "scegli_profilo:zdr_plain_chat",
      "richiesta_eccezione"
    ]
  }
}

I codici di rifiuto utili includono:

• model_profile_not_zdr_idoneo
• region_processing_not_supported
• storage_residency_not_supported
• raw_prompt_logging_not_allowed
• feature_requires_content_storage
• fallback_weakens_retention_policy
• contract_prerequisite_missing
• credenziali_rilevate

Passaggio 7: aggiungi un flusso di lavoro di eccezione, non un bypass nascosto

Alcune eccezioni sono legittime: risposta agli incidenti, debug approvato dal cliente, test di migrazione o limitazione temporanea del provider. Il gateway dovrebbe supportare le eccezioni senza trasformarle in una politica ombra permanente.

Ogni eccezione dovrebbe includere:

• identità dell'approvatore
• team o inquilino richiedente
• link al ticket o alla revisione del rischio
• giustificazione aziendale
• profili e funzionalità del modello consentiti
• classi di dati coperte
• data di scadenza
• requisiti di registrazione aggiuntivi

Raccomandazione: rendere le eccezioni più ristrette rispetto alla politica ordinaria. Evita opzioni globali come disable_retention_policy=true. Preferisci override con ambito come "consenti la registrazione del prompt di debug per il tenant A, endpoint B, per 24 ore, con redazione e approvazione di sicurezza".

Lista di controllo operativa

• Crea una matrice di funzionalità del provider con versione.
• Assegna un proprietario per i termini del fornitore, i prerequisiti contrattuali e le revisioni della conservazione.
• Richiedere alle applicazioni di dichiarare la classe di dati, i requisiti di residenza e le funzionalità richieste.
• Traffico riservato e regolamentato predefinito senza registrazione di prompt non elaborati.
• Rappresenta strumenti, messa a terra, caricamento di file, batch e conversazioni archiviate come flag di funzionalità separati.
• Esegui controlli dei criteri prima del routing primario e prima del routing di fallback.
• Registra versione policy, profilo modello, classe dati, flag funzionalità e motivo del rifiuto.
• Mantieni i metadati di analisi separati dai prompt e dai contenuti di output.
• Il rappresentante del test consente e nega i casi in CI.
• Esamina la deviazione delle politiche ogni volta che un fornitore modifica termini, regioni, endpoint o funzionalità.

Compromessi da rendere espliciti

Il routing rigoroso riduce la scelta. ZDR e vincoli di residenza possono impedire l'uso del modello più recente, del percorso dal costo più basso o di un endpoint ricco di funzionalità.

Il routing regionale può aumentare la latenza o i costi. La regione conforme più vicina potrebbe non supportare la modalità di elaborazione desiderata o potrebbe richiedere un percorso del provider diverso.

Le funzionalità gate sorprendono gli sviluppatori. Uno sviluppatore potrebbe pensare di abilitare solo la ricerca, ma la sicurezza vede un nuovo comportamento di conservazione. La documentazione e i messaggi di rifiuto riducono l'attrito.

La minimizzazione tempestiva complica il debug. I team hanno bisogno di campioni redatti, finestre di debug approvate dal tenant e metadati efficaci per analizzare i problemi senza archiviare tutto.

La matrice richiede manutenzione. I termini del fornitore cambiano. Lancio di nuovi modelli. Le regioni si espandono. Le funzionalità passano dalla beta alla produzione. Una matrice obsoleta è peggiore di nessuna matrice perché crea falsa fiducia.

Cos'è una raccomandazione e cos'è una previsione?

Consigli: applica la conservazione al gateway, classifica le richieste prima dell'instradamento, crea una matrice di capacità del provider, blocca le funzionalità che modificano la conservazione in base alla policy, evita la registrazione dei prompt non elaborati per impostazione predefinita e controlla la versione di ogni decisione della policy.

Previsione: i team della piattaforma AI tratteranno sempre più la privacy come parte della selezione del modello. Invece di chiedere “quale modello dovremmo usare?” le applicazioni richiederanno un profilo del modello che soddisfi i vincoli di capacità, costo, latenza, residenza e conservazione.

Previsione: le funzionalità di privacy specifiche del fornitore continueranno a divergere. I gateway che normalizzano solo i formati di richiesta e risposta non saranno sufficienti; anche i team di produzione avranno bisogno di una normalizzazione delle politiche.

Conclusione attuabile

Il routing sensibile alla conservazione dei dati non è un dashboard di conformità separato. Appartiene al percorso della richiesta.

Inizia con tre risultati finali: una tassonomia di sensibilità delle richieste, una matrice di funzionalità del provider con versione e un piccolo insieme di regole policy-as-code per ZDR, residenza, registrazione non elaborata, fallback e funzionalità di modifica della conservazione. Quindi fai in modo che il gateway restituisca chiare ragioni di rifiuto e conservi l'analisi senza archiviare contenuti non elaborati per impostazione predefinita.

Questa progettazione centralizza le decisioni che altrimenti sarebbero disperse tra opzioni SDK, variabili di ambiente, console dei provider e convenzioni specifiche del team. Fornisce inoltre ai team addetti alla sicurezza e alla piattaforma un pratico audit trail: quale richiesta è stata consentita, quale versione della policy è stata applicata, quale profilo del modello è stato selezionato e perché.

Leggi correlati

• registrazione rapida sicura e utilizzo a livello di gateway analisi
• creazione di una matrice di capacità del fornitore durante una migrazione API compatibile con OpenAI
• strumenti per agenti di governo con ambiti, approvazioni e audit trail