5 casos en los que la IA no compensa, y qué hacer en su lugar

Su consejo de administración pide un plan de IA, y un competidor acaba de anunciar un asistente. Alguien del equipo tiene una demo que funciona con diez ejemplos, y un proveedor ha enviado un presupuesto para los diez mil siguientes. Casi toda esa presión empuja a construir algo rápido.

Algunos de esos proyectos no deberían construirse. La IA funciona; lo que falta son las condiciones a su alrededor. Construir IA es nuestro oficio, y aun así en nuestras auditorías desaconsejamos parte de los proyectos que nos plantean.

Estos son los cinco casos que vemos con más frecuencia, cómo reconocer cada uno y a qué dedicar el presupuesto en su lugar.

1. Los datos no están (todavía)

La idea parece sencilla: un modelo que lee los tickets anteriores y redacta la respuesta. Luego alguien abre la herramienta de tickets. La mitad del historial está en buzones personales, las categorías han cambiado dos veces en tres años y nadie apuntó qué respuestas eran correctas.

Un modelo aprende de lo que usted le da, y se evalúa frente a lo que usted considera correcto. Si no existe ni lo uno ni lo otro, el proyecto se convierte en una limpieza de datos con la etiqueta de IA. Lleva meses, y mientras tanto la demo sigue luciendo bien: ahí está la trampa.

Qué hacer en su lugar. Arregle primero la captura: que el formulario de tickets haga las preguntas adecuadas, que las respuestas se guarden en un solo sitio, que se marquen las correctas. Son unas semanas de trabajo de producto, y se amortizan por sí solas con mejores informes y traspasos más limpios.

El proyecto de IA será viable unos meses después, sobre datos de los que se fía.

2. El volumen es demasiado bajo para amortizarlo

Una tarea que ocupa a alguien dos horas por semana es una molestia real. Rara vez justifica un modelo.

Haga la cuenta. Dos horas por semana son unas 100 horas al año. El cálculo cabe en una pizarra: horas ahorradas al año × coste horario total, frente al coste de construcción más un año de costes de operación (llamadas al modelo, monitorización, actualizaciones).

Tome su propio coste horario total: a 60 €, son 6000 € al año. Compare esa cifra con el presupuesto de una funcionalidad conectada a sus herramientas, más sus costes de operación. Para una tarea de este tamaño, la amortización suele quedar a años vista, si es que llega.

Un volumen bajo también perjudica la calidad. Con cuarenta casos al mes, no puede saber si el modelo acierta el 90 % de las veces o el 70 %. Se entera cuando un cliente se queja.

Qué hacer en su lugar. Mantenga la tarea en manos de una persona y hágala más rápida: una plantilla, una lista de verificación, una vista compartida de la información que esa persona busca una y otra vez. Vuelva a la IA cuando crezca el volumen, o cuando pueda agrupar varias tareas pequeñas con los mismos datos de entrada en un proyecto que merezca la pena construir.

3. El proceso cambia cada trimestre

Reglas de cualificación comercial reescritas tras cada consejo. Una tabla de precios con excepciones que nadie ha listado. Un proceso de alta de clientes que el equipo de operaciones rediseña cada primavera.

Una IA construida sobre un proceso en movimiento automatiza la versión del trimestre pasado. Cada cambio exige nuevas instrucciones, nuevas pruebas y, a veces, nuevos datos. El equipo se pasa el tiempo alineando el modelo con un objetivo que ya se ha movido.

Qué hacer en su lugar. Estabilice el proceso antes de automatizarlo. Ponga por escrito las reglas tal como se aplican hoy, con sus excepciones, y aplíquelas a mano o en una herramienta interna sencilla durante un trimestre.

Si se mantienen, tiene una especificación. Si siguen cambiando, ha aprendido que el problema está en la decisión, no en la ejecución.

4. Una regla simple o una herramienta no-code basta

Enrutar un correo porque su asunto contiene la palabra "factura". Enviar un recordatorio tres días después de un presupuesto. Copiar un formulario en el CRM. Hemos visto las tres cosas presentadas como proyectos de IA.

Una regla es predecible, no cuesta nada ejecutarla y cualquiera puede leerla. Un modelo es probabilístico, tiene un coste por llamada y hay que probarlo cada vez que cambia. Cuando la lógica cabe en una página, gana la regla.

Qué hacer en su lugar. Empiece por la regla. Zapier, Make o las automatizaciones que ya trae su CRM cubren la mayoría de estos casos, por una fracción del coste de operación.

Después mida lo que la regla no capta. Si los fallos son raros, ha terminado. Si se acumulan en un mismo punto, por ejemplo correos sin un asunto claro, aplique IA solo a esa parte, detrás de la regla.

Primero las reglas, y un modelo solo donde las reglas dejan de funcionar. Luce menos en una demo y es mucho más fácil de operar.

5. Nadie se hace cargo de la IA tras el lanzamiento

Este es el menos visible el primer día, y el más caro al sexto mes. El proyecto sale a producción y la persona que lo impulsó pasa a la siguiente prioridad. Seis meses después, el modelo responde preguntas sobre una línea de producto que ya no existe, y nadie ha revisado sus respuestas desde la primavera.

Una funcionalidad de IA no es una entrega puntual. Sus datos de entrada evolucionan, los modelos de base se actualizan, los usuarios encuentran casos límite que nadie probó. Sin un responsable, la calidad se degrada en silencio hasta que alguien lo nota, normalmente delante de un cliente.

Qué hacer en su lugar. Antes de empezar, nombre a la persona que se hará cargo tras el lanzamiento y dele tiempo para ello. Decida qué va a medir cada semana y a partir de qué nivel hay que corregir.

Si nadie dentro puede asumirlo todavía, el equipo que lo construyó puede operarlo tras el lanzamiento mientras usted encuentra a esa persona (así trabajamos en IA en producción), o un responsable de IA a tiempo parcial puede ocupar ese puesto unos días al mes.

Antes de firmar nada

Cinco preguntas, una por caso. Envíelas a quien esté redactando el plan de IA:

1. ¿Tenemos los datos, en un solo sitio, con las respuestas correctas marcadas?
2. ¿La tarea se repite lo bastante como para medirla?
3. ¿El proceso se ha mantenido estable durante un trimestre?
4. ¿Hemos probado antes una regla?
5. ¿Quién se hará cargo dentro de seis meses, con nombre y apellidos?

Si una respuesta es no, resuelva eso primero. Si las cinco son sí, lo difícil ya está hecho: en proyectos así, solemos tener una primera versión en producción entre 3 y 6 semanas después del arranque.

Una auditoría gratuita le dice de qué lado de la línea está su proyecto. Una hora sobre su negocio y después un documento breve con las oportunidades que vemos, y las que desaconsejamos. Reserve una auditoría gratuita y traiga el proyecto sobre el que tiene dudas.