De los modelos a los agentes: redefiniendo las tres líneas de defensa.

La IA agente rompe con las guías de gobernanza diseñadas para el software convencional y los modelos tradicionales, pero esa afirmación resulta más evidente en un caso concreto. Los años de trabajo en MLOps, que abarcan inventarios de modelos, pipelines de validación, monitoreo de desviaciones y flujos de trabajo de aprobación en entornos empresariales y de servicios financieros, no se descartan cuando una organización adopta LLMs y agentes. Lo que cambia es más limitado y específico de lo que la mayoría de las personas imagina.

Imagínese un equipo de gestión de riesgos de modelos que maneja una solicitud de ingreso habitual. El formulario plantea las preguntas habituales sobre los datos de entrenamiento, el número de versión, el estado de aprobación y la fecha de la última verificación de desviación, y el equipo ya ha procesado muchas de ellas. Luego aparece la descripción del sistema: cuatro agentes que colaboran entre sí, seis herramientas compartidas entre ellos, un índice de recuperación que se reconstruye cada día, y un resultado generado por una cadena en la que cada paso individual parecía correcto. Nada en el formulario encaja.

Una encuesta de McKinsey AI Trust de 2026 que abarca unas quinientas organizaciones muestra una imagen similar: aproximadamente un tercio de las empresas afirma que su madurez en materia de gobernanza es adecuada para los agentes autónomos que ya están en funcionamiento. El resto sigue utilizando el antiguo formulario de ingreso y espera que sea suficiente. Por lo general no lo es, por lo que la tarea útil es identificar dónde falla.

Qué ya cubre el programa existente

La gobernanza de MLOps es el conjunto de controles que mantienen fiable un modelo tradicional de aprendizaje automático desde su entrenamiento hasta su retiro. En la práctica:

• Versionado de modelos, para que siempre quede claro qué modelo se ejecuta en producción y por qué.
• Monitoreo de desviaciones que detecta el deterioro del rendimiento a medida que cambian los datos de entrada.
• Trazabilidad de los datos hasta los conjuntos de entrenamiento y validación.
• Procesos de aprobación antes de cualquier lanzamiento a producción.
• La disciplina de CI/CD y gestión de cambios que se espera de cualquier software en producción, la cual forma parte de este programa y no existe por separado.

Ninguno de estos controles se aplica automáticamente. Alguien debe hacerse responsable de cada uno de ellos, y otra persona debe verificar que ese responsable haya cumplido con su tarea.

La responsabilidad generalmente se asigna a través de las tres líneas de defensa, un marco que los bancos y otras industrias reguladas han utilizado durante mucho tiempo para distribuir la responsabilidad. Un detalle importante: el Instituto de Auditores Internos lo renombró como Modelo de Tres Líneas en 2020, desplazando el énfasis hacia la creación de valor en lugar de la mera defensa. Los círculos especializados en finanzas y riesgos de modelos siguen utilizando el término tres líneas de defensa, al igual que este texto, aunque el nombre oficial haya cambiado.

En un programa convencional de MLOps, la división se presenta de la siguiente manera:

• La primera línea, que abarca el producto, los datos e ingeniería, se encarga del desarrollo, pruebas, despliegue y documentación de los modelos.
• La segunda línea, que se ocupa del cumplimiento y los riesgos, establece políticas para el uso de los modelos, monitorea la existencia de sesgos y revisa las aplicaciones de alto riesgo antes de su lanzamiento.

La tercera línea, auditoría interna, tiene la descripción más limitada: confirmar de forma independiente que las dos primeras líneas realizan lo que afirman, sin tener que crear ni aprobar nada por sí misma.

Esta estructura está madura y es bien comprendida, y funciona para los sistemas para los cuales fue diseñada, es decir, modelos cuya estructura es fija, se valida una vez y se monitorea entre ciclos de revisión.

Cómo debe cambiar cada línea para los agentes

La gobernanza de AgentOps parte de las mismas tres líneas, pero la sustancia que cada una inspecciona difiere, ya que los sistemas se comportan de manera distinta. Las diferencias principales se reducen a cinco diferencias específicas.

Un artefacto se convierte en muchos. Un modelo clásico consiste en una sola entidad a versionar. El sistema de cuatro agentes es un conjunto: el modelo base, cuatro instrucciones para el sistema, seis definiciones de herramientas y una capa de recuperación que se actualiza por sí sola. Cada uno de estos elementos puede modificar el comportamiento, por lo que es necesario versionar y probar cada componente. Esto se asemeja menos a una entrada de registro y más a instrucciones y esquemas de herramientas tratados como código fuente, con control de versiones, revisión de solicitudes de integración y pruebas canario contra un conjunto de datos aparte antes de promover cualquier cambio. Al solo hacer seguimiento del modelo, quedan aproximadamente tres cuartas partes de las características de comportamiento sin gestionar.

La salida correcta se encuentra dentro del rango aceptable. Si se proporciona el mismo input a un modelo tradicional, este devuelve la misma salida, y por eso la validación es sencilla. Un LLM puede generar dos respuestas diferentes pero defendibles en distintas ejecuciones. Por lo tanto, la segunda línea deja de preguntar si una respuesta es correcta y comienza a preguntar si las respuestas permanecen dentro de un rango aceptable la mayor parte del tiempo. Esto requiere una puerta de evaluación con umbrales definidos, como una tasa mínima de aprobación en un conjunto de pruebas etiquetado antes del lanzamiento, y un mecanismo de revisión humana cuando la confianza o las puntuaciones de evaluación bajen por debajo de un umbral establecido. Acordar qué se considera aceptable la mayor parte del tiempo para un caso de uso específico es un proyecto en sí mismo, no algo que se pueda completar en una tarde.

Un único propietario se convierte en una cadena. Un modelo aislado que realiza una predicción por sí solo tiene un propietario evidente. Un sistema con cuatro agentes no tiene ninguno. Cuando el resultado final es incorrecto pero ninguno de los pasos individuales lo fue, el diagnóstico requiere un registro de decisiones que capture las transferencias intermedias así como el producto final: las entradas de cada agente, cada decisión y lo que se transmitió. Al no contar con ello, nadie puede determinar qué agente es responsable, y las primeras y segundas líneas discuten al respecto después de un incidente en lugar de acordarlo de antemano.

El monitoreo de deriva no es el monitoreo del comportamiento. Las verificaciones de deriva comparan las predicciones con una línea de base conocida. No tienen en cuenta lo que hace un agente durante su ejecución: las herramientas que invoca, las acciones que realiza, ni si se mantiene dentro del alcance establecido. Las plataformas de observabilidad de agentes abordan este punto ciego al registrar todo el rastro de ejecución, incluyendo las llamadas a herramientas, los parámetros y la forma en que la salida de un agente alimenta al siguiente. Muchas de ellas dependen de estándares abiertos como OpenTelemetry, lo que permite que los rastros sean portables entre diferentes proveedores. En este sistema, el rastro es el único elemento a partir del cual un auditor puede reconstruir los eventos posteriormente. Sin él, la auditoría de la tercera línea se realiza sobre una caja negra y se denomina verificación independiente.

El reentrenamiento del calendario se convierte en un cambio continuo. Los modelos tradicionales se reentrenan según un horario establecido: mensualmente, trimestralmente, cada vez que se acumulan suficientes datos nuevos. Un sistema basado en RAG o en ajustes finos continuos puede modificar su comportamiento efectivo tan a menudo como se actualice su base de conocimientos, posiblemente a diario. Si la capa de recuperación se actualiza cada noche, una tercera línea diseñada para revisiones trimestrales verifica el sistema aproximadamente noventa veces menos seguido de lo que este cambia.

Donde se encuentran los dos programas

Al compararlos directamente, ambos programas comparten una estructura básica. Se aplican las mismas tres fases, y ambos requieren control de versiones, pruebas, revisiones y auditorías independientes. Las diferencias radican en la granularidad, la frecuencia y el objeto que cada uno inspecciona.

La gobernanza de MLOps no está equivocada en este caso. Sus preguntas se basaban simplemente en la premisa de que el comportamiento del modelo se mantiene estable entre las revisiones, y un sistema cuyo índice de recuperación se reconstruye cada noche se niega a permanecer estable durante tanto tiempo. Las cinco diferencias provienen precisamente del fracaso de esa premisa: lo que antes cambiaba mensualmente ahora puede cambiar diariamente, a veces sin que nadie toque el modelo en absoluto.

Cerrar esa brecha no requiere crear una nueva función de gobernanza desde cero. Exige ampliar las capacidades existentes con funciones que antes no eran necesarias, y ser honestos sobre el costo de cada una de ellas:

• Primera línea: control de versiones para prompts y herramientas, con pruebas canario antes de la implementación. Se trata principalmente de un cambio en las prácticas de ingeniería y no de la creación de un nuevo equipo.
• Segunda línea: una puerta de evaluación que establece los umbrales de aceptación, junto con una ruta escrita para la escalada de decisiones que involucran a varios agentes. Se trata de un proyecto real de redacción de políticas, y la primera fase implicará negociaciones reales con los departamentos legales y de cumplimiento.
• Tercera línea: herramientas de observabilidad en tiempo de ejecución y las habilidades necesarias para auditar un registro de decisiones en lugar de una tarjeta de modelo estática. Para la mayoría de las funciones relacionadas con el riesgo de modelos, esto significa contratar a alguien nuevo o realizar una formación intensiva, no simplemente marcar una casilla en un antiguo formulario de revisión.

Ninguno de estos elementos es opcional si el objetivo es determinar de manera fiable cuál de los cuatro agentes tomó la decisión.

Qué han dicho hasta ahora los reguladores

Ningún marco regulatorio ha logrado adaptarse completamente a la IA agentes, pero tres modelos existentes de diferentes industrias muestran hacia dónde se dirigen las cosas.

• La Ley de IA de la UE se aplica en todos los sectores. Las obligaciones de transparencia del artículo 50 entrarán en vigor el 2 de agosto de 2026, independientemente de lo que ocurra. Las obligaciones más estrictas del Anexo III relacionadas con riesgos elevados se aplicarán también en esa fecha inicialmente, pero el paquete Digital Omnibus propuesto, acordado en principio en mayo de 2026 y aún pendiente de adopción formal, retrasaría su aplicación hasta diciembre de 2027. Un calendario de cumplimiento debería indicar dicho retraso como pendiente.
• El enfoque de la FDA respecto a los dispositivos médicos con tecnología de IA es vertical y está centrado en el producto, y su herramienta principal es el Plan de Control de Cambios Predeterminado. Bajo este plan, la aprobación inicial ya autoriza ciertas actualizaciones de modelos posteriores, siempre y cuando se mantengan dentro de los límites de rendimiento establecidos. Incluye orientaciones sobre buenas prácticas de aprendizaje automático y un sistema de calidad orientado a la norma ISO 13485. En efecto, el control de cambios pasa a formar parte del proceso de aprobación, y no es una obligación añadida posteriormente.
• Las normas financieras son instructivas en parte por lo que excluyen. La guía interagencial de 2026 SR 26-2, que sustituyó a SR 11-7, excluye explícitamente a la IA generativa y agente de su ámbito formal. Un marco maduro reconoce que las herramientas diseñadas para una generación de modelos no se aplican automáticamente a la siguiente, y las empresas que operan bajo él ya están desarrollando mecanismos de gobernanza para los agentes por delante de los reguladores.

Ninguno de estos tres documentos funciona como plantilla para copiar. Leídos juntos, sugieren una dirección: cambiar los límites autorizados con antelación, los niveles de riesgo, y reconocer abiertamente la discrepancia entre las reglas actuales y el comportamiento de los agentes.

Volver al formulario de solicitud

El formulario de solicitud existente puede permanecer. Además, el equipo necesita un cuestionario separado para los sistemas multiagente, organizado en torno a las tres categorías en las que ya se basa, y debe tener en cuenta que responder con honestidad requiere un esfuerzo real.

¿En qué paso avanzará primero un programa? Probablemente en la gestión de versiones, ya que se asemeja a un problema de control de versiones que los ingenieros ya saben cómo resolver. La rendición de cuentas por decisiones en cadena probablemente será lo que tarde más en resolverse. Se trata de un problema de diseño organizacional disfrazado de aspecto técnico, y ninguna puerta de evaluación puede solucionarlo.

Leer más

• De los bucles de agentes a los grafos de flujos de trabajo: estado tipado, puertas de evidencia y recuperación limitada — Por qué los agentes de ejecución prolongada superan las capacidades de un único bucle, y cómo los nodos explícitos, aristas, artefactos tipados, transiciones verificadas y permisos por nodo los hacen confiables.
• LLMOps para un agente de tareas: rastreos de MLflow, evaluaciones y una puerta de CI — Crea un asistente de tareas de PydanticAI con FastAPI, rastrea su funcionamiento con MLflow, evalúa su rendimiento con herramientas de GenAI y evita regresiones en GitHub Actions, todo con modelos locales.

Memory a largo plazo buscable para agentes de ingeniería de datos — Cómo un sistema de ingeniería de datos multiagente dejó de volver a depurar los mismos fallos: captura automática, diarios con alcance definido, una categoría seleccionada y recuperación a nivel de contexto.