Progetta la tua integrazione di conformità

Un'integrazione di produzione con la Compliance API comporta tre scelte progettuali: come consuma l'Activity Feed, come il suo output si correla con il tuo sistema di "security information and event management" (gestione delle informazioni e degli eventi di sicurezza), o SIEM, e dove risiedono le copie a lungo termine di attività e contenuti. Queste scelte sono indipendenti dagli endpoint stessi; questa pagina ti aiuta a valutare i compromessi.

Questa pagina presuppone che tu abbia letto le seguenti pagine:

• Interrogare l'Activity Feed, che definisce i parametri e il contratto di paginazione a cui si fa riferimento in tutta la pagina.
• Recuperare ed eliminare chat, file e progetti, che definisce gli endpoint di chat, file e progetti e la semantica di deleted_at a cui si fa riferimento in Pianifica la conservazione dei contenuti.
• Recuperare le trascrizioni delle sessioni, che definisce gli endpoint delle sessioni locali e remote.

Scegli un modello di consumo del feed

L'Activity Feed supporta due modelli di consumo: il "window polling" (polling a finestre) periodico delimitato da created_at.gte e created_at.lt, e le letture incrementali basate su cursore che persistono un cursore da una risposta e lo passano nella richiesta successiva. Entrambi restituiscono oggetti Activity identici; la differenza è lo stato che il tuo client persiste tra le chiamate.

Entrambi i modelli condividono questi vincoli:

• Le attività sono interrogabili entro 1 minuto dal loro verificarsi e conservate per 6 anni. La registrazione non è retroattiva: inizia quando la Compliance API viene abilitata per la prima volta per la tua organizzazione, e le attività precedenti all'abilitazione non vengono recuperate retroattivamente.
• Il limit massimo per ogni pagina è 5.000.
• I valori dei cursori sono stringhe opache che non devi analizzare.
• Le richieste sono limitate a 600 al minuto per organizzazione padre, condivise tra ogni chiave, ogni organizzazione collegata e ogni endpoint /v1/compliance/*; a differenza degli endpoint delle sessioni locali, gli endpoint delle sessioni remote prevedono un secondo budget di richieste aggiuntivo. Consulta 429 Too Many Requests per gli header di risposta e il contratto di retry.

Window polling

Imposta created_at.lt ad almeno 1 minuto nel passato in modo che ogni attività nella finestra sia già interrogabile. Usa created_at.gte per il limite inferiore e created_at.lt per il limite superiore in modo che le finestre consecutive si affianchino senza lacune o sovrapposizioni; riutilizza il valore lt della finestra precedente come gte della finestra successiva.

curl --fail-with-body -sS -G \
  "https://api.anthropic.com/v1/compliance/activities" \
  --header "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
  --data-urlencode "created_at.gte=2026-04-20T07:00:00Z" \
  --data-urlencode "created_at.lt=2026-04-20T08:00:00Z" \
  --data-urlencode "limit=5000"

Quando la risposta ha has_more: true, la finestra contiene più di una pagina di attività. Puoi paginare all'interno della finestra passando il last_id della risposta come after_id nella richiesta successiva (fermandoti quando has_more è false), oppure scegliere una finestra temporale più piccola. Consulta Paginare i risultati per il contratto completo.

Anche con un affiancamento pulito, un'attività che viene indicizzata dopo la chiusura della sua finestra non appare mai in una finestra successiva. Deduplica in base all'id dell'attività e amplia ogni nuova finestra in modo che si sovrapponga alla precedente di qualche minuto, oppure esegui un passaggio di riconciliazione periodico che interroghi nuovamente una finestra più vecchia.

Letture incrementali basate su cursore

first_id="activity_01XyDMpzjS89pFZXqSFUBDr6"  # first_id from a previous response

curl --fail-with-body -sS -G \
  "https://api.anthropic.com/v1/compliance/activities" \
  --header "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
  --data-urlencode "limit=5000" \
  --data-urlencode "before_id=$first_id"

Pagina fino a quando has_more è false, quindi persisti first_id dalla risposta finale e passalo invariato come before_id nell'esecuzione successiva per recuperare le attività più recenti del cursore salvato. Per procedere nella direzione opposta per un backfill, persisti last_id e passalo invece come after_id. Per il riferimento completo cursore-vs-page-token e la semantica di retry, consulta Paginare i risultati.

Un ciclo di catch-up (recupero) di produzione recupera le attività registrate dall'ultimo polling guidando l'iterazione tramite has_more e first_id:

cursor = stored_cursor
loop:
  page = GET /v1/compliance/activities?before_id={cursor}&limit=5000
  store(page.data)
  if page.first_id is not null:
    cursor = page.first_id
  if not page.has_more: break
persist(cursor)

I cursori sopravvivono alla rotazione delle chiavi; consulta Gestire e ruotare le chiavi.

Correla con il tuo SIEM

Ogni Activity contiene campi che puoi unire agli eventi già presenti nel tuo SIEM (Splunk, Datadog, Microsoft Sentinel, Cribl o simili):

actor.user_id e actor.email_address sono presenti quando actor.type è user_actor. actor.ip_address e actor.user_agent sono assenti in alcuni tipi di attore, come anthropic_actor e scim_directory_sync_actor. Controlla il discriminatore prima di leggere uno qualsiasi di questi campi. user_id è un identificatore stabile e opaco per l'account utente: è coerente in ogni endpoint della Compliance API e in ogni payload di attività, e non cambia quando cambiano l'email o il nome visualizzato dell'utente. Usa user_id, non email_address, come chiave di join primaria.

Le chiamate alla Compliance API stessa emettono attività compliance_api_accessed. Acquisiscile insieme agli altri tipi di attività in modo che il tuo SIEM registri chi ha interrogato i dati di conformità e quando. Passa activity_types[]=compliance_api_accessed per restringere la query, quindi nel tuo client leggi actor.api_key_id da ogni attività il cui actor.type è api_actor per attribuire l'accesso a una specifica Compliance Access Key o chiave API Admin.

Pianifica la conservazione dei contenuti

Cinque orizzonti di conservazione determinano ciò che puoi recuperare in seguito:

Per sapere come il resto della Claude Platform gestisce la conservazione, consulta API e conservazione dei dati.

Decidi tra esportazione e archiviazione e recupero on-demand tramite API come segue:

• Se il tuo orizzonte di legal hold o di audit supera i 6 anni per i metadati delle attività o le trascrizioni delle sessioni, esporta le pagine dell'Activity Feed e le trascrizioni delle sessioni nel tuo archivio man mano che le acquisisci.
• Se la tua policy di conservazione dei contenuti è più breve del tuo orizzonte di eDiscovery, esporta i contenuti di chat e file prima che la finestra di conservazione scada; la Compliance API non può restituire contenuti che la conservazione ha già rimosso. Lo stesso vale per le trascrizioni delle sessioni locali, che seguono il periodo di conservazione delle conversazioni personalizzato della tua organizzazione quando ne è impostato uno finito, anche quando tale periodo è inferiore a 6 anni. Gli endpoint delle sessioni locali smettono di restituire i messaggi più vecchi del periodo corrente della tua organizzazione non appena l'impostazione cambia, e allungare il periodo in seguito non ripristina le trascrizioni già scadute, quindi esporta qualsiasi trascrizione che devi conservare oltre tale periodo.
• Se devi conservare i contenuti delle chat dopo che gli utenti li eliminano in claude.ai (ad esempio, in caso di legal hold), esporta i contenuti di chat, file e artifact nel tuo archivio man mano che li acquisisci; la Compliance API non può restituire contenuti che un utente ha già eliminato.
• Se un flusso di lavoro potrebbe emettere un'eliminazione definitiva tramite la Compliance API (ad esempio, l'applicazione di DLP), recupera e archivia prima i contenuti di destinazione. Non esiste una finestra di recupero dopo un'eliminazione definitiva.

In ogni altro caso, affidati al recupero diretto tramite API ed evita di mantenere una copia parallela.

Garanzie di consegna e completezza

Considera l'Activity Feed come at-least-once (almeno una volta): un attraversamento paginato correttamente restituisce ogni attività almeno una volta, ma un retry dopo un errore parziale può riconsegnare attività che hai già memorizzato. Deduplica in base al campo id dell'attività.

Gli endpoint di elenco non restituiscono un campo total_count né un checksum. Per attestare che un'esecuzione di esportazione è completa, registra:

• Il cursore iniziale e il last_id terminale.
• Il numero di record esportati.
• Il timestamp dell'esecuzione e il request-id della pagina finale.

Il volume delle attività non è un controllo di completezza. I tipi di attività claude_*_viewed, come claude_chat_viewed, seguono il modello di caricamento di ciascuna app (consulta Comprendere l'oggetto Activity). Un periodo con messaggi di chat ma senza attività claude_chat_viewed non indica di per sé dati mancanti. Affidati invece all'attraversamento e al passaggio di sovrapposizione o riconciliazione descritto in Window polling.

Gli endpoint dei contenuti (chat, file, progetti, allegati di progetto e trascrizioni delle sessioni locali e remote) servono solo dati Claude Enterprise. L'Activity Feed espone eventi amministrativi e relativi alle risorse a livello di organizzazione. La Compliance API non include:

• Testo dei prompt o risposte del modello da Claude Console, o da carichi di lavoro della Claude API autenticati con una chiave API.
• Attività sul dispositivo nelle sessioni locali che non viene mai inviata ad Anthropic, come file locali che Claude non ha letto.
• Utilizzo di Claude Code autenticato con una chiave API di Claude Console, eseguito tramite una piattaforma cloud di terze parti (Amazon Bedrock, Google Cloud o Microsoft Foundry), o eseguito in Claude Code sul web.
• Sessioni locali di organizzazioni con HIPAA readiness abilitata, e sessioni locali per le quali è in vigore la zero data retention.
• Blocchi di pensiero, e immagini o altri contenuti binari, all'interno delle trascrizioni delle sessioni (le trascrizioni contengono solo prompt dell'utente, risposte dell'assistente e attività degli strumenti; le trascrizioni delle sessioni locali mostrano un blocco text segnaposto dove i contenuti binari sono stati omessi).
• Il file originale di un allegato di chat che claude.ai ha memorizzato come testo estratto, come alcuni caricamenti Word, PowerPoint e PDF (l'endpoint del contenuto dei file restituisce il testo estratto; consulta Recuperare file e artifact).
• Il prompt di sistema delle sessioni locali (un messaggio marcatore lo sostituisce).
• Definizioni degli strumenti e configurazione dei server MCP nelle trascrizioni delle sessioni (locali o remote), e metadati delle citazioni sui blocchi text nelle trascrizioni delle sessioni locali.
• Contenuti delle trascrizioni delle sessioni locali in un'organizzazione la cui chiave di crittografia gestita dal cliente non può attualmente essere utilizzata. Tali richieste restituiscono 503 Service Unavailable, e i metadati delle sessioni vengono comunque elencati.
• Contenuti rimossi dalla policy di conservazione della tua organizzazione.
• Contenuti delle chat che gli utenti eliminano in claude.ai (le chat vengono comunque elencate, con deleted_at popolato).
• Contenuti eliminati definitivamente tramite la Compliance API.

Consulta le FAQ della Compliance API per saperne di più su ciò che la Compliance API acquisisce e non acquisisce.

Per la catena di custodia, memorizza i record esportati con metadati di provenienza: endpoint di origine, parametri della query, timestamp dell'esecuzione e un hash del contenuto di ciascun record.

Passaggi successivi