Enterprise
Un registro de auditoría de solo adición para el desarrollo asistido por IA
Cada prompt, merge, despliegue y acción de administración, registrado de solo adición, así «quién hizo qué, y quién lo aprobó» tiene una respuesta que pueden leer tus auditores.
Ciao mantiene un registro de auditoría de solo adición sobre prompts, merges, despliegues y acciones de administración. A diferencia de las herramientas de desarrollo que solo registran commits, el registro captura la nueva pregunta de la era de la IA (qué se pidió a la IA, qué cambió como resultado, y qué humano lo revisó) con Guardrails registrando la revisión humana tras cada merge. El registro se puede exportar para revisión de auditoría y demostrar en vivo durante la evaluación.
Publicado 2026-07-03 · Última actualización 2026-07-03
«Quién hizo qué» ahora incluye a la IA
La gestión de cambios tradicional audita tres artefactos: el ticket, el commit y la aprobación. El desarrollo asistido por IA añade un cuarto que la mayoría de herramientas ignora: el prompt. Cuando una petición en lenguaje sencillo puede producir un cambio de producción, la petición en sí es parte del registro del cambio, y un registro de auditoría que empieza en el commit ya ha perdido el inicio de la historia.
Ciao registra la secuencia completa. Los prompts son eventos de primera clase; los merges llevan el registro de revisión de Guardrails (qué política se aplicó, qué humano lo revisó, qué se aprobó); los despliegues y acciones de administración completan el cuadro. El registro es de solo adición: las entradas se acumulan, y la historia que leen tus auditores es la historia que ocurrió. Nada de la secuencia tiene que reconstruirse a partir de exportaciones de chat o capturas de pantalla después del hecho.
Para un CISO, esto convierte una pregunta incómoda («¿cómo controláis lo que cambia la IA?») en una revisable: extrae el registro y lee exactamente qué se pidió, qué cambió, quién lo aprobó y cuándo se publicó. Esa única capacidad tiende a mover a una plataforma de desarrollo con IA de la columna «excepciones que explicar» de una revisión de riesgo a la columna «controles que citar», porque pocas historias de gestión de cambios en el resto del patrimonio empiezan tan temprano como la propia petición.
Qué se registra
Cuatro clases de evento, un registro: registrado en secuencia, no ensamblado después del hecho:
- Prompts — Las peticiones en lenguaje sencillo hechas a la plataforma: el verdadero inicio de cada cambio, capturado en lugar de perderse en una ventana de chat.
- Merges con contexto de revisión — Guardrails mapea el código en áreas de negocio, detecta cambios de riesgo, aplica políticas en lenguaje sencillo y registra la revisión humana, dejando un registro de auditoría tras cada merge.
- Despliegues — Qué se publicó y cuándo, conectando los cambios aprobados con lo que realmente corre frente a los usuarios.
- Acciones de administración — Cambios de identidad, acceso y configuración, incluidos eventos de aprovisionamiento de SSO y SCIM, así las revisiones de acceso y de cambios se basan en el mismo registro.
- De solo adición por diseño — El registro se acumula; las entradas no se editan in situ. Lo que leen los revisores es la secuencia tal como ocurrió.
Exportación y revisión
La evidencia que no puedes extraer es evidencia que no tienes. El registro se puede exportar para revisión de auditoría, así tu equipo puede llevar los registros a sus propios papeles de trabajo y proceso de retención en lugar de capturar la pantalla de una interfaz de proveedor. Durante la evaluación, pide dos cosas: una demostración en vivo donde eliges un cambio real y lo trazas de principio a fin, y una exportación de esa misma secuencia para que tus auditores vean el formato con el que realmente trabajarían. Pregunta también quién puede ejecutar exportaciones y cómo se registran los propios eventos de exportación: una buena historia de registro incluye la historia de acceso al propio registro.
Para la respuesta a incidentes, el mismo registro sirve a un dueño distinto. Cuando algo se rompe o parece incorrecto, los responsables reconstruyen la secuencia desde el prompt hasta el despliegue sin esperar a que alguien recuerde qué se pidió y aprobó. La evidencia que satisface a un auditor en la revisión trimestral es la evidencia que acorta la línea de tiempo de un incidente en la semana mala.
Cómo se desarrolla una solicitud de auditoría
Un recorrido concreto, usando el registro de la forma en que lo harían tus auditores:
1. Delimita la pregunta
Un auditor pregunta sobre un cambio: quién lo inició, qué tocó, quién lo aprobó, cuándo llegó a producción.
2. Extrae el registro
Localiza la secuencia: prompt, cambio resultante, política de Guardrails y registro de revisión, evento de despliegue.
3. Muestra la revisión
El registro del merge muestra la política en lenguaje sencillo que se aplicó y la revisión humana que registró Guardrails, respondiendo directamente a la pregunta de aprobación.
4. Exporta la evidencia
Exporta los registros relevantes a los papeles de trabajo de la auditoría, así el hallazgo descansa en registros en lugar de en el recuerdo.
5. Cierra el círculo
Como las acciones de administración están en el mismo registro, las preguntas de seguimiento sobre quién tenía acceso en ese momento se responden desde la misma fuente.
Tipos de evento y por qué le importan a los revisores
| Tipo de evento | Qué se registra | Por qué le importa a los revisores |
|---|---|---|
| Prompt | La petición en lenguaje sencillo hecha a la plataforma | El origen real de un cambio asistido por IA |
| Merge | Detección de cambio de riesgo, política aplicada, revisión humana registrada | Evidencia de aprobación tras cada merge |
| Despliegue | Qué se publicó y cuándo | Conecta las aprobaciones con la realidad de producción |
| Acción de administración | Cambios de identidad, acceso y configuración | Evidencia para revisiones de acceso y cambios privilegiados |
Notas de verificación
El registro es un control que puedes ver operar: durante la evaluación, haz un cambio a través de la plataforma y luego encuéntrate en el registro. Para evidencia escrita, los informes SOC 2 Tipo II están disponibles bajo NDA, y el paquete de seguridad, a petición vía la página de contacto, cubre la arquitectura de registro y los detalles de retención. Si tu marco de auditoría tiene requisitos particulares de retención o formato, plantéalos por escrito al equipo enterprise durante las compras.
Un hábito que vale la pena adoptar de los equipos que auditan bien: elige un cambio real por mes y trázalo de principio a fin como simulacro. Mantiene el músculo de auditoría en forma, saca a la luz huecos mientras son baratos de corregir, y convierte la auditoría anual en la repetición de algo rutinario en lugar de una carrera contrarreloj.
Preguntas frecuentes
¿Pueden los administradores editar o eliminar entradas del registro de auditoría?
El registro es de solo adición por diseño: las entradas se acumulan en lugar de editarse in situ. Para el detalle de arquitectura detrás de esa propiedad, solicita el paquete de seguridad y, bajo NDA, el informe SOC 2 Tipo II que cubre los controles relevantes.
¿Los prompts de IA realmente forman parte del registro de auditoría?
Sí. El registro abarca prompts, merges, despliegues y acciones de administración, así el registro de un cambio empieza en la petición en lugar de en el commit. Durante la evaluación puedes trazar un prompt hasta su despliegue.
¿Cuánto tiempo se retienen los registros de auditoría?
Los detalles de retención pertenecen por escrito, no a una página de marketing: se cubren en el paquete de seguridad y se pueden abordar en tu acuerdo. Indica el requisito de retención de tu marco durante las compras y obtén la respuesta documentada.
¿Podemos llevar el registro a nuestra herramienta de SIEM o GRC?
El registro se puede exportar para revisión de auditoría. La ingesta en tu pila específica de SIEM o GRC es una cuestión de integración: describe tu pipeline al equipo enterprise y confirma el flujo de trabajo durante la evaluación en lugar de asumirlo.
¿Quién puede leer el registro de auditoría?
El acceso al registro se rige por el control de acceso basado en roles, así la visibilidad de auditoría es un rol que tu workspace asigna deliberadamente. Los cambios de acceso son en sí mismos acciones de administración, registradas en el mismo registro al que conceden acceso.