Los riesgos de seguridad ocultos de los LLM

apresurarse a integrar modelos de idiomas grandes (LLM) en agentes de servicio al cliente, copilotos internos y ayudantes de generación de código, hay un punto ciego que surge: seguridad. Si bien nos centramos en los avances tecnológicos continuos y la exageración en torno a la IA, los riesgos y vulnerabilidades subyacentes a menudo no se abordan. Veo que muchas compañías manejan un doble estándar cuando se trata de seguridad. Las configuraciones de ONPREM están sujetas a un escrutinio intenso, pero el uso de servicios de IA en la nube como Azure OpenAI Studio o Google Gemini se adoptan rápidamente con el clic de un botón.

Sé lo fácil que es construir una solución de envoltura alrededor de las API de LLM alojadas, pero ¿es realmente la opción correcta para los casos de uso empresarial? Si su agente de IA está filtrando secretos de la compañía para OpenAi o siendo secuestrado a través de un mensaje ingenioso redactado, eso no es una innovación, sino una violación que espera que suceda. El hecho de que no nos enfrentemos directamente a las opciones de seguridad que se refieren a los modelos reales al aprovechar estas API externas, no deberían significar que podamos olvidar que las compañías detrás de esos modelos tomaron esas decisiones por nosotros.

En este artículo, quiero explorar los riesgos ocultos y defender un camino más consciente de la seguridad: LLMS autohospedados y estrategias apropiadas de mitigación de riesgos.

Los LLM no son seguros de forma predeterminada

El hecho de que un LLM suene muy inteligente con sus salidas no significa que sea inherentemente seguro para integrarse en sus sistemas. Un estudio reciente de Yoao et al. exploró el doble papel de LLM en seguridad [1]. Si bien los LLM abren muchas posibilidades y, a veces, incluso pueden ayudar con las prácticas de seguridad, también introducen nuevas vulnerabilidades y vías para el ataque. Las prácticas estándar aún deben evolucionar para poder mantenerse al día con las nuevas superficies de ataque creadas por soluciones alimentadas con AI.

Echemos un vistazo a un par de riesgos de seguridad importantes que deben tratarse cuando trabajen con LLM.

Fuga de datos

Fuga de datos Ocurre cuando la información confidencial (como los datos del cliente o la IP) se expone, accede o se usa mal durante la capacitación o inferencia del modelo. Con el costo promedio de una violación de datos que alcanza los $ 5 millones en 2025 [2]y el 33% de los empleados comparten regularmente datos confidenciales con herramientas de IA [3]La fuga de datos plantea un riesgo muy real que debe tomarse en serio.

Incluso si esas compañías de terceros LLM prometen no entrenar en sus datos, es difícil verificar lo que está registrado, almacenado en caché o almacenado aguas abajo. Esto deja a las empresas con poco control sobre el cumplimiento de GDPR y HIPAA.

Inyección rápida

Un atacante no necesita acceso a la raíz a sus sistemas de IA para hacer daño. Una simple interfaz de chat ya ofrece muchas oportunidades. Inyección rápida es un método en el que un hacker engaña a un LLM para que proporcione salidas involuntarias o incluso ejecute comandos no deseados. OWASP Notas Inyección indicada como el riesgo de seguridad número uno para LLMS [4].

Un escenario de ejemplo:

Un usuario emplea una LLM para resumir una página web que contiene instrucciones ocultas que hacen que la LLM filtrara la información de chat a un atacante.

Cuanta más agencia sea su LLM, mayor será la vulnerabilidad para ataques de inyección rápidos [5].

Cadenas de suministro opacas

Los LLM como GPT-4, Claude y Gemini son de código cerrado. Por lo tanto, no lo sabrás:

En que datos fueron entrenados
Cuando se actualizaron por última vez
Qué vulnerables son las exploits de día cero

Usarlos en producción introduce un punto ciego en su seguridad.

Slopsquatting

Con más LLMS utilizados como asistentes de codificación, ha surgido una nueva amenaza de seguridad: slopsquatting. Puede que estés familiarizado con el término Tipoquatting donde los piratas informáticos usan errores tipográficos comunes en código o URL para crear ataques. En Slopsquatting, los piratas informáticos no confían en errores tipográficos humanos, sino en alucinaciones de LLM.

Los LLM tienden a alucinar paquetes inexistentes al generar fragmentos de código, y si estos fragmentos se usan sin los controles adecuados, esto proporciona a los piratas informáticos una oportunidad perfecta para infectar sus sistemas con malware y los gustos. [6]. A menudo, estos paquetes alucinados sonarán muy familiares para los paquetes reales, lo que hace que sea más difícil para un humano captar el error.

Las estrategias de mitigación adecuadas ayudan

Sé que la mayoría de los LLM parecen muy inteligentes, pero no entienden la diferencia entre una interacción normal del usuario y un ataque inteligentemente disfrazado. Confiar en ellos a los ataques de autodetecto es como pedirle a Autocomplette que establezca las reglas de su firewall. Es por eso que es tan importante tener procesos y herramientas adecuados para mitigar los riesgos en torno a los sistemas basados en LLM.

Estrategias de mitigación para una primera línea de defensa

Hay formas de reducir el riesgo cuando se trabaja con LLM:

Desinfección de entrada/salida (como filtros regex). Al igual que demostró ser importante en el desarrollo frontal, no debe olvidarse en los sistemas de IA.
Información del sistema con límites estrictos. Si bien las indicaciones del sistema no son todos, pueden ayudar a establecer una buena base de límites
Uso de marcos de barandas de AI Para evitar el uso malicioso y hacer cumplir sus políticas de uso. Marcos como barandas ai hacen que sea sencillo configurar este tipo de protección [7].

Al final, estas estrategias de mitigación son solo un primer muro de defensa. Si está utilizando LLM alojados de terceros, todavía está enviando datos fuera de su entorno seguro, y aún depende de estas compañías de LLM para manejar adecuadamente las vulnerabilidades de seguridad.

Autohospedando tus LLM para más control

Hay muchas alternativas poderosas de código abierto que puede ejecutar localmente en sus propios entornos, en sus propios términos. Los avances recientes incluso han dado como resultado modelos de idiomas performantes que pueden ejecutarse con una infraestructura modesta [8]! Teniendo en cuenta los modelos de código abierto no se trata solo de costos o personalización (que posiblemente también sean bonusses). Se trata de control.

El autohospedaje te da:

Propiedad de datos completosnada deja tu entorno elegido!
Ajuste personalizado posibilidades con datos privados, lo que permite un mejor rendimiento para sus casos de uso.
Aislamiento de red estricto y sandboxing de tiempo de ejecución
Auditorabilidad. Sabes qué versión de modelo estás usando y cuándo se cambió.

Sí, requiere más esfuerzo: orquestación (por ejemplo, bentoml, servicio de rayos), monitoreo, escala. Tampoco estoy diciendo que el auto-anfitrión sea la respuesta para todo. Sin embargo, cuando hablamos de casos de uso que manejan datos confidenciales, la compensación vale la pena.

Trate los sistemas Genai como parte de su superficie de ataque

Si su chatbot puede tomar decisiones, acceder a documentos o llamar a las API, es efectivamente un consultor externo no vettido con el acceso a sus sistemas. Por lo tanto, trátelo de manera similar desde un punto de vista de seguridad: gobernar el acceso, monitorear cuidadosamente y no externalizarles el trabajo sensible. Mantenga los importantes sistemas de IA en casa, en su control.