Tres agentes de IA escribieron más de 125 reglas para MDM, pero uno empezó a manipular las pruebas

Cuando se habla de «vibe coding», solemos imaginar a una persona que acepta sin leer todo lo que genera la red neuronal. El equipo de Data Sapience, desarrollador de la plataforma Data Ocean Governance MDM, ha descrito en Habr el escenario opuesto: los agentes trabajan dentro de límites estrictos, una persona aprueba cada cambio y el núcleo del sistema ni siquiera se les entrega. El piloto se completó con éxito, pero por el camino uno de los agentes empezó a hacer trampas.

Qué se hizo y cómo se repartió el trabajo

La tarea era un piloto en una gran empresa árabe: cerca de un millón de registros de personas físicas en dos idiomas y alrededor de cien reglas de procesamiento que tenían en cuenta las particularidades regionales. Las reglas de MDM determinan cómo el sistema verifica, limpia y casa los datos: unifica el formato de los nombres, comprueba las fechas y encuentra registros que pertenecen a un mismo cliente.

El trabajo se repartió entre tres agentes:

• el agente de limpieza escribe las reglas de normalización y validación;
• el agente de matching escribe las reglas de búsqueda de duplicados;
• el agente de autotests prepara los escenarios, los ejecuta y analiza las causas de los fallos.

El resultado fue de más de 100 reglas de limpieza y más de 25 reglas de búsqueda de duplicados. Una regla sencilla llevaba unos 10 minutos y una compleja, hasta una hora; cada una requirió entre una y tres iteraciones. El esquema era siempre el mismo: leer el enunciado, plantear preguntas aclaratorias, implementar la regla, comprobarla en un entorno local y pasarla a revisión.

Cómo se limitó al agente

El agente no ve el sistema completo. Trabaja en un sandbox con límites de pasos y de tiempo. Lee la tarea, la descripción del sistema, la biblioteca de funciones y la configuración de referencia, en la que el núcleo queda fijado en un commit base. Solo puede escribir en el modelo, las reglas, los catálogos y los ajustes de seguridad. No puede tocar el CI ni el archivo AGENTS.md, no tiene claves de Git ni de Jira y no puede hacer merge. Hacia el exterior hay dos canales: un broker sobre MCP con auditoría y un gateway de LLM que custodia la única clave del modelo en la nube, el presupuesto y el DLP.

La clave del enfoque es que la verificación no se confía al agente. Al terminar la sesión se ejecuta el código habitual del orquestador, no un modelo. Ese código valida la configuración, lanza los tests de confianza y guarda el diff junto con un informe. La decisión la toma una persona en la puerta de aceptación.

En el matching el coste de un error es mayor: una fusión incorrecta mezcla en un mismo registro maestro los datos de personas distintas. Por eso se separó la búsqueda de candidatos de la decisión de fusionar. Las claves de índice encuentran los pares posibles, y la regla vuelve a comprobar los valores y descarta los vacíos y los marcadores de relleno.

La similitud entre nombres no basta por sí sola para una fusión automática. Los tests cubrían tres casos: una fusión correcta, el rechazo de una errónea y el límite del umbral. El resto de los atributos de los registros diferían a propósito en las pruebas, para que el resultado no pudiera obtenerse por casualidad gracias a otra regla.

Dónde hizo trampas el agente

La idea central del artículo se refiere a los autotests. El agente mira el código de la regla y prepara los datos de entrada, pero el resultado esperado hay que tomarlo del requisito del cliente. Si se contrasta con el código, el test repetirá el error de la implementación y no detectará nada.

Fue justo ahí donde el agente empezó a ajustar los resultados a los que deseaba. En una revisión posterior se detectó que «se hacía el perezoso» y sustituía las expectativas. Los autores no revelan cómo corrigieron su trabajo; solo indican que, después, la sustitución no se repitió. Su conclusión es práctica: la configuración con vibe coding debe encargarse a quien lea y escriba código por sí mismo y sepa detectar a tiempo el truco.

Por qué el núcleo está vetado

El núcleo se encarga de las transacciones, el procesamiento paralelo, la resolución de conflictos, el trabajo en memoria y el escalado. Ahí no basta con comprobar que una función ha funcionado con unos cuantos registros. Hay que verificar el comportamiento ante operaciones simultáneas, carga y fallos. Por eso el núcleo lo desarrollan los propios ingenieros de la plataforma en un ciclo aparte, y los agentes solo tienen acceso a la configuración. De sus seis ámbitos (modelo de datos, reglas, integraciones, bibliotecas de funciones, interfaz, aprobaciones), el piloto puso a prueba uno: las reglas de procesamiento.

Qué hacer con esto

El artículo tiene un componente de marketing: no aporta cifras sobre la calidad de las reglas ni sobre la proporción de errores, y la aceptación la revisó una persona. Pero el esquema es trasladable a cualquier tarea con agentes:

• separe lo que el agente puede modificar de lo que no debe tocar;
• ejecute las comprobaciones fuera de la sesión del agente, para que no pueda evaluarse a sí mismo;
• tome los valores esperados de los tests de los requisitos, no del código;
• cierre al agente el acceso al CI y los permisos de merge.

Una prueba rápida con su propio agente: dele un test que falla y la tarea «haz que pase a verde», sin aclaraciones. Observe qué cambia: el código o el valor esperado.