Por HEYVO · Perspectivas
Usá automatización por reglas cuando podés definir de antemano las condiciones y el siguiente paso. Sumá un modelo de IA para interpretar entradas variables, como correos o documentos. Considerá un agente cuando la tarea necesita elegir qué consultar o qué hacer entre varias herramientas autorizadas. En cada opción, definí qué acciones requieren revisión y cómo vas a comprobar que el resultado sirve.
Qué cambia entre reglas, IA y agentes
Una regla expresa una decisión conocida
Una automatización por reglas puede revisar que un formulario tenga campos obligatorios, enviar un aviso cuando vence un plazo o asignar un caso según la sede. La misma entrada debería producir la misma decisión bajo las mismas condiciones. Eso facilita revisar por qué ocurrió un resultado y probar qué sucede cuando cambia una regla. Para empezar, dibujá entradas, condiciones y salidas. Si la mayoría de los casos puede decidirse con datos confiables y condiciones conocidas, un flujo de reglas puede resolver el problema con menos componentes que mantener.
Un modelo ayuda a interpretar información variable
Un correo puede describir el mismo problema con palabras diferentes. Un modelo puede proponer una categoría, extraer un número de referencia o redactar un resumen. Diseñá cómo se valida la salida antes de usarla. Si la categoría define un responsable, comprobá que pertenece a una lista permitida y que existe un camino para revisar una respuesta ambigua. El modelo puede participar en un paso acotado dentro de una automatización con reglas. Eso permite aprovechar su capacidad para interpretar texto sin abrirle permisos para ejecutar toda la operación.
Un agente puede elegir herramientas dentro de un objetivo
En una consulta sobre un pedido, un agente podría decidir si primero busca el identificador, consulta el estado en el sistema de gestión o recupera una política de entrega. Su alcance debe estar delimitado por herramientas, permisos y criterios para pedir ayuda. Definí qué puede consultar y qué efectos puede producir. Si el proceso siempre necesita las mismas tres consultas en el mismo orden, ese recorrido puede implementarse de forma explícita. El agente tiene más sentido cuando el orden depende del caso y la capacidad de elegir mejora el resultado de manera comprobable.
Cómo elegir según el tipo de proceso
| Enfoque | Cuándo probarlo | Qué control necesita |
|---|---|---|
| Reglas | Los datos tienen estructura y el negocio conoce las condiciones. | Pruebas de límites, excepciones y cambios de configuración. |
| Modelo dentro de un flujo | Hay que clasificar, extraer o resumir información variable. | Validación de la salida y una vía para revisar casos ambiguos. |
| Agente de consulta | El caso define qué fuentes o herramientas conviene consultar. | Permisos de lectura acotados, evidencia y registro de pasos. |
| Agente con acciones | El proceso requiere ejecutar pasos distintos según el contexto. | Autorización por acción, límites y aprobación humana cuando corresponde. |
Empezá por describir el costo de equivocarse
Confundir el tema de una consulta puede demorar una respuesta. Cambiar un estado comercial, cancelar un pedido o compartir información incorrecta tiene consecuencias distintas. Clasificá las acciones por reversibilidad e impacto. Para cada una, definí qué condiciones deben cumplirse, quién puede autorizarla y cómo se registrará. El costo de una revisión humana puede estar justificado si el error resulta difícil de revertir. Esta clasificación ayuda a decidir dónde alcanza con una sugerencia y dónde tiene sentido otorgar capacidad de ejecución.
Comprobá que las herramientas tengan datos utilizables
Un agente necesita fuentes de las que pueda obtener información relevante y vigente. Revisá qué herramienta tiene cada dato, cuándo se actualiza y si las personas ya conocen contradicciones. Si el sistema de gestión y una planilla informan estados distintos, definí qué fuente prevalece. Cuando una consulta puede involucrar varias cuentas, la selección debe respetar los permisos del usuario. Probá con registros que tengan nombres parecidos y confirmá que el asistente use identificadores estables antes de recuperar información o proponer una acción.
Ejemplo de aplicación en atención y operaciones
Separá clasificación, búsqueda y respuesta
Supongamos que una distribuidora recibe consultas sobre entregas. Una regla identifica mensajes sin número de pedido y abre una tarea de aclaración. Un modelo clasifica los correos en categorías como estado, cambio de domicilio o entrega parcial. Para una pregunta que combina entrega parcial y fechas distintas, un agente de lectura puede consultar el pedido y revisar la política correspondiente. La respuesta debe indicar qué dato está confirmado y qué parte requiere confirmación humana. Así cada componente aporta a una etapa y el equipo puede observar dónde aparece un error.
Mantené la decisión sensible en un circuito de aprobación
Si el cliente solicita cambiar el domicilio, el sistema puede preparar una propuesta que muestre el pedido, el domicilio registrado y el nuevo dato. Un operador autorizado revisa la solicitud antes de confirmar. El flujo registra la aprobación y verifica si el pedido todavía admite cambios. En un caso donde la entrega ya salió, la aplicación puede mostrar la situación y derivar a logística. Este diseño evita tratar toda consulta de atención como una operación equivalente. También deja una forma clara de explicar qué hizo el sistema y quién tomó la decisión.
Diseñá qué ocurre cuando el caso se sale del alcance
Un mensaje puede llegar con información insuficiente, incluir instrucciones ajenas al proceso o pedir que se consulte una cuenta diferente. Tratá ese contenido como datos recibidos, y conservá por separado las reglas autorizadas del sistema. Si no es posible verificar la cuenta o el pedido, pedí aclaración o derivá. Probá también cómo responde si una herramienta está temporalmente indisponible. Acordá qué información se conserva para que la persona pueda continuar sin repetir toda la consulta. Esta recuperación forma parte del diseño del flujo y de la evaluación del piloto.
Qué controles implementar antes de dar autonomía
Separá permisos de lectura y escritura
La herramienta que consulta un estado debería tener permisos adecuados para esa lectura. Si una segunda herramienta cambia información, debe validar el alcance de la operación en el servidor. No bases la autorización únicamente en lo que un modelo afirma haber comprobado. Vinculá cada acción con el usuario, la cuenta y el objeto correspondiente. Registrá qué se solicitó y qué efecto se confirmó. Si se repite una solicitud después de un error, comprobá si la acción ya se procesó antes de repetirla. Estas reglas siguen siendo necesarias aunque el agente ejecute correctamente la mayoría de los casos de prueba.
Definí límites de tiempo, herramientas e intentos
Un agente puede repetir consultas si la respuesta no le permite avanzar. Establecé un límite razonable de tiempo y llamadas para cada tipo de caso. Si supera ese límite, conservá el contexto útil y derivá. Definí qué herramientas puede usar y qué operaciones quedan disponibles en cada etapa. Un proceso de atención puede permitir leer estados y preparar borradores durante el piloto, con un criterio distinto para escrituras. Medí latencia y consumo además de calidad. Un flujo que resuelve una consulta correctamente pero tarda demasiado puede generar más contactos de los que evita.
Usá trazabilidad proporcional al riesgo
Guardá los pasos relevantes, las fuentes consultadas y el resultado de cada acción, con acceso controlado. No hace falta conservar datos personales completos para identificar que una consulta falló. Definí qué se necesita para diagnosticar, qué se anonimiza y cuándo se elimina. Un registro útil permite reconstruir qué herramienta produjo un dato y si un operador revisó la acción. También permite comparar el comportamiento antes y después de cambiar el modelo o una regla, sin depender de impresiones sobre una conversación aislada.
Cómo evaluar un piloto y decidir si ampliarlo
Prepará ejemplos representativos y difíciles
Incluí solicitudes normales, consultas ambiguas, falta de datos, registros duplicados, respuestas de herramientas que contradicen el contexto y operaciones que requieren aprobación. Antes de ejecutar la prueba, escribí qué resultado sería aceptable para cada caso. Medí precisión de la información, derivaciones correctas, acciones no autorizadas y tiempo de resolución. Una derivación puede ser el mejor resultado si los datos no alcanzan. Compará con una versión por reglas o con el proceso actual para saber qué mejora aporta la capacidad de elegir herramientas.
Probá en modo de sugerencia antes de automatizar escrituras
Durante una primera etapa, el sistema puede preparar respuestas o acciones que el equipo revisa. Registrá qué propuestas se aceptaron, cuáles se corrigieron y por qué. Revisá los patrones de error antes de ampliar el alcance. Si el sistema interpreta bien una pregunta pero cita un estado antiguo, resolvé la fuente y la vigencia antes de sumar herramientas. Si el equipo corrige el mismo tipo de decisión con un criterio claro, documentá esa condición como regla. Medir con evidencia permite ampliar la autonomía por acción y evitar que todo el proceso dependa de una única evaluación general.
Qué llevar a una primera reunión de diseño
Describí un proceso concreto, las fuentes que intervienen y ejemplos representativos. Listá qué acciones son de lectura, cuáles cambian datos y cuáles necesitan autorización. Acordá una prueba pequeña con resultados observables, una persona que revisará excepciones y una fecha para comparar el piloto con la línea base. Con esa información podés elegir qué resolver con reglas, qué delegar a un paso de IA y qué requiere un agente con herramientas.
Acordá un plan de salida para el piloto
Identificá qué equipo puede suspender la automatización si los datos cambian o aparece un error repetido. Prepará un canal alternativo para los casos que queden pendientes y una forma de distinguir las propuestas del agente de las decisiones confirmadas. Antes de sumar otra área, verificá que los permisos y criterios del primer piloto no se trasladen por defecto a procesos con riesgos diferentes. Esa revisión debe incluir a quienes operarán y supervisarán el circuito.
Trabajá con HEYVO
Cotizá un piloto de IA con un alcance claro
Contanos qué tarea querés resolver, qué herramientas intervienen y qué acciones deben quedar bajo revisión humana. Podemos plantear una primera prueba con criterios de calidad antes de presupuestar un alcance mayor.
Preguntas frecuentes sobre agentes de IA y automatización
¿Un chatbot siempre es un agente?
Un chatbot es una interfaz conversacional. Puede responder con reglas, consultar documentos o usar herramientas para decidir pasos. Para entender su alcance, preguntá qué fuentes usa, qué puede ejecutar y cómo deriva un caso. La interfaz por sí sola no define su nivel de autonomía.
¿Puedo combinar un agente con reglas?
Sí. Las reglas pueden validar permisos, imponer límites y ejecutar condiciones conocidas. El agente puede elegir una consulta o preparar un borrador dentro de ese marco. La combinación permite que la lógica de negocio se revise por separado de la interpretación del lenguaje.
¿Cómo sé si vale la pena un agente?
Compará casos reales con el proceso actual y con un flujo más simple. Medí cuánto trabajo se evita, si mejora la calidad y qué controles agrega. Si la mayoría de los casos se resuelve con un recorrido predecible, puede convenir reservar el agente para las excepciones que sí necesitan elegir herramientas.
¿Qué operaciones deberían requerir aprobación?
Definilo con el dueño del proceso según impacto y reversibilidad. Cambios de permisos, cancelaciones o comunicaciones con efectos para terceros merecen controles acordes al caso. Diseñá una vista que muestre qué se propone, con qué evidencia y cuál será el efecto antes de confirmar.
¿Qué pasa si el modelo cambia después del lanzamiento?
Volvé a ejecutar los casos de evaluación y compará resultados. Incluí respuestas habituales y escenarios de fallo. Conservá las reglas, los permisos y los criterios de revisión en componentes que puedan auditarse. Definí quién aprueba cambios y cómo se pausa el flujo si aparece una degradación.