El error #1 que veo en empresas que empiezan con Power Platform (y cómo evitarlo)
Llevo años como consultor de Microsoft Power Platform y últimamente ayudo a equipos a meterse en Copilot Studio para construir sus primeros agentes. El patrón se repite siempre:
Una empresa mete a un empleado motivado a construir una Power App o un flujo de Power Automate sin pensar en Dataverse, en el modelo de datos, ni en gobernanza. Funciona genial... durante 3 meses. Luego llega el segundo flujo, el tercer conector personalizado, y el sistema se convierte en spaghetti de conectores premium sin control de entornos (dev/test/prod).
Mismo patrón ahora con Copilot Studio: la gente prototipa un agente en 20 minutos (porque es sorprendentemente fácil), lo conecta a datos sensibles de la empresa sin pasar por Data Loss Prevention (DLP) policies, y cuando quieren llevarlo a producción se dan cuenta de que no hay control de qué puede y no puede hacer el agente.
Lo que recomiendo siempre antes de escalar:
Define entornos separados (dev/test/prod) en el Power Platform Admin Center desde el día 1, no cuando ya duele.
Aplica políticas DLP antes de conectar cualquier agente de Copilot Studio a SharePoint, Dataverse o APIs externas.
Modela los datos en Dataverse, no en listas de SharePoint improvisadas — te ahorra meses de migración después.
Documenta quién es el 'maker' responsable de cada solución — el mayor riesgo de shadow IT no es la herramienta, es la falta de dueño.
Si tu equipo está en esa fase de "ya tenemos 15 flujos y nadie sabe cuáles siguen activos", ese es exactamente el momento de meter orden antes de escalar más. Feliz de compartir más sobre esto si a alguien le sirve.
