Microsoft sitúa en public preview el agente que ayuda a detectar amenazas, abuso, spam, configuraciones incorrectas y riesgos en sitios Power Pages.
Microsoft también lleva a preview nuevas capacidades de analítica y server logging, control granular de proveedores de autenticación y transferencia self-service de propiedad de sitios.
¿Qué ocurre cuando el portal deja de ser un proyecto y pasa a ser una puerta permanente hacia tus datos?
Ese es el punto donde muchos proyectos cambian de naturaleza. Un portal de clientes, proveedores o partners puede empezar con unos cientos de usuarios y terminar convertido en un canal operativo crítico. Cuando eso ocurre, ya no basta con que el formulario funcione. Hay que saber quién accede, qué ve, qué modifica, qué proveedor de identidad utiliza, quién es dueño del sitio, qué eventos se registran, qué alertas existen, qué pasa ante una amenaza y cómo se recupera el servicio cuando algo falla.
Power Pages está madurando justo donde las empresas más desconfiaban: seguridad, identidad y operación.
Durante años, una de las preguntas más repetidas alrededor de cualquier plataforma low-code ha sido la misma: “¿Esto sirve para algo serio?”. En portales externos la duda es todavía mayor, porque el usuario no está dentro de la organización y el sistema puede mostrar datos de clientes, pedidos, facturas, incidencias, contratos, documentos o expedientes.
Microsoft lleva tiempo respondiendo a esa objeción con identidad, roles, permisos de tabla, Dataverse, Microsoft Entra, DLP y administración de entornos. En 2026 el movimiento es más explícito: añade agentes orientados a seguridad, controles de autenticación, ownership auditable y nuevas capacidades de logging. La plataforma está dejando claro que un portal enterprise necesita controles de operación comparables a cualquier otro servicio expuesto a Internet.
Esto cambia también cómo debería venderse Power Pages internamente. No como “una forma rápida de montar un portal”, sino como una capa externa sobre procesos Microsoft que puede gobernarse, auditarse y evolucionar. Esa diferencia es decisiva cuando CIO, CISO, Riesgos o Compliance entran en la conversación.
El diseño visible es solo la superficie. La seguridad vive en identidades, roles, relaciones y registros.
Detectar amenazas antes de enterarte por un usuario: Power Pages añade una capa de vigilancia asistida por IA.
Microsoft sitúa en septiembre de 2026 la public preview del Admin Security Agent para Power Pages. La idea es ayudar a administradores a identificar amenazas, abuso, spam, contenido problemático y configuraciones de riesgo, además de ofrecer recomendaciones y alertas accionables desde el entorno de administración.
Phishing, abuso y DDoS
El agente está planteado para identificar y ayudar a mitigar amenazas como phishing, ataques de denegación de servicio distribuido y otras señales de abuso. Para un portal externo, esto añade una capacidad de vigilancia que antes dependía más de controles dispersos.
Spam y contenido inapropiado
En portales con formularios, comunidades, aportación documental o contenido generado por usuarios externos, identificar patrones de abuso puede evitar que la plataforma termine convertida en una nueva superficie de soporte manual.
Lo importante: no sustituye a un diseño seguro
Un agente de seguridad no corrige una arquitectura que concede acceso excesivo, mezcla datos sensibles o publica formularios sin controles. Su valor aparece cuando se suma a una base bien diseñada: identidades correctas, roles mínimos, permisos de página y tabla, límites de registro, entornos gobernados, pruebas negativas y responsables claros.
Microsoft incorpora controles de gobierno a nivel de entorno para decidir qué proveedores de autenticación externa pueden utilizar los portales.
Cuando cada equipo puede publicar un portal, también necesitas decidir qué identidades externas están permitidas.
Microsoft lleva a public preview en septiembre de 2026 nuevos controles para administrar proveedores externos de autenticación. La capacidad permite gobernar qué proveedores pueden integrarse con Power Pages a nivel de entorno y establecer excepciones cuando sea necesario.
Esto es más importante de lo que parece. En una organización con varios portales, distintos equipos pueden tomar decisiones diferentes sobre Microsoft Entra External ID, proveedores OpenID Connect u otros mecanismos. Si cada proyecto resuelve identidad por su cuenta, la compañía termina manteniendo políticas distintas, experiencias de acceso inconsistentes y un inventario difícil de auditar.
El gobierno central no significa obligar a todos los portales a usar exactamente lo mismo. Significa definir qué opciones son aceptables, qué requisitos deben cumplir y quién puede autorizar excepciones. Es la diferencia entre escalar Power Pages como plataforma o acumular sitios independientes.
Que el usuario pueda iniciar sesión no significa que deba poder ver todos los datos asociados a su cuenta.
Uno de los errores más peligrosos en un portal es confundir autenticación con seguridad. Saber quién es el usuario solo resuelve la primera parte. Después hay que decidir qué páginas puede abrir, qué tablas puede consultar, qué registros concretos puede leer o modificar y qué acciones puede ejecutar.
Autenticación
Comprueba quién es el usuario y con qué proveedor se identifica. Aquí entran Microsoft Entra, OpenID Connect y otros proveedores externos autorizados por la organización.
Rol y permiso
Define si el usuario es cliente, proveedor, distribuidor, empleado externo o colaborador y qué operaciones puede realizar sobre páginas y datos.
Ámbito de registros
Determina si el usuario ve registros propios, de su cuenta, relacionados con una relación específica o un conjunto más amplio. Aquí es donde se evitan muchas fugas de información.
Prueba negativa
No basta con comprobar que un cliente puede ver su pedido. Hay que demostrar también que no puede ver el pedido de otro, aunque conozca una URL, cambie un identificador o intente acceder por una ruta no enlazada.
La regla que debería estar en cualquier checklist de Power Pages
Una página no es segura porque el menú no la muestra. Un registro no está protegido porque el formulario no tiene un botón. La seguridad debe existir en los permisos y comprobarse intentando acceder como un usuario que no debería tener acceso.
Si el portal es crítico, necesitas saber qué está pasando antes de que soporte reciba veinte correos.
Microsoft sitúa en septiembre de 2026 la public preview de nuevas capacidades para configurar analítica de sitio y server logging. Es un cambio especialmente relevante para organizaciones que quieren operar Power Pages como un servicio empresarial y no como una pieza aislada que solo se revisa cuando falla.
La analítica responde preguntas de adopción y experiencia: quién usa el portal, qué rutas funcionan, dónde se abandona, qué formularios convierten, qué dispositivos aparecen y cómo evoluciona la demanda. El logging responde preguntas operativas: qué errores se producen, cuándo, bajo qué contexto y qué patrón puede estar detrás de una incidencia.
Ambas visiones deben convivir. Un portal puede estar técnicamente disponible y, al mismo tiempo, fallar como canal porque los usuarios abandonan procesos. O puede tener buena adopción y sufrir errores intermitentes que degradan confianza. Medir solo visitas o solo uptime deja media historia fuera.
Uso, abandono, errores, latencia, incidencias y capacidad deben entrar en el cuadro de mando de operación.
El portal no puede quedarse “sin dueño” porque la persona que lo creó cambió de puesto.
Microsoft ha incorporado transferencia self-service de propiedad de sitios Power Pages. La función permite reasignar ownership a otro usuario válido del tenant y registra el cambio con historial auditable. También ayuda a identificar sitios sin propietario válido para que los administradores puedan corregir la situación.
Parece administración básica, pero resuelve un problema muy real del low-code: soluciones creadas por personas concretas que después cambian de función, abandonan la empresa o dejan de mantener el portal. Cuando no existe ownership formal, nadie sabe quién aprueba cambios, quién responde ante una incidencia, quién revisa permisos o quién decide si el sitio debe retirarse.
Propietario de negocio
Debe responder por el servicio, priorizar mejoras y validar que el portal sigue resolviendo una necesidad real. No tiene por qué administrar técnicamente la plataforma.
Propietario técnico
Necesita conocer identidad, permisos, entornos, despliegues, integraciones, dominios, certificados y dependencias para mantener el servicio.
Seguridad y cumplimiento
Revisa controles, datos expuestos, proveedores de identidad, auditoría, riesgos y criterios que deben aplicarse de manera homogénea.
Soporte y operación
Debe saber qué monitorizar, cómo escalar errores, qué SLA aplica, qué documentación existe y qué equipo responde cuando el portal afecta a un proceso de negocio.
Cuando participa en pedidos, incidencias, documentación, pagos o contratos, debe gobernarse como cualquier otro sistema crítico.
Power Pages es low-code para construir. No es low-control para operar.
La facilidad de creación puede generar una falsa sensación de simplicidad. Un equipo funcional puede montar páginas, formularios y vistas con mucha velocidad. Pero en cuanto el portal interactúa con Dataverse, Dynamics 365, Business Central, APIs o documentos, el impacto técnico y de seguridad crece.
Eso no es un argumento contra Power Pages. Es justamente uno de sus puntos fuertes: permite separar velocidad de desarrollo y disciplina de plataforma. Makers pueden crear experiencias con rapidez, mientras la organización establece políticas de identidad, entornos, permisos, ALM, conectores, ownership y operación.
La empresa que obtiene más valor no es la que publica más portales. Es la que consigue que cada nuevo portal reutilice mejor el modelo de identidad, los componentes, las integraciones y los controles del anterior. Ahí aparece el efecto plataforma.
Qué papel debería tener cada pieza cuando Power Pages se conecta con procesos reales.
El portal no debería concentrar toda la lógica. Power Pages funciona mejor cuando actúa como experiencia externa y delega datos, automatización, identidad y procesos en las capas adecuadas del ecosistema Microsoft.
Experiencia externa
Navegación, formularios, listas, contenido, autoservicio y experiencia responsive para usuarios externos.
Dato y seguridad
Registros, relaciones, contactos, permisos y lógica compartida con Dynamics 365 y el resto de Power Platform.
Identidad externa
Autenticación, políticas, proveedores de identidad y control de acceso dentro de un modelo empresarial.
Orquestación
Aprobaciones, avisos, integraciones, tareas y automatización posterior a la interacción externa.
Sistema transaccional
Ventas, servicio, pedidos, compras, finanzas, inventario o proyectos siguen gobernándose en las aplicaciones de negocio.
Agentes y autoservicio
Experiencias conversacionales conectadas a conocimiento y acciones cuando el caso justifica una capa de IA adicional.
Cuanto más valor genera el portal, más importante es saber exactamente quién ve qué.
No hace falta que el sitio gestione información “secreta” para necesitar seguridad seria. Basta con que muestre datos personalizados, permita cargar documentos, active procesos internos o tenga capacidad para modificar registros de negocio.
Portal de clientes
Contratos, facturas, incidencias, pedidos, documentación o casos de soporte. El usuario debe ver únicamente la información asociada a su cuenta y sus permisos.
Portal de proveedores
Altas, certificados, pedidos, entregas, facturas, estados y solicitudes. Compras necesita autoservicio sin exponer información de otros proveedores ni procesos internos.
Portal de distribuidores
Oportunidades, precios, materiales, incentivos y soporte. La segmentación por partner, territorio y rol debe mantenerse incluso cuando existe un CRM común detrás.
Portal de proyectos u obra
Documentación, certificaciones, hitos, incidencias y subcontratas. Cada participante necesita acceso al proyecto adecuado y a los documentos correctos, no a toda la cartera.
Siete formas de convertir un portal low-code en una nueva fuente de riesgo operativo.
Empezar por la pantalla
Si se dibuja primero la experiencia y después se pregunta qué datos y permisos necesita, el portal nace con decisiones visuales por delante de decisiones de seguridad.
Dar permisos amplios para acelerar
“Ya restringiremos después” es una de las peores decisiones posibles cuando el sitio queda expuesto a Internet y trabaja con Dataverse.
No probar usuarios negativos
Las pruebas deben intentar romper el aislamiento: cambiar URLs, manipular identificadores, acceder con roles incorrectos y validar que el sistema deniega correctamente.
Dejar el ownership en una persona
Si el portal depende del maker original, cada cambio organizativo se convierte en un riesgo. Propiedad, soporte y evolución deben ser responsabilidades formales.
Medir visitas, pero no procesos
Un portal puede recibir tráfico y seguir sin resolver nada. Hay que medir solicitudes completadas, abandono, incidencias, tiempo de respuesta y reducción de carga interna.
No definir qué proveedor de identidad usar
Si cada portal elige autenticación por conveniencia local, la organización termina con políticas inconsistentes y más superficie de soporte.
Pensar que low-code elimina ALM y operación
Desarrollo, pruebas, producción, soluciones, cambios, dominios, certificados, integraciones, variables de entorno y rollback siguen existiendo. La plataforma simplifica muchas tareas, pero no convierte un servicio empresarial en un documento compartido.
Antes de aprobar otro portal, pregunta si estás creando un activo reutilizable o una excepción más.
El primer portal siempre es un proyecto. El tercero ya debería empezar a parecerse a una plataforma. Si cada sitio vuelve a decidir identidad, diseño, permisos, conectores, datos, componentes, logging y soporte desde cero, la organización no está escalando Power Pages: está multiplicando soluciones independientes.
Un modelo más maduro define patrones comunes: proveedores de identidad autorizados, naming, entornos, componentes reutilizables, criterios de datos anónimos, permisos, pipelines, documentación, ownership, telemetría, revisión de seguridad y proceso de retirada. Eso reduce tiempo de entrega sin sacrificar control.
Las novedades de 2026 van precisamente en esa dirección. Microsoft está añadiendo más capacidades para que administradores tengan visibilidad y puedan imponer reglas de plataforma. La oportunidad es aprovecharlas para que el negocio cree experiencias externas más rápido sin obligar a TI a perseguir portales después de publicados.
Además, este enfoque facilita algo que suele olvidarse: retirar bien lo que deja de tener sentido. Un portal enterprise necesita criterios de baja, archivado de datos, revocación de accesos, cierre de dominios, limpieza de integraciones y traspaso de conocimiento. Gobernar también significa saber cuándo una solución debe dejar de existir sin dejar usuarios, credenciales o dependencias huérfanas.
¿Quién es el colectivo externo?
Cliente, proveedor, partner, empleado externo, ciudadano o comunidad.
¿Qué datos necesita ver realmente?
Reducir superficie es una decisión de seguridad y también de experiencia.
¿Quién responde por el sitio?
Negocio, TI, seguridad y soporte deben tener responsables identificados.
¿Cómo sabremos que funciona?
Adopción, tareas completadas, reducción de contactos, errores, seguridad y satisfacción.
Quince comprobaciones mínimas para no estrenar el portal con una incidencia evitable.
Proveedor aprobado y experiencia de alta, acceso y recuperación probada.
Cada colectivo externo tiene solo los permisos que necesita.
Lectura, creación, actualización y borrado expresamente definidos.
Usuario, cuenta, relación y acceso global donde proceda.
Intentos de acceder a datos y rutas que deberían estar bloqueados.
Solo aquello que de verdad puede exponerse públicamente.
Responsable funcional y técnico identificados.
Errores e incidencias con suficiente contexto para diagnosticar.
Uso, conversión de proceso, abandono, tiempos y carga interna evitada.
Usuarios anónimos y autenticados con volumen realista.
Dataverse, Dynamics 365, ERP, APIs y servicios externos.
No solo el caso feliz: reintentos, rechazos y escalado.
Desarrollo, prueba, aprobación, publicación y rollback.
Canal, responsables, prioridades y conocimiento disponible.
Configuración, permisos, autenticación, exposición de datos, formularios, archivos, integraciones y amenazas revisadas como una única superficie.
Power Pages prepara una simplificación importante: acercar los roles web a los roles de seguridad de Dataverse.
Microsoft tiene prevista para noviembre de 2026 la disponibilidad general de una capacidad que unifica parte del modelo de autorización de Power Pages con los roles de seguridad de Dataverse. El objetivo es reducir la duplicidad entre usuarios del sitio, roles web, usuarios del sistema y roles de Dataverse, simplificando una zona que históricamente ha requerido bastante atención.
Para una empresa con uno o dos portales, la diferencia puede parecer menor. Para una organización con varios sitios, equipos, colectivos externos y procesos compartidos, tener modelos de autorización más alineados puede reducir errores de configuración y esfuerzo administrativo. Menos capas duplicadas significan menos puntos donde un cambio de rol puede quedar aplicado en un sitio pero no en otro.
Eso no elimina la necesidad de diseñar acceso con precisión. Un modelo más simple sigue necesitando decidir qué datos puede consultar un usuario, qué operaciones realiza y con qué alcance. La ventaja está en disminuir complejidad operativa para que el gobierno pueda centrarse más en reglas de negocio y menos en mantener dos mundos de permisos paralelos.
Si una empresa está diseñando hoy un portal que entrará en producción a finales de 2026 o comienzos de 2027, conviene revisar esta evolución antes de consolidar una arquitectura muy personalizada. No para esperar indefinidamente a cada novedad, sino para evitar decisiones que queden obsoletas pocos meses después.
La convergencia entre Power Pages y Dataverse apunta a un modelo de autorización más coherente para organizaciones que escalan portales.
Power BI embed token v2 ya está disponible: más opciones para llevar analítica segura a usuarios externos.
Microsoft marcó como disponible en julio de 2026 el soporte de Power BI embed token v2 para Power Pages. El cambio es relevante porque muchos portales dejan de aportar valor cuando el usuario puede introducir información, pero no puede entender qué está ocurriendo con su relación con la empresa. Analítica y autoservicio funcionan mucho mejor juntas.
Cliente: visibilidad sin pedir un informe
Consumo, incidencias, entregas, proyectos, facturación o nivel de servicio pueden convertirse en indicadores disponibles bajo demanda. El usuario obtiene contexto sin solicitar cada dato al equipo interno.
Proveedor: rendimiento y cumplimiento
Entregas, calidad, incidencias, documentación, tiempos o volumen pueden presentarse de forma controlada para que proveedor y compras trabajen sobre una misma lectura del rendimiento.
Distribuidor: actividad comercial
Oportunidades, objetivos, campañas, pedidos o incentivos pueden consultarse sin abrir el CRM interno completo. El portal se convierte en una experiencia de negocio, no en una colección de documentos.
Dirección de proyecto: seguimiento compartido
Hitos, desviaciones, documentación, incidencias y avance pueden mostrarse a clientes o colaboradores con el nivel de detalle apropiado para cada rol.
La analítica también necesita seguridad por diseño
Insertar Power BI en un portal no significa publicar un dashboard genérico para todos. El modelo debe respetar identidad, tenant, cuenta, rol y contexto de negocio para que cada usuario vea únicamente la información autorizada. La experiencia puede parecer sencilla; el gobierno del dato sigue siendo enterprise.
Un portal seguro necesita más que alguien que sepa construir páginas.
Ayesa Digital combina capacidades en Power Platform, Dynamics 365, Business Central, Azure, Microsoft 365, seguridad, integración y datos. Esa cobertura permite tratar Power Pages como parte de una plataforma empresarial y no como un proyecto web aislado.
El trabajo empieza por el servicio que necesita el usuario externo y continúa con datos, identidad, permisos, automatización, integración, licenciamiento, operación y evolución. Cuando hace falta IA, Copilot Studio puede incorporarse sobre una base de acceso ya gobernada en lugar de añadir otra capa de incertidumbre.
El resultado buscado es sencillo de explicar: que el cliente, proveedor o partner pueda resolver más cosas por sí mismo sin que la organización pierda control sobre datos, procesos y seguridad.
Diseño del servicio
Usuarios, journeys, datos, estados, documentos, acciones y resultado esperado.
Arquitectura Microsoft
Power Pages, Dataverse, Dynamics 365, Business Central, Azure, Microsoft 365 e integración.
Seguridad y gobierno
Identidad, permisos, entornos, ownership, DLP, auditoría, logging y ciclo de vida.
Operación y mejora
Adopción, soporte, métricas, incidencias, rendimiento, capacidad y evolución continua.
Lo que conviene tener claro antes de publicar un portal Power Pages en 2026.
¿Power Pages es seguro para clientes y proveedores?
Puede serlo si identidad, permisos de página, permisos de tabla, ámbito de registros y operación están correctamente diseñados y probados. La plataforma aporta controles; la configuración determina el resultado.
¿Qué aporta el Security Agent?
Microsoft incorpora asistentes de seguridad para ayudar a revisar configuración, autenticación, autorización y, en la preview de administración, detectar amenazas, abuso, spam y riesgos.
¿Está ya disponible el Admin Security Agent?
Microsoft lo sitúa en public preview desde septiembre de 2026. Al ser una capacidad preliminar, conviene evaluar su alcance y no tratarla todavía como sustituto de controles consolidados.
¿Qué cambia con los proveedores de autenticación?
La nueva capacidad de gobierno permite controlar a nivel de entorno qué proveedores externos están permitidos y establecer excepciones por sitio cuando sea necesario.
¿Por qué importa el ownership?
Porque un portal sin dueño termina sin decisiones claras sobre cambios, seguridad, soporte y retirada. Microsoft ya permite transferir propiedad con trazabilidad y detectar sitios que han quedado sin propietario válido.
¿Qué debería medirse además de visitas?
Procesos completados, abandono, errores, tiempo de respuesta, incidencias, carga interna evitada, satisfacción, disponibilidad y eventos relevantes de seguridad.
¿Power Pages sustituye al ERP o CRM?
No. Expone de forma controlada procesos y datos a usuarios externos. Business Central, Dynamics 365 o Dataverse siguen siendo los sistemas donde se gobierna el proceso interno.
¿Puede conectarse con Business Central?
Sí, mediante una arquitectura de integración adecuada. El proveedor puede consultar o aportar información sin entrar directamente en el ERP. Ayesa365 ya dispone de una guía específica para este escenario.
¿Puede incorporar agentes de IA?
Sí. Copilot Studio puede añadir experiencias conversacionales y acciones, pero las fuentes, permisos, herramientas y límites deben alinearse con el mismo modelo de gobierno del portal.
¿Cuál es el primer paso antes de construir?
Definir colectivo, servicio, datos, identidad, permisos, volumen y sistema de back office. Después se valida el encaje técnico, económico y operativo de Power Pages.
Microsoft Power Pages
Página principal para entender casos de uso, arquitectura, licenciamiento, integración y criterios de decisión.
Portal de proveedores + Business Central
Caso concreto para reducir correos, consultas y duplicación de datos con autoservicio conectado al ERP.
Gobierno Power Platform
Entornos, conectores, permisos, propietarios, ciclo de vida y control cuando Power Platform crece alrededor del ERP.
Microsoft Learn · Power Pages 2026
Plan oficial de Microsoft con las capacidades nuevas y previstas para Power Pages durante la release wave 1 de 2026.
¿Quieres abrir procesos a clientes o proveedores sin abrir más datos de los necesarios?
Podemos ayudarte a revisar el caso de uso, identidad, permisos, Dataverse, integración con Dynamics 365 o Business Central, licenciamiento, seguridad, operación y modelo de gobierno antes de construir el portal completo.
Business Development Manager | PSELLER Microsoft en Ayesa | Miembro Unidad Transición Energética, Climática y Urbana en Tecnalia | Secretaria de la Junta Directiva del Cluster de la Construcción (Build INN)