Automatización son pasos que tú especificaste: llega una factura, extrae estos campos, contrástalos con el pedido, contabiliza y avisa al comprador si los totales no cuadran. Funciona igual siempre. Cuando se rompe, se rompe con ruido y en un punto que puedes señalar.
Un agente es un modelo de lenguaje decidiendo qué hacer a continuación dentro de los límites que le pongas. Lee algo sin estructura — un correo, la transcripción de una llamada, un contrato —, elige cuál de tus herramientas usar y produce un resultado. Resuelve entradas que nadie podría enumerar de antemano, y no se comporta igual cada vez.
Pide a quien hace hoy ese trabajo que escriba la regla que sigue. No el resumen: la regla, con sus excepciones. Lo que ocurra a continuación te dirá casi todo.
Puede escribirla: usa automatización. Cuesta menos construirla, menos operarla, y podrás demostrar qué hizo exactamente.
No puede, porque depende de lo que diga el mensaje: ahí está el trabajo del modelo: leer lenguaje y convertirlo en algo estructurado sobre lo que tu automatización pueda actuar.
No puede, porque nadie lo ha decidido: no ayuda ninguno de los dos. La decisión la tiene que tomar una persona antes de que un sistema la ejecute, y fingir lo contrario es como mueren los pilotos.
En la práctica el debate está mal planteado. Un sistema de soporte no es un agente: es un flujo con un paso de clasificación donde un modelo lee el ticket y un paso de respuesta donde un modelo la redacta desde tu documentación. Todo lo que rodea esos dos pasos — enrutado, permisos, escalado, registro, escritura en el CRM — es automatización corriente, y así debe ser.
Esa forma es deliberada. El marco determinista es lo que hace el sistema auditable y barato; el modelo queda confinado a las partes que de verdad exigen criterio sobre lenguaje. Cuando un proyecto sale mal, muy a menudo es porque se le dio a un modelo un trabajo que una regla habría resuelto.
El coste por ejecución deja de ser despreciable. Los pasos deterministas no cuestan casi nada. Las llamadas al modelo tienen un precio unitario real, así que un volumen que antes era irrelevante en tu factura pasa a ser una partida que conviene prever.
La misma entrada puede dar salidas distintas. Eso es lo que se busca, y también el problema. Significa que hace falta evaluación — un conjunto de casos reales con respuestas correctas conocidas — y no una prueba que pasó una vez.
El fallo se vuelve silencioso. La automatización falla con un error. El modelo falla con una respuesta fluida y equivocada, por eso las citas, los umbrales de confianza y una vía humana para los casos dudosos no son extras.
La latencia sube. Segundos en lugar de milisegundos. Irrelevante en una respuesta de soporte, a veces decisivo en un checkout o en una API que alguien está esperando.
Coge un proceso. Divídelo en pasos y marca cada uno como regla o criterio. Si todos son reglas, no necesitas un modelo, y el proveedor que diga lo contrario está vendiendo. Si uno o dos pasos son criterio sobre lenguaje, ahí va el modelo, y el resto sigue siendo determinista.
Si la mayoría son criterio y no van sobre lenguaje sino sobre tu negocio — precio, crédito, contratación, a quién sacar de la lista de proveedores —, todavía no es un proyecto de automatización. Es un proyecto de decisión, y primero alguien tiene que fijar la política.
Cómo ordenar candidatos por volumen, minutos y claridad de las reglas.
Justo la forma descrita aquí: un flujo determinista con un modelo encargado de leer.
El servicio más amplio: procesos llevados a producción, con el modelo solo donde se justifica.
Usamos cookies solo para analítica: para ver desde qué páginas llegan las consultas. Nada más, y nada antes de que aceptes. Política de cookies