En IA, "gobernanza" quiere decir demasiadas cosas. Acá no hablo de marcos de ética, de comités de riesgo de modelos ni de las librerías de guardrails que filtran prompts y respuestas. Hablo de algo más acotado: las reglas deterministas que deciden si una acción que propone un agente se ejecuta o no (una transferencia, la aprobación de un siniestro, un cambio en el registro de un cliente) y la evidencia de lo que pasó.
Este año, la idea de un modelo demasiado capaz para liberarlo dejó de ser hipotética. En abril, Anthropic entregó Claude Mythos Preview sólo a un grupo limitado de defensores de ciberseguridad y de proveedores de infraestructura de software crítica, a través de Project Glasswing, y dijo que no piensa ponerlo a disposición del público general. En junio lanzó dos modelos que comparten el mismo modelo de base: Mythos 5, restringido a los socios de Glasswing, y Fable 5, abierto a todos, con clasificadores que derivan a un modelo menos capaz los pedidos sobre ciberseguridad, biología y química, o destilación. Tres días después, el gobierno de Estados Unidos les aplicó controles de exportación a los dos. Anthropic no tenía forma confiable de verificar la nacionalidad en tiempo real, así que suspendió los dos modelos para todos sus usuarios. Fable 5 volvió el 1 de julio, después de que Anthropic entrenara un clasificador de seguridad mejorado y se levantaran los controles. Mythos 5 ya había vuelto para un grupo de organizaciones de Estados Unidos, después de que el gobierno lo aprobara el 26 de junio.
Si cada una de esas decisiones fue acertada lo discuten otros. Para quien construye sobre estos modelos, la lección es estructural: lo que el modelo hace y lo que no hace lo decide otro, por sus propias razones y con sus propios tiempos.
Dos planos, dos dueños
En un despliegue de agentes hay dos clases de seguridad, y cada una tiene su dueño.
La seguridad del proveedor vive dentro del modelo y a su alrededor: entrenamiento, rechazos, políticas de uso, límites de capacidades, restricciones de acceso. Es del laboratorio. Sirve para que el modelo no contribuya a los daños que le importan al laboratorio, como armas biológicas, ciberataques o abuso masivo. Es un trabajo serio y valioso, y nada de lo que sigue va en su contra.
La gobernanza del operador vive en tu sistema: qué acciones puede tomar un agente, para qué cliente, con qué límites, con la confirmación de quién y con qué registro. Es tuya. Sirve para que tu negocio cumpla lo que les debe a sus clientes, a sus auditores y al regulador que le da la licencia.
El error es tomar la primera como un anticipo de la segunda. Que un modelo se niegue a explicar cómo sintetizar un patógeno no dice nada sobre si va a respetar un límite de transferencia, saltearse un paso de KYC o aprobar un siniestro fuera de política. Esos riesgos son tuyos, y nadie le pidió al laboratorio que los cargue.
Por qué la seguridad del proveedor no puede sostener tu cumplimiento
Tres propiedades la vuelven el lugar equivocado para anclar tus obligaciones. Ninguna es una falla del laboratorio: salen de que el sistema es suyo.
Cubre sus riesgos. Un laboratorio calibra sus salvaguardas contra daños catastróficos y de propósito general. Tus obligaciones son específicas y locales: las normas de un banco central sobre pagos electrónicos, las facultades de una aseguradora para liquidar siniestros, una ley de protección de datos. Ningún laboratorio va a entrenar su modelo con tu política de crédito, y aunque lo hiciera, no querrías que tu política de crédito dependiera del criterio de un modelo.
Corre con su calendario. Las salvaguardas se endurecen, las capacidades pasan a programas de acceso restringido, los modelos se discontinúan y, como se vio en junio, el acceso se puede suspender por razones que no controlan ni vos ni el laboratorio. Cada cambio llega con los tiempos del proveedor, y un control en el que se apoya tu auditor no puede moverse cada vez que un proveedor publica una actualización.
No deja evidencia que puedas entregar. Cuando un modelo se niega a hacer algo, ese rechazo es un comportamiento probabilístico. No deja un registro que tu regulador vaya a aceptar, y no podés demostrar que ayer habría pasado lo mismo. "El modelo no haría eso" no responde una observación de auditoría.
Si cambia el modelo, ¿qué debería cambiar con él?
Supongamos que mañana tu proveedor restringe una capacidad, discontinúa la versión que usás o corta el acceso por tres semanas, y pasás a otro modelo. Pueden cambiar dos cosas, y conviene no mezclarlas.
La conversación puede empeorar. Los modelos no entienden igual de bien a un cliente, no manejan igual la ambigüedad ni sostienen igual un tono. El reemplazo puede atender peor algunos casos de uso, por lo menos hasta que se ajusten los prompts. Es un costo real.
Lo que se ejecuta no puede cambiar en nada. Los límites, las confirmaciones exigidas, las precondiciones, quién puede hacer qué por quién y el registro de lo que pasó no deberían depender de qué modelo propone. Si cambiar de modelo puede cambiar lo que tu agente tiene permitido hacer, tu gobernanza era, desde el principio, un efecto secundario del modelo de otro.
Un sistema bien construido acepta el primer riesgo y elimina el segundo. La calidad del modelo pasa a ser una cuestión de producto que podés manejar, y el cumplimiento sigue siendo una propiedad de tu sistema.
El diseño que pasa la prueba
Pasar esa prueba exige tres decisiones, y Zarel está construido sobre ellas.
El modelo propone y nunca ejecuta. El LLM funciona como interfaz: entiende el pedido y propone una acción. Su salida entra al sistema como dato no confiable. Se convierte en una intención tipada, y nada se ejecuta hasta que la intención y sus campos coinciden con lo que declara el contrato.
El contrato declarado decide, y el runtime lo hace cumplir. Lo que un agente puede hacer está en un contrato que el operador escribe y versiona: capacidades, límites, precondiciones, confirmaciones exigidas. Un pipeline determinista contrasta cada propuesta con ese contrato, y una acción que el contrato no declara se rechaza. El contrato no sabe qué modelo mandó la propuesta.
El registro se puede verificar, además de leer. Cada transición de estado, cada paso de un flujo y cada decisión sobre una confirmación se escriben como un evento encadenado por hash, y también cada veredicto sobre una escritura propuesta, rechazos incluidos. Cada evento indica qué versión del contrato lo decidió. Hay checkpoints firmados que cubren la cadena, y cualquiera que reciba un paquete de evidencia puede verificarlo offline con las claves publicadas. En un despliegue self-managed, las claves de firma las tiene el cliente, así que el proveedor no puede firmar checkpoints en su nombre. Ese despliegue se lo ofrecemos a design partners y todavía no corrió en producción. La evidencia tiene la misma forma cualquiera haya sido el modelo que proponía ese día.
Nada de esto vuelve innecesaria la seguridad del proveedor: sigue siendo deseable un modelo que se niegue a ayudar a fabricar un arma. Pero conservar tu licencia no debería depender de eso.
La pregunta que hay que hacerse
Los laboratorios van a seguir tomando decisiones difíciles sobre lo que pueden hacer sus modelos, y las van a seguir revisando con sus propios tiempos.
Para un operador regulado, la pregunta es más simple: si mañana cambiara tu modelo, ¿podrías mostrarle a tu auditor que nada de lo que tus agentes tienen permitido hacer cambió con él?
Nicolás Moreno construye Zarel: operaciones de IA gobernadas, donde la IA propone y el contrato dispone.