Resumen
- Los riesgos de seguridad de la información de la inteligencia artificial generativa se pueden clasificar en dos categorías principales: fuga de información e introducción de vulnerabilidades
- La fuga de información puede provenir de datos públicos, fugas en las instrucciones y la exposición de datos personales
- La introducción de vulnerabilidades surge de problemas de calidad comunes en el código generado por la IA
- Ejemplos recientes de estos riesgos hacen que sean concretos y no solo hipotéticos.
- Las formas de mitigar estos riesgos son posibles mediante una gobernanza adecuada, que puede incluir:
- Suscribirse a API cerradas
- Construir una fachada de API para facilitar la auditabilidad y el control de acceso
- Autohospedar uno o más LLM de código abierto internos
- Utilizar LLM orientados al dominio para crear soluciones más adecuadas y minimizar la fuga de datos
- Fortalecer las prácticas de CI/CD (Integración Continua/Entrega Continua) e implementar prácticas de ingeniería de calidad comprobadas como requisito previo para el uso de la IA generativa
- Revisar las políticas relacionadas con la publicación de datos visibles al público
La inteligencia artificial generativa, en particular los Modelos de Lenguaje Grandes (LLM) como ChatGPT, ofrecen un inmenso potencial para resolver una amplia variedad de problemas empresariales, desde la creación de documentos hasta la generación de código. Esto es posible en parte porque han sido entrenados con conjuntos de datos enormes, una fracción significativa de todo el internet público, y porque continúan aprendiendo de las reacciones de los usuarios con el tiempo.
La inteligencia artificial generativa es inherentemente interactiva: los usuarios ingresan una instrucción, generalmente en forma de texto, y el modelo construye una respuesta en función de los miles de millones de parámetros que ha calculado utilizando su vasto corpus de entrenamiento. El uso efectivo implica una interacción continua, con el usuario corrigiendo la salida del algoritmo para mejorarla en la siguiente ronda.
Estos algoritmos pueden introducir riesgos de seguridad de la información de dos maneras novedosas: la fuga de información y la generación de vulnerabilidades. Además, cualquier uso de una nueva herramienta, API, servicio o proveedor de nube puede aumentar su superficie de ataque, pero dado que esto no es exclusivo de la IA generativa, este tema se aborda de manera limitada en el alcance de este artículo.
Fuga de información
La fuga de información es un riesgo de seguridad significativo al utilizar soluciones de IA generativa. Simplificaré el riesgo examinándolo en tres categorías: datos públicos, fugas en las instrucciones y exposición de datos personales. También resumiré brevemente el riesgo y discutiré estrategias para mitigarlo.
Datos públicos
Los LLM aprovechan conjuntos de datos grandes, en su mayoría extraídos de internet público. Esto incluye publicaciones de blogs, sitios web corporativos, manuales de entrenamiento, publicaciones en foros, artículos de noticias, boletos de soporte y más. Es probable que el sitio web de su empresa haya sido escaneado y utilizado para entrenar el modelo. Recientemente, el Washington Post ofreció un motor de búsqueda para el conjunto de datos C4 de Google, que le permite buscar por dominio y ver qué porcentaje de los tokens del conjunto de datos contribuye su sitio web.
Esto significa que es probable que la información que ha alojado en línea sea parte del modelo. Esto puede incluir material detallado que puede estar en las profundidades de los archivos de su sitio o incluso información que se ha eliminado desde entonces. Hay pocas esperanzas de deshacer esto; el escaneo de sitios web es un riesgo calculado que todas las empresas asumen. Sin embargo, los esfuerzos anteriores de escaneo nunca pudieron sintetizar resultados de una manera tan poderosa. El poder de los LLM cambia el cálculo de riesgos de hacer que la información sea libremente pública en internet.
Fuga en las instrucciones:
La segunda amenaza de seguridad de la información es más sutil y perjudicial. Dado que muchos productos LLM buscan mejorar según la entrada del usuario, es importante destacar que los modelos pueden entrenar en función de esa entrada. Esto significa que cualquier información propietaria utilizada en la fase de instrucciones del desarrollo del modelo puede terminar incrustada en el modelo y filtrarse a otros usuarios, incluidos posibles competidores. De hecho, se sospecha que esto ya ha ocurrido. Recientemente, Amazon emitió una advertencia interna a sus empleados sobre la herramienta, después de haber visto que el algoritmo generaba código sospechosamente similar al código fuente interno restringido.
Esta fuga se aplica tanto a los datos de texto como al código. Por ejemplo, si le pide a ChatGPT que sugiera eslóganes para su próxima campaña publicitaria, podría incrustar información sobre su producto en el modelo y poner esa información a disposición de otros de manera prematura. El código, los modelos de datos o los requisitos proporcionados al algoritmo pueden reflejar información interna propietaria que podría ser perjudicial en manos de un actor malicioso. Esto también puede revelar información sobre lanzamientos de productos futuros, detalles de infraestructura o estrategias comerciales.
Exposición de datos personales
Otro riesgo de fuga de información proviene de la exposición de datos personales. Aunque puede evitar el uso de datos personales directamente desde sus sistemas al usar IA generativa, la categoría de datos personales es amplia. Por ejemplo, ¿los representantes de servicio al cliente o ventas utilizan ChatGPT para escribir correos electrónicos a los clientes? Si es así, corre el riesgo de exponer datos personales, independientemente de lo insignificante que pueda parecer. Hubo una reciente brecha de datos en OpenAI donde los usuarios pudieron ver partes del historial de interacción de otros usuarios. Si estas instrucciones incluían datos personales protegidos, esto podría constituir un riesgo significativo de exposición de privacidad de datos para esas empresas.
"Cualquier información reservada utilizada en la fase inicial del desarrollo del modelo puede acabar integrada en el modelo y filtrarse a otros usuarios, incluidos competidores potenciales."
Introducción de vulnerabilidades
Otro riesgo surge cuando emergen vulnerabilidades, errores y exploits del código generado por la IA. Este problema surge de una combinación de factores. Primero, porque los LLM están entrenados en casi todo internet, esto significa que aprenden de cada patrón de codificación en el conjunto de entrenamiento, incluido el código que puede ser incorrecto, ineficiente, obsoleto o inseguro. Dado que los datos de entrenamiento son históricos, el modelo puede omitir los cambios más recientes en un lenguaje o herramienta que solucionan vulnerabilidades de seguridad.
En segundo lugar, el LLM no tiene la capacidad de razonar. No puede evaluar cualitativamente si un patrón es correcto; solo puede proporcionar salidas estadísticamente probables. No tiene la capacidad de juzgar si el código que emite sigue las mejores prácticas o incluso si introduce fallas de seguridad. La responsabilidad recae en el desarrollador para revisar el código que no creó, lo que puede representar un riesgo adicional debido a la falta de atención observada al usar herramientas automatizadas.
La investigación respalda esta evaluación de riesgos. Un estudio de Github Copilot mostró que el 40% de los 1,689 programas generados con la herramienta incluían posibles vulnerabilidades y exploits. Un estudio más reciente de Copilot, ChatGPT y Amazon Codewhisperer mostró que cada herramienta tenía altas tasas de código incorrecto. El cálculo costo-beneficio de usar LLM para generar código debe tener en cuenta el riesgo elevado que proviene de utilizar sus salidas.
Mitigaciones
La buena noticia es que una gobernanza cuidadosa y una implementación adecuada pueden mitigar muchos de estos riesgos de seguridad. Grupos como Github (Copilot) y OpenAI (ChatGPT) son conscientes de estos riesgos de seguridad de la información y son conscientes de que estos riesgos pueden obstaculizar el éxito de sus productos. La comunidad de desarrolladores también ha explorado mitigaciones, y aunque es poco probable que desarrollemos una panacea que elimine el riesgo, hay formas de evitarlo, mitigarlo y gestionarlo.
API cerradas
Una opción para prevenir la fuga de información es utilizar modelos de API "cerrados". Si bien muchas implementaciones de LLM pueden aprender dinámicamente a partir de la información que aporta, varias empresas están introduciendo modelos de suscripción que prometen que sus entradas, ya sean código, texto o imágenes, no se utilizan para mejorar aún más el modelo. Cada uno de los tres principales proveedores de servicios en la nube también está introduciendo ofertas de IA generativa, y muchos de ellos ofrecen garantías de procesamiento de datos de que sus datos de entrada no salen de la región, lo que ayuda al cumplimiento de los requisitos regulatorios.
Sin embargo, en la actualidad, es difícil validar externamente estas garantías; debe confiar en la palabra del proveedor, lo que puede no satisfacer a los reguladores o a su equipo legal, especialmente en lo que respecta a cualquier filtración de información de datos de clientes. Es difícil demostrar una negación, por lo que es un desafío desarrollar una estrategia de verificación que asegure que no se está produciendo una filtración de datos. Existe la esperanza de que en el futuro, los proveedores de herramientas de inteligencia artificial puedan ofrecer APIs validadas que garanticen la seguridad de los datos.
En términos de buenas prácticas, debe evitar enviar datos personales a estas APIs, a menos que haya obtenido el consentimiento explícito del usuario para hacerlo (y pueda demostrar que se otorgó el consentimiento). Los datos personales pueden estar en su almacén de datos, pero también pueden filtrarse a través de canales de servicio al cliente, envío y logística o ventas. Básicamente, cada vez que un empleado pueda estar utilizando un LLM para ayudar a redactar una respuesta a un cliente, debe ser consciente del riesgo de filtrar datos personales. Si aún no lo ha hecho, este es el mejor momento para implementar políticas corporativas que rijan el uso de LLM con datos personales.
Con estos riesgos en mente, y con el deseo de transparencia en cuanto a cómo se utilizan los LLM en la organización, un enfoque posible es restringir el acceso directo a las APIs, reemplazándolo por una fachada con un servicio alojado internamente. Este servicio puede ayudar a limpiar datos personales, señalar el uso indebido y el abuso, ofrecer auditabilidad interna y simplificar la gestión de costos. En lugar de llamar a la API externa del LLM, los usuarios llaman a una API interna que valida la solicitud y la pasa al LLM. La API de la fachada debe estar adecuadamente supervisada y los usuarios autenticados a través de la autenticación única en la nube.
Sin embargo, este enfoque tiene un inconveniente. Dado que los modelos no pueden aprender de sus entradas, no pueden adaptarse tan fácilmente a sus necesidades. Básicamente, está a merced del modelo, y a medida que aprende de otros usuarios, no hay garantía de que aprenda en una dirección beneficiosa para usted. A medida que el modelo cambia con el tiempo sin su influencia, su producción puede volverse menos relevante y la validez de las salidas para su caso de uso puede degradarse. Esto se puede mitigar desarrollando su propia solución.
Modelos alojados localmente
Si bien el uso de APIs cerradas y patrones de fachada puede ayudar a reducir el riesgo de fuga de información, no pueden abordar el riesgo de introducción de vulnerabilidades, y no ayudan a que los modelos se adapten a su base de conocimientos internos. Otra opción sería alojar su propio LLM o solución de inteligencia artificial generativa.
Los modelos masivos con varios cientos de miles de millones de parámetros son extremadamente costosos de entrenar y actualizar. Esto los convierte en algo inaccesible para la mayoría de las organizaciones para desarrollar. Sin embargo, las mejoras recientes en el aprendizaje por transferencia y las herramientas de desarrollo de IA han facilitado la posibilidad de alojar su propio LLM. Soluciones como LLaMa de Meta y el proyecto de nombre derivado de Stanford, Alpaca, son modelos mucho más pequeños que pueden entrenarse con costos de cómputo en la nube de tan solo $600. Algunas soluciones son lo suficientemente pequeñas como para entrenarse en una sola MacBook.
La desventaja de este enfoque es que los modelos resultantes son de calidad algo inferior, aunque los análisis cualitativos sugieren que su rendimiento sigue siendo suficiente para el propósito previsto.
Los modelos alojados localmente pueden adaptarse a su propia base de conocimientos; con el tiempo, pueden volverse aún mejores que los modelos públicos. El famoso memo filtrado de Google que decía "no tenemos un foso" sugiere lo mismo. Es completamente posible que el secreto ya se haya descubierto con respecto a la inteligencia artificial generativa y que en un futuro muy cercano veamos mejoras continuas en las herramientas y tecnologías que simplifican el desarrollo de modelos personalizados.
El uso de una solución alojada localmente reducirá significativamente el riesgo de fuga de información, incluida la fuga de datos personales, ya que ninguno de los datos sale de su entorno protegido. Sin embargo, no elimina completamente el riesgo. Por ejemplo, una práctica estándar en la modelización de datos es que los eventos de dominio no deben exponer el modelo de datos o la lógica de dominio interna. En parte, esto es para evitar el acoplamiento estrecho de sus sistemas y servicios que puede solidificar la arquitectura de su software, pero también es una mejor práctica para evitar la fuga de metadatos. Los metadatos internos y los modelos de datos pueden contener información confidencial que no desea exponer a toda la empresa. Las arquitecturas de Data Mesh abordan este problema explícitamente al garantizar que los datos y metadatos solo se puedan acceder a través de los puertos de salida de un producto de datos.
La introducción de LLM a nivel de toda la organización puede romper este aislamiento de la misma manera que los modelos de API abiertos. Si los equipos están proporcionando lógica o modelos de datos específicos del dominio a la IA, es posible que la IA pueda filtrar esta información fuera del dominio. Dado el costo y la complejidad cada vez menores de alojar su propia IA generativa, es posible que pronto sea una mejor práctica que cada dominio tenga su propio modelo personalizado. Aún no hemos llegado a ese punto. La capacitación y el alojamiento efectivos de modelos locales todavía son un desafío técnico, pero uno que se puede resolver. Hemos estado construyendo con éxito plataformas de aprendizaje automático que ejecutan modelos específicos del dominio durante algunos años, utilizando principios de Entrega Continua para el Aprendizaje Automático (CD4ML). De hecho, creemos que los principios de entrega continua son más importantes que nunca para garantizar el desarrollo de software seguro y de alta calidad.
"La mejor manera de evitar que se introduzcan vulnerabilidades es asegurarse de contar con un proceso de revisión sólido."
Prácticas de entrega continua
La mejor manera de prevenir la introducción de vulnerabilidades es asegurarse de tener un proceso de revisión sólido. En Thoughtworks, somos firmes defensores de la programación en pareja y creemos que tener a dos personas involucradas en todo el proceso de desarrollo de software es crucial para crear un código de alta calidad. La programación asistida por IA plantea algunas preguntas interesantes: ¿Es la IA un sustituto de un desarrollador en pareja? ¿Se convierte el programador en un revisor de código? Dado la calidad y los riesgos de seguridad demostrados en el código generado por IA, aún no estoy listo para asignarle personificación a la IA. Como se mencionó anteriormente, un LLM no puede ejercer juicio.
En su lugar, es fundamental centrarse en el desarrollo guiado por pruebas y la programación en pareja para asegurarse de que el código generado por la IA sea revisado adecuadamente. En mi experiencia con el código impulsado por IA, he encontrado que las herramientas son más efectivas cuando ya sé cómo debe ser un "buen" resultado. Puedo ajustar y modificar las salidas cuando sea necesario, y puedo diseñar instrucciones eficaces para obtener la salida correcta de manera rápida y eficiente.
Sin embargo, algunos de estos avances en productividad se compensan si tengo que pasar mucho tiempo probando el código en busca de casos límite y comportamientos inesperados. La mejor solución es automatizar tantas de estas comprobaciones como sea posible con una tubería de entrega continua (CI/CD) robusta. Las pruebas unitarias, las pruebas de integración, las comprobaciones de comportamiento, las pruebas de carga y rendimiento, las pruebas de humo, las comprobaciones de dependencia, los análisis de seguridad y más se pueden integrar en una buena tubería de CI/CD. Esto siempre ha sido cierto, pero la posibilidad de código impulsado por IA hace que estos sean cada vez más importantes. Lo último que desea hacer es enviar código defectuoso, no probado o insuficientemente probado que nadie en la organización entienda. De alguna manera, la mayor ganancia de productividad del código generado por IA podría resultar del hecho de que ahora debemos centrarnos más en la ingeniería de calidad.
Hay otro elemento en esto que se refiere a qué equipos estarán mejor posicionados para aprovechar el código impulsado por IA. Creo que los equipos de alto rendimiento y élite (según se define en Accelerate) se beneficiarán más de la tecnología. Esto se debe a que estos equipos ya tienen rutas sólidas hacia la producción, prácticas de reversión y avance bien probadas y una supervisión y observabilidad efectivas. Estos equipos son más propensos a saber qué es bueno y tienen experiencia en implementar código varias veces al día. Los equipos de bajo rendimiento pueden no beneficiarse de la IA en absoluto; en los peores casos, pueden causar más daño con la IA que sin ella. Por lo tanto, el moderno gerente de ingeniería debe considerar la tubería de CI/CD como una de las soluciones de mitigación de riesgos más potentes para el código impulsado por IA. Argumentaría que es la primera y más efectiva intervención posible en el desarrollo de software hoy en día y debería ser el primer lugar para comenzar su transformación hacia la IA.
Control de datos públicos
Durante años, muchas empresas han ofrecido servicios al cliente a través de foros públicos y otras formas de intercambio de información. Esto puede ayudar a reducir solicitudes duplicadas al poner la información a disposición de cualquier persona que la necesite, pero significa que parte de esta información ha sido escaneada y utilizada para entrenar LLM. El raspado de datos siempre ha sido un riesgo, pero las capacidades de síntesis a gran escala que poseen los LLM pueden hacer que este enfoque sea más riesgoso en el futuro. Las empresas deben reevaluar sus políticas con respecto a lo que publican en línea.
La pregunta sobre la divulgación de información ya no es "¿puede mi competidor ver esto y aprender de ello?", sino más bien "¿puede mi competidor usar esta información para entrenar una IA que lo ayude a obtener una ventaja competitiva?". La IA amplifica la velocidad a la que se difunde y aprende la información, por lo que es esencial reconsiderar cómo se utiliza la información pública. Si bien es imposible eliminar completamente la fuga de información, se pueden tomar medidas para mitigarla, como reducir la información detallada publicada en línea y revisar y ajustar las políticas de divulgación.
