Los registros de auditoría de API de IA son la capa de evidencia detrás de una revisión de seguridad. Quienes revisan no solo preguntan si una aplicación llamó a un modelo. Quieren saber quién realizó la solicitud, qué clave o proyecto se utilizó, qué modelo y proveedor la gestionaron, si se almacenaron cargas útiles sensibles, cuánto tiempo se conservan los registros y si el equipo puede reconstruir un incidente sin exponer prompts, completions, secretos o datos personales.
Eso hace que los registros de auditoría de API de IA sean distintos de los registros de API genéricos. Una solicitud a un LLM puede atravesar propietarios de aplicaciones, claves de gateway, proveedores upstream, rutas de modelos, medidores de tokens, rutas de fallback, centros de costes y políticas de tratamiento de datos en una sola llamada. La traza de auditoría tiene que conectar esas capas sin convertir el almacén de registros en un segundo repositorio de datos sensibles.
Flatkey es relevante porque flatkey.ai se posiciona públicamente como una pasarela de API única para equipos de IA en producción, con acceso a modelos, enrutamiento, facturación, análisis de uso, controles operativos, un panel y la URL base del router https://router.flatkey.ai/v1. Una pasarela central puede convertirse en el punto de control para el registro de API de IA y la evidencia para revisiones, pero este artículo no asume un esquema de exportación de registros de auditoría específico de Flatkey, un período de retención ni un alcance de cumplimiento. Verifique esos detalles en su consola actual antes de entregar evidencia a un comprador.
Respuesta rápida: qué piden los revisores de seguridad
Un buen paquete de registros de auditoría de API de IA responde siete preguntas recurrentes. Si puedes responderlas con registros en lugar de capturas de pantalla y mensajes de Slack, la revisión del proveedor se vuelve mucho más fácil.
| Pregunta del revisor | Evidencia que mostrar | Fallo común |
|---|---|---|
| ¿Quién usó la API de IA? | Actor, cuenta de servicio, propietario de la clave, propietario de la aplicación, proyecto, equipo, entorno e identificador de solicitud. | Solo aparece una clave compartida del proveedor, así que hay que adivinar la propiedad. |
| ¿Qué ruta del modelo se usó? | Ruta de la pasarela, proveedor, modelo, familia de endpoint, decisión de fallback, estado, latencia y clase de error. | Los registros de la aplicación conocen la acción del usuario, mientras que los registros del proveedor conocen la llamada al modelo, pero nada los vincula. |
| ¿Qué datos se almacenaron? | Modo de registro de carga útil, política de redacción, configuración de almacenamiento de prompt/completion y notas de tratamiento de datos sensibles. | Los prompts y las respuestas sin procesar se almacenan de forma predeterminada sin una razón de negocio ni un plan de enmascaramiento. |
| ¿Puedes reconstruir un incidente? | IDs de solicitud, marcas de tiempo, IDs de traza de la aplicación, IDs de solicitud de la pasarela, IDs de solicitud del proveedor cuando estén disponibles y historial de eventos exportable. | Los registros se pueden buscar en un panel, pero no se pueden exportar ni correlacionar con eventos de la aplicación. |
| ¿Cómo evitas el gasto descontrolado? | Informes de uso y coste por clave, proyecto, modelo, propietario y intervalo de tiempo, además de evidencia de revisión de cuota o presupuesto. | Los registros de auditoría muestran cambios, pero faltan informes de uso y coste en el conjunto de evidencias. |
| ¿Cuánto tiempo permanecen los registros? | Periodo de retención, comportamiento de eliminación, proceso de archivo/exportación y quién puede aprobar el acceso a extractos de registros. | Los equipos conservan los registros para siempre porque nadie eligió un periodo de retención. |
| ¿Quién puede ver los registros? | Lista de roles o grupos, aprobaciones de acceso, supervisión del acceso a registros y separación entre registros de metadatos y registros de carga útil. | Todos los que tienen acceso al panel pueden inspeccionar cuerpos de solicitud sensibles. |
Los registros de auditoría de la API de IA no son lo mismo que los informes de uso
Los revisores de seguridad suelen decir "logs" cuando en realidad se refieren a tres tipos distintos de evidencia: eventos de auditoría, observabilidad de solicitudes e informes de uso o costos. Tratarlos como capas separadas evita respuestas confusas.
| Tipo de evidencia | Pregunta principal | Campos típicos | Lo que no demuestra por sí solo |
|---|---|---|---|
| Registros de auditoría del proveedor | ¿Quién cambió la organización, el proyecto, la clave, el rol o la configuración? | Actor, correo electrónico o ID del actor, tipo de evento, recurso de destino, marca de tiempo, detalles de IP/sesión y detalles del cambio de configuración. | Qué solicitud de la app consumió tokens o qué flujo de trabajo del cliente desencadenó tráfico del modelo. |
| Registros de solicitudes del gateway | ¿Qué ocurrió con cada solicitud de la API de IA? | ID de solicitud, clave del gateway, propietario de la app, proveedor, modelo, endpoint, estado, latencia, ruta/respaldo, conteos de tokens, costo y metadatos. | Si un rol o una configuración de clave del lado del proveedor cambió antes de la solicitud. |
| Informes de uso y costos | ¿Cuánto tráfico, volumen de tokens y gasto hubo por propietario, clave, proyecto, modelo y intervalo de tiempo? | Tokens de entrada, tokens de salida, tokens en caché, conteo de solicitudes, proyecto, usuario, clave de API, modelo, partida, importe y moneda. | Quién aprobó el acceso, quién cambió una clave o qué solicitud exacta falló durante un incidente. |
La API de administración de OpenAI es un ejemplo público útil de esta separación. Su endpoint de Audit Logs se describe como una lista de acciones recientes de los usuarios y cambios de configuración de la organización, mientras que sus endpoints de usage y costs exponen campos de uso/costo y opciones de agrupación como proyecto, usuario, clave de API, modelo, nivel de servicio, partida e intervalo de tiempo. Esa separación es un buen modelo mental para cualquier programa de registros de auditoría de la API de IA: los eventos de auditoría, los registros de solicitudes y los informes de uso/costo deben estar conectados, pero no son intercambiables.
La lista de verificación de campos para los registros de auditoría de API de IA
Utilice esta lista de verificación como la matriz de evidencia para las revisiones de gateway de IA. No todos los campos pertenecen a todos los almacenes de registros. La idea es decidir qué pertenece a los registros de metadatos, qué pertenece a los registros de cargas restringidas, qué pertenece a los registros de administración del proveedor y qué no debe conservarse en absoluto.
| Grupo de campos | Campos recomendados | Valor para el revisor | Nota de manejo |
|---|---|---|---|
| Tiempo y correlación | Hora del evento, ID de solicitud del gateway, ID de rastreo de la aplicación, ID de solicitud del proveedor cuando esté disponible e ID del lote de exportación. | Permite a los equipos reconstruir la secuencia y vincular registros de la aplicación, el gateway y el proveedor. | Use un identificador de interacción estable para eventos relacionados. |
| Identidad y propiedad | Propietario de la clave del gateway, cuenta de servicio, proyecto, aplicación, equipo, centro de costos, entorno e ID de inquilino del cliente si es necesario. | Muestra la responsabilidad y respalda las preguntas de riesgo de proveedor sobre claves compartidas. | Prefiera IDs internos o identificadores hash sobre datos personales brutos cuando sea posible. |
| Ruta de la solicitud | Familia de endpoint, proveedor, modelo, grupo de ruta, decisión de respaldo, estado de caché, recuento de reintentos y código de estado. | Explica qué ruta de modelo atendió la solicitud y por qué ocurrió un respaldo. | No almacene secretos de los encabezados de la solicitud. |
| Métricas operativas | Duración, tiempo hasta el primer token cuando esté disponible, clase de error, evento de límite de tasa, decisión de cuota y decisión de política. | Apoya la clasificación de incidentes y la revisión de confiabilidad. | Mantenga los detalles de error útiles, pero sanee la entrada no confiable. |
| Uso y costo | Tokens de entrada, tokens de salida, tokens almacenados en caché, recuento de solicitudes, costo estimado, elemento de línea facturable y moneda. | Apoya la revisión del presupuesto, la asignación de costos y la investigación de gastos inusuales. | Use atribución de costos por equipo y seguimiento de uso por clave para los resúmenes. |
| Política de cargas | Modo de registro de cargas, resultado de la redacción, decisión de DLP, hash del prompt, hash de la respuesta e indicadores de adjunto/archivo. | Muestra si el contenido sensible se almacenó, se suprimió o se transformó. | El registro solo de metadatos suele ser suficiente para la revisión de seguridad y la clasificación de incidentes. |
| Retención y acceso | Clase de retención, fecha de eliminación, ubicación de archivo, permiso de exportación, rol del visor y evento de acceso al registro. | Responde preguntas sobre minimización de datos, limitación de almacenamiento y control de acceso del revisor. | Registre el acceso a registros sensibles y restrinja las vistas de las cargas. |
La guía de registro de OWASP es una buena base aquí: los registros de aplicaciones deben registrar cuándo, dónde, quién y qué; los datos de eventos de otras zonas de confianza deben tratarse como no confiables; y los datos sensibles deben eliminarse, enmascararse, sanearse, hashearse o cifrarse antes de que lleguen a los registros. Para los registros de auditoría de API de IA, ese último punto importa porque los prompts y las completaciones pueden contener secretos, datos regulados, contenido de clientes y estrategia interna.
Matriz de evidencia para SOC 2, ISO 27001, GDPR y revisión de proveedores
La tabla a continuación no es un mapeo de controles legales. Es una forma práctica de traducir el lenguaje de revisión de seguridad en evidencia que su equipo de plataforma realmente puede producir.
| Área de revisión | Lo que normalmente preguntan los revisores | Evidencia de los registros de auditoría de API de IA | Propietario de la evidencia |
|---|---|---|---|
| Control de acceso | ¿Quién puede crear, ver, actualizar o revocar las claves de API de IA y la configuración de la puerta de enlace? | Eventos de auditoría de administrador del proveedor, inventario de claves de la puerta de enlace, lista de roles/grupos y registro de revisión de acceso. | Seguridad o plataforma |
| Control de cambios | ¿Cómo demuestra que una ruta de modelo, cuota, clave o política cambió mediante un proceso aprobado? | Ticket de cambio, aprobador, evento de auditoría, configuración antes/después, registro de implementación y nota de reversión. | Ingeniería de plataforma |
| Respuesta a incidentes | ¿Puede reconstruir un uso sospechoso o errores del proveedor para un período definido? | IDs de solicitud, marcas de tiempo, metadatos de actor/proyecto/clave, decisiones de ruta, códigos de estado, recuentos de tokens y paquete de eventos exportado. | Operaciones de seguridad |
| Minimización de datos | ¿Almacena prompts y respuestas sin procesar? Si es así, ¿por qué y quién puede verlos? | Modo de registro de cargas útiles, política de redacción, lista restringida de visualizadores de cargas útiles y evidencia de que existe un modo solo de metadatos donde se usa. | Seguridad, privacidad y propietario de la aplicación |
| Retención | ¿Cuánto tiempo se conservan los registros y cómo se eliminan los registros caducados? | Política de retención, límite de almacenamiento, regla de eliminación, regla de archivo y registro de monitoreo de acceso a registros. | Seguridad y gobernanza de datos |
| Gobernanza de costos | ¿Puede detectar un gasto inesperado en modelos o atribuirlo a un equipo? | Exportaciones de uso/costo agrupadas por clave, proyecto, modelo, equipo, intervalo de tiempo y eventos de cuota. | FinOps o plataforma |
| Riesgo de proveedores | ¿Puede mostrar a un revisor un flujo de trabajo de evidencia concreto y repetible? | Paquete para revisores con sistemas de origen, fecha de exportación, rango de tiempo, propietario, declaración de redacción e índice de evidencia. | Seguridad y adquisiciones |
Para revisiones de estilo GDPR, los principios del artículo 5 de la regulación oficial incluyen minimización de datos y limitación del almacenamiento. Aplicado a los registros de auditoría de API de IA, eso significa que debe documentar por qué cada campo almacenado es necesario, evitar conservar cargas útiles sin procesar de forma predeterminada y establecer un período de retención que coincida con el propósito de los registros.
Qué no poner en los registros de auditoría de LLM
La forma más rápida de fallar una revisión de registros es crear más datos sensibles de los que necesita la propia aplicación de producción. Los registros de auditoría de LLM deben ayudar a responder preguntas de seguridad sin convertirse en una copia descontrolada de las conversaciones de los clientes.
| Datos | Riesgo | Patrón más seguro |
|---|---|---|
| Prompts y completions sin procesar | Pueden contener datos personales, secretos, contenido de clientes, contenido privilegiado o datos regulados. | Use por defecto registros solo de metadatos; almacene cargas útiles solo para casos de uso aprobados con acceso y retención restringidos. |
| Claves API, tokens bearer y credenciales del proveedor | Genera exposición de credenciales dentro del sistema de evidencias. | No registre nunca secretos. En su lugar, almacene un ID de clave, el propietario de la clave o una huella hash. |
| Identificadores de usuario sin redacción | Amplía el alcance de privacidad y hace que los exportes sean más difíciles de compartir. | Use IDs de usuario internos, IDs de tenant o hashes con sal si se requieren y aprueban los valores sin procesar. |
| Encabezados completos de solicitud y respuesta | Los encabezados pueden llevar cookies, tokens de autenticación, baggage de trazas y nombres de infraestructura interna. | Mantenga solo los encabezados incluidos en la lista de अनुमति, como ID de solicitud, clase de user agent o metadatos seguros de gateway. |
| Trazas de depuración de llamadas al modelo fallidas | Los datos de depuración pueden incluir cargas útiles sin procesar, stack traces y detalles internos de implementación. | Sanitice antes de la persistencia y almacene los registros de depuración extendidos por separado de los registros de auditoría estándar. |
La documentación pública de AI Gateway de Cloudflare muestra una distinción útil: los controles por solicitud pueden omitir el almacenamiento de las cargas útiles sin procesar de solicitud y respuesta, preservando al mismo tiempo metadatos como el recuento de tokens, el modelo, el proveedor, el código de estado, el costo y la duración. La documentación pública de observabilidad de AI Gateway de Vercel describe resúmenes de solicitudes por proyecto y clave API, además de registros detallados de solicitudes con campos de tokens y costos. Estos son ejemplos públicos del patrón general: mantener los metadatos ampliamente útiles y restringir estrictamente la visibilidad de las cargas útiles.
Cómo diseñar una pista de auditoría para un gateway de IA
Una pista de auditoría de gateway de IA funciona mejor cuando se diseña antes de que un revisor la solicite. Use este flujo de trabajo para convertir registros dispersos en evidencia de revisión.
- Elija el punto de control. Decida qué solicitudes deben pasar por el gateway de IA, qué eventos de administración del proveedor permanecen en los registros de auditoría del proveedor y qué eventos de la aplicación permanecen en los registros de la aplicación.
- Defina metadatos seguros del propietario. Estandarice los campos de proyecto, aplicación, equipo, entorno, centro de costos, inquilino del cliente y propietario clave. Evite valores de formato libre que filtren datos personales.
- Decida el modo de registro de cargas útiles. Separe el registro solo de metadatos del registro de prompts/respuestas sin procesar. Exija aprobación explícita para el almacenamiento de cargas útiles.
- Mapee los ID de solicitud. Pase un ID de solicitud o de seguimiento desde la aplicación al gateway y conserve los identificadores del gateway/proveedor cuando estén disponibles.
- Separe los eventos de cambio de los eventos de solicitud. La creación de claves, los cambios de rutas, los cambios de roles y los cambios de cuota pertenecen a los eventos de auditoría. Las llamadas al modelo pertenecen a los registros de solicitudes.
- Conecte el uso y el costo. Agregue resúmenes por clave, proyecto, modelo, equipo y segmento de tiempo para que las preguntas de presupuesto puedan responderse desde el mismo paquete de evidencia.
- Establezca reglas de retención y exportación. Decida quién puede exportar registros, cómo se redactan los extractos, dónde se almacena la evidencia y cuándo se elimina.
- Pruebe un paquete para revisores. Elija un intervalo de tiempo inocuo, exporte la evidencia y confirme que otro ingeniero pueda reconstruir la ruta de una solicitud solo a partir del paquete.
- Revise el acceso trimestralmente. Registre el acceso a los registros, restrinja las vistas de cargas útiles y elimine los permisos obsoletos de paneles/exportación.
Si ya enruta el tráfico a través de Flatkey, comience el flujo de trabajo desde el enrutador central: verifique la URL base actual, las claves, los propietarios, el análisis de uso, el contexto de facturación, los controles de enrutamiento, los controles de cuota y las etiquetas del panel. Luego conecte esos registros con los ID de seguimiento de la aplicación y los eventos de auditoría del lado del proveedor. Para el trabajo de configuración relacionado, use la lista de verificación de gateway de API de IA empresarial, la guía de registros de observabilidad de API de IA y el runbook de rotación de claves del gateway.
Plantilla de paquete para revisores
Cuando un comprador pide registros de auditoría de la API de IA, no envíes una exportación en bruto sin explicación. Envía un paquete de evidencia que muestre el alcance, el manejo de datos y la trazabilidad.
| Sección del paquete | Contenido | Por qué importa |
|---|---|---|
| Declaración de alcance | Sistema, entorno, rango de fechas, aplicaciones incluidas, claves de gateway incluidas y fuentes excluidas. | Evita que los revisores asuman que la muestra cubre todas las rutas de producción. |
| Índice de fuentes | Registros de auditoría del proveedor, registros de solicitudes del gateway, registros de la aplicación, informes de uso/coste, tickets de cambio y registro de revisión de accesos. | Muestra qué sistema prueba cada parte del rastro. |
| Diccionario de campos | Significado de ID de solicitud, actor, propietario de la clave, proyecto, proveedor, modelo, estado, tokens, coste, ruta y modo de carga útil. | Permite a los revisores interpretar las exportaciones sin adivinar. |
| Declaración de redacción | Qué se enmascaró, se aplicó hash, se eliminó o no se recopiló intencionalmente. | Muestra disciplina de minimización de datos. |
| Declaración de retención | Clase de retención, programa de eliminación, ubicación del archivo y proceso de excepción. | Responde a preguntas sobre limitación de almacenamiento y disponibilidad de evidencia. |
| Declaración de acceso | Roles que pueden ver los registros de metadatos, roles que pueden ver los registros de carga útil y cómo se supervisa el acceso a los registros. | Muestra la revisión de privilegio mínimo en torno a la propia evidencia. |
| Rastro de muestra | Una solicitud segura y no sensible que muestra el evento de la aplicación, la solicitud del gateway, la ruta del proveedor, el resumen de uso/coste y el estado final. | Demuestra que la ruta de la evidencia funciona de extremo a extremo. |
Notas de implementación de Flatkey
Para los equipos de Flatkey, mantén las notas de implementación vinculadas a la prueba actual del producto y no a suposiciones. El sitio público admite una narrativa de posicionamiento de una sola pasarela en torno al acceso al modelo, el enrutamiento, la facturación, el análisis de uso, los controles operativos, el contexto del panel, el contexto de precios y la URL base del router. Eso basta para enmarcar un flujo de trabajo práctico de evidencias, pero no basta para afirmar un formato específico de exportación de registros de auditoría de la API de IA nativo.
- Usa la pasarela como límite de responsabilidad. Asigna las claves del router y los proyectos a propietarios de aplicaciones, equipos, entornos y centros de coste antes de que crezca el tráfico en producción.
- Vincula los registros a los controles de gasto. Combina la observabilidad a nivel de solicitud con la gestión de cuotas, la atribución de costes y el catálogo de precios en vivo.
- Separa las evidencias de metadatos y de carga útil. Un revisor puede a menudo validar los controles de acceso, enrutamiento, coste y reconstrucción de incidentes sin ver prompts o respuestas en bruto.
- Comprueba el panel el día de la revisión. Verifica las etiquetas, el comportamiento de exportación, los permisos de rol, el estado de las rutas, la disponibilidad de modelos y los controles de retención antes de comprometerlos en un cuestionario de comprador.
- Mantén el CTA simple. Si quieres un único punto de control de la pasarela para el registro, el enrutamiento, la facturación y la revisión del uso de la API de IA, obtén una clave.
FAQ: Registros de auditoría de API de IA
¿Qué son los registros de auditoría de API de IA?
Los registros de auditoría de API de IA son registros que ayudan a los equipos a demostrar quién cambió el acceso o la configuración de la API de IA, qué aplicaciones y claves generaron tráfico del modelo, qué ruta de proveedor/modelo atendió las solicitudes, qué uso y costo se produjeron y cómo se manejaron los datos sensibles de la carga útil.
¿Son los registros de auditoría de LLM lo mismo que los registros de observabilidad?
No. Los registros de auditoría de LLM suelen centrarse en la responsabilidad, el acceso, los cambios de configuración y la evidencia para revisores. Los registros de observabilidad se centran en la depuración de solicitudes, la latencia, el uso de tokens, los errores y el comportamiento de las rutas. Los equipos maduros conectan ambas vistas mediante IDs de solicitud y metadatos de propietario.
¿Debería el registro de API de IA almacenar prompts y respuestas?
No por defecto. Almacene primero metadatos: IDs de solicitud, campos de propietario, modelo, proveedor, estado, recuentos de tokens, costo, latencia, ruta y modo de registro de carga útil. Almacene prompts o respuestas sin procesar solo cuando exista un propósito claro y aprobado, acceso restringido, redacción y un período de retención definido.
¿Qué campos debe incluir una pista de auditoría de ai gateway?
Una pista de auditoría de ai gateway debe incluir hora de la solicitud, ID de solicitud, aplicación o proyecto, propietario de la clave, entorno, proveedor, modelo, endpoint, decisión de ruta/fallback, estado, latencia, recuentos de tokens, costo, decisión de cuota, modo de registro de carga útil, clase de retención y controles de exportación/acceso.
¿Cómo ayuda Flatkey con los registros de auditoría de API de IA?
Flatkey proporciona un contexto central de gateway de API de IA para acceso a modelos, enrutamiento, facturación, análisis de uso, controles operativos y revisión de panel. Use ese punto central para estandarizar los metadatos de propietario y los flujos de trabajo de evidencia, y luego verifique el comportamiento actual de la consola antes de afirmar capacidades específicas de exportación de registros de auditoría, retención o control de acceso.
Cuando un comprador pregunta por registros de auditoría de API de IA, la mejor respuesta no es un montón de registros sin procesar. Es un paquete de evidencia claro: qué se registró, qué no se registró intencionalmente, quién puede verlo, cuánto tiempo permanece y cómo se puede reconstruir una solicitud desde la aplicación hasta el gateway, el proveedor y el resumen de costos. Si está centralizando el acceso a la API de IA y necesita esa ruta de evidencia, Obtenga una clave.
