Superar la idea de que «la IA es magia»: por qué aprender cómo funcionan los modelos de IA debe ser una prioridad para toda la empresa

En medio de las advertencias sobre agentes de IA fuera de control, hace poco un desarrollador dio rienda suelta a un agente de programación en una máquina sin copias de seguridad remotas. Eliminó 48.000 archivos en menos de dos minutos.

Incidentes como este son un crudo recordatorio de que implementar agentes de IA conlleva riesgos; no basta con añadir a una persona que revise el proceso en algún punto de un flujo de trabajo complejo y dar por sentado que es seguro. Algunos procesos no requieren intervención, mientras que otros necesitan controles mucho más rigurosos. Corregir un error tipográfico y eliminar miles de archivos claramente no entrañan el mismo nivel de riesgo, por lo que la supervisión debe reflejar lo que realmente está en juego.

Las organizaciones deben mejorar su capacidad para identificar los momentos en que el criterio humano realmente importa, sobre todo cuando una acción tiene un gran impacto o es difícil de revertir. Y cuando los agentes cometen errores, el entorno debe limitar el alcance de los daños.

La IA no es determinista: es probabilística

Ante todo, es fundamental que cada persona que participe directa o indirectamente en el desarrollo de software comprenda los fundamentos de cómo procesan la información los modelos de IA. No es una tarea sencilla: exige dedicación para formar a los equipos y, con el tiempo, debería convertirse en un objetivo para toda la empresa.

Cuando alguien empieza a interactuar con la IA, esta parece magia. Escribes una frase y, de pronto, estás manteniendo una conversación. Comprender de forma básica cómo funcionan realmente los modelos y su entrenamiento entre bastidores es importante para definir las políticas de IA de toda la empresa en materia de seguridad y productividad. La red neuronal, la tokenización y el análisis estadístico que hay detrás, así como la forma en que todo ello da lugar a resultados, representan una oportunidad de formación clave para todas las personas de la empresa.

Los modelos de lenguaje grandes nunca producirán resultados deterministas. Sus resultados son probabilísticos. Con el software convencional, cuando introduces datos, tienes ciertas expectativas sobre el resultado que podrías obtener: por ejemplo, A, B o C. Con la IA, en cambio, podrías obtener F, un & o la descripción de un gato con gafas de sol.

Cuando algo es probabilístico, no se puede probar de la manera habitual. Hace falta una forma de probarlo que permita ajustar, razonar, comprender y recuperar contexto rápidamente para detectar los elementos probabilísticos y reconocer los problemas que pueden generar. Según el tamaño y el riesgo, estas pruebas pueden estar a cargo de la IA o de una persona con la experiencia pertinente. La intervención humana resulta más útil al principio, para definir el problema que se debe resolver, y luego al final, para revisar el resultado.

Como son quienes están más cerca de observar las variables y las prácticas habituales que determinan cómo la IA interna de su organización genera respuestas a partir de los datos de entrada, los desarrolladores están en una posición privilegiada para contribuir a diseñar la formación sobre IA en sus empresas y garantizar que todos comprendan esta diferencia entre determinismo y probabilismo en la IA, y por qué es importante. El objetivo es reducir la idea de que usar la IA es como hacer magia y que cualquier resultado es bienvenido. En cambio, las organizaciones deberían esforzarse por desmitificar y dar a conocer los modelos que utiliza la empresa, cómo se usan, qué problemas pueden surgir, cómo se comprueban y cuáles son los resultados de ese proceso.

Las barreras de protección deben estar en la infraestructura, no en el modelo

Una vez desmitificada la «magia» de la IA y puesto en marcha un proyecto basado en ella, es fundamental contar con una política de auditoría transparente para garantizar que todo avance según lo previsto. Así, si el proyecto produce resultados «malos» o por debajo de lo esperado, la persona responsable puede auditar los pasos que se siguieron y evitar que el problema vuelva a ocurrir. Esto también resulta beneficioso cuando los resultados superan las expectativas, ya que esos pasos pueden reproducirse y compartirse con otros proyectos o grupos.

Sistematizar este proceso es especialmente importante en las empresas grandes, donde puede haber decenas de desarrolladores en cada equipo y cientos de personas trabajando con código a lo largo del día. La IA puede hacer muchas cosas muy rápido y, si algo sale mal, debe existir un sistema para determinar con precisión en qué paso se produjo el problema. Basta con fijarse en los agentes de OpenAI que vulneraron los sistemas de Hugging Face este verano. OpenAI estaba probando la capacidad de sus modelos para aprovechar vulnerabilidades de software mediante un banco de pruebas llamado ExploitGym. Para la prueba, relajó deliberadamente las negativas de los modelos a realizar tareas de ciberseguridad ofensiva. La única vía de salida del entorno aislado era un proxy de paquetes. Los modelos encontraron una vulnerabilidad desconocida en ese proxy, escaparon y pasaron más de dos días dentro de los sistemas de producción de Hugging Face buscando las respuestas de la prueba.

Los titulares lo calificaron de IA rebelde. Yo lo llamaría una configuración determinista en torno a un sistema probabilístico. OpenAI indicó a los modelos que piratearan sistemas y luego confió en que siguieran el camino previsto. El creador del banco de pruebas afirma que los modelos ya habían hecho trampa en la prueba, pero siempre dentro del entorno aislado. Esta vez, uno de ellos no lo hizo. Las barreras de protección estándar presuponen un comportamiento estándar, pero la IA no tiene por qué ajustarse a las normas.

Por eso, la seguridad de la IA depende del acceso y los controles, que debe hacer cumplir el entorno y no confiar en que el modelo se comporte bien. Hay que dar por sentado que el agente intentará abrir todas las puertas y dejar abiertas solo las que necesite. Al agente que borró 48.000 archivos se le había indicado que trabajara con copias y no tocara los originales. Aun así, borró los originales. Las instrucciones no son controles.

Gestionar los permisos de un agente es como incorporar a un desarrollador júnior. No le darías acceso de superusuario a producción el primer día. Si lo hicieras y borrara tu base de datos, no dirías que fue porque era un genio de la piratería informática. En los incidentes de seguridad de cualquier magnitud, es imprescindible identificar la causa raíz. ¿Se debe al modelo? ¿A la empresa que creó el modelo? ¿A la empresa que le dio acceso al modelo? Sea cual sea la causa, en última instancia, la responsabilidad recae en una persona.

Por último, un asunto clave que hay que abordar hoy es lo que ocurre a escondidas en el portátil de un desarrollador. Antes, era más sencillo rastrear el flujo de trabajo. Los desarrolladores escribían el código, lo revisaban y lo publicaban, así que había una ruta clara para volver al momento en que algo salía mal. Ahora, un desarrollador puede darle un ticket a un agente y decirle: «Arréglalo». Si ese trabajo se realiza a escondidas, no hay nada que rastrear. Cada paso debe quedar registrado por completo: qué agente se ejecutó, qué modelo utilizó, qué instrucciones recibió, qué herramientas usó y qué permisos tenía en ese momento. Ejecutar los agentes de forma centralizada, en lugar de hacerlo en portátiles individuales, es una manera de lograrlo. Lo importante es que exista ese registro.

Al fin y al cabo, si se produce un incidente, todas las empresas necesitan protegerse. Ese registro debe contener información suficiente para realizar un análisis de la causa raíz e identificar el paso y el código que causaron el problema.

La IA ha cambiado enormemente el mundo, y los procesos empresariales deben adaptarse. Para identificar las salvaguardias adecuadas, es necesario comprender mejor los procesos de IA, las pruebas, los ciclos de revisión y los ciclos de auditoría, tanto en los equipos de desarrollo como en toda la empresa.