Cómo identificar procesos adecuados para utilizar inteligencia artificial

Qué significa que un proceso sea apto para IA

Ser apto no significa que la IA sea obligatoria. Significa que existe una combinación razonable entre problema, información, capacidad operativa y riesgo. La evaluación debe comenzar por el trabajo que se desea mejorar, no por una herramienta o modelo.

Un proceso estable antes que una herramienta novedosa

Un proceso no necesita estar perfectamente documentado, pero sí debe tener un alcance reconocible: un inicio, un resultado, actores, entradas y decisiones. Cuando nadie puede explicar quién responde por el resultado o las reglas cambian sin control, la IA solo añade otra capa de incertidumbre.

La estabilidad tampoco significa rigidez. Puede haber excepciones y criterio profesional. Lo importante es comprender esas variaciones y decidir cuáles puede asistir una tecnología y cuáles requieren juicio humano.

Diferencia entre automatizar reglas y utilizar IA

Si una tarea puede resolverse con condiciones explícitas y datos estructurados —por ejemplo, enrutar una solicitud según tipo y monto— una automatización convencional suele ser más simple de explicar, probar y mantener. La IA resulta más pertinente cuando debe interpretar texto, imágenes, lenguaje o patrones variables que no se describen con reglas completas.

Siete criterios para evaluar un proceso

1. Objetivo y resultado observables

La pregunta inicial no es “¿dónde podemos usar IA?”, sino “¿qué resultado del proceso necesita mejorar y para quién?”. Un objetivo útil especifica una condición observable: reducir el tiempo de clasificación, encontrar evidencias con mayor consistencia o disminuir omisiones durante una revisión.

El resultado debe evaluarse en el proceso completo. Ahorrar minutos en una tarea no crea valor si después aumenta el retrabajo, la espera o la revisión manual.

2. Entradas, datos y documentos disponibles

La IA necesita ejemplos representativos del trabajo real. Conviene inventariar formatos, calidad, idiomas, excepciones, permisos y datos sensibles. Una demostración con cinco documentos limpios no demuestra desempeño con archivos incompletos, escaneos deficientes o estructuras distintas.

También debe existir una base legítima y autorizada para utilizar la información. La disponibilidad técnica de un archivo no equivale a permiso para procesarlo.

3. Volumen, frecuencia y variabilidad

Un proceso frecuente puede justificar una inversión porque el aprendizaje se reutiliza. Sin embargo, el volumen por sí solo no basta. Si las reglas son totalmente predecibles, una automatización tradicional podría ser suficiente; si cada caso es excepcional y no existen patrones, la IA puede aportar poco.

La oportunidad suele aparecer en una zona intermedia: existen patrones repetidos y variaciones que requieren extraer, clasificar, resumir o comparar información.

4. Riesgo, reversibilidad y costo del error

No todas las equivocaciones tienen la misma consecuencia. Una sugerencia de categoría que puede corregirse antes de guardar es distinta de una decisión que afecta derechos, pagos, seguridad o acceso a un servicio. Cuanto mayor sea el impacto, mayor debe ser el estándar de evidencia, prueba, supervisión y registro.

El AI RMF de NIST propone gestionar riesgos durante todo el ciclo de vida. En la práctica, implica identificar quién podría verse afectado, cómo se detectará un error y qué mecanismo permitirá corregir, detener o retirar la función.

5. Punto de control y responsable humano

“Habrá una persona revisando” es insuficiente si no se define qué revisa, con qué evidencia, dentro de qué plazo y qué decisión puede tomar. El control debe formar parte del diseño del proceso.

La persona responsable necesita ver la fuente, la salida y las condiciones que exigen escalamiento. La revisión no debe convertirse en aprobación automática por exceso de volumen o falta de contexto.

6. Integración con el trabajo existente

Muchos pilotos funcionan en una pantalla separada, pero fracasan al incorporarse a responsabilidades, sistemas y tiempos reales. Antes de construir conviene dibujar qué recibe la IA, qué produce, quién utiliza la salida y qué registro queda.

Si obliga a copiar información entre herramientas, crea un repositorio sin propietario o rompe la trazabilidad, la mejora local puede empeorar el proceso completo.

7. Capacidad de medir valor y mantener la solución

La evaluación necesita una línea base: tiempo, volumen, tasa de devolución, omisiones detectadas, nivel de servicio u otra medida vinculada al objetivo. No es necesario prometer un porcentaje; sí decidir qué señal justificaría continuar.

Además, alguien debe mantener instrucciones, integraciones, permisos, datos de referencia y pruebas. Un piloto sin responsable operativo se degrada cuando cambian documentos, reglas o necesidades.

Método de priorización paso a paso

1. Inventariar y delimitar procesos candidatos

Recoja oportunidades sin empezar por la solución. Para cada proceso registre propósito, inicio, fin, usuario, propietario, volumen, documentos, sistemas y problemas observados. Si la oportunidad es demasiado amplia, divídala en tareas o decisiones concretas.

2. Puntuar impacto, factibilidad y riesgo

Utilice una escala simple de uno a cinco y documente el motivo de cada puntuación. Impacto puede considerar calidad, tiempo, capacidad o riesgo evitado; factibilidad, evidencia e integración; riesgo, consecuencia del error, sensibilidad y reversibilidad.

La puntuación no reemplaza la conversación. Sirve para hacer visibles los supuestos y comparar candidatos con el mismo criterio.

3. Elegir una prueba con criterio de salida

Seleccione un alcance pequeño pero representativo. Defina antes de probar: conjunto de casos, medida de calidad, tiempo máximo, responsable de revisión, incidentes que obligan a detener y condición para avanzar, ajustar o descartar.

Un resultado válido puede ser decidir que la IA no es adecuada. Evitar una inversión mayor también es aprendizaje.

Ejemplo aplicado: clasificación documental frente a aprobación final

Ejemplo simulado. Una organización recibe expedientes con distintos tipos de documento y plantea dos candidatos:

• Clasificar documentos y señalar posibles faltantes: la salida puede contrastarse con el archivo, corregirse y enviarse a una persona revisora.
• Aprobar automáticamente el expediente: la decisión combina requisitos, excepciones y consecuencias que pueden afectar a terceros.

El primer candidato permite una prueba acotada: existe evidencia visible, el error es detectable y la persona conserva la decisión. El segundo no debe comenzar como automatización autónoma. Antes necesita reglas, responsabilidades, controles, tratamiento de excepciones y una evaluación más exigente del impacto.

La conclusión no es que clasificar siempre sea seguro. Si existen datos personales, documentos de baja calidad o categorías ambiguas, también requerirá controles. La comparación muestra cómo la tarea y el costo del error cambian la decisión.

Procesos que no deberían empezar con IA

Proceso inestable o sin propietario

Cuando el equipo todavía debate cuál es el resultado, cada área trabaja de forma diferente y nadie tiene autoridad para resolver excepciones, conviene levantar el proceso actual y diseñar una base común.

Decisión de alto impacto sin revisión humana efectiva

No debería iniciarse una automatización autónoma cuando la salida afecta derechos, selección, pagos, sanciones o seguridad y no existe una instancia competente que pueda revisar evidencia, corregir y responder.

Datos insuficientes o uso sin base legítima

Si los ejemplos no representan casos reales, el acceso no está autorizado o no pueden protegerse datos sensibles, el proyecto no está listo. Los datos simulados pueden probar una interfaz, pero no demuestran desempeño operativo.

Checklist de decisión

• ¿El problema está descrito sin mencionar una herramienta?
• ¿El proceso tiene inicio, fin, usuario y responsable?
• ¿La salida esperada puede observarse y evaluarse?
• ¿Existen datos representativos y autorizados?
• ¿Se conocen las excepciones importantes?
• ¿El costo del error está identificado?
• ¿La salida puede revisarse, corregirse y rastrearse?
• ¿Existe responsable de la decisión final?
• ¿Puede integrarse al flujo real?
• ¿Hay línea base, criterio de éxito y condición de salida?
• ¿Existe capacidad para mantener la solución?

Si varias respuestas son “no”, el siguiente trabajo probablemente sea ordenar el proceso, mejorar la evidencia o diseñar controles antes de construir IA.

Preguntas frecuentes

¿Todo proceso repetitivo necesita IA?

No. Si las reglas son conocidas y los datos están estructurados, una automatización convencional puede ser más económica, explicable y estable. La IA se justifica cuando aporta interpretación o manejo de variabilidad.

¿Cuándo basta una automatización convencional?

Cuando entradas, condiciones y resultados pueden expresarse mediante reglas deterministas. Alertas por vencimiento, validación de campos o enrutamiento de solicitudes pueden resolverse sin modelos de IA.

¿Quién debe aprobar el piloto?

El propietario del proceso y las áreas afectadas deben aprobar objetivo, alcance, datos, controles y criterios de salida. Tecnología habilita la prueba, pero no debe asumir por sí sola la responsabilidad funcional.

Fuentes y fecha de revisión

Revisión editorial: 20 de julio de 2026. Estas fuentes son marcos de referencia; no sustituyen una evaluación legal, sectorial, de seguridad o protección de datos aplicable a cada organización.

• NIST — Artificial Intelligence Risk Management Framework 1.0.
• NIST AIRC — funciones Govern, Map, Measure y Manage.
• OCDE — Principios sobre inteligencia artificial.
• ISO — sistemas de gestión de inteligencia artificial.