Compliance API para auditoría y supervisión

Módulo 7 · Administración y medición · Lección 3 de 6

Al terminar esta lección podrás explicar qué cubre la Compliance API, quién puede acceder a ella y cómo habilitarla cuando el equipo legal o de seguridad de un cliente lo solicite.

La única superficie que captura qué se habló.

Qué captura

El único mecanismo que ofrece la conversación.

Todas las demás superficies del stack de observabilidad capturan metadatos. La Compliance API captura contenido. Por eso es la herramienta adecuada para e-discovery, para la integración con DLP y para la retención legal (legal hold).

Cuando el equipo legal de un cliente envía un cuestionario de gobierno de datos, o cuando llega a la mesa del equipo de seguridad una solicitud de e-discovery, la Compliance API es la superficie por la que preguntan. También es el único mecanismo con retención de hasta seis años y capacidad de retención legal dirigida.

Qué obtienes

Contenido de conversaciones y eventos de auditoría. Acceso programático a las entradas y salidas del chat, a las cargas de archivos y a los eventos del feed de actividad. Es el único mecanismo del stack en el que está disponible el contenido del chat. Todas las demás superficies capturan solo metadatos.

Retención

Hasta seis años, configurable

Los planes Enterprise tienen retención indefinida por defecto. Las ventanas personalizadas van de 1 día a indefinida. La retención legal conserva el contenido más allá de la ventana de retención estándar para usuarios o conversaciones concretos.

Acceso

Solo Primary Owner

Solo el Primary Owner puede habilitar la Compliance API y crear claves de acceso. Los Owner no pueden acceder a esta superficie. El contenido de las conversaciones requiere el nivel de autorización más alto.

Casos de uso

Cuatro integraciones estándar

• SIEM: envía los eventos de actividad a Splunk, Microsoft Sentinel o cualquier backend OTLP mediante GET /v1/organizations/{id}/audit-events. Disponible en Enterprise y Platform.
• DLP / CASB: conecta Nightfall, Microsoft Purview o Symantec al endpoint de conversaciones (GET /v1/organizations/{id}/conversations) para el escaneo de contenido. Solo Enterprise.
• eDiscovery: recuperación dirigida por ID de usuario o por ID de conversación (GET …/conversations/{conversation_id}) para revisión en Relativity o Exterro. Solo Enterprise.
• Postura de seguridad de IA: categoría más nueva de herramientas que evalúan los patrones de uso de Claude y señalan riesgos de comportamiento usando los mismos endpoints.

El modelo es una interfaz compartida: el equipo de seguridad del cliente y sus proveedores de seguridad acceden a los mismos endpoints de la Compliance API, expuestos dentro de las herramientas que el cliente ya opera. Anthropic admite más de 28 integraciones con proveedores de seguridad en estas cuatro categorías, que abarcan plataformas SIEM, herramientas DLP y CASB, plataformas de eDiscovery y soluciones de postura de seguridad de IA. Para los clientes que preguntan “¿esto funciona con nuestro stack actual?”, la respuesta en la mayoría de los entornos empresariales es sí.

Regla de trabajo

La Compliance API te dice qué se discutió. OTel te dice qué se ejecutó. Los registros de auditoría capturan eventos administrativos. La Analytics API es una superficie separada: cubre señales de adopción y uso (DAU, utilización de asientos, gasto), no contenido de conversaciones. No la confundas con la Compliance API en una revisión de seguridad del cliente.

El stack de observabilidad

Misma pregunta. Cinco respuestas distintas.

Cada mecanismo responde a una pregunta distinta. La tabla resume lo que cubre cada superficie y dónde se detiene.

Superficie	Categoría	Qué cubre	Limitación	Acceso y retención
Audit Logs	Eventos administrativos	Inicios de sesión, eventos de proyectos y archivos, cambios de miembros y de ajustes de administración. Se exporta como CSV desde Organization settings.	No contiene contenido de conversaciones.	Owner y Primary Owner. Ventana rodante de 180 días.
Admin API	Gestión de la organización	Aprovisionamiento de usuarios, gestión de workspaces, claves de API y límites de gasto. Sirve para administrar la organización, no para revisar la actividad.	No contiene contenido de conversaciones.	Primary Owner y Owner. Disponible hoy para organizaciones Console y API.
OTel	Qué se ejecutó	Cada llamada a herramienta, comando bash, invocación MCP y solicitud de API. Stream OTLP en tiempo real hacia Splunk, Datadog o cualquier backend OTLP.	No captura contenido de conversaciones.	Requiere opt-in mediante configuración MDM o variable de entorno.
Analytics	Señales de adopción	Adopción agregada, utilización de asientos, uso de funcionalidades y gasto.	Sin contenido individual de conversación ni de actividad.	Primary Owner y Owner, mediante el dashboard de administración y la API programática. Ideal para readouts y decisiones de expansión.
Compliance API	Qué se discutió	Contenido de conversaciones (entradas, salidas, cargas de archivos) y eventos del feed de actividad.	—	Solo Primary Owner. Retención de hasta seis años, configurable.

Habilitar la API

Un ajuste. Tres rutas para configurarlo.

La Compliance API está desactivada por defecto. La forma de habilitarla depende de si el cliente está en un plan Enterprise o en Claude Platform. En ambos casos, el Primary Owner puede hacerlo sin apoyo de ingeniería.

1. Plan Claude Enterprise

Los Primary Owner habilitan la Compliance API desde la configuración de la organización. No requiere trabajo de ingeniería. Las claves de acceso se crean por integración y se pueden rotar o revocar desde la misma pantalla.

Pasos para habilitarla:

• Ve a Organization settings › API
• Haz clic en Enable en Compliance API
• Haz clic en + Create key para generar una clave de acceso de compliance
• Copia y guarda la clave de forma segura. Solo se muestra una vez.

Asocia cada clave a la integración que la necesita. Crea una clave separada para cada herramienta DLP, SIEM o plataforma de e-discovery. Así se limita el alcance si una clave necesita rotarse.

2. Claude Platform (clientes de API)

Los administradores de Claude Platform habilitan la Compliance API desde la consola de la plataforma. Las instrucciones completas y la documentación de los endpoints están en la guía de Compliance API del sitio de documentación de la plataforma.

Referencias:

• Documentación de la plataforma: platform.claude.com/docs/en/manage-claude/compliance-api
• Referencia de la API: platform.claude.com/docs/en/api/compliance

Requiere acceso. La documentación de la plataforma exige iniciar sesión. En los engagements con clientes, confirma si el cliente está en Enterprise o en Platform antes de remitirlo a los pasos de habilitación, porque el flujo es distinto.

3. Checklist previo al lanzamiento

La configuración de la Compliance API pertenece a la fase previa al lanzamiento, junto con el SSO y el aprovisionamiento de usuarios. Estos son los puntos que conviene confirmar antes de que el despliegue entre en producción:

• Compliance API habilitada y clave de acceso creada
• Acceso a los registros de auditoría confirmado desde Organization settings › Data and Privacy
• Política de retención de datos documentada y configurada
• Proceso de retención legal acordado con los equipos legal y de compliance
• Integración con DLP o SIEM conectada si la política de seguridad lo exige

No lo omitas durante el kickoff. Los clientes que completan la configuración de compliance antes del go-live evitan la vía de remediación más lenta, que consiste en extraer datos históricos después de que llegue una solicitud de incidente o de auditoría.

Comprueba tu comprensión

Escenario · Enrutar solicitudes de compliance

Cuatro decisiones. Cada una se corresponde con un mecanismo concreto. Si aciertas el enrutamiento, el cliente obtiene una respuesta rápida; si no, pierdes una semana buscando datos en la superficie equivocada. Ocho puntos en total. Cada opción vale 2 puntos (mejor), 1 (parcial) o 0 (incorrecta). Elige una opción en cada decisión y compara tu criterio con la explicación.

Decisión 1 de 4 · Solicitud de investigación de RR. HH.

Legal solicita acceso a las conversaciones de un empleado concreto de los últimos 90 días para una investigación de RR. HH. ¿A qué superficie lo diriges?

• A. Exportar los registros de auditoría desde Organization settings
• B. Consultar la Compliance API con el ID de usuario del empleado
• C. Consultar el feed SIEM de OTel para los eventos de sesión de ese usuario

Ver respuesta

Mejor opción: B (2 puntos). Parcial: C (1 punto). Incorrecta: A (0 puntos).

A. Exportar los registros de auditoría desde Organization settings (incorrecta, 0 puntos). Los registros de auditoría contienen metadatos de eventos, como inicios de sesión, eventos de proyectos y cambios administrativos. Está disponible para los Owner sin configuración adicional.

Retroalimentación: Los registros de auditoría contienen inicios de sesión, eventos de proyectos y cambios administrativos, pero no contenido de conversaciones. El equipo legal necesita las conversaciones reales. La Compliance API es el único mecanismo que las proporciona.

B. Consultar la Compliance API con el ID de usuario del empleado (mejor, 2 puntos). La Compliance API ofrece acceso programático al contenido de las conversaciones. Es el único mecanismo que incluye lo que realmente se dijo.

Retroalimentación: Correcto. La Compliance API es el único mecanismo que incluye el contenido de las conversaciones. Los registros de auditoría y OTel capturan metadatos y eventos de ejecución, no lo que se dijo. Para una solicitud de RR. HH. o de legal que requiere las conversaciones reales, la Compliance API es la única superficie viable.

C. Consultar el feed SIEM de OTel para los eventos de sesión de ese usuario (parcial, 1 punto). OTel captura eventos de sesión, llamadas a herramientas y metadatos de actividad vinculados a una identidad de usuario. El SIEM tiene 90 días de datos de eventos para este usuario.

Retroalimentación: Los eventos de sesión de OTel confirman que un usuario estuvo activo y pueden mostrar qué herramientas ejecutó, pero no incluyen el contenido de las conversaciones. Legal necesita saber qué se dijo, no solo cuándo ocurrió la sesión. Derívalo a la Compliance API.

Decisión 2 de 4 · Alertas de seguridad en tiempo real

El equipo de seguridad quiere alertas en tiempo real cada vez que un desarrollador ejecute un comando bash desde Claude Code. ¿Qué arquitectura lo admite?

• A. Consultar la Compliance API cada cinco minutos para detectar nuevos eventos de herramientas
• B. Configurar OTel con OTEL_LOG_TOOL_DETAILS=1 y enrutar al SIEM
• C. Exportar los registros de auditoría cada semana y marcar los eventos bash durante la revisión

Ver respuesta

Mejor opción: B (2 puntos). Parcial: A (1 punto). Incorrecta: C (0 puntos).

A. Consultar la Compliance API cada cinco minutos para detectar nuevos eventos de herramientas (parcial, 1 punto). La Compliance API captura eventos del feed de actividad. Con sondeos frecuentes, puedes acercarte a una detección casi en tiempo real de la actividad bash.

Retroalimentación: La Compliance API es un modelo de pull, no un stream. El sondeo cada cinco minutos introduce un retraso que anula la alerta en tiempo real. Para cualquier caso de uso que requiera detección inmediata de la ejecución de herramientas, OTel con un backend OTLP es la arquitectura adecuada.

B. Configurar OTel con OTEL_LOG_TOOL_DETAILS=1 y enrutar al SIEM (mejor, 2 puntos). OTel es el feed de ejecución en tiempo real. Con OTEL_LOG_TOOL_DETAILS habilitado, cada comando bash se captura como evento y se transmite al SIEM de inmediato.

Retroalimentación: Correcto. OTel es el feed de ejecución en tiempo real. Con OTEL_LOG_TOOL_DETAILS=1 habilitado, cada comando bash se captura como evento tool_result y se transmite al SIEM de inmediato. La Compliance API es un modelo de pull, no un stream en tiempo real.

C. Exportar los registros de auditoría cada semana y marcar los eventos bash durante la revisión (incorrecta, 0 puntos). Las revisiones semanales de los registros de auditoría son manejables y dan a seguridad una cadencia regular para revisar el uso de herramientas, sin añadir infraestructura nueva.

Retroalimentación: Las revisiones semanales de los registros de auditoría no permiten alertas en tiempo real. Además, los registros de auditoría no incluyen el detalle de las llamadas a herramientas a nivel de comando. OTel con OTEL_LOG_TOOL_DETAILS habilitado está diseñado específicamente para este requisito.

Decisión 3 de 4 · Solicitud de retención legal

Legal necesita conservar todas las conversaciones de un empleado a través de Claude Code y Claude.ai durante una posible retención de tres años relacionada con una investigación en curso. ¿Qué configuras?

• A. Establecer la ventana de retención de datos de toda la organización en tres años en los ajustes de administración
• B. Habilitar la retención legal para ese usuario mediante la Compliance API
• C. Descargar ahora el CSV de los registros de auditoría y archivarlo externamente

Ver respuesta

Mejor opción: B (2 puntos). Parcial: A (1 punto). Incorrecta: C (0 puntos).

A. Establecer la ventana de retención de datos de toda la organización en tres años en los ajustes de administración (parcial, 1 punto). Los controles de retención de datos personalizados permiten configurarla de 1 día a indefinida. Ajustarla a tres años garantiza que todos los datos de la organización se conserven durante el periodo requerido.

Retroalimentación: Cambiar la ventana de retención de toda la organización es la dirección correcta, pero no equivale a una retención legal. Una retención fija el contenido concreto para impedir su eliminación con independencia de la política de la organización. Eso requiere la Compliance API. Cambiar solo la retención puede dejar el contenido expuesto si la política se modifica después.

B. Habilitar la retención legal para ese usuario mediante la Compliance API (mejor, 2 puntos). La Compliance API admite retención legal dirigida, que conserva el contenido de usuarios o conversaciones concretos independientemente de la política de retención estándar.

Retroalimentación: Correcto. La Compliance API admite retención legal dirigida, que conserva el contenido de usuarios o conversaciones concretos independientemente de la política de retención estándar. Los ajustes de retención personalizados cambian el valor por defecto de toda la organización, pero no crean una retención legal. En procedimientos legales, la diferencia importa.

C. Descargar ahora el CSV de los registros de auditoría y archivarlo externamente (incorrecta, 0 puntos). Una exportación en un momento concreto, archivada externamente, significa que legal tiene los datos independientemente de lo que ocurra después con la política de retención.

Retroalimentación: Los registros de auditoría no contienen contenido de conversaciones. Archivar un CSV de eventos administrativos no cumplirá un requisito de retención legal sobre datos de conversaciones. La Compliance API admite retención legal dirigida precisamente para este escenario.

Decisión 4 de 4 · Monitoreo de DLP

El equipo de compliance pregunta cómo vigilar las conversaciones de Claude en busca de PII compartida con el sistema. ¿Cómo lo configuras?

• A. Conectar una herramienta DLP mediante la Compliance API
• B. Enrutar los eventos de OTel al SIEM y escanear allí los patrones de PII
• C. Revisar a diario la Analytics API en busca de picos de uso inusuales

Ver respuesta

Mejor opción: A (2 puntos). Parcial: B (1 punto). Incorrecta: C (0 puntos).

A. Conectar una herramienta DLP mediante la Compliance API (mejor, 2 puntos). La Compliance API da a las herramientas DLP acceso programático al contenido de las conversaciones. Hay integraciones de la Compliance API disponibles para las plataformas de seguridad más habituales.

Retroalimentación: Correcto. El DLP requiere escanear el texto real de entrada y salida de las conversaciones. La Compliance API es el único mecanismo que proporciona contenido de conversaciones de forma programática. Hay integraciones de la Compliance API disponibles para las plataformas DLP más habituales, así que es una vía bien respaldada.

B. Enrutar los eventos de OTel al SIEM y escanear allí los patrones de PII (parcial, 1 punto). Los eventos de OTel incluyen atributos de identidad de usuario, como el correo y el ID de sesión. Una regla del SIEM que vigile patrones de PII en esos atributos ofrece alertas en tiempo real sin necesidad de una integración con la Compliance API.

Retroalimentación: Los atributos de los eventos de OTel incluyen la identidad del usuario y el contexto de sesión, pero no el contenido de las conversaciones. Una regla del SIEM puede señalar patrones de sesión inusuales, pero no puede escanear PII que aparezca en el texto de una conversación. Para un DLP a nivel de contenido, la Compliance API es necesaria.

C. Revisar a diario la Analytics API en busca de picos de uso inusuales (incorrecta, 0 puntos). Los picos inusuales en el uso de tokens o en el volumen de sesiones pueden indicar, a veces, que se están procesando datos sensibles en volúmenes superiores a los habituales.

Retroalimentación: Los datos de Analytics están agregados y no contienen contenido de conversaciones. Los picos inusuales de uso pueden motivar una investigación adicional, pero no pueden confirmar si apareció PII en una conversación concreta. El DLP requiere acceso al contenido, que solo proporciona la Compliance API.

Ver debrief y texto de cierre

La fuente asigna un texto de cierre según la puntuación final, sobre un máximo de 8 puntos.

Listo para atender la llamada de compliance (7 u 8 puntos). Enrutaste las cuatro solicitudes del cliente al mecanismo correcto. La distinción entre lo que cubre la Compliance API frente a OTel y los registros de auditoría es la que aparece en cada revisión de seguridad empresarial. La tienes.

Encuadre sólido, con algunas lagunas (4 a 6 puntos). El núcleo de la distinción está, pero una o dos decisiones confundieron OTel o los registros de auditoría con la Compliance API. El dato que más saldrá: solo la Compliance API incluye el contenido de las conversaciones. Todo lo demás son metadatos.

Conviene volver a repasarlo (0 a 3 puntos). La distinción clave que hay que repasar: la Compliance API captura lo que se discutió; OTel captura lo que se ejecutó; los registros de auditoría capturan eventos administrativos. Cada mecanismo tiene su carril claro. Repasa los temas y vuelve después.

Ruta de habilitación

De una solicitud de compliance a un feed activo.

La mayoría de los clientes llegan a la Compliance API a través de una revisión de seguridad, una solicitud de e-discovery o una política de gobierno de datos. El camino desde “lo necesitamos” hasta “el feed está funcionando” tiene cinco pasos.

flowchart LR
    P1["1. Identificar el requisito"] --> P2["2. Confirmar acceso de Primary Owner"]
    P2 --> P3["3. Habilitar en Organization settings"]
    P3 --> P4["4. Crear una clave de acceso de compliance"]
    P4 --> P5["5. Conectar a la integración"]

1. Identificar el requisito

¿E-discovery, DLP, retención legal o integración con SIEM? Cada una implica una configuración ligeramente distinta. Aclara esto antes de abrir la consola de administración. Llegar sin saber qué integración se va a conectar te costará una segunda llamada.

2. Confirmar el acceso de Primary Owner

Solo el Primary Owner puede habilitar la Compliance API. Los Owner no pueden. Asegúrate de tener a la persona correcta en la llamada antes de la sesión de habilitación. Un Owner que intente completar este paso no verá la opción en sus ajustes.

3. Habilitar en Organization settings

Ve a Organization Settings › API. Haz clic en Enable en Compliance API. Esto tarda menos de un minuto y no requiere apoyo de ingeniería.

4. Crear una clave de acceso de compliance

Haz clic en + Create key. Crea una clave separada para cada integración. Las claves se muestran una sola vez; guárdalas de forma segura. Si una clave necesita rotarse, vuelve a la misma pantalla y emite una nueva sin afectar a las demás integraciones.

5. Conectar a la integración

Herramienta DLP, SIEM o plataforma de e-discovery. Hay integraciones de la Compliance API disponibles para las plataformas de seguridad más habituales. Para desarrollos a medida, la documentación completa de los endpoints está en la documentación de Claude Platform.

Ideas clave

La Compliance API tiene una sola función. Sabe cuándo usarla.

• Conoces qué captura la Compliance API y cómo encaja en el stack de observabilidad de cinco mecanismos.
• Solo la Compliance API incluye el contenido de las conversaciones; el resto de superficies captura metadatos.
• Solo el Primary Owner puede habilitarla y crear claves de acceso; conviene emitir una clave separada por integración.
• Antes del go-live, confirma la clave, el acceso a los registros de auditoría, la política de retención, el proceso de retención legal y la integración DLP o SIEM.

OTel es el feed de ejecución en tiempo real. La lección 4 cubre las tres rutas de exportación, el despliegue en toda la organización mediante managed-settings y las métricas clave que tus clientes querrán ver en sus dashboards.

Siguiente: Configuración del pipeline de OpenTelemetry