Cómo priorizar casos de uso de IA por impacto y complejidad

La conversación sobre inteligencia artificial en muchos comités de dirección sigue el mismo guion: alguien trae una herramienta que ha visto, se abre un piloto, el piloto funciona razonablemente bien en una demostración y después nadie sabe explicar qué ha mejorado en la cuenta de resultados. Un año más tarde la empresa tiene cuatro pilotos vivos, ninguno en producción y una desconfianza creciente hacia el tema.

El problema no es la tecnología. Es que se está eligiendo por disponibilidad —lo que se puede probar rápido— en lugar de por criterio —lo que compensa construir. Este artículo describe el método que usamos para ordenar una cartera de casos de uso de IA de forma que la dirección pueda decidir con las mismas reglas que aplica a cualquier otra inversión.

Primero: un inventario honesto de candidatos

Antes de priorizar hay que tener qué priorizar, y conviene que la lista no salga solo del área de tecnología. Las mejores candidaturas aparecen preguntando a los responsables operativos dos cosas muy concretas: qué tarea repetitiva consume más horas de su equipo y qué decisión toman con información peor de la que les gustaría.

De esas conversaciones suelen salir entre veinte y cuarenta candidatos, y casi siempre pertenecen a cuatro familias:

• Extracción y clasificación de documentos: facturas, albaranes, contratos, pedidos por correo, partes de trabajo.
• Asistencia al conocimiento interno: buscar y sintetizar información dispersa en manuales, histórico de proyectos, tarifas o normativa.
• Apoyo a la decisión: previsión de demanda, detección de anomalías, priorización de cartera, puntuación de oportunidades.
• Interacción con clientes: primer nivel de atención, cualificación de entrantes, respuesta a peticiones estándar.

Anotar de qué familia es cada candidato ya aporta información: dentro de una misma familia, el segundo caso de uso siempre cuesta bastante menos que el primero, porque reutiliza integraciones, gobierno y aprendizaje.

Segundo: valorar el impacto en euros, no en adjetivos

“Ahorra mucho tiempo” no es un impacto, es una impresión. Para que la comparación entre casos sea posible hay que llevar todos al mismo denominador, y el más útil es el económico anual.

Hay tres formas legítimas de expresarlo, y conviene no mezclarlas:

1. Coste evitado. Horas liberadas multiplicadas por un coste horario cargado. Es el cálculo más fácil y el más frecuentemente inflado: solo cuenta si esas horas se reasignan a algo o si evitan una contratación real.
2. Ingreso influido. Más oportunidades atendidas, menos fugas en el proceso comercial, mejor tasa de retención. Exige poder atribuir el efecto, así que sea prudente.
3. Riesgo reducido. Errores de facturación, incumplimientos, penalizaciones, roturas de stock. Se estima como probabilidad por coste del incidente.

Una advertencia importante: las cifras que aparecen en esta fase son estimaciones de trabajo, no promesas. Sirven para ordenar una lista, no para comprometer un retorno ante el consejo. Nuestra recomendación es documentar siempre el supuesto que sostiene cada número, porque el debate del comité será sobre los supuestos, no sobre el resultado.

Tercero: medir la complejidad donde de verdad duele

La complejidad de un caso de uso de IA casi nunca está en el modelo. Está alrededor. Estos son los cinco factores que en nuestra experiencia mueven el coste y el plazo:

• Acceso al dato. ¿Existe, está accesible por API, tiene histórico suficiente, es de calidad aceptable? Un caso excelente sobre datos que nadie puede extraer es un caso inviable.
• Integración con el sistema de registro. Un resultado que hay que copiar a mano al ERP no ahorra trabajo: lo desplaza.
• Tolerancia al error. No es lo mismo sugerir una respuesta que un humano revisa que emitir un documento contable. Cuanto menor sea la tolerancia, más control, validación y trazabilidad hay que construir.
• Cambio de proceso y adopción. Si el caso obliga a que veinte personas trabajen de otra manera, el trabajo real es de gestión del cambio, no de tecnología.
• Exposición regulatoria y de datos personales. Determina el marco de gobierno, dónde puede residir el dato y qué evidencias hay que conservar.

Puntúe cada factor de 1 a 5 y quédese con la suma. No busque precisión: busque que dos casos que parecían iguales dejen de parecerlo.

Cuarto: colocar todo en una matriz y decidir

Con impacto anual estimado en un eje y complejidad en el otro, la cartera se ordena sola en cuatro zonas:

• Alto impacto y baja complejidad. Se ejecuta ya. Suele haber menos casos aquí de los que la organización espera, y son los que financian la credibilidad del programa.
• Alto impacto y alta complejidad. Se prepara. Requieren fase previa de datos, arquitectura o gobierno, y decisión explícita del comité sobre el presupuesto.
• Bajo impacto y baja complejidad. Se hacen si sobra capacidad, nunca a costa de los anteriores. Son buenos para entrenar al equipo interno.
• Bajo impacto y alta complejidad. Se descartan y se documenta por qué. Ese registro evita que el mismo caso vuelva a proponerse cada seis meses.

Una regla práctica que ahorra discusiones: ningún caso pasa a construcción sin un responsable de negocio que se comprometa a medir el resultado. Si nadie del negocio quiere firmar la métrica, el caso no importa lo suficiente.

Antes de construir, dos preguntas de gobierno

Aunque el caso gane en la matriz, conviene responder dos preguntas antes de escribir la primera línea de código:

• ¿Qué pasa cuando se equivoca? Todo sistema de IA falla algunas veces. Defina de antemano el circuito de revisión humana, el umbral de confianza y cómo se detecta la degradación con el paso del tiempo.
• ¿Quién lo mantiene? Un caso de uso en producción tiene coste recurrente: revisión de calidad, cambios en las fuentes, actualizaciones de modelo, consumo. Si ese coste no está presupuestado, el ahorro estimado es ficticio.

Empezar pequeño, pero empezar en producción

El error más caro de esta etapa no es elegir mal el caso: es quedarse en piloto. Un piloto que nunca entra en producción consume presupuesto, ocupa a los mejores perfiles y genera la conclusión equivocada de que “la IA no funciona aquí”.

Es preferible reducir el alcance hasta que quepa en producción —un tipo de documento, un equipo, una línea de producto— que ampliar el alcance para que el piloto luzca mejor. El primer caso de uso tiene una misión adicional a la suya propia: dejar montado el camino por el que pasarán los siguientes.

En BGS Data ese trabajo de ordenación es el AI Opportunity Map: un inventario de casos de uso valorados por impacto, complejidad, riesgo y dependencias, con una recomendación de secuencia y el marco de gobierno mínimo para llevar el primero a producción. Si tiene sobre la mesa varias ideas de IA y ninguna forma clara de compararlas, podemos revisarlo en un diagnóstico ejecutivo o por contacto directo.