Guía de decisión / Inteligencia artificial

IA o automatización: cómo elegir para cada proceso.

Usa reglas para condiciones exactas, integración para mover datos entre sistemas e IA cuando la tarea exija interpretar información variable. Después decide qué puede actuar automáticamente y qué resultado necesita revisión.

Autoría: Kenea · Publicación y revisión: 8 de septiembre de 2026.

La diferencia está en cómo se obtiene el resultado

Automatizar significa que un sistema ejecuta pasos de un proceso con las condiciones que se hayan definido. Puede hacerlo mediante reglas, cálculos, intercambios de datos o modelos de IA. Por eso «IA o automatización» no siempre es una elección entre dos productos: una automatización puede incluir una tarea de IA.

En esta guía, IA se refiere sobre todo a modelos que interpretan o generan texto y documentos. Otras técnicas de IA, como los modelos predictivos, necesitan su propio diseño y evaluación. Tener un chatbot no demuestra que un proceso operativo esté integrado.

Una regla también puede estar mal definida, y una integración puede fallar aunque no utilice IA. La elección técnica cambia lo que hay que comprobar; no elimina la necesidad de pruebas.

Un flujo definido y un agente tienen necesidades distintas

Anthropic distingue los flujos con pasos predefinidos de los agentes que deciden dinámicamente su recorrido y uso de herramientas. La autonomía puede resultar útil en tareas abiertas, pero añade decisiones que evaluar. Antes de introducirla conviene comprobar si un flujo más sencillo ya resuelve el caso. Fuente: Building effective agents.

Por ejemplo, leer una solicitud, proponer una categoría y dejarla en una bandeja es un recorrido acotado. Permitir que un agente consulte aplicaciones, cambie registros y escriba a terceros amplía el alcance. Hay que especificar qué acciones puede realizar, con qué datos y en qué punto debe detenerse. La palabra «agente» no sustituye esas decisiones.

Cómo combinar reglas e IA en un mismo proceso

Ejemplo hipotético: una empresa recibe solicitudes de mantenimiento por correo. El diseño podría separar cinco pasos; no representa una instalación ni un resultado de Kenea.

1. Recepción: registrar la referencia del mensaje y evitar procesar dos veces la misma entrada.
2. Interpretación: proponer equipo afectado, ubicación y tipo de incidencia a partir del texto.
3. Validación: comprobar que el equipo existe y que los campos obligatorios están presentes.
4. Revisión: mostrar al responsable las peticiones ambiguas y la evidencia que respalda cada propuesta.
5. Registro: crear una tarea con los datos aceptados y comprobar que el sistema de destino devuelve la referencia esperada.

La IA participaría en la interpretación. La identidad de la solicitud, los permisos y las comprobaciones de negocio seguirían siendo responsabilidades del sistema. Si el modelo propone una ubicación que no figura en el inventario, el flujo debe señalarlo en vez de completar el dato por su cuenta.

Ese reparto también ayuda a localizar problemas. Una clasificación incorrecta requiere revisar ejemplos y criterios; un registro duplicado exige investigar la integración. Cambiar el modelo no arregla necesariamente ambos.

Evalúa una muestra que se parezca al trabajo real

Reúne entradas autorizadas que incluyan formatos habituales, documentos incompletos, variaciones de idioma, casos ambiguos y situaciones fuera de alcance. Define el resultado esperado con quien conoce el proceso. Reserva ejemplos para comprobar cambios sin reutilizar siempre los mismos durante el ajuste.

La evaluación debe observar el resultado de la tarea, no solo si la respuesta parece convincente. Anthropic explica esa separación y recomienda definir entradas, criterios de éxito y comprobaciones repetibles. Las salidas pueden variar entre ejecuciones, de modo que un caso que sale bien una vez no acredita estabilidad. Fuente: Demystifying evals for AI agents.

• Calidad: qué campos, categorías o afirmaciones son correctos, y qué errores tienen consecuencias mayores.
• Cobertura: cuántas entradas puede resolver y cuántas deriva a revisión o quedan fuera de alcance.
• Revisión: cuánto tarda una persona en comprobar y corregir cada resultado.
• Tiempo: cuánto espera el usuario y cómo se comporta el proceso ante varias solicitudes.
• Coste: consumo del modelo, búsqueda, almacenamiento, integración y trabajo de supervisión.

Compara la propuesta con el procedimiento actual y con una alternativa sencilla. Un modelo que produce borradores rápidos puede aportar poco si comprobarlos exige rehacer la tarea. Para extracción documental, revisa por separado identificadores, fechas, cantidades y texto libre: una media única puede ocultar errores importantes.

No trates la «confianza» declarada por un modelo como una probabilidad calibrada de acierto. Si quieres utilizar un umbral para derivar casos, comprueba su relación con errores observados en una muestra representativa. Cuando no exista evidencia suficiente, conserva la revisión.

Define qué revisa una persona y qué puede ejecutar el sistema

«Habrá supervisión humana» es insuficiente si nadie sabe qué revisar. La persona necesita el dato de origen, la propuesta, las comprobaciones que ya se hicieron y las acciones disponibles: aceptar, corregir, pedir información o detener el caso. También necesita tiempo asignado y una cola que no oculte los pendientes.

Separa la lectura de la escritura. Una prueba puede comenzar consultando datos o preparando borradores. Autorizar después una modificación requiere una decisión explícita sobre alcance, validación y recuperación. Evita dar acceso completo a una aplicación para resolver una tarea que solo necesita unos campos.

Los documentos y correos pueden contener instrucciones que intenten alterar el comportamiento del modelo. OWASP describe este riesgo como inyección de instrucciones. La aplicación debe tratar ese contenido como datos a examinar, mantener límites de permisos y validar las acciones fuera del texto generado. Fuente: OWASP Gen AI Security Project, Prompt Injection.

Antes de usar documentos reales, acuerda qué información se necesita, dónde se procesa, quién puede acceder y cómo se elimina. La selección de un proveedor o un modelo debe considerar esas condiciones junto con calidad, coste y operación.

Cuándo avanzar y cuándo cambiar el planteamiento

Avanza cuando la muestra permita explicar la mejora, los errores sean visibles y exista un procedimiento practicable para resolverlos. Si las excepciones ocupan más trabajo del que se libera, el proceso necesita otro alcance. Si el dato de origen es insuficiente, puede ser más útil cambiar su captura que pedir al modelo que lo deduzca.

Deja por escrito la tarea, la alternativa comparada, los criterios de aceptación, el límite de acciones y quién revisará futuros cambios. Repite las comprobaciones relevantes al cambiar modelo, instrucciones, documentos o herramientas. Una demostración inicial sirve para investigar; la aceptación exige evidencia del recorrido completo.

La línea de IA aplicada de Kenea empieza por evaluar ese encaje. Puedes explorar tu proceso en el evaluador gratuito, revisar qué automatizar primero o explorar las soluciones antes de elegir una implementación. El evaluador ofrece orientación a partir de tus elecciones; una evaluación técnica por encargo requiere acordar alcance, precio y calendario.

Explorar mi proceso Revisar la integración

Fuentes y alcance

Fuentes primarias consultadas el 8/9/2026: Anthropic, Building effective agents (19/12/2024; la propia página advierte de cambios posteriores en las herramientas), Anthropic, Demystifying evals for AI agents (9/1/2026) y OWASP, LLM01:2025 Prompt Injection. Se utilizan como referencias de diseño, evaluación y seguridad, no como avales de Kenea ni de un proveedor concreto. El ejemplo y la matriz son propuestas editoriales.