Por Ignacio Muñoz, Gerente de Desarrollo de Negocios
Muchas empresas ya tienen bots, flujos RPA o soluciones de inteligencia artificial funcionando en áreas específicas. El problema aparece después: cuando esa automatización pasa a depender de sistemas reales, datos cambiantes, usuarios internos, reglas de negocio, auditoría y soporte.
El go-live suele tratarse como cierre del proyecto. En automatización empresarial, debería entenderse como el primer día de operación.
Si una automatización solo funciona cuando la mira la persona que la construyó, no está en producción. Está en custodia.
Escribí este blog porque la diferencia importa. Una cosa es automatizar una tarea. Otra es sostener una automatización crítica durante meses, con monitoreo, control de excepciones, QA, seguridad, métricas y responsables claros.
Ahí es donde muchas iniciativas de RPA e IA empiezan a generar deuda operativa.
Una automatización puede funcionar bien en demo y fallar en la operación diaria. No necesariamente porque esté mal construida, sino porque nadie diseñó qué pasa cuando cambia el entorno.
Una pantalla se actualiza. Una credencial expira. Un archivo llega con otro formato. Una API no responde. Un usuario carga datos incompletos. Una regla comercial cambia. Un modelo de IA empieza a responder con menor precisión porque los documentos de entrada ya no son los mismos.
Cuando no hay operación diseñada, cada una de esas situaciones se transforma en soporte informal.
El equipo que antes hacía trabajo manual ahora revisa errores, desbloquea ejecuciones, corrige datos o persigue excepciones. La promesa de eficiencia se mantiene en el discurso, pero en la práctica la carga se mueve de un lugar a otro.
Un bot sin monitoreo no es eficiencia. Es riesgo diferido.
Y con IA el riesgo es mayor. Un modelo puede clasificar, extraer, resumir o recomendar. Pero si nadie mide precisión, deriva casos dudosos o revisa sus errores, la empresa no está automatizando con inteligencia: está delegando sin control.
La brecha entre adopción y escalamiento no es menor. El estudio global de McKinsey sobre el estado de la IA muestra que muchas organizaciones ya usan IA, pero una parte importante sigue en fases de experimentación o piloto, sin capturar aún valor a escala empresarial.
La tecnología ya está entrando. La operación no siempre la está alcanzando.
Las fallas post go-live rara vez aparecen como un gran evento. Normalmente parten como fricción acumulada: ejecuciones detenidas, casos pendientes, excepciones sin dueño, datos mal procesados o reportes que dejan de cuadrar.
Los problemas más frecuentes son concretos:
El patrón se repite: el proyecto se cerró, pero la operación quedó abierta. Cuando una automatización toca procesos financieros, atención interna, conciliaciones, facturación, datos personales o sistemas core, esa falta de operación deja de ser un problema técnico. Se convierte en riesgo de negocio.
No todas las empresas necesitan un modelo complejo de automatización. Pero cualquier organización con bots o IA en producción debería tener, al menos, cinco capas básicas.
No basta con saber si el bot corrió. Hay que saber qué procesó, qué no procesó, cuánto demoró, qué excepciones generó y qué impacto tuvo en el flujo.
Las métricas mínimas deberían incluir disponibilidad, ejecuciones exitosas, tasa de error, tasa de excepción, volumen procesado, backlog pendiente y cumplimiento de SLA.
En procesos críticos, el monitoreo también debe mirar costo por transacción, tiempo de ciclo, errores evitados y casos derivados a revisión humana.
Sin monitoreo, la empresa se entera tarde. Y cuando se entera tarde, el costo ya se acumuló.
Toda automatización debe asumir que habrá casos fuera de regla.
El problema no es que existan excepciones. El problema es que nadie haya definido qué hacer con ellas.
Una operación sana determina qué casos resuelve automáticamente el bot, cuáles pasan a una persona, dónde quedan registrados, quién los toma, cuánto tiempo pueden estar pendientes y cómo se cierra el ciclo.
En automatización con IA, este punto es crítico. Si un modelo clasifica documentos, extrae información o recomienda una acción, debe existir un umbral de confianza. Bajo ese umbral, el caso no debería seguir solo: debe pasar a revisión humana.
La IA no tiene que decidirlo todo. Tiene que acelerar lo que puede y escalar lo que no debe resolver sola.
Una actualización menor puede romper una automatización productiva. Un cambio en SAP, ERP, CRM, un portal externo, una regla de negocio o el formato de un documento puede afectar flujos que antes funcionaban bien. Por eso el QA no puede terminar en el go-live.
Los servicios de QA con IA de ACL apuntan justamente a fortalecer esa capa: pruebas funcionales, regresión, performance, detección temprana de errores y control de calidad durante el ciclo de vida.
Cuando hay IA, el QA debe sumar otras preguntas: si el modelo sigue respondiendo con precisión, si aumentaron los falsos positivos, si cambió el tipo de documentos recibidos, si hay degradación en el desempeño o si se están derivando suficientes casos a revisión humana.
Un bot que ejecuta mal escala errores. Un modelo que interpreta mal escala decisiones incorrectas. Ambos necesitan pruebas, control y monitoreo.
El control de cambios es una de las capas más subestimadas en RPA e IA. Una regla comercial puede parecer menor para un área, pero romper la lógica completa de una automatización. Un nuevo campo obligatorio puede detener un flujo. Un cambio en permisos puede bloquear ejecuciones. Una actualización de interfaz puede dejar un bot fuera de servicio.
La pregunta no es solo “qué cambió”. Es qué automatizaciones dependen de eso.
En IA, el gobierno de cambios también debe considerar prompts, modelos, fuentes de datos, bases documentales, permisos, herramientas conectadas y criterios de revisión humana. El AI Risk Management Framework de NIST es una referencia útil para ordenar prácticas de riesgo, medición, gobernanza y confianza en sistemas de IA.
Si la solución usa modelos generativos o agentes, también conviene considerar riesgos como prompt injection, exposición de información sensible o exceso de autonomía, abordados por OWASP en su guía para aplicaciones LLM.
No se trata de frenar la automatización. Se trata de que los cambios no sorprendan a la operación.
La automatización no puede evaluarse solo por percepción. Necesita indicadores visibles para TI y para negocio.
Las métricas técnicas muestran si la solución está operando. Las métricas de negocio muestran si sigue valiendo la pena.
| Dimensión | Métricas recomendadas |
|---|---|
| Estabilidad | Disponibilidad, ejecuciones exitosas, fallas por período |
| Soporte | MTTR, incidentes abiertos, recurrencia de errores |
| Excepciones | Tasa de excepción, backlog, tiempo de resolución |
| Negocio | SLA, tiempo de ciclo, costo por transacción, ROI |
| Calidad | Errores evitados, retrabajo, precisión de extracción o clasificación |
| IA | Nivel de confianza, revisión humana, falsos positivos, drift |
| Riesgo | Trazabilidad, auditoría, accesos, cambios no autorizados |
Para equipos de tecnología, referencias como las métricas DORA Four Keys ayudan a mirar estabilidad y capacidad de recuperación, especialmente con indicadores como change failure rate y time to restore service.
En automatización, la lógica es similar: no basta con desplegar. Hay que saber cuántas veces falla, cuánto tarda en recuperarse y cuánto impacto genera cada incidente.
En una compañía financiera de Estados Unidos, DataArt automatizó procesos críticos de billing combinando UiPath RPA, Python y validación documental con IA. El caso público de DataArt reporta un MVP en tres meses, un aumento de cinco veces en la velocidad de procesamiento, más de 90% de facturas validadas automáticamente y una reducción de errores de 20%.
La lectura comercial es clara: en facturación, acelerar sin control puede acelerar errores. El valor está en combinar automatización, validación, precisión y cumplimiento.
Ese tipo de solución no puede quedar sin monitoreo, QA y trazabilidad. Si procesa información crítica, debe operar como parte del control financiero.
En un proyecto de ACL para una institución financiera en Chile, el desafío era reducir la incertidumbre en la conciliación de transacciones recibidas desde marcas internacionales. El proceso tenía alto volumen, múltiples monedas, integración con sistemas core y riesgo contable.
ACL implementó una cuadratura automatizada en dos etapas, con dashboard diario, seguimiento de transacciones pendientes, firma digital y reportes para auditoría. La solución permitió eliminar manualidad en la cuadratura diaria y reducir en 90% las transacciones rechazadas tras detectar brechas en reglas de negocio.
Este es el tipo de automatización que sí exige operación productiva: no solo ejecuta una tarea, también deja evidencia, ordena excepciones y reduce incertidumbre en un proceso financiero crítico.
DataArt implementó un chatbot de IA para soporte interno, integrado con Microsoft Teams, portales internos, Confluence y Jira Service Management. La solución centralizó 26 servicios y resolvió automáticamente entre 50% y 60% de las solicitudes internas.
El valor no está solo en responder preguntas. Está en ordenar la entrada de solicitudes, enrutar correctamente, reducir tickets evitables y liberar especialistas para casos complejos.
Pero una solución así solo funciona bien si se opera: base de conocimiento actualizada, rutas de escalamiento, ownership, métricas de SLA y revisión continua de respuestas.
Una empresa debería revisar su modelo de operación cuando los bots fallan y solo una persona sabe corregirlos; cuando las excepciones se gestionan por correo o planillas; cuando TI no tiene inventario completo de automatizaciones; cuando los cambios de sistemas rompen flujos productivos; o cuando el negocio no sabe cuánto valor sigue generando la solución.
Con IA, la señal es todavía más clara: si el modelo responde, pero nadie mide precisión, confianza, sesgos, derivaciones a revisión humana o calidad de salida, la empresa no tiene una operación de IA. Tiene una apuesta. Y una apuesta no escala.
Cuando aparecen estas señales, el problema ya no es “hacer más automatización”. Es ordenar la operación que sostiene lo que ya existe.
Operar RPA e IA en producción requiere capacidades que normalmente viven en áreas distintas: automatización, QA, datos, arquitectura, seguridad, soporte y negocio.
ACL powered by DataArt conecta esas capas con una mirada local y global.
Desde ACL, el acompañamiento puede incluir servicios RPA, QA con IA, gobierno de datos, DevOps, arquitectura, staffing especializado y soporte continuo. Desde DataArt, se suman capacidades globales en IA y Machine Learning, plataformas de datos, ingeniería de software, cloud, MLOps, LLMOps y soluciones enterprise.
El objetivo no es sumar más tecnología por defecto. Es construir una operación donde cada automatización tenga dueño, monitoreo, métricas, soporte, trazabilidad y mejora continua.
Ahí RPA e IA dejan de ser proyectos aislados y se convierten en una capacidad instalada.
Después del go-live empiezan las preguntas importantes: quién monitorea, quién responde, cómo se manejan excepciones, qué pasa si cambia un sistema, cómo se prueba una nueva versión, qué métricas se revisan y cómo se evita que la IA actúe sin control suficiente.
Las empresas que logren escalar RPA e IA no serán necesariamente las que tengan más bots. Serán las que tengan mejor operación.
En ACL powered by DataArt ayudamos a las organizaciones a diseñar, estabilizar y evolucionar automatizaciones críticas con gobierno, QA, datos, soporte y métricas de negocio.
Si tu empresa ya tiene bots, flujos RPA o soluciones de IA en producción, pero todavía opera con monitoreo informal, excepciones manuales o soporte dependiente de pocas personas, agenda un diagnóstico con ACL powered by DataArt. Revisemos qué automatizaciones están generando valor, cuáles están creando deuda operativa y cómo sostenerlas con mayor control.
Después del go-live comienza la operación real. La automatización debe monitorearse, mantenerse, probarse ante cambios, gestionar excepciones y medirse con indicadores de negocio y estabilidad.
Los bots pueden fallar por cambios en pantallas, permisos, credenciales, reglas de negocio, formatos de datos, sistemas legacy o falta de pruebas de regresión. Muchas fallas no vienen del bot en sí, sino del entorno operativo que cambia.
Cuando hay IA, además del monitoreo técnico, se debe controlar precisión, confianza, sesgos, respuestas incorrectas, revisión humana, cambios en datos de entrada y comportamiento del modelo en el tiempo.
Cuando las automatizaciones impactan procesos críticos, dependen de sistemas core, generan excepciones frecuentes, no tienen monitoreo formal o requieren justificar continuidad, control y ROI ante gerencia.
Cómo elegir un partner de RPA en Chile sin comprometer escalabilidad ni control