Lo que los directivos deben saber sobre la GenAI

Bienvenidos al pódcast de FS-ISAC, FinCyber Today. Soy Elizabeth Heathfield, directora de Asuntos Corporativos de FS-ISAC. La IA generativa ya no es solo un enfoque innovador, sino un imperativo en toda regla. Por eso, las empresas y los equipos deben ir un paso más allá y aprender a pensar como la IA. Patrick Sullivan, vicepresidente y CTO de Akamai, y yo hemos hablado sobre cómo los equipos de seguridad pueden aprender a aprovechar la naturaleza no determinista de la IA. Muchas gracias por venir. Tengo muchas ganas de hablar contigo sobre esto, porque sé que ambos somos fanáticos de la IA.

Empecemos hablando sobre cómo gestionar el riesgo de esta naturaleza no determinista. Primero, empecemos con lo más básico. ¿Qué es la naturaleza no determinista de los modelos de IA generativa? Sí, creo que es importante empezar por lo más básico. Si analizamos los modelos de IA generativa que tanto nos entusiasman a todos, en esencia, lo que hacen es una gran cantidad de multiplicaciones de matrices complejas y luego intentan completar la siguiente palabra con los resultados más probables. Según cómo se configuren, eligen la opción más probable o una alternativa menos probable.

Entonces, ¿por qué decimos que la IA es no determinista? Porque, si la ejecutas ahora con unas entradas, aunque el modelo sea estático y no haya cambios, obtendrás unos resultados diferentes a los de la próxima vez que la ejecutes. Y así continuamente. Esa es una de las diferencias con muchos de los sistemas que hemos estado utilizado. Es necesario hacer un cambio de mentalidad. Por ejemplo, en las pruebas de seguridad, si tienes una carga latente de inyección preparada que no se activa en un momento determinado, eso no significa que no seas vulnerable, porque la próxima vez que ejecutes exactamente la misma carga contra la misma aplicación, puede activarse y provocar un resultado adverso. Por eso creo que es tan importante que la gente lo entienda.

Y me he dado cuenta de que no basta con comprenderlo. Es necesario verlo en acción. Tienes que usar el teclado, prestar atención a lo que ocurre en pantalla y observar este fenómeno: tienes una carga latente, lo ejecutas todo exactamente igual, y de pronto ves que genera un impacto. Eso te ayuda a comprender lo que significa y las repercusiones para la seguridad.

¿Cómo deberían las personas abordar esto y comprenderlo? Hablo del ámbito empresarial. Es importante que las personas sepan que no estamos hablando de chatbots. Hablamos de flujos más complejos, basados en agentes y demás. Exacto. En los equipos de seguridad actuales hay miembros aprovechando la gran cantidad de información disponible y que están al día de todos los avances. Por lo tanto, creo que los líderes deberían centrarse en el nivel básico. ¿Cómo podemos asegurarnos de que todos los empleados del ámbito de cumplimiento y seguridad reciben esta información? Incluidos los equipos rojos, de auditoría y de seguridad de las aplicaciones.

Algunas personas se aburrirán con la formación básica, pero es importante establecer un punto de partida. Se podría organizar un taller o un hackatón de IA. Así los empleados participarían activamente y observarían qué ocurre. Es importante poner en práctica el enfoque "ver para creer". Luego, alguien lleva a cabo una auditoría y piensas: "¿Qué significa tener garantías?" Aunque una prueba salga correcta, ¿cómo se interpreta eso en un sentido más amplio? La próxima vez que la ejecutes en un sistema estático, ¿podría no serlo? Quieres que todos estén alineados.

Muy bien. Ya hemos establecido las bases. Ahora, hablemos de algunas de las oportunidades que están aprovechando en el sector financiero. ¿Cuáles son las oportunidades que ofrece esta nueva IA generativa? Estamos viendo cómo diferentes empresas están adoptando la IA a ritmos diferentes. Algunos líderes han dicho: "Puede que seamos una organización consolidada, pero no vamos a ceder esta oportunidad a las startups y empresas de fintech más ambiciosas. Vamos a aprovecharla". Está muy bien que estén dispuestos a asumir riesgos. Mientras ocurre todo esto, uno de los primeros ámbitos donde se podrían implementar algunas de estas herramientas es en el desarrollo de copilotos de IA. Ya empezamos a ver los resultados y un aumento de la productividad de los desarrolladores. Según un estudio reciente de uno de nuestros partners en Apiiro, a medida que se desarrollan asistentes de IA generativa, las actualizaciones de software se cuadruplican, según las PR enviadas. De media, podrían aumentar hasta 10 veces en todas las herramientas AST que se están ejecutando. Muchas son redundantes, pero, en general, mejoran la agilidad, lo cual es estupendo para el negocio.

Pero si el equipo de seguridad de las aplicaciones no consigue automatizar este proceso, la competencia le adelantará por la derecha. Primera oportunidad. Otra oportunidad es simplemente la cobertura. Recibimos muchas alertas de todas las herramientas. En los informes de brechas de seguridad a menudo vemos que han ocurrido incidentes graves. Y no es que no se hayan activado las alertas pertinentes. Más bien es que, al activarse de forma aislada, no llegan al umbral para que un humano les preste atención. Si tenemos más cobertura de un sistema de IA que pueda llevar a cabo algunas de esas acciones y reducir ese umbral, el escrutinio sería mayor. Eso es otra de las oportunidades.

Bueno, ya hemos hablado de algunas de las oportunidades. Hablemos ahora de los riesgos. En tu opinión, ¿cuáles son los riesgos que las organizaciones tienen que afrontar? Pensemos en la gestión de riesgos con respecto a unos años atrás, cuando no existía la IA generativa. ¿Qué riesgos conlleva su implementación? El ámbito de la seguridad de las aplicaciones sería uno de ellos. Yo, personalmente, he estado probablemente dos décadas abordando esos riesgos de seguridad. Uno de los errores habituales que afecta a la seguridad de las aplicaciones es mezclar código e instrucciones con datos. Deben ir por separado. Si las instrucciones SQL entran en la base de datos, es un problema. Si las instrucciones del sistema operativo se interpretan, es otra clase de riesgo.

Hemos visto que, con las aplicaciones de IA generativa, los usuarios mezclan las instrucciones y los datos, y eso se convierte en un cóctel de problemas. Entonces, el modelo que debemos considerar es el de la trifecta letal. Es decir, juntar los datos externos, como una consulta o datos de formación que se introducen en el sistema, con datos internos con un RAG o algún otro tipo de sistema que acceda a datos confidenciales, donde guardamos diversas reglas sobre cómo preservar la confidencialidad y quién tiene acceso a esta información, y un tercer componente, el canal de comunicación, como una API. La comunicación directa sería el peor de los casos. Y también el acceso a servicios como el correo o módulos de control de software, un repositorio público o Slack, cualquiera de estas herramientas. Cuando juntamos todo esto en la llamada "trifecta letal", indica que hay cierto nivel de riesgo que necesitamos adoptar tácticas defensivas realmente eficaces. Por eso, si nos limitamos a dos de los tres componentes, probablemente estaremos más protegidos.

Hablando de herramientas que las empresas utilizan y que se basan en los modelos de vanguardia, ¿es en ellas donde se suele mezclar todo esto? Diríamos que sí. Creo que los modelos más avanzados nos proporcionarán esos datos externos. Así que, de entrada, tenemos todo tipo de datos externos, los cuales podrían ser explotados por los ciberdelincuentes. Si saben que lo que buscan está ahí, pueden acceder a ello con una entrada que ellos mismos generen. Si a eso le sumas todo lo demás, la situación es bastante delicada. Eso forma parte de los riesgos a los que estamos expuestos.

¿Cómo se gestiona el riesgo cuando parece que todo va bien, pero en realidad no? ¿Cómo se controla eso? Porque antes vivíamos en un mundo donde todo era blanco o negro. Y ahora... Quiero decir, según los resultados del modelo, todo está bien y parece correcto. ¿Deberíamos utilizar más de un modelo? ¿Cómo deberíamos verificar los resultados? Es una pregunta difícil porque aunque estos sistemas suelen tener razón, si se equivocan también responden con seguridad. Hay varias técnicas que podríamos adoptar. Por ejemplo, un modelo que supervise al modelo y examine variantes de solicitudes anteriores u otros sistemas, dependiendo de la gravedad. Algunas organizaciones dicen: "Aún no estamos preparados para prescindir de las personas. Tendremos una salvaguarda humana".

En seguridad solemos decir que el humano es el eslabón más débil. Por eso resulta un tanto irónico que recurramos a equipos humanos. Esos son algunos de los controles compensatorios. Es algo que debemos tener en cuenta. En este nivel de madurez, a veces nos responderán erróneamente, pero con muchísima seguridad. Con respecto a eso, ¿cómo sabemos dónde está el fallo? Sé que hay evaluaciones y todo un mundo dedicado a diseñar sistemas de IA que comprueban otra IA.

Y también conozco este enfoque de la intervención humana en la IA. Pero quizás los equipos tarden más en comprobarlo todo que en hacerlo ellos desde cero, sin necesidad de adoptar un nuevo sistema tan costoso. Hay varias formas de evaluar y comprobar, ya sea de manera automatizada o humana. Pero también tenemos que cumplir muchos requisitos normativos. ¿Cómo crees que deberíamos hacerlo para no quedarnos atrás y cumplir con los requisitos generales de GRC mientras solucionamos todo esto? Porque, obviamente, nos va a llevar tiempo.

Desde luego. Hay una diferencia enorme entre el ritmo de la innovación en este ámbito, que evoluciona a una velocidad vertiginosa, y el ritmo de adaptación de las normativas. Por eso, queremos facilitarles el trabajo a nuestros compañeros de GRC, los encargados de gestionar este desajuste. Pero al mismo tiempo, gran parte de las normativas más estrictas se basan en principios básicos y muchos de ellos seguirán siendo válidos. Lo básico: ¿tienes un buen inventario de recursos en el que implementar estas tecnologías? Antes hablábamos sobre modelos deterministas y no deterministas. Es verdad que, si conoces el modelo, y tienes el control administrativo del sistema, puedes manipularlo. Puedes configurarlo, ajustar la temperatura a cero y obligarlo a ser predecible. Y ahí es donde la seguridad y el cumplimiento podrían aportar valor y meter presión al negocio. Porque hay ciertos sistemas que no tienen que ser impredecibles. Si se trata de una aplicación aburrida del ámbito legal o contable, por ejemplo, no necesitas una creatividad desbordante. En un agente, tal vez prefieras priorizar que sea previsible.

En otros casos, algunos defienden que es mejor explorar más opciones menos probables para generar lo que percibimos como creatividad en los sistemas. Creo que es fundamental preguntarse si realmente necesitas ese nivel de comportamiento no determinista en un sistema. Debería justificarse si así lo fuera. Vale, entonces quieres intentar que sea lo más predecible posible. Otra cosa que he oído es que algunas personas dividen las tareas. Esto forma parte del flujo de trabajo de los agentes y subagentes. Por ejemplo, este subagente solo realiza esta tarea concreta, por lo que puedes rastrear los errores. Mientras que si solo tienes un flujo de trabajo donde todos hacen un sinfín de pasos, es muy difícil ver dónde está el fallo. Si puedes dividirlo en componentes ínfimos, será más predecible, aunque siga estando automatizado. Sin duda, ese es otro buen ejemplo.

Además, el nivel de supervisión de los equipos de seguridad y cumplimiento ayuda a lograr mejores resultados. Es como un reparto de funciones en el que asignas todas estas tareas. Tenemos la ventaja de trabajar con una base sólida de principios fundamentales. De modo que, en algunos casos, tratar estos sistemas como si no fueran diferentes y supervisarlos como lo hemos hecho tradicionalmente resulta útil. Por otro lado, sin embargo, los atacantes están aprovechando la naturaleza no determinista de la IA como auténticos oportunistas. Operan con libertad y esperan que ocurra algo en lo que no hayamos pensado. Si creamos sistemas muy predecibles y limitamos su poder, también estaríamos dándoles una ventaja a los ciberdelincuentes. ¿Estás de acuerdo?

Sí... Voy a retomar el ejemplo de la seguridad de las aplicaciones. Hemos estado creando API y aplicaciones para que los usuarios puedan aprovecharlas de una forma u otra, guiados por una función de búsqueda. Es posible que, mirando hacia el futuro, descubramos que estamos desarrollando API y aplicaciones web para alimentar a un agente o un chatbot. Si la gente quiere saber qué institución financiera es la más adecuada para ellos dadas una serie de condiciones, quizá se estén ayudando de un agente o un chatbot. Y la forma en la que atendemos a los bots que alimentan el entrenamiento y la manera cómo respondemos a esos agentes que puede requerir un tratamiento diferente para optimizar ese caso de uso, no como lo que hacemos hoy con un visitante web normal. Ese es el caso ideal, donde tenemos un cliente válido detrás de parte de esta tecnología. Obviamente, luego entran en escena los suplantadores y personas que utilizan estas herramientas con fines ilícitos. Y con lo que vamos a tener que lidiar es más automatización, más bots entrando en nuestro sitio y la gestión de identidades delegadas. Soy el propietario de mi identidad y quiero que un agente haga cosas en mi nombre.

Eso es algo que ya estamos empezando a ver, pero aún estamos en una fase inicial. Eso será un reto para los equipos de IAM en lo que respecta a la autorización. Hay mucho trabajo por hacer. Sí. Esto es algo que ya comentamos anteriormente en nuestro panel. También hay el riesgo de terceros, de cadena de suministro y de enésimos proveedores. Porque si nuestros agentes hablan con los agentes de los proveedores, que a su vez hablan con otros agentes, perdemos totalmente la visibilidad. Son como cajas negras apiladas unas sobre otras.

¿Cómo deberíamos abordar eso? Gestionar el riesgo de la cadena de suministro ya es complejo, y ahora estamos añadiendo otra capa nueva con aún menos visibilidad. ¿Cómo deberíamos enfocarlo? Sí, creo que el primer reto es que, del lado del cliente, si alguien usa un agente, hay que identificarlo y tratarlo correctamente, y validar que esa es la identidad delegada que queremos autorizar. Ese es el primer paso. Además, en nuestro back-end, usamos agentes de terceros que luego llaman a enésimas partes. Así es como debemos gestionar el riesgo de nuestra cadena de suministro.

Una firma captó muy bien este problema a principios de año con la carta abierta de Pat Opet a los proveedores de SaaS, señalando de forma directa las lagunas del ecosistema actual. Y creo que parte de la solución vendrá de que los proveedores de SaaS sean más transparentes sobre lo que pasa más abajo en la cadena. Los delincuentes ya fuerzan esta situación. Fue profético. Hemos hablado mucho sobre LLM, que son lo que todos tienen en mente al pensar en IA generativa, pero también se oye hablar mucho sobre el potencial de los modelos de lenguaje pequeños. Sobre todo en casos de uso muy específicos, no hace falta un océano si un lago ya es suficiente.

¿Podría ser esa una forma de gestionar parte de este riesgo no determinista? Creo que sí. Esta es otra área donde la seguridad ejerce presión sobre el negocio y plantea preguntas difíciles: "¿De verdad necesitamos un LLM y todos los riesgos que conlleva?" Modelar las amenazas contra un LLM es una auténtica locura. Ahora tienes que pensar: "¿Puedo preguntar a una app financiera cómo hacer un arma de destrucción masiva?" Eso puede influir en tu modelo, según los datos con los que entrenes. Y cuando los equipos de seguridad cuestionan el negocio, surge la pregunta: "¿Realmente necesitamos un modelo no determinista, o bastaría con uno determinista?" Y eso puedes ajustarlo desde la propia configuración. De igual modo, creo que es necesario plantearse: "¿Necesitamos un LLM o un SLM sería suficiente?" Ese podría ser otro ejemplo de cómo la seguridad podría ayudar al negocio a obtener un mejor resultado para todos.

Esta pregunta se la hacen cada vez más organizaciones y creo que es una evolución positiva. Hemos hablado sobre los modelos y un poco sobre la temperatura, pero también hay que controlar el contexto. No puedes simplemente dejar que el contexto siga creciendo para siempre, porque eso obviamente reduce la calidad del resultado. Además, cuantos más resultados y datos obtienes, más caro resulta. Es necesario limitarlo un poco. También tenemos las indicaciones y como hacerlas más predecibles. Existen bibliotecas y plantillas de indicaciones. Si son más predecibles, los datos que se introducen están más controlados. Así, también podrías gestionar parte del no determinismo en todas estas dimensiones.

Una de las cosas que estoy viendo es que tenemos que educar a nuestro personal y enseñarles todas estas dimensiones para que sepan qué herramientas hay y vean que no es una única solución. ¿Qué opinas? Estoy de acuerdo. Si miramos hacia atrás, a medida que nos fuimos embarcando en nuevas tendencias, fuimos viendo las desventajas de seguridad. Cuando comenzamos a adoptar el comercio electrónico, hubo toda una oleada de inyecciones SQL y las bases de datos saturaron las aplicaciones web. Aprendimos de ello y mejoramos la revisión de las entradas de las aplicaciones. Luego, al migrar a la nube, surgieron una serie de patrones similares. La idea sería que, al entrar en esta tendencia, nos preguntemos si hay alguna lección que podamos sacar de la introducción de estas aplicaciones web conectadas a datos confidenciales en el back-end, o quizá nos sirva lo que aprendimos con la nube. ¿Podemos extraer conclusiones de experiencias previas para que ninguna organización sufra mucho y luego todos aprendamos de ello? Esperemos que ese sea el caso y que podamos reducir el riesgo antes de que dé lugar a brechas graves.

Bueno, creo que hemos tratado muchos temas. Si solo pudieras sacar una conclusión de esta conversación, ¿cuál sería? Hemos hablado sobre muchos temas interesantes. Diría que lo más importante es que el equipo de seguridad de la información entienda lo básico. Es necesario ofrecer una formación básica en IA, idealmente práctica, en la que la gente pueda participar, como un taller o un hackatón. Ya tenemos muchos de los principios básicos. Cuando veamos y comprendamos estas cosas, sabremos dónde aplicarlos. Eso es lo más importante.