Cómo auditar una automatización de IA antes de comprometerte a construirla

Respuesta Directa

Una auditoría de automatización con IA es la revisión previa a la construcción que pregunta si una automatización propuesta sobrevivirá al contacto con un sistema que no deja de cambiar, no si funcionó bien en la demo. Pone a prueba tres cosas antes de que se escriba una sola línea de código: qué es lo primero que rompe el flujo de trabajo, cuánto tiempo permanece invisible un fallo, y quién queda designado para arreglarlo después de la entrega. Si te la saltas, el equipo hereda un sistema que nadie es dueño de mantener.

Puntos Clave

• Una automatización que solo sobrevive a la demo no ha sido auditada. Pregunta qué pasa cuando cambia el formato de entrada, la API o la pantalla de la que depende.
• La mayor parte de la fragilidad viene de atar un paso a cómo se ve algo hoy, en lugar de a lo que el flujo de trabajo realmente necesita de él.
• Observable significa que una persona designada se entera de que una ejecución falló dentro de un día, no que un panel suele estar en verde.
• La responsabilidad es un nombre en un documento, no una frase de política. Una automatización sin dueño se degrada hasta que alguien la borra en silencio.
• Gartner espera que más del 40% de los proyectos de IA agéntica sean cancelados para finales de 2027, y señala como razones el costo creciente, el valor de negocio poco claro y controles de riesgo inadecuados, no la calidad del modelo.

¿Qué es una auditoría de automatización con IA, y qué no decide?

Esta auditoría no decide qué flujo de trabajo automatizar primero. Esa es una pregunta distinta, y ya escribí sobre ella como un ejercicio de priorización propio en Auditoría de flujos con IA: por qué las horas ahorradas son un mal criterio: ordenado por cuán barato es revertir una salida incorrecta, no por horas ahorradas.

Esta auditoría empieza después de que se toma esa decisión. Ya se eligió un flujo de trabajo. Un proveedor, un desarrollador o un equipo interno tiene una propuesta sobre la mesa, a veces ya con un prototipo funcionando. La pregunta aquí es más específica y llega después: ¿esta construcción en particular, tal como está diseñada, debería realmente pasar a producción?

Ese es un tipo de fallo distinto al de elegir el flujo de trabajo equivocado. Un equipo puede elegir el flujo correcto para automatizar y aun así encargar una versión frágil, sin dueño y sin observabilidad de ese mismo flujo y la auditoría en esta etapa es lo que detecta eso antes de firmar el contrato o de programar el sprint.

¿Qué hace realmente frágil a una automatización?

La fragilidad casi nunca tiene que ver con el modelo. Tiene que ver con a qué se ató la automatización.

Un flujo de trabajo que lee una pantalla, hace clic en una secuencia fija de botones y extrae un valor de una posición específica de la página está atado a cómo se ve esa pantalla hoy. Renombra un botón, mueve una columna o actualiza la aplicación subyacente, y la automatización no se degrada de forma controlada: se detiene, en silencio o con estruendo, según si alguien construyó el manejo de errores para ese fallo específico.

Una versión más silenciosa del mismo fallo: un ticket de soporte solía llevar el número de pedido en el asunto, y el flujo de triage leía ese asunto para buscar el pedido. Una migración de mesa de ayuda cambia la plantilla del asunto, el parser no devuelve nada, y cada ticket que antes se enrutaba solo ahora queda sin asignar hasta que alguien nota que la cola está creciendo.

La misma fragilidad aparece un nivel más arriba en las construcciones agénticas. Un agente al que se le da un objetivo vago y acceso amplio a herramientas encontrará un camino que funciona en las pruebas y se rompe la primera vez que una API upstream cambia la forma de su respuesta, llega un documento en un formato que nadie probó, o una cola se acumula más allá de lo que el agente asumía como normal. La lectura de Gartner sobre esto es directa: muchos de los proyectos de IA agéntica que espera que se cancelen para 2027 son pilotos en etapa temprana “impulsados por el hype” y “a menudo mal aplicados”, lo que ciega a las organizaciones frente al costo y la complejidad reales de desplegar agentes de IA a escala. El fallo no es el modelo. Es comprometerse con un diseño que nadie puso a prueba contra las formas en que los sistemas subyacentes realmente cambian.

La pregunta de la auditoría es concreta: nombra las tres cosas más probables de cambiar bajo esta automatización en los próximos doce meses, y pregunta qué le pasa al flujo de trabajo cuando cada una cambie. Si la respuesta es “se detiene y nadie se da cuenta”, eso es la fragilidad, y es mucho más barato arreglarla antes del lanzamiento que después.

Qué tiene que significar “observable” antes de construirla

La guía de arquitectura de Google Cloud define la observabilidad como recopilar y correlacionar telemetría (logs, métricas y trazas) para que un equipo pueda detectar problemas antes de que lleguen a los usuarios y solucionar los que sí llegan. Esa definición está pensada para equipos de software en producción, pero el requisito se traslada directamente a una automatización de flujo de trabajo, y suele faltar en la propuesta. Mira cómo se ve esto en la práctica en cómo medir si un flujo de trabajo con IA realmente está funcionando.

Tradúcelo en tres preguntas que una auditoría tiene que responder antes de comprometerse:

• Si una ejecución falla a mitad de la actualización del CRM o del envío del correo, ¿queda registrado que pasó, o el registro simplemente no se crea?
• ¿Hay un lugar donde una persona mire (un canal de Slack que alguien realmente lee, una cola de tickets, una alerta que avisa) donde una ejecución fallida sea visible, o alguien solo se entera cuando llama un cliente?
• ¿Cuál es el tiempo máximo entre un fallo silencioso y que una persona se entere? Un día es una respuesta defendible. Un vago “probablemente lo notaríamos” no lo es.

La mayoría de las propuestas de automatización describen el camino feliz con detalle y el camino de fallo en una sola frase, casi siempre “los errores quedan registrados”. Registrados dónde, leídos por quién, revisados con qué frecuencia: esas tres preguntas de seguimiento son la auditoría real, y una propuesta que no puede responderlas de forma concreta no está lista para construirse.

Las cinco cosas a revisar antes de comprometerte

Aplica estas cinco preguntas a la propuesta real, no a la presentación del proveedor. Si el equipo que presenta la automatización no puede responder un criterio en una frase, ese es el hallazgo, no una razón para asumir que la respuesta está bien.

Un ejemplo trabajado: el bot de facturas que parecía terminado

Una automatización lee las facturas de proveedores que llegan, extrae el total y la fecha de vencimiento, y los escribe en el sistema contable. En la demo, diez facturas se procesan sin problemas. El equipo la aprueba.

Aplica las cinco preguntas antes de esa aprobación, y aparece un panorama distinto. Superficie de fallo: la extracción asume un diseño de PDF de una sola columna; una factura escaneada a dos columnas de un proveedor nuevo lee el total equivocado. Detección: nada marca un valor que se vea inusualmente bajo o alto, así que el total incorrecto se registra. Responsabilidad: la persona que la construyó dejó el proceso sin documentar y se movió a otro proyecto. Reversibilidad: el registro en el sistema contable es fácil de corregir, así que en esto está bien. Costo de cambio: desconocido, porque nadie ha intentado actualizar la lógica de extracción desde que se lanzó.

Cuatro de cinco respuestas son débiles, y ninguna de ellas involucra al modelo produciendo una mala suposición. El modelo hizo su trabajo con la factura que se le mostró. La brecha está en lo que el equipo nunca construyó a su alrededor: una verificación del número antes de registrarlo, un nombre asignado al mantenimiento, y un plan para el formato de factura que la demo nunca probó.

Este es el caso habitual, no la excepción. La mayoría de las automatizaciones frágiles pasan su demo y fallan ante su primera entrada genuinamente nueva, y la auditoría es lo que detecta esa brecha sobre el papel en lugar de en el libro contable.

Cuando la respuesta honesta es: todavía no la construyas

Dos respuestas deberían detener una construcción sin importar qué tan bien se haya visto la demo.

La primera es una brecha de responsabilidad. Si la respuesta honesta a “quién arregla esto después de la entrega” es nadie actualmente en el equipo, la automatización está programada para degradarse desde el primer día. Funcionará hasta que el primer cambio la rompa, y luego quedará rota, porque nadie es dueño de la solución y nadie quiere ofrecerse como voluntario para un sistema sin documentar.

La segunda es una acción irreversible sin una capa de detección. Una automatización que puede registrar un reembolso, enviar un mensaje visible para el cliente o actualizar un precio público necesita tanto una compuerta antes de la acción como una forma de notar rápidamente si esa compuerta falló. Una propuesta con la acción pero sin la detección no está a medio construir: es la construcción equivocada, porque la parte que se omitió es justo la que importa cuando algo sale mal. Este es el mismo límite que sigo encontrando en por qué agregar un agente de IA a un flujo de trabajo roto suele fallar: el agente rara vez es el problema. Lo que se le permitió tocar sin control, sí lo es.

Ninguna de estas dos cosas es un veredicto sobre el flujo de trabajo en sí. El flujo elegido antes puede seguir valiendo la pena automatizarlo. Lo que falla la auditoría es este diseño específico, y la solución suele ser más pequeña que empezar de nuevo: agrega el dueño, agrega la señal de fallo, limita lo que el agente puede tocar sin que una persona confirme primero.

Resumen

Una auditoría de automatización con IA pregunta si una construcción específica, ya elegida, sobrevivirá a las formas en que cambian sus sistemas subyacentes, no si funcionó en la demo. Revisa qué se rompe primero, qué tan rápido aparece un fallo silencioso, quién queda designado para arreglarlo, si una salida incorrecta se puede deshacer sin llamar al cliente, y cuánto costará el siguiente cambio. La propia predicción de Gartner, una pluralidad de proyectos de IA agéntica cancelados para 2027 por costo y valor poco claro, es lo que pasa cuando esa auditoría se salta. Aplica las cinco preguntas a la propuesta real antes de que se lance, no después de que se rompa frente a un cliente.