En la web, el agente hace push a main. En el código de consenso, ni lo intenta.

La pregunta que más me hacen los CTO de banca, sanidad y administración pública no es si dejar que los agentes de IA escriban código. Es hasta dónde dejarlos llegar antes de que alguien de cumplimiento pregunte quién aprobó ese commit.

Respondo desde el asiento de quien construye. En los últimos seis meses mi equipo ha sacado dos productos con agentes de IA en el circuito desde la primera tarjeta hasta el último despliegue: MintID, una cadena de identidad respaldada por KYC donde lo difícil es el consenso y la criptografía, y ZadQ, una capa de responsabilidad para pagos entre máquinas que se vende a entidades de pago y reguladas. Lo digo de entrada porque importa para lo que sigue: fundé MintID y soy el propietario del grupo que construye ambos. Si buscáis la opinión independiente, no es este artículo.

Lo que sí puedo daros es el mecanismo. No tenemos una política para el código asistido por IA. Tenemos una por radio de daño. Los mismos agentes, el mismo modelo, el mismo tablero de JIRA, y una correa cuya longitud la fija lo que se rompe si el agente se equivoca.

La correa la fija el radio de daño, no el modelo

Estos son los dos extremos, uno al lado del otro.

En la web pública de MintID —HTML y CSS puros, prerenderizada, sin backend, sin JavaScript en ejecución— el agente trabaja directamente sobre main, y un push a main despliega en producción. Sin ramas, sin worktrees. La puerta es mecánica: lint, tests, una comprobación de idiomas y un script de auditoría que tumba la build si sobrevive un <script> extraviado o falta un artefacto obligatorio. Si el agente se equivoca, una página se ve rara durante los minutos que tarda el siguiente push. Radio de daño: cosmético.

En el protocolo de MintID —Go sobre Cosmos SDK para el estado visible en consenso, Rust para el núcleo criptográfico— el contrato compartido que cada agente carga antes de tocar un fichero empieza con una regla en mayúsculas: ningún agente, bajo ninguna circunstancia, puede ejecutar git push contra main. Todo el trabajo vive en ramas feat/MINT-xxx. La fusión la hago yo a mano. Radio de daño: un error de determinismo en una ruta de ejecución de bloque, que en una cadena no es un bug: es una bifurcación.

Entre los dos polos está todo lo demás, y la regla que coloca cada repositorio en la escala se enuncia en una línea: cuanto más caro es deshacer, más corta es la correa. Una web estática se deshace con un push. Una regla de consenso se deshace con una votación de gobernanza y una disculpa.

Cuatro agentes, un humano y una máquina de estados que impone el tablero

Lo que la gente subestima es que «la IA escribe el código» no es un rol. En el protocolo corren cuatro.

• Un agente CTO lee la especificación y convierte una tarjeta en un brief de ejecución. Corre sobre el modelo de razonamiento más pesado que tenemos, porque una mala especificación es el artefacto más caro de toda la cadena.
• Un agente Dev implementa exactamente el brief: el cambio más pequeño que cumple, cubierto por tests, sin reescrituras especulativas. Opus o Sonnet según la tarjeta.
• Un agente QA valida los criterios de aceptación, el determinismo y los invariantes de privacidad, y emite un informe con uno de tres veredictos —PASS, FAIL, CONDITIONAL— y, si no es PASS, un campo de enrutamiento: de vuelta a Dev, de vuelta al CTO o a mí.
• Un agente PM es el único que habla con un humano. Mueve la tarjeta de JIRA, despacha a los demás y se detiene tras dos ciclos de reintento fallidos con un resumen completo en mi mesa.

Cada transición de estado es una transición de tarjeta en el tablero 166: To Do → In Progress → REVIEW → Done, y Done es el único estado que me pertenece. El agente nunca decide que ha terminado; lo decide el tablero, y la última columna del tablero lleva el nombre de una persona. No es ceremonia. Es la diferencia entre «el modelo escribió casi todo el código» y «una persona con nombre responde de cada línea fusionada».

La regulación vive en la definición de hecho

La ingeniería regulada tiene la costumbre de escribir el cumplimiento en un documento que nadie abre. Nosotros lo escribimos en la lista que el agente QA no puede saltarse. Dos líneas de la Definition of Done del protocolo cargan con casi todo el peso:

1. Determinismo. Ninguna llamada de red, reloj, aleatoriedad, HSM, RPC o FFI entra en una ruta de ejecución de bloque sin un punto de auditoría explícito y marcado. Una FFI nueva en Rust sobre esa ruta no es un comentario de revisión: es, por definición, un punto de auditoría que bloquea el lanzamiento.
2. Invariantes de privacidad. Nunca se escribe en el estado de la cadena un KYC en bruto, datos personales, la carga de una credencial, su número de serie ni un registro de presentación: requisitos R2, R8 y R18 de la especificación congelada, comprobados en cada tarjeta.

Y por encima de ambas, la regla de escalado: todo lo que toca criptografía en la ruta de consenso, o los invariantes de privacidad, se escala a mí por defecto. No son decisiones autónomas. Los agentes proponen; no disponen.

Una línea más del contrato que interesará a quien trabaja en entornos regulados: toda la inferencia del modelo pasa por nuestra propia cuenta de AWS Bedrock, y los agentes tienen prohibido introducir dependencias de cualquier API pública de modelos. El código que toca datos de identidad lo redacta un modelo que corre dentro de un perímetro que controlamos. Es la misma disciplina que defendí en el artículo sobre el perímetro: la residencia es una orden de compra; el perímetro es ingeniería.

Las líneas rojas en CI cazan la frase que habría cazado la abogada, una semana antes

ZadQ nos enseñó algo que el código de MintID no: en un producto regulado, el texto también es código.

La web comercial de ZadQ también la construyen agentes, y el riesgo allí no es una bifurcación: es una afirmación. Un porcentaje de ahorro. La expresión «zero-knowledge» en una superficie v0 que todavía no se la ha ganado. La palabra «token» donde un regulador de pagos lee un criptoactivo. Así que el vocabulario prohibido es un fichero del repositorio, versionado, que solo cambia por tarjeta, y npm run verify tumba la build con cualquier coincidencia. La lista es tosca a propósito: nada de coste o retorno, nada de vocabulario criptográfico que el producto aún no pueda sostener, nada de «requiere un servicio activo» (el servicio degrada a «desconocido» y no bloquea nada, y el texto tiene que decirlo en positivo) y nada de pruebas prestadas: ni «testimonio», ni «certificado», ni «disponibilidad» mientras no haya una real que señalar.

Y luego está la puerta en sí. La web de ZadQ llevaba una constante PUBLICATION_GATE que se mantuvo en closed —páginas fuera del índice, build que lo comprueba— hasta que una acreditación fechada de marca la pasó a open el 20 de agosto de 2026. El mismo mecanismo que una feature flag; la funcionalidad era «tener permiso para existir en público».

Concedo la objeción evidente: una lista de palabras es un revisor de cumplimiento muy rudimentario. Lo es. También corre en cada commit, a coste marginal cero, y cazó en CI exactamente las frases que un revisor humano habría marcado una semana después en una llamada. La abogada sigue leyendo el texto final. Lo lee una vez.

El propio diseño de MintID dice lo mismo sobre la IA: evidencias, nunca veredictos

Hay una simetría agradable en todo esto, y no es casual. El plano emisor de MintID acepta la entrada de cribadores de IA —clasificadores de documentos, pruebas de vida, todo el mercado de herramientas KYC— y rechaza estructuralmente cualquier campo «grado» que el cribador afirme. Un cribador produce evidencias, enumeradas y con procedencia. La autoridad emisora decide, incluido el grado de garantía, y el sistema de tipos no permite otra cosa.

Es la misma postura que aplicamos a nuestra ingeniería: el modelo produce el diff, los tests y el informe. El veredicto —fusionar, publicar, entregar— es de una persona, y las herramientas están construidas para que no se pueda delegar por descuido. En junio escribí que el modelo es la materia prima y el arnés es el foso. Seis meses entregando código regulado con agentes han afilado la tesis: el arnés es también el relato de cumplimiento.

Qué ha salido de ahí

Me quedo con los números que puedo defender. El primer arranque de red completo del protocolo —nodo de cadena más servicio verificador, reproducible desde un paquete en minutos— encontró cero defectos en el código del protocolo; lo que se rompió fue herramienta de despliegue, y se arregló sobre la marcha. El equipo integrado que construyó el núcleo y los tres SDK verificadores entregó cada hito en fecha y con cero bugs, y el cliente renovó por el doble del presupuesto inicial: esa historia es pública. ZadQ pasó del primer commit a una web operativa en diez días, y a un portal de desarrolladores, condiciones completas y blog en menos de tres semanas, con cada uno de sus 51 commits llevando un número de tarjeta.

Nada de eso es una mainnet, una auditoría ni una cifra de clientes, y no lo voy a disfrazar. Es la prueba de que los agentes pueden sostener una base de código regulada a velocidad cuando la correa está diseñada, no supuesta.

Qué haría este trimestre si fuera vuestro CTO

1. Clasificar cada repositorio por el coste de deshacer, no por equipo. Con tres niveles basta: «push despliega», «rama y fusión humana», «rama, fusión humana y punto de auditoría».
2. Escribir el contrato del agente como el primer fichero que carga, no como una página de Confluence. Misión, fuente de verdad, reglas duras, lo que no se hace, formato de salida obligatorio. Lo que no está en la ventana de contexto no es una regla.
3. Separar los roles. Un agente que especifica, otro que implementa y otro que revisa con un veredicto de tres estados y un campo de enrutamiento. El revisor no puede ser el autor.
4. Meter la regulación en la definición de hecho como líneas comprobables: los invariantes por los que preguntará el auditor, redactados de modo que un revisor pueda contestar sí o no.
5. Hacer del escalado el comportamiento por defecto en la ruta peligrosa. Criptografía, consentimiento, movimiento de dinero: el agente propone; una persona con nombre dispone.
6. Tratar el texto como código allí donde las afirmaciones están reguladas. Una lista de palabras versionada y una build que falla si coincide.
7. Mantener la inferencia dentro del perímetro para todo lo que lea datos regulados. Bedrock, un endpoint privado, vuestro propio hardware: lo importante es que el modelo corra donde ya viven los datos.

Hace seis meses la respuesta honesta a «hasta dónde dejamos llegar al agente» era «lo estamos averiguando». Ahora es: exactamente hasta donde deshacer es barato, y ni un commit más allá. En la web, el agente hace push a main. En el código de consenso ni lo intenta, y esa frase, no el modelo que hay detrás, es lo que le enseñaría a vuestro regulador.

Si estáis montando un equipo asistido por IA dentro de un perímetro así, contadme cómo es el perímetro. El diseño de la correa es la parte que conviene acertar primero.