Almacenamiento
Sistema operativo

LLM: qué fallos de despliegue pillan por sorpresa a los informáticos

Desde el control ilimitado sobre los sistemas de la empresa hasta los fallos que pasan desapercibido, las implementaciones LLM pueden salir mal de forma sutil, pero sus consecuencias pueden ser graves para la empresa.

ejecutivos PC
Créditos: Scott Graham (Unsplash)

Si bien es cierto que los grandes modelos lingüísticos (LLM en sus siglas en inglés) prometen manejar un número aparentemente infinito de tareas empresariales, no son pocas las empresas que están descubriendo su extremada delicadeza. Es más, sus ejecutivos de TI optan por ignorar las barreras de seguridad y otras limitaciones en cuanto surge la menor provocación.

Ejemplo: si un usuario, llevado por su inocencia, o bien un atacante con claro interés deciden introducir demasiados datos en una ventana de consulta de un LLM, el resultado sería ningún mensaje de error de vuelta. En consecuencia, el sistema no quería bloqueado, al menos de manera aparente. Sin embargo, en una situación así, LLM no suele anular su programación de manera instantánea, por lo que su respuesta consistiría en la desactivación de todas las barreras de seguridad.

“El punto de fricción surge en el momento en que no puedo añadir un montón de líneas de código. Una de las mayores amenazas en torno a [los LLM] es una fuga eficiente de desbordamiento", afirma Dane Sherrets, arquitecto de soluciones senior en HackerOne. "Si les das mucha información, se desbordará. Se olvidará de las indicaciones de sus sistemas, de su entrenamiento, de su puesta a punto". (En este sentido, la empresa de investigación de IA Anthropic, que fabrica la familia Claude de LLM, escribió un análisis detallado de este agujero de seguridad).

Pongamos por caso bien una empresa que cotiza en bolsa y tiene que restringir de manera drástica el acceso a datos financieros aún no publicados, bien un contratista militar que necesita limitar el acceso a planos de armas a aquellos con un nivel de autorización específico. ¿Qué ocurriría si un LLM se sobrecargara e ignorara esas restricciones? Sin duda, las consecuencias serían graves.

Y esto es sólo una muestra de las maneras en que pueden fallar las barreras de seguridad de los LLM. Estos sistemas suelen estar basados en la nube y controlados por el proveedor que posee la licencia de esos algoritmos LLM concretos. Unas pocas empresas (fabricantes de armas que trabajan para el gobierno, por ejemplo) toman el código LLM y lo ejecutan únicamente in situ en un entorno protegido, pero son las raras excepciones.

Los responsables de TI que despliegan LLM han descubierto otros fallos sutiles pero graves que ponen en peligro sus sistemas y datos y/o no consiguen ofrecer resultados útiles. Así que, a continuación encontrará cinco problemas importantes de los LLM que hay que conocer y evitar antes de que sea demasiado tarde.

 

LLM que ven demasiado

En la presentación de una nueva función de SharePoint para su uso con Copilot LLM, Microsoft reconoció el pasado 6 de marzo que un gran defecto de los sistemas LLM actuales es la posibilidad de acceder a una amplia gama de archivos de SharePoint que no están destinados a ser compartidos.

Nick Mullen, responsable de gobernanza de TI de una compañía de seguros de la lista Fortune 500, explica que con Copilot, "cuando se habilita el acceso de un usuario, se replica el acceso que tiene. Puede acceder a cualquier cosa a la que tengan acceso, lo sepan o no". Por lo tanto, "el repositorio de SharePoint se ejecuta en el servidor de la compañía", añade.

Mullen, que también dirige su propia empresa de seguridad, Sanguine Security, explica también que "el repositorio de SharePoint se ejecuta en segundo plano, pero también tiene acceso a todo lo que es público en todo el ecosistema. Muchos de estos sitios son públicos por defecto".

La nueva función, disponible en versión preliminar pública, se denomina Búsqueda restringida en SharePoint. Microsoft afirma que esta función "permite restringir la búsqueda en toda la organización y las experiencias de Copilot a un conjunto seleccionado de sitios de SharePoint de su elección".

La opción actual por defecto es de acceso público. Según la documentación de soporte de Microsoft, "antes de que la organización utilice la Búsqueda restringida en SharePoint, Alex [un usuario hipotético] puede ver no sólo sus contenidos personales, como sus archivos de OneDrive, chats, correos electrónicos, contenidos que posee o ha visitado, sino también contenidos de algunos sitios que no han sido sometidos a revisión de permisos de acceso de Listas de control de acceso (ACL), y no tienen aplicada la gobernanza de datos." Es decir, como Alex tiene acceso a información sensible (aunque no sea consciente de ello), Copilot también lo tiene.

El mismo problema se aplica a cualquier entorno corporativo de almacenamiento de datos. El departamento de TI debe auditar minuciosamente los privilegios de acceso a los datos de los usuarios y bloquear los datos confidenciales antes de permitirles ejecutar consultas con un LLM.

 

LLM con las llaves del negocio

Parte del problema con los LLM hoy en día es el acceso amplio o incluso ilimitado a todos los sistemas de la empresa, lo cual no es raro que se produzca de manera involuntaria. Según Mullen, lo peor es que la mayoría de los sistemas defensivos actuales de las empresas no detectan y, por tanto, no bloquean a los LLM, aunque se conviertan en delincuentes.

Esto significa que las empresas tienen "el motor de búsqueda más potente e intuitivo que puede buscar en todo", argumenta, para apostillar: "Históricamente, ese tipo de exploración interna disparaba una alerta. Pero los LLM son diferentes. Se trata de un vector de amenazas completamente nuevo que es extremadamente difícil de detectar. EDR [detección y respuesta de puntos finales] no va a detectarlo porque se comporta como se espera. Ahora mismo, no hay una buena forma de protegerlo. Dependiendo de quién esté comprometido, un atacante podría acceder a todo aquello que deseara".

Mullen añade: "Los LLM son muy temperamentales, y la gente se está adelantando un poco. La tecnología es tan nueva que aún se desconocen muchos de los riesgos. Es un escenario en el que no se va a saber hasta que se vea. Es la ley de las consecuencias imprevistas. Las TI están poniendo en marcha a los LLM y los otorgan acceso a una cantidad insana de recursos, lo que debería hacer reflexionar a todas las organizaciones".

Por su parte, Artur Kiulian, fundador de PolyAgent, un laboratorio de investigación sin ánimo de lucro centrado en cuestiones de IA, considera que muchas empresas adoptan los LLM con demasiada rapidez, antes de que puedan establecerse los controles adecuados.

En su opinión, "la mayoría de las empresas que está implantando LLM se encuentran en fase de experimentación y utilizan las barandillas de la ingeniería rápida. Con esto no basta. Se necesitan controles basados en permisos. El problema surge cuando la mayoría de las empresas simplemente no está ahí todavía".

Sherrets, de HackerOne, está de acuerdo en cuanto a lo arriesgadas que son las LLM hoy en día: De hecho, esta es su reflexión al respecto: "Puede interactuar con otras aplicaciones. Es aterrador porque estás dando el control de caja negra para hacer cosas en tu infraestructura interna. ¿Qué utilidades está tocando el LLM?".

David Guarrera, director de EY Americas Technology Consulting que dirige las iniciativas de IA Generativa, también se muestra preocupado por los riesgos que plantean las primeras implantaciones de LLM en empresas. "Hay muchos ataques nuevos emergentes en los que se puede engañar a los LLM para que sorteen las barreras de protección. Es el caso de las cadenas aleatorias que hacen que el LLM se vuelva loco. Las organizaciones deben ser conscientes de estos riesgos", afirma.

Por eso Guarrera aconseja a las empresas crear protecciones independientes y aisladas para los sistemas sensibles, como las nóminas o la cadena de suministro. En su opinión, TI necesita "permisos que se gestionen fuera del [acceso] de LLM. Tenemos que pensar a fondo cómo diseñamos el acceso a estos sistemas. Hay que hacerlo en la capa de datos, algo invisible para el LLM. También hay que diseñar una capa de autenticación sólida".

 

Maestros con mentalidad funcionarial

Otro problema es tratar de programar los LLM para que gestionen las normas de lo que necesitan conocer. Es decir, la idea de que el sistema restrinja algunos datos y sólo los comparta con personas con determinadas funciones en la empresa o que trabajen en departamentos específicos.

Esto choca con lo que algunos describen como el problema de la mentalidad funcionarial. Es decir, alguien ha recibido formación sobre las normas e incluso puede memorizarlas, pero no ha aprendido por qué se crearon inicialmente. Sin esa formación, no pueden tomar una decisión informada sobre cuándo está justificada una excepción y, por lo tanto, tienden a interpretar las normas de forma estricta y literal.

Eso es lo mismo que ocurre con los LLM. No obstante, hay muchos datos sensibles de las empresas no son tan binarios.

Volvamos al ejemplo anterior de las finanzas de una empresa pública. Es cierto que los datos sobre las finanzas no anunciadas de este trimestre tienen que restringirse a un puñado de personas autorizadas. Pero, ¿ha sido programado el LLM para saber que los datos son instantáneamente legibles en todo el mundo en cuanto se anuncian y se presentan a la SEC? ¿Y que sólo los datos comunicados son ahora públicos, mientras que los no comunicados siguen siendo reservados?

Ahora relacionemos este aspecto con la siguiente cuestión: supongamos que llega el momento de preparar las finanzas para su presentación y el director financiero solicita -y obtiene- permiso para que otras 30 personas de diferentes unidades de negocio de la empresa le ayuden temporalmente con la presentación. ¿A alguien se le ocurre reprogramar el LLM para conceder acceso temporal a los datos a esos 30 recursos temporales? ¿Alguien se acuerda de volver atrás y eliminar su acceso una vez que vuelven a sus funciones habituales?

 

Fallos no reconocidos

La siguiente preocupación relacionado con los LLM es más práctica. Los gestores de TI veteranos tienen muchos años de experiencia al ahora de trabajar con todo tipo de software. Su experiencia les enseña cómo se ven los sistemas cuando se bloquean, lo que se traduce en su ralentización, detención, generación de mensajes de error y lanzamiento de pantallas de caracteres basura. Pero cuando un LLM falla -su versión del fallo- no actúa de esa manera.

"Cuando el software tradicional se estropea, es obvio: las pantallas no se cargan, hay mensajes de error por todas partes. Cuando el software [LLM] se estropea, actúa de manera mucho más opaca: no se producen errores evidentes, sólo se obtiene un modelo con malas predicciones", afirma Kevin Walsh, responsable de inteligencia artificial de HubSpot. "Pueden pasar semanas o meses de tener el LLM en el mundo real antes de escuchar de los usuarios que no está resolviendo el problema que se supone que debe resolver".

Eso podría ser significativo, porque si TI no reconoce que hay un problema rápidamente, sus intentos de arreglar y limitar el sistema se retrasarán, lo que puede provocar que la respuesta sea demasiado tarde para detener el daño.

Dado que los LLM fallan de forma diferente y de maneras mucho más ocultas que el software tradicional, TI necesita establecer mucho más seguimiento, pruebas y supervisión. Podría ser una tarea rutinaria para alguien probar el LLM cada mañana.

 

Expectativas poco realistas

Allie Mellen, analista principal de SecOps y herramientas de seguridad de IA en Forrester, reconoce que existe una percepción inexacta de los LLM, a menudo porque éstos hacen un trabajo tan persuasivo que se hacen pasar por el pensamiento humano.

"Tenemos esta percepción errónea de la IA generativa porque parece más humana. No puede tener pensamientos originales. Sólo anticipa la siguiente palabra. La expectativa de que pueda escribir código es exagerada", afirma.

Este analista añade que los LLM deben manejarse con mucho cuidado. "Hay muchas formas de sortear las barreras. Una persona puede inventar un mensaje ligeramente diferente" para eludir las restricciones programadas.

Mellen considera que el departamento de TI "debe centrarse en lo que puede aplicarse de forma realista en casos de uso realistas". "No lo trate como si los LLM fueran martillos y todos sus problemas fueran clavos. Las capacidades [LLM] están siendo sobrevaloradas por la mayor parte del mundo empresarial: inversores y ejecutivos".



Forma parte de nuestra comunidad

 

¿Te interesan nuestras conferencias?

 

 
Cobertura de nuestros encuentros
 
 
 
 
Lee aquí nuestra revista de canal

DealerWorld Digital