La regla 'primero verifica, luego te niegas': cómo quitarle a un agente de IA la costumbre de rendirse ante el primer error

• Tamaño de la regla de autonomía del sistema: 5 KB de texto, cargados al inicio de cada sesión
• Opciones obligatorias que agotar antes de negarse: 6 frentes (archivos, navegador, cuentas, API interna, rutas alternativas, script propio)
• Límite de persistencia por obstáculo: 3–4 intentos significativos con herramientas distintas
• Perímetro de protección contra daños: 42 reglas de vigilancia de comandos, 25 prohibiciones absolutas y un hook de archivos

Durante casi un año se repitió la misma escena cómica en mi trabajo con agentes de IA. Yo asignaba una tarea —por ejemplo, renombrar en masa una lista de registros en un servicio—. El modelo respondía educadamente: 'Lamentablemente, esto no se puede hacer desde la interfaz; entra en la configuración y renómbralos manualmente.' Yo escribía dos palabras: 'Inténtalo tú mismo.' El agente buscaba en el disco, encontraba un archivo de configuración local, editaba tres líneas y resolvía la tarea.

En algún momento me di cuenta de que trabajaba como entrenador motivacional de una red neuronal: sentado junto al ring con una toalla, intentando convencerla de que creyera en sí misma.

¿Por qué la frase 'esto es imposible' de un modelo de lenguaje es una

alucinación y no un hecho?

La raíz del problema está en cómo interpretamos las respuestas de los LLM. Si un agente escribe 'todas las pruebas pasaron con éxito', ningún ingeniero sensato le cree sin ver el registro del test runner. Pero cuando el mismo agente escribe 'esto no se puede hacer, no hay acceso', la gente trata ese rechazo como un hecho médico comprobado.

En realidad, el modelo nunca verificó el acceso. Simplemente cruzó probabilidades estadísticas de su conjunto de entrenamiento y presentó una suposición con forma de afirmación categórica. Para eliminar ese hábito, escribí un módulo de reglas compacto de cinco kilobytes. Su invariante principal dice así: antes de pronunciar cualquier frase de rechazo ('no puedo', 'no tengo esa herramienta', 'hazlo manualmente'), el agente debe presentar un par concreto: qué herramienta usó para comprobarlo y qué código de error o salida obtuvo. Sin una llamada a herramienta de por medio, no lo intentó: adivinó.

¿Qué 6 vías alternativas debe comprobar el agente antes de recurrir a un humano?

En lugar de rendirse prematuramente, el agente ahora sigue una lista estricta de seis niveles: 1. Archivos y bases de datos locales: casi todo lo que muestra una aplicación de escritorio vive en disco en formato JSON, SQLite o caché, y puede leerse y escribirse directamente. 2.

Automatización de navegador: cinco circuitos independientes (desde un navegador instantáneo por CLI hasta perfiles con cookies activas y motores stealth) abren cualquier panel de administración al que yo pueda acceder a simple vista. 3. Cuentas ya configuradas: las credenciales de correo, discos en la nube, calendarios, mensajería y servidores ya están guardadas en un almacén seguro; solo hace falta solicitarlas a través del puente.

4. API web internas: la ausencia de documentación pública no es un callejón sin salida; el agente abre la pestaña de red de DevTools, examina las cabeceras de la petición saliente y la reproduce desde un script. 5.

Cambio de ruta ante un bloqueo externo: si una petición directa choca con un antibot o un timeout, se recurre a un proveedor alternativo o a un espejo. 6. Creación de una microherramienta propia: cuando no existe una utilidad lista, el agente escribe en dos minutos un script de Python de usar y tirar, y resuelve la tarea.

Para que la búsqueda no se convierta en un bucle infinito, hay un límite: tras 3–4 intentos significativos con métodos distintos, el agente se detiene y entrega un informe técnico preciso de cada vía comprobada.

¿Cómo darle a un agente libertad total de acción y garantizar que no

destruya el sistema?

Permitir que un agente autónomo busque por su cuenta rutas alternativas, sin pedir confirmación constante con el botón 'Sí', solo es seguro cuando a su alrededor se ha levantado un perímetro de seguridad a prueba de fallos.

En mi caso, esta protección se reparte en tres capas: un vigilante de comandos de terminal con 42 reglas revisa cada llamada antes de ejecutarla, una lista negra de 25 prohibiciones absolutas bloquea de forma permanente borrar directorios raíz, formatear discos, eliminar tablas de bases de datos y forzar `git push --force`, y un hook de archivos independiente protege contraseñas y núcleos de configuración frente a sobrescrituras. Además, cualquier texto externo proveniente de correos y chats se marca como dato no confiable, para descartar inyecciones de prompt.

Puedes conseguir este módulo de reglas junto con los vigilantes de seguridad en mi canal [@jemal_hamidun](https://t.me/jemal_hamidun). Toda esta arquitectura de autonomía segura viene integrada de fábrica en [Nomad AI](https://nomadnet.ai). Puedes aprender a configurar este tipo de entornos para tus propias tareas en [Hamidun Academy](https://academy.hamidun.com) (con 72 horas de prueba gratuita), y la base completa de más de 370 habilidades junto con masterminds en vivo te esperan en [Vibe Club](https://hamidun.com/club).