Meta Muse ofrece una respuesta sorprendentemente concreta a una pregunta que la industria de la IA ha evitado en gran medida: ¿dónde vive realmente un agente personal de IA?
La respuesta de Meta no es «dentro de la aplicación de chat». Cada Muse obtiene un ordenador dedicado en la nube, con almacenamiento, memoria, un navegador, un sistema de archivos, tareas en segundo plano y sus propios límites de seguridad. Esto importa porque un agente que sigue trabajando después de que cierres el portátil necesita algo más que un modelo potente. Necesita un lugar persistente donde vivir.
¿Qué es Meta Muse y cómo funciona?
Meta Muse es un agente personal de IA diseñado para hacer tareas, no solo para responder preguntas. Puede usar servicios conectados, enviar correos electrónicos, realizar compras con aprobación, recordar información sobre el usuario, trabajar para alcanzar objetivos a más largo plazo y continuar las tareas en segundo plano.
Lo importante es su arquitectura. Muse Spark proporciona el modelo de razonamiento, pero el propio agente funciona desde Muse Secure VM. Esa máquina virtual contiene los archivos del usuario y los datos de los servicios conectados, además de proporcionar a Muse un navegador, herramientas, capacidad de cómputo y un espacio de trabajo persistente.
Esto separa dos conceptos que a menudo se tratan como uno solo: el modelo que razona y el ordenador donde vive el agente.
¿Qué es Muse Secure VM?
Meta describe Muse Secure VM como un ordenador en la nube dedicado para cada usuario. Es una máquina virtual Linux aislada, con su propio navegador y suficiente CPU, memoria y almacenamiento para compilar código, desarrollar Skills personalizadas, ejecutar subagentes simultáneos y ejecutar tareas cron.
La máquina virtual también es el registro principal de todo lo que el usuario introduce en Muse. Los archivos, el estado persistente de las aplicaciones, los datos relacionados con la memoria y las credenciales de los servicios conectados se conservan en este entorno persistente, en lugar de existir únicamente dentro de una conversación con un modelo.
Es un cambio arquitectónico importante. Muse se parece más a darle a un agente de IA su propia estación de trabajo que a insertar otro asistente en el teléfono del usuario.
¿Por qué un agente de IA necesita su propio ordenador?
Un chatbot puede desaparecer después de devolver una respuesta. Un agente personal útil no puede hacerlo. Puede estar esperando un evento, ejecutando una tarea programada, conservando trabajo sin terminar, preservando archivos o coordinando varios subagentes mientras el usuario se encuentra en otro lugar.
Esos trabajos requieren una infraestructura informática común: un sistema de archivos, ejecución de procesos, bases de datos, acceso a la red, registros, credenciales y estado persistente. Nada de eso se resuelve simplemente proporcionando al modelo subyacente una ventana de contexto más grande.
| Asistente de chat | Agente siempre activo |
|---|---|
| Responde a una indicación | Trabaja hacia un objetivo |
| Sesión temporal | Estado persistente |
| Historial de conversaciones | Memoria, archivos y bases de datos |
| Pocas acciones inmediatas | Herramientas, habilidades y conectores |
| El usuario espera una respuesta | Los trabajos en segundo plano continúan |
| Centrado en el modelo | Centrado en la ejecución |
Esta es la lección más importante de Muse: un agente de IA siempre activo se está convirtiendo en una carga de trabajo de servidor. El modelo de frontera puede seguir ejecutándose en otro lugar, pero el agente necesita una infraestructura persistente a su alrededor.
¿Muse de Meta sigue trabajando en segundo plano?
Sí. Meta diseñó Muse para avanzar en el trabajo después de que el usuario le proporciona un objetivo, en lugar de exigir que la aplicación permanezca abierta durante cada paso. Su máquina virtual dedicada también puede gestionar subagentes simultáneos y trabajos cron programados.
Eso cambia el significado de «IA personal». Una tarea puede comenzar con una conversación, continuar como trabajo en segundo plano, esperar nueva información, activar otra acción más adelante y volver al usuario solo cuando se requiera su aprobación o una decisión.
Para ese modelo, la disponibilidad es importante. El ordenador del agente debe permanecer disponible incluso cuando el ordenador del usuario no lo esté.
¿Dónde almacena Muse los archivos, la memoria y el estado del agente?
Meta afirma que la máquina virtual dedicada del usuario actúa como fuente de verdad para todo lo que se incorpora a Muse. El estado persistente de las aplicaciones se almacena en PostgreSQL, fuera de la celda principal de ejecución del agente, mientras que los archivos y los datos del espacio de trabajo permanecen dentro del entorno de la máquina virtual dedicada.
Esto es diferente de depender por completo del contexto del modelo. Un modelo puede olvidar tokens antiguos, resumir una conversación o ser reemplazado por un modelo más reciente. Los archivos y las bases de datos persistentes sobreviven a esos cambios.
Es probable que esa separación sea cada vez más importante para los agentes personales: el razonamiento puede reemplazarse; el estado persistente no debería tener que reemplazarse.
¿Cómo protege Muse las contraseñas y las credenciales?
Muse está diseñado deliberadamente para no ver las credenciales reales que utiliza. Los tokens de OAuth y otros secretos los almacena un servicio de autenticación independiente, fuera de la celda de ejecución del agente, y las operaciones que requieren credenciales se ejecutan mediante procesos con controles más estrictos.
El navegador sigue el mismo principio. Cuando un usuario introduce una contraseña, esta puede ir directamente al almacenamiento protegido de credenciales y posteriormente inyectarse en el navegador sin exponerla al agente principal de Muse.
Esto es importante porque un agente autónomo no debería necesitar acceso sin restricciones a todos los secretos necesarios para realizar su trabajo. La capacidad de usar una credencial y la capacidad de leer una credencial son permisos diferentes.
¿Qué es Sentinel de Meta Muse?
Meta coloca un segundo agente, Sentinel, fuera del entorno de ejecución principal de Muse. Sentinel es la autoridad de permisos para las acciones de los conectores y la salida de red: Muse puede proponer una acción, pero no puede decidir por sí solo que la acción está permitida.
Esto crea una separación útil entre razonar sobre qué hacer y tener autoridad para hacerlo realmente. Las acciones sensibles pueden denegarse o devolverse al usuario para su aprobación, mientras que los límites deterministas del sistema siguen vigentes incluso si Muse toma una mala decisión.
Esto es especialmente importante porque la inyección de prompts sigue siendo un problema abierto. Las páginas web, los archivos y las salidas de las herramientas pueden contener instrucciones maliciosas, por lo que Meta trata los datos externos como potencialmente no confiables en lugar de asumir que el modelo siempre reconocerá un ataque.
¿La VM segura de Muse es solo un sandbox?
Es más complejo que un solo contenedor. Dentro de cada VM, el arnés principal de Muse, el espacio de trabajo, las herramientas y los binarios se ejecutan en un systemd-nspawn celda de ejecución. El usuario root dentro de esa celda se asigna a un usuario sin privilegios del host, mientras que las capacidades peligrosas del kernel y las llamadas al sistema están restringidas.
Los componentes sensibles para la seguridad se encuentran fuera de la celda de ejecución. El almacenamiento de credenciales, la ejecución de conectores, los clasificadores de seguridad, Sentinel, el estado persistente de PostgreSQL y los proxies de red están separados, de modo que comprometer el agente principal no otorgue automáticamente el control de todas las protecciones.
Meta resume bien el diseño: el modelo mental adecuado es dos dominios de seguridad aislados en una misma máquina, no un agente de IA con acceso root sin restricciones.
¿Puede Meta acceder a los datos dentro de la VM segura de Muse?
Con la VM segura disponible desde el lanzamiento, sí, en determinadas circunstancias. Meta afirma que las políticas operativas restringen el acceso del personal, pero la arquitectura actual no impide técnicamente que Meta acceda a los datos de la VM cuando sea necesario para brindar soporte, proteger u operar el servicio.
Esa distinción es importante. El aislamiento frente a otros usuarios y el aislamiento frente al proveedor de la nube son garantías de privacidad diferentes.
Meta también afirma que las conversaciones y los datos de la máquina virtual no se comparten con sus sistemas publicitarios, mientras que las trayectorias de inferencia pueden anonimizarse y utilizarse para entrenar modelos, a menos que el usuario renuncie a ello. Estas son políticas del producto, no garantías criptográficas.
¿Qué es la máquina virtual confidencial de Muse?
Meta planea ofrecer una máquina virtual confidencial de Muse más adelante, en 2026. El objetivo es cifrar la máquina virtual para que ni siquiera Meta pueda acceder a los datos que contiene, con un diseño pensado para ser auditable externamente.
Esto revela una jerarquía importante de privacidad:
| Arquitectura | ¿Quién controla la infraestructura? | ¿Puede el proveedor acceder técnicamente a los datos? |
|---|---|---|
| Agente estándar en la nube | Proveedor de la nube | Normalmente posible |
| Máquina virtual segura de Muse | Meta | Posible en circunstancias definidas |
| Máquina virtual confidencial de Muse | Meta | Diseñado para impedir criptográficamente el acceso |
| Servidor de agentes autoalojado | Usuario | Depende de los servicios y las conexiones con modelos utilizados |
Por tanto, «nube» y «privado» no son términos opuestos. Las preguntas reales son quién controla la máquina, quién controla las claves de cifrado, qué datos salen de la máquina y en qué componentes se confía.
¿Es un servidor doméstico una alternativa a la máquina virtual segura de Muse?
Desde el punto de vista arquitectónico, un servidor doméstico puede realizar muchas de las mismas tareas persistentes: permanecer conectado, almacenar archivos, ejecutar bases de datos, alojar índices RAG, guardar la memoria del agente, ejecutar contenedores, programar automatizaciones y conservar copias de seguridad. Eso no significa que un servidor doméstico recree automáticamente Muse.
El modelo de seguridad de Muse incluye aislamiento en tiempo de ejecución, sustitución de credenciales, salida de red restringida, aplicación independiente de políticas, clasificadores y barreras de aprobación. Darle simplemente a un contenedor Docker acceso a un directorio personal y a varias claves de API no es equivalente.
La ventaja de un servidor doméstico es diferente: la propiedad y el control de la capa persistente. Los usuarios pueden decidir dónde se almacenan los archivos, las bases de datos, las Skills, los registros y los servicios, y seguir utilizando modelos en la nube cuando sea útil contar con inferencias de vanguardia.
Máquina virtual en la nube frente a servidor doméstico: ¿dónde debería residir un agente siempre activo?
La elección depende menos del rendimiento bruto de la IA que de las prioridades operativas. Una máquina virtual administrada elimina el mantenimiento y puede integrar estrechamente la seguridad con el producto. Un servidor doméstico ofrece más control sobre los datos persistentes y los servicios autohospedados, pero hace que el usuario sea responsable del aislamiento, las actualizaciones, las copias de seguridad y las políticas de acceso.
| Requisito | Máquina virtual segura administrada | Servidor doméstico |
|---|---|---|
| Disponibilidad las 24 horas, los 7 días de la semana | Encaja muy bien | Encaja muy bien |
| Sin mantenimiento de la infraestructura | Encaja muy bien | Encaja mal |
| Propiedad local de los archivos | Administrada por el proveedor | Encaja muy bien |
| Servicios personalizados autohospedados | Depende de la plataforma | Encaja muy bien |
| Controles de seguridad integrados | Encaja muy bien | Depende del usuario |
| Modelos de frontera en la nube | Nativa | Se puede conectar de forma remota |
En última instancia, una arquitectura híbrida puede ser más práctica que tratar la nube y la infraestructura local como opciones mutuamente excluyentes. Los datos privados y los servicios persistentes pueden permanecer en una infraestructura controlada por el usuario, mientras que el contexto seleccionado se envía a un modelo de frontera cuando su capacidad de razonamiento justifica la compensación.
¿Necesita una GPU potente un agente de IA siempre activo?
No necesariamente. Muse ayuda a demostrar por qué «servidor de agentes» y «servidor de inferencia» no deberían tratarse como sinónimos.
| Carga de trabajo del agente | Requisito de GPU local |
|---|---|
| Almacenamiento de archivos | Ninguna |
| PostgreSQL y memoria | Ninguna |
| Tareas cron | Ninguna |
| Servicios de API y MCP | Ninguna |
| Habilidades y scripts | Normalmente ninguna |
| Almacenamiento y recuperación para RAG | Normalmente ninguna o baja |
| Embeddings | Aceleración opcional |
| Inferencia local a escala de frontera | Potencialmente muy alta |
Un ordenador para agentes necesita persistencia antes que un hardware de inferencia masiva. El almacenamiento, las bases de datos, las redes, la automatización y la disponibilidad continua son útiles incluso cuando el modelo principal de razonamiento vive en la nube.
¿Qué revela Meta Muse sobre el futuro de la IA personal?
Lo más interesante que Meta creó para Muse quizá no sea Muse Spark. Quizá sea la decisión de darle al agente un ordenador propio.
Esa arquitectura reconoce algo importante: cuando la IA pasa de responder preguntas a mantener objetivos, operar herramientas, almacenar memoria y trabajar sin supervisión, el modelo se convierte en un solo componente. El agente también necesita un lugar duradero para su estado y sus servicios.
Por tanto, la futura pila de IA personal podría dividirse en dos capas reemplazables: un motor de razonamiento y un ordenador para agentes. El motor de razonamiento podría ser Meta, OpenAI, Anthropic o un modelo local. El ordenador persistente puede ser una máquina virtual administrada en la nube, un servidor doméstico de propiedad privada o una combinación de ambos.
La respuesta de Muse es un ordenador dedicado en la nube de Meta. La lección más importante es más duradera: la IA siempre activa necesita un lugar donde vivir.
Preguntas frecuentes
¿Meta Muse se ejecuta localmente?
No. Muse se ejecuta en una máquina virtual dedicada en la nube de Meta. La aplicación Muse o la interfaz web se conecta a ese entorno de agente remoto.
¿Meta Muse está siempre en ejecución?
Muse está diseñado para el trabajo en segundo plano y de larga duración, y su máquina virtual puede ejecutar tareas cron programadas y subagentes simultáneos. Las tareas individuales siguen dependiendo de los permisos, la disponibilidad del servicio y las políticas de ejecución de Muse.
¿Es Muse Secure VM un ordenador físico independiente?
No. Es una máquina virtual dedicada, lo que significa que el usuario recibe un entorno de computación virtual aislado en lugar de un servidor físico dedicado.
¿Dónde almacena Meta Muse su memoria?
Meta afirma que la máquina virtual dedicada es la fuente de verdad de los datos de Muse. El estado duradero de la aplicación se almacena en PostgreSQL, mientras que los demás archivos y datos del espacio de trabajo permanecen dentro del entorno de la máquina virtual del usuario.
¿Puede Meta ver los datos dentro de Muse Secure VM?
La versión de lanzamiento no impide técnicamente que Meta acceda a los datos de la máquina virtual cuando sea necesario para operar, ofrecer asistencia o proteger el servicio. Meta afirma que las políticas operativas restringen el acceso. La VM confidencial prevista tiene como objetivo impedir criptográficamente que la propia Meta lea los datos.
¿Puede Muse ver mis contraseñas?
Meta diseñó Muse para que el agente principal no reciba las contraseñas reales ni las credenciales de los servicios conectados. Los secretos se mantienen en un almacenamiento de credenciales separado y se proporcionan a las operaciones autorizadas sin exponerlos directamente al agente.
¿Qué hace Muse Sentinel?
Sentinel es un agente de permisos independiente que evalúa las acciones de los conectores y el acceso a la red. Muse puede proponer una acción, pero Sentinel determina si se permite, se deniega o requiere la aprobación del usuario.
¿Puede un agente de IA personal ejecutarse en un servidor doméstico?
Sí. Un servidor doméstico puede alojar componentes persistentes de agentes, como archivos, bases de datos, memoria, sistemas RAG, Skills, herramientas, automatización y copias de seguridad. Recrear el aislamiento y las protecciones de credenciales de un sistema gestionado como Muse requiere ingeniería de seguridad adicional.
¿Un servidor de agentes de IA necesita una GPU?
No para muchas cargas de trabajo de agentes. Los archivos, las bases de datos, la memoria, la automatización, los servicios de API, el almacenamiento RAG, los registros y las copias de seguridad pueden ejecutarse sin una GPU potente. Los requisitos de GPU dependen principalmente de si el servidor también realiza inferencias locales de IA.
¿Es un servidor doméstico más privado que Muse Secure VM?
Puede ofrecer al usuario un mayor control sobre la infraestructura y los datos, pero el alojamiento local no es automáticamente seguro ni privado. Los permisos, el acceso remoto, las API de terceros, la inferencia en la nube, las credenciales, las copias de seguridad y la configuración de red siguen determinando qué datos pueden salir del servidor.
Centro de Tecnología e IA
Más para leer

¿Cómo proporciona un intermediario secreto credenciales a un agente de IA sin exponerlas en los prompts?
Sigue la identidad de la carga de trabajo, la política, la emisión de tokens, la inyección de solicitudes, la redacción, la caducidad y la...

¿Cómo contiene un entorno aislado de herramientas los efectos secundarios de un agente de IA?
Descubre cómo el aislamiento, los controles de capacidad, el estado desechable, el control de salida, las cuotas y los registros de auditoría limitan los...

¿Cómo produce el decodificado restringido un JSON válido según el esquema?
Comprende la compilación de esquemas, el enmascaramiento de tokens, el estado del analizador sintáctico, los subconjuntos compatibles, la latencia, el truncamiento y por qué...

