El 42% de las empresas descartó la mayoría de sus iniciativas de IA en 2025. El doble que el año anterior.

Muchos de esos proyectos no debieron haber empezado.

En 25 años construyendo software empresarial, he visto esta película antes. La nube iba a reemplazar todo. El móvil iba a reemplazar todo. Las empresas que ganaron en cada ciclo no fueron las que adoptaron primero — fueron las que supieron cuándo la nueva tecnología era la herramienta equivocada.

Con la IA está pasando lo mismo. Y esto lo digo como alguien que vive de implementar IA.

En IQ Source, aproximadamente 4 de cada 10 veces que un cliente nos contacta queriendo IA, le decimos que no la necesita. Eso no es malo para el negocio. Es lo mejor que hacemos por el negocio.

Cinco preguntas antes de empezar

No tenemos un framework propietario ni un proceso de 12 pasos. Tenemos cinco preguntas que hacemos en la primera reunión con cada cliente. Si alguna enciende una alerta, el proyecto cambia de dirección — o no empieza.

1. ¿El proceso se basa en reglas fijas? En ese caso, un motor tradicional siempre va a ser más barato y predecible.
2. La auditoría. Si estás en un sector regulado, necesitas explicar cada decisión. Una caja negra no te sirve de nada ante un regulador.
3. La calidad de los datos. Meter datos sucios a un modelo solo va a servir para que aprenda patrones que no existen.
4. ¿Dan los números? Hay que evaluar si lo que cuesta cada llamada a la API tiene sentido frente al valor real que genera esa decisión.
5. El orden interno. Si el proceso actual no funciona bien a nivel organizacional, la IA va a automatizar el caos.

El caso más típico que vemos: alguien quiere un chatbot con IA para clasificar tickets de soporte interno. Pero cuando revisamos el proceso, resulta que tienen pocas categorías, reglas claras para cada una, y un equipo que ya las clasifica correctamente más del 95% del tiempo.

Ese problema no es de inteligencia — es de automatización pura. Un motor de reglas con enrutamiento automático se construye en dos semanas, cuesta una fracción de lo que costaría el proyecto de IA, y acierta el 100% de los casos dentro de las reglas definidas. Sin latencia de API, sin costo por transacción, sin alucinaciones.

Cuando le dices eso a un cliente en vez de venderle el proyecto más caro, la confianza que construyes vale más que cualquier contrato individual.

Si puedes escribirlo como if/then, no necesitas un modelo

Este es el escenario más común que vemos. Un cliente quiere usar IA para algo que se puede resolver con lógica determinística.

Cálculos de impuestos. Verificaciones de cumplimiento regulatorio. Enrutamiento de tickets. Clasificación de productos por reglas de inventario. Validación de formularios.

La diferencia en números es clara. Un motor de reglas responde en milisegundos con un costo marginal de cero, y tienes precisión del 100% dentro de los parámetros que definiste. Sabes exactamente qué pasó en cada caso. Un modelo de IA, por el contrario, tarda entre 200 y 2,000 milisegundos, te cobra entre $0.002 y $0.05 por cada llamada a la API, y su precisión suele rondar el 85-95%. Además, pierdes la explicabilidad.

El modelo solo vale la pena cuando estás lidiando con ambigüedad — interpretar intención del usuario, manejar texto libre, clasificar entradas que no encajan en categorías claras. Si el 95%+ de tus casos sigue reglas definidas, meter IA al flujo solo lo encarece y lo hace menos predecible.

Volviendo al ejemplo de los tickets de soporte: si tus categorías cubren el 95%+ del volumen, el restante va a una cola manual — que es exactamente lo que haría un modelo de IA cuando no tiene confianza suficiente en su clasificación. Mismo resultado, sin el costo.

98% de precisión sin explicación es peor que 95% con auditoría

Un banco te niega un préstamo. Preguntas por qué. La respuesta que recibes: “el modelo determinó que tu perfil de riesgo es elevado.”

¿Eso es aceptable? En muchas jurisdicciones, no. Y cada vez en más.

En industrias reguladas — banca, seguros, salud, legal — no alcanza con que el sistema acierte. Tiene que poder explicar por qué acertó. Un modelo que es correcto el 98% del tiempo pero funciona como caja negra puede ser peor que un sistema basado en reglas que acierta el 95% y produce una cadena de decisión auditable.

Los datos lo confirman. Gartner predijo que más del 30% de los proyectos de IA generativa se abandonarían después de la prueba de concepto, y uno de los factores principales es la incapacidad de cumplir con controles de riesgo y gobernanza.

Cuando un cliente en sector financiero o de salud nos pide implementar IA para toma de decisiones, la primera conversación no es sobre modelos ni sobre datos. Es sobre qué pasa cuando un regulador pide que expliquen una decisión. Si no hay respuesta clara, retrocedemos a un sistema basado en reglas — que sí puede mostrar exactamente por qué se tomó cada decisión.

Tu problema de datos no es un problema de IA

Muchas veces llega un cliente queriendo predecir demanda con IA, pero al revisar sus sistemas descubrimos que solo tienen seis meses de historial para apenas 40 productos con ventas recurrentes de un catálogo de 300. Con esos volúmenes, un modelo de IA no va a encontrar patrones — va a inventarlos. Eso no es un problema de IA. Es un problema de datos. Y la IA no lo resuelve — lo amplifica.

Situación de datos	Enfoque recomendado
Miles de registros limpios, patrones claros	ML clásico (regresión, árboles de decisión) funciona bien y es interpretable
Cientos de registros, algunas señales	Heurísticas basadas en reglas de negocio + promedios móviles
Datos sucios o inconsistentes	Limpieza y estandarización de datos primero, IA después
Pocos registros, muchas variables	El modelo va a memorizar ruido, no a aprender patrones

BCG encontró que solo el 25% de las empresas obtiene valor significativo de sus iniciativas de IA — y el 5% lo logra a escala. Una de las razones principales: el 63% de las organizaciones no tiene las prácticas de gestión de datos necesarias para IA.

Si no tienes datos suficientes, un modelo de ML clásico con 10 variables bien elegidas va a superar a un LLM que no tiene con qué trabajar. Y va a costar una fracción.

Cuando las cuentas no cierran: latencia y costo por transacción

Este es el escenario más fácil de evaluar porque es pura aritmética.

Supongamos que tienes un e-commerce que procesa 50,000 transacciones al día. Quieres usar IA para detectar fraude en tiempo real. El modelo necesita evaluar cada transacción antes de aprobarla.

El cálculo:

• Costo por llamada a API de un modelo de lenguaje: ~$0.01 (conservador)
• 50,000 transacciones/día × $0.01 = $500/día = $15,000/mes
• Valor promedio de fraude prevenido (suponiendo 0.1% de transacciones fraudulentas con ticket promedio de $80): ~$4,000/mes

El modelo cuesta casi 4 veces más de lo que ahorra. Y eso sin contar la latencia: cada llamada a la API agrega 200-500ms. En un checkout, eso es la diferencia entre una compra completada y un carrito abandonado.

¿La alternativa? Un sistema de reglas que marca las transacciones sospechosas (monto inusual, IP de país diferente, tres intentos fallidos) y solo envía esas — digamos el 2% — a un modelo más sofisticado. Costo: $300/mes en lugar de $15,000. Latencia: <10ms para el 98% de las transacciones.

Aunque los costos de IA cayeron ~80% en 18 meses, la aritmética por transacción sigue matando proyectos donde el volumen es alto y el valor por unidad es bajo. Haz las cuentas antes de empezar.

Ninguna IA arregla un proceso roto

En Word Magic, la empresa de software de traducción que fundé con mi padre en los 90, pasamos meses intentando automatizar la recepción y el procesamiento de pedidos online. Construimos un sistema interno a la medida — ya conté esa historia en otro post. Pero el problema no era el sistema. Era que el proceso de fulfilment no estaba estandarizado: la información llegaba de distintos canales en formatos distintos, las reglas de validación variaban según quién procesara el pedido, y no había un flujo único acordado entre los equipos.

Ninguna tecnología iba a resolver eso. Tuvimos que sentarnos, definir un proceso claro y consistente, y recién ahí la automatización funcionó.

Ese patrón aparece en ~70% de las consultas de IA que hago hoy. El cliente describe un problema de clasificación, predicción o análisis. Investigamos. Y descubrimos que el problema real es que no hay un proceso claro, o que tres equipos operan con definiciones diferentes, o que los datos no se recopilan de forma consistente.

BCG lo cuantifica con su regla 10-20-70: el éxito de una transformación con IA depende 10% de los algoritmos, 20% de los datos y la tecnología, y 70% de las personas, los procesos y el cambio organizacional. McKinsey confirma que solo el 39% de las organizaciones reporta impacto en EBIT por sus inversiones en IA — en gran parte porque no rediseñan los workflows.

Automatizar un proceso roto no lo arregla. Lo rompe más rápido.

Ya escribimos sobre las preguntas que la IA no hace. Esta es la más importante: ¿el proceso que quieres automatizar funciona bien sin tecnología? Si no, no compres un modelo. Arregla el proceso.

Qué usar en su lugar

Escenario	Alternativa más simple	Costo aproximado	Tiempo de implementación
Proceso con reglas claras y fijas	Motor de reglas (código propio o herramientas low-code)	$2K-$10K	1-3 semanas
Predicción con datos estructurados limitados	ML clásico (regresión, random forest)	$5K-$15K	2-4 semanas
Conexión entre sistemas sin lógica compleja	Automatización de workflows (n8n, Make, Zapier)	$1K-$5K	1-2 semanas
Proceso desorganizado o con definiciones inconsistentes	Rediseño de proceso + documentación	$3K-$8K	2-4 semanas
Detección de anomalías con alto volumen	Reglas para filtrar + modelo solo para casos ambiguos	$5K-$12K	3-5 semanas

Estas alternativas no son emocionantes. No van a generar un slide impactante para el board. Pero resuelven el problema a una fracción del costo, con menos riesgo y en menos tiempo.

Cuándo la IA SÍ es la respuesta

No quiero que este post suene a que estamos en contra de la IA. Vivimos de ella. Pero la IA gana cuando el problema involucra lenguaje natural ambiguo, reconocimiento de patrones en datos no estructurados, personalización a escala o razonamiento sobre contextos que cambian constantemente.

Si tu problema encaja ahí, hemos escrito sobre cómo cerrar la brecha de utilización y sobre cómo implementar agentes de IA en operaciones reales. Esa es la otra mitad de nuestro trabajo — y la que más nos entusiasma.

Pero ese trabajo funciona mejor cuando primero descartamos los proyectos que no debían ser de IA.

---

Prefiero decirte hoy que no uses IA y ganarme tu confianza, a venderte un proyecto que termine en el cementerio del 42%. Si no tienes claro si tu próximo proyecto necesita IA o algo más simple, esa es exactamente la conversación que tenemos en nuestra evaluación de madurez de IA.

Evaluar si mi proyecto necesita IA