Español

Microsoft Convirtió Windows en una Plataforma de Agentes en Build 2026. Aquí Está la Decisión del CTO Antes de que el Windows Agent Store Alcance GA

Tres runtimes de agentes de Windows anclados por el Windows Agent Store

El keynote de Build 2026 de Microsoft no se limitó a presentar funcionalidades. Cambió el modelo de compras para el despliegue de agentes empresariales en Windows, y la decisión que tome su equipo en el Q3 determinará la flexibilidad que tendrá una vez que el Windows Agent Store (WAS) alcance disponibilidad general (GA).

El 2 de junio en Fort Mason, San Francisco, Satya Nadella abrió Build 2026 con un conjunto de anuncios que, tomados en conjunto, redefinen lo que significa ejecutar agentes dentro de su organización. Según el resumen de Build 2026 de ChatForest, Microsoft lanzó el Windows Agent Framework (WAF) como proyecto de código abierto con licencia MIT, puso el Windows Agent Runtime (WAR) en versión preliminar, abrió el Windows Agent Store con una distribución de ingresos del 85/15 para desarrolladores y nombró Project Polaris como el modelo predeterminado de reemplazo en GitHub Copilot a partir de agosto de 2026.

Esa última parte merece una segunda lectura. Microsoft reemplaza GPT-4 con su propio modelo de desarrollo interno en su propio producto para desarrolladores, ejecutándose en sus propios aceleradores Maia. La empresa que construyó su estrategia de IA sobre OpenAI ahora integra verticalmente la capa de modelos. Para los CTO que han aprobado un número de asientos de GitHub Copilot basándose en la calidad del modelo de OpenAI, esto no es una nota al pie. Es una conversación de renovación.

Qué Se Entregó Realmente en Build 2026

Datos Clave:

  • Reparto de ingresos del 85/15 para desarrolladores: El Windows Agent Store paga a los desarrolladores el 85%, frente al 70/30 de Apple App Store y Mac App Store. Microsoft ofrece condiciones más favorables para ganar la distribución de ISV. (Fuente: resumen de Build 2026 de ChatForest)
  • Project Polaris pasa a ser predeterminado en GitHub Copilot: agosto de 2026, con un período de retroceso opcional a GPT-4 de 3 meses. Se ejecuta en los aceleradores Maia de Microsoft. (Fuente: ChatForest)
  • Keynote de Build 2026: 2 de junio de 2026, Fort Mason SF, apertura de Satya Nadella. (Fuente: NotebookCheck)

Esto es lo que Microsoft anunció realmente, sin la capa de marketing:

  • Windows Agent Framework (WAF): Un framework de desarrollo de agentes de código abierto con licencia MIT, con API nativas de agentes integradas en el shell del sistema operativo Windows. La licencia MIT significa que se estandarizará rápidamente. Se espera que los constructores de agentes de terceros apunten a WAF en cuestión de meses.
  • Windows Agent Runtime (WAR): Un runtime en versión preliminar que aloja y ejecuta agentes directamente en dispositivos Windows. Este es el entorno de ejecución local. Se complementa con el Windows 365 for Agents existente, que utiliza una Cloud PC (PC personal en la nube) como host del agente. Ahora existen dos runtimes para agentes de Windows antes de llegar siquiera a Azure.
  • Windows Agent Store (WAS): Un marketplace curado para distribuir agentes a usuarios empresariales. Adobe y Zoom son nombrados como socios de diseño. El reparto de ingresos del 85/15 es el titular: los desarrolladores conservan más, por lo que más desarrolladores construyen primero para Windows.
  • Project Polaris: El modelo de codificación propio de Microsoft. Reemplaza a GPT-4 como motor predeterminado de GitHub Copilot en agosto de 2026. Habrá disponible un retroceso de 3 meses a GPT-4. Polaris se ejecuta en los aceleradores Maia personalizados de Microsoft, lo que significa que la estructura de costos de inferencia queda completamente bajo el control de Microsoft de ahora en adelante.

Por Qué Tres Runtimes Es la Historia Real

Comparación de los niveles de runtime de agentes de Windows que muestra Local WAR, Windows 365 y Azure Agent Mesh

El anuncio que recibe mayor cobertura es el Windows Agent Store. Pero la decisión estructural subyacente es menos evidente: Microsoft ahora ofrece a los CTO empresariales tres entornos de runtime distintos para agentes de Windows, y el store se conecta a los tres.

Aquí está el desglose:

Runtime Más adecuado para Propietario de la identidad Ubicación del registro de auditoría
Windows Local + WAR Agentes anclados en escritorio, flujos de trabajo con capacidad offline Identidad del dispositivo (unido a Entra) Registro de eventos local + reenvío a SIEM
Windows 365 for Agents (Cloud PC) Agentes accesibles por navegador, equipos distribuidos, sustitución de VDI Identidad en la nube (Entra ID) Centro de cumplimiento de Microsoft 365
Azure Agent Mesh Orquestación del lado del servidor, pipelines multi-agente, agentes de capa API Principal de servicio o identidad administrada Azure Monitor + Sentinel

Estos no son intercambiables. Un agente construido para Windows Local + WAR tiene un modelo de identidad fundamentalmente diferente al que se ejecuta dentro de una Cloud PC de Windows 365. Mezclarlos sin una elección explícita crea brechas de auditoría, lo que implica riesgo de cumplimiento normativo.

Compare esto con cómo Apple gestiona la distribución: la App Store (70/30) y la Mac App Store (70/30) alimentan ambas un único runtime. Microsoft ejecuta una arquitectura más compleja, y el reparto del 85/15 del WAS es el incentivo para que los ISV construyan en los tres runtimes.

Para los CTO que están desarrollando un marco de evaluación de proveedores de IA, esta tricotomía de runtimes debe ser un eje de evaluación explícito antes de aprobar cualquier agente específico. Si espera hasta que los agentes ya estén desplegados para preguntar "¿en qué runtime se están ejecutando?", encontrará la respuesta dispersa en tres superficies de gobernanza diferentes.

El marco nombrado para pensar en esto: La Prueba de los Tres Runtimes. Para cualquier nuevo despliegue de agentes de Windows, haga tres preguntas antes de aprobarlo: ¿En qué runtime vive este agente (Local WAR / Windows 365 Cloud PC / Azure Agent Mesh)? ¿Quién es propietario de su identidad y registro de auditoría? ¿Cuál es el camino de retroceso si el runtime queda obsoleto o el proveedor abandona el store?

Qué Cambia Esto para la Renovación de GitHub Copilot

Project Polaris no es simplemente un cambio de modelo. Es Microsoft re-asegurando su propio stack de productos de IA.

Cuando su organización aprobó los asientos de GitHub Copilot, estaba comprando la calidad del modelo de OpenAI dentro de un producto de Microsoft. A partir de agosto de 2026, el modelo predeterminado es Polaris, un modelo de codificación construido por Microsoft que se ejecuta en aceleradores Maia. El retroceso de 3 meses a GPT-4 da tiempo, pero es un retroceso, no una opción permanente. Pasada esa ventana, permanecer en GPT-4 dentro de Copilot probablemente requerirá una configuración explícita o un nivel de producto diferente.

Las preguntas que su equipo debe responder antes del cambio predeterminado de agosto:

  1. ¿La aprobación de asientos de Copilot incluyó un benchmark de calidad del modelo? En caso afirmativo, ejecute Polaris contra él ahora, durante la ventana de retroceso.
  2. ¿Su organización tiene una licencia GitHub Enterprise con acceso a personalización de modelos? En ese caso, la migración a Polaris es una decisión de configuración, no solo una decisión de renovación.
  3. ¿La política de uso de IA de su equipo de seguridad hace referencia específicamente a OpenAI, o hace referencia al "modelo que impulsa Copilot"? De cualquier manera, se impone una revisión de la política. Consulte Building Your AI Use Policy para saber qué debe cubrir esa revisión.

El problema más profundo es la concentración en un solo proveedor. El paso de Microsoft a Polaris es exactamente el tipo de cambio de dependencia de un solo proveedor que las estrategias de mitigación de la dependencia de proveedores de IA están diseñadas para detectar a tiempo. Puede estar bien con Polaris, pero la decisión de aceptarlo debe ser explícita, no por defecto.

FAQ

¿Debemos migrar fuera de GPT-4 en GitHub Copilot en agosto?

No de inmediato. Microsoft proporciona un retroceso opcional de 3 meses a GPT-4 después de que Polaris se convierta en el predeterminado. Pero el retroceso es temporal. Lo correcto es probar Polaris con los flujos de trabajo de codificación reales de su equipo ahora, durante la ventana de versión preliminar, y tratar el retroceso como un margen para la evaluación, no como una permanencia prolongada.

¿El Windows Agent Store es un marketplace controlado por la empresa o abierto?

Microsoft lo describe como curado, con Adobe y Zoom como socios de diseño. Pero "curado" no significa controlado por TI. Los administradores empresariales probablemente necesitarán configurar las políticas de acceso al WAS a través de Microsoft Intune o acceso condicional basado en Entra. El nivel de granularidad de esos controles no quedará claro hasta que llegue GA. Los CTO deben presionar a los equipos de cuentas de Microsoft para obtener detalles específicos sobre los controles de tenant empresarial antes de aprobar cualquier agente proveniente del WAS.

La Lista de Verificación de Compras de Agentes de Windows para el Q3

Ejecute esto con sus líderes de arquitectura y seguridad antes de que el Windows Agent Store alcance GA:

Paso 1: Asigne cada agente actual y planificado de Windows a un runtime. Mapee cada agente (incluyendo GitHub Copilot, cualquier integración de Azure OpenAI y cualquier herramienta ISV con clientes Windows) a uno de los tres runtimes: Windows Local + WAR, Windows 365 Cloud PC o Azure Agent Mesh. No permita agentes sin asignar. Use su proceso de puertas de aprobación de IA y revisión de proveedores para hacer cumplir esto.

Paso 2: Defina la propiedad de identidad y auditoría por runtime. Para cada runtime en uso, especifique qué equipo es propietario de la superficie de identidad (TI, seguridad o ingeniería de plataforma) y dónde aterriza el registro de auditoría. Haga esto explícito en su documentación de registros de auditoría para acciones ejecutadas por IA antes de aprobar cualquier agente proveniente del WAS.

Paso 3: Establezca una puerta de evaluación de Polaris antes de agosto. Programe una revisión de calidad de Copilot durante la ventana de retroceso de 3 meses. Ejecute sus 3 a 5 principales flujos de trabajo de codificación a través de Polaris. Compare la calidad de los resultados con las referencias de GPT-4. Decida explícitamente si acepta Polaris como predeterminado o solicita acceso extendido a GPT-4. No deje que el cambio predeterminado de agosto ocurra sin una decisión registrada.

Paso 4: Actualice su registro de riesgo de proveedores. Añada el Windows Agent Store como entrada de riesgo en el canal de distribución. Tenga en cuenta que los agentes provenientes del WAS pueden ejecutarse en múltiples runtimes y que Microsoft controla el reparto de ingresos, los criterios de curación y las especificaciones de compatibilidad de runtime. Haga una referencia cruzada con sus estrategias de mitigación de la dependencia de proveedores de IA para documentar la exposición aceptable antes de aprobar agentes del WAS a escala.

Qué Hacer Esta Semana

El WAS aún no está en GA. Esa es su ventana. Esto es lo que importa antes de que lo esté:

  • Informe a su equipo de cuentas de Microsoft sobre sus preguntas de arquitectura de runtime. Obtenga respuestas específicas sobre los controles de tenant empresarial para el WAS antes de que los equipos de producto estén saturados con el tráfico del lanzamiento de GA.
  • Consulte la fecha de renovación de GitHub Copilot. Si está a 6 meses de la renovación, inicie la evaluación de Polaris ahora. El período de retroceso de 3 meses debe caber dentro de esa ventana.
  • Lea la licencia MIT del WAF. Las licencias de código abierto cambian el proceso de revisión de seguridad. Su equipo de AppSec necesita evaluar WAF antes de que cualquier equipo interno construya sobre él. MIT es permisiva, pero eso tiene dos caras.
  • Añada "tres runtimes" al orden del día de su próxima revisión de arquitectura. Incluso si su organización no está desplegando activamente agentes de Windows hoy, la decisión de arquitectura de runtime da forma a cada evaluación de proveedor futura que realizará. Anticípese mientras aún puede tomar la decisión de forma deliberada.
  • Verifique si su política de uso de IA cubre los marketplaces de distribución de agentes. La mayoría de las políticas redactadas antes de 2026 no lo hacen. El WAS es una nueva superficie de distribución con sus propias implicaciones de seguridad y compras.

Para el marco más amplio sobre cómo decisiones como esta encajan en una estrategia de despliegue de IA plurianual, el modelo de 5 etapas de madurez de IA es una referencia útil para situar la preparación actual de su organización y saber cuán agresivo ser con la adopción temprana del WAS.

Learn More