Donde dejan de aplicar los estándares de seguridad de la IA — y donde debe comenzar la protección en tiempo de ejecución

Con todo el debate sobre los riesgos de seguridad de la IA, un tema que parece pasar desapercibido es este: el hecho de que los sistemas de IA solo funcionan al exponer sus activos más valiosos — modelos y datos.

A diferencia del software tradicional, la IA no simplemente ejecuta una lógica predefinida. Combina constantemente modelos propietarios con entradas sensibles para generar salidas, a menudo en infraestructuras que no fueron diseñadas para proteger la computación.

De esta manera, la seguridad tradicional es insuficiente. El cifrado es efectivo cuando los datos se almacenan o se transmiten a través de una red, pero no cuando los datos se procesan o se operan. Para la IA en particular, el peligro surge cuando se despliega un modelo. Sus parámetros se cargan en la memoria, se inicializan y se ejercitan a gran escala – el punto en el que el cifrado deja de ser efectivo – exponiéndolo a un posible acceso no autorizado. Durante la inferencia, los datos sensibles fluyen a través de ese mismo espacio expuesto. El resultado es una superficie de riesgo muy vulnerable: los sistemas de IA que pueden parecer seguros – pero en realidad no están protegidos en los momentos más críticos.

Organismos de normalización como el Instituto Nacional de Estándares y Tecnología (NIST), la Agencia de Ciberseguridad de la Unión Europea (anteriormente conocida como la Agencia de Seguridad de las Redes y la Información de la Unión Europea, o ENISA), y el Proyecto de Seguridad de Aplicaciones Web Abiertas (OWASP) han comenzado a cartografiar este territorio. Describen los riesgos, nombran las vulnerabilidades y esbozan principios de gobernanza. Pero se detienen antes de prescribir cómo proteger los modelos como propiedad intelectual y los datos como activos confidenciales una vez que comienza la ejecución. Cerrar esta brecha requiere repensar la seguridad de la IA – no como un ejercicio de cumplimiento, sino como un problema de la computación en sí. Aquí es donde el cifrado en uso, o el cifrado de extremo a extremo, juega un papel.

El Punto Ciego en la Seguridad de la IA Moderna

La mayoría de las conversaciones sobre la seguridad de la IA aún giran en torno a terreno familiar: gobernanza de datos de entrenamiento, controles de acceso, monitoreo de API, y políticas de usuario responsables. Estos son necesarios. Sin embargo, ninguno de ellos aborda lo que sucede después del despliegue, cuando un modelo sale del repositorio y se convierte en un sistema vivo.

Una vez desplegado, los parámetros de un modelo ya no son artefactos abstractos. Son activos vivos, residentes en la memoria, accesados continuamente durante la inferencia y a menudo utilizados por múltiples inquilinos o clientes a través de servicios de IA compartidos. Esta exposición ocurre antes de que se realice cualquier solicitud de inferencia, lo que complica el riesgo al introducir entradas sensibles y comportamiento observable externamente.

Tratar la protección del modelo como una preocupación pre-despliegue y la seguridad de la inferencia como una preocupación en tiempo de ejecución pierde el punto. En sistemas reales, estos riesgos se superponen. Los modelos y los datos se exponen a lo largo de la inicialización, la ejecución y la salida. La seguridad que comienza y termina con controles de almacenamiento no aborda estas exposiciones.

Qué Hace Bien NIST — y Dónde Se Detiene

El Marco de Gestión de Riesgos de la IA de NIST se ha convertido en una piedra angular para las organizaciones que intentan gestionar el riesgo de la IA. Su estructura — gobernar, mapear, medir, gestionar — ofrece una forma disciplinada de pensar en la rendición de cuentas, el contexto, el impacto y la mitigación en todo el ciclo de vida de la IA.

Lo que NIST hace particularmente bien es enmarcar el riesgo de la IA como sistémico en lugar de accidental. Los fallos de la IA rara vez son eventos de un solo punto; surgen de las interacciones entre modelos, datos, personas y infraestructura. Ese enmarque es esencial.

Donde el marco se queda corto es al no dictar cómo se protegen los activos de la IA de alto valor una vez que los sistemas están en vivo. Los parámetros del modelo se tratan implícitamente como artefactos de tiempo de diseño en lugar de activos en tiempo de ejecución. Se asume que los entornos de ejecución son lo suficientemente confiables.

En la práctica, los parámetros del modelo a menudo son la propiedad intelectual más valiosa que posee una organización. Se cargan en la memoria, se copian en nodos, se almacenan en caché y se reutilizan. Si la gestión de riesgos de la IA no tiene en cuenta la confidencialidad de los modelos durante el despliegue y la ejecución, un activo crítico queda fuera del límite de riesgo, como un pato sentado.

ENISA y la Realidad de las Amenazas Específicas de la IA

El trabajo de ENISA sobre la ciberseguridad de la IA impulsa la conversación más lejos. Su marco multilayer distingue entre la seguridad de la infraestructura tradicional y los riesgos específicos de la IA, reconociendo que los sistemas de IA se comportan de manera diferente — y fallan de manera diferente — que el software convencional.

¿Por qué es importante? La IA introduce amenazas que no encajan perfectamente en los controles existentes: extracción de modelos, fuga de parámetros, exposición de co-tenencia y manipulación durante la ejecución. Estos riesgos no requieren atacantes exóticos. Surgen naturalmente cuando los modelos de alto valor se ejecutan en entornos compartidos o externamente administrados.

El marco de ENISA reconoce implícitamente que garantizar la seguridad de la IA significa garantizar el comportamiento, no solo el código. Pero al igual que la mayoría de las normas, se centra en lo que debe considerarse, no en cómo se aplican técnicamente las protecciones una vez que los modelos están en ejecución.

OWASP y el Costo de la Inteligencia Observable

La lista de los 10 principales de OWASP para aplicaciones de modelos de lenguaje grande ofrece una visión más concreta de cómo los sistemas de IA se rompen en el mundo real. Inyección de prompts, divulgación de información sensible, fuga de incrustaciones, transparencia excesiva de salida — estos no son problemas teóricos. Son subproductos de desplegar modelos poderosos sin limitar lo que revelan.

Aunque estos problemas a menudo se enmarcan como problemas de la capa de aplicación, sus consecuencias son más profundas. La exposición repetida del comportamiento del modelo puede llevar a un clonado efectivo; las incrustaciones mal aisladas pueden revelar estructura; y el abuso de inferencia se convierte en una vía para la replicación del modelo.

La taxonomía de OWASP deja claro que proteger la IA no es solo detener las entradas malas. Se trata de limitar lo que los modelos exponen — interna y externamente — una vez que están operativos.

Una Conclusión Compartida, un Trabajo Inacabado

A lo largo de NIST, ENISA y OWASP, hay un acuerdo general sobre los fundamentos:

• El riesgo de la IA abarca el ciclo de vida
• Los sistemas de IA introducen nuevas categorías de amenazas
• Los modelos y los datos son activos de alto valor
• La exposición en tiempo de ejecución es inevitable

Lo que estos marcos carecen es de un mecanismo para hacer cumplir la confidencialidad una vez que los modelos están desplegados y comienza la computación. Esa omisión no es un error, ya que las normas definen la intención y el alcance. La implementación generalmente se deja al diseñador del sistema.

Pero dejan una brecha crítica — una que crece más ancha a medida que los sistemas de IA se escalan.

El Cifrado en Uso Cambia la Ecualización

El cifrado en uso cambia el modelo de seguridad. En lugar de asumir que los datos y los modelos deben estar expuestos para ser útiles, trata la computación como algo que se puede proteger.

En términos prácticos, esto significa:

• Los modelos permanecen cifrados durante el despliegue, la inicialización y la ejecución
• Las entradas nunca son visibles en texto plano para el entorno de ejecución
• Los estados intermedios no pueden ser inspeccionados ni modificados
• La infraestructura ya no necesita ser confiable implícitamente

Esto no reemplaza los marcos de gobernanza o los controles de la capa de aplicación – los opera. Convierte los principios de riesgo en garantías aplicables justo cuando los sistemas de IA son más vulnerables.

En otras palabras, el cifrado en uso es la capa que falta entre la política de la IA y la realidad de la IA.

Cuando la Gobernanza Termina y Comienza la Ejecución: Seguridad de la Computación de la IA

La seguridad de la IA se rompe en tiempo de ejecución. Una vez desplegados, los modelos de la IA y los datos sensibles deben estar expuestos en la memoria para funcionar, creando una superficie de riesgo que los controles tradicionales — cifrado en reposo, cifrado en tránsito y marcos de gobernanza — nunca estuvieron diseñados para proteger.

Organismos de normalización como NIST, ENISA y OWASP han hecho progresos críticos en la definición del riesgo de la IA, la rendición de cuentas y el mal uso. Pero su orientación trata en gran medida a los modelos como artefactos de diseño y asume que los entornos de ejecución pueden ser confiables. En la práctica, los parámetros del modelo y las entradas sensibles se acceden, se reutilizan y a menudo se procesan en entornos compartidos o externamente administrados.

Cerrar esta brecha requiere repensar la seguridad de la IA no como un ejercicio de cumplimiento, sino como un problema de proteger la computación en sí — cuando los modelos están vivos, los datos están en uso y la exposición es inevitable. El cifrado en uso ofrece una forma viable de mantener los modelos de la IA y las entradas sensibles seguras en todas las etapas del ciclo de vida de la IA.