Gobernanza práctica de GenAI: Cómo reducir el riesgo de seguridad de la información

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.

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.