Cómo gobernar la seguridad de los agentes de IA en el desarrollo de software

Los agentes de inteligencia artificial dejaron de ser un experimento en los equipos de ingeniería. Hoy leen repositorios, escriben código, ejecutan pruebas y, en algunos casos, lanzan cambios a ambientes productivos con poca intervención humana. La adopción avanza con rapidez en organizaciones de banca, seguros, telecomunicaciones y manufactura de México, mientras que los controles de seguridad suelen definirse después, cuando el agente ya está trabajando.

Esa diferencia de ritmo abre una brecha que un líder de tecnología puede cerrar con decisiones concretas. Un agente tiene credenciales, accede a datos y ejecuta acciones sobre sistemas críticos, así que merece el mismo rigor que cualquier persona con esos privilegios. Cuatro prácticas permiten gobernarlo a tiempo. Consisten en limitar sus accesos, registrar cada acción, asignar a una persona que lo audite y probar su exposición a manipulaciones externas.

Por qué los agentes de IA cambian el riesgo en el desarrollo de software

Un asistente de código propone una línea. La persona decide si la acepta. Un agente de IA recibe un objetivo, planifica los pasos para alcanzarlo y los ejecuta con las credenciales que se le entregaron. Puede abrir archivos, consultar bases de datos, modificar configuraciones y desplegar cambios dentro de una misma sesión de trabajo.

Ese cambio de rol modifica la superficie de riesgo. Si el agente cuenta con permisos amplios, un error de interpretación o una instrucción maliciosa puede terminar en una acción sobre sistemas en producción, sin que ninguna persona la haya revisado antes. En banca, seguros o telecomunicaciones, donde el código toca datos de clientes y procesos regulados, el impacto de una acción así se mide en incidentes de seguridad y en hallazgos de cumplimiento.

Por ello la seguridad de los agentes merece tratarse como una disciplina propia dentro del ciclo de vida del desarrollo de software (SDLC, por sus siglas en inglés). Las cuatro prácticas siguientes funcionan como un solo sistema de control, y cada una responde una pregunta distinta sobre el agente.

Defina a qué sistemas y datos puede acceder cada agente

La primera decisión consiste en delimitar el alcance. Cada agente debería operar con el mínimo de permisos que su tarea exige, igual que una cuenta de servicio bien administrada. Un agente que genera pruebas unitarias necesita leer un repositorio y ejecutar un ambiente de pruebas, pero no tiene motivo para consultar la base de datos de clientes ni para modificar la tubería de despliegue.

En la práctica, esto exige tres definiciones por escrito antes de poner el agente a trabajar. Primero, los repositorios, ambientes y herramientas que puede usar. Segundo, las categorías de datos que puede leer, con especial atención a la información personal, financiera o confidencial. Tercero, las acciones que requieren aprobación humana, como fusionar cambios a la rama principal o desplegar a producción.

Las credenciales merecen el mismo cuidado. Conviene entregarlas con vigencia corta y por tarea, evitando que el agente herede el acceso completo del desarrollador que lo lanzó. Cuando el alcance está documentado, ajustarlo o revocarlo toma minutos en lugar de semanas.

Mantenga un registro completo de lo que hace cada agente

Sin un historial de lo que hace, un agente no se puede gobernar. El registro debe capturar qué instrucción recibió, qué herramientas invocó, qué archivos y datos tocó, qué cambios propuso o ejecutó y con qué resultado. Si algo falla en producción, el equipo necesita reconstruir la secuencia completa de decisiones del agente en lugar de deducirla a partir de síntomas.

Tres propiedades distinguen un buen registro. Debe ser completo, inalterable y consultable:

• Completo: Ninguna acción debe quedar fuera del historial para no perder rastreabilidad.
• Inalterable: El propio agente o usuarios no autorizados no pueden borrarlo ni modificarlo.
• Consultable: Por agente, por sistema y por fecha, e integrarse con las herramientas de monitoreo actuales.

Este historial sirve en dos momentos. Durante un incidente acelera el análisis de causa raíz. Durante una auditoría demuestra a reguladores y áreas de cumplimiento que las acciones automatizadas se ejecutaron bajo reglas conocidas, algo que en banca y seguros pesa tanto como el resultado técnico.

Asigne a una persona para auditar su comportamiento

Un agente no responde ante nadie, de modo que la responsabilidad recae en el equipo que lo opera. Conviene designar a una persona con nombre y cargo que revise de forma periódica cómo se comporta. Esa figura puede ubicarse en ingeniería, en seguridad o en una función de gobierno de IA, siempre que tenga autoridad para pausar el agente o recortar sus permisos.

La auditoría revisa si el agente se mantuvo dentro del alcance autorizado, si sus decisiones siguieron los estándares de código y seguridad de la organización, así como si aparecen patrones no previstos, por ejemplo, accesos inusuales o cambios en horarios atípicos. Con ese análisis se ajustan los permisos, se actualizan las instrucciones del agente y se decide si su autonomía crece o se reduce.

Esta supervisión humana evita que la automatización diluya la responsabilidad. Cuando algo sale mal, la organización sabe quién debe responder y qué decisión corregir.

Pruebe de forma constante la exposición a manipulaciones externas

Los agentes procesan texto de múltiples fuentes, como tickets, documentación, páginas web, correos o comentarios en repositorios. Cualquiera de esos insumos puede contener instrucciones ocultas diseñadas para desviar su comportamiento, una técnica conocida como inyección de instrucciones (prompt injection). Un comentario aparentemente inocuo dentro de un archivo puede llevar a un agente a exponer credenciales o a insertar código dañino.

Para anticiparse, el equipo debe atacar a sus propios agentes antes de que lo haga un tercero. Esto implica ejercicios periódicos de red teaming que intenten engañar al agente con instrucciones maliciosas, ampliar sus permisos o extraer información que no debería entregar. Los hallazgos se convierten en nuevas reglas, filtros de entrada o restricciones de herramientas.

Estas pruebas se repiten cada vez que cambia el modelo, el conjunto de herramientas o los sistemas a los que el agente se conecta, porque cualquiera de esos cambios altera su exposición. Una prueba aprobada hace seis meses no dice nada sobre la configuración actual.

Seguridad desde el diseño antes de pasar a producción

Las cuatro prácticas rinden más cuando se incorporan desde el diseño del agente, antes de su puesta en producción. Agregarlas después obliga a rediseñar permisos, integrar registros que no se previeron y asignar responsables bajo la presión de un incidente. Definirlas desde el inicio permite que el equipo avance con velocidad sin acumular un riesgo que más tarde cuesta más corregir. Ese enfoque corresponde a un modelo AI-First, donde la seguridad acompaña cada etapa del ciclo de vida del software.

Antes de ampliar el uso de agentes, su equipo debería poder responder con precisión a qué sistemas accede cada uno, qué acciones ejecutó y quién responde por su comportamiento.