Los modelos de IA necesitan una máquina virtual

 (blog.sigplan.org)
3 puntos por GN⁺ 2025-09-01 | 1 comentarios | Compartir por WhatsApp
  • El software de IA requiere características propias de un sistema operativo que van más allá de simplemente invocar un modelo, como seguridad, aislamiento, escalabilidad y portabilidad; para ello se propone el concepto de una máquina virtual para modelos de IA (MVM)
  • Así como la Java Virtual Machine (JVM) hizo posible la seguridad de memoria y el principio de “escribir una vez, ejecutar en cualquier lugar”, una VM para IA también separa el modelo de la lógica de integración para garantizar intercambiabilidad e interoperabilidad
  • La VM define un conjunto estándar de instrucciones para llamadas al modelo, llamadas a herramientas, almacenamiento de resultados, entrada del usuario y bifurcaciones condicionales, de modo que el comportamiento del modelo pueda restringirse y rastrearse de forma segura
  • Investigaciones existentes como las llamadas estructuradas a herramientas de OpenAI, MCP de Anthropic, FIDES/AC4A de Microsoft y runtimes de código abierto ya muestran una dirección hacia la estandarización
  • Una VM para IA bien definida puede hacer posible mayor seguridad y privacidad, monitoreo de rendimiento, validación de salidas y la construcción de un ecosistema multiplataforma, posicionándose como infraestructura clave para que los sistemas de IA sean más confiables y seguros

Introducción

  • Los modelos de IA ya se usan en software para diversos fines, como copilotos de aplicaciones, integración con IDE y uso de herramientas mediante el protocolo MCP
    • Estos avances aumentan la necesidad de garantizar privacidad, seguridad y funcionamiento correcto
  • La seguridad y la privacidad deben asegurarse desde la etapa de diseño del sistema; agregarlas después no es suficiente
  • Inspirándose en la Java Virtual Machine (JVM), se propone la importancia de una máquina virtual estandarizada para modelos de IA
    • La JVM proporciona un entorno de ejecución confiable mediante seguridad de memoria, control de acceso y verificación de bytecode
    • Gracias a ello se hizo posible “escribir una vez y ejecutar en cualquier lugar”

El papel de la máquina virtual para modelos de IA (MVM)

  • La MVM funciona como software intermediario entre el modelo de IA y el entorno externo
    • Ejemplo: cuando un usuario escribe un prompt como “reservar un vuelo”, la MVM lo envía al modelo, incluso añadiendo contexto
    • Si el modelo responde “usar la herramienta de reserva”, la MVM verifica la lista de herramientas permitidas y decide si realizar o no la llamada
    • Esto garantiza que el modelo no haga llamadas no autorizadas
  • Todo sistema comercial de IA necesita un software de control similar
  • La MVM define un conjunto de instrucciones, por ejemplo:
    • autenticar, cargar, inicializar y descargar modelos
    • invocar modelos con contexto
    • parsear la salida del modelo
    • autenticar, cargar e invocar herramientas, parsear resultados y almacenarlos en memoria
    • solicitar entrada del usuario, añadir memoria de historial y usar estructuras de control como condicionales

Investigación existente y necesidad

  • Protocolo de llamadas estructuradas a herramientas de OpenAI: ofrece una integración clara de herramientas mediante una API de llamadas a funciones basada en JSON y especificaciones OpenAPI
  • MCP (2024) de Anthropic: un protocolo abierto que conecta asistentes de IA con datos externos
    • Se compara con “el puerto USB-C de las aplicaciones de IA” y ofrece una interfaz universal
    • Ya cuenta con casos de adopción rápida, incluso en grandes empresas
  • Orquestadores de seguridad – FIDES y AC4A (2025):
    • FIDES (Microsoft Research): aplica políticas de flujo de información, rastrea etiquetas de confidencialidad de datos y añade una acción de “inspección”
    • AC4A: administra herramientas y datos en una estructura jerárquica al estilo de un sistema operativo y fuerza un modo de operación de mínimo privilegio
    • Estos proyectos muestran que una MVM puede incorporar seguridad y control de acceso de forma nativa
  • Runtimes de agentes de código abierto: langchain, Semantic Kernel, llguidance ofrecen servicios de runtime que apoyan el desarrollo estable de aplicaciones de IA
  • La especificación de una MVM requiere que los datos de entrenamiento del modelo reflejen la especificación de la interfaz, y hace necesaria una coevolución entre el modelo y la MVM

Beneficios de la MVM

  • Separación de responsabilidades: separa la lógica del modelo de la lógica de integración, convirtiendo al modelo en un componente intercambiable
    • Se mantiene la interoperabilidad al reemplazarlo por un modelo nuevo o al moverlo a otra plataforma
  • Seguridad y gobernanza integradas: la MVM garantiza la seguridad mediante verificación de permisos, registros de auditoría y mecanismos de protección
    • Como en AC4A, la MVM puede actuar como guardián para frenar comportamientos inesperados
  • Seguimiento transparente del rendimiento: mediante diagnósticos en tiempo de ejecución, ofrece visibilidad sobre rendimiento del modelo, consumo de recursos y niveles de acceso a datos
    • Con benchmarks es posible comparar precisión, utilidad y capacidad de respuesta
  • Validación de la salida del modelo: técnicas como las pruebas de conocimiento cero permiten verificar la integridad de la salida, reforzando la confianza y la rendición de cuentas

Conclusión

  • Una máquina virtual para modelos de IA es necesaria para reducir la complejidad de los sistemas de IA y aumentar la interoperabilidad
  • Refuerza la seguridad, la privacidad, la portabilidad y la confiabilidad, al tiempo que acelera el desarrollo y amplía la escalabilidad del ecosistema
  • Con base en investigaciones de empresas tecnológicas, startups y la academia, una especificación de MVM puede ofrecer un estándar para que los modelos de IA interactúen de forma segura y fluida
  • El objetivo es construir consenso con la comunidad sobre la necesidad de una especificación de MVM y los elementos que debe incluir

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-09-01
Opiniones en Hacker News

  • Creo que a este texto le faltan explicaciones concretas, así que no queda claro qué está proponiendo exactamente. Una VM (Virtual Machine) al final está relacionada con el conjunto de instrucciones, el flujo de control, registros, etc., pero este texto se enfoca solo en la autorización. En esencia, parece estar hablando de “algo parecido a un sandbox, jail o contenedor que permita que el modelo interactúe con el mundo exterior”

    • Me pregunto si realmente se refiere a un motor de ejecución de VM, o a algo como Docker para LLM. En general, parece una idea más empaquetada que desarrollada. Si el diseño del sistema de empaquetado es deficiente, puede ser un desastre. Basta ver varias experiencias con el empaquetado en Python

    • Al ver la palabra VM, de inmediato me sonó muy cercana a sandbox. Como el propio texto habla de “aislamiento”, no sentí que fuera ambiguo ni que faltara información. Aun así, el argumento del autor es demasiado obvio y la solución está incompleta. Incluso si lo metes en un sandbox a nivel de OS o hardware, sigue siendo problemático si el agente encuentra algo como un AWS CLI con IAM mal configurado. Los límites remotos también son complejos. No encontré ninguna idea nueva. No creo que el problema sea la elección del término

    • Según la definición que da el texto, podría decirse que los AI agents actuales ya se están ejecutando dentro de una VM. Por ejemplo, en un MCP host se puede pedir la aprobación del usuario para ejecutar algo, o se pueden tener reglas que autoaprueben ciertos patrones de comandos, como en Claude code

  • Creo que el problema esencial no es qué herramientas darle al LLM, sino qué acciones permitirle realizar. Por ejemplo, en un escenario de reserva de vuelos, quiero que el LLM compare precios en varios sitios web e incluso complete el pago. Pero no quiero que elija una opción inútil como un vuelo de 37 horas solo porque cuesta 3 dólares menos. Al consultar beneficios laborales, solo debería poder ver los suyos, no los de sus colegas. Incluso con la misma herramienta, el alcance de los permisos cambia. Un responsable de RR. HH. obviamente puede ver la información de los empleados que administra, pero en ese caso aparecen otros temas como el registro de auditoría. Es decir, más que la acción, importa la intención. Lo deseable es poner al LLM como representante del usuario dentro de la misma caja de permisos

    • En el fondo, de lo que se está hablando es de un capability security model. Hay que pasarle explícitamente al agente de software las capabilities a las que puede acceder, y cualquier acción fuera de esa lista debería quedar físicamente imposibilitada. Pero en la práctica no hay sistemas operativos mainstream que implementen este modelo. Ha habido varios estudios e intentos (ejemplos de OS: EROS, Fuchsia, Sandstorm), pero no tuvieron mucho éxito en el mercado. Por eso, en la práctica, lo más cercano es usar una VM y dejar dentro de ella solo las herramientas necesarias. No es perfecto, porque las herramientas en sí son demasiado generales comparadas con capabilities reales. El software construido bajo el principio de mínimo privilegio suele fracasar en el mercado

    • No importa tanto qué acciones puede realizar una herramienta, sino la combinación de datos y acciones a los que esa herramienta puede acceder. Como no se puede predecir perfectamente el comportamiento del LLM, no hay que confiar en él. Por ejemplo, al LLM se le puede permitir acceso solo a sitios de reserva de vuelos, pero no se le deben pasar datos como SSN o información de cuentas bancarias. El problema es la procedencia de los datos (provenance) y los permisos. Cuanto más sensibles sean los datos de una tarea, más restricciones se necesitan; en cambio, si son menos sensibles, se pueden permitir más acciones. Los datos deberían llevar información de permisos, y un mediador debería limitar qué datos y acciones puede tener una tarea nueva al hacer spawn. Ejemplo: si una tarea de planificación de viaje hace spawn de una subtarea para buscar vuelos, el mediador solo debería pasarle datos no sensibles, como parte del itinerario, y bloquear el acceso a datos sensibles

    • Se puede ver al LLM agent como otro usuario más, con los mismos privilegios base que el usuario. Tiene permisos distintos según el contexto. Por ejemplo, puede tener lectura/escritura en una carpeta de código fuente y solo lectura en otra. Los permisos del LLM agent cambian según el proyecto y son la intersección o un subconjunto de los permisos del usuario. Básicamente hay tres tipos de permisos: Allow, Deny y Ask (pedir permiso), y si hace falta se le pregunta al usuario si lo autoriza. El problema es que los permisos de los OS, las apps y los datos existentes no están lo suficientemente detallados. Incluso git debería estar diseñado para permitir comandos específicos, no acceso total. Hoy las aplicaciones intentan imitar esto cada una por su cuenta en espacio de usuario, de forma torpe. El flujo de trabajo se parece a sudo. Si lanzo una app con mi usuario LLM Agent, se le otorgan o restringen permisos según ese contexto. Solo puede actuar dentro de lo que yo permito cuando se lo pido. Pero hoy cada app agentic tiene que implementar este proceso por su cuenta, así que habría que convertirlo en un servicio sistemático del OS. Como solución temporal, se podría esquivar creando y eliminando cuentas temporales de usuario por cada contexto del agente, comunicándose solo por IPC o red

    • Dudo que este modelo realmente funcione bien. Aunque el LLM pueda hacer algo, los sitios web podrían detectarlo y ajustar precios o romper sus árboles de decisión. En ese caso, sería mucho mejor que todos los sitios usaran directamente una API para LLM, o algo como “rss + json”. Como los BBS o los sistemas de menú por SMS, si solo entregan datos simples y opciones, también sería ideal para los LLM. Lo mismo con la publicidad. No tiene sentido mostrar anuncios a un LLM; de hecho, sería más efectivo hacer anuncios que intenten engañarlo. Por ejemplo, en una búsqueda de vuelos, un anuncio podría engañar al LLM para que crea que mi producto es el mejor. Como la IA todavía es bastante simple, sería curioso ver publicidad diseñada específicamente para IA

    • Si fuera posible definir y hacer cumplir qué es una “buena respuesta”, quizá ni siquiera haría falta un LLM. En el caso de una persona de RR. HH., se le puede preguntar directamente por la intención, pero con un LLM lo veo difícil porque no tiene intención propia

  • Hace tiempo vi un post en HN sobre cómo John Carmack había desperdiciado tiempo y dinero en Meta tratando de crear XROS. En cambio, este texto que vi hoy parece argumentar con fuerza la necesidad de un “nuevo OS”. Una VM no es un OS completo, pero se diferencia en que puede ser ligera y reutilizar OS y codebases existentes

    • Son dos temas completamente distintos. En realidad, tampoco me parece que este texto esté defendiendo con fuerza la necesidad de una VM o de un nuevo OS. Al final, todo se reduce a control de acceso

    • En XR el enfoque estaba en performance y dev experience, mientras que en LLM el tema central es cómo hacer sandboxing y simplificar el acceso a herramientas y datos. Hay mucho trabajo por hacer para evitar que el LLM rompa el entorno de ejecución o corrompa datos, y si hubiera estándares, se reduciría la carga de reentrenamiento y también sería más fácil para otros aprovechar modelos ajenos. En XR, con algo como un SDK, el entrenamiento puede resolver bastante, pero en IA los costos de I+D y cómputo son muchísimo mayores

    • WebAssembly ya ofrece sandbox por defecto, así que diría que ya se ha avanzado a medias. Lo que falta es una interfaz clara para transferir datos y permisos entre instancias, y una forma de que las instancias puedan crearse mutuamente

    • No creo que este texto justifique escribir un nuevo OS. Construir un entorno de ejecución para IA y diseñar desde cero un OS optimizado para IA son cosas completamente distintas

  • Después de leer el texto con cuidado y revisar los enlaces de referencia, sentí que está apuntando a un problema más fundamental que simplemente una “VM para IA”. Una VM sola no basta para garantizar la seguridad de un workflow con LLM. El workflow de nivel superior necesita acceso a tareas y datos sensibles como red, PII y credentials, y los LLM son vulnerables a prompt injection y problemas de consistencia. Meter al LLM en una VM no resuelve eso por sí solo. Hace falta “gestión de flujo de información”: particionar workflow, datos y cómputo por unidad de tarea, para que solo las subtareas mínimas tengan acceso a información limitada. Solo el subconjunto que maneja tareas sensibles debería ser confiable y verificable por separado. Ahí están el núcleo de los “Secure Orchestrators” que menciona el texto y el paper FIDES. Al final, la “VM” no es más que ejecutar una tarea en un contenedor al que solo se le dieron permisos y datos limitados. El orchestrator crea ese contenedor, le asigna permisos adecuados y además debería poner etiquetas de sensibilidad (taint-tracking) a los datos resultantes. En conjunto, me parece más acertado hablar de “partitioning” o “isolation”, y enfatizar los problemas de datos, que de “VM for AI”

    • Suena parecido a Microsoft Wassette

    • El objetivo debería ser eliminar por completo el concepto mismo de workflow. En el esquema LLM+VM, proporcionar herramientas al LLM ya es en sí mismo el workflow. Este enfoque a veces ya funciona bien, pero tiene límites ante excepciones no definidas de antemano o tareas que requieren herramientas nuevas. Además, un enfoque basado en workflows siempre tendrá dificultades para escapar de limitaciones lineales (o DAG, incluso con loops). El siguiente paso es no darle herramientas en absoluto y que el propio LLM cree la herramienta sobre la marcha cuando la necesite. Algunos problemas requieren un enfoque de fuerza bruta

  • Mientras leía esto, me dio la impresión de que últimamente muchos textos parecen escritos por IA. Desde el punto de vista del hosting, lograr levantar un AI agent de forma estable en cualquier entorno ya es un reto enorme. Como desarrollador, uso devcontainers con rootless docker en wsl; puede que algunos malwares logren escapar, pero aun así siento que este enfoque es más seguro que el de una VM. Además, tiene ventajas como reproducibilidad y aislamiento del entorno, y si la IA rompe mi entorno, simplemente vuelvo a levantar el contenedor, así que pesa menos

  • Si uno mira los métodos de despliegue de modelos más avanzados a nivel comercial, casi todas las características mencionadas en este texto, como el aislamiento, ya están implementadas. No al nivel del propio OS, pero funcionalmente se parecen bastante. Aun así, ni eso alcanza. Para que un agente haga bien su trabajo, necesita acceso a recursos importantes, y darle exactamente solo los permisos necesarios es mucho más difícil que aislar al propio LLM. El modelo correcto para la seguridad de un LLM es “untrusted userspace”. No hace falta diseñar todo un OS

    • Creo que “untrusted userspace” es el concepto correcto. Puede que enfoques como estos ayuden un poco en seguridad, pero no coincido con que, como exageran los autores, “garanticen” nada. Compararon el acceso a herramientas con permisos de archivos, pero el historial de los permisos de archivos en los OS no es precisamente brillante. Si vas a verificar si se permite usar una herramienta de reservas o no, al final eso es un navegador web. Y el navegador, además de ser una herramienta de propósito general, también puede estar expuesto a ataques como jailbreak. Lo importante es que incluso bajo estas restricciones de máquina virtual, hacen falta nuevas medidas de seguridad para impedir que el modelo de IA actúe de forma traicionera. La enseñanza simple es que al final hay que resolver sí o sí el problema de alignment

  • Estoy de acuerdo en que el aislamiento de LLM debe llevarse con el mismo rigor que el diseño de una VM. Es por la misma razón por la que en los OS tradicionales estas conductas se aplican con tanta estricta separación. Hace poco resumí algunas ideas en este blog. Lo enfoqué comparando el modo de operación de los LLM con procesos/tareas de un OS tradicional, y las principales abstracciones no son difíciles de implementar: se puede unificar la interfaz de chat/tool de 8 backends de LLM y centralizar la aprobación de herramientas. Aún no implementé el modelo de capabilities, pero por mi experiencia pasada con OS (VSTa), me parece un enfoque natural. Un LLM debería poder delegar a otro un subconjunto de los permisos que posee, y ya construí una herramienta para esa delegación

  • Me parece que crear una nueva máquina abstracta como una VM solo agrega más complejidad. Ya existen cuentas, permisos de lectura/escritura/ejecución de archivos, y el acceso temporal o remoto puede cubrirse suficientemente con access tokens. Creo que cualquier capabilities model puede implementarse de sobra con esos conceptos. Yo preferiría simplificar las herramientas que ya existen. Ahora todos están experimentando con cosas nuevas esperando cambios de fondo en todo el software, pero creo que más bien debería ser un momento para reducir complejidad innecesaria y hacer las cosas más simples. Por ejemplo, convertir un servidor MCP en una herramienta CLI simple para Claude toma 10 minutos. A ese nivel ya me parece bastante usable

    • El modelo de seguridad de los OS de escritorio modernos es absurdamente insuficiente para la época actual. Dar todos los permisos sin apenas avisos ni confirmaciones al usuario roza la locura. Si un usuario realmente quiere un entorno sin restricciones, debería tener esa opción, pero el valor por defecto tendría que ser el mínimo privilegio. Los permisos deberían otorgarse por programa y por dominio. Por ejemplo, una herramienta para visualizar uso de disco podría necesitar acceso completo al filesystem, pero no tendría por qué tener acceso a la red local ni a Internet

    • La mayor fortaleza de una VM es limitar el alcance del daño. Un buen agente podría usar zero days del sistema para comprometerlo fácilmente. Incluso con permisos de usuario ya es lo bastante peligroso, y limitar el conocimiento del agente con un firewall es muy difícil, porque en Internet hay muchas formas de esquivarlo. Como estos sistemas se volverán muy buenos para hackear sistemas, hacen falta defensas extremadamente sólidas

    • En un entorno LLM, una “lectura temporal” no existe realmente. En cuanto algo entra en el contexto, hay que asumir que puede filtrarse a cualquier lugar conectado hasta que el agente muera y el contexto se elimine. Eso da igual si hay VM o no; una VM por sí sola no es una solución de seguridad

    • Estoy de acuerdo en la mayor parte. Muchos riesgos de seguridad existen con o sin VM. Hacia adelante, defense in depth va a ser todavía más importante, pero por ahora hay demasiadas formas fáciles para que un atacante use un AI agent para perjudicar a un usuario

    • En el momento en que permites una herramienta de edición de archivos, en realidad ya perdiste casi toda la seguridad

  • Creo que Fuchsia podría ser un OS realista para controlar el comportamiento de modelos de IA. Como es un object capability OS, cada componente (proceso) solo puede acceder a las capabilities que se le otorgaron explícitamente

    • Me gusta y comparto el diseño de Fuchsia, pero no creo que llegue a hacerse realidad. En vez de crear un OS nuevo, veo más probable que el rumbo sea un modelo tipo Fuchsia basado en componentes WASM/WASI, capaz de alojarse desde la nube hasta el móvil

  • Cuando ChatGPT ejecuta código (por ejemplo, al pedirle procesar un CSV), parece hacerlo dentro de una VM con acceso solo a ciertas herramientas y librerías, un disco sandboxeado y sin conexión a Internet. O sea, ya se está avanzando hacia una estructura bastante parecida

    • Devin y OpenHands son parecidos. Incluso en un proyecto piloto de IA que hice hace unos meses, uno de los elementos clave era “ejecutar el agente en una VM (por defecto)”

    • Es una forma montada sobre Kubernetes en AKS (Azure Kubernetes), con gvisor y Jupyter encima

    • No necesariamente. Por ejemplo, si asumimos que en una máquina corren dos IAs (como ChatGPT y otra), no existe ningún estándar ni interoperabilidad para colaboración o funcionamiento conjunto entre ellas.