Cuando un proyecto de inteligencia artificial no llega a buen puerto, la explicación que circula suele ser técnica: el modelo alucina, la infraestructura no daba para más, la integración era compleja. Es una explicación cómoda, porque desplaza la responsabilidad hacia algo que suena inevitable. En la práctica, los fallos que se repiten tienen poco de tecnológicos y mucho de decisión previa.

Estos son los seis patrones que aparecen una y otra vez, con la advertencia de que reconocerlos en un proyecto propio es incómodo, porque casi siempre implican que algo se dio por resuelto demasiado pronto.

1. Empezar por la herramienta y buscarle un problema después

La secuencia habitual es la inversa a la correcta. Alguien detecta una plataforma de agentes, contrata una licencia anual y después convoca al equipo para decidir qué automatizar. El resultado es un proyecto que existe para justificar la compra, con un alcance que se estira y se encoge según lo que la herramienta permite, no según lo que el negocio necesita.

El síntoma es fácil de detectar: en la primera reunión se habla de funcionalidades del producto y no de un proceso concreto con horas perdidas al mes. La alternativa es aburrida y funciona: elegir un proceso, medirlo durante dos semanas, calcular cuánto cuesta hoy y solo entonces evaluar qué tecnología lo mejora.

2. Dar por hecho que el dato está bien

Es el error más caro y el más frecuente. La conversación inicial suele incluir la frase «la documentación la tenemos toda en el servidor», que casi nunca significa lo que parece. Lo que hay es una mezcla de versiones, borradores sin fecha, archivos escaneados sin capa de texto, duplicados con nombres distintos y carpetas que solo entiende la persona que se jubiló el año pasado.

Un sistema de IA no arregla esa situación: la amplifica. Si le das documentación contradictoria, devolverá respuestas contradictorias con mucha seguridad. La fase de inventario y limpieza no es un trámite previo, es la parte del proyecto que decide si el resultado es fiable.

Una regla útil: si un compañero nuevo no podría encontrar la respuesta correcta en esa documentación en menos de diez minutos, un sistema RAG tampoco lo hará de forma fiable.

3. Nadie definió qué significa «funciona»

Sin un criterio de éxito acordado antes de empezar, la evaluación se convierte en una conversación de impresiones. El equipo técnico enseña diez respuestas correctas, alguien pregunta por una que salió mal y el proyecto entra en una negociación sobre percepciones.

Un criterio útil combina tres capas. Una métrica de calidad: porcentaje de respuestas correctas sobre un conjunto de referencia de cien preguntas reales, con revisión humana. Una métrica de producto: cuántas personas lo usan y cuántas veces a la semana. Y una métrica de negocio: tiempo ahorrado por consulta o reducción de interrupciones al equipo experto.

El error clásico es medir solo la primera. Un sistema con un 90 % de acierto que nadie abre no ha funcionado. Un sistema con un 75 % que elimina tres horas semanales de búsqueda puede ser un éxito rotundo.

4. La prueba de concepto se queda en el laboratorio

La distancia entre una demo y un sistema en producción es la parte que casi nunca aparece en el entusiasmo inicial. La demo funciona con veinte documentos, sin permisos, sin usuarios concurrentes, sin auditoría y sin nadie que la use ocho horas al día.

En producción aparecen cosas como estas: documentos que se actualizan y hay que reindexar, usuarios de departamentos distintos que no deben ver lo mismo, consultas ambiguas que en la demo nadie hizo, latencias que se acumulan cuando el índice crece, y un coste por consulta que hay que vigilar.

Cerrar esa brecha exige trabajo poco vistoso: conjunto de evaluación, monitorización, registro de consultas fallidas, política de actualización del índice y un responsable claro. Un proyecto que no presupuesta esa fase está comprando una demo, no un sistema.

5. Se ignoró a quien hace el trabajo

Los procesos descritos en una presentación y los procesos reales rara vez coinciden. En el papel, el comercial consulta el CRM y registra la llamada. En la realidad, apunta tres cosas en una libreta mientras habla, y solo pasa al CRM lo imprescindible cuando se lo pide el jefe de ventas.

Si la herramienta obliga a cambiar ese hábito de golpe, no se usa. Y si el sistema de IA devuelve una respuesta que hay que copiar a mano a otra pantalla, se usa la primera semana y luego se abandona. La integración en el flujo existente, con el mínimo número de clics y en el sitio donde la persona ya trabaja, no es un detalle de UX: es una condición de viabilidad.

6. La gobernanza y el cumplimiento llegan al final

Revisar el tratamiento de datos personales, los acuerdos de confidencialidad con clientes y el encaje en el Reglamento europeo de IA cuando el sistema ya está construido suele terminar en dos escenarios igual de malos: se desmonta parte del trabajo o se lanza con un riesgo que nadie ha evaluado.

Estas cuestiones se resuelven antes de escribir código, y en la mayoría de los casos no bloquean el proyecto: lo ordenan. Saber qué documentación contiene datos personales, qué proveedor de modelo trata qué información y cuánto tiempo se conservan los registros de consultas son decisiones de diseño, no trámites finales.

Un test rápido de viabilidad antes de arrancar

  • ¿El proceso ocurre al menos varias veces por semana y consume horas medibles?
  • ¿Existe un responsable funcional que pueda decidir qué respuesta es la buena?
  • ¿La información necesaria está en documentos o sistemas a los que podemos acceder?
  • ¿Podemos construir un conjunto de cien preguntas reales con su respuesta correcta?
  • ¿El equipo que va a usar el sistema ha participado en la definición?
  • ¿Sabemos qué hacemos cuando el sistema se equivoca, y quién asume esa revisión?
  • ¿Hay un plan para mantenerlo dentro de doce meses?

Si fallan tres o más, el problema no es la tecnología elegida. Es que el proyecto todavía no está definido y conviene gastar dos semanas en definirlo antes de comprometer un presupuesto mayor.

Cuándo la respuesta correcta es no hacer IA

Hay procesos que se resuelven mejor sin inteligencia artificial y decirlo a tiempo es parte del trabajo. Si los datos de entrada están perfectamente estructurados y la regla es fija, una integración determinista es más rápida, más barata y más fácil de auditar. Si el problema es que hay tres ERPs y nadie los ha unificado, la IA no va a hacer esa unificación por ti. Y si la decisión requiere criterio jurídico o responsabilidad humana, la IA puede preparar el trabajo, pero no sustituir la firma.

Rechazar un proyecto mal planteado es más rentable a medio plazo que aceptarlo y descubrirlo en la fase tres. Por eso tenemos una página dedicada a explicar cuándo no trabajamos con un cliente: sirve para no perder el tiempo en ninguna de las dos direcciones.

Los proyectos de IA que salen bien no son los que usan el modelo más avanzado, sino los que eligen un proceso acotado, tienen el dato ordenado, definen el éxito antes de empezar y dejan a alguien responsable de sostenerlo. El resto es ingeniería, y la ingeniería se puede planificar.