Agente, chatbot, IA o RPA: cómo elegir para una tarea

Primero describe la tarea que quieres resolver

Elegir entre automatización con reglas, RPA e inteligencia artificial requiere entender la tarea y sus excepciones. La forma del dato es una pista, pero no decide por sí sola la tecnología. Un texto puede resolverse con un formulario o una búsqueda simple; una tabla puede contener decisiones ambiguas que necesitan revisión profesional.

Empieza por identificar la entrada, la acción permitida y la evidencia de salida. Pregunta qué información puede variar, qué errores serían graves y qué parte del trabajo debe aprobar una persona. Esta descripción permite comparar propuestas sobre el mismo problema en lugar de comparar nombres comerciales.

Un flujo pequeño que prepara un borrador puede ser suficiente para comenzar. Añadir un agente con múltiples herramientas no demuestra más valor si no mejora una decisión o una tarea concreta. La tecnología se selecciona después de aclarar el alcance y los controles.

Agente, chatbot y automatización no son equivalentes

Un chatbot es una interfaz de conversación y puede funcionar con reglas o modelos. Una automatización ejecuta pasos definidos. Un agente puede utilizar un modelo para decidir acciones dentro de límites y herramientas autorizadas. Tener lenguaje natural no implica autonomía para modificar sistemas de la empresa.

Anthropic distingue flujos predefinidos y agentes como patrones de diseño. Es una referencia conceptual, no una clasificación legal ni una certificación del producto de un proveedor. En una propuesta conviene pedir ejemplos de las acciones concretas que se permiten y de las que requieren revisión.

Una misma solución puede combinar conversación, reglas y aprobación. Por ejemplo, interpretar la pregunta de una persona, consultar un catálogo autorizado y pedir confirmación antes de crear una solicitud. La conversación explica la salida; los permisos y las validaciones controlan la acción.

Cuándo considerar reglas, API o RPA

Las reglas ayudan cuando las condiciones pueden expresarse y verificarse. Una API autorizada permite intercambiar datos mediante un contrato técnico. La RPA suele operar pasos sobre interfaces y puede ser útil cuando no existe otro acceso viable. Ninguna de estas opciones está libre de fallos: pueden cambiar pantallas, formatos, permisos o reglas del negocio.

Para una suma o una validación de campos, el cálculo determinista facilita reproducir el resultado. Si una propuesta introduce interpretación probabilística en esa parte, pregunta qué necesidad resuelve y cómo se comprueba su salida. La revisión no consiste en descartar modelos, sino en usarlos donde aporten a la tarea.

Una automatización por pantalla requiere evaluar estabilidad, permisos y mantenimiento. Que una página sea visible no acredita autorización para automatizarla. Si una fuente exige controles de acceso o limita consultas, el diseño debe respetarlos y contemplar una alternativa autorizada.

Qué cambia cuando se usa un modelo

Un modelo puede ayudar a interpretar lenguaje, proponer categorías o redactar un borrador. Su respuesta puede ser incorrecta aunque esté escrita con seguridad. Por eso se necesitan fuentes identificables, salidas estructuradas cuando corresponda y validaciones antes de ejecutar cambios.

Una orden incluida en un documento no debe convertirse en permiso para usar herramientas. El sistema separa contenido recibido de instrucciones operativas y limita las acciones disponibles. Cuando falta evidencia suficiente, debe pedir información o derivar a la persona responsable, sin completar datos por intuición.

El costo también cambia según modelo, volumen y tamaño de las entradas y salidas. No todas las tareas necesitan el mismo modelo ni una conversación extensa. La propuesta debe explicar qué se procesa, qué se conserva y cómo se evitan llamadas innecesarias.

Recibir y preparar una factura

Datos de prueba. Un flujo recibe un documento estructurado, valida sus campos y prepara una propuesta contable. La lectura de un campo con nombre puede resolverse sin un modelo; una descripción ambigua puede requerir clasificación asistida y revisión. La aprobación contable permanece separada.

La DIAN describe la validación previa. Ese control no decide por sí solo la cuenta, el centro de costo o el tratamiento de una operación en una empresa. Tampoco todos los documentos recibidos tienen necesariamente el formato o la calidad esperados.

La salida del ejemplo es un borrador con observaciones, no una contabilización garantizada. Puedes ampliar esa separación en la guía de causación. Antes de escribir en un sistema real se verifican acceso, permisos, duplicados y estado final del registro.

Construye una muestra que permita decidir

Reúne casos representativos de las variaciones de la tarea, incluyendo datos incompletos y errores. Una muestra no se vuelve suficiente por alcanzar un número redondo. Su utilidad depende de qué situaciones cubre y de qué decisiones quieres evaluar. Conserva una parte para comprobar el diseño después de ajustarlo.

Para cada caso, registra la salida esperada, la fuente que la justifica y quién la puede confirmar. Distingue errores leves de errores que afectan dinero, derechos, seguridad o información personal. Un promedio de aciertos puede ocultar una falla crítica que sólo aparece en una clase de entradas.

No adoptes porcentajes universales para decidir cuándo usar IA. Observa si hay reglas claras, cuántas excepciones relevantes aparecen y cuánto cuesta resolverlas. Cuando no existe una respuesta esperada acordada, primero hay un problema de definición del proceso que una herramienta no puede resolver sola.

Compara propuestas con el mismo recorrido

Pide una demostración de entrada, acción, revisión y resultado. Comprueba qué acceso y entorno se usan, y cuáles resultados se verificaron contra cuentas autorizadas. Una pantalla atractiva no acredita que una integración esté lista ni que soporte las excepciones de tu negocio.

Separa implementación, infraestructura, licencias, uso del modelo y mantenimiento. Pregunta por límites de consumo y por el procedimiento para detener una automatización. La opción de menor precio aparente puede omitir revisiones o dependencia de un proveedor que luego sea difícil sustituir.

Solicita también documentación de propiedad y acceso a los datos. Define quién administra cuentas, quién conserva las credenciales y qué ocurre al terminar el servicio. Una integración útil debe poder explicarse y operarse sin depender de una conversación informal con la persona que la construyó.

Fallos que el diseño debe contemplar

• Una fuente cambia de columnas o deja de responder.
• La misma entrada llega repetida o dos procesos actúan al tiempo.
• El modelo propone un campo que no existe en el sistema.
• El servicio externo crea un recurso y se pierde su respuesta.
• Una persona retira un permiso o solicita eliminar información.
• El trabajo queda pendiente de aprobación y cambia el responsable.

Esos casos necesitan estados visibles y una recuperación acotada. Repetir una orden sin comprobar su resultado puede duplicar operaciones. Conservar una referencia y consultar el estado suele ser parte del diseño; la estrategia exacta depende del contrato del sistema externo.

Cómo medir y cuándo ampliar

Establece una línea base antes de atribuir mejoras. Mide entradas, resultados válidos, excepciones, tiempo de revisión y errores relevantes bajo condiciones comparables. Distingue capacidad estimada de tiempo realmente aprovechado, y costos evitados de costos que continúan existiendo.

El diagnóstico orientativo ayuda a ordenar una tarea con reglas locales; no audita una empresa ni certifica una arquitectura. El estimador calcula escenarios a partir de supuestos y muestra revisión y capacidad, que puede ser negativa.

Para revisar un proyecto concreto, explora automatización de procesos o describe la tarea. El siguiente paso comercial consiste en verificar fuentes, permisos y criterios de aceptación. No requiere prometer autonomía total ni reemplazar a quienes deben decidir sobre excepciones.

En la aceptación incluye una entrada correcta y otra que deba permanecer pendiente. La persona que evalúa debe poder explicar la diferencia sin leer el código. Comprueba también que detener el flujo impida nuevas acciones y que las operaciones ya iniciadas mantengan un estado consultable. Si cambia una regla o un permiso, conserva su versión y vuelve a comprobar los casos afectados antes de ampliar la tarea.