
El informe del Project NANDA del MIT Media Lab publicado en 2025 concluyó que, pese a entre 30.000 y 40.000 millones de dólares invertidos por empresas en IA generativa, el 95% de los pilotos no producía ningún retorno medible. Un año antes, Gartner ya había predicho que al menos el 30% de los proyectos de IA generativa se abandonarían después de la prueba de concepto antes de terminar 2025.
Yo he estado en ambos lados de esa estadística. Dirijo marketing e innovación en una red de más de 70 clínicas dentales, y eso significa implantar tecnología con equipos que no son técnicos, en sitios donde nadie tiene tiempo de aprender una herramienta nueva porque la sala de espera está llena. He tirado a la basura proyectos que en la demo funcionaban perfectamente. También tengo tres o cuatro cosas funcionando desde hace más de un año que ahorran horas reales cada semana.
La diferencia entre unos y otros no ha sido casi nunca la tecnología. Ha sido el proceso, la gente y la medición.
La respuesta corta: las implantaciones de IA no fracasan por el modelo, fracasan por cinco motivos previos al modelo. Se elige la herramienta antes que el problema. Se automatiza un proceso que ya estaba roto. No se mide el antes, así que no se puede demostrar el después. El piloto no escala porque nadie decidió qué haría falta para escalarlo. Y el equipo que hace el trabajo no participa, así que no lo usa. Arreglar esos cinco puntos te pone por delante del 95%.
Los diez errores, en una tabla
| # | Error | Síntoma de que lo estás cometiendo |
|---|---|---|
| 1 | Empezar por la herramienta | Se compró tras una demo o una conferencia y luego se buscó dónde encajarla |
| 2 | Automatizar un proceso roto | Ahora los errores llegan más rápido y en mayor cantidad |
| 3 | No medir el antes | Nadie sabe cuánto se tardaba antes, así que el ahorro es una opinión |
| 4 | El piloto eterno | Lleva meses "funcionando muy bien" en un solo equipo |
| 5 | Ignorar a quien hace el trabajo | El equipo lo usó dos semanas y volvió a lo de siempre |
| 6 | Subestimar el coste real | El presupuesto solo tenía la línea de licencias |
| 7 | No revisar la salida | Algo salió con un dato inventado y nadie lo detectó |
| 8 | Datos sucios o dispersos | Medio proyecto se ha ido en limpiar y unificar información |
| 9 | Sin política de uso ni formación | Cada uno usa la herramienta que quiere con los datos que quiere |
| 10 | Comprar por FOMO | La justificación real es que la competencia lo ha anunciado |
1. Empezar por la herramienta en vez de por el problema
Es el error madre y del que cuelgan casi todos los demás. Alguien vuelve de un evento, ve una demo espectacular, y de vuelta a la oficina la pregunta ya no es "qué problema tenemos" sino "dónde metemos esto".
Lo he hecho. Probé una herramienta de generación de contenido porque en la demo producía en segundos lo que a nosotros nos costaba horas. Tardé un mes en aceptar que nuestro cuello de botella nunca había sido escribir: era la aprobación clínica de cada pieza antes de publicarla. Producir el triple de borradores solo hizo la cola más larga. La herramienta era buena; resolvía el paso rápido de un proceso cuyo paso lento estaba en otro sitio.
La pregunta correcta no es "¿qué puede hacer la IA?", es "¿en qué se nos va el tiempo y cuál de esas cosas se repite igual todas las semanas?". Si no tienes esa respuesta escrita, no estás en condiciones de comprar nada.
2. Automatizar un proceso que estaba mal
Una frase que repito en cada reunión: automatizar el caos da caos, pero más rápido y en mayor volumen.
Si tu proceso de reclamación de documentación consiste en que tres personas mandan correos distintos sin criterio común, automatizarlo no lo arregla: multiplica los correos incoherentes. Si tu proceso de presupuestos depende de que alguien recuerde aplicar un descuento, automatizarlo va a fijar por escrito un error que antes al menos se corregía a mano.
Antes de automatizar nada, dibuja el proceso tal y como es de verdad, no como está en el manual. Casi siempre aparecen dos o tres pasos que directamente sobran. Eliminarlos suele dar más ahorro que la automatización, y es gratis. Cuando el proceso ya está limpio, la automatización rinde el doble. En cómo automatizar tareas con IA desarrollo el orden concreto.
3. No medir el antes, y por tanto no poder demostrar el después
Este es el error que más proyectos buenos ha matado, y duele porque es evitable con una hoja de cálculo y dos semanas de paciencia.
Sin línea base, la conversación final es siempre la misma. Dirección pregunta cuánto se ha ahorrado. Tú dices "muchísimo tiempo". Te piden un número. Improvisas. Alguien lo cuestiona. El proyecto muere, no porque no funcionara, sino porque no supiste demostrarlo.
Lo que hay que capturar antes de tocar nada, durante dos o tres semanas:
- Tiempo por unidad de trabajo. Minutos por factura, por informe, por respuesta.
- Volumen mensual. Cuántas de esas unidades pasan al mes.
- Tasa de error o de retrabajo. Cuántas hay que rehacer.
- Quién lo hace y cuánto cuesta su hora. Sin esto, el ahorro no se convierte en euros.
No hace falta nada sofisticado: un formulario y que la gente apunte. Si el equipo se niega a apuntar durante dos semanas, ahí tienes una señal temprana de que tampoco va a usar la herramienta.
4. El piloto eterno que nunca escala
El piloto va bien. Todos contentos. Y pasan seis meses.
Ocurre porque un piloto es cómodo: pequeño, con gente motivada, con atención directa de quien lo impulsa y sin que nadie mida su coste real. Escalar obliga a decidir presupuesto, formación, permisos, integraciones y responsables. Da pereza, así que el piloto se prorroga.
La regla que aplico ahora: todo piloto nace con fecha de defunción y criterio de escalado escrito. Cuánto dura (cuatro a ocho semanas suele bastar), qué número tiene que alcanzar y qué pasa si no lo alcanza. Y "si no lo alcanza" significa apagarlo, no "seguimos probando".
Un detalle que aprendí a base de errores: el piloto se hace en el sitio difícil, no en el fácil. Si lo pruebas con el equipo más motivado y mejor organizado, obtienes un resultado que no se va a repetir en ningún otro sitio. Nosotros probamos en una clínica de tamaño medio con rotación normal de personal, no en la que mejor funciona.

5. Ignorar a quien hace el trabajo
Si el equipo no lo usa, no existe. Da igual lo bien que funcione.
Y aquí va lo más importante que he aprendido en estos años: la resistencia del equipo casi nunca es cabezonería, es información. Cuando alguien que lleva ocho años haciendo una tarea te dice que la herramienta no le sirve, lo normal es que tenga razón en algo concreto que tú no habías visto.
Nos pasó con un asistente de respuesta automática para mensajes de pacientes. Funcionaba bien en las pruebas. En recepción lo abandonaron en dos semanas. La explicación, cuando por fin pregunté bien, era simple y nada emocional: el borrador que generaba había que revisarlo siempre, y revisar y corregir un texto ajeno les costaba más que escribir el suyo, que ya tenían medio memorizado. La herramienta no ahorraba tiempo en su flujo real. Tenían razón.
Tres cosas que sí funcionan:
- Meter a dos o tres personas del equipo desde el diseño, no desde la formación. Que elijan ellos qué parte se automatiza primero.
- Ser explícito con la pregunta que todo el mundo se hace y nadie formula: si esto ahorra tiempo, ¿sobra alguien? Si no lo respondes tú, se responde solo, y la respuesta que se inventan siempre es la mala.
- Que el primer caso de uso les quite un marrón, no que les añada un paso. La primera automatización que enganchó de verdad fue la que eliminaba la parte más odiada del cierre del día, no la que más horas ahorraba sobre el papel.
6. Subestimar el coste real
El presupuesto típico tiene una línea: licencias. El coste real tiene seis.
| Concepto | Lo que se presupuesta | Lo que cuesta de verdad |
|---|---|---|
| Licencias | El precio por usuario del plan visto en la web | Ese precio por los usuarios reales, no por los del piloto |
| Configuración inicial | "Una semana" | De cuatro a ocho semanas de alguien que ya tiene su trabajo |
| Integración con lo que ya tienes | Se da por incluida | Casi nunca lo está, y es la partida que más se dispara |
| Formación | Una sesión de una hora | Sesión inicial más refuerzo a los 30 días y material para los que entran nuevos |
| Mantenimiento | Cero | De dos a cuatro horas semanales de una persona con nombre y apellidos |
| Revisión de las salidas | Cero | Proporcional al volumen, y no baja a cero nunca |
Para dar referencias concretas: ChatGPT Business está en 20 dólares por usuario y mes con facturación anual, o 25 con facturación mensual, con un mínimo de dos usuarios, tras la bajada de precio de OpenAI de abril de 2026. Microsoft 365 Copilot cuesta 30 dólares por usuario y mes con contrato anual, y es un complemento: exige además una licencia base de Microsoft 365. Precios de agosto de 2026, y conviene comprobarlos porque en este mercado se mueven cada pocos meses.
Pero el coste que nadie presupuesta es el sexto y es el que decide la rentabilidad: alguien tiene que cuidar aquello. Si no hay una persona con nombre responsable de la herramienta, en seis meses estará desactualizada, con las excepciones sin resolver y con medio equipo trabajando por fuera de ella. He visto morir así más proyectos que por cualquier problema técnico.
7. Confiar en la salida de la IA sin revisión
Un modelo de lenguaje produce texto plausible, no texto verdadero. Es un matiz que en una lluvia de ideas no importa nada y en un documento con consecuencias lo cambia todo.
Dónde sale caro de verdad, por orden:
- Cualquier cosa con efectos legales o fiscales. En España ya hay sanciones: el Tribunal Superior de Justicia de Canarias multó en febrero de 2026 con 420 euros a un letrado por presentar un escrito con 48 citas de jurisprudencia falsas generadas por IA, y en julio de 2026 con 840 euros a otro por al menos 25 sentencias inventadas. El criterio del tribunal fue claro: la responsabilidad es siempre de quien firma.
- Cifras que van a un cliente o a un comité. Un modelo puede equivocarse en una aritmética de tres pasos con seguridad absoluta.
- Comunicación en nombre de la empresa. Un tono equivocado en un mensaje delicado hace más daño que el tiempo que ahorraste.
- Cualquier salida que entre en un sistema sin que la vea un humano. Es el caso más peligroso porque el error no se detecta hasta que ya ha viajado.
La regla operativa que uso: si la salida va a salir de la empresa o va a entrar en un sistema, la firma una persona. Y esa revisión se presupuesta como coste del proyecto, no como algo que se hace "de paso". El proyecto que solo es rentable si nadie revisa nada, no es rentable.
8. Datos sucios, dispersos o inaccesibles
Ninguna IA arregla datos malos. Los procesa igual de mal, pero más deprisa y con más aplomo.
Los síntomas: el mismo cliente aparece tres veces escrito de tres formas distintas, la información crítica vive en un Excel del portátil de alguien, dos sistemas dan cifras diferentes para lo mismo y nadie sabe cuál es la buena. En cuanto un proyecto de IA toca esos datos, se convierte en un proyecto de limpieza de datos disfrazado, con la mitad del presupuesto y ninguna de las expectativas ajustadas.
No hace falta arreglarlo todo antes de empezar: eso sería otra forma de no empezar nunca. Lo que sí hace falta es saber en qué estado están los datos del caso concreto que vas a automatizar y presupuestar la limpieza como parte del proyecto. Si el diagnóstico dice que están mal, tienes dos opciones honestas: limpiarlos primero, o elegir otro caso de uso.
9. Ni política de uso ni formación
Sin política de uso, lo que pasa es esto: la gente ya está usando IA. Con sus cuentas personales, en herramientas gratuitas, pegando lo que necesita pegar. Incluidos datos de clientes, condiciones de contratos y documentación interna.
Eso no se arregla prohibiéndolo, porque la prohibición solo consigue que deje de contarse. Se arregla con tres cosas concretas:
- Un plan de empresa en el que los datos no se usen para entrenar y con un encargo de tratamiento firmado. Es lo que convierte un riesgo de RGPD en un tratamiento documentado.
- Un folio de política de uso: qué se puede pegar y qué no, qué hay que anonimizar, qué salidas exigen revisión y quién responde. Un folio, no un manual de cuarenta páginas que nadie va a leer.
- Formación real y corta, con los documentos de la empresa, no con ejemplos genéricos. Una hora bien enfocada con casos propios rinde más que un curso de veinte. Lo desarrollo en formación en IA para empresas.
Añade el contexto normativo: las obligaciones de transparencia del artículo 50 del Reglamento Europeo de IA están en aplicación desde el 2 de agosto de 2026. Si tienes un chatbot atendiendo clientes o generas contenido sintético, esto te afecta y conviene revisarlo con quien lleve el cumplimiento.

¿Te preocupa el futuro con la IA?
Descubre cómo la inteligencia artificial ha liquidado las viejas reglas del juego y qué puedes hacer tú al respecto.
Leer más sobre el libro10. Comprar por FOMO
"La competencia ha anunciado que usa IA." Es la peor razón posible para gastar dinero, y es la razón real de buena parte del gasto en IA de los últimos dos años. El anuncio de un competidor no informa sobre lo que funciona: informa sobre lo que su departamento de marketing quiere que parezca. Muchos corresponden a pilotos que nunca escalaron y algunos a herramientas ya apagadas.
La prueba que uso en una reunión: pedir la métrica. Si la justificación se puede decir sin ninguna cifra —"nos hace más innovadores", "es el futuro", "los clientes lo esperan"—, es FOMO. Un proyecto legítimo se enuncia siempre igual: "esta tarea nos cuesta X horas al mes, creemos que podemos bajarla a Y, y lo sabremos en ocho semanas".
Cómo hacerlo bien: elegir el primer caso de uso
El primer proyecto no tiene que ser el más ambicioso. Tiene que ser el que se pueda demostrar. El objetivo del primero no es el ahorro: es ganar la credibilidad para hacer el segundo.
La fórmula que uso para priorizar es sencilla: frecuencia × tiempo × dolor, filtrada por riesgo. Puntúa del 1 al 5 cada criterio para cada candidato.
| Criterio | Pregunta | Qué puntúa alto |
|---|---|---|
| Frecuencia | ¿Cuántas veces al mes pasa? | Todos los días mejor que una vez al mes |
| Tiempo por vez | ¿Cuánto se tarda cada vez? | Cuanto más tiempo, más margen de mejora |
| Dolor | ¿Cuánto se odia esa tarea? | Lo que la gente detesta se adopta antes |
| Medibilidad | ¿Puedo medir el antes en dos semanas? | Si no se puede medir, no es el primero |
| Riesgo si falla | ¿Qué pasa si la salida es incorrecta? | Cuanto menor sea el daño, mejor para empezar |
| Datos disponibles | ¿La información está limpia y accesible? | Si hay que limpiar seis meses, no es el primero |
Puntúa a mano en una reunión de una hora con dos personas que hagan el trabajo. Gana el candidato con puntuación más alta, no el más vistoso. Casi siempre sale algo aburrido: clasificar correos, extraer datos de documentos, preparar borradores repetitivos. Perfecto. Lo aburrido es lo que se mide bien.
Después, cuatro pasos y ninguno se salta:
- Medir el antes durante dos o tres semanas. Tiempo, volumen, errores, coste por hora.
- Piloto de seis a ocho semanas en un entorno normal, no en el mejor, con criterio de éxito escrito de antemano.
- Decidir en la fecha acordada: escalar, ajustar una vez más, o matarlo. Matar un proyecto que no llega al número no es un fracaso, es la parte del método que hace que el resto funcione.
- Si escala, nombrar responsable y presupuestar mantenimiento. Sin esas dos líneas, escalar es solo posponer la muerte.
Si quieres el panorama de qué se puede automatizar y con qué herramientas, lo tengo en automatización con IA en empresas y en la guía general de IA para empresas.

Cuándo NO usar IA
Esta es la sección que casi ningún artículo del tema incluye, y es la que más me interesa. Hay situaciones en las que la respuesta correcta es no.
Cuando el volumen es bajo. Si una tarea ocurre cinco veces al mes, ninguna automatización se paga. El tiempo de configuración y mantenimiento se come el ahorro entero. Hazla a mano y dedica el esfuerzo a otra cosa.
Cuando el proceso cambia constantemente. Automatizar algo que se redefine cada dos meses significa reconfigurarlo cada dos meses. Estabiliza primero, automatiza después.
Cuando el error tiene consecuencias graves e irreversibles. Decisiones clínicas, jurídicas o financieras con impacto directo en una persona. La IA puede asistir, ordenar información y preparar borradores, pero la decisión y la firma son humanas. Y no por prudencia decorativa: porque la responsabilidad legal no se delega en un proveedor.
Cuando el valor del servicio es precisamente que lo hace una persona. Hay comunicaciones donde el hecho de que alguien haya dedicado tiempo es el mensaje. Automatizar la disculpa por un error, el seguimiento de una reclamación delicada o la felicitación a un cliente de quince años destruye exactamente lo que estabas intentando transmitir.
Cuando no puedes medir el resultado. Si no hay forma de saber si funciona, no lo hagas. Vas a estar seis meses discutiendo opiniones.
Cuando el problema real es organizativo. Si el equipo va desbordado porque falta gente o porque hay tres personas haciendo tareas duplicadas, la IA no lo arregla: lo tapa un trimestre y luego vuelve peor. Esto lo he visto suficientes veces como para ponerlo el último y en negrita: la tecnología no arregla problemas de organización, los hace más difíciles de ver.
Preguntas frecuentes
¿Por qué fracasan la mayoría de los proyectos de IA en empresas?
Porque se elige la herramienta antes que el problema, se automatiza un proceso que ya estaba mal, no se mide la situación de partida y no se involucra a quien hace el trabajo. El informe del MIT de 2025 cifró en el 95% los pilotos de IA generativa sin retorno medible, y el motivo dominante era de integración y proceso, no de calidad del modelo.
¿Cómo elijo el primer caso de uso de IA en mi empresa?
Puntúa los candidatos por frecuencia, tiempo por vez y dolor que causa la tarea, y descarta los que no puedas medir en dos semanas o cuyos datos estén sucios. Suele ganar algo aburrido y repetitivo, que es justo lo que conviene: lo aburrido se mide bien y demuestra el retorno.
¿Cuánto cuesta de verdad implantar IA en una empresa?
Las licencias suelen ser la partida menor. A los 20-30 dólares por usuario y mes de una herramienta como ChatGPT Business o Microsoft 365 Copilot hay que sumar de cuatro a ocho semanas de configuración, la integración con los sistemas existentes, la formación con refuerzo posterior y entre dos y cuatro horas semanales de mantenimiento de forma indefinida.
¿Qué hago si mi equipo se resiste a usar la IA?
Escúchalos antes de insistir: la resistencia suele ser información, no cabezonería. Lo habitual es que la herramienta no ahorre tiempo en su flujo real, o que nadie haya respondido a la pregunta de si el ahorro implica que sobra gente. Empieza por un caso que les quite una tarea odiada.
¿Cuánto debe durar un piloto de IA?
Entre cuatro y ocho semanas, con la fecha y el criterio de éxito acordados por escrito antes de empezar. Si al llegar la fecha no alcanza el número, se apaga. Los pilotos sin fecha de caducidad se convierten en proyectos zombis que consumen atención durante años.
¿Hace falta una política de uso de IA aunque seamos pocos?
Sí, y cabe en un folio: qué se puede pegar en una herramienta y qué no, qué hay que anonimizar, qué salidas exigen revisión humana y quién responde. Sin ella, el equipo ya está usando herramientas gratuitas con datos de clientes, solo que sin contarlo.
¿Es obligatorio avisar de que un contenido o un chatbot usa IA?
Las obligaciones de transparencia del artículo 50 del Reglamento Europeo de IA están en aplicación desde el 2 de agosto de 2026 y afectan a sistemas que interactúan con personas y a determinados contenidos sintéticos. Si tienes un chatbot atendiendo clientes, revísalo con quien lleve el cumplimiento normativo.
¿Cuándo no merece la pena usar IA?
Cuando el volumen es bajo, cuando el proceso cambia cada pocas semanas, cuando un error tiene consecuencias graves e irreversibles, cuando el valor del servicio está precisamente en que lo haga una persona, o cuando el problema de fondo es organizativo. En ese último caso la IA solo tapa el síntoma durante un trimestre.
Inteligencia Artificial aplicada a negocio
Sin humo. Solo experimentos reales, prompts que funcionan y estrategias de escalabilidad.






