Tu gobernanza de TI se hizo para software que no cambia. Los agentes cambian a diario.
Ya tienes gobernanza de TI, y es buena en aquello para lo que se construyó: software determinista, entregas con control de cambios, la misma entrada produciendo la misma salida. Te ha servido bien durante décadas, y el instinto de extenderla a los agentes es razonable.
Solo que un agente no es nada de lo que esa gobernanza presupone. Es probabilístico, se desvía con cada actualización de modelo y actúa sobre contexto en vivo que ninguna nota de versión recoge. Adaptar a un sistema que cambia a diario un control de cambios diseñado para código fijo no se sostiene, y fingir lo contrario es cómo un proyecto con aspecto de gobernado produce un sistema ingobernable.
El error no es que la gobernanza de TI sea débil. Es que le estás pidiendo que responda a una pregunta que nunca se diseñó para hacer. El control de cambios pregunta "¿qué cambió, quién lo aprobó y cuándo lo entregamos?". Esa pregunta no tiene respuesta cuando el cambio es una actualización de modelo que no entregaste y el comportamiento se movió solo.
La unidad de gobernanza tiene que cambiar
La gobernanza determinista gobierna entregas. La gobernanza de agentes tiene que gobernar decisiones.
Suena a sutileza. Es todo el asunto. En un mundo centrado en la entrega, una vez que una build está probada y entregada, se asume que cada ejecución de esa build es correcta porque la build es correcta. La unidad que apruebas es la entrega, y la entrega es estable.
Un agente no tiene entrega estable que aprobar. Dos ejecuciones del mismo agente sobre el mismo documento pueden diferir, y el modelo que hay detrás puede ser otro la semana que viene. Así que lo que gobiernas no puede ser la build. Tiene que ser cada decisión que toma el agente: qué decidió, bajo qué autoridad, sobre qué datos y contra qué política. La gobernanza pasa de ser un gate que atraviesas una vez a una disciplina que corre de forma continua, en cada decisión, durante toda la vida del sistema.
Eso no es un PDF de política. Es control de ingeniería con un dueño y un rastro de auditoría.
Los agentes se ganan la autonomía, no empiezan con ella
El mecanismo central es la autonomía graduada. Un agente no entra en producción autónomo. Sube una escalera, y los evals, las pruebas que miden si supera un listón, son el gate de confianza en cada peldaño.
| Peldaño | Rol | Qué significa | Ejemplo |
|---|---|---|---|
| Sombra | El agente observa | Propone, nunca actúa. Los evals base fijan el listón. | Redacta el memorando de crédito; una persona escribe el que sale. |
| Supervisado | Persona en el circuito | Solo actúa después de que una persona apruebe cada paso. | Prepara el pago; una persona pulsa aprobar. |
| Guiado | Persona sobre el circuito | Actúa de forma autónoma; las personas tratan las excepciones. | Da de alta clientes de extremo a extremo; las personas revisan los casos señalados. |
| Total | Autónomo | Corre de extremo a extremo dentro de un radio de acción acotado y documentado. | Concilia libros durante la noche; las decisiones con consecuencia siguen necesitando aprobación. |
Lee la escalera con atención, porque dos propiedades la convierten en algo más que un cuadro de madurez.
Primera, un peldaño se gana, no se programa. El agente sube solo cuando supera el listón de evals del siguiente nivel, y el listón se fija de antemano, sobre la línea base del propio proceso. Es lo contrario de un plan de lanzamiento que aceleras para cumplir una fecha.
Segunda, un peldaño se pierde automáticamente. Si la monitorización de drift detecta que el rendimiento se ha salido del listón, el agente se degrada sin esperar a que una persona lo note. La autonomía no es un permiso que concedes una vez y olvidas. Es un estado que el sistema tiene que justificar de forma continua.
A medida que el agente se demuestra, las personas pasan de aprobadores a gestores de excepciones. Es una ganancia de eficiencia real, y está acotada por la responsabilidad, por diseño. La matriz de autonomía y el kill-switch están documentados, probados y llevan un registro inmutable de intervenciones. El radio de acción de un agente "Total" no es "lo que decida hacer". Es un alcance escrito y acotado, con las decisiones con consecuencia siempre encaminadas a una persona.
Los evals son el listón de confianza, no una casilla de lanzamiento
La palabra "eval" se usa con ligereza, así que conviene ser concreto sobre qué hace aquí.
Un eval no es una prueba de aceptación única que corres antes de entrar en producción y luego archivas. Es la medición permanente que decide, de forma continua, si el agente merece la autonomía que tiene ahora mismo. Es lo que convierte "creemos que funciona" en "superó el listón a las 09:14 de hoy, y esta es la puntuación que autorizó este peldaño".
Esto importa porque los sistemas probabilísticos se degradan en silencio. Una actualización de modelo mejora un comportamiento y empeora otro. Un cambio en la distribución de las entradas, nuevos formatos de documento, un nuevo patrón de fraude, aleja al agente de los casos con los que se validó. Sin un eval en vivo y monitorización de drift, nada de eso es visible hasta que llega a un cliente o a un regulador. Con ellos, la degradación es automática y el registro muestra exactamente cuándo y por qué.
Evals más monitorización de drift son lo que te permite decir la frase que un comité de riesgos necesita oír: la autoridad del agente no se presupone, se mide, y se revoca en cuanto la medición baja.
Esto va junto a tu gobernanza de TI, no encima
El objetivo no es sustituir ITIL. Es nombrar responsabilidades con la claridad suficiente para que nadie asuma que la otra capa está cubriendo un hueco.
| Asunto | Tu gobernanza de TI | Gobernanza de agentes |
|---|---|---|
| Entregas deterministas, infraestructura, accesos | Es dueña | Consume |
| Drift de modelo y de comportamiento, día a día | No se diseñó para eso | Es dueña (evals, monitorización de drift) |
| Evidencia por decisión | No es su unidad de trabajo | Es dueña (rastro de evidencias) |
| Autonomía y radio de acción | N/A | Es dueña (escalera, kill-switch) |
Tu gobernanza de TI sigue haciendo aquello en lo que es excelente: infraestructura, accesos, entregas deterministas. La capa de gobernanza de agentes se pone a su lado y asume lo que la gobernanza determinista nunca se construyó para sostener: drift, evidencia por decisión y la escalera de autonomía. Dos sistemas, costuras limpias, ninguna cobertura presupuesta.
El modo de fallo que hay que evitar es el silencioso: un proyecto que parece gobernado porque pasó por el comité de cambios normal, y es ingobernable en la práctica porque el comité no tiene forma de ver una actualización de modelo ni de medir el drift. Pasó el gate equivocado.
Así que la pregunta que llevar a tu próxima revisión no es "¿esto pasó por control de cambios?". Es para un sistema que cambia a diario, quién es dueño del drift, dónde está la evidencia por decisión, y podemos degradar a un agente automáticamente en cuanto se salga de su listón. Si la respuesta honesta es "nuestro proceso de entregas asume que sigue probado", todavía no tienes gobernanza de agentes. Tienes gobernanza determinista apuntada a un sistema probabilístico, y las dos no encajan.
Si quieres ver cómo es la autonomía ganada en uno de tus procesos, reserva una reunión.