Cómo priorizar oportunidades de IA: impacto, viabilidad, riesgo y datos

Cuando una empresa empieza a plantearse seriamente la incorporación de Inteligencia Artificial a sus procesos, una de las primeras dificultades suele ser decidir por dónde empezar. Ideas aparecen enseguida: automatizar una tarea administrativa, clasificar documentación, ayudar a un equipo a consultar información interna, revisar incidencias, generar borradores o incorporar algún tipo de asistente. Basta con reunir durante una hora a responsables de varios departamentos para terminar con una lista considerable de posibles aplicaciones.

Tener muchas ideas, sin embargo, no significa tener una hoja de ruta. De hecho, es precisamente en ese momento cuando empieza una parte del trabajo que suele recibir menos atención: determinar qué oportunidades justifican realmente la inversión y cuáles deberían esperar.

Una forma bastante habitual de abordar esta cuestión consiste en partir de la tecnología disponible. Se prueba una herramienta, se descubre una capacidad interesante y después se buscan procesos en los que utilizarla. El planteamiento puede servir para experimentar, pero resulta bastante menos útil cuando hay que decidir dónde invertir recursos de verdad, porque termina condicionando el problema a la solución que ya tenemos delante.

En Mitnix preferimos partir de los procesos y de los problemas que existen alrededor de ellos. Una vez identificados, analizamos si la IA puede aportar una mejora suficiente y en qué condiciones tendría sentido hacerlo. Durante ese análisis utilizamos cuatro dimensiones que, aunque no resuelven por sí solas la decisión, permiten comparar oportunidades con bastante más criterio: impacto, viabilidad, riesgo y disponibilidad y calidad de los datos.

La combinación es importante. Un proceso puede tener un retorno potencial enorme y ser un pésimo candidato para empezar si depende de información que la empresa todavía no puede proporcionar de manera fiable. Otro puede ser extremadamente sencillo de automatizar y, después de hacer números, resultar irrelevante para la operación. También encontraremos iniciativas interesantes cuyo principal problema no sea tecnológico, sino el riesgo que asumiríamos dejando determinadas decisiones en manos de un sistema automático.

Por eso conviene analizar las cuatro dimensiones en conjunto.

---

1. Impacto: entender qué mejora y cuánto importa

La primera cuestión que intentamos aclarar es bastante sencilla de formular, aunque no siempre sea tan fácil de responder: si conseguimos mejorar este proceso, ¿qué cambia realmente para la empresa?

En las primeras conversaciones aparecen con frecuencia respuestas como «ahorraremos tiempo», «reduciremos errores» o «seremos más eficientes». Todas pueden ser ciertas, pero todavía dicen poco sobre el valor de una iniciativa. Para poder comparar oportunidades necesitamos acercarnos algo más al funcionamiento cotidiano del proceso y, siempre que sea posible, poner cifras.

El impacto puede proceder de reducir horas de trabajo, disminuir errores, evitar costes, aumentar la capacidad de un equipo sin incrementar proporcionalmente sus recursos, mejorar tiempos de respuesta, reducir riesgos o permitir que determinados profesionales dejen de dedicar parte de su jornada a tareas que no requieren realmente su conocimiento. También puede existir un impacto comercial directo, por ejemplo cuando una mejora permite responder antes a oportunidades de venta, atender más solicitudes o reducir abandonos.

La frecuencia del proceso suele ser uno de los primeros datos que merece la pena revisar. Ahorrar diez minutos en una tarea realizada unas pocas veces al año difícilmente justificará por sí solo un proyecto, mientras que reducir dos minutos en una operación que se repite cientos de miles de veces puede tener un efecto considerable. Aun así, tampoco deberíamos utilizar únicamente el volumen como criterio. Hay procesos poco frecuentes en los que un solo error puede generar una pérdida económica importante, retrasar una operación durante días o provocar consecuencias contractuales. En ellos, el valor puede estar mucho más relacionado con la reducción de errores que con las horas ahorradas.

Para hacer una estimación razonable conviene conocer cuántas veces se ejecuta el proceso, quién participa, cuánto tiempo consume, qué coste tiene actualmente y qué ocurre cuando algo sale mal. También interesa conocer sus dependencias: una tarea aparentemente pequeña puede estar provocando retrasos en varios procesos posteriores y tener, por tanto, un impacto bastante mayor del que refleja su coste directo.

No siempre encontraremos todas estas métricas disponibles. Es habitual que una empresa conozca bien determinados indicadores comerciales o financieros y, sin embargo, nunca haya medido cuánto tiempo consume una operación interna concreta. En ese caso habrá que estimarlo, observar una muestra o medir durante un periodo antes de tomar una decisión. Esa falta de información también nos dice algo sobre el nivel de definición del proceso.

Lo importante en esta fase es disponer de una hipótesis que podamos contrastar posteriormente. Si afirmamos que una automatización reducirá carga administrativa, deberíamos saber qué carga existe actualmente y qué indicador utilizaremos después para comprobarlo. Sin una referencia de partida es muy fácil terminar un proyecto técnicamente correcto sin saber si ha aportado el valor que justificó iniciarlo.

---

2. Viabilidad: llevar una idea hasta producción cambia bastante las cosas

Una oportunidad puede tener un impacto muy atractivo y seguir sin ser una buena candidata para ejecutarse inmediatamente. La razón suele aparecer cuando dejamos de analizar lo que queremos conseguir y empezamos a estudiar cómo funciona realmente el proceso dentro de la empresa.

En una prueba de concepto podemos trabajar con un conjunto de documentos seleccionado previamente, preparar datos de forma manual y conectar únicamente los sistemas imprescindibles para validar una hipótesis. En producción desaparece buena parte de esa comodidad. La solución tendrá que convivir con aplicaciones existentes, permisos, restricciones de infraestructura, información incompleta, excepciones y dependencias que quizá llevan años formando parte de la operativa.

Por eso la viabilidad técnica empieza por algo bastante poco sofisticado: inventariar qué sistemas intervienen y comprobar de qué manera podemos trabajar con ellos. Necesitamos saber si disponemos de APIs, cómo accederemos a la información, qué volumen tendremos que procesar, qué latencia exige el proceso y qué infraestructura existe. También debemos identificar dependencias externas y sistemas legacy, porque pueden cambiar considerablemente el alcance del proyecto.

No es raro comenzar analizando una automatización que parece sencilla y descubrir después que necesita combinar información de un ERP, una aplicación desarrollada hace quince años, varios documentos almacenados en SharePoint y una hoja de cálculo mantenida manualmente por un departamento. La capacidad de IA que queríamos utilizar puede seguir siendo relativamente sencilla, pero ya hemos descubierto que buena parte del esfuerzo estará en conseguir que la información llegue de forma consistente.

Esta situación es importante porque evita atribuir a la IA una complejidad que en realidad pertenece a la arquitectura de la empresa. En muchos proyectos empresariales, conseguir una respuesta aceptable de un modelo es bastante menos complicado que integrar esa respuesta de manera fiable en el proceso existente.

La viabilidad tampoco termina en los sistemas. Hay que entender cómo se realiza el trabajo de verdad, y para ello resulta imprescindible hablar con las personas que lo ejecutan. Los procedimientos documentados son útiles como punto de partida, pero rara vez contienen todas las excepciones que han aparecido con el tiempo. Puede haber controles manuales introducidos después de una incidencia, decisiones que dependen de experiencia acumulada, pasos que siguen figurando en el procedimiento aunque ya no se hagan o tareas que todo el departamento conoce pero nadie llegó a documentar.

Estas diferencias tienen consecuencias directas sobre el diseño. Si automatizamos el proceso que figura en un documento sin comprender el que realmente utiliza el equipo, probablemente descubriremos las excepciones cuando el sistema ya esté construido.

También hay que identificar quién tiene autoridad para decidir qué debe ocurrir en los casos dudosos. Cuando un proyecto empieza a sacar a la superficie excepciones que llevan años resolviéndose mediante criterio informal, alguien tendrá que convertir parte de ese criterio en reglas, controles o procedimientos. Si nadie es propietario del proceso, conseguir esas decisiones puede acabar siendo uno de los mayores bloqueos del proyecto.

Por último está el mantenimiento, que debería entrar en la conversación bastante antes de llegar a producción. Las APIs cambian, los permisos caducan, aparecen nuevos tipos de documentos, se sustituyen aplicaciones y los procesos evolucionan. Una solución que solo puede mantenerse con la presencia continua del equipo que la desarrolló puede funcionar técnicamente y seguir siendo una mala solución para esa organización.

---

3. Riesgo: no todos los errores cuestan lo mismo

Al analizar riesgo conviene asumir desde el principio que en algún momento algo no funcionará como esperamos. Puede equivocarse un modelo, fallar una integración, cambiar el formato de un dato o aparecer una situación que no contemplamos durante las pruebas. Diseñar partiendo de esa posibilidad resulta bastante más útil que intentar construir un sistema alrededor de la expectativa de que nunca ocurrirá.

Lo que necesitamos conocer es la consecuencia de ese fallo.

Una clasificación incorrecta de documentación interna puede obligar a una persona a corregir posteriormente una categoría. La misma tasa de error aplicada a una automatización que autoriza operaciones financieras, modifica datos contables o genera comunicaciones externas puede tener implicaciones completamente distintas. Por eso una métrica de precisión, utilizada de forma aislada, no permite determinar si una solución es suficientemente segura para producción.

El análisis debería tener en cuenta el impacto económico, las posibles implicaciones legales, la información a la que accede el sistema, la exposición reputacional y la facilidad con la que podemos revertir una acción. También necesitamos saber si podremos reconstruir posteriormente qué ocurrió: qué información recibió el sistema, qué decisión tomó, qué reglas se aplicaron y qué acción terminó ejecutándose.

Esta trazabilidad se vuelve especialmente importante a medida que aumenta la autonomía. Si una solución únicamente prepara un borrador que después revisa una persona, el control puede estar en esa revisión. Cuando el sistema empieza a ejecutar acciones directamente, necesitamos trasladar parte de ese control a otros mecanismos.

La supervisión humana es uno de ellos, aunque tampoco conviene utilizarla como respuesta automática a cualquier riesgo. Obligar a una persona a revisar el cien por cien de las operaciones puede terminar reproduciendo buena parte del trabajo que queríamos eliminar y, además, generar un problema conocido: cuando un sistema acierta casi siempre, la revisión humana tiende a convertirse con el tiempo en una validación rutinaria.

En muchos casos tiene más sentido decidir qué situaciones requieren intervención. Podemos establecer límites económicos, identificar determinados tipos de operación, solicitar revisión cuando la confianza sea insuficiente o detener el flujo cuando aparezca una excepción que el sistema no sabe gestionar. El diseño concreto dependerá del proceso, pero debería responder a las consecuencias de equivocarse y no simplemente a cuánto puede automatizar la tecnología.

También necesitamos mecanismos de parada y recuperación. Si una automatización empieza a comportarse de forma inesperada, deberíamos poder detenerla sin tener que desmontar media arquitectura y, cuando sea posible, revertir las acciones realizadas. Este tipo de cuestiones puede parecer excesivo durante una prueba pequeña; deja de parecerlo bastante rápido cuando el sistema empieza a ejecutar cientos o miles de operaciones.

---

4. Datos: comprobar qué tenemos antes de diseñar alrededor de lo que suponemos

Muchos casos de uso resultan convincentes mientras hablamos de los datos de manera abstracta. La situación cambia cuando empezamos a examinarlos.

En una organización real es normal encontrar campos incompletos, duplicados, distintas convenciones para representar la misma información y registros históricos cuyo significado ha cambiado con los años. También es habitual que los datos necesarios para un proceso estén repartidos entre varias aplicaciones. Parte puede encontrarse en el ERP, otra en el CRM, determinados documentos en SharePoint y algún dato imprescindible en una hoja de cálculo que, oficialmente, era solo una solución temporal.

Nada de esto impide necesariamente utilizar IA, pero sí afecta al esfuerzo y a la fiabilidad que podemos esperar.

Antes de priorizar una oportunidad necesitamos comprobar si la información necesaria existe, si podemos acceder a ella y si tiene calidad suficiente para el uso previsto. La calidad necesaria tampoco es absoluta; depende del proceso. Un sistema utilizado para ayudar a localizar documentación puede tolerar determinados errores que serían inaceptables en una automatización que modifica información financiera.

Además de analizar el estado actual hay que pensar en cómo se generan esos datos. Podemos dedicar varias semanas a limpiar información histórica y obtener un conjunto excelente para entrenar, configurar o validar una solución. Si los sistemas de origen continúan generando registros con los mismos problemas, al cabo de unos meses estaremos de nuevo en el punto inicial.

Esta diferencia entre una prueba y producción merece especial atención. Para validar una idea es completamente razonable seleccionar una muestra, corregir errores y trabajar con un conjunto controlado. Lo que no deberíamos hacer es extrapolar directamente ese resultado al comportamiento que tendremos cuando la solución reciba información sin preparar.

En producción aparecerán documentos con formatos nuevos, campos vacíos, registros duplicados y errores de integración. Habrá información introducida por usuarios de maneras que no habíamos previsto y sistemas que temporalmente no estarán disponibles. El diseño tiene que contemplar qué hacer en esas situaciones: rechazar el registro, solicitar una corrección, aplicar un tratamiento alternativo o enviar el caso a revisión.

Esperar a disponer de datos perfectos tampoco sería una estrategia realista. La cuestión es conocer suficientemente bien sus limitaciones para decidir si podemos trabajar con ellas y qué controles necesitaremos.

---

Una matriz para ordenar la discusión

Después de analizar estos aspectos podemos utilizar una matriz sencilla para comparar oportunidades. Una escala del 1 al 5 suele ser suficiente para una primera valoración.

Dimensión	1	3	5
Impacto	Bajo	Moderado	Muy alto
Viabilidad	Difícil	Factible con dependencias	Alta
Riesgo	Alto	Controlable	Bajo
Datos	Insuficientes	Utilizables con trabajo	Disponibles y fiables

La puntuación es útil siempre que recordemos para qué sirve. No estamos intentando convertir una decisión empresarial en una suma de cuatro números, sino hacer explícitas las razones por las que una oportunidad parece mejor o peor que otra.

Podemos tener, por ejemplo, una primera valoración como esta:

Oportunidad	Impacto	Viabilidad	Riesgo	Datos
Clasificación automática de solicitudes	4	5	4	5
Generación automática de contratos	5	3	2	4
Resumen interno de documentación	3	5	5	5
Decisión automática sobre incidencias críticas	5	2	1	3

Si sumamos las puntuaciones estaremos perdiendo parte de la información que acabamos de obtener. Dos proyectos pueden terminar con una valoración total parecida y tener perfiles completamente distintos. Uno puede ofrecer un retorno enorme acompañado de un riesgo elevado, mientras otro aporta un beneficio más modesto pero puede ponerse en producción con rapidez y con pocas dependencias.

La elección dependerá también de la situación de la empresa. Una organización que ya tiene experiencia desplegando este tipo de soluciones, cuenta con controles consolidados y dispone de una arquitectura preparada puede asumir un proyecto que sería una elección bastante discutible para otra que está realizando su primera implantación.

Precisamente por eso interesa conservar las dimensiones separadas. La matriz proporciona una base común para discutir prioridades sin reducir toda la decisión a una impresión general sobre qué idea parece más interesante.

---

El valor de un proyecto no depende de cuánto se note que utiliza IA

Una parte considerable de las oportunidades con mejor retorno son poco visibles desde fuera. No tienen necesariamente una interfaz conversacional ni producen una demostración especialmente llamativa, y en algunos casos el usuario ni siquiera necesita saber que existe un modelo participando en el proceso.

Pensemos en una automatización que durante la noche analiza solicitudes recibidas, extrae determinados datos, contrasta información con otros sistemas y deja preparado un orden de prioridad para el equipo que empieza a trabajar por la mañana. Desde el punto de vista de una demostración puede resultar menos atractiva que un asistente respondiendo preguntas en tiempo real, pero si elimina cientos de horas mensuales y reduce retrasos operativos, la comparación empresarial es bastante sencilla.

La clasificación de información, extracción documental, detección de anomalías, conciliación entre sistemas, recuperación de conocimiento interno, preparación de borradores o apoyo en revisiones masivas son buenos ejemplos de aplicaciones que pueden generar valor sin necesidad de convertir la IA en la parte visible del producto.

Esto también ayuda a evitar otro problema: introducir una interfaz o un nivel de autonomía que el proceso no necesita únicamente porque asociamos la IA con una determinada forma de utilizarla. Si podemos resolver una necesidad mediante un flujo sencillo que utiliza un modelo en un punto concreto, probablemente no necesitemos construir un agente autónomo alrededor.

La arquitectura debería responder al problema que estamos resolviendo y al retorno esperado. Todo lo demás añade coste, superficie de fallo y mantenimiento.

---

Algunas oportunidades necesitan trabajo previo

Durante la priorización aparecerán proyectos interesantes que todavía no están en condiciones de empezar. Conviene distinguirlos de aquellos que simplemente tienen poco valor, porque el tratamiento posterior es diferente.

Si nadie es claramente responsable del proceso, no tenemos métricas mínimas sobre su funcionamiento, las reglas cambian continuamente o los datos presentan problemas importantes, puede ser necesario trabajar primero sobre esas condiciones. Lo mismo ocurre cuando existe una integración crítica sin resolver, no podemos limitar adecuadamente las consecuencias de un error o la empresa no tiene capacidad para mantener la solución una vez implantada.

En ocasiones el propio análisis de IA pone de manifiesto un problema anterior. Podemos descubrir que antes de automatizar necesitamos rediseñar un proceso que ha ido acumulando excepciones durante años, o que sería conveniente unificar información que distintos departamentos mantienen por separado. Resolverlo puede mejorar la operación incluso antes de introducir ninguna capacidad de IA.

Por eso aplazar una iniciativa no debería interpretarse necesariamente como un resultado negativo. Si hemos identificado que el proyecto tiene potencial y sabemos qué dependencias debemos resolver para hacerlo viable, ya tenemos una decisión útil y una posible línea de trabajo.

Lo que conviene evitar es iniciar el desarrollo esperando que esos problemas se resuelvan durante el proyecto. A veces ocurre; otras veces terminamos utilizando el presupuesto destinado a la automatización para arreglar problemas estructurales que deberían haberse identificado antes.

---

De las oportunidades a una cartera de proyectos

Después del análisis podemos agrupar las iniciativas según su situación. Algunas estarán preparadas para avanzar porque combinan un impacto suficiente con una viabilidad razonable, riesgo controlado y datos adecuados. Otras necesitarán trabajo previo en integración, datos, seguridad, gobierno o definición del proceso. También habrá casos en los que una prueba acotada sea la mejor forma de resolver una incertidumbre antes de comprometer más recursos, y finalmente encontraremos oportunidades cuyo retorno actual no justifica el esfuerzo o el riesgo.

Podemos utilizar categorías como prioridad inmediata, preparar primero, experimentar y descartar por ahora, aunque el nombre concreto es lo de menos. Lo importante es que cada oportunidad termine en una situación que implique una decisión.

Una lista de cuarenta ideas marcadas como «interesantes» no ayuda demasiado a decidir qué hacemos el lunes siguiente.

Además, incluso después de seleccionar buenos candidatos aparece una limitación adicional: los proyectos comparten recursos.

Podemos identificar cinco iniciativas perfectamente viables y descubrir que todas necesitan a las mismas dos personas de sistemas, que tres requieren cambios en el ERP y que varias dependen de un departamento que ya está participando en otros proyectos. Cada iniciativa puede ser razonable de manera individual y el conjunto resultar imposible de ejecutar en el mismo periodo.

La capacidad disponible tampoco se limita a las horas de desarrollo. Los responsables de proceso tienen que participar, los usuarios deben validar resultados, seguridad tendrá que revisar determinados componentes y alguien tendrá que tomar decisiones cuando aparezcan excepciones. Todas esas personas continúan, además, con su trabajo habitual.

Por eso, cuando existen varios candidatos, conviene plantear la priorización como una decisión de portfolio. Ya no estamos intentando determinar únicamente si un proyecto tiene sentido, sino si es la mejor utilización de los recursos disponibles en ese momento.

Una pregunta bastante útil en estas situaciones es qué iniciativa elegiríamos si durante el próximo trimestre solo pudiéramos iniciar una. Obliga a comparar de verdad y suele producir una conversación bastante más concreta que asignar prioridades alta, media y baja a una hoja de cálculo.

---

Qué buscar en un primer proyecto

Cuando una organización todavía no tiene experiencia llevando soluciones de IA a producción, el primer proyecto proporciona información que va bastante más allá del caso de uso elegido.

Durante su ejecución aparecerán cuestiones relacionadas con accesos, seguridad, integración, monitorización, costes, gestión de incidencias y mantenimiento. También veremos hasta qué punto los procedimientos internos existentes sirven para este tipo de soluciones y cómo reaccionan los usuarios cuando una parte de su forma de trabajar cambia.

Por eso suele ser razonable elegir un primer caso que tenga retorno suficiente para justificar la inversión, pero que permita aprender sin introducir desde el principio consecuencias difíciles de controlar. No tiene por qué ser el proyecto más pequeño ni el más sencillo; simplemente interesa que exista cierto margen para ajustar la solución mientras la organización desarrolla experiencia.

Ese primer despliegue debería ayudarnos a comprobar cómo gestionamos la integración con sistemas corporativos, permisos, seguridad, observabilidad, métricas, cambios en el proceso y mantenimiento posterior. Es probable que algunas decisiones que parecían correctas sobre el papel tengan que modificarse después de unas semanas de uso real.

Si documentamos esas decisiones y los problemas encontrados, parte del esfuerzo realizado deja de pertenecer exclusivamente al primer caso de uso. Los siguientes proyectos podrán reutilizar arquitectura, controles, procedimientos, integraciones e incluso criterios de evaluación que ya hemos probado en producción.

Ahí empieza a aparecer una capacidad organizativa que resulta bastante más valiosa que acumular pruebas de concepto independientes.

---

Antes de construir la hoja de ruta hay que conocer el punto de partida

La misma oportunidad puede ser prioritaria para una empresa y prematura para otra. La diferencia puede estar en sus datos, en la arquitectura tecnológica, en la definición de sus procesos, en los controles de seguridad disponibles o simplemente en la experiencia que tiene operando automatizaciones.

Imaginemos dos organizaciones que quieren aplicar IA al mismo proceso y estiman un retorno similar. Una dispone de información centralizada, APIs, responsables claros y mecanismos de monitorización ya utilizados en otros sistemas. La otra necesita obtener los datos de varias aplicaciones aisladas, tiene problemas de calidad y todavía no ha definido quién será responsable de operar la solución.

El caso de uso es parecido, pero el proyecto que tendrá que ejecutar cada empresa no lo es.

Esta es la razón por la que una hoja de ruta de IA debería construirse teniendo en cuenta tanto las oportunidades como la capacidad actual de la organización para ejecutarlas. Procesos, datos, tecnología, seguridad y gobierno condicionan el orden en el que tiene sentido avanzar y permiten identificar trabajo previo que, de otro modo, aparecería cuando el proyecto ya estuviera en marcha.

Evaluar esa madurez no consiste en decidir mediante una etiqueta si una empresa está o no «preparada para la IA». La utilidad está en conocer qué puede abordar razonablemente hoy, qué limitaciones debe tener en cuenta y qué capacidades necesita desarrollar para afrontar después proyectos de mayor alcance.

Si quieres analizar ese punto de partida de forma estructurada, puedes realizar nuestro diagnóstico de preparación para IA y obtener una primera visión de las áreas que ya están preparadas y de aquellas que convendría reforzar antes de abordar determinadas iniciativas.

Evaluar la preparación de tu organización