Por qué casi ningún proyecto de IA en una pyme llega a producción

El patrón se repite hasta aburrir

Un directivo ve una demo. Alguien monta un prototipo en quince días. Funciona con los diez ejemplos que probaron, todo el mundo aplaude y en el negocio no cambia nada.

Seis meses después la herramienta tiene tres usuarios, y los tres son la persona que la construyó. Nadie mata el proyecto oficialmente. Simplemente deja de mencionarse.

Hemos entrado en esa sala muchas veces. El diagnóstico casi nunca es el modelo.

Cuatro razones, por orden de frecuencia

1. Nunca estuvo atado a un número

Un piloto que ahorra tiempo indefinido no se puede defender en una reunión de presupuesto. Si nadie acordó la línea base antes de empezar, nadie puede demostrar después que funcionó.

Primero la línea base, siempre. Cuánto tarda hoy, cuántas veces pasa, cuántas sale mal. Veinte minutos de medición valen más que un trimestre de discusión.

2. Vivía fuera de las herramientas que usa la gente

El prototipo está en su propia página web. Tu equipo vive en un CRM, un correo y una ventana de chat. Pedirles que abran una cuarta cosa cuesta más atención de la que devuelve la herramienta.

Esta es la razón más común por la que muere un buen piloto. La adopción es un problema de distancia antes que de calidad.

3. Acertaba el 90 % y no había plan para el otro 10

Un software que acierta nueve de cada diez veces es excelente. Esa misma precisión sin cola de excepciones es una trampa, porque alguien tiene que revisarlo todo para encontrar el caso número diez.

Diseña el camino del fallo el primer día. Qué hace la máquina cuando duda, quién lo ve, en cuánto tiempo.

4. Nadie se hizo cargo después de la demo

El consultor se fue. El impulsor interno cambió de puesto. Luego un proveedor de modelos publicó una actualización, la salida se desvió y alguien volvió sin decir nada a la hoja de cálculo de siempre.

Un piloto demuestra que la tecnología puede funcionar. Producción demuestra que tu empresa puede sostenerla. Son dos proyectos distintos, y solo uno paga.

Un ejemplo con el coste real

Una consultora de selección de 35 personas dedicó cuatro meses a construir un filtro de currículums con IA. El presupuesto fueron 28.000 dólares de trabajo externo más unas 120 horas internas.

El filtro era preciso. Su problema era que los reclutadores tenían que subir el currículum a otra aplicación, esperar y luego copiar el resumen de vuelta al sistema de seguimiento de candidatos.

Pasos añadidos por candidato: tres. Tiempo ahorrado por candidato: cuatro minutos. La herramienta se comía dos de esos minutos en copiar y pegar, así que la ganancia real era lo bastante fina como para ignorarla con prisa.

Lo reconstruimos en nueve días dentro del propio sistema de seguimiento. El filtrado ocurre al llegar el candidato, el resumen aparece en su ficha y nadie sube nada. El uso pasó de dos reclutadores a nueve porque el trabajo bajó a cero clics extra.

La lección en una línea

La reconstrucción costó una fracción del proyecto original y no cambió nada del modelo. Cambió dónde vivía el modelo.

Qué forma tiene un proyecto que sobrevive

La forma es distinta desde el principio. No más cuidadosa, sino apuntada a producción en vez de a que la aprueben.

• Un proceso, un número medible, un responsable con nombre dentro de la empresa.
• Construido donde ya ocurre el trabajo, aunque esa plataforma sea más aburrida de programar.
• Un entorno de pruebas con datos históricos reales antes de tocar a un cliente.
• Una cola de excepciones desde el primer día, con una persona que la revisa a diario.
• Algo funcionando en el negocio antes de cinco semanas, no una hoja de ruta para el mes seis.

Ese último punto es el que más se discute, normalmente porque un plan largo parece más serio. Seis meses construyendo sin contacto con producción no es rigor. Es una apuesta sobre supuestos que nadie ha probado.

Dónde se gana la IA su sitio

Usamos modelos donde las reglas no llegan: leer documentos sin estructura, clasificar texto libre, redactar con una voz entrenada, resumir una llamada en una decisión. Todo lo demás funciona mejor como automatización normal, que es más barata de operar y mucho más fácil de depurar.

Un sistema que solo usa IA para la parte de lenguaje suele sobrevivir, porque el 80 % aburrido sigue funcionando el día que un modelo tiene un mal rato.

Antes de aprobar el siguiente

Haz cuatro preguntas en la reunión. Cada una lleva un minuto y son incómodas a propósito.

1. ¿Qué número se mueve, y cuánto vale hoy?
2. ¿Qué herramienta tiene abierta esa persona cuando pasa esto?
3. ¿Qué ocurre cuando la salida es incorrecta, y quién lo ve?
4. ¿Quién se hace cargo de esto en el mes seis, con nombre y apellidos?

Un proyecto que no puede contestar las cuatro no está listo. Descubrirlo ahora sale barato.

La prueba del mes tres

Pon una fecha en el calendario tres meses después del arranque, antes de que nadie construya nada. Ese día miras dos números.

Cuánta gente lo usó la semana pasada y si la línea base se movió. Un uso por debajo de la mitad de los usuarios previstos significa que la herramienta está en el sitio equivocado, diga lo que diga el informe de precisión.

Una línea base que no se ha movido significa que el proceso nunca era la restricción. Cualquiera de las dos respuestas es barata de arreglar en el mes tres y dolorosa de descubrir en el nueve.

Esa reunión la reservamos en el arranque y la mantenemos incluso cuando el proyecto va claramente bien. La costumbre es lo que hace que las malas noticias lleguen a tiempo.