Comprar una herramienta de inteligencia artificial no convierte un proceso confuso en uno fiable. Si el equipo no comparte una forma de trabajar, las excepciones viven en mensajes privados y nadie sabe qué hacer cuando algo falla, la tecnología solo acelerará una parte del desorden.
La pregunta útil no es «¿dónde podemos poner IA?», sino «¿qué flujo merece cambiar, qué resultado esperamos y cómo mantendremos el control?». Este marco ayuda a responderla sin prometer ahorros antes de medirlos.
1. Describe el proceso real, no el procedimiento ideal
Empieza con un caso concreto y reciente. Sigue una solicitud desde que entra hasta que queda resuelta: quién la recibe, qué información consulta, qué decisiones toma, qué herramientas utiliza y qué entrega al siguiente paso. Las instrucciones oficiales suelen omitir atajos, esperas y correcciones; observar un caso real permite descubrirlos.
El mapa inicial puede ser sencillo. Para cada paso anota entrada, acción, salida, responsable, herramienta y tiempo de espera. Añade una marca cuando alguien tenga que interpretar información, pedir datos que faltan o decidir fuera de la regla habitual.
No hace falta modelar toda la empresa. Basta un flujo con límites claros: por ejemplo, desde la recepción de una solicitud hasta su clasificación, o desde la llegada de una factura hasta que queda preparada para revisión.
2. Puntúa seis criterios antes de priorizar
Una matriz no decide por ti, pero obliga a comparar candidatos con el mismo lenguaje. Valora cada proceso con una escala corta —por ejemplo, bajo, medio y alto— y conserva la evidencia utilizada.
- Frecuencia y volumen. ¿Cuántas veces ocurre el flujo y cómo cambia la carga? Un proceso frecuente ofrece más oportunidades de aprendizaje, pero el volumen por sí solo no justifica automatizar.
- Estabilidad. ¿Los pasos y las reglas se repiten o cambian cada semana? Automatizar una regla todavía inestable suele trasladar el retrabajo al sistema.
- Excepciones. ¿Qué proporción de casos requiere contexto, negociación o una autorización especial? Registra el tipo de excepción, quién la resuelve y cómo vuelve al flujo.
- Calidad de la información. ¿Las entradas están disponibles, son legibles y tienen un significado compartido? Si faltan datos o cada equipo usa categorías distintas, esa deuda debe formar parte del alcance.
- Impacto y riesgo. ¿Qué ocurre si el sistema se equivoca, se retrasa o deja de responder? Aumenta la supervisión cuando haya consecuencias para clientes, dinero, seguridad, derechos o cumplimiento.
- Reversibilidad. ¿Puedes detener el flujo, recuperar el estado anterior y continuar manualmente? Un primer piloto debe tener una salida practicable, no solo una copia de seguridad teórica.
La conclusión no tiene que ser «automatizar» o «no automatizar». Puede ser documentar primero, simplificar una regla, mejorar la captura de datos o crear una ayuda para que una persona decida mejor.
3. Separa automatización clásica, asistencia con IA y decisión humana
Muchos problemas operativos no necesitan IA. Si las entradas son estructuradas y las reglas son explícitas, una integración, una validación o un workflow determinista suele ser más fácil de probar y mantener.
La IA puede ser útil cuando la tarea exige clasificar texto, extraer información de documentos, resumir, generar una propuesta o detectar patrones. En esos casos no basta con comprobar que una demostración funciona: hay que definir datos de prueba, calidad mínima, casos límite y qué hará la persona responsable cuando la salida sea incierta.
El AI Risk Management Framework de NIST propone establecer el contexto y el propósito, delimitar el alcance y documentar la supervisión humana. Es una buena disciplina incluso para pilotos pequeños: primero se entiende dónde operará el sistema y después se mide si es apropiado.
El marco de rendición de cuentas de la GAO agrupa las prácticas en gobernanza, datos, rendimiento y monitorización. Traducido a una decisión operativa: alguien debe ser dueño del resultado, los datos deben ser adecuados, el comportamiento debe evaluarse y el seguimiento continúa después del lanzamiento.
4. Elige un piloto que pueda aprender y detenerse
El mejor primer proceso no siempre es el de mayor impacto. Conviene elegir uno suficientemente valioso para que el aprendizaje importe, pero lo bastante acotado para observarlo, corregirlo y revertirlo sin comprometer la operación.
Antes de empezar, deja por escrito:
- El inicio y el final del flujo, incluyendo los casos que quedan fuera.
- La persona propietaria del proceso y quién puede detener el piloto.
- La métrica de partida y el resultado que se observará: tiempo de ciclo, retrabajo, errores detectados, cumplimiento del plazo o carga de revisión.
- La muestra con la que se probará, incluyendo casos normales y excepciones conocidas.
- El punto de control humano y los criterios para aceptar, corregir o rechazar una salida.
- El procedimiento de reversión y cómo se conservará la trazabilidad.
Evita convertir una hipótesis en una promesa comercial. El piloto sirve para obtener evidencia en tu contexto; solo después podrás decidir si ampliar, rediseñar o retirar la solución.
5. Usa una matriz de decisión sencilla
Puedes ordenar los candidatos en cuatro zonas:
- Alta repetición y pocas excepciones: buen candidato para automatización determinista.
- Alta repetición y excepciones identificables: candidato para un flujo híbrido, con reglas claras y escalado a una persona.
- Información no estructurada y resultado verificable: posible asistencia con IA, siempre con evaluación y límites.
- Proceso cambiante, sin propietario o con consecuencias difíciles de revertir: primero aclarar el proceso y su gobernanza.
La matriz es un punto de partida, no una fórmula universal. Ajusta el peso de cada criterio al riesgo del proceso y documenta por qué un candidato avanza antes que otro.
Checklist para llevar a la primera conversación
- Un ejemplo real y anonimizado del flujo.
- Volumen aproximado y variación por periodos.
- Lista de excepciones y responsables actuales.
- Sistemas implicados y restricciones de acceso.
- Errores o retrasos que hoy se pueden observar.
- Consecuencia de una salida incorrecta.
- Métrica de partida y criterio para detener el piloto.
- Datos que no deben salir del entorno autorizado.
Con esta información, la conversación cambia: ya no se trata de comprar IA, sino de decidir qué parte del trabajo conviene rediseñar, qué tecnología es suficiente y qué control necesita el equipo.
Empieza por un proceso, no por una herramienta
Si tienes varios candidatos, selecciona dos o tres y compáralos con los seis criterios. El objetivo de la primera sesión no es cerrar una solución, sino identificar el flujo que puede producir aprendizaje útil con un riesgo controlado.
En Codiloop podemos ayudarte a preparar un diagnóstico de automatización a partir de un proceso concreto, sus excepciones y las señales que ya puedes medir.