Qué es un caso de uso de IA y cómo se define bien

El problema: aprobar una intención, no una decisión

En esa misma planta, cuando se revisó a fondo qué se había aprobado en comité, la respuesta fue una frase, no una decisión: "vamos a usar IA para prevenir fallas de máquina". Sonaba concreta en la sala de dirección y resultó imposible de ejecutar en el piso, porque nadie sabía a cuál de las once máquinas críticas se refería, quién iba a mirar las alertas cada turno, ni qué pasaba hoy cuando una máquina fallaba sin aviso: cuántas horas de producción se perdían, cuánto costaba la reparación de urgencia, cuántas órdenes se entregaban tarde.

Esto se repite con variaciones mínimas en logística, en cobranza, en atención al cliente. El patrón es el mismo: el comité aprueba una intención general, no una decisión operativa acotada. Se destina presupuesto a explorar proveedores y tecnología antes de escribir, con números, qué proceso concreto se va a intervenir, quién responde por ese proceso y qué le cuesta hoy a la empresa cuando ese proceso falla. Sin esas respuestas, cualquier "proyecto de IA" es en realidad un experimento sin dueño, y los experimentos sin dueño rara vez sobreviven al primer trimestre difícil.

El síntoma más caro no es que el proyecto fracase rápido: es que tarde meses en fracasar. Se contrata un proveedor, se arma un roadmap de doce meses, se paga la primera licencia, y recién en la tercera reunión de seguimiento alguien pregunta "¿pero esto qué tarea concreta está resolviendo?". Para entonces ya se gastó el presupuesto del año y la credibilidad interna que se necesitaba para pedir el siguiente proyecto.

Qué es un caso de uso de IA, en criterio de negocio

Antes de hablar de modelos, de proveedores o de pilotos, hay una pregunta que casi ninguna empresa responde por escrito con precisión: qué es, en criterio de negocio, un caso de uso de IA. No es una tecnología, no es un área completa de la empresa, no es un objetivo genérico de eficiencia. Es una decisión concreta y acotada, con nombre y apellido de quién responde por ella.

Fíjate en las palabras de esa definición. Decisión o tarea, no "iniciativa" ni "transformación". Concreta, no aspiracional. Con dueño, volumen y costo del error, no con "potencial" o "impacto esperado". Y de punta a punta: la inteligencia artificial no colabora ni sugiere sobre una parte del proceso, resuelve el ciclo completo de esa tarea específica, del inicio al resultado entregado.

Si a tu proyecto le falta cualquiera de esos cuatro elementos (decisión concreta, dueño, volumen, costo del error), no tienes un caso de uso: tienes una hipótesis. Las hipótesis se prueban con un método y con un tiempo acotado, no se presupuestan como si ya estuvieran validadas.

Qué distingue una idea, un deseo y un caso de uso real

En la práctica converso con equipos que usan la frase "caso de uso" para referirse a tres cosas completamente distintas, y esa mezcla explica buena parte de los proyectos de IA que nunca llegan a producción.

• La idea es la intuición inicial: "la inteligencia artificial nos puede ayudar en algún lado del negocio". No apunta a nada concreto, solo abre la conversación.
• El deseo es un paso más, pero sigue flotando: "queremos usar IA para mejorar el servicio". Nombra un área completa, no un proceso específico.
• El objetivo institucional es todavía más ambicioso y todavía menos operativo: "queremos ser una empresa impulsada por IA". Es una aspiración de directorio, no una unidad de trabajo asignable.
• El caso de uso es el único de los cuatro que se puede asignar a una persona un lunes por la mañana: tiene un proceso identificado, un dueño con nombre, un volumen medible y un costo del error conocido.
• Solo el caso de uso se puede aprobar o descartar en una reunión de treinta minutos; los otros tres pueden discutirse durante años sin que nadie se equivoque ni acierte, porque no hay nada concreto contra qué medir el acierto.

Esta escalera importa porque la mayoría de los comités de dirección aprueban presupuesto en el segundo o tercer escalón (el deseo o el objetivo institucional) creyendo que ya aprobaron un caso de uso. No lo hicieron. Solo aprobaron una intención.

Los cinco elementos que debe tener escrito para que exista

Cuando reviso una propuesta de proyecto de IA hago siempre el mismo ejercicio antes de hablar de tecnología: pido que alguien complete cinco espacios en blanco. Si no puede completarlos con precisión, ahí termina la conversación sobre herramientas, porque todavía no hay caso de uso, hay una intención con buena diapositiva.

• Proceso: el paso a paso exacto que se va a intervenir, no el área completa donde ese paso ocurre.
• Dueño: la persona que responde por el resultado día a día, no el patrocinador ejecutivo que firmó el presupuesto.
• Volumen: cuántas veces ocurre esa tarea en un mes típico, porque sin volumen suficiente no hay retorno que alcance para pagar la implementación ni el mantenimiento.
• Costo del error: qué pasa hoy, en plata o en tiempo, cuando esa tarea sale mal, porque ahí vive el techo real de lo que vale la pena invertir.
• Número objetivo: la meta concreta que se va a medir, en una fecha concreta, en lugar de una intención abierta como "mejorar la experiencia".

Estos cinco elementos no son un formulario burocrático: son la diferencia entre discutir sobre un proceso real de la empresa y discutir sobre una idea que suena bien en una presentación. Cuando alguno falta, casi siempre se puede rastrear ahí, meses después, el motivo exacto por el que el proyecto se estancó.

Una vez que existen dos o más casos de uso escritos con estos cinco elementos completos, la pregunta cambia: deja de ser qué es un caso de uso y pasa a ser cuál conviene implementar primero. Esa priorización tiene su propio criterio, que desarrollo en la guía de cómo elegir el primer caso de uso de IA, y no tiene sentido resolverla antes de tener al menos dos candidatos completos sobre la mesa.

El anti-patrón más común: confundir un área con un caso de uso

La frase "queremos IA en atención al cliente" no es un caso de uso, es un área completa de la empresa con docenas de procesos distintos adentro: restablecer contraseñas, consultar el estado de un pedido, procesar una devolución, escalar una queja, cotizar un servicio nuevo. Cada uno de esos procesos tiene su propio volumen, su propio dueño natural y su propio costo del error. Tratarlos como si fueran uno solo es la manera más rápida de gastar presupuesto sin poder medir nada al final.

Una empresa de servicios financieros mediana en Colombia vivió exactamente esto: el comité aprobó "IA en atención al cliente" como línea de presupuesto anual. Nueve meses después, al preguntar qué se había resuelto, la respuesta fue vaga, porque el "caso de uso" nunca dejó de ser un área. Cuando finalmente se dividió esa área en procesos individuales, apareció uno solo con volumen y costo del error suficientes para justificar una implementación: la clasificación del primer contacto de reclamos por tipo y urgencia, con el equipo de reclamos como dueño. Ese sí era un caso de uso; "atención al cliente" nunca lo fue.

Cuatro deseos mal formulados y su versión de caso de uso real

Ver el mismo deseo en sus dos versiones ayuda más que cualquier definición abstracta.

Mal formulado: "queremos IA para vender más". Bien formulado: clasificar los leads entrantes del formulario web según probabilidad real de cierre, con el equipo comercial como dueño, unos cientos de leads al mes, y el costo del error medido en horas de vendedor invertidas en contactos que nunca iban a comprar.

Mal formulado: "queremos usar IA en selección de personal". Bien formulado: filtrar el primer descarte de postulaciones para una vacante operativa específica, con el área de reclutamiento como dueña, varios cientos de postulaciones por proceso, y el costo del error medido en días adicionales de vacante abierta y en horas de reclutador revisando perfiles que no cumplen el mínimo del puesto.

Mal formulado: "queremos IA en finanzas". Bien formulado: conciliar automáticamente las facturas de proveedores contra las órdenes de compra correspondientes, con el área contable como dueña, miles de facturas al mes, y el costo del error medido en horas de analista corrigiendo descuadres que ya deberían haberse detectado antes del pago.

Mal formulado: "queremos un chatbot". Bien formulado: resolver las consultas repetitivas de estado de pedido dentro del canal de soporte, con el equipo de postventa como dueño, miles de conversaciones al mes, y el costo del error medido en tiempo de agente humano gastado en preguntas de bajo valor que no requieren criterio ni negociación.

En los cuatro casos, la versión mal formulada nombra una aspiración o una tecnología. La versión de caso de uso real nombra un proceso, un dueño, un volumen y un costo del error. Ese es el examen, siempre.

Mi criterio

Cuándo sí y cuándo no es un caso de uso real

No todo lo que suena a caso de uso está listo para convertirse en proyecto con presupuesto asignado. Antes de dar ese paso, vale la pena revisar señales concretas en ambos sentidos, no impresiones generales.

Señales de que el caso de uso está listo para avanzar

• Puede nombrarse un dueño operativo real, no solo un patrocinador ejecutivo que firma el presupuesto.
• El volumen mensual de la tarea está documentado con una cifra concreta, no con una impresión aproximada.
• Existe un costo del error conocido, aunque sea una estimación razonable, en horas de trabajo o en dinero.
• El proceso actual ya está mapeado paso a paso, incluyendo sus excepciones más frecuentes.
• Hay un número objetivo y una fecha definida para revisarlo, no una intención abierta sin plazo.

Señales de que todavía es un deseo, no un caso de uso

• La frase que lo describe nombra un área completa de la empresa, no un proceso específico dentro de ella.
• Nadie en la sala puede decir cuántas veces ocurre esa tarea en un mes típico.
• El presupuesto ya quedó aprobado, pero el dueño operativo todavía no está definido por escrito.
• La principal justificación es que la competencia ya lo está haciendo.
• El éxito se describe con adjetivos, como más eficiente o más moderno, y no con una cifra verificable en el tiempo.

Cierre

Un caso de uso de IA bien definido respeta un orden que casi nunca se respeta en la práctica: primero el dolor real de la operación, después el proceso concreto que lo produce, después el dato que existe (o no existe todavía) para resolverlo, y solo al final la herramienta que lo va a ejecutar. Cuando ese orden se invierte, y se elige la herramienta antes de escribir el proceso, el proyecto nace con la lógica cambiada: se busca dónde meter la tecnología en vez de preguntar qué tarea concreta merece resolverse de punta a punta.

Escribir los cinco elementos antes de firmar con un proveedor no es un trámite burocrático, es la diferencia entre un proyecto que sobrevive al primer trimestre difícil y uno que termina como anécdota de comité. Las empresas que más avanzan con inteligencia artificial no son las que más pilotos corren: son las que menos veces confunden un deseo con una decisión.