Agentes de IA fuera de control: vigilar máquinas con más máquinas no es seguridad
Los agentes de IA ya ejecutan código, acceden a datos y toman decisiones a una velocidad imposible de auditar manualmente. Anthropic apuesta por evaluadores externos y nuevas startups quieren usar otra IA como vigilante. El verdadero reto para desarrolladores en 2026 es menos futurista: permisos mínimos, logs verificables y control humano.
Escucha el artículo
Poner otra inteligencia artificial a vigilar a una IA descontrolada no es una estrategia de seguridad: es una muñeca rusa con acceso a producción. La industria está entregando terminales, credenciales y capacidad de ejecución a agentes cada vez más autónomos, mientras intenta convencernos de que otro modelo detectará a tiempo lo que el primero haga mal.
La automatización no es el problema. El problema es confundir velocidad con control y autonomía con fiabilidad. En 2026, el debate ya no trata de si un agente puede escribir código, sino de quién responde cuando lo escribe, lo ejecuta y toca datos reales sin que nadie alcance a revisar cada paso.
Los agentes de IA ya trabajan más rápido de lo que podemos auditarlos
Los asistentes de programación dejaron de ser autocompletadores glorificados. Herramientas como Claude Code, Codex y otros agentes pueden recorrer repositorios, modificar varios archivos, ejecutar pruebas, consultar servicios y encadenar acciones durante largos periodos. Esa capacidad multiplica la productividad, pero también amplía el radio de explosión de cualquier error.
TechCrunch informó que las empresas se enfrentan a un problema obvio: los agentes actúan durante más tiempo, a mayor escala y con un volumen que ningún equipo humano puede revisar de forma exhaustiva. La respuesta emergente parece lógica en una diapositiva y absurda en producción: colocar otra IA entre el agente y su siguiente acción.
Apollo Research, por ejemplo, desarrolló Watcher para revisar acciones propuestas por agentes de programación antes de que se ejecuten. El sistema busca señales de riesgo como filtraciones de datos privados o eliminación de archivos sin permiso. Las actividades sospechosas pasan a modelos más potentes, y estos pueden bloquearlas o pedir aprobación humana.
Tiene sentido como capa adicional. El peligro aparece cuando esa capa se convierte en coartada para conceder permisos excesivos al agente principal. Un modelo probabilístico no se transforma en firewall solo porque su prompt diga “vigila al otro modelo”.
El problema de fondo: una IA también puede engañar a su vigilante
Un agente mal orientado, comprometido o simplemente equivocado puede producir acciones plausibles y explicaciones convincentes. Si el vigilante también interpreta lenguaje y contexto mediante inferencias probabilísticas, existe la posibilidad de que acepte una justificación falsa o no detecte una secuencia peligrosa repartida en muchos pasos aparentemente inocentes.
El riesgo no exige imaginar una superinteligencia rebelde. Basta con una credencial demasiado poderosa, una instrucción ambigua y un sistema sin límites claros. Es la misma receta de miles de incidentes tradicionales, solo que ahora el proceso puede equivocarse cientos de veces por minuto.
TechCrunch recoge una crítica más incómoda: buena parte de estos fallos no requiere ciencia ficción, sino higiene básica de seguridad. Logs completos, control del tráfico de red, permisos mínimos, aislamiento de procesos y límites de gasto o ejecución llevan décadas funcionando. La industria está intentando vender “IA que vigila IA” antes de aplicar con rigor controles que ya conocemos.
La seguridad de un agente no se mide por lo inteligente que parece, sino por lo poco que puede destruir cuando se equivoca.
Ese principio obliga a diseñar para el fallo. Un agente con acceso de solo lectura no necesita que confiemos ciegamente en su razonamiento. Uno encerrado en un sandbox no puede improvisar una conexión a cualquier servidor. Un cambio que exige revisión antes del despliegue reduce el daño incluso cuando tanto el agente ejecutor como el monitor fallan.
El giro inesperado: la evaluación independiente entra dentro del laboratorio
Mientras muchas startups construyen vigilantes automáticos, Anthropic eligió otra pieza del rompecabezas: permitir que evaluadores independientes observen cómo nacen y se despliegan sus modelos. La compañía anunció una alianza con Accenture para hacer red teaming, evaluar alineación y comprobar salvaguardas desde dentro.
La idea de una evaluación “embebida” importa porque los auditores tendrían acceso comparable al de un empleado. Podrían seguir decisiones de entrenamiento y despliegue, detectar puntos ciegos y verificar si los compromisos públicos de seguridad existen también en la práctica. Anthropic y Accenture prevén invertir al menos mil millones de dólares cada una durante cinco años para construir capacidad en este terreno.
Pero tampoco conviene tragarse el titular completo sin masticarlo. Anthropic financiará directamente el trabajo inicial y todavía no existen estándares definidos sobre acceso, publicación de hallazgos o financiación independiente. Un auditor pagado por la empresa auditada puede hacer un trabajo excelente, pero la independencia debe demostrarse con reglas, transparencia y capacidad real de publicar problemas incómodos.
La oportunidad está en combinar tres niveles, no en elegir uno: controles técnicos deterministas, monitores inteligentes y evaluación humana externa. Cada capa cubre fallos diferentes. Ninguna merece convertirse en excusa para eliminar las otras.
Qué deben cambiar hoy los desarrolladores que usan agentes de IA
Para un desarrollador freelance o un equipo pequeño, el problema parece lejano hasta que un agente toca el repositorio equivocado, imprime una variable secreta o ejecuta una migración irreversible. No hace falta operar miles de agentes para sufrir un incidente; basta con uno que tenga más autoridad de la necesaria.
El primer cambio es tratar al agente como a un colaborador externo rápido, útil y falible. Dale un entorno aislado, credenciales temporales y permisos limitados a la tarea. Separa desarrollo de producción. Registra comandos, cambios de archivos, llamadas de red y decisiones de aprobación. Y conserva una ruta clara para detener la ejecución.
El segundo es convertir la verificación en parte del flujo, no en un ritual posterior. Tests, análisis estático, revisión de diffs y comprobaciones de seguridad deben ejecutarse antes de aceptar el resultado. Un monitor basado en IA puede priorizar alertas, pero las reglas duras deben bloquear acciones que nunca deberían ocurrir.
El tercero es controlar también la infraestructura aparentemente rutinaria. GitHub anunció que ubuntu-latest migrará de Ubuntu 24.04 a 26.04 entre el 19 de octubre y el 19 de noviembre. Paquetes y versiones cambiarán, y algunos desaparecerán. Si tus workflows dependen de componentes implícitos, pueden romperse sin que hayas cambiado una línea de código.
La lección conecta directamente con los agentes: lo implícito es enemigo de la seguridad. Fija versiones cuando necesites estabilidad, prueba el nuevo runner antes de la migración y evita que un agente “arregle” un pipeline roto mediante cambios amplios que nadie entiende. Primero identifica la causa; después automatiza la solución.
La carrera por los agentes autónomos seguirá. También crecerá el mercado de observabilidad, evaluación y vigilancia automática. Pero el producto ganador no será el que prometa más autonomía: será el que permita saber qué ocurrió, limitar qué podía ocurrir y asignar responsabilidad cuando algo salga mal.
¿Quieres integrar agentes de IA en tu producto sin entregarles las llaves de todo el sistema? Escríbeme. Soy Brayan, desarrollador freelance, y puedo ayudarte a diseñar automatizaciones útiles, auditables y con límites reales antes de que el experimento termine convertido en incidente.