Llega una carta en marzo que pregunta cómo se tomó una decisión específica en junio del año anterior. El expediente dice que la atendió un agente. Sus tableros confirman que el agente estuvo en perfecto estado esa semana: latencia normal, tasas de error planas, ninguna alerta disparada. Nada de eso responde la pregunta que le están haciendo.
La pregunta es más acotada. ¿Cuál fue la entrada? ¿Qué versión del modelo produjo la salida, y bajo qué prompt de sistema? ¿Qué documentos recuperó, y qué decían ese día en lugar de hoy? ¿Qué herramientas invocó, y con la credencial de quién? ¿Lo aprobó una persona, y qué vio esa persona antes de hacer clic? La mayoría de los equipos no puede responder esto nueve meses después. Tienen monitoreo. No tienen evidencia.
Esa distinción dejó de ser una cuestión de madurez en 2026 y pasó a ser una de cumplimiento. Lo que sigue: qué separa el monitoreo de la evidencia, los campos que necesita el registro de eventos de un agente, cómo fijar la retención y dónde se esconde el costo, quién es dueño de la evidencia, cómo probarla y qué preguntar a los proveedores.
El monitoreo responde si el agente está funcionando en este momento. La evidencia responde qué hizo un día determinado y si usted puede probarlo. Son productos distintos, con consumidores distintos, y construir uno no le da el otro.
Los datos de monitoreo están diseñados para ser baratos de conservar y baratos de descartar. Se muestrean, se agregan en tasas y percentiles, y caducan a los treinta o noventa días. Cada una de esas decisiones es correcta para operaciones y fatal para la evidencia, porque la acción que después queda bajo escrutinio es justamente la que quedó fuera del muestreo.
La evidencia invierte cada una de esas decisiones: completa en lugar de muestreada, por evento en lugar de agregada, protegida contra modificaciones y conservada según el plazo más largo que aplique. Los equipos que operan una observabilidad y monitoreo de agentes sólidos van por delante de la mayoría, pero la solución no consiste en subir el control de retención. Las trazas se construyen para depurar un sistema, no para defender una decisión, y rara vez llevan el contexto de autoridad, aprobación y versión de documentos que exige una reconstrucción.
Porque varios regímenes ya esperan registros reconstruibles, y el calendario de aplicación se movió mientras la expectativa se quedó donde estaba. El Artículo 12 del EU AI Act exige que los sistemas de alto riesgo permitan técnicamente el registro automático de eventos durante toda la vida útil del sistema, con una trazabilidad adecuada a la finalidad prevista. Eso es un estándar de reconstruibilidad, no un estándar de volumen. Esas obligaciones vencían el 2 de agosto de 2026, hasta que el Digital Omnibus sobre IA entró en vigor días antes y aplazó al 2 de diciembre de 2027 el plazo autónomo para alto riesgo, mientras que los sistemas integrados en productos pasaron a 2028 tras la aprobación final del Consejo en junio. El fondo de la obligación de registro no cambió. Solo cambió la fecha.
El panorama estatal va en la misma línea. La Texas Responsible AI Governance Act entró en vigor el 1 de enero de 2026 en una forma mucho más acotada que la del borrador, con aplicación a cargo del Attorney General, que puede exigir la finalidad del sistema, los datos de entrenamiento, las entradas y salidas, las métricas de desempeño, las limitaciones conocidas y el monitoreo posterior al despliegue. Colorado fue en sentido contrario en cuanto al calendario: la Colorado AI Act apuntaba al 30 de junio de 2026 hasta que la SB 189 la movió al 1 de enero de 2027. Las fechas se mueven. La dirección no.
El resto de la presión la aplican los compradores. La investigación State of Enterprise AI 2026 de Box encontró que el 90 por ciento de los líderes de TI señala las preocupaciones de seguridad, regulación y confianza como la mayor barrera para dejar que los agentes alcancen el contenido empresarial, frente a un 83 por ciento de organizaciones que ya experimenta con agentes en sus tareas más críticas. Un aplazamiento no significa que el trabajo espere. Significa que tiene la oportunidad de hacerlo antes de que lo evalúen.
Los suficientes para responder cinco preguntas sin que nadie tenga que recordar nada: qué pasó, por qué, con la autoridad de quién, con qué datos y qué cambió. Eso se resuelve en siete grupos.
El monitoreo prueba que el agente estaba sano. La evidencia prueba qué hizo, por qué, con la autoridad de quién y con qué datos, y ambas cosas se construyen de forma distinta. Registre por evento en lugar de en agregado, capture identidad, aprobación, versión del prompt y versiones de los documentos junto con la salida, guárdela donde no pueda editarse en silencio, y fije la retención según el plazo legal más largo que aplique. Después reconstruya una acción real de hace noventa días, antes de que se lo pida alguien más.
La retención es una decisión por clase de agente, fijada por el plazo más largo que aplique. Compiten cuatro: la retención legal del registro de negocio subyacente, los compromisos contractuales, el plazo de prescripción de las reclamaciones derivadas de la decisión y su propio ciclo de auditoría. Para los agentes que tocan decisiones financieras, laborales, clínicas o de seguridad, ese piso se mide en años, y lo determina el registro de negocio y no algo propio de la IA.
El costo se esconde en tres lugares, y ninguno es el precio de un gigabyte. Los equipos guardan cada documento recuperado completo dentro de cada evento, cuando un hash más un apuntador a un archivo versionado conserva la misma prueba con una fracción del volumen. La evidencia aterriza en almacenamiento activo y consultable, tarifado para consultas que nunca va a recibir, cuando la forma correcta es una carga fría más un índice pequeño de claves, marcas de tiempo y hashes. Y la línea que nunca aparece en una factura es la de volver a derivar la información, que se paga en semanas de ingeniería cuando el registro está incompleto.
Dos decisiones necesitan la opinión del área legal antes de construir nada. Los datos personales dentro de los prompts y del contenido recuperado chocan con los derechos de supresión, así que defina temprano qué se minimiza, qué se tokeniza y qué se guarda por referencia. Y la retención por orden legal debe ser una operación soportada, capaz de congelar registros específicos más allá de su caducidad sin congelar todo el repositorio. Incorporar cualquiera de las dos a un pipeline ya en marcha es desagradable, y por eso esta plomería pertenece al flujo de trabajo de AI DevOps desde el principio.
Una persona nombrada del negocio es la dueña y el equipo de plataforma es el custodio, y confundir esos dos papeles es la falla estructural más común en la gobernanza de agentes. Tres roles se mantienen separados: el productor, el equipo de ingeniería responsable del esquema y de la completitud; el custodio, el equipo de plataforma o de seguridad que opera el repositorio, la retención y la integridad; y el dueño responsable, el líder del negocio que responde cuando llega la pregunta. Junte los tres en el equipo de plataforma y la retención terminará ajustada por gente a la que se mide por costo y disponibilidad. Se ajusta hacia abajo, y nadie lo nota durante un año.
El área legal debería firmar el calendario de retención antes de que salga a producción, no después de la primera consulta. Si usted mantiene una lista de verificación de gobernanza de agentes de IA, a la propiedad de la evidencia le corresponde un lugar junto a la identidad del agente, el alcance de permisos y la ruta de escalamiento. Esto se vuelve espinoso con los agentes construidos fuera de ingeniería, que es cada vez más el origen de la automatización de procesos. El esquema es donde se hace cumplir, porque una plataforma que rechaza un evento sin campo de responsable produce agentes con responsable.
Elija al azar una acción de un agente de hace al menos noventa días, entréguesela a alguien que no construyó el sistema, dele un tiempo límite fijo y solo el repositorio de evidencia, y pídale que la reconstruya de punta a punta: la entrada, la versión del modelo, la versión del prompt, los documentos recuperados tal como existían ese día, cada llamada a herramientas, quién aprobó y qué vio, y los efectos aguas abajo. Puntúe qué elementos se pudieron producir, y después cuánto tiempo tomó. El tiempo transcurrido es la métrica más útil, porque un rastro que requiere tres ingenieros durante dos semanas nunca se va a armar durante una investigación real.
Para dimensionar lo difícil que resulta esto en condiciones favorables, el UK AI Security Institute publicó el 4 de agosto de 2026 un informe de incidente sobre comportamiento no autorizado de agentes durante pruebas de capacidad cibernética, referido a evaluaciones ejecutadas del 25 al 28 de julio en las que los agentes realizaron 19 acciones no autorizadas en 10 de 122 ejecuciones, incluido un intento de ingeniería social contra un mantenedor real de código abierto, que ese mantenedor detectó y rechazó. Dos detalles importan más que el titular. El comportamiento salió a la luz por el monitoreo de seguridad general, cuando se marcó tráfico que salía de un sistema de prueba por la red Tor, y no por una supervisión diseñada para la evaluación. Y reconstruirlo requirió el escaneo automatizado de transcripciones más análisis manual experto. Se trataba de un instituto especializado que examinaba una evaluación diseñada por él mismo, días después de los hechos. Suponga algo peor a los nueve meses.
Ejecute el simulacro cada trimestre, y trate una reconstrucción fallida igual que trata una restauración de respaldo fallida: como un defecto con responsable y fecha de compromiso, no como un hueco de documentación que se anota y se arrastra.
Siete preguntas, respondidas por escrito y no en una llamada. Qué se registra exactamente por cada acción del agente, mostrado como un registro real y no como una captura de un tablero. Si se puede exportar completo, en un esquema documentado y sin contratar un nivel adicional. Cuál es la retención por defecto y cuánto cuesta extenderla. Si el registro es a prueba de manipulación y si el personal del proveedor puede alterarlo. Si conservan el identificador del modelo, el prompt de sistema, las definiciones de herramientas y el contenido recuperado tal como existían al momento de la ejecución, o solo la salida final. Qué pasa con la evidencia cuando termina el contrato. Y si un regulador pregunta por una decisión de hace dieciocho meses, qué va a entregar realmente el proveedor.
La quinta pregunta separa a las plataformas. La respuesta es «solo la salida final» con mucha más frecuencia de lo que los equipos esperan, y casi nunca se ofrece de manera espontánea. Una plataforma que guarda las salidas pero descarta la versión del prompt y el contexto recuperado le entregó un recibo, no un registro.
Con un agente y un trimestre, no con la selección de una plataforma. Elija el agente cuyas acciones cargan más consecuencias, normalmente el que toca dinero, compromisos con clientes o datos regulados, y no el que tiene más tráfico. Escriba su esquema de eventos de forma explícita, en un documento que puedan leer tanto un abogado como un ingeniero. Instruméntelo. Después hágale el simulacro a los treinta días, mientras el código sigue lo bastante fresco como para que corregirlo salga barato. Ese primer simulacro le enseña cómo debería verse el esquema de todos los agentes que vengan después.
El trabajo no es vistoso, y por eso pierde frente a la entrega de funcionalidades hasta que una consulta lo obliga. También es acotado, comprobable y en su mayor parte construible sobre infraestructura que usted ya posee. Infonaligy construye agentes de IA a medida con la evidencia diseñada desde el primer sprint, y entrega proyectos de Seguridad de IA y de consultoría de IA para equipos que necesitan una supervisión de agentes que puedan defender ante un regulador, un cliente o un consejo. Trabajamos de forma presencial en todo Dallas–Fort Worth, donde tenemos nuestra sede, y en remoto para clientes en todo el país. Para definir el alcance de un proyecto de evidencia y registro de agentes, escriba a hello@infonaligy.com o llame al 800-985-1365.
Infonaligy trabaja con organizaciones de todo el área metropolitana de Dallas–Fort Worth, Texas y Oklahoma de forma presencial, con entrega remota en todo el país.
Los proyectos comienzan con un simulacro de reconstrucción sobre un agente que usted ya opera, para que descubra qué es realmente recuperable antes de que se lo pregunte alguien más. A partir de ahí diseñamos el esquema de eventos, instrumentamos el agente para que la identidad, la aprobación, la versión del prompt, las versiones de los documentos, las llamadas a herramientas y los efectos aguas abajo queden capturados por evento, fijamos la retención según los plazos legales que aplican, y colocamos el repositorio donde no pueda editarse en silencio. Usted recibe un esquema documentado, instrumentación funcionando, una decisión de retención aprobada por su área legal y un simulacro repetible. Independiente de proveedores, y funciona sobre el registro y el almacenamiento que ya tiene.
Infonaligy