De cara al cliente
Asistentes de soporte que resuelven las preguntas frecuentes, clasifican los tickets por tema y urgencia y pasan los difíciles a una persona con la conversación ya resumida. Asistentes de ventas que califican los leads entrantes, responden preguntas sobre el producto a partir de una ficha técnica y redactan seguimientos que un comercial edita antes de enviar. En retail y viajes, el mismo patrón aparece como ayuda con el estado del pedido y las reservas. Funcionan cuando tienes un historial de conversaciones del que aprender y una vía clara de escalado para cuando el modelo no está seguro, y fallan cuando al asistente se le pide que lo responda todo y nunca diga «te paso con una persona».
Operaciones y back-office
Aquí está la mayor parte del dinero discreto. El procesamiento de documentos extrae campos de facturas, contratos, reclamaciones y formularios de alta para que una persona revise en lugar de volver a teclear. Los asistentes de conocimiento interno responden preguntas del equipo (políticas de RR. HH., procedimientos de TI, especificaciones de producto) a partir de tus propios documentos, no de una wiki enterrada. Súmale la redacción de respuestas rutinarias, actas de reuniones e informes preliminares. Nada de esto es vistoso. Pero quita horas de trabajo repetitivo por equipo cada semana, y suele ser el punto de partida de menor riesgo, porque una persona revisa cada resultado.
Datos y decisiones
Previsión de demanda, detección de fraude o anomalías, puntuación de leads o de riesgo y priorización de una cola: los casos en los que hay suficiente historial para que los patrones sean reales y no ilusiones. Un banco marca una transacción extraña; un almacén predice el stock del mes que viene; un prestamista ordena solicitudes. Necesitan datos limpios y etiquetados y una evaluación honesta contra un conjunto reservado, no una demo con filas escogidas a mano. El potencial es grande, y también lo es el coste de lanzar un modelo que nadie midió.
Dónde fallan de verdad los proyectos de IA
El modelo rara vez es el problema. Los proyectos se atascan en la capa aburrida que lo rodea. Los datos están repartidos entre sistemas, la mitad desactualizados y sin responsable, así que el asistente responde con seguridad desde la fuente equivocada. El piloto funciona en un notebook y luego no tiene dónde ejecutarse, porque nunca se planificaron el despliegue, el control de acceso ni la monitorización. Y nadie decidió qué puede hacer la IA por su cuenta y qué tiene que aprobar una persona. Así que elige un caso de uso en el que los datos ya existan y alguien sea responsable de ellos. Ese único filtro descarta más proyectos malos que cualquier elección de modelo.
Cómo saber si un caso de uso funciona
Decide la cifra antes de construir y luego vigílala. En un asistente de soporte es la tasa de desvío y la frecuencia con la que tuvo que intervenir una persona: una herramienta que lo escala todo no ahorró nada. En el procesamiento de documentos es la proporción de documentos que pasan sin corrección y la tasa de error en los que no. En una previsión es la precisión frente a lo que pasó de verdad, no frente al conjunto de prueba con el que la ajustaste. Mi regla: si no puedes decir en una frase qué demostraría que funciona, todavía no está listo para construirse.