El problema que llegó antes que el plan
Cuando arrancamos el proyecto, el CIO ya sabía que tenía un problema de shadow AI. Lo que no sabía es que era más grande de lo que pensaba. El assessment inicial identificó 47 herramientas de IA no corporativas en uso activo: ChatGPT, GitHub Copilot personal, Perplexity, extensiones de Chrome sin control, Grammarly con datos de clientes procesados en servidores externos. En una corporación de servicios financieros con 8.000 empleados en seis países europeos.
El equipo de seguridad lo sabía desde hacía meses pero no tenía argumento para bloquearlo: "si lo bloqueas sin dar alternativa, lo usan igualmente desde el móvil personal conectado al hotspot". La dirección quería capitalizar la IA generativa de forma segura. El problema no era la tecnología. Era el orden: todos querían empezar por el despliegue, y nadie quería empezar por el gobierno de datos.
Spoiler: si empiezas por el despliegue sin el gobierno de datos, Copilot se convierte en el mejor buscador de información que no debería estar accesible. Y eso es exactamente lo que ocurre en el 70% de los proyectos que fracasan.
Por qué el gobierno de datos va primero (siempre)
Copilot for Microsoft 365 respeta los permisos de SharePoint y Teams. Esto suena bien hasta que descubres que el 60% de los documentos confidenciales de tu organización no tienen los permisos correctos asignados. No porque nadie lo haya querido hacer mal. Porque en los últimos diez años, nadie ha tenido un motivo urgente para auditarlo.
Copilot no crea accesos que no existen. Pero sí convierte en trivial explotar los que ya existen. Un analista junior con acceso heredado a carpetas de M&A puede, sin intención maliciosa, preguntarle a Copilot "¿qué operaciones corporativas estamos evaluando?" y obtener un resumen de documentos que técnicamente tiene permiso de ver pero que nunca habría encontrado manualmente.
El trabajo de gobierno de datos previo al despliegue tiene tres dimensiones que no se pueden comprimir:
1. Clasificación de información con Microsoft Purview
Establecer cuatro niveles: Público, Interno, Confidencial y Altamente Confidencial. Lo importante no es la taxonomía —cada organización tiene la suya— sino la automatización. Las etiquetas que requieren que el empleado las aplique manualmente tienen una tasa de cumplimiento del 23% a los seis meses. Las etiquetas aplicadas automáticamente por Purview mediante trainable classifiers y sensitive information types alcanzan el 94% en el mismo plazo.
En este proyecto tardamos seis semanas en clasificar el corpus documental principal: 2,3 millones de documentos en SharePoint Online y OneDrive. El dato más relevante no fue el tiempo de clasificación sino lo que encontramos: el 31% de los documentos marcados como Confidencial por el sistema tenían permisos de acceso incorrectos. Se corrigieron antes de activar Copilot.
2. Políticas de DLP integradas con Copilot
Microsoft Purview permite definir políticas de DLP (Data Loss Prevention) que se aplican también al contexto de Copilot: qué puede resumir, qué puede incluir en respuestas a otros usuarios, qué puede referenciar en un draft generado. Para datos de categorías especiales bajo GDPR (salud, afiliación sindical, datos biométricos), la política fue prohibitiva: Copilot no genera contenido basado en esos datos, aunque el usuario tenga permiso técnico de acceso.
3. Acceso mínimo necesario antes de activar
Revisión de todos los grupos de Teams y sitios de SharePoint con más de 500 miembros para identificar "oversharing estructural": grupos que se crearon para un proyecto y que siguieron con membresía masiva indefinida. En esta organización encontramos 34 sitios con más de 2.000 miembros activos que contenían documentación de proyectos ya cerrados. Se archivaron o corrigieron permisos antes del día 1 de Copilot.
El assessment de madurez: 12 dimensiones
Antes de diseñar el plan de adopción usamos un framework de madurez propio con 12 dimensiones: datos, procesos, cultura, talento, arquitectura técnica, gobierno, liderazgo ejecutivo, gestión del cambio, métricas, privacidad, cumplimiento regulatorio y seguridad. El objetivo no es sacar nota en todas. Es identificar las que bloquean el despliegue y las que se pueden mejorar durante el programa.
Los resultados en este caso: arquitectura técnica (M365 E5 completamente desplegado) y liderazgo ejecutivo (sponsor del CEO con presupuesto asignado) eran fortalezas reales. Gobierno de datos y gestión del cambio eran los puntos débiles críticos. El plan se construyó en torno a estas dos dimensiones, no a las tecnológicas.
El modelo de despliegue por oleadas
El despliegue secuencial en tres oleadas no es una preferencia estética. Es la única forma de iterar el marco de gobierno antes de que escale a toda la organización:
Oleada 1 (semanas 1-6): Early Adopters — 100 usuarios. Seleccionados deliberadamente heterogéneos: no solo los entusiastas de la tecnología sino también perfiles críticos del negocio (legal, finanzas, RRHH, operaciones). El objetivo es identificar fricciones reales, no validar el caso de uso ideal. Los early adopters documentaron todos los casos en los que Copilot dio resultados incorrectos, confusos o potencialmente problemáticos. Esa documentación fue el input para ajustar las políticas de Purview antes de la oleada 2.
Oleada 2 (semanas 7-14): Departamentos piloto — 1.200 usuarios. Tres departamentos completos: ventas, atención al cliente y análisis financiero. Formación diferenciada por perfil. Para ventas: cómo usar Copilot en Teams para preparar reuniones y generar propuestas. Para análisis financiero: cómo evitar errores numéricos (los LLMs no calculan, resumen; los cálculos los hace Excel, no Copilot). Para atención al cliente: cómo usar Copilot en Outlook sin incluir datos de clientes en los prompts.
Oleada 3 (semanas 15-24): Organización completa — 8.000 usuarios en 6 países. Con las lecciones de las dos oleadas anteriores, el despliegue global fue técnicamente el más sencillo. La complejidad fue lingüística y cultural: la biblioteca de prompts se localizó a cinco idiomas, y los casos de uso verificados se adaptaron a las especificidades de cada mercado nacional.
El programa "Copilot Champions"
La formación estándar de Microsoft —buena como base— no resuelve el problema de adopción real. El problema de adopción es que los empleados no saben qué preguntarle al asistente. No es un problema de habilidad técnica. Es un problema de imaginación del caso de uso aplicado a su trabajo concreto.
El programa de Champions designó un referente por departamento con una agenda concreta: cuatro horas de formación avanzada, acceso a la beta de nuevas funcionalidades antes que el resto, responsabilidad de documentar los tres mejores casos de uso de su área y presentarlos al equipo mensualmente. La comunidad de práctica en Teams con más de 400 prompts verificados y organizados por rol y función fue el activo más valorado por los usuarios al final del programa.
El dato que más sorprendió al Comité de Dirección: los departamentos con el mayor incremento de productividad no fueron los que tenían usuarios más "techies". Fueron los departamentos donde el Champion era alguien respetado por su conocimiento del negocio, no por su conocimiento tecnológico.
Cómo medir el ROI antes de que el Comité te lo pida
El ROI de Copilot no se mide con una encuesta de satisfacción. Se mide con un modelo de impacto económico riguroso que sobrevive una auditoría interna. Estos son los tres componentes del modelo que presentamos al Consejo de Administración en el mes 4:
Tiempo ahorrado por tarea: medición directa mediante muestreo. Antes del despliegue, cronometramos tareas representativas por rol: redactar el resumen de una reunión de 90 minutos (17 minutos de media), preparar el primer borrador de una propuesta comercial (2,3 horas), buscar y consolidar precedentes contractuales para un negocio nuevo (4,1 horas). Cuatro semanas después del despliegue, la misma muestra. Reducción media del 62% en las tareas medidas.
Valor del tiempo liberado: no todo el tiempo ahorrado se convierte en valor económico directo. El modelo aplica un factor de conversión por rol: para ventas, el tiempo liberado de tareas administrativas se asigna a actividades de generación de pipeline (el 40% del tiempo liberado tiene valor directo medible). Para analistas, el tiempo liberado se redirige a análisis de mayor complejidad que antes no se hacían por falta de tiempo. El valor del tiempo del empleado se calcula con el coste salarial cargado, sin exageraciones.
Evitación de costes de shadow AI: el coste de un incidente de fuga de datos en una organización financiera en Europa incluye sanciones GDPR (hasta 4% de la facturación global), coste reputacional y coste de investigación forense. No se puede incluir como ROI positivo pero sí como riesgo evitado cuantificado. En este caso, con el volumen de datos sensibles procesados en herramientas externas antes del despliegue, el equipo de seguridad estimó una exposición de riesgo anual de 800.000€-2,1M€. Eliminar ese riesgo tiene valor financiero aunque no aparezca en la cuenta de resultados.
El resultado que se presentó: ROI positivo en el mes 4. Ahorro de 2,1 horas semanales por usuario en tareas de alto volumen y bajo valor. Proyección a 12 meses de 4,7M€ en valor generado para el negocio considerando todos los componentes del modelo.
Lo que nadie te cuenta: las 4 razones por las que los proyectos Copilot fracasan
1. Activar Copilot sin resolver el gobierno de datos primero. Ya lo hemos explicado. Es el error más común y el más costoso. No porque Copilot sea inseguro —lo es por diseño— sino porque expone el desorden de permisos que lleva años acumulándose. Si detectas este riesgo tarde, el proyecto se para para hacer el trabajo de gobierno que debería haberse hecho antes. Mejor hacerlo en el orden correcto.
2. Medir el éxito por licencias activadas, no por uso real. El 90% de licencias activadas y el 20% de uso activo semanal es el patrón más común en organizaciones que no han invertido en adopción. La licencia activa no genera ROI. El uso activo en casos de uso de alto valor sí. La diferencia está en el programa de Champions y en la biblioteca de casos de uso por rol, no en la tecnología.
3. Tratarlo como un proyecto IT, no como un programa de cambio cultural. Copilot cambia la forma en que los empleados trabajan. Los programas de cambio requieren patrocinio ejecutivo visible, comunicación continua, gestión del miedo ("¿me va a sustituir?") y tiempo. Los proyectos que funcionan tienen un sponsor del Comité de Dirección que usa Copilot personalmente y lo cuenta públicamente. Los que fracasan tienen un sponsor que firma el presupuesto y delega la ejecución al equipo IT sin aparición posterior.
4. No documentar los límites del sistema. Copilot comete errores. Los LLMs alucina. En organizaciones reguladas, un error de Copilot que llega a un cliente o a un auditor puede ser más costoso que el ROI generado. Las organizaciones que gestionan bien este riesgo documentan explícitamente qué tareas NO se deben delegar a Copilot (redacción de comunicaciones regulatorias definitivas, cálculos financieros sin revisión humana, síntesis de datos legales vinculantes) y forman a los empleados en esos límites con la misma energía que en los casos de uso positivos.
Los números finales
Mes 6 del programa: 8.000 usuarios activos en 6 países. NPS de adopción: 72 (benchmark del sector servicios: 34). Uso de shadow AI detectado: cero herramientas no corporativas en uso activo según los logs de Defender for Cloud Apps. Tiempo de análisis de reuniones reducido un 71%. Tiempo de redacción de propuestas comerciales reducido un 58%. Satisfacción del equipo de análisis financiero, que declaró haber podido abordar proyectos de mayor complejidad que antes se rechazaban por falta de capacidad.
Lo que más recuerdo de la presentación al Consejo es la pregunta del CFO: "¿Por qué no lo hicimos antes?" La respuesta honesta es que antes no existían las herramientas, el volumen de datos en M365 no era suficientemente maduro, y la organización no estaba lista para el cambio cultural que requiere. Los tres factores convergieron en 2025-2026. El momento era el correcto.