Recientemente, en zenital, hemos realizado una prueba de concepto para un cliente sobre el uso de GitHub Copilot en el desarrollo con Power BI. Más allá de evaluar las capacidades concretas de la herramienta, la experiencia nos ha llevado a una cuestión que aparece de forma recurrente en el ámbito corporativo: ¿cuándo incorporar una nueva tecnología y cuándo esperar a que madure?

Adoptarla pronto puede aportar ventajas claras: acceder antes a nuevas capacidades, aumentar la productividad, mejorar determinados procesos y, sobre todo, empezar a acumular experiencia mientras otras organizaciones todavía están evaluando su potencial. Pero también implica aceptar un mayor nivel de incertidumbre: productos menos estables, documentación incompleta, funcionalidades sujetas a cambios y una base limitada de experiencias reales de las que aprender.

Por tanto, la decisión no consiste simplemente en elegir entre adoptar una tecnología cuanto antes o esperar. Consiste en determinar si el valor de empezar antes compensa el riesgo y el coste adicional que supone trabajar con una tecnología todavía inmadura.

El valor de llegar antes

En nuestra PoC vimos que algunas tareas de desarrollo con Power BI podían beneficiarse especialmente del uso de GitHub Copilot. La IA puede acelerar determinadas tareas y reducir el tiempo dedicado a actividades repetitivas. Por ejemplo, documentar un modelo de Power BI puede implicar redactar descripciones para decenas de tablas, columnas y medidas. GitHub Copilot permite generar este tipo de contenido en segundos y con un alto grado de fiabilidad. También puede agilizar la escritura de código DAX o ayudar durante la identificación y resolución de problemas en los reportes.

Este tipo de mejoras reduce los tiempos de desarrollo y libera tiempo para tareas en las que el criterio profesional aporta más valor: entender los requerimientos, diseñar el modelo, analizar los resultados o decidir cómo presentar la información.

Sin embargo, el beneficio más relevante de experimentar pronto puede no ser la productividad inmediata, sino el conocimiento que se genera. Probar una tecnología antes de que su uso esté plenamente consolidado permite identificar qué hace bien, dónde están sus límites y en qué situaciones aporta realmente valor. En consultoría, conocer una tecnología no basta, necesitamos criterio para aconsejar cuándo está suficientemente madura para un caso de uso, qué riesgos implica introducirla y qué nivel de dependencia resulta razonable asumir.

‍

El coste de trabajar con una tecnología poco madura

La adopción temprana también traslada parte del esfuerzo de maduración del fabricante a los usuarios.

Durante nuestra PoC encontramos varios ejemplos. Uno de ellos fue un bug que bloqueaba Desktop Bridge, un componente necesario para conectar Power BI con el agente de IA. También vimos limitaciones menos visibles pero relevantes para una adopción real: en algunas tareas, Copilot resultaba más lento de lo deseable y el consumo de créditos podía aumentar rápidamente. Esto no impide utilizar la herramienta, pero sí afecta a su viabilidad al escalar su uso.

La PoC también puso de manifiesto que utilizar una herramienta generalista no siempre es suficiente. Para integrarla realmente en nuestra forma de desarrollar Power BI, es necesario personalizar su comportamiento mediante un agente propio o skills que incorporen nuestras guidelines y criterios de desarrollo. Descubrir estos requisitos antes de escalar es, de hecho, uno de los principales beneficios de experimentar pronto.

A todo esto se suma un problema: cuando algo falla, muchas veces no hay a quién preguntarle. Con una tecnología consolidada, cuando surge una dificultad, la solución suele encontrarse en la documentación oficial, en un foro o en un artículo técnico. Con una tecnología muy nueva, esa red aún se está formando.

Los primeros usuarios, por tanto, no solo asumen un mayor riesgo técnico. También tienen que resolver y documentar problemas que quienes lleguen después probablemente encontrarán ya explicados por la documentación o la comunidad.

‍

Un dilema que no es exclusivo de la IA

Power BI ofrece un ejemplo muy cercano: Microsoft publica regularmente nuevas capacidades en estado Preview, lo que permite utilizarlas antes de que alcancen su versión definitiva, pero también implica aceptar posibles cambios, limitaciones o comportamientos inestables.

En nuestro trabajo ya estamos explorando algunas de estas capacidades, como los formatos PBIP y PBIR o el nuevo tema Modern Visual.

Utilizarlas pronto nos permite familiarizarnos antes con una forma de trabajo que tendrá cada vez más importancia. Pero existe una diferencia importante entre probarlas y construir procesos críticos con ellas.

‍

‍

No todas las tecnologías deben adoptarse en el mismo momento

El momento adecuado para adoptar una tecnología depende de varias preguntas, que nos ayudan a decidir cuánto riesgo merece la pena asumir:

• ¿Qué grado de madurez tiene la tecnología? Si esperamos cambios importantes, la incertidumbre aumenta.
• ¿Qué beneficio esperamos obtener y a qué coste? Hay que considerar su rendimiento, coste económico y cómo cambian esos factores al escalar.
• ¿Encaja con nuestra forma de trabajar? Una herramienta puede ser técnicamente válida y, aun así, necesitar personalización para respetar guidelines, estándares o procesos internos.
• ¿Qué ocurre si falla? No es lo mismo acelerar una tarea interna que afectar a un proceso crítico, ni utilizar una capacidad que podemos abandonar fácilmente que construir una dependencia difícil de revertir.
• ¿Tenemos capacidad para experimentar? Hace falta tiempo, conocimiento y margen para equivocarse.

Estas preguntas ayudan a evitar dos extremos poco rigurosos: adoptar una tecnología simplemente porque es nueva o descartarla solo porque aún no está completamente madura.

También hay que considerar el coste de esperar. Mientras una organización no experimenta, otras pueden estar acumulando experiencia y formando a sus equipos. Cuando la tecnología se consolida, todos pueden acceder al mismo producto; lo que no se adquiere de inmediato es el conocimiento acumulado durante ese periodo.

‍

Prueba antes de adoptarlo

Aquí aparece una distinción importante: experimentar con una tecnología no equivale a adoptarla de forma operativa. Entre integrarla ampliamente e ignorarla hasta que alcance madurez plena, existe una alternativa: probarla mediante PoCs, pilotos o casos de uso de bajo riesgo, limitando la exposición mientras se genera conocimiento.

El objetivo en esta fase no debería ser solo comprobar si algo funciona, sino reducir la incertidumbre: entender qué condiciones necesita para una adopción más amplia, si ofrece un rendimiento suficiente, si su coste es asumible, cómo se integra con las herramientas existentes y hasta qué punto puede adaptarse a las guidelines de la organización. 

Nuestra PoC con GitHub Copilot tuvo precisamente ese valor. Aunque una prueba no lleve inmediatamente a una adopción generalizada, genera conocimiento útil tanto para decisiones inmediatas como futuras. 

Podemos pensar en esta estrategia como pasar de querer ser early adopter a ser early learner: aprender mediante experimentación controlada antes de hacer que la organización dependa de esa tecnología.

No siempre hay que ser un early adopter. Pero conviene evitar convertirse en un late learner.

‍