Cómo aplicar IA en una empresa real sin humo: la guía honesta

TL;DR

Aplicar IA en una empresa real sin humo es elegir un caso de uso medible, atacarlo con tecnología que ya existe, medir lo que ahorra de verdad y escalar solo lo que funciona; no es presentar un PowerPoint con la palabra “transformación” repetida treinta veces. El 78% de las empresas dice usar IA, pero solo el 6% ve impacto financiero serio. La diferencia no está en el modelo, está en quién decide qué hacer y quién mide el resultado. En este artículo te cuento, sin filtros, lo que hago yo en Datalvar AI, los errores que cometí, los proyectos que no funcionaron y los criterios que uso ahora para distinguir un caso real de uno con humo.

¿Por qué la mayoría de proyectos IA en empresa no llegan a producción?

Llevo desde 2023 metido a tiempo completo en proyectos de IA aplicada en empresa media, y la conclusión a la que he llegado después de bastantes reuniones, propuestas y pilotos es bastante incómoda: la mayoría no llega a producción. Y no porque la tecnología no esté lista, sino porque el proyecto nunca debió arrancarse así. McKinsey publicó en 2025 que el 88% de las organizaciones usan IA de forma regular, pero solo el 6% ven impacto a nivel EBIT. Esa brecha de 82 puntos es donde vive todo el humo de la industria.

Cuando aterrizo en una empresa para hablar de IA, lo primero que veo casi siempre es lo mismo. Hay un comité, un consultor que ha hecho una presentación, un piloto en marcha en alguna área que el director financiero no termina de entender, y un CEO que oye hablar de IA en sus cenas y siente que llega tarde. El problema no es la IA. El problema es que el proyecto nació mal: sin caso claro, sin métrica clara y sin alguien que se la juegue con el resultado. Cuando eso pasa, la IA se convierte en otro pet project más que sobrevive seis meses antes de morir en silencio.

Mi tesis después de varios fracasos propios y muchos ajenos es esta: aplicar IA en una empresa real sin humo no es un problema técnico, es un problema de gobierno. Las empresas que sí lo hacen bien no tienen modelos mejores, ni más datos, ni mejor infraestructura; tienen a alguien con autoridad real que ha elegido un caso concreto, ha puesto presupuesto para construirlo de verdad y mide trimestre a trimestre. Lo demás es ruido. Si te quedas con una idea de este artículo, quédate con esa: la diferencia entre un proyecto IA con humo y uno real es quién firma y quién mide.

¿Qué dice el dato y qué dice mi experiencia?

El AI Index 2025 de Stanford HAI deja números brutales: el 78% de las organizaciones usaron IA en al menos una función de negocio en 2024, frente al 55% el año anterior. Adopción brutal en 12 meses. Pero el mismo informe dice que el coste de inferencia ha caído un 99,6% en dos años. Es decir: el problema ya no es el modelo ni el coste. El problema es decidir bien y ejecutar bien. Lo que era caro y exclusivo en 2022 es commodity en 2026. Lo que escasea ahora es criterio.

Lo que veo yo en la trinchera coincide con esos datos. En 2024 firmamos diez proyectos en Datalvar AI. Dos funcionaron rotundamente y siguen creciendo. Cuatro funcionaron a medias, con ahorro modesto pero real. Tres se atascaron en validaciones internas y los hemos tenido que reactivar de cero este año. Uno lo cancelamos nosotros porque el cliente no tenía la organización lista. Esa estadística personal —20% éxito rotundo, 40% éxito modesto, 30% atasco, 10% cancelación— es bastante parecida a lo que oyes en privado en cualquier corrillo de consultores honestos. Lo que pasa es que en LinkedIn solo cuentan el 20% que funcionó.

Quien te diga que sus proyectos IA salen al 100% miente o no ha hecho proyectos serios. Es así de simple. La IA aplicada en empresa real no es un copy-paste; es una intervención organizativa con tecnología, y en cualquier intervención organizativa, las cosas se rompen. Aceptarlo de entrada cambia cómo presupuestas, cómo escalas y a quién mandas la factura. Si me contratas creyendo que esto es enchufar GPT y ya, no aceptaré el proyecto.

¿Cuál es el patrón que distingue lo que llega a producción?

Después de analizar mis propios proyectos y los que veo en clientes externos, hay un patrón que se repite en los que sí escalan. Primero, tienen un sponsor con autoridad ejecutiva real (no un mando intermedio enviado a “explorar”). Segundo, tienen un caso de uso con baseline numérico medible antes de empezar. Tercero, el equipo técnico y el equipo de negocio están en la misma sala desde la semana uno. Cuarto, hay un compromiso de seis a doce meses, no un piloto de seis semanas. Quinto, hay paciencia para iterar dos o tres veces el prompt, el flujo o el modelo. Cuando faltan tres de esas cinco condiciones, el proyecto está muerto antes de empezar.

Mi regla de oro tras dos años: si el sponsor no puede decirme en una frase qué métrica va a mover y cuánto, no arranco el proyecto. Da igual lo bonito que esté el PowerPoint, da igual el presupuesto. Sin métrica clara firmada por quien manda, eso no es un proyecto IA: es una excursión.

Y hay un patrón inverso, igual de claro, en los proyectos que mueren: el “vamos a hacer un piloto pequeño para ver”, la falta de baseline previa, el equipo técnico contratado externamente sin contraparte interna, la presentación a comité cada dos semanas que paraliza la iteración, y la palabra “transformación” usada más de tres veces en la primera reunión. Cuando veo eso, sé que es humo. A veces lo digo, a veces me callo y cobro la factura. Cada vez digo más.

El humo más caro: la “transformación digital con IA” sin caso claro

El producto más vendido del mercado en 2025 y 2026 se llama “transformación digital con IA” y es, en el 90% de los casos, humo facturable. No estoy diciendo que la transformación no exista; estoy diciendo que vendérsela a una PYME o a una empresa media de 200 personas como un paquete cerrado de 80.000 a 300.000 euros, sin caso de uso concreto, es estafa intelectual aunque sea legal. Y lo veo todos los meses. Empresas que han pagado por un “diagnóstico de madurez digital” lleno de matrices y benchmarks y que, seis meses después, no han movido una sola métrica.

El patrón es muy reconocible. Llega una consultora grande o mediana, hace un workshop de dos días, presenta una “hoja de ruta IA” con quince iniciativas priorizadas en un mapa de calor, recomienda un “centro de excelencia IA” con tres personas a tiempo completo, y se va con la factura. Lo que queda en la empresa son tres slides, dos hojas de Excel y mucha gente reunida sin saber qué hacer el lunes. Cuando me llaman a recoger esos restos, lo primero que hacemos es tirar el documento entero y empezar por una pregunta de tres palabras: ¿qué duele más? Porque aplicar IA en una empresa real sin humo empieza por elegir dolor concreto, no por dibujar mapas.

Mi opinión, abiertamente contrarian: los “centros de excelencia IA” en empresa media son, mayoritariamente, mecanismos para que nadie tenga que rendir cuentas. Si la IA es responsabilidad de un equipo transversal de cuatro personas que no manda en ninguna unidad operativa, no va a pasar nada. Lo que funciona es lo contrario: la IA es responsabilidad de la persona que dirige el área donde duele —operaciones, atención al cliente, ventas, finanzas— y el equipo técnico está a su servicio. Cuando inviertes el organigrama, los proyectos se mueven. Cuando no, no.

¿Qué frases delatan al vendor de humo?

He hecho una colección personal de frases que, cuando las oigo en una primera reunión, me dicen casi todo lo que necesito saber del proyecto. No son infalibles, pero son una señal muy fuerte. Te las dejo aquí porque te van a ayudar a filtrar:

• “Vamos a hacer un piloto pequeño para ver” (sin métrica, sin baseline).
• “Hay que crear un copiloto interno” (sin decir qué tarea concreta acelera).
• “Necesitamos una estrategia IA holística” (la palabra holístico es bandera roja).
• “Empezamos con casos de uso de baja complejidad” (eufemismo de no hacer nada relevante).
• “Vamos a montar un GPT propio” (cuando ChatGPT Enterprise haría el 90% del trabajo).
• “Necesitamos primero formar a todo el mundo en IA” (cuando lo urgente es elegir un caso).

Lo que tienen todas estas frases en común es que aparentan rigor pero esconden ausencia de decisión. Suenan bien en un comité, no comprometen a nadie y permiten facturar formación, talleres y diagnósticos durante meses. Si quien te vende IA usa más de dos de estas frases en la primera hora, considera levantarte de la mesa. O al menos, pide un caso concreto con métrica y plazo antes de firmar.

¿Por qué el humo se paga tan caro?

Porque cumple una función organizativa. Comprar “transformación IA” a una consultora grande le sirve al CEO para enseñar al consejo que se está haciendo algo. Le sirve al CIO para no quedar atrás. Le sirve al director financiero porque es una partida grande pero predecible. Y le sirve al consultor porque factura mucho con poco riesgo de resultado, dado que el resultado nunca se midió de verdad. Es una compra simbólica, no operativa. Y como tal, su utilidad es simbólica. Lo que no es es aplicar IA en una empresa real.

Cuando empecé en esto cobraba menos y aceptaba estos proyectos. Hoy directamente no firmo si no hay un caso concreto y un sponsor con autoridad. He perdido facturación por esa decisión, pero he ganado algo más valioso: dormir tranquilo sabiendo que los proyectos que firmo tienen razonable probabilidad de funcionar. Y los que no, los devuelvo. Esa selección dura te la tienes que aplicar tú también si eres quien compra: si el vendor IA no te puede decir qué métrica va a mover y cuánto, no lo contrates aunque sea barato.

¿Cómo distinguir un proyecto IA con humo de uno real?

Aquí te dejo la tabla que llevo en la cabeza cuando me reúno con un cliente potencial o cuando reviso una propuesta interna. La uso casi como una checklist mental. Si un proyecto cae mayoritariamente en la columna izquierda, lo más probable es que no llegue a producción. Si cae en la derecha, tiene opciones reales de salir bien.

Te doy un ejemplo para que se vea bien. En 2025 nos llegaron dos oportunidades casi en la misma semana. La primera: una empresa industrial de 400 personas pidiendo “estrategia IA corporativa” con presupuesto generoso pero sin caso concreto. La segunda: una empresa de servicios de 80 personas pidiendo “reducir tiempo de respuesta del back-office en facturación” con dolor claro y métrica obvia (37 minutos de media por ticket, querían bajar a 10). Acepté la segunda. Decliné la primera. La segunda lleva nueve meses en producción ahorrando dinero. La primera, según he sabido por terceros, va por el segundo cambio de consultora y todavía no ha movido una métrica. Esa es la diferencia.

Si el vendor IA no te puede decir, en la primera hora, qué métrica vas a mover, en cuánto, en qué plazo y cómo lo mediréis, vete. No es que el vendor sea malo necesariamente, es que el proyecto no está pensado. Y un proyecto IA no pensado es dinero quemado, con o sin buen vendor.

¿Qué señales delatan al proyecto que sí va a llegar?

El proyecto que sí llega tiene unas señales muy claras desde la primera reunión. Hay alguien del lado del cliente que se sienta y habla en concreto: “tenemos este flujo, cuesta esto, queremos bajarlo a esto, esta es la persona del área que estará pegada al proyecto, este es el calendario”. No hay PowerPoint, hay un Excel con datos del proceso actual. No hay buzzwords, hay nombres de campos del CRM y volúmenes mensuales. No se habla de “agentes” en abstracto, se habla del ticket-tipo y del 80% de los casos que se podrían automatizar.

Cuando empieza así, sé que vamos a llegar a producción. Puede que tardemos más de lo previsto, puede que cambiemos el enfoque técnico a mitad, puede que el primer modelo no funcione y haya que probar otro. Pero llegamos. Porque hay un dolor identificado, un dueño identificado y una métrica identificada. Lo demás es ingeniería, y la ingeniería en 2026 es razonablemente accesible: APIs maduras, frameworks consolidados, costes de inferencia que han caído más del 99% en dos años según Stanford HAI. El cuello de botella no es técnico, casi nunca lo es.

Cuando empieza con “necesitamos una estrategia”, “vamos a explorar”, “queremos entender qué es posible”, sé que estamos en territorio de humo. No quiere decir que sea mala gente; suele ser gente honesta y curiosa que no sabe lo que no sabe. Pero a esa gente no le puedes vender un proyecto IA, le tienes que vender primero claridad sobre qué duele en su empresa. Y eso no se hace con un workshop genérico, se hace sentándote con sus operativos y mirando datos reales del CRM o del ERP durante una semana. Cuando lo haces, el caso de uso aparece solo.

¿Qué caso de uso elegir primero (criterios honestos)?

Esta es la pregunta más importante de todo el artículo, y la que peor se contesta en el mercado. Casi todos los frameworks que circulan por LinkedIn dicen lo mismo: “empieza por algo de bajo riesgo y alto impacto”. Gracias, capitán obvio. El problema es cómo identificas, en tu empresa concreta, qué es “bajo riesgo y alto impacto”. Te dejo los criterios que uso yo, en este orden, y que me han funcionado en proyectos muy distintos.

Primer criterio: dolor real y cuantificable. No me sirve “perdemos tiempo en reuniones”. Sí me sirve “el equipo de back-office tarda una media de 37 minutos en procesar una factura compleja y procesamos 1.200 al mes”. Si el dolor no se puede traducir a horas, errores, dinero o casos por mes, no es un buen caso para empezar. Es ruido. Cuando empiezas por un caso con métrica clara, sabes desde el día uno si estás avanzando o no.

Segundo criterio: frecuencia. Prefiero un caso que se ejecute 1.000 veces al mes con un ahorro de 5 minutos cada vez (83 horas al mes) que un caso que se ejecute 10 veces al mes con un ahorro de 4 horas cada vez (40 horas al mes). No solo por el ahorro absoluto, sino porque la frecuencia te da datos. Con 1.000 ejecuciones al mes puedes iterar el sistema rápido, ver errores, medir mejoras. Con 10 ejecuciones al mes, te quedas ciego mucho tiempo. La IA aprende y mejora cuando hay volumen para medirla.

Tercer criterio: tolerancia al error. Hay procesos donde un 5% de error es aceptable porque hay revisión humana en otro punto del flujo. Hay procesos donde un 0,1% de error te lleva a un problema regulatorio. Empezar por casos con tolerancia razonable al error te permite poner el sistema en producción mucho antes y aprender. Empezar por casos crítico-regulatorios (cumplimiento, sanitario, financiero formal) te condena a meses de QA antes de ver el primer euro de ahorro.

¿Cuáles son los casos de uso que sí funcionan en empresa media?

Después de dos años haciendo esto, aquí están los casos donde casi siempre veo retorno claro en empresa media (de 50 a 500 personas):

• Triaje y respuesta inicial de correos y tickets entrantes (operaciones, atención cliente, back-office administrativo).
• Extracción de datos estructurados desde documentos no estructurados (facturas, contratos, formularios, certificados).
• Generación asistida de propuestas comerciales y documentos a partir de plantillas y datos del CRM.
• Resúmenes automáticos de reuniones, llamadas grabadas y correos largos con acciones extraídas.
• Búsqueda interna conversacional sobre documentación corporativa (RAG sobre intranet, manuales, procedimientos).
• Clasificación y enrutamiento automático de leads, candidatos o solicitudes.
• Asistentes especializados internos para equipos concretos (legal, RRHH, soporte técnico, marketing operativo).

Estos son casos probados, con tecnología madura, donde no estás inventando nada raro. Si tu primer caso no está en esta lista o muy cerca, sospecha. No porque la lista sea exhaustiva, sino porque empezar por algo fuera del set probado multiplica el riesgo de proyecto y reduce las probabilidades de éxito. Tiempo habrá de hacer cosas más raras cuando ya tengas un caso funcionando en producción y el equipo haya aprendido a operar IA.

¿Qué casos veo demasiado y casi nunca funcionan?

Hay un grupo de casos que se proponen en cada propuesta de “transformación IA” y que casi nunca llegan a producción con ROI claro. Te los enumero para que los detectes:

• “Asistente IA para clientes finales” en empresas que no tienen volumen brutal de soporte (debajo de 10.000 tickets/mes es difícil que compense vs sistemas más simples).
• “Predicción de churn con IA” cuando ni siquiera tienen la data básica de uso bien estructurada.
• “Generación automática de contenidos creativos” sin proceso editorial claro.
• “Análisis de sentimiento de redes sociales” sin que nadie vaya a usar el output para tomar decisiones.
• “Modelos predictivos a medida” en empresas sin equipo de ciencia de datos para mantenerlos.
• “Visión artificial para detectar X” cuando el proceso humano actual ya funciona razonablemente bien.

No es que estos casos no se puedan resolver con IA; es que en el contexto de una empresa media sin equipo IA propio, suelen ser proyectos caros, lentos y de retorno incierto. Hay empresas grandes y nichos donde sí tienen sentido, pero como primer caso de uso en una empresa media son malísima opción. Lo que veo es que se eligen porque suenan ambiciosos, no porque sean los más rentables. Y elegir por ambición sonora en lugar de por probabilidad de éxito es el error número uno cuando hablamos de aplicar IA en una empresa real sin humo.

¿Cuánto cuesta de verdad y cuánto se ahorra de verdad?

Este apartado va a parecer aburrido, pero es donde se separa la gente seria de la gente que vende humo. Las cifras que te doy son rangos que veo en proyectos reales, no medias de mercado glamorosas. Una empresa media que quiere implementar un caso de uso IA serio, en producción, con integración con sus sistemas, suele moverse en estos rangos: implementación inicial entre 15.000 y 80.000 euros, dependiendo de complejidad e integraciones; coste operativo mensual entre 200 y 3.000 euros (modelos, infraestructura, herramientas); mantenimiento y mejora continua entre 1.000 y 4.000 euros al mes durante al menos los primeros seis meses post-lanzamiento.

Te dejo una tabla con casos típicos para que tengas referencias. Son rangos reales que firmamos en proyectos de los últimos 12 meses, no inventos de Excel.

Lo que NO te digo aquí, y casi nadie cuenta, es lo que cuesta el cliente. Cuando implantas un sistema IA en una empresa, hay un coste interno del cliente que no aparece en factura pero existe: tiempo del sponsor (50-150 horas en los primeros 3 meses), tiempo de los operativos que entrenan el sistema y revisan outputs iniciales (otras 80-200 horas), tiempo de IT para integraciones (60-120 horas) y tiempo de change management que casi siempre se subestima (entre 50 y 200 horas dependiendo del tamaño del equipo afectado). Eso a sueldos brutos cargados son entre 10.000 y 40.000 euros adicionales que no aparecen en ninguna propuesta pero que tienes que asumir. Si no asumes ese coste, el proyecto no funciona.

¿Por qué casi nadie cuenta los costes reales?

Por dos razones. La primera, comercial: si cuentas todo lo que cuesta de verdad un proyecto IA en empresa, muchos clientes no lo arrancarían. La segunda, técnica: la mayoría de quienes venden no han operado el sistema más de seis meses, así que ni siquiera saben cuánto cuesta mantenerlo. Hay un sesgo brutal en este sector hacia el “look at this demo” y muy poca conversación sobre “look at this system in production 18 months later”. La fase de operación es donde el dinero se queda o se va, y casi nadie habla de ella.

Mi recomendación si vas a comprar IA: pide al vendor referencias de proyectos en producción con más de 12 meses, no demos. Pide hablar con el cliente final, no con el consultor que lo lideró. Pregunta cuánto se ha gastado en mantenimiento mensual, cuántas veces ha habido que reentrenar o cambiar el modelo, cuántos incidentes ha habido en producción y cómo se resolvieron. Si el vendor no puede contestar a eso con casos reales, no ha operado IA en producción nunca. Y si no ha operado, lo que te va a vender es humo bien envuelto.

¿Qué ROI honesto puedes esperar?

Aquí va lo más impopular del artículo. El ROI honesto de un proyecto IA bien hecho en empresa media, en el primer año, suele estar entre el 100% y el 300%. Es decir, por cada euro que metes (incluyendo costes ocultos), recuperas entre 2 y 4 al cabo de 12 meses. No es magia, no es 10x, no es transformacional. Es buen ROI para un proyecto de software interno, pero no es el ROI que prometen las consultoras en sus decks. Y a partir del segundo año, cuando el sistema ya está pagado y solo queda el coste operativo, el ROI sí se dispara (suele pasar de 5x a 10x acumulado).

Las casuísticas extremas existen. Hay proyectos IA donde el ROI ha sido del 1000% en seis meses; los he visto en casos muy concretos de procesos masivos. Y hay proyectos donde el ROI ha sido negativo durante todo el primer año porque el sistema no funcionó como se esperaba y hubo que rehacerlo. Lo que importa no es la anécdota extrema, importa la media razonable: si planificas tu inversión asumiendo 2x-4x en año uno y 5x-10x en año dos, vas a tomar decisiones sensatas. Si planificas asumiendo el 10x del primer año del unicornio del LinkedIn de turno, vas a tomar decisiones malas.

¿Por qué los pilotos exitosos no escalan?

Esta es una de las preguntas más frustrantes del sector y donde más he aprendido a base de tropiezos. Llevas un piloto IA durante tres meses, sale razonable, métricas decentes, el equipo está contento, presentas resultados al comité y… no escala. Lo intentas con el siguiente departamento y se atasca. Lo intentas con otra unidad y se complica. El piloto se queda como una isla, no como punto de partida. McKinsey lo llama “the scaling gap” y le ha dedicado bastante espacio en su informe 2025.

Por qué pasa esto, en mi experiencia, son tres razones combinadas. Primera: el piloto se hizo en condiciones especiales (con un equipo motivado, con datos limpios, con un sponsor implicado) que no se replican fácilmente en otras áreas. Cuando intentas trasladarlo a otra unidad, te encuentras con datos sucios, equipo menos receptivo, sponsor menos comprometido, y lo que funcionó en el piloto no funciona ahí. La conclusión equivocada es “la IA no escala”. La conclusión correcta es “el modelo de implantación no escala”.

Segunda razón: no se ha invertido en las capas que permiten escalar. Cosas como un sistema de monitoreo de calidad de outputs, un proceso de gobierno de prompts y modelos, una documentación operativa para que otros equipos puedan usar el sistema, una capa de integración estándar con CRM/ERP. Sin esa “fontanería” invisible, cada nuevo despliegue es un proyecto desde cero. Los pilotos que sí escalan son los que, además de hacer el piloto, invirtieron desde el día uno en la fontanería de plataforma.

Tercera: el cambio organizativo no se gestionó. La IA cambia cómo trabaja la gente. Si el piloto se hizo con un equipo voluntario entusiasta, escalarlo significa enfrentar resistencia real en equipos menos receptivos. Si no hay un esfuerzo explícito de comunicación, formación y acompañamiento, el segundo despliegue va a fracasar por razones humanas, no técnicas. Y casi nadie planifica esto. Casi todos los presupuestos IA infraponderan el change management.

¿Qué hacen las empresas que sí escalan?

He estado en suficientes proyectos para ver el patrón. Las empresas que escalan IA con éxito hacen tres cosas que las que se atascan no hacen. Primero, desde el segundo proyecto invierten en plataforma compartida: un único stack de modelos, una única capa de integración, un único sistema de monitoreo. Segundo, crean un pequeño equipo central (2-5 personas) que es el “platform team” de IA, separado de los equipos de producto que usan IA. Tercero, mantienen el ownership de cada caso de uso en el negocio, no en el equipo central; el platform team da herramientas, el negocio decide qué construir.

Esto es lo opuesto al “centro de excelencia IA” que vende humo. El platform team no decide casos de uso, no audita iniciativas, no aprueba o desaprueba; solo construye y mantiene las herramientas que el negocio usa. Es un modelo de ingeniería de plataforma, no de comité. Cuando funciona bien, en menos de un año tienes cinco o seis casos de uso en producción, cada uno con su dueño de negocio, y un equipo central muy pequeño dándoles soporte técnico. Eso es escalado real, no aspiración.

Si en tu empresa el equipo IA decide qué proyectos hacer, lo estás haciendo al revés. El equipo IA debería ser un proveedor interno de herramientas y conocimiento, y los proyectos los deberían decidir los dueños de las áreas que los van a usar y medir. Cuando el centro decide, la IA se queda en piloto. Cuando deciden los operativos con dolor real, la IA llega a producción.

¿Por qué la mayoría de proyectos se atascan en el segundo año?

Otro patrón que veo: muchos proyectos funcionan bien el primer año y se atascan el segundo. La razón suele ser que el modelo o el sistema necesita una segunda iteración seria (porque el mundo cambió, porque el volumen creció, porque los datos evolucionaron) y nadie ha presupuestado esa iteración. Se asumió que la IA “funcionaba sola” y no se previó el coste de mantenimiento serio. Cuando llega el momento de la actualización, no hay presupuesto, el sistema empieza a degradarse, los usuarios pierden confianza y el proyecto entra en espiral.

Mi recomendación es presupuestar desde el inicio un 20-30% del coste de implementación inicial como gasto recurrente anual de mejora y mantenimiento. Así, si la implementación costó 40.000 euros, se reservan 8.000-12.000 al año para mantenimiento serio (no solo para pagar APIs, también para revisar prompts, ajustar flujos, monitorear calidad y actualizar componentes cuando los proveedores cambian sus modelos). Esto se parece más a cómo se presupuesta software corporativo serio que a cómo se presupuesta una novedad. La IA en producción es software corporativo, no un experimento.

¿Cómo distinguir un vendor IA honesto de uno comercial?

Aquí va una de las secciones más útiles, creo, para quien está al otro lado de la mesa. Si vas a contratar IA para tu empresa y no sabes quién es honesto y quién no, te pongo los criterios que yo aplicaría si tuviera que comprar y no tuviera mi propio equipo. Son los criterios por los que querría ser evaluado yo cuando vendo.

Esa última fila es la que más uso como termómetro personal. Un vendor IA honesto desactiva el hype, no lo amplifica. Si me dice “no sé si esto funcionará, vamos a hacer la fase 1 y veremos”, es buena señal. Si me dice “esto es transformacional y va a cambiar tu empresa”, es mala señal. La incertidumbre honesta sobre un proyecto técnico complejo es signo de madurez. La certeza absoluta vendida en una primera reunión es signo de comercial agresivo.

¿Qué preguntas tendría que hacerte cualquier vendor IA serio?

Cuando alguien te quiere vender IA, debería hacerte estas preguntas en la primera o segunda conversación. Si no las hace, es que no le interesa entender tu negocio, le interesa cerrar el contrato. Te las enumero para que las uses como filtro:

• ¿Qué proceso concreto te duele más hoy y por qué?
• ¿Tienes números actuales del coste de ese proceso (tiempo, errores, dinero)?
• ¿Quién dentro de la empresa se va a sentar a trabajar con nosotros y tiene autoridad para decidir?
• ¿Qué pasaría si esto no funciona en el primer intento?
• ¿Cuál es el plan para mantener este sistema cuando lleve 18 meses en producción?
• ¿Tu equipo IT está preparado para integrar y mantener este tipo de sistema?
• ¿Hay procesos regulatorios o de compliance que afecten a este caso?

Si yo te quisiera vender IA y no te hago estas preguntas, despídeme antes de firmar. Estas preguntas no son opcionales, son lo mínimo para hacer una propuesta seria. Cuando alguien viene con propuesta cerrada sin haber hecho estas preguntas, esa propuesta está vacía. Y firmar propuestas vacías es la forma número uno de quemar dinero en IA corporativa.

¿Cómo distinguir al “experto IA” real del que improvisa?

Hay un fenómeno muy 2025-2026 que es la explosión de “expertos IA” recién aterrizados que ayer eran community managers y hoy venden estrategias IA. No es maldad necesariamente, es oportunismo de mercado. Pero el daño que hacen es real. Cómo distinguir al experto real: pídele que te enseñe sistemas en producción que él haya construido (no demos, no prototipos, no Notion bonitos), pídele que te explique un fracaso suyo con detalle técnico, pídele que te diga qué modelos usa para qué casos y por qué (no “uso GPT-4” sin más), pídele que te enseñe cómo monitorea calidad en producción.

El experto real responde a todo eso sin pestañear y con humildad. El que improvisa se enreda, generaliza, se va por las ramas o pivotea hacia “es que cada caso es único”. Cuidado con “cada caso es único” cuando lo usan para evadir preguntas concretas. Cada caso tiene matices, pero los principios son comunes y un experto los conoce. Si no los conoce, no es experto, es comercial con vocabulario.

Lo que veo en empresas que sí lo hacen bien

Después de meterme en bastantes empresas distintas (industria, servicios profesionales, distribución, financiero, salud), hay un puñado de cosas que se repiten en las que sí están sacando valor real de la IA. No son las más sofisticadas técnicamente, ni las que tienen más presupuesto, ni las que han contratado a la consultora más cara. Son las que comparten una cierta cultura operativa que voy a intentar describir.

Primero, son empresas con una cultura de medición. No hablan de IA con métricas vagas; hablan con números concretos del proceso afectado y comparan antes y después con honestidad. Cuando hago la primera reunión con ellos, ya tienen los números de su proceso, no tienen que pedirlos al equipo. Esa madurez de medición es la base sobre la que se sostiene cualquier proyecto IA serio. Sin medición previa, la IA es fe.

Segundo, son empresas donde el operativo del proceso afectado tiene voz real. No es un proyecto IT que aterriza en el equipo desde arriba; es un proyecto donde quien hace el trabajo dice qué le ayuda y qué no, y se ajusta el sistema en función de su feedback. Esto suena obvio, pero la cantidad de proyectos IA que se diseñan sin hablar con quien hace el trabajo es asombrosa. Y luego sorprende que no se adopten.

Tercero, son empresas que aceptan que la primera versión no será la última. Lo presupuestan así, lo comunican así internamente, lo planifican así. No esperan que el sistema funcione perfecto desde el día uno; esperan iterar tres o cuatro versiones en los primeros seis meses. Esa aceptación del proceso iterativo es lo que separa los proyectos que llegan a estado estable del que se abandonan tras el primer tropezón.

¿Qué cultura organizativa hace falta para que la IA funcione?

Si tuviera que resumir la cultura de una empresa que aplica IA bien, diría que es una empresa que ya tomaba decisiones con datos antes de oír hablar de IA. La IA no transforma una cultura ad hoc en una cultura basada en datos; amplifica la cultura que ya hay. Si en tu empresa las decisiones se toman por intuición y nadie mide nada, la IA va a producir resultados borrosos que nadie podrá interpretar. Si en tu empresa ya hay reflejo de medir antes y después, la IA va a producir mejoras que se podrán cuantificar y por tanto escalar.

Por eso, mi recomendación impopular: si la empresa no tiene cultura de datos, antes de meter IA hay que meter cultura de datos. Tres a seis meses de instaurar disciplinas básicas de medición de procesos clave, cuadros de mando reales, revisión periódica de métricas, antes de gastar un euro en IA. No es glamouroso, no se vende bien en una propuesta, pero es lo que hace que después la IA funcione. Y lo dice alguien que vive de vender IA. Aplicar IA en una empresa real sin humo empieza, a veces, por no aplicar IA todavía.

¿Qué rol tiene el CEO en todo esto?

El rol del CEO en proyectos IA es crítico y casi siempre mal entendido. El CEO no tiene que entender los detalles técnicos. No tiene que saber qué es un LLM, qué es RAG, qué es fine-tuning. Lo que tiene que hacer es tres cosas concretas: asignar autoridad clara a alguien con P&L para los proyectos IA, presupuestar honestamente incluyendo costes ocultos, y proteger a los equipos del ruido externo durante las fases de iteración. Si el CEO hace eso, la IA tiene posibilidades. Si el CEO se mete en el detalle técnico o no protege a los equipos, la IA se queda en humo.

He visto CEOs muy técnicos que sabotean sus propios proyectos IA por meterse demasiado y CEOs muy de negocio que los catapultan por dar autonomía total a quien lidera y proteger el espacio. La diferencia no está en el conocimiento técnico del CEO, está en su capacidad de delegar con autoridad real. Cuando delegas autoridad real, las cosas pasan. Cuando delegas autoridad parcial vigilada de cerca, las cosas no pasan.

Errores caros que cometí o vi en clientes

Toca confesar. Algunos errores los he cometido yo en Datalvar AI, otros los he visto en clientes externos donde he aterrizado después del fracaso. Los pongo aquí sin filtros porque creo que es la mejor forma de demostrar que aplicar IA en una empresa real sin humo es difícil y se aprende a base de tropezar. Si alguien te dice que su track-record es perfecto, miente o ha hecho pocos proyectos.

Error uno, mío: vender un proyecto IA a un cliente que no tenía cultura de datos. El proyecto técnicamente funcionaba; entregamos un sistema decente. Pero el cliente no podía medir si estaba mejorando o no porque su proceso previo no estaba medido. El sistema se quedó en producción seis meses sin que nadie supiera si valía la pena, hasta que un cambio de prioridades lo apagó. Lo aprendí: si el cliente no mide antes, no firmes. Antes de firmar pídeles números concretos del proceso actual. Si no los tienen, hazles un trabajo previo de medición antes de meter IA. O, mejor, ese mismo trabajo de medición se lo cobras como fase 0 del proyecto.

Error dos, mío: presupuestar un MVP sin contemplar las integraciones. Era 2024, primer año a tiempo completo en IA, y subestimé el coste de integrar el sistema con el CRM del cliente. Lo que iba a ser un proyecto de 25.000 euros terminó costando 45.000 entre integración real y revisiones de seguridad. Asumí parte del sobrecoste yo, era lo correcto, pero perdí dinero en el proyecto. Lo aprendí: la integración con sistemas legacy es siempre más cara de lo que parece. Ahora presupuesto integraciones por separado y por fases, no las meto dentro del MVP.

Error tres, visto en cliente: contratar consultora grande para “estrategia IA” sin caso de uso definido. Cliente industrial, 600 personas. Pagaron 80.000 euros por un diagnóstico de seis semanas que entregó un PowerPoint con 47 iniciativas IA priorizadas. Año y medio después, ninguna de las 47 iniciativas estaba en producción. Cuando entramos nosotros, lo primero fue tirar el PowerPoint y elegir un único caso (triaje de incidencias técnicas de planta) que estaba causando dolor real medible. En tres meses, ese caso estaba en producción ahorrando 45.000 euros al año. Lo aprendí: si te ofrecen un mapa antes de un caso concreto, sospecha.

¿Qué otros errores se repiten en clientes que veo?

He visto un puñado de errores tan repetidos que parecen patrones culturales del sector. Te los pongo en bloque:

• Confundir POC con producción: dar por bueno un POC que funcionó en condiciones ideales y asumir que en producción irá igual.
• Comprar tecnología antes de entender el proceso: contratar plataformas IA caras antes de tener claro qué proceso van a mejorar.
• Subestimar el cambio organizativo: el sistema técnico funciona pero el equipo no lo adopta porque no se gestionó la transición.
• Presupuesto a corto sin pensar en operación: 50.000 euros para construir, cero euros previstos para operar.
• Falta de governance de datos: aplicar IA a procesos que tocan datos sensibles sin haber pensado el marco de cumplimiento.
• Promesas externas antes de tiempo: anunciar al consejo “estamos haciendo IA” antes de tener resultados, generando expectativas imposibles.
• Confundir velocidad de demo con velocidad de producción: una demo bonita en dos semanas no significa producción en cuatro.

Cada uno de estos errores me ha costado o le ha costado a algún cliente cifras de cinco o seis dígitos. No son matices, son agujeros graves. Si reconoces más de dos de estos en tu empresa o en tu proyecto IA actual, para y replantea. Es mucho más barato parar a tiempo que terminar un proyecto mal diseñado.

¿Qué he dejado de hacer que antes hacía?

Una pregunta que me gusta hacerme cada año: qué he dejado de hacer que antes hacía. En IA hay tres cosas que he dejado de hacer en los últimos doce meses y que me han mejorado los resultados claramente.

Dejé de aceptar proyectos sin sponsor con autoridad. Ya no firmo proyectos donde mi contraparte es un mando intermedio enviado a “explorar”. Si quien manda no se sienta en la primera reunión, no firmo. Dejé de prometer plazos optimistas; ahora los plazos que doy son los que de verdad creo, no los que el cliente quiere oír. Dejé de cerrar proyectos completos a precio fijo; ahora todo va por fases con kill-switch en cada una. Esos tres cambios han bajado mi tasa de conversión comercial, pero han subido mi tasa de éxito en producción. Y al final, lo segundo es lo que importa.

¿Cómo lo hago yo (lo que aplico en Datalvar AI)?

Aquí te cuento el proceso real que aplicamos en Datalvar AI cuando aterrizamos en un cliente. No es ningún framework propietario inventado, es la destilación de lo que hemos visto que funciona después de bastantes proyectos. Te lo cuento por fases.

Fase 0, descubrimiento (1-2 semanas). Nos sentamos con el sponsor y con el equipo operativo del proceso candidato. No hacemos workshop genérico de IA; hacemos un análisis del proceso concreto que duele: pasos, tiempos, volúmenes, errores, casos atípicos, integración con sistemas. Salimos con un documento de 10-15 páginas que describe el proceso actual, los números actuales, la hipótesis de mejora con IA y el caso de inversión preliminar. Si los números no salen, lo decimos y no seguimos. Si los números salen, pasamos a fase 1.

Fase 1, MVP (4-8 semanas). Construimos la versión mínima viable del sistema, en producción, con un subgrupo del equipo del cliente como usuarios piloto. No es demo, no es POC, es algo que se usa en el trabajo real desde la semana 3 o 4. Iteramos rápido con el feedback de los usuarios reales. Al final de la fase 1 tenemos métricas reales, no proyectadas, de cuánto está ahorrando el sistema. Si la realidad confirma la hipótesis (con margen razonable), pasamos a fase 2. Si la realidad la desmiente, paramos y replanteamos. Esa es la kill-switch.

Fase 2, despliegue y consolidación (6-12 semanas). Extendemos el sistema al resto del equipo afectado, integramos con todos los sistemas necesarios, montamos monitoreo de calidad y operación, documentamos y formamos. Al cierre de fase 2, el cliente puede operar el sistema con poca dependencia nuestra. Pasamos a fase 3 de mantenimiento ligero (presencia mensual o trimestral), o el cliente sigue con nosotros en evolución continua si quiere construir más casos.

¿Qué hacemos en mantenimiento que casi nadie hace?

El mantenimiento es donde la mayoría de proyectos IA mueren en silencio. Nosotros hacemos cuatro cosas en mantenimiento que no son glamurosas pero son las que mantienen el sistema vivo: revisión mensual de métricas operativas (latencia, errores, calidad de outputs por muestreo), revisión trimestral de prompts y flujos (a veces el mundo cambió y hay que ajustar), revisión semestral del modelo y proveedor (porque los modelos comerciales cambian rápido y a veces te conviene cambiar), y revisión anual del caso de uso completo (¿sigue teniendo sentido el caso? ¿hay mejor forma de resolverlo?). Es trabajo aburrido pero indispensable.

Lo que veo en clientes que vienen de otras consultoras: les construyeron un sistema, no les dejaron documentación operativa, no les montaron monitoreo, no quedó nadie en la consultora con conocimiento del proyecto. El sistema se degrada en silencio durante seis meses, los usuarios empiezan a desconfiar, alguien decide apagarlo. Cuando llegan a nosotros buscando alternativa, la mitad de las veces el proyecto era recuperable si se hubiese mantenido bien. El problema casi nunca fue técnico.

Un sistema IA en producción sin monitoreo de calidad es como un coche sin cuadro de mandos. Puede que vaya bien, puede que vaya mal, pero no lo sabes. Y cuando algo se rompe, te enteras tarde, mal y caro. El monitoreo de calidad no es lujo, es higiene básica. Si tu vendor IA no incluye monitoreo en la propuesta, ese vendor no ha operado sistemas en producción.

¿Cómo decidimos qué tecnología usar en cada caso?

Otra pregunta común. Mi postura es muy poco glamurosa: usamos los modelos comerciales (OpenAI, Anthropic, Google) salvo que haya razón específica para no hacerlo. Razones para no usarlos: cumplimiento regulatorio que exige procesamiento local, volúmenes brutales donde el coste por token deja de salir, o caso de uso muy específico donde un modelo open source fine-tuneado da mejor calidad. Para el 80% de los casos en empresa media, modelos comerciales vía API son la elección correcta. Te los integran rápido, son fiables, se actualizan solos y el coste de operación es muy razonable.

Si alguien te quiere vender “tu propio LLM corporativo” en una empresa media sin caso muy especial, sospecha. Casi siempre, en empresa media, “LLM propio” es palabreo. La realidad es API de Anthropic o de OpenAI con tu prompt encima y tus datos como contexto. Que no es malo, es perfecto. Pero llamarlo “LLM propio” es marketing, no técnica. Para ese 80%, lo que importa no es el modelo, es la capa de orquestación, los prompts, la integración con tus sistemas y el monitoreo. Ahí es donde está el trabajo serio. El modelo es commodity en 2026.

Mi opinión contrarian: por qué muchos “agentes IA” no son agentes

Voy a meterme en territorio impopular. En 2026, todo lo que se vende se llama “agente IA”. Antes era “asistente IA”, antes “chatbot inteligente”, antes “automatización con IA”. El vocabulario cambia, la cosa cambia menos. Mi opinión, después de construir varios sistemas que se llaman a sí mismos agentes y de auditar sistemas de competidores, es que la mayoría de “agentes IA” que se venden en empresa media son flujos automatizados con un LLM dentro, no agentes en sentido técnico estricto.

Un agente, técnicamente, es un sistema que puede planificar pasos, tomar decisiones, ejecutar acciones con herramientas y recuperarse de errores, todo de forma autónoma para alcanzar un objetivo. Eso es muy difícil de hacer bien y muy caro de mantener. Lo que se vende como agente en la mayoría de empresas medias es: un workflow predefinido con varias llamadas a LLM dentro, con condiciones if/else, donde el LLM no decide la estructura del flujo, solo decide el contenido en cada paso. Eso no es agente, es automatización con IA. Y está perfecto, funciona muy bien, pero no es agente.

Por qué importa la distinción. Porque vender “agentes” implica capacidades que el sistema no tiene, genera expectativas falsas, y cuando el cliente descubre que su “agente” no maneja casos fuera del flujo prediseñado, se siente engañado. Si vendieras “automatización con IA contextual” en lugar de “agente IA” expectativa y realidad estarían alineadas, el cliente estaría más satisfecho, y nadie tendría que explicar por qué su agente no puede reaccionar a algo inesperado. La inflación de vocabulario perjudica al sector entero.

Mi opinión impopular: el 90% de los “agentes IA” que se venden en empresa media son automatizaciones con IA, no agentes. Y está bien, las automatizaciones con IA funcionan estupendamente. Pero llamarlas agentes infla expectativas y deja al cliente con la sensación de que la IA no cumple. La IA cumple; lo que no cumple es el marketing inflado del sector.

¿Cuándo sí necesitas un agente de verdad?

Hay casos donde sí necesitas un agente en sentido técnico estricto. Suelen ser casos con alta variabilidad en el flujo (cada caso es muy distinto y no se puede predefinir todos los caminos), donde hay necesidad de descomponer tareas dinámicamente, donde hay que usar herramientas externas en orden no predecible, o donde se requiere razonamiento de varios pasos con memoria. En empresa media, esos casos son una minoría. La mayoría de las necesidades de empresa media se cubren con automatización contextual con IA, que es más simple, más fiable y más barato de mantener.

Mi recomendación práctica: empieza siempre por la solución más simple que funcione. Si una llamada a LLM con prompt cuidadoso resuelve, no hagas un flujo. Si un flujo determinístico con varias llamadas resuelve, no hagas un agente. Si necesitas un agente, hazlo, pero asumiendo que vas a invertir bastante más en testing, monitoreo y manejo de errores. La complejidad técnica tiene coste operativo. Y el coste operativo es lo que hace que un sistema sobreviva o no en producción.

¿Por qué este sector necesita más honestidad?

Porque está viviendo una burbuja de expectativas que no se corresponde con lo que se entrega. Cuando empresas paganas descubren la brecha entre lo prometido y lo entregado, pierden confianza no solo en el vendor, sino en la tecnología. Y esa pérdida de confianza nos perjudica a todos. Quienes hacemos IA seria pagamos el precio del hype inflado por quienes no la hacen bien. Por eso, en parte, escribo este artículo. Lo necesito por interés propio: si el sector se desinfla por exceso de humo, los próximos clientes van a ser más reticentes, más exigentes, más difíciles.

La salida es desinflar el discurso desde dentro. Hablar como lo que es: una herramienta poderosa pero acotada, con costes reales, con plazos reales, con riesgos reales, capaz de generar mucho valor cuando se aplica bien. No hace falta inflarla; ya es lo bastante valiosa con sus límites reales. El problema es que vender realidad cuesta más que vender promesas, y mucho consultor encuentra más fácil prometer que entregar. Por eso, cada artículo honesto que circule en el sector mejora un poco el ecosistema. Aplicar IA en una empresa real sin humo empieza por cómo se habla de la IA, no solo por cómo se construye.

Caso real anonimizado: industria manufacturera de 220 personas

Te cuento un caso real anonimizado para cerrar con concreción. Empresa industrial española, 220 personas, facturación alrededor de 35 millones, sector componentes para automoción. Llegaron a nosotros en otoño de 2024 después de un año perdido con otra consultora que les había vendido “estrategia IA holística” por 65.000 euros. Resultado de esa consultora: PowerPoint de 88 páginas con un roadmap de 23 iniciativas IA. Resultado tangible para la empresa: cero.

Cuando entramos, hicimos exactamente lo contrario: ignorar el roadmap y preguntar al director de operaciones qué proceso le dolía más. Respuesta inmediata: la gestión de incidencias técnicas reportadas por clientes finales (talleres mecánicos y distribuidores). El equipo de soporte técnico tardaba una media de 52 minutos por incidencia compleja entre leer el caso, buscar en manuales, consultar histórico de incidencias previas y redactar respuesta técnica. Volumen: 1.400 incidencias al mes. Coste implícito en horas de ingeniería: alrededor de 18.000 euros al mes.

Caso de uso claro, métrica baseline clara (52 minutos), volumen alto (1.400/mes), dolor reconocido, sponsor con autoridad (el director de operaciones se sentó él en cada reunión). Todas las señales verdes. Acordamos una fase 1 de 6 semanas por 19.500 euros para construir un MVP que asistiera al equipo de soporte recuperando casos similares previos, sugiriendo respuesta técnica y precargando el borrador para revisión humana.

¿Qué pasó en producción?

A las 6 semanas teníamos un MVP en producción usado por 4 ingenieros de soporte. Métrica a las 12 semanas: tiempo medio por incidencia bajó de 52 a 28 minutos en los casos donde el sistema encontraba precedente útil (el 73% del volumen). En el resto, el sistema añadía 2 minutos de fricción que el equipo aceptaba como coste asumible. Ahorro neto mensual estimado: 8.400 euros. Payback de la fase 1: 2,3 meses. Pasamos a fase 2 inmediatamente.

Fase 2, despliegue completo al equipo de soporte (11 personas) e integración con su CRM. Coste 28.000 euros. Plazo 10 semanas. A los 6 meses de la fase 2, el sistema procesaba el 100% de las incidencias entrantes, el tiempo medio había bajado a 24 minutos (frente a los 52 iniciales) y el equipo había podido absorber un crecimiento del 18% del volumen de incidencias sin contratar a nadie nuevo. Ahorro anual reconocido por el cliente: 142.000 euros. Inversión total acumulada: 47.500 euros entre fases 1 y 2. Mantenimiento mensual: 1.800 euros.

Año y medio después, el sistema sigue en producción, ha tenido dos iteraciones serias del modelo (al pasar de un proveedor a otro porque salió mejor opción), y el cliente ha comenzado a construir un segundo caso de uso con nosotros (asistente comercial para preparación de propuestas técnicas). Lo que importa de este caso no es la cifra de ahorro, importa el método: caso concreto, métrica clara, sponsor con autoridad, fases con kill-switch, mantenimiento previsto, escalado solo cuando el primer caso estaba probado. No fue ningún superpoder. Fue oficio.

Lo que hicimos en este caso no era especialmente difícil ni innovador técnicamente. Lo difícil fue, antes de empezar, decir “no” al roadmap de 23 iniciativas y “sí” a un único caso. Esa decisión, no la tecnología, es la que separa los proyectos que funcionan de los que no. La tecnología en 2026 es accesible. La decisión, no tanto.

¿Qué dejó este caso como aprendizaje?

Tres lecciones que me llevo, y que aplico ahora siempre. Primera: el caso correcto casi siempre te lo dice el operativo, no el directivo. El directivo te habla en estrategia, el operativo te habla en dolor concreto. Empieza por el operativo. Segunda: el ahorro real es siempre mayor del estimado cuando se acierta el caso, porque hay efectos colaterales positivos no anticipados (mejor calidad, menor rotación, mejor experiencia de cliente final) que no entran en el cálculo inicial. Tercera: la honestidad técnica genera confianza que termina facturando más. Este cliente nos contrató para un segundo caso porque el primero se hizo bien y se contó honestamente lo bueno y lo malo. La transparencia construye negocio.