Auditoría adversarial multi-agente: cuando «todo está en verde» no basta

Una implementación puede compilar correctamente, superar todas sus pruebas y cumplir aparentemente con las tareas planeadas. Eso no garantiza que funcione de principio a fin.

Los defectos más difíciles no siempre están dentro de una función concreta. A menudo aparecen en las costuras del sistema: un servicio que nadie llama, una pantalla conectada al método equivocado, una migración que no refleja el contrato esperado o una afirmación de «verificado» que en realidad solo se comprobó contra un mock.

Para investigar esas zonas, StrayMark incorpora un instrumento de ingeniería que denominamos auditoría adversarial multi-agente, o AAMA.

Qué es una AAMA

Una AAMA es una auditoría estructurada en la que varios modelos de IA, pertenecientes a familias distintas, examinan de forma independiente una unidad de implementación: el Charter.

Cada auditor recibe el mismo contrato de trabajo:

• qué debía construirse;
• qué tareas formaban parte del alcance;
• qué archivos cambiaron;
• qué decisiones y riesgos quedaron registrados;
• qué condiciones debían cumplirse para cerrar el trabajo.

Su objetivo no es confirmar que el resultado «parece correcto». Es intentar refutarlo con evidencia.

Los auditores inspeccionan el código, trazan flujos entre componentes, revisan pruebas, ejecutan las verificaciones permitidas y comparan la implementación real con las obligaciones del Charter.

Lo hacen en aislamiento. No pueden leer los informes de los demás ni modificar el proyecto: deben reportar lo que encuentran, no corregirlo. Así evitamos que una primera opinión contamine a las demás, y podemos distinguir entre coincidencia auténtica y repetición.

Más que pedir varias opiniones

Ejecutar cuatro veces el mismo prompt no constituye una auditoría multi-agente. La AAMA introduce separación de funciones.

Los auditores independientes exploran el mismo trabajo desde perspectivas diferentes. Algunos son especialmente rigurosos con el alcance; otros siguen mejor los flujos de ejecución, la configuración real, la seguridad o la deuda técnica.

El calibrador, o consolidador, revisa después todos los informes: verifica los hallazgos, elimina duplicados, resuelve contradicciones, recalibra severidades y puede descubrir problemas que ningún auditor señaló.

El responsable humano conserva la decisión final: cerrar el Charter, remediarlo o diferir parte del trabajo de forma explícita. Es la misma línea que explicamos en Por qué StrayMark no automatiza sin supervisión.

El resultado no es una votación entre modelos. Es una investigación con evidencias, contradicción y adjudicación.

Ampliar la figura

Un caso real: miles de pruebas y una función que no funcionaba

En una auditoría reciente, el Charter revisado implementaba un mecanismo de acceso urgente o break-glass: una autorización temporal, limitada y registrada para consultar información sensible.

La solución parecía sólida. Existían servicios, controles de acceso, pruebas unitarias, integración con PostgreSQL y miles de pruebas aprobadas.

Sin embargo, la primera ronda de auditoría encontró un defecto decisivo: el método que consultaba la autorización urgente estaba implementado y probado, pero ninguna de las ocho superficies de la aplicación lo utilizaba.

Cada componente funcionaba por separado. El recorrido completo, no. Un operador podía activar correctamente la autorización y aun así no acceder a ningún expediente.

La auditoría permitió localizar el problema, remediarlo y añadir una prueba de integración que verificara el camino real: desde la identidad de quien consulta hasta el expediente consultado.

En la segunda ronda, cuatro auditores independientes confirmaron que el defecto principal estaba cerrado. Pero uno de ellos encontró un problema de la misma familia: otro método público, el que revocaba la autorización, existía y tenía pruebas, y tampoco lo invocaba nadie en producción.

Ese es el tipo de fallo que una revisión convencional puede pasar por alto: la capacidad está escrita, pero no está conectada.

La auditoría también se audita

La parte más interesante ocurrió después.

Tras la primera ronda se había creado un test guardián con una regla en apariencia general: un punto de entrada de autorización no debía existir sin que algo lo llamara en producción.

El consolidador descubrió que ese test solo enumeraba el método que ya había fallado. No cubría la familia completa de capacidades públicas.

La organización había aprendido una lección, la había convertido en código y, aun así, la había generalizado a medias. Los informes detallados permitieron verlo.

Esta es una propiedad importante de la AAMA: no solo produce hallazgos sobre el software. También genera información sobre:

• qué modelos investigan con mayor profundidad;
• cuáles tienden a producir falsos positivos;
• cuáles detectan mejor los problemas de alcance;
• qué verificaciones resultaron insuficientes;
• qué reglas nuevas deben incorporarse al proceso;
• qué defectos se le escaparon a todos.

En otras palabras, la auditoría se convierte en un sistema que también puede examinar y mejorar su propio desempeño.

Qué recibe quien dirige el proyecto

Para una persona responsable de producto, operación o entrega, la AAMA ayuda a distinguir entre conceptos que suelen confundirse.

Código producido y funcionalidad operativa. Que una capacidad exista no significa que la aplicación pueda utilizarla.

Pruebas aprobadas y criterio de negocio cumplido. Una suite puede verificar los componentes y omitir la costura que los conecta.

Deuda consciente y omisión accidental. Un riesgo documentado tiene contexto, propietario y destino; una diferencia silenciosa, no. Es la distinción que sostiene los FollowUps.

Consenso y certeza. La coincidencia de varios auditores aumenta la confianza, pero un hallazgo único puede ser el más importante de toda la ronda.

Actividad y evidencia. No basta con registrar que algo fue revisado: debe quedar claro qué se verificó, contra qué realidad y con qué resultado.

Eso permite tomar decisiones de cierre más defendibles y conservar una memoria técnica reutilizable para los trabajos siguientes.

Una capacidad de ingeniería de StrayMark

StrayMark no trata la auditoría como un reporte aislado al final del proyecto. El Charter, los registros de implementación, el rango de Git, los informes de los auditores, la consolidación y las acciones de remediación permanecen vinculados dentro de un mismo flujo de gobernanza.

La AAMA convierte ese conjunto en un instrumento para proyectos donde la entrega necesita algo más que velocidad:

• software con impacto operativo;
• sistemas que manejan información sensible;
• implementaciones asistidas por agentes de IA;
• equipos que necesitan trazabilidad;
• organizaciones que no pueden conformarse con un «parece funcionar».

La promesa no es que un grupo de modelos encontrará absolutamente todos los defectos. Es que cada afirmación importante puede ser cuestionada, cada hallazgo puede ser rastreado y cada fallo del propio proceso puede convertirse en una mejora permanente de ingeniería.

Con StrayMark, la IA no solo ayuda a construir software. También participa en un sistema diseñado para poner a prueba lo que construyó, confrontar sus conclusiones y dejar la decisión final donde debe estar: en manos humanas. Es la misma apuesta que contamos en Una auditoría que te deja en la sala.

---

Sobre StrayMark

StrayMark es un framework y una herramienta de línea de comandos, escritos en Rust, para la disciplina que exige trabajar con agentes de IA: externaliza el alcance, las decisiones y los riesgos en archivos versionados junto al código, de modo que el agente ejecute contra restricciones y no invente las suyas. La AAMA es una de sus capacidades. Es software libre con licencia MIT, de uso gratuito, y su documentación está en straymark.dev.