Power Apps con agentes: construir ya no es el cuello de botella

Microsoft liberó la autoría de apps canvas con agentes de IA. La velocidad dejó de ser el problema; ahora el reto es decidir quién delega qué, con qué datos y bajo qué reglas.

Un analista de operaciones pide una app para registrar inspecciones de campo. En el backlog de su área hay otras 14 solicitudes parecidas. La respuesta habitual: “entra en el próximo trimestre”.

Ese “próximo trimestre” acaba de perder su justificación técnica.

Desde septiembre de 2026, un agente de IA puede crear pantallas, conectar datos y escribir fórmulas Power Fx dentro de una app canvas real, mientras una persona revisa el resultado en Power Apps Studio. No es un prototipo desechable ni un generador de maquetas. Es la misma app que su equipo ya sabe gobernar, probar y desplegar.

Este artículo explica la imagen que Microsoft usa para presentar esta capacidad, qué cambió en concreto y, sobre todo, qué debe decidir TI antes de que cada área empiece a pedirle apps a un agente.

Cifra	Qué significa
1 de septiembre de 2026	Microsoft anunció la disponibilidad general de la coautoría de apps canvas con agentes; ya es apto para cargas productivas
Más de 1.400 conectores	El agente trabaja sobre el mismo ecosistema de conectores y controles de gobierno de siempre
.NET 10 SDK	Requisito local para ejecutar el servidor MCP; implica gestionar estaciones de trabajo de los makers
15 de noviembre de 2026	Retiro del Release Planner; las novedades pasan a publicarse de forma continua

La imagen, pieza por pieza

El diagrama resume una arquitectura en tres tiempos: contexto, orquestación y resultado.

A la izquierda: lo que el agente necesita saber

Cinco fuentes alimentan al agente:

• Dataverse: datos y lógica de negocio. El modelo de datos que ya existe.
• Azure: servicios y APIs para lo que el low-code no resuelve solo.
• Conectores: sistemas externos, del ERP al CRM.
• Código: componentes y lógica personalizada.
• Su contexto: requisitos, documentos y patrones de la organización.

Este último bloque es el más subestimado. Un agente sin contexto genera apps genéricas. Uno con sus estándares de diseño y sus reglas de negocio genera apps que se parecen a las suyas.

Al centro: el agente y el protocolo

El Power Apps Canvas Authoring Agent recibe herramientas y datos. Arriba, Copilot y los agentes de IA cumplen un ciclo: entender, planificar, actuar. Abajo aparece MCP, descrito como una forma estándar para que los agentes interactúen con herramientas y servicios.

A la derecha: la app, lista

La flecha “Build & update” termina en una app funcional. La promesa del pie: construir, extender, mantener. Más rápido.

La franja inferior asigna un rol a cada producto: Power Apps construye, Dataverse unifica, Azure escala y Copilot acelera.

La imagen no muestra una herramienta nueva. Muestra una nueva puerta de entrada a una plataforma que usted ya administra.

Qué pasó realmente: de preview a producción

La capacidad no nació este mes. El servidor MCP que la sostiene se publicó en NuGet en versiones preview desde abril de 2026, con actualizaciones casi mensuales hasta la versión 1.1.5 del 31 de agosto.

Lo relevante es el salto a disponibilidad general. Según Microsoft, ahora se puede integrar la colaboración con agentes en las prácticas de desarrollo productivo, sobre las apps canvas existentes y sin empezar de cero.

Para un gerente de TI, “GA” cambia la conversación. Ya no se trata de un experimento de un maker curioso. Es una capacidad soportada que llegará a su tenant, la haya planificado o no.

Un detalle adicional: Microsoft dejó de publicar planes de lanzamiento semestrales y pasó a un roadmap continuo. Esperar “la próxima ola” para evaluar novedades ya no funciona como estrategia.

MCP: el enchufe que lo hace posible

El Model Context Protocol (MCP) es un estándar abierto que permite a un agente de IA descubrir y usar herramientas externas de forma estructurada. Piénselo como un contrato: la herramienta declara qué puede hacer y el agente lo invoca sin integraciones a medida.

En Power Apps, el servidor MCP le da al agente un conjunto concreto de capacidades. De acuerdo con Microsoft, los agentes pueden crear y modificar apps y pantallas, inspeccionar controles, conectores y fuentes de datos, entender esquemas, configurar controles, escribir fórmulas Power Fx y validar los cambios sincronizándolos con una sesión de coautoría en vivo.

La consecuencia estratégica es que usted elige el agente. La documentación oficial menciona GitHub Copilot, Claude Code u otra herramienta que soporte servidores MCP y plugins de agentes. No hay un único proveedor de IA atado a la plataforma.

Coautoría, no piloto automático

El flujo es menos mágico y más útil de lo que sugiere el marketing:

1. Preparar la app. La app debe existir en Power Apps, guardada en el entorno correcto y con coautoría habilitada, aunque esté vacía.
2. Conectar el agente. El maker vincula su herramienta local a la sesión abierta en Studio.
3. Describir la necesidad. En lenguaje natural: “una pantalla de solicitudes con filtro por estado”.
4. Generar y validar. El agente genera archivos .pa.yaml con pantallas, controles y fórmulas, los valida con el servidor MCP y corrige errores.
5. Revisar y ajustar. Los cambios aparecen en Studio, donde una persona prueba y refina.

El punto clave está en el paso 4. El código fuente de la app queda en archivos legibles, así que cada aporte del agente es visible y revisable. Eso permite algo que el low-code tradicional hacía mal: control de versiones y revisión de cambios como en cualquier proyecto de software.

Una app que se puede revisar línea por línea es una app que se puede auditar.

Lo que el agente acelera (y lo que no)

Donde rinde:

• Pantallas repetitivas que siguen un mismo patrón.
• Refactorizaciones amplias sobre apps existentes.
• Primeras versiones funcionales a partir de un requerimiento claro.
• Mantenimiento: agregar filtros, campos o vistas sin rehacer la app.

Donde no reemplaza a nadie:

• Definir el modelo de datos correcto en Dataverse.
• Decidir qué conectores son aceptables según su política de datos.
• Validar accesibilidad, seguridad y cumplimiento.
• Entender el proceso de negocio que la app debe soportar.

Microsoft lo dice sin rodeos: la herramienta intenta generar código listo para producción, pero la responsabilidad de validarlo sigue siendo de su organización.

El costo que nadie pone en la propuesta

Cada instrucción al agente consume tokens. Microsoft lo reconoce abiertamente y recomienda usar el agente donde más valor aporta, como generar pantallas relacionadas, y hacer cambios pequeños a mano.

Esto tiene implicaciones financieras concretas:

• Licenciamiento del agente: cada maker necesita acceso a una herramienta de IA compatible, con su propio costo de licencia.
• Consumo variable: una refactorización amplia puede costar más que el trabajo manual si el requerimiento está mal definido.
• Estaciones de trabajo: el requisito de .NET 10 SDK obliga a gestionar software en los equipos de los makers.

Si va a presentar esto al directorio, no venda “apps gratis y rápidas”. Venda menor tiempo de entrega con un costo variable que se puede medir y acotar.

Cómo empezar sin romper nada

1. Elija un caso acotado. Una app interna, con datos no sensibles y un dueño de negocio comprometido.
2. Use un entorno de desarrollo. La guía oficial recomienda validar los cambios generados en una app no productiva antes de aplicarlos en producción.
3. Aplique mínimo privilegio. La cuenta que conecta el agente solo debe poder editar la app objetivo.
4. Revise sus políticas de DLP. El agente respeta las restricciones de conectores existentes; asegúrese de que estén bien definidas.
5. Defina qué se revisa. Establezca quién aprueba los .pa.yaml generados antes de publicar.
6. Mida. Compare horas de desarrollo y consumo de IA contra una app similar construida manualmente.

Objeciones de un gerente escéptico

“Esto va a multiplicar las apps sin control.” El riesgo existe, pero no es nuevo: el shadow IT low-code ya ocurre. La diferencia es que ahora las apps generadas quedan en archivos revisables y bajo las mismas políticas de entorno y conectores. El problema no es el agente; es no tener gobierno previo.

“¿Y la seguridad de conectar un agente externo a mi tenant?” Es una preocupación válida. Microsoft señala que las credenciales se manejan con el SDK de identidad de Azure, sin almacenar tokens, y advierte sobre ataques de inyección de prompts indirecta. Además, los administradores pueden bloquear plugins de agentes, servidores MCP de terceros o procesos MCP locales. Usted conserva el control; debe decidir activamente cómo usarlo.

“Mis makers no son desarrolladores. ¿Van a usar una terminal?” Algunos sí, otros no. Existe instalación desde Visual Studio Code, lo que reduce la fricción, pero el perfil ideal hoy es un maker avanzado o un desarrollador de fusión. No lo despliegue masivamente el primer mes.

El nuevo trabajo de TI

Durante años, el argumento contra el backlog fue la capacidad: pocos desarrolladores, demasiadas solicitudes. Ese argumento se debilita cada vez que un agente genera en minutos una pantalla que antes tomaba días.

Lo que no se debilita es la necesidad de criterio. Qué datos exponer. Qué procesos merecen una app. Qué calidad es aceptable. Quién responde cuando algo falla a las 3 a. m.

Cuando construir se vuelve barato, gobernar se vuelve la ventaja competitiva.

Las áreas de TI que definan hoy sus reglas de juego serán las que capturen esa velocidad. Las que esperen encontrarán agentes trabajando en su tenant bajo reglas que nadie escribió.

El agente ya está listo. La pregunta es si su gobierno también.

Fuentes

• Microsoft Power Platform Blog — Turbocharge your canvas development with the canvas authoring agent plugin – now generally available! (1 de septiembre de 2026)
• Microsoft Learn — Create and edit canvas apps with AI code generation tools
• NuGet — Microsoft.PowerApps.CanvasAuthoring.McpServer
• Microsoft Learn — Power Platform 2026 release wave 1 plan overview
• HubSite 365 — Power Platform: No More Release Waves
• GitHub — microsoft/power-platform-skills