Cómo definir un caso de uso de IA concreto y medible

Qué hace concreto a un caso de uso

«Usar IA en atención al cliente» no es un caso de uso; es un área. Un caso de uso concreto describe una tarea específica, quién la realiza, qué entra, qué sale, qué decide una persona y cómo se sabrá si ha mejorado. Cuanto más preciso sea, más fácil será estimar el esfuerzo, comparar propuestas de proveedores y medir resultados.

Una prueba sencilla: si dos proveedores leen tu descripción y te presentan soluciones muy diferentes, el caso de uso todavía es demasiado abierto. Si ambos entienden lo mismo y solo varían en cómo resolverlo, está bien definido.

El documento del Plan IA360 menciona la identificación de un caso de uso concreto como parte de la implantación del futuro Bono IA, junto al diagnóstico previo de madurez y la medición posterior del impacto en productividad. No hay convocatoria abierta ni bases que digan cómo debe documentarse; la ficha que sigue es una propuesta práctica para definirlo bien.

La ficha del caso de uso

Describe cada caso candidato con los mismos apartados. Una página por caso es suficiente, y tenerlos todos en el mismo formato permite compararlos sin que gane el que mejor se ha presentado.

El apartado de decisión humana es el que más se olvida. Define con claridad en qué punto revisa una persona y qué ocurre cuando la solución no está segura. Esa respuesta condiciona el diseño, el esfuerzo de revisión y, por tanto, el cálculo del ahorro.

• Proceso y objetivo: qué tarea se mejora y qué problema de negocio resuelve.
• Usuarios: quién trabajará con la solución y quién revisará sus resultados.
• Entrada: qué recibe la solución (correos, documentos, registros del ERP, llamadas transcritas).
• Salida: qué produce (una clasificación, un borrador, un dato extraído, una respuesta con fuente).
• Decisión humana: qué valida una persona antes de que el resultado tenga efecto.
• Datos y sistemas: qué fuentes necesita y con qué aplicaciones debe conectarse.
• Indicador principal: lo que se medirá antes y después, por ejemplo minutos por documento.
• Riesgos y límites: qué errores serían graves y qué queda fuera del alcance.

Cómo elegir entre varios candidatos

Lo habitual es tener varias ideas. Para elegir, puntúa cada candidato en unos pocos criterios con una escala de uno a tres. No buscas una fórmula exacta, sino una conversación ordenada que evite elegir por entusiasmo o por la última demostración que alguien vio.

Un buen primer caso combina valor medio o alto con riesgo bajo, datos disponibles y un responsable comprometido. Los casos de mucho valor pero alto riesgo, como respuestas automáticas sobre condiciones contractuales, suelen funcionar mejor en una segunda fase, cuando el equipo ya sabe revisar y medir.

Haz la puntuación en grupo, con la dirección, el responsable técnico y quien ejecuta los procesos. Las diferencias de puntuación entre unos y otros son lo más interesante: suelen revelar riesgos o carencias de datos que una sola persona no ve.

• Valor: cuánto tiempo, error o retraso elimina si funciona.
• Frecuencia: cuántas veces se repite la tarea; lo frecuente compensa mejor el esfuerzo.
• Datos disponibles: si existen ejemplos suficientes y accesibles.
• Riesgo: qué ocurre si la solución se equivoca y quién lo detectaría.
• Integración: si exige conectar varios sistemas o puede empezar de forma aislada.
• Patrocinio: si hay un responsable dispuesto a dedicarle tiempo.

Un ejemplo trabajado

Por ejemplo, una empresa de instalaciones y mantenimiento con 30 personas recibe avisos de averías por correo, teléfono y un formulario web. Una administrativa los lee, identifica cliente y contrato, clasifica la urgencia y crea la orden de trabajo en su programa de gestión. La dirección quiere «usar IA para los avisos».

Definido como caso de uso, quedaría así: la solución lee los avisos que llegan por correo y formulario (el teléfono queda fuera de esta fase), identifica el cliente y el contrato en el programa de gestión, propone un tipo de avería y una urgencia según reglas acordadas, y deja una orden de trabajo en borrador. La administrativa revisa y confirma. El indicador principal es el tiempo desde que llega el aviso hasta que existe la orden confirmada; el secundario, el número de órdenes con cliente o urgencia corregidos.

Con esa definición, el proveedor sabe qué integración necesita, la empresa sabe qué datos preparar (contratos actualizados y reglas de urgencia por escrito) y todos saben qué se medirá. También queda claro lo que no se promete: la solución no atiende llamadas ni decide prioridades por sí sola.

Señales de que el caso de uso no está maduro

Algunas señales indican que conviene trabajar más la definición antes de pedir propuestas o lanzar un piloto.

Ninguna de estas señales descarta el caso para siempre. Indican trabajo previo: medir la situación actual, escribir las reglas, preparar los datos o asignar un responsable con tiempo real para el proyecto.

• Nadie sabe cuánto tarda hoy la tarea ni cuántos errores tiene.
• Las reglas para resolver la tarea solo están en la cabeza de una persona.
• El caso depende de datos que no existen o que nadie mantiene.
• El objetivo es «automatizarlo del todo» sin definir qué pasa con las excepciones.
• El caso se ha elegido porque una herramienta lo hace bien, no porque resuelva un problema.
• No hay nadie con tiempo para revisar resultados durante la prueba.

Validar la definición antes de comprometerse

Antes de dar por cerrada la ficha, revísala con tres grupos: quien ejecuta la tarea, que detectará excepciones olvidadas; el responsable técnico, que confirmará si los datos y las conexiones existen; y la dirección, que validará si el indicador refleja el objetivo de negocio.

Después, contrasta la definición con una muestra real. Toma veinte o treinta casos recientes y recorre la ficha con ellos: ¿la entrada es la descrita?, ¿está clara la salida esperada para cada uno?, ¿cuántos quedarían fuera de alcance? Si una parte grande de la muestra no encaja, la definición necesita ajustes.

Una ficha validada es el punto de partida del piloto. Con ella ya tienes la pregunta que el piloto debe responder, los datos que necesitas preparar y el indicador que medirás antes y después.