En esta entrevista de Help Net Security, Naor Penso, CISO de Cerebras Systems , explica cómo modelar las amenazas de las pilas de IA modernas sin considerarlas un único riesgo. Analiza la importancia de segmentar los sistemas de IA por función e impacto, cómo enmarcar el modelado de amenazas para los líderes empresariales y qué supuestos se desmoronan a medida que la IA se convierte en infraestructura central.
¿Cuál es la forma correcta de dividir una pila de IA moderna para el modelado de amenazas para que los equipos eviten agrupar todo bajo la vaga etiqueta de «sistemas de IA»?
La forma correcta de dividir una pila de IA moderna para el modelado de amenazas no es tratar a los “sistemas de IA” como una categoría de riesgo monolítica; deberíamos volver a los fundamentos de seguridad y segmentar la pila según lo que hace el sistema, cómo se usa, la sensibilidad de los datos que toca y el impacto que podría tener su falla o violación.
Esto distingue las herramientas de productividad interna de bajo riesgo de los modelos integrados en flujos de trabajo de misión crítica o aquellos que representan propiedad intelectual central y garantiza que la IA se evalúe en contexto en lugar de por etiqueta.
¿Cómo transmitir a los líderes empresariales que el modelado de amenazas no es un bloqueador sino un facilitador del rendimiento y la confiabilidad?
El modelado de amenazas impulsa una mayor calidad que va más allá de la seguridad, y la mejor manera de transmitirlo a los líderes empresariales es mediante analogías arraigadas en su propio ámbito. Por ejemplo, en un concesionario de automóviles, nadie permitiría que un nuevo vendedor firmara un descuento del 80 %. El gerente general comprende al instante la razón de esa protección: protege los ingresos, la reputación y la estabilidad operativa.
Esta es una amenaza empresarial, e identificarla requiere la misma disciplina que el modelado de amenazas aplica a la tecnología. En este contexto, se demuestra que el modelado de amenazas no es un obstáculo, sino un facilitador del rendimiento, la fiabilidad y la toma de decisiones acertadas.
¿Qué heurísticas tradicionales de modelado de amenazas fallan primero cuando las cargas de trabajo de ML, los aceleradores y las canalizaciones de datos se convierten en el núcleo del entorno?
Para los LLM , más que para el aprendizaje automático tradicional, la primera heurística que se rompe es el supuesto de comportamiento determinista. En los sistemas clásicos, la misma entrada introducida en el mismo algoritmo produce siempre el mismo resultado.
Con los LLM, parámetros como la temperatura, top_p y las particularidades de la ejecución introducen un no determinismo inherente, por lo que no se puede esperar que un modelo responda de forma idéntica a la misma solicitud. Esta falta de determinismo crea una «incógnita desconocida» que dificulta la verificación del funcionamiento correcto y consistente del sistema, y difumina la frontera entre el comportamiento esperado y el comportamiento malicioso o anormal.
¿Cuál es el tipo de señal operativa de los canales de IA (por ejemplo, picos de tokens, desviaciones de incrustación extrañas, anomalías de programación de GPU) que cree que debería incorporarse al modelado de amenazas pero rara vez se hace?
Los patrones de llamada a herramientas son un aspecto clave que debe incorporarse al modelado de amenazas. La mayoría de las implementaciones modernas de LLM se basan en llamadas a herramientas externas, como búsquedas web o MCP internos (algunos del lado del servidor y otros del lado del cliente). A menos que estos estén estrictamente definidos y restringidos, pueden provocar que el modelo se comporte de forma inesperada o parcialmente maliciosa. Los cambios en la frecuencia, secuencia o parámetros de las llamadas a herramientas pueden indicar un uso indebido, confusión del modelo o un intento de escalamiento.
¿Qué nuevas categorías de impacto empresarial deben representarse en los modelos de amenazas cuando los propios modelos pueden convertirse en “infraestructura crítica”?
Los denominadores comunes siguen siendo los mismos: confidencialidad, integridad y disponibilidad. Pero cuando los modelos se convierten en infraestructura crítica, estos elementos primitivos se expanden a nuevas categorías de riesgo que antes no existían. La integridad ahora incluye la desviación de la integridad, el envenenamiento de modelos y el sesgo ilegal.
La disponibilidad ahora incluye la degradación del modelo, los fallos de dependencia y las ralentizaciones de la inferencia que pueden interrumpir las funciones empresariales principales. La confidencialidad se extiende al propio modelo como propiedad intelectual sensible, lo que incluye el riesgo de robo o replicación no autorizada.
Fuente y redacción: helpnetsecurity.com / Mirko Zorz
