Dónde entra la IA en tu operación y dónde no: guía de decisión

La IA entra donde el proceso es repetitivo, tiene volumen suficiente para que importe y su resultado ya lo revisa alguien. No entra donde el error es caro y nadie va a mirar la salida. Casi todo lo que falla en la práctica cae del segundo lado, o directamente nunca llegó a tocar el trabajo real.

Puntos clave

• El 88% de las organizaciones ya adoptó IA y el 70% la usa en al menos una función.
• El informe de MIT NANDA reporta que el 95% de las organizaciones no obtiene retorno, y se presenta a sí mismo como hallazgos preliminares.
• La causa no es la calidad de los modelos: son proyectos que nunca entraron en el flujo de trabajo que iban a cambiar.
• Del mismo estudio: comprar llega a despliegue el doble de veces que construir, con la advertencia de causalidad que trae el propio informe.

¿Cuánta gente está usando IA y a cuánta le está funcionando?

Casi todos la usan y casi nadie la cobra. Es la brecha más grande de este tema, y las dos mitades vienen de fuentes distintas.

Del lado de la adopción, el AI Index 2026 de Stanford encontró que el 88% de las organizaciones encuestadas adoptó IA, que el 70% ya usa IA generativa en al menos una función de negocio, y que el despliegue de agentes sigue en cifras de un solo dígito en casi todas las áreas (Stanford HAI).

Del lado del resultado está el informe The GenAI Divide: State of AI in Business 2025, de la iniciativa NANDA del MIT, que es de donde sale el famoso 95%. Lo leímos completo, las 26 páginas, y hay que decir dos cosas antes de citarlo.

La primera es dónde está. La URL del MIT no entrega el archivo; el PDF circula alojado por terceros. Eso no lo hace menos auténtico, y sí explica por qué casi todo el mundo lo cita a través de la prensa.

La segunda es lo que el informe dice de sí mismo en su primera página: «Preliminary Findings from AI Implementation Research from Project NANDA», con periodo de investigación de enero a junio de 2025. Hallazgos preliminares. La estadística más citada del año sobre IA empresarial se presenta a sí misma como preliminar, y eso no aparece en ninguna de las mil veces que se ha repetido.

Su metodología, literal: «a systematic review of over 300 publicly disclosed AI initiatives, structured interviews with representatives from 52 organizations, and survey responses from 153 senior leaders collected across four major industry conferences».

Qué mide	Cuánto
Organizaciones que ya adoptaron IA	88%
Organizaciones con IA generativa en al menos una función	70%
Despliegue de agentes por función de negocio	Cifras de un dígito
Organizaciones que no obtienen ningún retorno	95%
Alianzas externas que llegan a despliegue	~67% de las veces
Desarrollos internos que llegan a despliegue	~33% de las veces

Fuentes: las tres primeras filas salen de Stanford HAI, AI Index 2026. Las tres últimas, de MIT NANDA, The GenAI Divide: State of AI in Business 2025, leído en el documento original el 1 de septiembre de 2026. Las dos últimas cifras son literales: «external partnerships with learning-capable, customized tools reached deployment ~67% of the time, compared to ~33% for internally built tools».

Una corrección, y es nuestra. Antes citábamos estas cifras a través de Fortune, que fue quien hizo famoso el estudio, porque no habíamos localizado el original. Fortune se equivocó en dos cosas y nosotros publicamos su versión. Dijo que el estudio se hizo con 150 entrevistas y una encuesta a 350 empleados, cuando fueron 52 organizaciones y 153 directivos. Y dijo que los desarrollos internos funcionan «un tercio de las veces» que las compras, lo que da el triple de diferencia; el informe dice 67% contra 33%, que es el doble. Publicamos «el triple» y era «el doble». Está corregido arriba.

Y el propio informe pone un límite que casi nadie repite. Sobre esas dos últimas filas escribe: «These success rate differences may reflect organizational capabilities rather than implementation approach alone... The correlation between external partnerships and success does not necessarily prove causation.» Dicho de otro modo: puede que comprar no funcione mejor, sino que las empresas que compran sean distintas de las que construyen. Sobre el resto de sus cifras añade que son «directionally accurate based on individual interviews rather than official company reporting».

Con esas dos advertencias encima, las dos últimas filas siguen siendo lo más útil del informe, y lo que más contradice el instinto de mucha dirección técnica.

¿Por qué fallan los pilotos?

No por el modelo. El informe apunta a una brecha de aprendizaje: «Most GenAI systems do not retain feedback, adapt to context, or improve over time.» Herramientas que nunca entraron en el proceso que se compraron para cambiar. Se quedaron al lado, como una pestaña más que alguien abre cuando se acuerda.

Es el mismo patrón que hunde las implementaciones de CRM, y por la misma razón: un sistema que vive fuera del trabajo compite contra la costumbre y pierde. Lo tratamos a fondo en por qué fracasan las implementaciones de CRM.

La consecuencia práctica es que la pregunta de compra no es «¿qué tan bueno es este modelo?». Es «¿en qué momento exacto del día de qué persona aparece esto?». Si no puedes contestarla con un nombre y una hora, todavía no tienes un proyecto.

¿Qué procesos son buenos candidatos?

Los que cumplen las tres condiciones a la vez. Una o dos no bastan.

1. Se repite lo suficiente, decenas de veces al mes como mínimo. Por debajo de eso, el esfuerzo de montarlo y mantenerlo no se recupera nunca, por bien que funcione.
2. Alguien ya revisa la salida. Si el resultado pasa por ojos humanos antes de tener consecuencias, el error es barato y corregible, y ese colchón es lo que te permite aprender en producción sin romper nada.
3. El resultado se puede juzgar: alguien puede mirar dos salidas y decir cuál está mejor. Si nadie sabe cómo se ve un buen resultado, no vas a poder medir si mejora.

La tercera es la que más se salta y la que más caro sale. Un proyecto sin criterio de calidad no se puede mejorar ni cancelar: solo se puede defender con anécdotas.

¿Qué procesos no conviene automatizar?

Tres tipos, y ninguno tiene que ver con la dificultad técnica.

El primero son los que definen tu relación con el cliente en un momento delicado: una renegociación, un reclamo grave, una mala noticia. No porque el modelo no pueda redactarlo, sino porque el costo de que salga mal una vez borra el ahorro de las cien que salieron bien.

El segundo son los procesos rotos. Automatizar algo que nadie entiende lo vuelve más rápido y más difícil de arreglar. Si hoy depende de que Ana sepa a quién llamar, primero hay que escribir lo que Ana sabe.

El tercero son los que ocurren tres veces al mes, y aquí el problema es de mantenimiento: todo proyecto de IA necesita atención cuando cambia el modelo, cuando cambia el proceso o cuando cambia el formato de entrada. Con poco volumen, esa atención cuesta más que hacer el trabajo a mano.

¿Construir o comprar?

Comprar, salvo que el proceso sea tu ventaja competitiva. Las cifras del informe son inusualmente claras para una pregunta que normalmente se decide por gusto: las alianzas externas llegan a despliegue cerca del 67% de las veces, y los desarrollos internos cerca del 33%.

La lectura no es que los equipos internos sean peores. Es que un proveedor especializado ya recorrió los errores de ese caso de uso concreto, y ese recorrido es la mayor parte del valor. Construir tiene sentido cuando el proceso es lo que te distingue, porque entonces esos errores son tuyos y aprenderlos es el activo.

Con un matiz que el informe se pone a sí mismo y que conviene tener presente al usar este argumento en una junta: la diferencia puede venir de cómo son las empresas que compran, no de que comprar funcione mejor. Quien compra suele tener otra tolerancia al riesgo y otra madurez de compras. Correlación, no causa.

¿Cómo se calcula el retorno sin inventar números?

Con dos mediciones tomadas antes de empezar. Sin la primera, cualquier cifra posterior es una historia.

La primera es cuánto cuesta hoy ese proceso: cuántas veces ocurre al mes, cuánto tarda cada vez, y a qué costo por hora. Es aritmética aburrida y casi nadie la hace, y por eso casi nadie puede demostrar retorno después.

La segunda es cuál es la tasa de error actual. Sí, la del proceso humano. Un modelo que acierta el 92% suena mal hasta que descubres que el proceso manual acertaba el 88%, y entonces suena distinto. Sin línea base, cualquier tasa de error se puede presentar como fracaso o como éxito según convenga.

Con esas dos, el cálculo posterior es honesto. Sin ellas, lo que hay es un proveedor enseñándote su propio caso de estudio.

¿Y los datos personales?

Es la parte que más se salta y la única con consecuencia legal. En México, la LFPDPPP obliga a informar en el aviso de privacidad las finalidades del tratamiento de datos personales. Mandar datos de tus clientes a un modelo de un tercero es un tratamiento que probablemente no estaba contemplado cuando se redactó ese aviso.

No soy abogado y esto no es asesoría legal: la recomendación concreta es que antes del piloto alguien revise si tu aviso de privacidad cubre lo que vas a hacer, y que la decisión quede por escrito. Es una conversación de una hora antes de empezar, o un problema mucho más caro después.

Como criterio de diseño, hay una regla que ahorra la mayoría de esas conversaciones: manda al modelo la menor cantidad de datos personales que permita hacer el trabajo. Muchas veces el caso de uso funciona igual con los datos anonimizados.

Por dónde empezar

Elige un proceso que cumpla las tres condiciones, mide lo que cuesta hoy, y ponle al piloto una fecha de corte y un criterio de éxito escrito antes de arrancar. Seis a ocho semanas.

Si al final el criterio no se cumplió, se cancela. Esa disciplina es lo que separa a las empresas del 5% del resto: no aciertan más, cierran antes lo que no funciona y liberan el presupuesto para la siguiente.

Si quieres que revisemos qué proceso tuyo es el mejor candidato, el diagnóstico inicial no tiene costo. También puedes ver cómo trabajamos la transformación con IA.

Preguntas frecuentes

¿Por dónde empiezo si no tengo experiencia con IA? Por un proceso que hoy hace una persona, que se repite muchas veces al mes y cuyo resultado alguien revisa de todas formas. Esas tres condiciones juntas te dan un caso donde el error es barato, el volumen justifica el esfuerzo y la calidad se puede medir desde el primer día.

¿Conviene construir o comprar? Comprar, salvo que el proceso sea tu diferenciador. El informe de MIT NANDA encontró que las alianzas externas llegan a despliegue cerca del 67% de las veces y los desarrollos internos cerca del 33%: el doble, no el triple que circula por ahí. El propio informe advierte que esa diferencia puede reflejar la capacidad de la organización y no el método. Construir tiene sentido cuando el proceso es la ventaja competitiva, no cuando solo quieres ahorrar la licencia.

¿Cómo sé si mis datos están listos? Haz la prueba concreta: toma diez registros al azar del proceso que quieres automatizar y revísalos a mano. Si más de dos tienen información incompleta, duplicada o contradictoria, el modelo va a amplificar eso. Primero se limpia.

¿Cuánto debería durar un piloto? Entre seis y ocho semanas, con criterio de éxito escrito antes de empezar. Un piloto sin fecha de corte no es un piloto: es un proyecto sin presupuesto aprobado que se va a arrastrar hasta que alguien se canse.