La guía de seguridad de IA de Sandia pone en alerta a las startups de Tri-Valley
Sandia National Laboratories reunió a cuatro investigadores ante startups de Tri-Valley con una advertencia: la rápida adopción de la IA está creando riesgos que las revisiones de software convencionales pueden pasar por alto. El panel del 29 de julio llevó los métodos de seguridad de IA de Sandia al entorno empresarial, donde los equipos pequeños suelen implementar modelos antes de establecer programas formales de aseguramiento.
El evento no presentó un nuevo producto, estándar vinculante ni regulación. Su importancia residía en el modelo operativo que presentó Sandia. Las startups deberían examinar los datos, los modelos, las integraciones y las decisiones humanas como un sistema conectado, y después probar ese sistema frente a fallos y ataques realistas.
Esta postura genera un conflicto claro entre la velocidad de implementación y las pruebas de seguridad. Las startups compiten lanzando funciones pronto, aprendiendo de los usuarios y cambiando de rumbo con rapidez. Sandia aborda la IA desde entornos de altas consecuencias, donde un fallo sin explicación puede comprometer un sistema completo.
El panel también cuestionó una suposición habitual entre las startups. Utilizar un modelo a través de un proveedor reputado no transfiere todos los riesgos a ese proveedor. La empresa que desarrolla la aplicación final sigue controlando el acceso a sus datos, la capa de recuperación, las herramientas, los permisos, la experiencia de usuario y los procedimientos de respuesta.
Esto convierte el aseguramiento de la IA en una responsabilidad de producto, no en un ejercicio final de cumplimiento. La pregunta inmediata para los fundadores es si sus equipos pueden aportar pruebas sobre el comportamiento del sistema antes de que clientes, reguladores o atacantes las exijan.
La seguridad de IA de Sandia pasa del laboratorio a las operaciones de las startups
El evento tradujo las preocupaciones de seguridad nacional en cuestiones operativas que las empresas jóvenes ya afrontan.
Daybreak Labs organizó el Lunch and Learn gratuito en Livermore, California, de 11:30 a. m. a 1:30 p. m. La incubadora sin ánimo de lucro apoya a startups de ciencias de la vida y tecnología profunda en la región de Tri-Valley.
El panel contó con Amanda Dodd, Gayle Thayer, Philip Kegelmeyer y Jonathan Crussell, de Sandia. Sus trayectorias abarcaron análisis de seguridad nacional, algoritmos seguros, analítica de datos adversariales, seguridad de software y flujos de trabajo de IA agéntica.
Dodd, directora de Computation and Analysis for National Security de Sandia, centró la conversación en las vulnerabilidades creadas por una adopción acelerada. Comparó la expansión actual de la IA con la adopción generalizada de internet durante los años noventa.
Su comparación se centró en la incertidumbre, no en la nostalgia. La conectividad a internet creó servicios valiosos al tiempo que expuso los sistemas a ataques y modos de fallo que muchas organizaciones no habían previsto. Ahora la IA añade una incertidumbre similar dentro de sistemas que generan contenido, recomiendan decisiones y, en ocasiones, toman medidas.
Según el programa del evento, el debate abordó velocidad frente a seguridad, innovación frente a regulación y riesgos relacionados con equipos humanos y de IA. También examinó cómo se solapan las prioridades del gobierno y del sector privado.
El posterior informe del panel de Sandia describió tres consecuencias empresariales de las amenazas de IA: pérdida de propiedad intelectual, interrupción operativa y exposición regulatoria. Estos resultados dan a las debilidades técnicas un significado financiero y estratégico directo.
Thayer, responsable del departamento de Secure Algorithms de Sandia, explicó que la atención de seguridad está desplazándose más allá del hardware y el software convencional. Los investigadores examinan cada vez más los propios algoritmos y el comportamiento que surge de su uso.
Este cambio importa porque una aplicación de IA puede funcionar según lo previsto y aun así producir resultados inseguros. Un modelo podría revelar contexto sensible, aceptar una instrucción maliciosa o comportarse de forma impredecible fuera de sus condiciones originales de prueba.
La aplicación también puede fallar sin que nadie la ataque. Instrucciones ambiguas, datos desconocidos, criterios de evaluación débiles o un nivel de autonomía inadecuado pueden causar errores graves. El análisis convencional de vulnerabilidades no identificará todos esos problemas.
El enfoque de Sandia incluye red teaming, es decir, sondear activamente un sistema en busca de debilidades antes de que las encuentre un adversario. Los investigadores también comparan la fiabilidad, la seguridad y los límites de rendimiento bajo condiciones definidas.
Probar los límites es diferente de informar una única puntuación de precisión favorable. Una evaluación útil pregunta dónde deja el sistema de comportarse de forma aceptable, qué entradas desencadenan ese cambio y si la supervisión puede detectarlo.
Por tanto, el panel hizo más que enumerar riesgos de IA. Conectó la identificación de riesgos con pruebas repetibles, mitigación y diseño seguro. Esa secuencia convierte una advertencia abstracta en una disciplina de ingeniería.
Nada en el informe público indica que Sandia certificara a las startups participantes o evaluara sus productos. La sesión fue un intercambio de enfoques y preocupaciones, no una auditoría.
Esta distinción es importante. Un panel de dos horas no puede establecer si un sistema de IA concreto es seguro. Sin embargo, puede cambiar las preguntas que los fundadores se hacen antes de lanzar uno.
La rápida adopción de IA deja a las startups con una brecha de aseguramiento
Las startups afrontan presión porque sus ciclos de lanzamiento son más cortos que el tiempo necesario para comprender cada comportamiento del modelo.
Una empresa joven puede añadir un modelo alojado a un producto sin entrenar ese modelo. Puede conectar documentos de clientes, registros internos o herramientas externas mediante interfaces de programación de aplicaciones dentro de un ciclo de desarrollo corto.
La aplicación resultante hereda varias capas de incertidumbre. Su comportamiento depende del modelo fundacional, las instrucciones del sistema, los datos recuperados, las integraciones de software, los permisos y la entrada del usuario.
Un cambio en cualquiera de esas capas puede alterar el sistema. Un proveedor de modelos puede actualizar el comportamiento, un índice de recuperación puede admitir documentos nuevos o un cliente puede habilitar una nueva integración.
Estos cambios crean lo que los equipos suelen llamar una brecha de aseguramiento. El producto se desarrolla más rápido que las pruebas de la empresa sobre seguridad, fiabilidad y comportamiento aceptable.
La brecha se vuelve más grave cuando un sistema de IA puede actuar. Los flujos de trabajo agénticos son aplicaciones que permiten a un modelo planificar pasos y llamar a herramientas con una intervención humana limitada. Pueden enviar mensajes, editar registros, ejecutar código o activar procesos empresariales.
Cada permiso adicional aumenta el impacto de una respuesta equivocada o manipulada. Una respuesta deficiente dentro de una ventana de chat resulta inconveniente. La misma respuesta enviada a una herramienta de ejecución puede modificar datos o exponer información.
La inyección de prompts ilustra la diferencia. Un atacante introduce instrucciones en la entrada del usuario o en contenido externo, con la esperanza de que el modelo las siga en lugar de las reglas previstas por el desarrollador.
La actual lista de riesgos de LLM mantenida por OWASP identifica la inyección de prompts como una vulnerabilidad importante de las aplicaciones. También aborda la divulgación de información sensible, las debilidades de la cadena de suministro, el manejo inadecuado de salidas y la agencia excesiva.
Estos riesgos atraviesan las fronteras organizativas. Un proveedor de modelos protege su plataforma, mientras que el desarrollador de una aplicación controla los prompts, la recuperación, las herramientas y las reglas de acceso. Después, el cliente controla el comportamiento de los usuarios, los datos conectados y la configuración local.
Ningún participante ve el sistema completo. Eso facilita diluir la responsabilidad hasta que ocurre un incidente.
El panel de Sandia devolvió la responsabilidad a la organización que implementa el sistema. El gobierno puede aportar investigación, marcos de trabajo y evaluación independiente. Sin embargo, las empresas siguen siendo responsables de los riesgos creados por sus productos y decisiones operativas.
Esta responsabilidad no exige que una startup replique un laboratorio nacional. Exige que la empresa defina qué significa un comportamiento seguro para su propio caso de uso.
Un asistente de investigación clínica y un generador de textos de marketing no deberían compartir criterios de aceptación idénticos. El primero maneja información con mayores consecuencias y exige pruebas, controles de acceso y revisión más estrictos.
Las startups también deben separar la calidad del modelo de la seguridad del sistema. Un modelo puede rendir bien en tareas rutinarias y fallar ante entradas adversariales. Puede responder con precisión y, al mismo tiempo, revelar información que un usuario no debería recibir.
También es posible lo contrario. Una aplicación puede prevenir ataques comunes y aun así generar recomendaciones poco fiables. La seguridad y la utilidad se solapan, pero una no garantiza la otra.
Por eso, una única puntuación de referencia ofrece un aseguramiento débil. Los equipos necesitan pruebas vinculadas a las tareas previstas, al uso indebido previsible, a los límites de acceso y a las condiciones reales de implementación.
También necesitan registros. Una base de conocimientos con capacidad de búsqueda puede conservar versiones de modelos, resultados de evaluaciones, incidentes y riesgos aceptados entre los equipos de ingeniería y producto.
La documentación no es burocracia añadida después del desarrollo. Permite a un equipo identificar cuándo cambió el comportamiento y si una mitigación anterior sigue funcionando.
La presión es inmediata y de largo plazo. Los compradores empresariales ya preguntan a los proveedores sobre el manejo de datos, los proveedores de modelos, los controles de acceso y la respuesta a incidentes. Las futuras normas pueden formalizar más esas pruebas.
Una startup que no pueda responder a estas preguntas puede perder acuerdos antes de sufrir una brecha técnica. En ese sentido, una IA confiable se convierte en parte de la credibilidad del producto.
La disyuntiva central es velocidad frente a pruebas
El mensaje de Sandia no exige una innovación más lenta, pero sí pruebas más sólidas antes de otorgar mayor autoridad a la IA.
Los fundadores suelen considerar la velocidad como un requisito de supervivencia. Lanzar rápido genera comentarios de los usuarios, demuestra la demanda y ayuda a una empresa pequeña a competir con organizaciones de presupuestos mayores.
Los equipos de seguridad abordan el mismo lanzamiento desde otra dirección. Quieren modelos de amenazas, pruebas, registros, límites de acceso y un plan de respuesta antes de que un sistema llegue a datos sensibles.
Ambas posturas contienen preocupaciones válidas. Retrasar cada función experimental hasta que cumpla estándares de altas consecuencias supondría una carga para muchas startups. Implementar un sistema autónomo sin pruebas significativas expondría a los clientes a riesgos que no pueden ver.
La respuesta práctica es un aseguramiento proporcional. Un asistente de redacción de bajo impacto necesita controles distintos de los de un agente que puede modificar registros financieros, de laboratorio o de producción.
El aseguramiento proporcional empieza con un contexto definido. El equipo documenta quién utilizará el sistema, a qué datos puede acceder, qué acciones puede realizar y qué fallos son inaceptables.
Después, la empresa identifica amenazas creíbles y modos de fallo habituales. Las amenazas incluyen prompts maliciosos, datos envenenados, credenciales robadas, dependencias comprometidas e intentos de extraer contexto privado.
Los fallos habituales merecen la misma atención. Un modelo puede malinterpretar una solicitud, inventar una fuente, seleccionar la herramienta equivocada o seguir funcionando después de que sus supuestos dejen de ser válidos.
A continuación llega la medición. Los equipos crean conjuntos de evaluación a partir de tareas realistas, casos límite conocidos y ejemplos adversariales. Registran los resultados esperados antes de ejecutar las pruebas.
Una prueba útil tiene una condición de aprobación observable. “El modelo debe ser seguro” no es medible. “El asistente no debe devolver registros fuera del espacio de trabajo del usuario autenticado” es lo bastante específico como para probarlo.
El enfoque de red team de Sandia añade la perspectiva de un atacante. Los evaluadores buscan rutas inesperadas a través de la aplicación completa, incluidas sus instrucciones, datos conectados, interfaces y herramientas.
La comunidad más amplia de laboratorios del Departamento de Energía ha descrito trabajos similares. Un informe sobre seguridad de la IA de varios laboratorios afirma que los benchmarks estáticos son insuficientes para predecir el comportamiento fuera de condiciones conocidas.
El informe también identifica límites de recursos. Las evaluaciones exhaustivas consumen capacidad de cómputo, trabajo especializado y tiempo. Los nuevos modelos llegan más rápido de lo que los evaluadores pueden analizar cada uno a fondo.
Esta limitación es especialmente relevante para las startups. Las pequeñas empresas no pueden probar todas las entradas posibles ni reproducir las evaluaciones internas del proveedor.
Aun así, pueden evaluar la aplicación que controlan. Una evaluación focalizada debe abarcar los datos, las herramientas, los roles de usuario y los flujos de trabajo de mayor impacto de la empresa.
La mitigación sigue a las pruebas. Un equipo puede restringir permisos, aislar contenido no confiable, validar resultados, exigir aprobación humana o limitar las herramientas a las que el modelo puede recurrir.
El control más sólido suele reducir las consecuencias de un fallo. Si un asistente solo redacta una acción, una persona puede revisarla. Si el asistente ejecuta esa acción directamente, la empresa necesita una autorización y una supervisión más estrictas.
La revisión humana no es automáticamente eficaz. Los revisores pueden caer en la complacencia cuando la mayoría de los resultados parecen correctos, especialmente bajo presión de tiempo.
Por ello, los equipos deben identificar las decisiones en las que la revisión es más importante. También deben presentar suficiente contexto para que una persona reconozca un resultado cuestionable.
La supervisión cierra el ciclo. Los registros deben mostrar qué modelo, instrucciones, fuentes de datos y herramientas contribuyeron a un resultado importante. Sin ese contexto, investigar un incidente se convierte en conjeturas.
Ninguno de estos pasos crea una garantía permanente. El comportamiento del modelo, el código de la aplicación, los datos y los atacantes cambian. Las pruebas deben continuar durante toda la vida del sistema.
Aquí es donde el conflicto entre velocidad y evidencia se vuelve manejable. Una startup puede avanzar rápidamente en un entorno restringido y ampliar la autoridad a medida que mejora la evidencia.
Puede empezar con usuarios internos, datos sintéticos y herramientas de solo lectura. Las etapas posteriores pueden incorporar datos de clientes o acciones limitadas después de que el sistema cumpla umbrales explícitos.
Este camino considera la seguridad como parte del desarrollo de producto. Evita la falsa disyuntiva entre bloquear cada experimento y lanzar cada capacidad sin límites.
Los marcos ayudan, pero no certifican un producto
Los marcos existentes organizan el trabajo sobre riesgos de IA, pero no pueden determinar si la aplicación de una startup es lo suficientemente segura.
El Marco de Gestión de Riesgos de IA de NIST ofrece a las organizaciones cuatro funciones conectadas: gobernar, mapear, medir y gestionar. La gobernanza se aplica a las demás funciones, en lugar de aparecer solo al final.
El marco es voluntario y está diseñado para un uso amplio. Su marco de riesgos de IA ayuda a las organizaciones a incorporar la confiabilidad en el diseño, desarrollo, despliegue, uso y evaluación de la IA.
Para una startup, “gobernar” significa asignar autoridad para tomar decisiones y documentar la tolerancia al riesgo. Alguien debe decidir qué casos de uso están permitidos y qué evidencia respalda el lanzamiento.
“Mapear” significa comprender el contexto. Los equipos identifican usuarios, partes afectadas, datos, dependencias, beneficios esperados y posibles daños.
“Medir” abarca las pruebas y el análisis. Incluye evaluación del rendimiento, pruebas de seguridad, evaluación de incertidumbre y supervisión frente a criterios definidos.
“Gestionar” convierte los hallazgos en prioridades y acciones. Una empresa acepta, reduce, transfiere o evita riesgos según su gravedad y los controles disponibles.
NIST también publicó un perfil de IA generativa en julio de 2024. El perfil adapta el marco más amplio a los riesgos que los sistemas generativos introducen o intensifican.
Estos recursos aportan vocabulario y estructura. No inspeccionan un producto, garantizan el cumplimiento ni certifican el comportamiento de un modelo.
La postura de Sandia parece técnicamente más exigente que simplemente adoptar el lenguaje de un marco. Sus investigadores destacaron el red teaming, los benchmarks, el diseño seguro y la comprensión de los límites de rendimiento.
Este énfasis importa porque los documentos de gobernanza pueden desconectarse del software. Un registro de riesgos puede afirmar que la inyección de prompts está resuelta mientras el sistema de recuperación desplegado aún transmite instrucciones no confiables a un modelo.
La evidencia debe conectar cada riesgo identificado con un control y una prueba. La empresa también debe saber qué riesgos permanecen después de la mitigación.
La evaluación independiente puede reforzar ese proceso. Sandia describió a los centros de investigación y desarrollo financiados por el Gobierno federal como fuentes de análisis técnico imparcial.
Sin embargo, el informe público del panel no anunció un servicio general de certificación de Sandia para startups. Expresó interés en identificar dónde la industria puede satisfacer necesidades de garantía y dónde los laboratorios nacionales pueden abordar brechas.
Es una invitación a colaborar, no una prueba de una vía ya terminada. El acceso, el alcance, la gestión de la propiedad intelectual y los acuerdos de contratación determinarán si las startups individuales pueden participar.
Sandia ya opera programas que conectan laboratorios, universidades y empresas más pequeñas. Su programa RAIICE busca proporcionar conjuntos de datos abiertos y planificación técnica para trabajos de IA y aprendizaje automático relacionados con energía resiliente.
RAIICE demuestra un modelo de colaboración, pero no debe confundirse con el panel de seguridad de julio. El panel no anunció que sus asistentes hubieran ingresado a ese programa.
Esta distinción expone el ángulo escéptico del mensaje de Sandia. La experiencia técnica existe y los fundadores claramente la necesitan. Lo que sigue siendo incierto es hasta qué punto esa experiencia puede llegar a los equipos comerciales.
Los laboratorios nacionales trabajan con misiones específicas, normas de contratación y limitaciones de recursos. Las startups operan con calendarios comprimidos y pueden necesitar respuestas en cuestión de días.
Un modelo de colaboración debe salvar esa diferencia de ritmos. Debe convertir métodos de investigación en pruebas que los equipos pequeños puedan ejecutar, repetir y explicar a sus clientes.
La regulación crea otra incertidumbre. Según los informes, los panelistas favorecieron reglas claras que permitan a la industria asumir responsablemente los riesgos de IA, pero el evento no produjo ninguna norma legal propuesta.
Las reglas pueden aclarar expectativas, pero también pueden quedar obsoletas a medida que cambian los modelos y las aplicaciones. Los requisitos prescriptivos pueden premiar el cumplimiento de listas de verificación sin mejorar el comportamiento real.
Las reglas centradas en resultados crean un problema distinto. Pueden indicar a las empresas qué resultado lograr sin ofrecer formas asequibles de demostrarlo.
La mejor señal a corto plazo será la evidencia práctica. Métodos de prueba públicos, herramientas de evaluación reutilizables, conjuntos de datos accesibles y colaboraciones documentadas con startups demostrarían que la visión de asociación se está volviendo operativa.
Hasta entonces, las empresas no deben afirmar que adoptar un marco demuestra seguridad. Deben describir los controles que utilizan, las pruebas que realizaron y las limitaciones que aún observan.
Lo que fundadores y compradores deberían vigilar a continuación
La próxima prueba será determinar si el lenguaje de riesgos de Sandia produce prácticas repetibles, alianzas creíbles y expectativas de mercado más claras.
La primera señal es una vía concreta de colaboración para pequeñas empresas. Sandia afirmó que quiere identificar dónde la industria puede satisfacer necesidades de garantía y dónde los laboratorios nacionales pueden cubrir brechas.
Una vía útil definiría los proyectos elegibles, la experiencia disponible, los requisitos de gestión de datos, los entregables esperados y los plazos de participación. Los casos de estudio públicos facilitarían la evaluación del modelo.
Si surgen esos detalles, reforzarán la afirmación central del panel. Mostrarían que los métodos de los laboratorios nacionales pueden ir más allá de la discusión y respaldar el desarrollo comercial.
Si no aparece ninguna vía, el evento seguirá siendo una iniciativa de divulgación valiosa, pero ofrecerá una ayuda operativa limitada. Las startups aún tendrían que crear sus propios programas de pruebas o contratar especialistas externos.
La segunda señal es la validación técnica vinculada a aplicaciones reales. Los fundadores deberían estar atentos a evaluaciones publicadas que cubran inyección de prompts, filtración de datos, manipulación de modelos, uso inseguro de herramientas y comportamiento fuera de las condiciones normales de prueba.
El trabajo más útil informará sobre condiciones de fallo y riesgos residuales, no solo sobre puntuaciones favorables. Debe explicar qué cambió después de las pruebas y si la mitigación resistió otro ciclo de ataque.
Esa evidencia reforzaría el argumento de que una IA confiable crea una ventaja competitiva. Los compradores pueden comparar proveedores con mayor confianza cuando las empresas presentan resultados repetibles.
La falta de evidencia debilitaría ese argumento. El lenguaje de seguridad por sí solo no distingue un producto de otro, especialmente cuando todos los proveedores hacen promesas similares.
La tercera señal es el paso de marcos amplios hacia expectativas más claras de clientes y reguladores. NIST está revisando AI RMF 1.0 y desarrollando perfiles adicionales para ciberseguridad e infraestructura crítica.
Los fundadores deberían seguir si los cuestionarios empresariales, requisitos de contratación, revisiones de seguros y normas sectoriales empiezan a solicitar evidencia similar. La convergencia reduciría la incertidumbre sobre qué controles merecen una inversión temprana.
La fragmentación crearía una carga mayor. Una startup podría enfrentarse a formatos de evaluación distintos por parte de cada cliente, regulador y socio.
Los compradores desempeñan un papel en la configuración de ese resultado. Deben preguntar a los proveedores qué modelos y fuentes de datos respaldan un flujo de trabajo, qué acciones puede realizar el sistema y cómo el proveedor prueba los límites de acceso.
También deben preguntar qué sucede después de una actualización del modelo. Una evaluación previa ofrece protección limitada si un proveedor cambia el comportamiento o la aplicación obtiene nuevas herramientas.
Los desarrolladores deben tratar cada permiso añadido como una nueva decisión de seguridad. Conectar un asistente al correo electrónico, código fuente, registros de clientes o datos de laboratorio cambia las consecuencias de un fallo.
Los trabajadores del conocimiento también deben comprender esos límites. Necesitan señales claras sobre qué información puede ingresar a un sistema de IA y qué resultados requieren una revisión independiente.
El panel de Sandia no resolvió estas cuestiones. Hizo más difícil que las startups las sigan posponiendo.
La lección más duradera es que la seguridad de la IA abarca todo el sistema operativo que rodea a un modelo. Los datos, las instrucciones, el software, los permisos, los usuarios y la supervisión influyen en el resultado.
Esa lección también aclara qué deben hacer ahora los fundadores. Definir el sistema, clasificar sus fallos de mayor impacto, probarlos, reducir permisos y conservar evidencia.
Después, deben preguntarse si cada nueva capacidad merece la autoridad que recibe. Una demo convincente no es un caso de garantía, y la reputación de un proveedor no sustituye las pruebas de la aplicación.
La orientación de Sandia sobre seguridad de IA importará más si las empresas convierten esa disciplina en trabajo rutinario de producto. Los fundadores deberían empezar por seleccionar un flujo de trabajo con consecuencias significativas y documentar sus riesgos, controles, pruebas y límites no resueltos.
