El agente no es el producto. El proceso rediseñado sí. La pregunta no es qué agente ponemos, es qué vale la pena cambiar antes de automatizar algo que hoy se hace mal.
Diagnóstico sin costoEs la pregunta que hacemos en la primera reunión, y la que ordena todo lo demás: ¿en cuál están hoy?
Contesta preguntas sobre información que la empresa ya tiene. Es el más fácil de poner en producción y el que menos riesgo trae, porque no toca nada. También es el que más rápido muestra valor.
Analiza un caso y propone una acción, pero la decisión la toma una persona. Es el punto de equilibrio de la mayoría de las empresas de la región, y donde más valor queda sin capturar.
Hace la tarea completa, tocando los sistemas reales. Es donde está el retorno grande y también todo el riesgo. Requiere límites de autonomía definidos y escalamiento a humano desde el diseño, no como parche.
La mayoría de los proyectos que fracasan intentan saltar del nivel 1 al 3 sin pasar por el 2. No es un problema técnico: es que nadie definió quién se hace responsable de lo que el agente decide.
Un proceso que hoy toma seis pasos porque históricamente hubo tres sistemas que no se hablaban no necesita un agente que haga los seis pasos más rápido. Necesita tener dos pasos.
Automatizar un proceso malo lo único que hace es acelerar el error. Y además lo cristaliza, porque una vez que hay un agente construido sobre ese flujo, cambiarlo cuesta más que antes.
Por eso nuestro trabajo en esta capa arranca mapeando el proceso como es hoy, identificando qué pasos existen solo por razones históricas, y recién después definiendo qué se automatiza.
El orden que usamos. Descubrir dónde está la fricción → Diseñar el flujo nuevo, no automatizar el viejo → Construir a producción con gobierno → Escalar el patrón al siguiente caso.
Cuatro patrones, y ninguno es técnico.
Un agente que ejecuta toma decisiones. Si no está escrito quién se hace cargo cuando se equivoca, el proyecto se frena en Legales o en Riesgos, casi siempre después de haberlo construido.
El agente hace exactamente lo que hacía la persona, incluidos los tres pasos que existían solo porque dos sistemas no se hablaban. Ahora el error es más rápido y más difícil de cambiar.
Un agente razona sobre lo que la empresa sabe. Si esa capa no existe o está sucia, ninguna cantidad de ingeniería de prompts lo arregla. Es la Layer 1 y va antes.
El proyecto se declaró exitoso el día que el agente quedó andando. Tres meses después lo usan doce personas y nadie se enteró, porque nadie definió qué se iba a medir.
El proceso hoy. Una solicitud de crédito comercial pasa por seis manos. Dos de esos pasos son buscar información en sistemas distintos y copiarla a un formulario. Tiempo total: cuatro días, de los cuales tres son espera.
El rediseño, antes de automatizar. Dos de los seis pasos existen porque hace ocho años el sistema de riesgo no leía del CRM. Hoy sí lee. Esos pasos se eliminan, no se automatizan. El proceso queda en cuatro pasos.
Qué hace el agente. Reúne la información de los tres sistemas, arma el legajo, calcula el score preliminar y lo deja listo para revisión humana. No aprueba. Ese límite es una decisión de negocio, no técnica.
Qué se mide. Tiempo de ciclo, porcentaje de legajos que el humano modifica, y cuántas veces el agente escala por no estar seguro. Esa última métrica es la más útil de las tres y casi nadie la mira.
Resultado esperado. De cuatro días a uno, con la decisión todavía en manos de una persona. Si más adelante el número de correcciones humanas baja lo suficiente, ahí se discute subir el nivel de autonomía. No antes.
El ejemplo es ilustrativo y no corresponde a un cliente identificable.
| Cuándo | Con qué | Por qué |
|---|---|---|
| Agentes conversacionales con integración a SAP, CRM o ERP | DruidAI | Challenger en el Magic Quadrant de Gartner de plataformas de IA conversacional. Más de 1.200 millones de conversaciones por año |
| Agentes sobre el conocimiento de la empresa | Glean | Si ya está la capa de conocimiento montada, construir agentes ahí es mucho más barato que empezar de cero. Ver Glean |
| Agentes que corren en infraestructura propia | Red Hat OpenShift AI | Cuando hay requisitos de soberanía de datos o de on-premise, que en banca y sector público es lo normal |
| Casos que no encajan en ninguna plataforma | Desarrollo a medida | A veces la plataforma cuesta más que construirlo. Lo decimos cuando pasa |
| Empresas de menos de 200 personas | Desarrollo propio de GCG | A esa escala ninguna licencia enterprise cierra. Ver soluciones para PyMEs |
Depende enteramente de cuántos sistemas tiene que tocar para hacer su trabajo. Un agente de nivel 1 sobre conocimiento que ya está conectado es un proyecto de semanas. Uno de nivel 3 que ejecuta contra el ERP y el CRM es otro orden de magnitud. Lo cotizamos en la primera conversación, que no se cobra.
El primer agente en producción suele llevar entre cuatro y ocho semanas desde que el proceso está definido. La parte que más tarda casi nunca es construirlo: es acordar qué puede y qué no puede hacer.
Se equivoca, es inevitable. Por eso los límites de autonomía y el escalamiento a humano se definen antes de construir, no después del primer incidente. Y por eso la observabilidad no es opcional: ver gobierno y seguridad de IA.
Un chatbot de árbol de decisión responde lo que alguien anticipó. Un agente razona sobre el contexto real de la empresa y puede resolver casos que nadie escribió de antemano. La diferencia práctica es que el primero frustra y el segundo se usa. Pero si el conocimiento de la empresa está desordenado, el agente tampoco va a andar, y eso es la Layer 0 y la Layer 1.
Es la pregunta con la que arrancamos. Contanos qué proceso les duele y vemos si corresponde un agente que responde, uno que recomienda o uno que ejecuta.
info@greatchallengegroup.com · +54 (911) 5102-0411 · +1 (754) 207-1727
