Una lista de cien ideas de IA suele ser menos útil que una conversación de una hora con la persona que resuelve las excepciones de un proceso. Esa persona sabe dónde se pierde tiempo, qué dato nunca llega y qué decisión obliga a rehacer el trabajo.
El problema no suele ser encontrar posibilidades. Es distinguir una oportunidad real de una demostración vistosa. “Crear un asistente para el departamento” todavía no es un caso de uso. “Preparar el primer borrador de respuesta a reclamaciones, usando el expediente y la política vigente, para que un especialista lo revise” sí empieza a serlo.
Empiece por el trabajo, no por la herramienta
La unidad de análisis debe ser el flujo de trabajo. Conviene anotar quién lo inicia, qué información recibe, qué entrega, con qué frecuencia ocurre y dónde aparecen esperas, errores o retrabajo. OpenAI propone precisamente observar frecuencia, repetibilidad y alcance como señales de valor, y separar ese valor de la complejidad de proceso, gobierno y sistemas (OpenAI Academy).
Hay una diferencia considerable entre “usar IA en compras” y “comparar las cláusulas de penalización de las ofertas recibidas con el pliego aprobado”. La segunda formulación permite comprobar si los documentos existen, quién valida la comparación y cuánto tarda hoy. También deja ver las excepciones: anexos ilegibles, condiciones expresadas de forma ambigua o cambios posteriores al cierre.
Una ficha mínima debería responder a seis preguntas:
| Pregunta | Qué buscamos |
|---|---|
| ¿Quién hace el trabajo? | Usuario y propietario del proceso |
| ¿Qué lo activa? | Evento, solicitud o calendario |
| ¿Qué entradas utiliza? | Datos, documentos, permisos y calidad |
| ¿Qué debe producir? | Resultado observable, no una capacidad genérica |
| ¿Qué ocurre si falla? | Impacto, reversibilidad y escalado |
| ¿Cómo funciona hoy? | Tiempo, coste, calidad y volumen de referencia |
Si no podemos describir el proceso sin mencionar un modelo, todavía nos falta entender el problema.
Valor: frecuencia, alcance y consecuencia
La frecuencia importa, pero no basta. Una tarea diaria que ahorra dos minutos puede valer menos que una revisión trimestral que evita una decisión de cientos de miles de euros. Por eso conviene mirar tres dimensiones juntas.
La primera es el volumen: cuántas veces ocurre y cuántas personas intervienen. La segunda es la fricción: esperas, cambios de sistema, búsquedas, correcciones y trabajo que se repite. La tercera es la consecuencia: qué mejora si el flujo funciona mejor. Puede ser capacidad liberada, menor tiempo de respuesta, más ventas, menos riesgo o una calidad más consistente.
Aquí aparecen con frecuencia estimaciones demasiado cómodas. Si veinte personas dedican “aproximadamente” diez horas semanales a una tarea, no debemos convertir de inmediato esas doscientas horas en ahorro. Parte del tiempo seguirá existiendo, habrá revisión y el tiempo liberado solo crea valor si se reasigna. La recomendación es fijar una línea base con unidad, periodo y método de medición antes de atribuir resultados (OpenAI Academy).
Viabilidad: la parte que estropea muchas listas
Dos casos con el mismo valor potencial pueden tener destinos opuestos. Uno usa documentos bien clasificados, tiene un responsable claro y se integra con una API estable. El otro depende de correos personales, conocimiento tácito y cinco aplicaciones sin conexión. La promesa de negocio puede ser idéntica; la posibilidad de implantarla no.
La viabilidad se entiende mejor al separar cuatro preguntas:
- ¿Disponemos de las entradas necesarias y tenemos derecho a utilizarlas?
- ¿Podemos evaluar el resultado con ejemplos reales y criterios acordados?
- ¿Existe una vía técnica para insertar la solución en el proceso?
- ¿Hay una persona responsable de adoptar, corregir y mantener el nuevo flujo?
La calidad del dato no significa perfección. Significa saber qué falta, qué está desactualizado y cuándo el sistema debe abstenerse. Un proyecto puede empezar con información imperfecta si la incertidumbre es visible y existe una ruta segura para las excepciones.
El riesgo puede cambiar por completo el orden
Una automatización que clasifica solicitudes internas no merece el mismo tratamiento que otra que bloquea pagos o filtra candidatos. El marco de NIST propone relacionar el contexto de uso, los requisitos, la tolerancia al riesgo y las mediciones a lo largo de la operación, no como una revisión aislada al final (NIST AI RMF).
Para priorizar, resultan especialmente útiles dos criterios: el impacto del error y su reversibilidad. Si una salida incorrecta se detecta rápido y se corrige sin daño, podemos probar con menos controles. Si una acción afecta a derechos, dinero, reputación o datos sensibles, necesitaremos permisos más estrictos, evaluación más amplia y supervisión humana. Eso reduce la velocidad y eleva el coste, aunque el caso siga siendo valioso.
El riesgo no siempre descarta. A veces cambia el alcance. En lugar de permitir que la IA apruebe una operación, puede preparar el expediente, señalar inconsistencias y dejar la decisión a una persona autorizada.
Una matriz útil, sin falsa precisión
Puntuar de uno a cinco cada criterio ayuda a comparar, pero una suma puede ocultar un bloqueo. Un caso con enorme valor y datos inaccesibles no es prioritario ahora. Es una oportunidad condicionada.
Nos funciona mejor una secuencia de tres filtros:
- Valor demostrado. Existe un problema frecuente o relevante y una línea base razonable.
- Condición mínima de ejecución. Hay propietario, entradas accesibles, forma de evaluar e integración posible.
- Riesgo aceptable para el alcance propuesto. Los controles y la intervención humana encajan con la consecuencia del error.
Después sí tiene sentido ubicar cada oportunidad en “ahora, después o más adelante”. La hoja de secuenciación de OpenAI añade una pregunta particularmente buena: cuál es la condición menos probada y cuál sería la evidencia mínima para resolverla (OpenAI Academy).
Pensemos en dos candidatos. El primero resume reuniones comerciales y actualiza el CRM con aprobación del vendedor. El segundo predice qué clientes cancelarán y activa descuentos. El segundo promete más ingresos, pero exige datos históricos fiables, una definición estable de cancelación, control del margen y una política de ofertas. El primero quizá produzca valor verificable en semanas. Priorizarlo no es falta de ambición; es comprar evidencia.
La prueba más pequeña que permita decidir
Un piloto útil no intenta demostrar que “la IA funciona”. Resuelve la incertidumbre principal. Si dudamos de la calidad, probamos con un conjunto representativo y criterios ciegos. Si preocupa la adopción, ejecutamos el flujo con usuarios reales. Si el obstáculo es la integración, validamos primero permisos, latencia y trazabilidad.
Antes de comenzar conviene dejar escrita la decisión del día 30 o 90: ampliar, rediseñar, mantener acotado o detener. También las condiciones. Por ejemplo: reducir un 25 % el tiempo de preparación sin aumentar correcciones graves, con al menos un 70 % de uso entre el equipo piloto. Sin umbrales, casi cualquier demostración acaba declarada “prometedora”.
La mejor cartera de IA no contiene las ideas más llamativas. Contiene una combinación deliberada de resultados cercanos, capacidades que conviene construir y apuestas cuya incertidumbre merece ser investigada. La pregunta final no es “¿dónde podemos poner IA?”, sino “¿qué evidencia necesitamos para invertir en esta oportunidad y no en la siguiente?”.
Preguntas frecuentes
¿Cuántos criterios debe tener la matriz?
Seis o siete suelen bastar: valor, frecuencia, alcance, viabilidad, datos, riesgo y capacidad de adopción. Más columnas dan apariencia de rigor, pero rara vez mejoran la decisión.
¿Debemos empezar siempre por un caso de bajo riesgo?
No necesariamente. Conviene empezar por un riesgo controlable y un resultado relevante. Un caso inocuo que nadie necesita tampoco crea aprendizaje útil.
¿Cómo comparamos beneficios distintos?
Defina una unidad para cada uno —horas, tiempo de ciclo, errores, conversión o exposición al riesgo— y evite sumarlos hasta disponer de una traducción económica defendible.
¿Quién debe participar en la priorización?
El propietario del proceso, usuarios que hacen el trabajo, tecnología, datos y, cuando corresponda, seguridad, legal o compliance. La decisión solo financiera suele ignorar las condiciones de operación.
¿Cuándo descartamos una idea?
Cuando no existe un problema comprobable, la consecuencia no justifica el esfuerzo o falta una condición que no se puede resolver razonablemente. Descartar pronto también es retorno.