Construir software nunca fue tan barato. Un puñado de ingenieros despliega hoy lo que antes pedía un equipo de cincuenta. Así que la apuesta del momento parece obvia: si construir cuesta poco, construye tu camino hacia la transformación con IA.

Kevin Mannion le puso nombre a este momento en un post que se volvió viral esta semana: estamos en el pico del Mount Stupid, el pico de confianza de la curva de Dunning-Kruger. Máxima confianza y mínima competencia, exactamente al mismo tiempo.

La tesis de este post en una línea: la bajada de esa curva (la resistencia que nadie sacó a la luz, los casos raros, la última milla donde muere la adopción) es real y predecible, y en la mayoría de las empresas nadie es su dueño. La función que cuida esa bajada antes de construir es un discovery con compuerta Go/No-Go. Eso es exactamente lo que hacemos.

La apuesta es construir. Los datos dicen lo contrario.

La lógica del pico es tentadora porque la primera mitad es verdad. Construir de verdad es más barato. Lo que falla es el salto que viene después: si construir es barato, entonces construir es la respuesta.

El reporte de MIT NANDA, The GenAI Divide: State of AI in Business 2025, lo midió sin piedad: el 95% de los pilotos de IA empresariales no genera impacto medible en el P&L, pese a los 30 a 40 mil millones de dólares invertidos. No porque la construcción haya fracasado. Porque la organización no estaba lista para lo que se construyó.

Y trae un dato que casi nadie cita, el que de verdad debería frenarte antes de aprobar el presupuesto: comprar a un proveedor especializado o armar una alianza funciona cerca del 67% de las veces. Construir internamente acierta apenas un tercio de eso.

Léelo otra vez. La apuesta que Mannion describe (la de construir tu camino) es, en los números, la ruta con menos probabilidad de éxito. No es una opinión de consultor. Es lo que pasó en 300 despliegues reales.

La bajada que nadie menciona en los talleres

¿Qué es exactamente esa bajada? Mannion la describe mejor que nadie: la resistencia que nadie sacó a la luz en los talleres, los casos borde que no estaban en los requisitos, la última milla larga donde muere la adopción.

Nada de eso es nuevo, y esa es la parte incómoda. Hay más de un millón de personas a las que les pagan, literalmente, por verlo venir: líderes de transformación, consultores de desarrollo organizacional, especialistas en comunicación, gerentes de adopción, equipos de personas y cultura. Ya pasaron por esta curva con ERP, con CRM, con la transformación digital.

Pero, como dice Mannion, no están en la mesa. Cita que el 52% de las organizaciones toma decisiones de IA sin recursos humanos en la sala. El CIO tiene el presupuesto. Los Forward Deployed Engineers tienen la construcción. Y nadie tiene la bajada.

Ese es el agujero. No es un problema de talento técnico ni de presupuesto. Es que la responsabilidad de la bajada de la curva no está asignada a nadie, así que aparece como una sorpresa en producción cuando ya era predecible en una pizarra.

Llevo viendo esta curva desde 1990

Llevo construyendo software desde 1990. Si algo aprendí en treinta y seis años es que cada ola de tecnología se vende primero en su pico de confianza.

El ERP en los noventa iba a ordenar la empresa entera con solo instalarlo. El CRM iba a hacer que ningún cliente se cayera de la grieta. La transformación digital iba a reinventar el negocio. En cada caso el pico se sintió igual de real, y en cada caso la bajada llegó por el mismo lado: la gente no usó el sistema como se asumió, los procesos reales no se parecían al organigrama, y la última milla de adopción se comió el retorno prometido.

Lo que cambió esta vez es la herramienta, no la curva. Los modelos son mejores, construir es más rápido, los demos son más convincentes. Pero la bajada sigue siendo la misma de siempre: la organización no estaba lista para lo que se construyó. Quien te diga que esta vez la tecnología es tan buena que se salta la bajada, está parado justo en el pico.

El que ya pasó el valle tiene razón

Lo más interesante del post de Mannion pasó en los comentarios. J. Patrick McDonald, que asesora en gobernanza de IA, no le discutió la curva. Le discutió dónde estamos parados: él y muchos de los CTO con los que trabaja tocaron fondo en el valle hace más de un año y ya vienen subiendo del otro lado.

Y soltó la frase que importa: el 90% de esos pilotos nunca tuvo chance de mostrar retorno, porque el retorno nunca se consideró cuando arrancó el piloto. La justificación de valor era delgada o inexistente, basada en supuestos que nadie validó.

Eso no contradice la tesis de la bajada. La confirma. Si el retorno nunca se definió, claro que el piloto no movió el P&L: nadie sabía qué iba a mover. Jason Duncan lo remató en el mismo hilo: muchos proyectos empiezan con una solución y después salen a buscar un problema, y para cuando alguien pregunta cómo se va a medir el éxito, el proyecto ya arrancó. La tecnología acelera el progreso, sí, pero también acelera la ambigüedad.

Esa es justo la decisión que un discovery toma antes de escribir una línea de código: qué problema, qué retorno, qué pasa si la respuesta es que no vale la pena. No es burocracia. Es el seguro contra la bajada.

Lo que hacemos en IQ Source con esto

Cuando una empresa nos pide ayuda con IA, la primera pregunta no es qué construir. Es si conviene construir, y quién va a ser dueño de la bajada cuando aparezca.

AI Maestro es ese discovery. Dos meses mapeando la operación real, no la del organigrama, para producir tres cosas: un mapa de cómo funciona de verdad el proceso, un Score de Oportunidad de IA que dice dónde el retorno es real y dónde es un demo bonito, y una compuerta Go/No-Go al final que decide, con datos, si se construye o no. Más de una vez esa compuerta termina recomendando no construir todavía, o construir mucho menos de lo que el cliente vino a pedir.

Lo que ese discovery hace, en el fondo, es ponerle dueño a la bajada antes de que exista. La resistencia, los casos raros, la última milla: todo eso sale a la luz en la fase de discovery, en el papel, cuando cambiar de rumbo todavía es barato. Es la misma disciplina que ya escribí cuando adoptar IA no es lo mismo que transformarse, y la que aplico cuando ayudo a una empresa a decidir si la IA es siquiera la respuesta para ese proceso. Muchas veces no lo es, y saberlo antes vale más que cualquier piloto.

El pico de confianza se siente bien. Por eso es peligroso. La pregunta que conviene hacer en tu próxima reunión de IA no es “¿qué construimos?”. Es otra, más incómoda: cuando esto llegue a producción y aparezca la resistencia que nadie mencionó, ¿quién, con nombre y apellido, es dueño de esa bajada? Si nadie levanta la mano, todavía no estás listo para construir. Estás parado en el pico.

Ponle dueño a la bajada de tu proyecto de IA