No es una predicción. Es lo que está pasando ahora mismo en la mayoría de equipos de ingeniería.
Los equipos están atrapados entre dos frases que se contradicen y que suelen decirse en la misma semana, a veces en la misma reunión: «no tengo tiempo de investigar cómo meter la IA en mi día a día» y «tengo que meter la IA como sea o nos quedamos atrás». Ninguna de las dos es mentira. Ese es el problema.
Cuando un equipo decide construir un framework para introducir IA de forma estructurada, el primer error habitual es tratarlo como un problema de herramientas. No lo es. Es un problema de tiempo y de a quién se le asigna. En la mayoría de equipos la IA ya se usa, cada persona a su manera, sin proceso común y sin criterio compartido. El síntoma no es falta de adopción. Es adopción desordenada bajo presión, y eso cansa más que no adoptar nada.
Esa dicotomía —investigar vs no quedarse atrás— no se resuelve con un mandato de «usad más IA». Eso es lo que hacen los equipos que luego reportan frustración y saturación: añaden una exigencia nueva encima de las entregas que ya existían, sin liberar tiempo real para nadie. El resultado es cumplimiento superficial. Gente que activa Copilot para que se note que lo usa, no porque haya cambiado cómo trabaja.
Un diagnóstico bien hecho es simple pero poco intuitivo: en lugar de preguntar «¿quién necesita más formación en IA?», conviene preguntar «¿quién de aquí ya tiene curiosidad e iniciativa propia con esto, aunque sea de forma desordenada?». No es la misma pregunta. La primera busca carencias. La segunda busca energía ya existente que solo necesita estructura. A esas personas —normalmente 1 o 2 dentro de un equipo de 3 a 8 personas— conviene reservarles parte de su tiempo, de forma explícita y con el resto del equipo sabiéndolo, para que analicen las fricciones reales y empiecen a esbozar el sistema, en vez de pedirles que lo hagan «cuando puedan» entre entregas.
El riesgo oculto aquí es doble:
- El primero: si esto se convierte en una tarea más de nadie en particular, no avanza, porque siempre pierde frente a la entrega con fecha.
- El segundo: más silencioso, si se elige a la persona equivocada —la más senior, o la que grita más fuerte que «hay que usar IA»— en vez de la que tiene curiosidad real, se acaba construyendo un framework de escritorio que nadie adopta después, porque no nace de la fricción real del equipo.
La prescripción para esta primera fase:
El Bloque 1 del framework (diagnóstico y casos de uso priorizados), es esta: identificar en el equipo quién ya está experimentando con IA por iniciativa propia, aunque sea de forma caótica. Darle tiempo protegido y visible —no oficioso— para que documente qué usa cada persona hoy, dónde hay más fricción diaria real, y proponga 3 o 4 casos de uso concretos por donde empezar. No intentar cubrir todo el ciclo de desarrollo desde el día uno. Empezar donde ya hay dolor real, no donde suena mejor en una presentación.
La dicotomía entre «no tengo tiempo» y «no podemos quedarnos atrás» no se resuelve pidiendo más esfuerzo individual. Se resuelve dando a alguien del equipo el tiempo y el mandato explícito de convertir ese caos en estructura. Esa es la primera decisión real de cualquier proceso de este tipo, y en las próximas dos semanas veremos cómo se traduce en un stack de herramientas y en los primeros guardrails.
Si te ha resultado útil, la mejor forma de ayudarme a seguir construyendo este espacio es compartirlo con alguien de tu equipo o tu red que esté pensando en estos mismos problemas.
Cada semana sigo analizando este tipo de temas aquí. Si llegaste por primera vez, bienvenido. Y si no quieres perderte la siguientes, suscríbete que es GRATIS. 😉