Registro de Auditoría

El registro de auditoría de i1n registra cada mutación en una organización, no como una línea general de 'archivo de traducción actualizado', sino como un evento estructurado, por clave y por idioma. Cuando un usuario del panel cambia la traducción al español (es_mx) de errors.insufficient_funds a las 14:32 UTC, el registro captura el valor exacto anterior, el valor exacto posterior, la identidad del actor, la marca de tiempo, la dirección IP y el agente de usuario de la solicitud que produjo el cambio.

La cobertura abarca toda el área de la plataforma: creación, edición y eliminación de traducciones; creación, cambio de nombre y eliminación de namespaces; cambios en la configuración del proyecto y la voz de marca; invitaciones de equipo, cambios de roles y eliminaciones; creación, rotación, cambios de alcance y eliminación de claves de API; cambios en el plan de facturación, eventos de suscripción y activación de BYOK.

Las operaciones masivas, como la inserción de i1n, producen un evento por cada par clave-idioma modificado en lugar de un único resumen general, con un identificador de lote compartido en los metadatos. Una inserción que actualiza 200 claves en cuatro idiomas produce 800 entradas de auditoría direccionables individualmente, cada una con su propia diferencia. Por lo tanto, los auditores pueden responder 'qué cambió el 17 de abril a las 14:32' hasta la cadena exacta.

Los eventos son emitidos por disparadores de PostgreSQL adjuntos a cada tabla auditada. No existe una ruta de escritura a nivel de aplicación que omita el registro; cada mutación exitosa genera su fila de auditoría dentro de la misma transacción de base de datos. Un cambio que se confirma sin una fila de auditoría correspondiente no es posible por diseño.

Cada entrada de auditoría está etiquetada con uno de los cinco tipos de actor: 'user' para mutaciones del panel, 'cli' para operaciones directas de línea de comandos, 'mcp' para cambios realizados por un agente de IA a través del servidor MCP de i1n, 'webhook' para eventos originados en sistemas externos como el proveedor de facturación, y 'system' para trabajos internos de la plataforma como la poda de retención.

La atribución de usuarios del panel es criptográfica. El identificador del actor es el ID de cuenta del usuario autenticado, que se muestra junto con su correo electrónico verificado y nombre de la lista de miembros de la organización. Los administradores que revisan el registro ven identidades humanas reales, no UUIDs opacos.

La atribución de CLI y MCP está criptográficamente vinculada a la clave API en uso, con el prefijo de clave registrado para la correlación forense. También se capturan pistas derivadas de la configuración de git del desarrollador —correo electrónico y nombre completo— pero se etiquetan explícitamente como no verificadas en el panel. Esta separación honesta entre la identidad criptográfica y los metadatos autoinformados es lo que los revisores de cumplimiento esperan de un sistema de auditoría maduro.

La observabilidad del agente de IA es, hasta donde sabemos, exclusiva de i1n. Cada cambio de traducción realizado por Claude Code, Cursor o cualquier otro cliente conectado al servidor i1n MCP se etiqueta con actor_type = 'mcp'. Las organizaciones pueden filtrar el registro de auditoría para responder 'qué traducciones fueron modificadas por última vez por un agente de IA en comparación con un revisor humano', una pregunta que no tiene una respuesta clara en ninguna otra plataforma de localización.

A medida que los agentes de IA asumen una mayor parte del flujo de trabajo de localización, la capacidad de auditarlos como actores de primera clase se está convirtiendo en un requisito de adquisición. El filtro de tipo de actor está a un clic en el panel y es un parámetro de consulta en la exportación CSV.

El registro de auditoría es de solo adición a nivel de base de datos. Los disparadores emiten filas; no se expone ninguna ruta de INSERT a los clientes, y no hay políticas de UPDATE o DELETE en la tabla. Los miembros de una organización no pueden editar su propio historial. El personal de operaciones de i1n tampoco puede editar ni eliminar entradas; la tabla está protegida a nivel de esquema, no a nivel de aplicación.

La retención es de 365 días, alineada con la línea base de control SOC 2 para los registros de actividad. Los registros de más de 365 días se eliminan mediante un trabajo programado que emite una entrada de auditoría; cada eliminación es rastreable. Las organizaciones que requieren ventanas más largas para una revisión regulatoria específica pueden solicitar una extensión a nivel de contrato.

El registro expone los puntos de datos que los revisores de cumplimiento suelen solicitar: quién, qué, cuándo, dónde (dirección IP), cómo (agente de usuario) y qué cambió (valores antes y después, en su totalidad). Para las organizaciones sujetas al mantenimiento de registros del Artículo 30 del GDPR o a los reguladores de fintech que requieren trazabilidad del contenido visible para el usuario, la exportación es suficiente como evidencia primaria.

i1n no publica actualmente un informe SOC 2 Tipo II a nivel de plataforma. El registro de auditoría es el control subyacente que respalda el programa de cumplimiento SOC 2, GDPR o fintech de un cliente — no reemplaza los controles organizacionales, pero elimina el bloqueo más común en las revisiones de cumplimiento, que es la ausencia de un rastro auditable sobre los cambios de contenido.

El acceso de lectura al registro de auditoría está restringido a los propietarios y administradores de la organización. Los editores y espectadores no ven la pestaña del registro de auditoría en el panel de control y no pueden consultarla a través de la API. Esta separación está reforzada por la seguridad a nivel de fila de PostgreSQL, no por el ocultamiento del lado del cliente; no hay forma de leer el registro desde un rol no privilegiado.

Los editores y espectadores siguen estando completamente sujetos al registro de auditoría. Cada acción que realizan en la plataforma —ediciones de traducción, solicitudes de traducción de IA, operaciones a nivel de miembro— se registra con su identidad y es visible para el equipo de administración. Las personas que están siendo auditadas no pueden eliminarse del registro.

Los propietarios y administradores no pueden editar entradas históricas. La pregunta 'quién puede leer' y la pregunta 'quién puede modificar' tienen deliberadamente respuestas diferentes: leer es a nivel de administrador, modificar no es para nadie. Esto satisface las expectativas de separación de funciones que los auditores aplican al revisar los controles de acceso internos.

El acceso a la API refleja el modelo del panel. El registro de auditoría se expone a través de las mismas políticas de seguridad a nivel de fila que controlan el panel, por lo que cualquier cuenta de servicio o token de integración utilizado para consultar el registro hereda automáticamente las mismas restricciones.

Los datos del registro de auditoría se pueden exportar como CSV desde el panel de control con una acción de un solo clic. La exportación cubre cualquier rango de tiempo seleccionado y respeta los filtros activos —tipo de actor, tipo de evento, proyecto y término de búsqueda— para que los revisores puedan recibir una porción acotada en lugar del historial completo. El CSV conserva la fidelidad completa: marca de tiempo, organización, proyecto, identidad del actor, tipo de actor, prefijo de clave de API, tipo de evento, entidad, valor anterior, valor posterior, dirección IP, agente de usuario y metadatos.

Cada exportación de CSV genera una entrada de auditoría de tipo audit_log.exported, que registra quién realizó la exportación y qué filtros se aplicaron. Esto cierra el ciclo de cadena de custodia (chain-of-custody) sobre el que preguntan los revisores de cumplimiento: el acto de extraer evidencia es en sí mismo parte de la evidencia.

El registro de auditoría está activo automáticamente en todas las organizaciones Enterprise. No hay ningún paso de configuración, ningún interruptor de activación y ninguna configuración requerida. Los clientes Enterprise existentes, incluido belo, el socio de lanzamiento, tienen un registro poblado desde el momento en que se lanzó la función, capturando la actividad de cada panel, CLI y cliente MCP conectado a la organización.

Las organizaciones en el plan Pro o Business no tienen acceso al registro de auditoría. La actualización a Enterprise activa el registro de inmediato y comienza a capturar eventos a partir de la marca de tiempo de la actualización; no se proporciona retención histórica previa a la actualización. Comuníquese con el equipo de i1n para analizar los precios de Enterprise para su organización.