Cómo definir el primer caso de uso de IA en tu empresa

Hay una distorsión que aparece una y otra vez: las empresas piensan en el primer caso como una prueba técnica. "Vamos a probar si la IA funciona". El problema es que la IA, en términos de motor, casi siempre funciona; lo que se está probando realmente es si la organización es capaz de incorporar IA con criterio, de medir el impacto y de sostener un sistema en el tiempo. Es una prueba de proceso, no de modelo.

Por eso un primer caso bien elegido no tiene que ser el más vistoso ni el más ambicioso. Tiene que ser el que mejor responda a cinco preguntas: hay datos disponibles, hay métrica clara, hay tolerancia razonable a errores, hay alguien con autoridad que lo necesita, y se puede meter en producción sin reorganizar la empresa. Esa combinación es más difícil de encontrar que parece, y descartarla por buscar el caso de mayor titular es uno de los errores más caros que vemos.

Estos son los criterios que aplicamos antes de empezar a hablar de tecnología. Si un caso candidato no pasa los cinco, normalmente no es el primer caso, aunque sea estratégico. Hay otros sitios mejores por donde empezar y volveremos al caso ambicioso cuando la organización tenga músculo para ejecutarlo.

• Datos accesibles. El caso puede usarse con datos que ya existen o que pueden conseguirse en semanas, no con datos que llevan dos años pendientes de integración. Si la respuesta a "¿están los datos?" empieza por "deberíamos antes…", no es el primer caso.
• Volumen suficiente. El proceso ocurre con frecuencia (decenas o cientos de veces a la semana). Si pasa tres veces al mes, el ahorro acumulado no justifica la inversión y no genera evidencia para defender el siguiente paso.
• Métrica clara antes de empezar. Existe una línea base que el negocio reconoce — tiempo medio de respuesta, calidad de salida, coste por operación, NPS, error rate — y un acuerdo previo sobre qué movimiento consideraríamos éxito. Si la métrica se define después, lo que se ha hecho es teatro.
• Tolerancia razonable a errores. Hay un humano en el bucle, una etapa de revisión, o el coste de un error es absorbible. Diagnósticos médicos, decisiones de crédito críticas o procesos jurídicos sensibles rara vez son buenos primeros casos: son destinos, no puntos de partida.
• Stakeholder con voz. Existe alguien que necesita el resultado, que tiene autoridad para defender el caso en el comité y que va a usar el sistema o forzar su uso. Sin esa figura, el caso muere por aburrimiento — no por fallar, sino por nadie reclamarlo.

Existen tres familias de primer caso que cumplen los cinco criterios en la mayoría de empresas. No son los más ambiciosos, pero son los que generan la curva de aprendizaje y la credibilidad necesarias para que el resto del programa de IA tenga recorrido. Cuando alguien nos pide una recomendación cerrada, casi siempre acabamos en una de estas tres.

• Asistente sobre documentación interna (RAG). Cubre preguntas frecuentes de empleados sobre RRHH, IT, finanzas o procedimientos operativos. Hay volumen, los datos viven en SharePoint, Confluence o intranets, la métrica es clara (tiempo de respuesta, deflexión de consultas a soporte), tolera errores porque siempre se puede contrastar con la fuente, y el stakeholder es la dirección de operaciones o de personas.
• Clasificación o resumen automático de entradas estructuradas. Tickets de soporte, emails comerciales, encuestas, comentarios de clientes, currículums. Hay volumen alto, la métrica es la precisión del clasificador o el tiempo ahorrado, los errores son corregibles humanamente, y el stakeholder es el responsable del proceso afectado.
• Generación asistida de contenido específico para tareas administrativas. Borradores de propuestas comerciales, fichas internas, resúmenes de reuniones, briefings, fichas de cuenta. No sustituye al humano, le quita la página en blanco. Métrica: tiempo dedicado al primer borrador. Stakeholder: responsable de marketing, ventas u operaciones.

Hemos visto los mismos errores repetirse en empresas muy distintas, y la mayoría tienen una raíz común: no resistir el caso vistoso. Es difícil decir que no a una propuesta brillante en una reunión de comité, pero la salud del programa de IA depende exactamente de eso. Estos son los cuatro errores que más han bloqueado proyectos en los que hemos entrado después.

• El caso del wow. Una idea espectacular en demo pero con datos que no existen, sin métrica acordada o con un perfil de error que el negocio no puede absorber. Suele venir de presentaciones inspiradoras y muere en la fase de discovery.
• El caso sin métrica. "Vamos a probar y a ver qué sale." El proyecto entrega algo funcional pero nadie tiene claro si ha funcionado, así que la pregunta del comité — ¿lo escalamos? — se queda sin respuesta defendible.
• El caso bloqueado por gobernanza. Idea válida pero con dependencias legales, contractuales o de cumplimiento que tardan más en resolverse que el propio proyecto técnico. El AI Act, RGPD o políticas internas a veces son razones de descarte legítimas, no obstáculos a saltar.
• El caso del proyecto transversal. Un caso que afecta a cinco departamentos y necesita el acuerdo de todos para arrancar. Posible, pero rara vez como primer caso. El primero debe poder empujarlo una sola persona si hace falta.

La fase de discovery existe precisamente para evitar perder meses construyendo el caso equivocado. Es una inversión pequeña (semanas, no meses) con un único objetivo: salir con una decisión defendible de seguir o parar. En DatIACode la planteamos como un mini-proyecto cerrado, con entregables claros y sin compromiso de continuidad.

1. 1. Workshop inicial con el stakeholder y el responsable técnico. Reconstruimos el proceso actual paso a paso y mapeamos dónde la IA podría entrar.

2. 2. Inventario de datos

   qué hay, dónde vive, qué calidad tiene, qué permisos requieren. Muchos casos se descartan aquí, lo cual es éxito.

3. 3. Definición de métrica

   línea base actual, objetivo realista a 3 meses y forma de medir. Si el negocio no firma esta métrica, paramos.

4. 4. Prototipo mínimo (2-3 semanas) con datos reales pero alcance acotado. Sirve para ver si la IA funciona en este contexto, no para producción.

5. 5. Revisión de viabilidad

   coste estimado de pasar a producción, esfuerzo de mantenimiento, riesgos regulatorios y dependencias internas.

6. 6. Decisión go / no-go con propuesta concreta. Si es go, ya hay alcance, presupuesto y arquitectura inicial sobre la mesa.

Antes de comprometer presupuesto, lleva el caso candidato a una página con estos campos cubiertos. Si no puedes rellenar alguno con claridad, ya tienes el primer trabajo: aclararlo. Esta plantilla no es exclusiva de IA — es la disciplina mínima de cualquier proyecto de transformación — pero en IA es especialmente útil porque tiende a venderse en abstracto.

• Caso de uso en una frase. Quién va a usar el sistema, para qué tarea y en qué momento del flujo actual entra.
• Línea base: cómo se hace hoy, cuánto cuesta (tiempo o dinero), qué métricas existen.
• Objetivo: qué movimiento de esa métrica consideraríamos éxito a tres meses y a doce meses.
• Datos requeridos: qué necesita el sistema, dónde están, permisos de acceso y limpieza estimada.
• Riesgos: regulatorios (AI Act, RGPD), reputacionales (errores visibles al cliente), técnicos (latencia, coste por petición).
• Stakeholder: quién defiende el caso, quién lo va a usar y quién decide si se mantiene.
• Coste estimado: discovery, prototipo, producción y mantenimiento anual.
• Decisión esperada: qué propone el equipo y qué necesita del comité.

El acompañamiento que ofrecemos en esta fase es exactamente lo que faltaba en la mayoría de empresas con las que hemos trabajado: criterio técnico aplicado al caso concreto del cliente, sin agenda comercial de vender el caso más grande. Sumamos consultoría, formación y desarrollo bajo un mismo equipo, así que la decisión que tomamos contigo es la que sostenemos después si decides ejecutarla.

Las formas más comunes en que entramos en esta fase son tres:

• Workshop de selección de primer caso (1-2 días). Tu equipo lleva 4-6 candidatos, salimos con un caso priorizado y un plan de discovery acotado.
• Discovery completa de un caso (3-4 semanas). Inventario de datos, prototipo, métrica firmada y decisión go/no-go en mano del cliente.
• Acompañamiento estratégico continuo (mensual). Si necesitas un sparring técnico recurrente para discutir nuevos candidatos a medida que aparecen, sin tener que contratar un proyecto completo cada vez.