Recientemente, en zenital, hemos llevado a cabo una prueba de concepto para un cliente sobre el uso de GitHub Copilot en el desarrollo de Power BI. Más allá de evaluar las capacidades específicas de la herramienta, la experiencia nos llevó a plantearnos una pregunta que surge repetidamente en los entornos corporativos: ¿cuándo se debe incorporar una nueva tecnología y cuándo es mejor 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 lo tanto, la decisión no consiste simplemente en elegir entre adoptar una tecnología lo antes posible o esperar. Se trata de determinar si el valor de empezar antes compensa el riesgo y el coste adicional que supone trabajar con una tecnología que aún no está madura.

El valor de llegar antes

En nuestra prueba de concepto (PoC), constatamos que algunas tareas de desarrollo de Power BI podrían beneficiarse especialmente del uso de GitHub Copilot. La inteligencia artificial puede agilizar ciertas tareas y reducir el tiempo dedicado a actividades repetitivas. Por ejemplo, documentar un modelo de Power BI puede implicar redactar descripciones para docenas de tablas, columnas y medidas. GitHub Copilot puede generar este tipo de contenido en segundos y con un alto grado de fiabilidad. También puede agilizar la redacción de código DAX y ayudar a identificar y resolver problemas en los informes.

Estas mejoras reducen los plazos de desarrollo y permiten dedicar más tiempo a tareas en las que el criterio profesional aporta un mayor valor: comprender los requisitos, diseñar el modelo, analizar los resultados o decidir cómo presentar la información.

Sin embargo, es posible que la ventaja más significativa de experimentar desde el principio no sea la productividad inmediata, sino el conocimiento que se genera. Probar una tecnología antes de que su uso esté plenamente consolidado permite identificar en qué aspectos destaca, cuáles son sus límites y en qué situaciones aporta realmente valor añadido. En el ámbito de la consultoría, no basta con conocer una tecnología; necesitamos la capacidad de criterio necesaria para asesorar sobre cuándo está lo suficientemente madura para un caso de uso concreto, qué riesgos conlleva su implantación y qué nivel de dependencia es 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 prueba de concepto también puso de manifiesto que el uso de una herramienta de uso general no siempre es suficiente. Para integrarla realmente en nuestra forma de desarrollar con Power BI, es necesario personalizar su comportamiento mediante un agente específico o funciones que incorporen nuestras directrices y criterios de desarrollo. Identificar estos requisitos antes de pasar a una escala mayor es, de hecho, una de las principales ventajas de experimentar desde el principio.

Además de todo esto, hay otro reto: cuando algo sale mal, a menudo no hay nadie a quien preguntar. Con una tecnología bien 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 de apoyo aún se está creando.

Por lo tanto, los primeros usuarios no solo asumen un mayor riesgo técnico, sino que también deben resolver y documentar problemas que , probablemente, quienes lleguen más tarde encontrarán ya explicados en la documentación o por parte de 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 desde el principio nos permite familiarizarnos antes con una forma de trabajar que cobrará cada vez más importancia. Sin embargo, hay una diferencia importante entre probarlas y basar en ellas procesos fundamentales.

‍

‍

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

El momento adecuado para adoptar una tecnología depende de varias cuestiones, 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 tener en cuenta el coste de la espera. Mientras una organización no experimenta, es posible que otras estén acumulando experiencia y formación a sus equipos. Cuando la tecnología se consolide, todo el mundo podrá acceder al mismo producto; lo que no se podrá adquirir de inmediato es el conocimiento acumulado durante ese periodo.

‍

Prueba antes de adoptarlo

Aquí es donde surge una distinción importante: experimentar con una tecnología no es lo mismo que adoptarla de forma operativa. Entre integrarla de forma generalizada e ignorarla hasta que alcance su plena madurez, existe una alternativa: probarla mediante pruebas de concepto (PoC), proyectos piloto o casos de uso de bajo riesgo, lo que permite limitar la exposición al riesgo al tiempo que 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 prueba de concepto con GitHub Copilot aportó precisamente este valor. Aunque una prueba no conduzca de inmediato a una adopción generalizada, genera conocimientos útiles tanto para las decisiones inmediatas como para las 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.

‍