De cada veinte proyectos de IA que una empresa pone en marcha, diecinueve no llegan nunca a la cuenta de resultados.

La cifra viene de un estudio de la iniciativa NANDA del MIT, The GenAI Divide: State of AI in Business 2025, publicado en agosto de 2025 tras analizar 300 despliegues reales: el 95% de los pilotos de IA generativa no produce ningún impacto medible en el P&L. Solo uno de cada veinte mueve de verdad el negocio.

El reflejo de muchos comités de dirección ante ese dato es buscar al culpable en el sitio equivocado, normalmente el modelo, el proveedor o la ausencia de un equipo técnico interno potente. De ahí sale la conclusión más cara de todas: la de que sin un departamento de IT robusto no se puede hacer IA con cabeza.

La pyme que no arrastra un gran departamento de IT tiene en realidad una ventaja que la gran empresa ha perdido, porque nadie dentro de la organización cobra por defender un piloto que no funciona. Lo que falta es un criterio para decidir qué se hace primero, qué se aparca y qué no se toca. Este artículo es ese criterio, y se puede aplicar el lunes por la mañana.

El año en que la IA dejó de ser un experimento

En 2026 la conversación ha cambiado de fase. La última encuesta global de McKinsey sobre el estado de la IA muestra que casi nueve de cada diez organizaciones ya la usan con regularidad, así que la pregunta de "¿adoptamos IA?" ha dejado de tener sentido, porque la respuesta ya es que sí, lo quiera el comité o no.

La pregunta que importa ahora es otra: de todo lo que se puede hacer con IA, ¿qué hace tu empresa primero?

Para una pyme el peligro concreto tiene nombre, y es la cartera por miedo. El comité ve a la competencia anunciar iniciativas, se pone nervioso y aprueba ocho o diez pilotos a la vez para no quedarse atrás. Seis meses después hay ocho facturas, ningún dueño claro y nada que enseñar.

Hay un dato del mismo estudio del MIT que conviene tener delante al priorizar, ya que más de la mitad de los presupuestos de IA se destinan a herramientas de ventas y marketing mientras que el mayor retorno aparece en la automatización del back-office, es decir, en reducir trabajo administrativo, recortar coste de procesos externalizados y ordenar operaciones. El sitio donde el dinero es más fácil de recuperar rara vez coincide con el sitio donde el comité quiere gastarlo.

Por qué esto no es una decisión de tu equipo técnico

Priorizar casos de uso de IA es, en el fondo, asignar capital, y asignar capital es trabajo de dirección general y de finanzas, no de un perfil técnico.

Esta es la reclasificación que cambia el resultado. Cuando el comité trata la priorización como un asunto técnico la delega, y quien la recibe optimiza por criterios técnicos (qué es elegante de construir, qué usa la tecnología más nueva) en lugar de optimizar por euros. El orden de los proyectos lo tiene que fijar quien responde del margen.

El miedo de fondo en muchas pymes es "no tengo ingenieros para esto". El mismo estudio del MIT lo desactiva con un dato útil, porque comprar herramientas de IA a proveedores especializados funciona alrededor del 67% de las veces, mientras que construir la solución en casa funciona solo en torno a un tercio de los casos. Para una empresa sin un departamento de IT grande, el camino con más probabilidad de retorno consiste en comprar producto probado y conectarlo, en lugar de montar un proyecto de ingeniería.

Dicho de otro modo, la falta de un equipo técnico interno no te impide hacer esto: te empuja hacia la forma que, según los datos, funciona mejor de todas maneras.

El marco: puntúa cada caso de uso en tres ejes

El marco es deliberadamente simple, porque tiene que caber en una hoja y sobrevivir a una reunión de comité. Cada caso de uso candidato se puntúa de 1 a 5 en tres ejes.

Impacto económico. Cuántos euros mueve al año, expresados en una métrica que el CFO ya reconoce: horas de trabajo liberadas y valoradas a coste, reducción de coste unitario, ciclo de caja, ingresos retenidos. Si el patrocinador no sabe decir la cifra de partida de esta semana, el impacto sigue siendo un interrogante en lugar de un 5.

Esfuerzo. Cuánto cuesta ponerlo en marcha, y aquí el coste rara vez es la licencia. Es la preparación del dato, la integración con lo que ya tienes y, sobre todo, el cambio de hábito de las personas que usarán la herramienta. Un caso que exige limpiar tres bases de datos antes de arrancar es de esfuerzo alto aunque el software cueste cuatro euros al mes.

Riesgo. Qué pasa cuando el sistema se equivoca. Un asistente que redacta borradores internos tiene riesgo bajo, porque un humano revisa antes de que nada salga. Un sistema que responde directamente a clientes, decide precios o toca datos personales tiene riesgo alto, y arrastra además el filtro regulatorio europeo.

La trampa habitual consiste en promediar los tres números. No lo hagas. El impacto y el esfuerzo se comparan entre sí, pero el riesgo funciona como una barrera, de modo que cualquier caso de riesgo alto queda fuera del primer lote de 90 días por bueno que parezca, porque tu objetivo inicial no es el proyecto más ambicioso, sino demostrar que el método funciona sin jugarte la reputación en el primer intento.

La matriz: cuatro casillas y qué haces con cada una

Con el riesgo alto ya apartado, coloca el resto de casos en una matriz de impacto contra esfuerzo. Salen cuatro casillas.

Victorias rápidas (impacto alto, esfuerzo bajo). Son tu lote de los primeros 90 días. Casi siempre viven en el back-office: resúmenes de documentos, primer borrador de informes recurrentes, clasificación de correo, preparación de datos para reuniones.

Apuestas mayores (impacto alto, esfuerzo alto). Importan, pero no ahora. Van a una hoja de ruta a doce meses y solo se financian cuando una victoria rápida haya demostrado que la empresa sabe ejecutar. Arrancar por aquí es el error más común y más caro.

Rellenos (impacto bajo, esfuerzo bajo). Se hacen solo si sobra capacidad después de las victorias rápidas. Nunca compiten por la atención del comité.

Pozos sin fondo (impacto bajo, esfuerzo alto). Se descartan hoy, en la propia reunión. Si alguien insiste, esa insistencia suele señalar que el caso tenía padrino interno y no retorno.

"El primer caso de IA de una empresa no debería elegirse por lo ambicioso que suena en el consejo, sino por lo rápido que demuestra que el método funciona."

¿Por qué tanta disciplina para empezar por lo pequeño? Porque la credibilidad interna de la IA se gana o se pierde con el primer proyecto. Una victoria rápida que mueve una métrica real en 90 días te compra permiso para las apuestas mayores. Un primer proyecto ambicioso que encalla mata el apetito del comité durante dos años.

La hoja de ruta de 90 días

El marco anterior se convierte en calendario. Lo que sigue es algo que un CEO o un CFO puede llevar al comité de esta semana y poner en marcha sin contratar a nadie.

1. Días 1 a 15: inventaría y puntúa. Reúne en una sola lista todos los casos de uso de IA que alguien en la empresa haya propuesto, tenga en marcha o haya imaginado, y puntúa cada uno en los tres ejes. La lista suele ser más larga y más desordenada de lo que el comité esperaba, y eso ya es información.

2. Días 1 a 15: asigna un dueño de negocio a cada caso. Una persona con cuenta de resultados, no de IT, que gane o pierda dinero con el proceso afectado. Un caso sin dueño no se puntúa: se descarta. La orfandad es el primer síntoma de un piloto que no va a llegar a ningún sitio.

3. Días 16 a 30: elige dos o tres victorias rápidas y mide la línea base. Solo dos o tres, no diez. Para cada una, escribe el número de partida de hoy: minutos por tarea, coste por proceso, errores por lote. Sin línea base medida ahora, en 90 días no podrás demostrar nada y el proyecto vivirá de la sensación de que "parece que va bien".

4. Días 16 a 30: compra, no construyas. Para cada victoria rápida, busca una herramienta de proveedor especializado antes de plantear un desarrollo propio. Es más rápido, es más barato de revertir si falla y, según los datos, tiene el doble de probabilidad de funcionar.

5. Días 31 a 75: ejecuta con un punto de control en el día 50. Deja que el equipo use la herramienta de verdad. En el día 50, revisa: si la métrica no se ha movido nada a mitad de camino, probablemente no se moverá al final, y conviene saberlo con tiempo para corregir o cortar.

6. Días 76 a 90: mide contra la línea base y decide. Compara el número final con el de partida. Cada victoria rápida entra en una de dos columnas: la que movió la métrica, que pasa a ser candidata a escalar, y la que no la movió, que se cierra sin drama. Ese cierre limpio es parte del método, no un fracaso.

Noventa días, dos o tres herramientas compradas, ningún ingeniero contratado y, al final, evidencia en lugar de opiniones.

Quién firma esto y qué pasa el día 91

El marco pierde su valor si lo aplica quien pide el presupuesto. Tiene que sostenerlo alguien con autoridad transversal, y en una pyme eso es el CEO o el CFO, sentados en la misma mesa. La razón es sencilla, porque el paso 2 y la casilla de los pozos sin fondo obligan a decir que no a proyectos con padrino interno, y eso solo lo hace con comodidad quien responde del conjunto.

El día 91 tu empresa está en un sitio distinto. Ya no discute si la IA sirve, porque tiene una métrica que subió o bajó de verdad. Ha aprendido a recorrer el ciclo completo (inventariar, puntuar, priorizar, medir, decidir) y ese ciclo se repite cada trimestre con casos nuevos, ahora ya con las apuestas mayores sobre la mesa.

La matriz cabe en una servilleta. Lo difícil viene después: sostener el criterio cuando llegan diez propuestas con padrino y prisa, y mantener la cabeza fría sobre qué mueve el negocio y qué solo suena bien. Esa conversación, la de cómo un equipo directivo construye y defiende su propia hoja de ruta de IA sin delegarla, es la que trabajamos en Shift Directivo, el programa presencial de Stradiax para directivos.

La próxima vez que llegue una propuesta de IA al comité, antes de preguntar qué modelo usa, pásala por los tres ejes. Si no tiene impacto medible, dueño de negocio y un esfuerzo asumible, esa propuesta todavía no está lista para ejecutarse, tenga tu empresa departamento de IT o no. Su sitio es la lista de espera.