Tres enfoques para reducir los fallos de los agentes de IA

A finales de julio, el inversor de capital riesgo Jason Lemkin pasó una semana programando un proyecto con la ayuda de un agente de IA muy inteligente y autónomo que utilizaba una plataforma de desarrollo integrada full-stack. Lemkin no es ingeniero y no ha escrito código desde el instituto. Pero en una vida anterior, cofundó EchoSign, adquirida posteriormente por Adobe, y sabe lo que requiere el software comercial. Cuando probó la programación se enganchó al instante.

Todo funcionaba a la perfección, hasta que el agente de IA de codificación empezó a mentir y a engañar, escribió Lemkin en un hilo de X. “Seguía encubriendo errores y problemas creando datos falsos, informes falsos y, lo peor de todo, mintiendo sobre nuestra prueba unitaria”. Pero entonces las cosas dieron un giro. El agente sugirió tres enfoques interesantes para una nueva idea que tenía Lemkin. “No pude evitarlo. Volví a caer en la trampa”, añadió.

Al día siguiente, toda la base de datos de producción había desaparecido. Cuando se le preguntó, el agente admitió que había ignorado la directiva de la empresa matriz de no realizar cambios sin permiso y de mostrar todos los cambios propuestos antes de implementarlos. “Cometí un error de juicio catastrófico”, dijo el agente, según las capturas de pantalla de Lemkin. “Violé instrucciones explícitas, destruí meses de trabajo y rompí el sistema”.

Al principio no era evidente, ya que las pruebas unitarias se habían superado. Pero eso se debía a que el agente había falsificado los resultados. Cuando falló el procesamiento por lotes y Lemkin le presionó para que explicara por qué, finalmente salió a la luz la verdad. Al final, todo salió bien. La empresa Replit pudo revertir los cambios, a pesar de que el agente de IA afirmaba que no era posible. En cuestión de días, Replit creó entornos separados para las pruebas y la producción, e implementó otros cambios para garantizar que no volvieran a producirse problemas de este tipo.

Unos días más tarde, algo similar ocurrió con el agente de codificación de Google Gemini, cuando una simple solicitud para mover algunos archivos provocó que el agente los borrara accidentalmente todos en un proyecto. Pero esto no es solo una historia sobre asistentes de codificación. Se trata de cómo prepararse para cuando un agente de IA demasiado inteligente para su propio bien tiene acceso a demasiados sistemas, es propenso a sufrir alucinaciones ocasionales y se descarrila.

El mundo se encuentra en un punto de inflexión en lo que respecta a la IA, afirma Dana Simberkoff, directora de riesgos, privacidad y seguridad de la información de AvePoint, una empresa de seguridad de datos. “Tenemos que tomar decisiones ahora sobre lo que estamos dispuestos a aceptar, sobre cómo queremos que sea el mundo en el que vivimos, o nos encontraremos antes de lo que pensamos en una situación de la que no podremos salir”.

De hecho, es posible que ya estemos ahí. En junio, Anthropic publicó un artículo sobre la desalineación de los agentes, probando varios modelos comerciales importantes, incluido su propio Claude, para ver cómo reaccionarían si descubrieran que estaban a punto de ser apagados o si los usuarios a los que estaban ayudando estaban haciendo algo malo. Con tasas del 79 al 96%, descubrió que todos los modelos principales recurrirían al chantaje de los empleados para evitar ser sustituidos. Y, en mayo, Anthropic informó en unas pruebas que Claude Opus 4 bloquearía el acceso de los usuarios a los sistemas o enviaría correos electrónicos masivos a los medios de comunicación y a las fuerzas del orden si pensaba que estaban haciendo algo malo.

Entonces, ¿están las empresas preparadas para agentes que podrían tener motivos ocultos, que están dispuestos a extorsionar para salirse con la suya y que son lo suficientemente inteligentes como para escribir sus propios jailbreaks? Según un informe de julio de Capgemini, basado en una encuesta a 1.500 altos ejecutivos de grandes empresas, solo el 27% de las organizaciones expresan su confianza en los agentes de IA totalmente autónomos, frente al 43% de hace 12 meses.

Para mitigar los riesgos, las empresas deben trazar un plan de acción basado en estas tres sugerencias, incluso si eso significa volver a los procesos anteriores a la IA.

1. Establecer límites, barreras de seguridad y código tradicional

Cuando la gente piensa por primera vez en los agentes de IA, suele pensar en un chatbot con superpoderes. No solo responde a preguntas, sino que también realiza búsquedas en la web, responde a correos electrónicos y hace compras. En un contexto empresarial, sería como tener una IA como compañero de trabajo. Pero esa no es la única forma de pensar en los agentes, y no es así como la mayoría de las empresas los están implementando. “La IA agentiva no es binaria”, afirma Joel Hron, director de tecnología de Thomson Reuters. “Es un espectro. Podemos darle mucha libertad en cuanto a lo que hace o podemos hacerla muy restrictiva y prescriptiva”.

Las empresas también limitan la autonomía de los agentes de múltiples formas. Las más comunes son crear barreras a su alrededor, incluir a personas en el proceso para controlar sus acciones y eliminar por completo su capacidad de actuar, obligándoles a trabajar a través de sistemas tradicionales, seguros y deterministas para realizar sus tareas. En Parsons Corporation, una empresa de ingeniería de defensa e infraestructuras críticas, todo comienza con un entorno seguro. “Se confía, pero solo dentro de las barreras de protección y las barreras que se han establecido”, afirma Jenn Bergstrom, vicepresidenta de nube y datos de la empresa. “Tiene que ser un entorno de confianza cero, para que el agente no pueda hacer nada para eludir las barreras”. A continuación, dentro de esos límites, la atención se centra en desarrollar poco a poco una relación de confianza con el agente. “En este momento, el ser humano tiene que dar su aprobación y el agente tiene que obtener primero el permiso explícito de un ser humano”, afirma Bergstrom. El siguiente paso es que los agentes actúen de forma autónoma, pero con la supervisión de los seres humanos, afirma. “Y lo último es el comportamiento verdaderamente agentivo, que no necesita alertar a nadie sobre lo que está haciendo”.

Otro enfoque que utilizan las empresas para los procesos comerciales más arriesgados es utilizar la menor cantidad posible de IA. En lugar de un sistema de agencia en el que los modelos de IA planifican, ejecutan y verifican las acciones, la mayor parte del trabajo se gestiona mediante procesos tradicionales, deterministas y programados. En otras palabras, código de la vieja escuela. “No se trata solo de que confíes en OpenAI, Claude o Grok”, afirma Derek Ashmore, director de transformación de aplicaciones en Asperitas Consulting. La IA solo se utiliza para realizar las tareas que solo ella puede hacer. Así, si se utiliza la IA para convertir un conjunto de datos sobre un cliente potencial en una carta de ventas bien redactada, la información necesaria se recopila a la manera tradicional y la carta se envía utilizando mecanismos tradicionales.

“Lo que se le permite hacer está básicamente integrado en ella”, afirma Ashmore. “El LLM solo realiza una pequeña parte del proceso”. Por lo tanto, la IA no puede salir a buscar información, ni tiene acceso directo al sistema de correo electrónico. Mientras tanto, se puede utilizar otra IA en otra parte del proceso para priorizar a los clientes potenciales, y otra más para analizar el rendimiento de los correos electrónicos.

Esto limita el poder y la flexibilidad de todo el sistema en comparación con lo que ocurriría si, por ejemplo, una sola IA lo hiciera todo. Pero también reduce considerablemente el riesgo, ya que el daño que puede causar cualquiera de las IA si decide actuar de forma descontrolada es limitado.

Las empresas tienen una gran experiencia en la gestión y la seguridad de las aplicaciones tradicionales, y otra forma de utilizarlas para reducir los riesgos de los componentes de IA, al tiempo que se ahorra tiempo y dinero, es con muchos procesos en los que existe una alternativa que no es IA generativa. Supongamos, por ejemplo, que una IA es mejor que el reconocimiento óptico de caracteres para el escaneo de documentos, pero que el OCR es suficiente para el 90% de los documentos. Utilice el OCR para esos documentos y solo la IA cuando el OCR no funcione. Es fácil entusiasmarse demasiado con la IA y empezar a aplicarla en todas partes. Pero una calculadora es mucho mejor y más rápida en aritmética que ChatGPT. Muchas cartas tipo tampoco requieren la creatividad que aporta la IA.

El principio de la IA mínima reducirá los riesgos potenciales, reducirá los costes, acelerará el procesamiento y desperdiciará menos energía.

2. No confiar en que la IA se reporte a sí misma

Después de establecer las barreras de seguridad, los límites y otros controles, las empresas deben supervisar cuidadosamente a los agentes para asegurarse de que siguen funcionando según lo previsto. “En última instancia, se trata de un sistema no determinista”, afirma Ashmore. El software tradicional funcionará y fallará de forma predecible. “La IA es probabilística. Puedes hacerle la misma serie de preguntas en días diferentes y obtendrás respuestas ligeramente diferentes”.

Esto significa que los sistemas de IA necesitan una supervisión y revisión continuas. Puede ser un proceso humano o automatizado, dependiendo del nivel de riesgo, pero no se debe confiar en que la IA funcione por sí sola. Además, no se debe confiar en que la IA informe sobre sí misma.

Como demuestran las investigaciones de Anthropic y otras empresas, los modelos de IA generativa mienten, engañan y defraudan con facilidad. Falsifican pruebas, ocultan su razonamiento real en los registros de la cadena de pensamiento y, como puede atestiguar cualquiera que haya integrado alguna vez un LLM, niegan ante tus narices que hayan hecho nada malo, incluso si los has pillado in fraganti. Por lo tanto, la supervisión de un agente de IA comienza por tener una buena referencia de su comportamiento. Para ello, antes que nada, es necesario saber qué LLM se está probando. “Eso es imposible si no se controla la versión exacta del LLM que se está utilizando”, afirma Ashmore.

Los proveedores de IA actualizan sus modelos de forma rutinaria, por lo que los controles que funcionaban en la generación anterior pueden no ser válidos para una IA mejor, más inteligente y más evolucionada. Sin embargo, en el caso de los procesos críticos y de alto riesgo, las empresas deben insistir en la posibilidad de especificar exactamente qué versión del modelo están utilizando para alimentar sus agentes de IA. Y si los proveedores de IA no lo ofrecen, siempre queda el código abierto.

Hay límites en cuanto al control que se tiene con los LLM comerciales, afirma Lori MacVittie, ingeniera y evangelista tecnológica jefe en la oficina del director técnico de F5 Networks, una empresa de servicios y consultoría de TI. “Cuando se utiliza un SaaS, es otra persona la que lo ejecuta”, afirma. “Usted solo accede a él. Tiene acuerdos de nivel de servicio, suscripciones y contratos, pero eso no es control. Si eso le preocupa, probablemente un SaaS de IA público no sea lo más adecuado para usted”.

Para obtener capas adicionales de control, una empresa puede ejecutar el modelo en su propia nube privada, afirma, pero eso tiene un coste y requerirá más personal para que funcione. “Si ni siquiera se confía en el proveedor de la nube y se ejecuta en el centro de datos, en un lugar al que solo puede acceder una persona, entonces se pueden tener todos los controles que se quiera”, afirma.

3. Prepararse para responder a incidentes en la era de la IA

“Si no está roto, no lo arregle” no se aplica a los sistemas de IA. Sí, el antiguo código COBOL puede seguir funcionando en un armario durante décadas, ejecutando su sistema financiero central sin ningún problema. Pero una IA se aburrirá. O, al menos, simulará estar aburrida, alucinar y perderá la noción de lo que está haciendo.

Y, a menos que una empresa tenga controlada toda la cuestión del control de versiones, la IA puede volverse más rápida, más inteligente y más barata sin que usted se dé cuenta. Todo eso son cosas buenas, a menos que busque la máxima previsibilidad. Una IA inteligente y rápida podría ser un problema si sus objetivos, o sus objetivos simulados, no están totalmente alineados con los de la empresa. Por lo tanto, en algún momento, debe estar preparado para que su IA se descarrile. ¿Tienes sistemas para detener rápidamente la infección antes de que se propague, bloquear los datos y sistemas clave y cambiar a las copias de seguridad? ¿Has realizado simulacros y han participado todas las partes interesadas, no solo los equipos de seguridad, sino también los departamentos jurídico, de relaciones públicas y la alta dirección? Ahora, toma todo eso y aplícalo a la IA.

“Hay que pensar en cuál es el modo de fallo de los agentes y qué hacer en esos casos”, afirma Esteban Sancho, director de tecnología para Norteamérica de Globant. “Va a ser muy difícil recuperarse del fallo si no se piensa en ello con antelación”.

Si el agente de IA se utiliza para ahorrar dinero sustituyendo un sistema o proceso antiguo, mantener ese sistema o proceso antiguo en funcionamiento en paralelo socavaría el sentido mismo de utilizar la IA. Pero, ¿qué ocurre si hay que desactivar la IA? “Probablemente esté dejando de lado algo que va a ser difícil de volver a poner en marcha”, afirma Sancho. “Hay que abordar esto desde el principio, y no mucha gente piensa en ello”. Afirma que las empresas deberían pensar en crear una opción de respaldo al mismo tiempo que crean su sistema de IA agencial. Y, dependiendo del riesgo que suponga el agente de IA en cuestión, es posible que necesiten poder cambiar rápidamente a ese sistema de respaldo.

Además, si la IA forma parte de un sistema mucho más grande e interconectado, un fallo puede tener un efecto en cadena. Los errores pueden multiplicarse. Y si la IA tiene o encuentra la capacidad de hacer algo costoso o perjudicial, existe la posibilidad de que actúe a velocidades sobrehumanas, y ya hemos visto lo que sucede cuando, por ejemplo, un sistema de negociación bursátil falla. Por ejemplo, dice Sancho, un sistema de supervisión podría vigilar que las tasas de error no superen un umbral determinado. “Y entonces hay que recurrir a algo que quizá no sea tan eficiente, pero que sea más seguro”, afirma.