La mayoría de los equipos que dicen haber "adoptado IA" no adoptaron IA, distribuyeron licencias de Copilot, abrieron una cuenta de ChatGPT para el equipo y marcaron la tarea como concluida. Seis meses después el resultado es previsible: dos o tres devs entusiastas extrayendo valor real, el resto produciendo PRs con el mismo bug genérico que el LLM alucinó en tres repositorios diferentes, ningún dato que sostenga una conversación con la dirección, y un costo de API que nadie sabe explicar. La IA no falló. El método de adopción falló.
El framework Steply de adopción corporativa de IA tiene 7 fases organizadas en 3 movimientos: Fundación (¿estamos listos? ¿quién es el dueño?), Estructura (¿cómo adoptar sin amplificar el caos?) y Sostenimiento (¿cómo mantenerlo funcionando a escala?). No es receta de cocina, es una secuencia obligatoria, saltar el Movimiento 1 e ir directo al Movimiento 3 es exactamente lo que produce el caos amplificado que este framework existe para evitar. Este post recorre cada fase, lo que entrega, y el síntoma que aparece cuando se la ignora.
Por qué saltar una fase amplifica el caos en vez de generar productividad
La IA no es una herramienta neutral que mejora lo que está bien y empeora lo que está mal por igual. La IA es un multiplicador. Empuja la señal del equipo hacia arriba cuando hay claridad de proceso y hacia abajo cuando hay ambigüedad. Un equipo que ya produce código sin dueño claro, sin estándar de revisión, sin criterio de done, va a producir más código sin dueño, sin estándar y sin criterio, ahora generado en segundos en vez de horas. El bug es el mismo, solo que escala.
Por eso el orden de los movimientos no es estético. Fundación primero porque sin diagnóstico no sabes qué estás optimizando, sin AI enablers no tienes infraestructura para ejecutar nada serio, y sin piloto estás apostando el presupuesto anual a una hipótesis. Estructura después porque solo tiene sentido remover cuellos de botella cuando ya mediste dónde están, y la adopción progresiva solo funciona cuando hay un piloto exitoso para usar como prueba. Sostenimiento al final porque gobernar y escalar algo que no está funcionando es teatro de proceso, estás documentando expectativas en vez de realidad.
Movimiento 1, Fundación: ¿estamos listos? ¿Quién es el dueño?
Es la fase donde la mayoría de las empresas hace trampa. "Ya estamos listos, el equipo es senior, no necesita diagnóstico", frase que precede al 100% de los proyectos de IA que naufragan en 4 meses. La Fundación responde dos preguntas que nadie quiere responder con honestidad: dónde duele de verdad, y quién asume el resultado. Sin esas dos respuestas, todo lo demás es improvisación.
Fase 1, Diagnóstico
No es un workshop de medio día con post-it de colores. Es un mapeo honesto de tres cosas: (1) dónde el equipo gasta tiempo que no entrega valor (revisión circular, debugging de regresión, build roto, reunión sobre reunión), (2) qué procesos tienen regla clara pero ejecución manual repetitiva (triaje de issues, clasificación de tickets, generación de release notes, escritura de documentación a partir del código), y (3) cuál es la tolerancia real del liderazgo al riesgo, riesgo de error del modelo, riesgo de exposición de datos, riesgo de cambio de proceso. Sin diagnóstico, cualquier herramienta parece buena porque no hay criterio de comparación.
Fase 2, AI Enablers
Antes de cualquier caso de uso, hace falta tener lo que hace posible la IA dentro de la empresa: una política de datos clara (qué puede ir al modelo externo, qué necesita quedarse in-house), contratos con proveedores (Anthropic, OpenAI, Google o self-hosted) con cláusula de no entrenamiento, control de costo (límite por clave, alerta por consumo, atribución por equipo), y acceso técnico (proxy corporativo, gateway de modelo, observabilidad de llamadas). Una empresa que entra en IA sin enablers descubre, dos meses después, que el consumo de tokens se duplica cada quincena y nadie sabe quién está llamando a qué API con qué dato.
Fase 3, Piloto
Un único caso de uso, con alcance corto, plazo corto, éxito medible. No es "vamos a ver dónde ayuda la IA", es "vamos a resolver este problema específico en 6 semanas y medir antes/después". El piloto sirve a tres propósitos: prueba de valor concreto para el liderazgo, aprendizaje operativo para el equipo técnico, y generación de evidencia interna para vencer la resistencia cultural que siempre existe en la próxima fase. Un piloto sin métrica es una demo bonita que nadie toma en serio.
Movimiento 2, Estructura: ¿cómo adoptar sin amplificar el caos?
Con la Fundación en su lugar, el problema deja de ser "si la IA funciona" y se vuelve "cómo expandir sin romper lo que ya está bien". Es aquí donde el framework se diferencia del enfoque ingenuo de "libera Copilot para todos y reza". La Estructura es deliberada sobre dónde aplicar (cuellos de botella reales, no modas) y cómo aplicar (progresivamente, por anillo, no en big-bang).
Fase 4, Cuellos de botella
Con el piloto entregado, tienes un mapa mucho más honesto de dónde la IA realmente mueve la aguja. Ahora la pregunta es: ¿cuáles son los 2 o 3 cuellos de botella del flujo de ingeniería que, si se remueven, liberan el mayor throughput? Suele ser código boilerplate, generación de tests, documentación de API, triaje de bugs, escritura de migrations, refactor mecánico. No es "todo dev usa IA todo el tiempo", es "los cuellos de botella identificados pasan a usar IA con un proceso bien definido". La aplicación quirúrgica le gana a la aplicación difusa en todo escenario donde la métrica importa.
Fase 5, Adopción Progresiva
Anillos concéntricos. Anillo 1: el equipo del piloto se vuelve el squad de referencia, opera con IA en producción, documenta patrón y antipatrón. Anillo 2: dos o tres equipos adyacentes adoptan el mismo patrón bajo la mentoría del Anillo 1. Anillo 3: rollout general, con material de onboarding listo y un canal de soporte interno funcionando. Cada anillo solo se abre después de que el anterior se estabilizó. El big-bang de adopción ("la semana que viene todos lo están usando") es la forma más cara conocida de quemar la credibilidad de la IA dentro de la empresa, cuando un equipo no entrenado falla en público, la narrativa que queda es "la IA no funciona aquí", no "la adopción se hizo mal".
Movimiento 3, Sostenimiento: ¿cómo mantenerlo funcionando a escala?
Es la fase ignorada con más frecuencia, y la que más cobra intereses después. La adopción sin sostenimiento se degrada en 6 a 12 meses, el estándar se diluye, el costo se escapa, el entusiasmo inicial se vuelve frustración cuando el modelo cambia de versión y rompe el flujo, y la empresa vuelve prácticamente al estado pre-IA con la diferencia de tener una factura mensual que justificar.
Fase 6, Gobernanza
La gobernanza aquí no es un comité. Es un conjunto pequeño y operativo de cosas: (1) un dueño nombrado para cada uso de IA en producción (con nombre, no con cargo), (2) una política de revisión de prompts e system instructions versionada en git como cualquier otro código, (3) auditoría mínima de salidas críticas (muestreo del 1-5% por uso), (4) un proceso de aprobación para nuevos casos de uso (no para frenar, para registrar y medir), y (5) una revisión trimestral de lo que todavía tiene sentido. La buena gobernanza es la que cabe en una página. La mala gobernanza es la que necesita un comité para explicar por qué existe.
Fase 7, Escala
La escala no es "más IA en más lugares", es volver el uso de IA tan rutinario como usar CI/CD. Significa: estándar de prompt versionado en una biblioteca interna, gateway de modelo con fallback y ruteo por costo, observabilidad de latencia/costo/calidad por caso de uso, plan de migración entre versiones de modelo (porque va a cambiar), y onboarding de un nuevo dev que incluye la IA como cualquier otra herramienta del stack. Cuando la fase 7 está madura, nadie en la empresa habla más sobre un "proyecto de IA". Habla sobre el producto. La IA se volvió el sustrato.
Lo que este framework explícitamente no es
No es metodología ágil renombrada. No es una certificación. No tiene nivel Bronce/Plata/Oro. No vende entrenamiento. Es un diagnóstico de orden. Si tu empresa está en la fase 6 sin haber pasado por la 1, el síntoma va a aparecer en 90 días en forma de fatiga de proceso sobre una tecnología que nadie entiende bien. Si está en la fase 4 sin haber pasado por la 3, va a elegir el cuello de botella equivocado y quemar el presupuesto del piloto en la fase equivocada. El orden es la contribución.
Para el equipo técnico que lee esto y piensa "estamos claramente en la fase 5 pero saltamos la 1 y la 2", ese es exactamente el diagnóstico más común y el más corregible. Volver no es un retroceso, es un desbloqueo. La alternativa, seguir sin fundación, es el escenario en el que se gasta el año entero optimizando algo que nadie logra explicarle al liderazgo en el Q4. El framework existe para evitar esa conversación.