Los agentes de IA más útiles de Google no conversan. Viven en la revisión de código y frenan vulnerabilidades

Cuando una empresa imagina un agente de IA, casi siempre imagina una conversación: alguien pide algo y el agente responde o actúa. Algunos de los agentes más valiosos no se parecen en nada a eso. No tienen ventana de chat. Funcionan dentro de un proceso en el que la empresa ya confía, y lo que entregan es una decisión que ese proceso ya sabe gestionar.

Un artículo publicado en septiembre por dos responsables de ingeniería de Google describe exactamente eso: agentes de IA integrados en el ciclo de desarrollo que protege el código de la propia infraestructura de Google. Es uno de los relatos públicos más detallados de agentes operando dentro de un proceso de control a escala, y sus decisiones de diseño sirven mucho más allá de Google.

Cómo funciona el sistema

Según Google, el sistema tiene tres etapas y un paso de corrección:

• Análisis antes del envío. Cada cambio de código, en todas las capas del stack, se evalúa en tiempo real con agentes de IA dentro de las herramientas de desarrollo. Los agentes usan modelos de amenazas locales construidos con metadatos vivos del código y grafos de dependencias.
• Triaje. Un agente de triaje separado y especializado valida cada hallazgo con un análisis ligero de menos de un minuto, mediante el análisis del árbol sintáctico, el recorrido del grafo de llamadas y reglas de seguridad preindexadas, para demostrar que un atacante puede alcanzar realmente la ruta vulnerable. Google informa de una precisión superior al 92% en esta etapa.
• Análisis después del envío. Un análisis nocturno, con capacidad ociosa, busca vulnerabilidades introducidas por la suma de varios cambios.
• Corrección automática, aprobación humana. Un agente de corrección usa los hallazgos y las pruebas generadas para construir el arreglo, que se envía a revisión humana dentro de la propia revisión del cambio original.

Google afirma que el sistema cubre todos los cambios de código que se despliegan en su infraestructura, en cientos de millones de líneas, y que evita que cientos de vulnerabilidades al mes lleguen al código o a producción. También informa de falsos positivos de solo el 3% en algunos casos. Son cifras de Google sobre su propio entorno. El trabajo se apoya en Mantis, un harness de revisión multiagente que Google ha publicado como código abierto.

1. Cambio de código enviado
2. Agente de análisis con modelo de amenazas
3. Agente de triaje con prueba estructural
4. Agente de corrección propone el arreglo
5. El revisor aprueba en la misma revisión
6. Análisis nocturno entre cambios

Paso realizado por un agente de IADecisión humana, en el proceso que ya existía

Cinco decisiones de diseño que vale la pena copiar

1. Separe los agentes. La primera recomendación de Google es mantener separados los harnesses, las reglas y el contexto de los agentes de desarrollo, análisis y triaje, para evitar sesgos. Es la versión agéntica de la segregación de funciones: quien encuentra el problema no debería ser quien decide si es real, y ninguno de los dos debería escribir el arreglo sin control.

2. Combine IA con comprobaciones deterministas. El triaje no confía en la opinión de un modelo de que el código es vulnerable. Usa análisis estructural para demostrar que la ruta es alcanzable. Unir un análisis rápido con IA y una validación determinista es lo que reduce a la vez la latencia y los falsos positivos. El patrón sirve para cualquier agente cuyo resultado genera trabajo a personas.

3. Dé a los agentes el contexto que ya tiene. Google señala los modelos de amenazas existentes como la entrada clave para la precisión. La mayoría de las empresas tiene activos equivalentes: catálogos de controles, registros de decisiones de arquitectura, clasificación de datos.

4. Ponga la aprobación humana donde las personas ya deciden. El arreglo llega en la revisión del cambio original. El revisor no aprende una herramienta nueva ni atiende otra cola. La adopción llega porque el agente encaja en el flujo de trabajo, no al revés.

5. Use el harness para absorber la variabilidad de los modelos. Google observa que un harness multiagente compensa la variabilidad entre modelos. La fiabilidad la aporta el diseño, no un modelo concreto. Planteamos un argumento parecido en nuestro análisis sobre el harness de IA.

España: la regulación ya pide este tipo de evidencia

En la UE, el Reglamento de Ciberresiliencia exige a los fabricantes de productos con elementos digitales gestionar vulnerabilidades durante todo el ciclo de vida, y sus obligaciones de notificación se aplican desde septiembre de 2026. Las entidades financieras, además, están sujetas a DORA, aplicable desde enero de 2025, que exige un marco de gestión del riesgo TIC. Un agente que actúa dentro de la revisión de código, con la aprobación humana registrada en el mismo lugar, genera justo el tipo de evidencia que piden auditores y supervisores.

Latinoamérica: capacidad de seguridad limitada, procesos existentes

Pocas empresas de la región tienen equipos de seguridad de aplicaciones del tamaño necesario para revisar cada cambio. Ahí está el valor del patrón de Google: un primer filtro automático, con validación determinista, que llega al revisor que ya existe. El cuidado es que el agente no se convierta en un atajo: la aprobación sigue siendo de una persona con nombre.

Qué hacer ahora

1. Elija un control existente con una decisión clara: revisión de código, revisión de accesos, cuestionarios de riesgo de proveedores, aprobación de cambios.
2. Separe quién encuentra de quién confirma. Un agente señala; una comprobación determinista o un segundo agente confirma. Mida la precisión antes de mostrar el resultado a nadie.
3. Entregue el resultado dentro del flujo actual, con el mismo aprobador humano y el mismo registro de evidencias.
4. Trate los falsos positivos como métrica principal. Un agente que satura a los revisores acabará desactivado, por muchos problemas reales que encuentre.
5. Mantenga bajo revisión los cambios de los propios agentes. Como señalamos en nuestro análisis de AIP Evolve, de Palantir, los agentes que modifican sistemas necesitan su propia evaluación y sus propias aprobaciones.

En resumen

Los agentes que describe Google son invisibles para la mayoría de las personas a las que ayudan. Precisamente de eso se trata. Los agentes empresariales de más valor pueden acabar desapareciendo dentro de procesos de control que ya existen, donde el éxito se mide en precisión, tiempo de corrección y confianza de los revisores, y no en conversaciones.