Diseña tu integración de cumplimiento

Una integración de producción con la Compliance API toma tres decisiones de diseño: cómo consume el Activity Feed, cómo se correlaciona su salida con tu sistema de "security information and event management" (gestión de información y eventos de seguridad), o SIEM, y dónde residen las copias a largo plazo de la actividad y el contenido. Estas decisiones son independientes de los endpoints en sí; esta página te ayuda a evaluar las ventajas y desventajas.

Esta página asume que has leído las siguientes páginas:

• Consultar el Activity Feed, que define los parámetros y el contrato de paginación a los que se hace referencia a lo largo de esta página.
• Recuperar y eliminar chats, archivos y proyectos, que define los endpoints de chats, archivos y proyectos, y la semántica de deleted_at a la que se hace referencia en Planificar la retención de contenido.
• Recuperar transcripciones de sesiones, que define los endpoints de sesiones locales y remotas.

Elige un patrón de consumo del feed

El Activity Feed admite dos patrones de consumo: el sondeo periódico por ventanas delimitado por created_at.gte y created_at.lt, y las lecturas incrementales basadas en cursores que persisten un cursor de una respuesta y lo pasan en la siguiente solicitud. Ambos devuelven objetos Activity idénticos; la diferencia es el estado que tu cliente persiste entre llamadas.

Ambos patrones comparten estas restricciones:

• Las actividades se pueden consultar dentro de 1 minuto después de ocurrir y se retienen durante 6 años. El registro no es retroactivo: comienza cuando la Compliance API se habilita por primera vez para tu organización, y la actividad anterior a la habilitación no se rellena retroactivamente.
• El limit máximo para cada página es 5,000.
• Los valores de cursor son cadenas opacas que no debes analizar.
• Las solicitudes están limitadas a 600 por minuto por organización principal, compartidas entre todas las claves, todas las organizaciones vinculadas y todos los endpoints /v1/compliance/*; a diferencia de los endpoints de sesiones locales, los endpoints de sesiones remotas tienen un segundo presupuesto de solicitudes adicional. Consulta 429 Too Many Requests para conocer los encabezados de respuesta y el contrato de reintentos.

Sondeo por ventanas

Establece created_at.lt al menos 1 minuto en el pasado para que todas las actividades de la ventana ya se puedan consultar. Usa created_at.gte para el límite inferior y created_at.lt para el límite superior, de modo que las ventanas consecutivas se encadenen sin huecos ni superposiciones; reutiliza el valor lt de la ventana anterior como el gte de la siguiente ventana.

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"

Cuando la respuesta tiene has_more: true, la ventana contiene más de una página de actividades. Pagina dentro de la ventana pasando el last_id de la respuesta como after_id en la siguiente solicitud (deteniéndote cuando has_more sea false), o elige una ventana de tiempo más pequeña. Consulta Paginar resultados para conocer el contrato completo.

Incluso con un encadenamiento limpio, una actividad que se indexa después de que su ventana se haya cerrado nunca aparece en una ventana posterior. Deduplica por el id de la actividad y, o bien amplía cada nueva ventana para que se superponga con la anterior por unos minutos, o bien ejecuta una pasada de reconciliación periódica que vuelva a consultar una ventana más antigua.

Lecturas incrementales basadas en cursores

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 hasta que has_more sea false, luego persiste el first_id de la respuesta final y pásalo sin cambios como before_id en la siguiente ejecución para recuperar las actividades más recientes que el cursor guardado. Para recorrer en la dirección opuesta en un relleno histórico, persiste last_id y pásalo como after_id en su lugar. Para la referencia completa de cursores frente a tokens de página y la semántica de reintentos, consulta Paginar resultados.

Un bucle de puesta al día de producción obtiene las actividades registradas desde tu último sondeo, impulsando la iteración a partir de has_more y 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)

Los cursores sobreviven a la rotación de claves; consulta Administrar y rotar claves.

Correlaciona con tu SIEM

Cada Activity contiene campos que puedes cruzar con eventos que ya están en tu SIEM (Splunk, Datadog, Microsoft Sentinel, Cribl o similar):

actor.user_id y actor.email_address están presentes cuando actor.type es user_actor. actor.ip_address y actor.user_agent están ausentes en algunos tipos de actor, como anthropic_actor y scim_directory_sync_actor. Verifica el discriminador antes de leer cualquiera de estos campos. user_id es un identificador estable y opaco de la cuenta de usuario: es consistente en todos los endpoints de la Compliance API y en todas las cargas útiles de actividad, y no cambia cuando cambia el correo electrónico o el nombre visible del usuario. Usa user_id, no email_address, como clave de cruce principal.

Las llamadas a la propia Compliance API emiten actividades compliance_api_accessed. Ingiérelas junto con los demás tipos de actividad para que tu SIEM registre quién consultó los datos de cumplimiento y cuándo. Pasa activity_types[]=compliance_api_accessed para delimitar la consulta y luego, en tu cliente, lee actor.api_key_id de cada actividad cuyo actor.type sea api_actor para atribuir el acceso a una Compliance Access Key o clave de Admin API específica.

Planifica la retención de contenido

Cinco horizontes de retención determinan lo que puedes recuperar más adelante:

Para saber cómo el resto de la Claude Platform maneja la retención, consulta API y retención de datos.

Decide entre exportar y archivar o recuperar bajo demanda mediante la API de la siguiente manera:

• Si tu horizonte de retención legal o de auditoría supera los 6 años para los metadatos de actividad o las transcripciones de sesiones, exporta las páginas del Activity Feed y las transcripciones de sesiones a tu propio archivo a medida que las ingieres.
• Si tu política de retención de contenido es más corta que tu horizonte de eDiscovery, exporta el contenido de chats y archivos antes de que expire la ventana de retención; la Compliance API no puede devolver contenido que la retención ya haya eliminado. Lo mismo aplica a las transcripciones de sesiones locales, que siguen el período de retención de conversaciones personalizado de tu organización cuando se establece uno finito, incluso cuando ese período es más corto que 6 años. Los endpoints de sesiones locales dejan de devolver mensajes más antiguos que el período actual de tu organización tan pronto como cambia la configuración, y alargar el período más adelante no restaura las transcripciones que ya expiraron, así que exporta cualquier transcripción que debas conservar más allá de ese período.
• Si debes retener el contenido de chats después de que los usuarios lo eliminen en claude.ai (por ejemplo, bajo una retención legal), exporta el contenido de chats, archivos y artefactos a tu propio archivo a medida que lo ingieres; la Compliance API no puede devolver contenido que un usuario ya haya eliminado.
• Si un flujo de trabajo podría emitir una eliminación definitiva a través de la Compliance API (por ejemplo, aplicación de DLP), recupera y archiva primero el contenido objetivo. No hay ventana de recuperación después de una eliminación definitiva.

En todos los demás casos, confía en la recuperación directa mediante la API y evita mantener una copia paralela.

Garantías de entrega y completitud

Trata el Activity Feed como at-least-once (al menos una vez): un recorrido correctamente paginado devuelve cada actividad al menos una vez, pero un reintento después de una falla parcial puede volver a entregar actividades que ya almacenaste. Deduplica por el campo id de la actividad.

Los endpoints de listado no devuelven un campo total_count ni una suma de verificación. Para certificar que una ejecución de exportación está completa, registra:

• El cursor inicial y el last_id final.
• El número de registros exportados.
• La marca de tiempo de la ejecución y el request-id de la página final.

El volumen de actividad no es una verificación de completitud. Los tipos de actividad claude_*_viewed, como claude_chat_viewed, siguen el patrón de carga de cada aplicación (consulta Comprender el objeto Activity). Un período con mensajes de chat pero sin actividades claude_chat_viewed no indica por sí solo que falten datos. En su lugar, confía en el recorrido y en la pasada de superposición o reconciliación descrita en Sondeo por ventanas.

Los endpoints de contenido (chats, archivos, proyectos, adjuntos de proyectos y transcripciones de sesiones locales y remotas) sirven únicamente datos de Claude Enterprise. El Activity Feed muestra eventos administrativos y de recursos de toda la organización. La Compliance API no incluye:

• Texto de prompts ni respuestas del modelo de Claude Console, ni de cargas de trabajo de la Claude API autenticadas con una clave de API.
• Actividad en el dispositivo en sesiones locales que nunca se envía a Anthropic, como archivos locales que Claude no leyó.
• Uso de Claude Code autenticado con una clave de API de Claude Console, ejecutado a través de una plataforma en la nube de terceros (Amazon Bedrock, Google Cloud o Microsoft Foundry), o ejecutado en Claude Code en la web.
• Sesiones locales de organizaciones con preparación para HIPAA habilitada, y sesiones locales para las que está vigente la retención cero de datos.
• Bloques de pensamiento, e imágenes u otro contenido binario, dentro de las transcripciones de sesiones (las transcripciones contienen únicamente prompts del usuario, respuestas del asistente y actividad de herramientas; las transcripciones de sesiones locales muestran un bloque text de marcador de posición donde se omitió el contenido binario).
• El archivo original de un adjunto de chat que claude.ai almacenó como texto extraído, como algunas cargas de Word, PowerPoint y PDF (el endpoint de contenido de archivos devuelve el texto extraído; consulta Recuperar archivos y artefactos).
• La indicación del sistema de las sesiones locales (un mensaje marcador la sustituye).
• Definiciones de herramientas y configuración de servidores MCP en las transcripciones de sesiones (locales o remotas), y metadatos de citas en los bloques text de las transcripciones de sesiones locales.
• Contenido de transcripciones de sesiones locales en una organización cuya clave de cifrado administrada por el cliente no se puede usar actualmente. Esas solicitudes devuelven 503 Service Unavailable, y los metadatos de la sesión se siguen listando.
• Contenido eliminado por la política de retención de tu organización.
• Contenido de chats que los usuarios eliminan en claude.ai (los chats se siguen listando, con deleted_at completado).
• Contenido eliminado de forma definitiva a través de la Compliance API.

Consulta las Preguntas frecuentes de la Compliance API para obtener más información sobre lo que la Compliance API captura y lo que no.

Para la cadena de custodia, almacena los registros exportados con metadatos de procedencia: endpoint de origen, parámetros de consulta, marca de tiempo de la ejecución y un hash de contenido de cada registro.

Próximos pasos