Skip to content
Volver al Magazine
automation-aiops 5 min read

Microsoft Foundry Local + Scout: cuando el trabajo agente se mueve al perimetro

¿Aplica esto a tu empresa?

Diagnóstico IA gratuito 30 min →

Key Takeaways

  • - contexto de Microsoft 365
  • - acciones en aplicaciones de trabajo
  • - recursos locales de escritorio
  • - modelos y runtimes que ya no dependen siempre de una llamada remota

Decision

Separar automatizacion fiable de demo fragil antes de darle autonomia.

Room

Revision de operaciones, arquitectura, seguridad o plataforma.

Risk

Aumentar velocidad sin observabilidad, rollback, ownership ni criterio de parada.

Agent prompt: identificar guardrails, puntos de control, fallos probables y criterios de autonomia

Problema

Durante demasiado tiempo, la promesa agentica enterprise se ha quedado partida en dos.

Por un lado, agentes potentes en cloud con acceso a modelos, workflows y gobierno. Por otro, trabajo real que sigue viviendo en navegador, escritorio, archivos locales y sistemas internos. El resultado es una operacion fracturada: el agente razona lejos del lugar donde realmente ocurre el trabajo.

En Build 2026, Microsoft junto dos piezas que normalmente se analizan por separado: Foundry Local para ejecutar modelos y capacidades de IA localmente en Windows, y Scout como agente personal persistente dentro de Microsoft 365. La señal no es que Microsoft “tambien tenga su propia IA”. La señal es que quiere unir cloud, desktop y perimetro local en una sola superficie operativa.

Tesis

Lo relevante de Microsoft esta semana no es un modelo nuevo. Es un cambio de arquitectura.

Microsoft esta intentando que el agente deje de ser una ventana de chat y pase a ser una capa que opera entre:

  • contexto de Microsoft 365
  • acciones en aplicaciones de trabajo
  • recursos locales de escritorio
  • modelos y runtimes que ya no dependen siempre de una llamada remota

Eso cambia la conversacion de “que modelo usas” a “donde corre el trabajo y bajo que control”.

Framework

Hay cuatro capas en la apuesta de Microsoft:

  • Scout: agente persistente conectado a Teams, Outlook, OneDrive y SharePoint.
  • Work IQ APIs: superficie para que los agentes interactuen con datos y apps de Microsoft 365.
  • Foundry Local + Windows AI APIs: ejecucion local y capacidades on-device en Windows.
  • Agent 365 / seguridad y gobierno: observabilidad, permisos y control de agentes incluso cuando no viven solo en cloud.

Mini-caso: un analista recibe correos, prepara una reunion, consulta archivos, revisa calendario y necesita cruzar decisiones con notas locales del proyecto. Si el agente vive solo en cloud, la friccion aumenta cada vez que sale de las apps centrales. Si vive en un perimetro mixto, puede moverse entre el conocimiento enterprise y el contexto local con menos ida y vuelta.

Senal medible: porcentaje de tareas agenticas que pueden resolverse sin sacar al usuario de su flujo de trabajo entre desktop, navegador y suite colaborativa.

Postura: el verdadero producto no es el copiloto. Es el perimetro donde ese copiloto puede trabajar de forma segura.

Por que importa ahora

El 2 de junio de 2026, Microsoft presento Scout como un agente siempre activo para trabajo y reforzo en paralelo el stack de IA local en Windows con Foundry Local, Windows AI APIs y mas capacidad on-device sobre CPU, GPU y NPU.

Visto junto, el movimiento apunta a una tesis ambiciosa: los agentes no van a vivir solo en SaaS ni solo en chat. Van a vivir en la interfaz de trabajo completa.

Eso importa operacionalmente por tres razones:

  • Reduce latencia de contexto: no todo requiere viaje a cloud.
  • Acerca el agente al trabajo real: navegador, archivos y apps locales vuelven a entrar en juego.
  • Sube el liston de governance: si el agente toca desktop y recursos locales, el control ya no puede quedarse en la app.

Anti-ejemplo

“Tenemos un agente en M365, asi que ya estamos cubiertos.”

No. Tener un agente dentro de una suite no resuelve por si solo:

  • que recursos locales puede usar
  • que modelo corre donde
  • que datos salen del dispositivo
  • como se registra la accion entre cloud y escritorio
  • quien apaga el flujo si algo se desvía

Sin ese diseño, solo cambias de interfaz. No cambias de operating model.

Protocolo (3 pasos)

  1. Mapea donde ocurre realmente el trabajo. Suite, navegador, desktop, archivos locales, sistemas internos.
  2. Decide que parte debe correr local. Privacidad, latencia, coste, continuidad offline o proximidad al usuario.
  3. Une ejecucion y gobierno. Logs, identidad, permisos y kill switch deben cruzar cloud y perimetro local.
CapaPreguntaRiesgo si falta
agentequien actua y para queautomatizacion sin owner
contextoque datos usarespuestas desconectadas
runtime localque corre en devicelatencia y dependencia excesiva
gobiernoquien observa y cortaautonomia sin control

Relacionado

Fuentes consultadas

Proximo paso

Si tu empresa quiere agentes persistentes, deja de pensar solo en la suite. Haz un mapa del perimetro de trabajo real: navegador, desktop, archivos, contexto local y gobierno compartido.

microsoft foundry-local scout local-ai
Cite this article

Berthelius, V. (2026). “Microsoft Foundry Local + Scout: cuando el trabajo agente se mueve al perimetro”. BRTHLS Magazine. https://www.brthls.com/magazine/microsoft-foundry-local-scout-trabajo-se-mueve-al-perimetro-es

Fractional CAIO · Diagnóstico gratuito

¿Tu empresa está lista para operar con IA?

30 minutos. Sin pitch. Un diagnóstico honesto de dónde estás y qué mover primero.

Reservar diagnóstico gratuito