Come creare un router di policy di conservazione dei dati per API LLM multi-provider

Un router LLM multi-provider non deve scegliere prima un modello e poi porre domande sulla conservazione. Se un flusso di lavoro di supporto è contrassegnato come senza conservazione, il gateway deve sapere se il provider, l'endpoint, la regione, l'impostazione dell'account e la combinazione di funzionalità selezionati possono onorare tale promessa prima che la richiesta lasci i tuoi confini.

È facile non notare la modalità di errore. Un team inizia con il completamento della chat senza stato. Il percorso è accettabile. Successivamente, qualcuno aggiunge il caricamento di file, la cronologia delle conversazioni memorizzata, il web grounding, l'elaborazione batch o un archivio di vettori. Il nome del modello potrebbe rimanere lo stesso, ma il comportamento dei dati cambia. Un semplice router a latenza o costo può inviare silenziosamente richieste regolamentate o vincolate dal contratto del cliente a un percorso che archivia i contenuti più a lungo di quanto consentito dal carico di lavoro.

La soluzione pratica è mettere i controlli di conservazione dei dati LLM davanti al routing del modello. Il router dovrebbe classificare la richiesta, confrontarla con una policy di conservazione canonica, filtrare le funzionalità del provider, bloccare le funzionalità non consentite ed emettere prove verificabili per la decisione.

Fatti da considerare come vincoli di progettazione

La gestione dei dati del fornitore non è uniforme e raramente viene acquisita solo in base al nome del fornitore. I seguenti fatti sono importanti quando si progetta un router con riconoscimento della fidelizzazione:

• OpenAI afferma che i API dati non vengono utilizzati per addestrare o migliorare i modelli a meno che il cliente non dia il proprio consenso. I clienti idonei possono configurare il monitoraggio degli abusi modificati o la conservazione zero dei dati a livello di organizzazione o di progetto dopo l'approvazione.
La conservazione dei dati zero di
• OpenAI modifica il comportamento dell'endpoint, incluso il trattamento del parametro store per le risposte e i completamenti della chat come falso, ma alcuni endpoint e funzionalità possono comunque archiviare lo stato dell'applicazione e non sono idonei alla conservazione dei dati zero.
• Anthropic documenta Zero Data Retention per Claude API in quanto non memorizza i prompt o le risposte dei clienti inattivi dopo la restituzione della risposta API, ma la copertura dipende dall'endpoint e dall'idoneità delle funzionalità.
• Anthropic afferma che alcune Claude funzionalità o modelli coperti potrebbero richiedere la conservazione e potrebbero non essere disponibili con Conservazione zero dei dati se non specificatamente autorizzati.
• Google Cloud documenta che Gemini i dati di Enterprise Agent Platform non vengono utilizzati per addestrare o perfezionare modelli AI/ML senza previa autorizzazione o istruzioni, ma la conservazione zero dei dati richiede azioni specifiche e potrebbe non essere possibile per alcune funzionalità avanzate.
• Google Cloud documenta che Grounding with Google Search archivia query derivate e log di contesto per un massimo di tre giorni e non può disabilitare tale spazio di archiviazione per tale funzionalità. Consiglia Web Grounding for Enterprise quando è richiesta la conservazione dei dati pari a zero.
• I documenti Microsoft che indicano che i modelli ospitati in Azure venduti da Azure non rendono disponibili richieste e completamenti a OpenAI o ad altri provider di modelli e non li utilizzano per addestrare modelli di base senza autorizzazione o istruzioni.
• Microsoft documenta che il tipo di distribuzione di Azure influisce sulla posizione di elaborazione. Le distribuzioni globali possono elaborare richieste e risposte in qualsiasi area geografica in cui viene distribuito il modello, mentre le distribuzioni DataZone limitano l'elaborazione alla zona selezionata. I dati archiviati rimangono nell'area geografica designata dal cliente.
• Microsoft documenta che alcune funzionalità di Azure con stato archiviano dati, inclusi file, archivi di vettori, cronologia dei messaggi di risposta, thread degli assistenti, input di elaborazione batch e completamenti archiviati.
• Documenti Microsoft in cui i clienti approvati possono modificare il monitoraggio degli abusi e che il portale di Azure o CLI possono mostrare ContentLogging=false quando l'archiviazione dei dati di monitoraggio degli abusi è disattivata.

Questi non sono dettagli sui bordi. Significano che il router deve valutare insieme endpoint, funzionalità, approvazione dell'account e regione. Un'etichetta a livello di fornitore come "ZDR abilitato" è troppo grossolana per i criteri di produzione.

Architettura di riferimento

Un gateway AI multi-modello API sensibile alla fidelizzazione necessita di cinque componenti nel percorso della richiesta:

1. Classificatore di richieste: estrae la riservatezza dei dati, il contratto del tenant, i requisiti della regione, l'utilizzo delle funzionalità, gli input dei file, l'utilizzo degli strumenti e le autorizzazioni di registrazione.
2. Risolutore di policy: mappa la richiesta a una policy di conservazione canonica, in genere da tenant, progetto, ambiente, chiave API e metadati del carico di lavoro.
3. Registro delle capacità del provider: registra le capacità di provider, endpoint, modello, funzionalità, regione e conservazione a livello di account con prove datate.
4. Valutatore policy: filtra i percorsi candidati e restituisce un percorso approvato o un rifiuto della policy con un codice motivo.
5. Emettitore di controllo: registra il percorso scelto, la policy corrispondente, i presupposti di capacità, la regione, i flag di archiviazione e la modalità di registrazione dei contenuti.

Questa architettura mantiene le decisioni relative alla conservazione e alla residenza separate da costi, latenza e fallback. L'indirizzamento dei costi può ancora avvenire, ma solo all'interno dell'insieme di percorsi che soddisfano i criteri di conservazione.

Definisci una policy di conservazione canonica

Inizia con un oggetto policy indipendente dal provider. Non copiare la terminologia di un fornitore nel tuo contratto interno. La tua policy interna dovrebbe descrivere cosa può fare il carico di lavoro, non come un fornitore specifico commercializza un controllo.

{
  "policy_id": "support_no_retention_eu_v1",
  "max_content_retention": "none_after_response",
  "training_allowed": false,
  "human_review_allowed": false,
  "allowed_regions": ["EU"],
  "stateful_storage_allowed": false,
  "file_storage_allowed": false,
  "grounding_allowed": false,
  "batch_processing_allowed": false,
  "full_content_logging_allowed": false,
  "redacted_content_logging_allowed": true,
  "audit_level": "route_decision_with_provider_evidence"
}

Per carichi di lavoro meno limitati, utilizza il rilassamento esplicito anziché i campi mancanti:

{
  "policy_id": "internal_analytics_standard_v1",
  "max_content_retention": "30_days",
  "training_allowed": false,
  "human_review_allowed": false,
  "allowed_regions": ["US", "EU"],
  "stateful_storage_allowed": true,
  "file_storage_allowed": true,
  "grounding_allowed": true,
  "batch_processing_allowed": true,
  "full_content_logging_allowed": false,
  "redacted_content_logging_allowed": true,
  "audit_level": "metadata_and_decision"
}

I campi importanti non sono solo la durata della conservazione. Funzionalità con stato, file, grounding, elaborazione batch e modalità di registrazione influiscono tutti sull'accettabilità di un percorso.

Crea il registro delle capacità del provider

Il registro delle capacità è la fonte attendibile del router. Dovrebbe essere mantenuta come configurazione controllata, non dispersa tra gli adattatori del provider.

Un record utile include:

• provider: fornitore o piattaforma cloud.
• account_scope: organizzazione, progetto, distribuzione, abbonamento o tenant in cui un'impostazione è approvata.
• endpoint: chat, risposte, messaggi, batch, file, assistenti, incorporamenti, messa a terra, archivio di vettori o altra API superficie.
• model_family e model_id facoltativo: perché l'idoneità del modello può differire.
• region_mode: globale, regionale, zona dati, area geografica designata dal cliente o equivalente specifico del fornitore.
• content_retention: nessuna archiviazione dopo la risposta, conservazione per il monitoraggio degli abusi, conservazione dello stato dell'applicazione, log derivati con durata fissa o sconosciuto.
• training_use: disabilitato per impostazione predefinita, attivato o sconosciuto.
• human_review: abilitato, modificato, disabilitato o sconosciuto.
• stateful_storage: indica se l'endpoint o la funzionalità memorizza lo stato della conversazione, i file, i dati vettoriali, i completamenti o gli input batch.
• feature_flags: messa a terra, file, strumenti, cache, output archiviati, batch, assistenti o funzionalità equivalenti.
• evidence: nome del documento di origine, URL, data di recupero e data di revisione del proprietario.

Esempio:

{
  "capability_id": "azure-openai-gpt4o-datazone-chat-zdrlike-v3",
  "provider": "azure_openai",
  "account_scope": "prod-subscription-123",
  "endpoint": "chat_completions",
  "model_family": "gpt-4o",
  "region_mode": "datazone_eu",
  "content_retention": "abuse_monitoring_disabled_when_contentlogging_false",
  "training_use": "disabled_without_permission",
  "human_review": "modified_abuse_monitoring_approved",
  "stateful_storage": false,
  "features": {
    "files": false,
    "vector_store": false,
    "stored_completions": false,
    "grounding": false,
    "batch": false
  },
  "evidence": {
    "source": "provider_data_privacy_and_abuse_monitoring_docs",
    "retrieved_at": "2026-10-08",
    "review_owner": "security-architecture"
  }
}

Il consiglio è di trattare lo sconosciuto come negato per i carichi di lavoro sensibili. Se un record di capacità non dispone di un campo di conservazione, di una modalità regionale o di idoneità alle funzionalità, non dovrebbe soddisfare criteri rigorosi.

Classificare la richiesta prima dell'instradamento

La classificazione dovrebbe avvenire prima della selezione del modello. Un buon classificatore combina metadati statici e ispezione delle richieste:

• API ambito chiave: tenant, team, ambiente, applicazione e tipo di carico di lavoro.
• Tag del contratto: nessuna conservazione, solo UE, controlli di tipo HIPAA, dati finanziari, riservatezza del cliente o solo interno.
• Tipo di carico utile: testo libero, documento, immagine, riferimento al file, input di incorporamento, risultato dello strumento o contesto recuperato.
• Utilizzo delle funzionalità: web grounding, caricamento di file, archiviazione di vettori, lavoro batch, cronologia delle conversazioni archiviate, chiamate a strumenti o archiviazione di risposte.
• Modalità di registrazione: contenuto completo consentito, contenuto oscurato consentito, solo metadati o nessun contenuto del registro dell'applicazione.
• Suggerimenti regionali: posizione dell'utente, residenza dei dati del tenant, regione del progetto o regione di distribuzione.

Non fare affidamento solo sul rilevamento automatico dei dati sensibili. Utilizza la policy del carico di lavoro dichiarata dalla chiave API o dal progetto come origine primaria, quindi utilizza i classificatori per restringere la policy quando il carico utile contiene segnali di rischio.

function resolvePolicy(request) {
  const base = policyForApiKey(request.apiKeyId);
  const tenant = tenantContractPolicy(request.tenantId);
  const features = detectRequestedFeatures(request);
  const sensitivity = classifyPayload(request);

  return strictestApplicablePolicy([base, tenant, features, sensitivity]);
}

In pratica, ciò significa che una chiave di assistenza clienti può essere impostata su nessuna conservazione per impostazione predefinita, mentre una chiave di sperimentazione interna può consentire un routing più ampio. Se la stessa chiave di supporto tenta di caricare un file, la policy effettiva dovrebbe includere file_storage_allowed=false a meno che non esista un percorso approvato in grado di supportare file.

Valuta la policy prima del routing dei costi o della latenza

Il valutatore dovrebbe funzionare come un filtro. Riceve una policy, funzionalità di richiesta e percorsi del fornitore candidato. Restituisce solo i percorsi che soddisfano la policy.

function eligibleRoutes(request, policy, capabilities) {
  return capabilities.filter((route) => {
    if (!regionAllowed(route, policy.allowed_regions)) return false;
    if (!retentionAllowed(route, policy.max_content_retention)) return false;
    if (!trainingAllowed(route, policy.training_allowed)) return false;
    if (!humanReviewAllowed(route, policy.human_review_allowed)) return false;
    if (request.usesFiles && !policy.file_storage_allowed) return false;
    if (request.usesFiles && route.features.files !== true) return false;
    if (request.usesGrounding && !policy.grounding_allowed) return false;
    if (request.requiresState && !policy.stateful_storage_allowed) return false;
    if (route.content_retention === "unknown") return false;
    return true;
  });
}

function routeRequest(request) {
  const policy = resolvePolicy(request);
  const candidates = capabilityRegistry.findByModelIntent(request.modelIntent);
  const eligible = eligibleRoutes(request, policy, candidates);

  if (eligible.length === 0) {
    return deny("RETENTION_POLICY_NO_ELIGIBLE_ROUTE", policy.policy_id);
  }

  return chooseByCostLatencyAndHealth(eligible);
}

Questo ordine è importante. Il routing di fallback non deve passare a un provider non idoneo durante un'interruzione. L'instradamento batch non deve spostare una richiesta senza conservazione in un archivio processi asincrono. Il grounding non dovrebbe attivare una funzionalità che introduce log derivati quando la policy lo vieta.

Se la tua piattaforma espone un multimodello OpenAIcompatibile API, mantieni onesto il livello di compatibilità: lo stesso corpo della richiesta può essere compilato in diverse funzionalità native del provider. Il valutatore della policy deve controllare la richiesta compilata, non solo la forma SDK originale.

Blocca esplicitamente le combinazioni di funzionalità rischiose

L'implementazione più sicura consiste nel creare regole di rifiuto esplicite per le combinazioni note ad alto rischio. Esempi:

• NO_RETENTION + FILE_UPLOAD: nega a meno che l'endpoint file specifico e l'impostazione dell'account non siano approvati per il criterio.
• NO_RETENTION + VECTOR_STORE: nega a meno che l'archivio dei vettori non sia all'interno del tuo archivio controllato e il provider non riceva mai lo stato del file persistente.
• NO_RETENTION + STORED_RESPONSE: forza i flag di archiviazione della risposta disattivati o nega se l'endpoint non può disabilitare l'archiviazione.
• EU_ONLY + GLOBAL_DEPLOYMENT: nega se l'elaborazione può avvenire al di fuori della regione o della zona dati consentita.
• NO_RETENTION + WEB_GROUNDING: nega se la funzione di messa a terra memorizza query derivate o log di contesto oltre i criteri.
• METADATA_ONLY_LOGGING + DEBUG_TRACE: elimina il contenuto di prompt e completamento dai log e dalle tracce dell'applicazione.
• ZDR_REQUIRED + STATEFUL_ASSISTANT_THREAD: nega a meno che la funzionalità non sia specificamente idonea ai controlli approvati dell'account.

Restituisce errori specifici. Un rifiuto utile indica allo sviluppatore cosa non è riuscito e quali alternative approvate esistono.

{
  "error": {
    "code": "RETENTION_POLICY_DENIED",
    "reason": "NO_RETENTION_POLICY_DISALLOWS_FILE_STORAGE",
    "policy_id": "support_no_retention_eu_v1",
    "requested_feature": "file_upload",
    "approved_alternatives": [
      "send extracted text without provider file storage",
      "use internal document retrieval with metadata-only provider call",
      "request policy approval for controlled file processing"
    ]
  }
}

Registrazione delle inferenze separata dalla telemetria operativa

I criteri di conservazione non dovrebbero forzare il gateway a diventare cieco. In genere è possibile mantenere la telemetria operativa senza archiviare i contenuti di prompt o completamento.

Per carichi di lavoro rigidi, preserva:

• ID richiesta e ID traccia;
• tenant, progetto, API chiave e identificatori del carico di lavoro;
• ID norma e versione norma;
• provider, endpoint, modello, distribuzione e regione utilizzati;
• flag di funzionalità richiesti e consentiti;
• codici motivo della decisione;
• conteggio token, latenza, codice di stato e metadati dei costi;
• hash o impronte digitali stabili per la deduplicazione, se approvati dai criteri.

Sopprimi o oscura:

• suggerimenti grezzi;
• completamenti grezzi;
• contenuto del file caricato;
• output dello strumento che contengono i dati dei clienti;
• contesto recuperato da sistemi sensibili;
• il provider esegue il debug dei payload che duplicano i contenuti.

Qui è dove il routing di conservazione si collega all'osservabilità LLM indipendente dal provider. L'osservabilità dovrebbe dimostrare cosa è successo senza espandere l'insieme di sistemi che conservano contenuti sensibili.

Prova di audit per ogni decisione

Un record di controllo dovrebbe spiegare perché un percorso è stato consentito o negato. Non è necessario che il contenuto completo sia utile.

{
  "request_id": "req_01J...",
  "tenant_id": "tenant_42",
  "policy_id": "support_no_retention_eu_v1",
  "policy_version": 7,
  "decision": "allow",
  "provider": "anthropic",
  "endpoint": "messages",
  "model_family": "claude",
  "region_mode": "approved_region",
  "features": {
    "files": false,
    "grounding": false,
    "stateful_storage": false,
    "batch": false
  },
  "logging_mode": "metadata_only",
  "capability_record_id": "anthropic-claude-messages-zdr-v5",
  "capability_evidence_date": "2026-10-08",
  "reason_codes": [
    "POLICY_MATCHED_NO_RETENTION",
    "REGION_ALLOWED",
    "STATELESS_ENDPOINT",
    "CONTENT_LOGGING_SUPPRESSED"
  ]
}

Per le richieste respinte, mantieni la stessa struttura con decision=deny e codici motivo come REGION_NOT_ALLOWED, GROUNDING_RETENTION_EXCEEDS_POLICY o STATEFUL_STORAGE_NOT_ALLOWED.

Utilizza i test del contratto per le regole di conservazione

Il routing della conservazione dovrebbe avere test automatizzati. I test importanti non sono solo test unitari per i singoli fornitori; sono test contrattuali per il comportamento delle policy tra le combinazioni di fornitori.

I casi di test di alto valore includono:

• I criteri di non conservazione e il caricamento di file dovrebbero essere negati a meno che non esista uno specifico percorso approvato in grado di supportare file.
• Le norme esclusive dell'UE e l'implementazione globale dovrebbero negare il consenso anche quando il modello è altrimenti disponibile.
• Il criterio di conservazione zero e la cronologia delle conversazioni archiviate dovrebbero negare o forzare la disattivazione dell'archiviazione quando supportato.
• La funzionalità di messa a terra con conservazione dei log derivati dovrebbe essere negata in base ai criteri di non conservazione.
• La politica di registrazione dei soli metadati dovrebbe eliminare i contenuti di richiesta e completamento da tracce, log e rapporti di errore.
• Il record di capacità del provider con conservazione sconosciuta dovrebbe essere negato per i carichi di lavoro regolamentati.
• Il fallback dopo l'interruzione del provider dovrebbe rimanere all'interno del set di percorsi idonei.
• L'elaborazione batch dovrebbe essere negata quando l'endpoint batch archivia i file di input più a lungo di quanto consentito dai criteri.

Prova anche la deriva. Quando un record di capacità cambia, il sistema dovrebbe mostrare quali policy e percorsi sono interessati prima che la modifica raggiunga la produzione.

Proprietà operativa

La parte difficile non è scrivere il primo valutatore. Mantiene aggiornato il registro e impedisce eccezioni non documentate.

Assegna proprietari per:

• cadenza di revisione della documentazione del fornitore;
• stato di approvazione per controlli a livello di account come il monitoraggio degli abusi modificato o la conservazione dei dati pari a zero;
• inventario per la distribuzione regionale;
• idoneità delle funzionalità per file, archivi di vettori, grounding, batch e risposte archiviate;
• flusso di lavoro per eccezioni policy;
• verifica della conservazione dei record e del controllo degli accessi;
• Messaggi di errore rivolti agli sviluppatori e alternative approvate.

Ogni record di capacità deve avere una data di revisione. Se scade, policy rigorose dovrebbero smettere di fidarsi di esso o richiedere l’approvazione manuale. I documenti del fornitore e il comportamento delle funzionalità cambiano troppo spesso perché questa sia una configurazione statica.

Compromessi

Un router di conservazione rigoroso riduce la scelta dei modelli disponibili. Alcuni modelli di anteprima, API con stato, strumenti di messa a terra e flussi di lavoro di file non saranno disponibili per carichi di lavoro sensibili. Questo è lo scopo del controllo, ma i team di prodotto hanno bisogno di alternative chiare.

Il routing regionale può aumentare la latenza o i costi quando l'implementazione più veloce è globale ma il carico di lavoro richiede un'area geografica o una zona dati specifica. Rendilo visibile nella telemetria in modo che i team capiscano perché una richiesta ha utilizzato un percorso più costoso o più lento.

Il blocco delle funzionalità stateful può spingere i team a creare il proprio livello di memoria. Potrebbe trattarsi dell'architettura giusta, ma necessita comunque di policy di archiviazione, flussi di lavoro di eliminazione, crittografia, controllo degli accessi e registri di controllo. Lo spostamento dello stato fuori dal provider non rimuove il lavoro di governance.

La redazione di richiesta e completamento protegge i dati sensibili, ma indebolisce il debug e il controllo della qualità. Utilizza metadati di richiesta riproducibili, dispositivi di test deterministici, campionamento controllato per i carichi di lavoro consentiti e accesso rivoluzionario documentato laddove i criteri lo consentono.

Consigli

• Applica la conservazione e la residenza prima del routing del modello, non come controllo post-elaborazione.
• Funzionalità del modello a livello di provider, endpoint, funzionalità, regione e approvazione dell'account.
• Utilizza il comportamento di rifiuto per impostazione predefinita per carichi di lavoro regolamentati o vincolati a contratto con il cliente.
• Tratta il caricamento di file, gli archivi di vettori, il web grounding, l'elaborazione batch e la cronologia delle conversazioni archiviate come dimensioni di policy separate.
• Mantieni la telemetria operativa anche quando è necessario eliminare i contenuti di prompt e completamento.
• Genera record di controllo che includono policy, percorso, prove di funzionalità, regione, flag di archiviazione e codici motivo.
• Scrivi test contrattuali per combinazioni di funzionalità ad alto rischio e comportamenti di fallback.

Previsione: il routing di conservazione diventerà un livello gateway standard

La direzione più probabile è che il routing della conservazione diventi un livello standard nelle piattaforme LLM aziendali, in modo simile ai limiti di velocità, ai controlli del budget e all'osservabilità. Man mano che i fornitori aggiungono più strumenti con stato, opzioni di messa a terra, cache, file, agenti e funzionalità di memoria gestita, il percorso sicuro dipenderà meno dal nome del modello e più dal percorso di esecuzione completo.

Si tratta di una previsione, non di un requisito universale attuale. Il requisito attuale è più semplice: se il tuo team non promette alcuna conservazione, elaborazione regionale, utilizzo della formazione o revisione umana, il tuo gateway ha bisogno di una logica di policy e di prove sufficienti per dimostrare che ogni richiesta ha rispettato tali vincoli.

Conclusione attuabile

Costruisci il router di fidelizzazione come porta di policy davanti alla selezione del fornitore. Definisci una policy di conservazione canonica, classifica ogni richiesta prima dell'instradamento, mantieni un registro datato delle capacità del provider, nega le combinazioni non sicure per impostazione predefinita e registra le prove di controllo senza conservare i contenuti sensibili.

L'obiettivo della progettazione non è trovare un fornitore che sia sempre sicuro. L'obiettivo è dimostrare che una richiesta specifica, utilizzando un endpoint e un set di funzionalità specifici, in un account e in una regione specifici, ha soddisfatto la policy prima di essere inviata.

Lettura correlata

• progetto di osservabilità LLM indipendente dal provider