Automatización con IA: la excepción también se diseña

Una automatización suele presentarse con un recorrido limpio: llega una solicitud, el sistema la interpreta, actualiza un registro y avisa al responsable. Ese recorrido existe, pero rara vez ocupa todo el día de trabajo.

En la operación aparecen nombres parecidos, documentos incompletos, precios fuera de regla, clientes sin identificación suficiente, datos que contradicen al sistema principal y solicitudes que nadie autorizó todavía. Si el diseño solo contempla el caso ideal, cada excepción termina en un correo urgente, una hoja paralela o una persona que corrige el resultado sin dejar rastro.

La automatización con IA puede ayudar a reconocer esas variaciones. No debe ocultarlas. Un buen flujo identifica lo que entiende, separa lo que necesita confirmación y detiene aquello que podría producir una promesa, un cobro o una decisión equivocada.

El caso normal no es el proceso completo

Pensemos en una solicitud de cotización. El cliente escribe el servicio, la cantidad y una fecha aproximada. El sistema puede extraer esos datos y preparar una ficha. Hasta ahí, la automatización parece sencilla.

El problema aparece cuando la solicitud dice “lo mismo de la vez pasada”, adjunta una foto borrosa o pide un descuento que no aparece en las reglas vigentes. También puede llegar desde un correo distinto al que la empresa tiene registrado. El trabajo no consiste solamente en extraer texto: consiste en saber qué parte se puede preparar y cuál debe volver a una persona.

Ese criterio debe existir antes de elegir la herramienta. En la inteligencia artificial aplicada, la IA puede interpretar lenguaje variable, proponer una clasificación o señalar una contradicción. Las reglas del negocio siguen siendo necesarias para validar condiciones estables, y el equipo conserva la autoridad sobre las decisiones sensibles.

Tres rutas para una solicitud que no encaja

No todas las excepciones merecen el mismo tratamiento. Una clasificación útil puede separar el trabajo en tres rutas.

La primera es la corrección automática de bajo riesgo. Si falta un formato, el sistema puede pedirlo. Si una fecha está escrita de dos maneras equivalentes, puede normalizarla. Si el número de referencia aparece con espacios, puede limpiarlo sin cambiar su significado.

La segunda es la preparación con revisión. Aquí la IA puede resumir el caso, reunir documentos, comparar una condición con la política vigente y proponer el siguiente paso. La persona revisa antes de enviar, cambiar un estado o comprometer un precio.

La tercera es la pausa obligatoria. Una identidad dudosa, una solicitud de acceso, un conflicto entre fuentes o una excepción que afecte un pago no debería resolverse con una frase más segura. El sistema debe explicar qué encontró, qué falta y quién puede decidir.

La diferencia no está en que una ruta use IA y otra no. Está en las consecuencias de equivocarse. La automatización de procesos vuelve esas rutas visibles mediante estados, responsables y condiciones de salida, en vez de dejar que cada empleado improvise.

La bandeja de excepciones necesita dueño

Crear una bandeja donde caiga todo lo que la IA no pudo resolver no es suficiente. Una cola sin responsable solo cambia de lugar el atraso.

Cada excepción debería llegar con el contexto que permita trabajarla: solicitud original, cliente o expediente relacionado, datos extraídos, fuente consultada, regla que no se pudo aplicar y acción que el sistema evitó ejecutar. También debe quedar claro qué área puede corregir el caso y qué plazo tiene sentido para esa revisión.

Una empresa puede descubrir que la mayoría de sus excepciones se repite. En ese caso, no siempre conviene entrenar un modelo nuevo. Puede faltar una regla de negocio, un campo en el formulario, una fuente oficial o una integración con el sistema que mantiene el estado real.

Por ejemplo, si muchas solicitudes se detienen porque el catálogo no informa la unidad de venta, la solución puede ser mejorar el catálogo. Si se detienen porque el cliente tiene dos registros, primero hay que ordenar la identidad. Si se detienen porque el precio depende de una aprobación comercial, el flujo debe representar esa aprobación en lugar de pedirle a la IA que adivine.

El diseño debe registrar lo que no hizo

En una automatización normal se registra el resultado: caso creado, correo enviado o pedido actualizado. En un flujo con excepciones también importa registrar la acción que el sistema decidió no ejecutar.

Ese registro puede responder preguntas concretas:

• ¿Qué dato provocó la pausa?
• ¿Qué fuente estaba vigente en ese momento?
• ¿Qué permiso faltaba?
• ¿Quién revisó el caso?
• ¿Qué cambió después de la revisión?
• ¿El mismo tipo de excepción volvió a ocurrir?

Esta información ayuda a corregir el proceso sin borrar la historia. También evita que una persona reciba un caso aparentemente incompleto y tenga que reconstruir desde cero qué intentó hacer el sistema.

La seguridad y gobernanza de IA debe incluir estos registros y no solo el control de acceso al modelo. Una excepción puede contener más información que el resultado final, especialmente cuando incluye documentos adjuntos, datos de clientes o explicaciones internas.

Cómo probar una excepción antes de ponerla en producción

Un piloto no debería utilizar únicamente solicitudes bien redactadas y registros sin duplicados. Conviene preparar una pequeña colección de casos incómodos que representen el trabajo diario:

• un cliente nuevo con un nombre parecido a otro;
• un documento adjunto que no coincide con el formulario;
• una política vigente y otra retirada en la misma carpeta;
• una solicitud sin el dato necesario para calcular el precio;
• un usuario que pide una acción fuera de su permiso;
• un cambio en el sistema principal mientras el borrador espera aprobación;
• un caso que ya fue atendido y vuelve a entrar por otro canal.

La prueba debe observar el recorrido completo. No basta con verificar si la IA clasificó bien el texto. Hay que comprobar si pidió el dato correcto, si evitó actualizar el registro equivocado, si avisó a la persona adecuada y si el cierre dejó evidencia suficiente.

También conviene medir el costo de la excepción. Una automatización puede reducir el tiempo de los casos normales y, al mismo tiempo, duplicar el trabajo de los casos difíciles. Esa información no invalida el proyecto, pero sí cambia el alcance: quizá haya que mejorar el formulario, reducir permisos, integrar otra fuente o empezar con una sola clase de solicitudes.

La meta no es eliminar todas las excepciones

Las excepciones forman parte del negocio. El objetivo razonable es que no queden escondidas, que reciban una respuesta proporcional y que las repetidas sirvan para mejorar el proceso.

La IA puede reconocer variaciones, reunir contexto y preparar alternativas. Las reglas pueden controlar condiciones conocidas. Una persona debe conservar la decisión cuando la salida implique dinero, derechos, acceso, cumplimiento o una promesa difícil de revertir.

Antes de automatizar con IA, conviene revisar un proceso real y contar dónde se detiene, quién corrige y qué información falta. Global Agenttic puede ayudar a ordenar ese recorrido y convertirlo en un piloto con alcance, responsables, pruebas de excepción y criterios de salida claros desde contacto.

Automation is often shown as a clean path: a request arrives, the system interprets it, updates a record, and alerts someone. That path exists, but it rarely represents the whole working day.

Real operations include similar names, incomplete documents, prices outside the rules, customers who cannot be identified confidently, conflicting records, and requests nobody has authorized yet. If the design only covers the ideal case, every exception becomes an urgent email, a parallel spreadsheet, or an unexplained manual correction.

AI-powered automation can help recognize those variations. It should not hide them. A reliable workflow identifies what it understands, separates what needs confirmation, and stops actions that could create a wrong promise, charge, or decision.

The normal case is not the whole process

Consider a quote request. The customer writes the service, quantity, and an approximate date. The system can extract those details and prepare a record. The workflow looks simple.

The difficulty starts when the customer says “the same as last time,” attaches a blurry photo, or asks for a discount that is not in the current rules. The request may also arrive from an email address that is not linked to the customer record. The task is not only to extract text. It is to decide what can be prepared and what must return to a person.

In applied artificial intelligence, AI can interpret variable language, suggest a classification, or flag a conflict. Business rules still matter for stable conditions, and people retain authority over sensitive decisions.

Three routes for a request that does not fit

Low-risk corrections can happen automatically. The system can request a missing format, normalize equivalent date formats, or remove spaces from a reference number without changing its meaning.

A second route is preparation with review. AI can summarize the case, gather documents, compare a condition with the current policy, and suggest the next step. A person reviews before sending, changing a status, or committing a price.

The third route is a required pause. Uncertain identity, access requests, conflicting sources, and payment-related exceptions should not be solved with more confident wording. The system should explain what it found, what is missing, and who can decide.

The difference is not simply whether a route uses AI. It is the consequence of being wrong. Process automation makes these routes visible through states, owners, and exit conditions.

The exception queue needs an owner

A queue for everything AI could not solve is not enough. A queue without an owner only moves the backlog.

Each exception should arrive with the original request, related customer or case, extracted data, consulted source, rule that failed, and action the system avoided. The responsible area and a reasonable review time should also be clear.

If the same exception repeats, the answer may not be a new model. The missing piece could be a business rule, a form field, an authoritative source, or an integration with the system that holds the real status.

Record what the system did not do

A normal automation records its result: case created, email sent, or order updated. An exception workflow should also record the action it decided not to execute. That history connects the pause to the source, missing permission, reviewer, correction, and any recurrence.

AI security and governance should include these records, not only model access controls. An exception can contain more information than the final output, especially when attachments, customer data, or internal explanations are involved.

Test an exception before production

A pilot should include similar customer names, mismatched attachments, retired policies, missing pricing data, unauthorized actions, changing source records, and duplicate requests through different channels.

Check the full path. Did the system request the right information? Did it avoid updating the wrong record? Did it alert the right person? Did the closure leave enough evidence? A lower rate of normal-case work does not prove success if difficult cases now take twice as long.

The goal is not to eliminate every exception

Exceptions are part of business. The practical goal is to make them visible, route them according to their consequences, and use repeated cases to improve the process.

AI can recognize variations, gather context, and prepare alternatives. Rules can control known conditions. A person should retain decisions involving money, rights, access, compliance, or promises that are difficult to reverse.

Before automating with AI, review a real process and count where it stops, who corrects it, and what information is missing. Global Agenttic can help turn that path into a pilot with clear scope, owners, exception tests, and exit criteria through contact.