IA aplicada

Agentes de IA con criterio: cómo evaluar un agente antes de contratarlo

Antes de contratar un agente, pide evidencia sobre su alcance, datos, permisos y recuperación ante fallas. Cinco frentes y un piloto acotado para evaluar la propuesta.

Rubén Villasmil23 de octubre de 20267 min de lectura
Rubén contrasta un caso de prueba impreso con una ejecución en una computadora.

Una evaluación de agentes de IA debe empezar por una tarea concreta y por las consecuencias de que salga mal. Pide al proveedor que muestre qué hace el agente, qué datos usa, qué puede modificar y cómo se recupera el trabajo cuando falla. La prueba debe incluir el error. Una demostración que solo recorre el caso favorable deja sin responder las preguntas que importarán cuando el sistema opere con tu equipo.

Antes de contratar, escribe qué decisión necesitas tomar y qué evidencia la sostendría. No basta con ver una respuesta convincente: necesitas entender el recorrido completo y los límites de actuación. Estos cinco frentes ayudan a convertir una presentación comercial en una revisión práctica, sin exigir al equipo que se vuelva especialista en cada componente técnico.

1. Delimita la tarea y lo que queda fuera

Pregunta qué evento inicia el trabajo, qué información necesita y qué resultado debe entregar. “Automatizar la atención” es demasiado amplio para evaluar una implementación. Clasificar consultas, preparar una respuesta o actualizar un registro son tareas diferentes. Para cada una, especifica cuándo se considera terminada y qué situaciones requieren intervención de una persona.

El alcance debe poder comprobarse con ejemplos. Pide recorrer casos habituales y excepciones de tu negocio con información de prueba. Si el proveedor cambia la explicación de la tarea según la pregunta, todavía falta una definición compartida. No interpretes una demostración fluida como prueba de que el alcance está resuelto.

Anota también las exclusiones. Un agente que prepara una propuesta no necesita, por ese motivo, poder cambiar condiciones comerciales o enviarla sin revisión. La guía sobre qué necesita una empresa antes de sumar agentes de IA plantea las bases del proceso. La evaluación previa a contratar debe convertir esas bases en un trabajo verificable.

2. Sigue el recorrido de los datos

Pide que el proveedor explique qué información entra, de qué sistemas proviene, dónde se procesa y qué se conserva. Incluye archivos adjuntos, registros de actividad y copias de prueba. No necesitas aceptar una explicación llena de nombres técnicos: necesitas poder identificar qué datos del negocio atraviesan cada parte del servicio y con qué propósito.

Pregunta quién puede acceder a esa información, cómo se retira un acceso y qué ocurre cuando deja de utilizarse el servicio. No entregues datos que la tarea no necesita. Para la prueba inicial, usa información ficticia o preparada sin datos sensibles cuando sea posible. Si se requiere información real, define primero el alcance y los controles correspondientes.

Una alerta concreta es que nadie pueda describir el recorrido de un documento o diferenciar los datos del entorno de prueba de los de operación. Solicita un esquema entendible y una demostración con un registro de ejemplo. Si una respuesta queda pendiente, registra quién debe aclararla antes de avanzar.

Analista revisa una lista de comprobación junto a una computadora.

3. Revisa los permisos antes de habilitar acciones

Haz una lista de lo que el agente puede consultar y otra de lo que puede cambiar. Después pregunta qué acciones requieren aprobación humana. Leer una ficha, modificarla, enviar un mensaje y borrar información no tienen la misma consecuencia. Un permiso debe responder a una tarea definida. La comodidad de configuración no basta como motivo para dar acceso amplio.

Pide ver qué ocurre cuando el agente intenta una acción fuera de su alcance. ¿La operación se detiene? ¿Se solicita aprobación? ¿Quién recibe esa solicitud y qué información puede revisar? La seguridad de agentes de IA necesita traducirse en comportamientos comprobables, además de explicaciones generales sobre protección.

Incluye cambios de equipo: una persona deja su rol, una integración se reemplaza o una tarea deja de estar autorizada. Pregunta quién actualiza permisos y cómo confirma que el cambio se aplicó. Si una función necesita una excepción, debe quedar identificada antes de ampliar el acceso, junto con el motivo y el responsable de revisarla.

4. Comprueba si podrás reconstruir lo ocurrido

Un registro útil debería permitir entender qué solicitud se recibió, qué información se consultó, qué acción se intentó y cuál fue su resultado. Pide ver cómo se relacionan esos pasos en un caso de prueba. Un mensaje que solo diga “tarea completada” puede dejar fuera la información necesaria para revisar una decisión o investigar una falla.

El registro debe servir a quien revisa el trabajo. Pregunta quién puede consultarlo, qué datos expone y cómo se encuentra una conversación o una acción determinada. Define también qué información conviene excluir del registro para no reproducir datos sensibles sin necesidad. Más detalle no equivale por sí solo a mejor control.

Propón una revisión sencilla: otra persona del equipo recibe el caso terminado y debe explicar qué hizo el agente y qué quedó pendiente. Si necesita pedir una reconstrucción verbal al proveedor para cada caso, identifica qué evidencia falta. La evaluación de agentes de IA debe contemplar ese trabajo de revisión cotidiano.

5. Ensaya la falla y la recuperación

Pregunta qué pasa si una herramienta no responde, falta información o una ejecución se interrumpe después de realizar parte del trabajo. Pide mostrar cómo se informa el estado y quién decide el siguiente paso. Reintentar no debe confundirse con empezar de nuevo. Por ejemplo, comprueba cómo se evita enviar dos veces un mensaje cuando la confirmación del primer envío no llega.

Ese ejemplo es una situación de prueba, no un incidente atribuido a un proveedor. Usa el mismo criterio para revisar qué se puede corregir, qué requiere una acción compensatoria y qué cambio no puede deshacerse. Pregunta quién puede detener el agente y cómo continúa el equipo mientras el problema se investiga.

Asigna un contacto responsable de los problemas operativos y acuerda cómo se comunican las limitaciones conocidas. Si la única respuesta es que el agente aprende solo o no debería fallar, falta evidencia para decidir. Necesitas un procedimiento observable para reconocer la falla, limitar su efecto y retomar el trabajo.

Rubén y una analista revisan una lista de prueba y registran observaciones en un cuaderno.

Haz un piloto acotado y decide con evidencia

Antes de ampliar, elige un proceso, un período definido y criterios escritos. No hay una duración universal: debe permitir observar situaciones representativas sin dar por evaluado lo que todavía no ocurrió. Separa las condiciones necesarias para operar de las mejoras que pueden revisarse después.

Una checklist de evaluación de agentes de IA puede pedir evidencia de estos puntos:

  • La tarea y sus exclusiones están documentadas.
  • Se conoce el recorrido de los datos de prueba.
  • Los permisos y las aprobaciones fueron ensayados.
  • Otra persona puede reconstruir una ejecución.
  • Se probó una falla y la forma de retomar el trabajo.
  • Existe un responsable de revisar excepciones y detener la operación.

Si una pregunta crítica sigue sin respuesta, deja esa parte fuera del alcance inicial. No hace falta resolver todas las posibilidades para comenzar una prueba, pero sí reconocer qué condiciones todavía no permiten operar y quién debe aportar la evidencia pendiente.

Define la aceptación antes de ver la demostración. Al cerrar el piloto, separa lo comprobado, lo fallido y lo que sigue sin probarse. No conviertas “no observamos errores” en una garantía de funcionamiento. Esa distinción permite decidir si ampliar, corregir o mantener la tarea bajo atención humana.

Qué deja el recorrido de la serie

La serie comenzó por las condiciones que necesita una pyme antes de incorporar agentes. Luego revisó atención al cliente, finanzas y recursos humanos. En la pieza sobre por qué RRHH requiere especial cuidado al automatizar aparece una pregunta transversal: qué decisiones siguen necesitando criterio y responsabilidad humana.

Este quinto episodio reúne esas preguntas en una decisión de contratación. Las soluciones de agentes de IA deben evaluarse según el trabajo que permiten sostener y revisar. El cierre no consiste en elegir entre entusiasmo y rechazo, sino en pedir evidencia suficiente para el alcance que vas a autorizar.

Si estás comparando propuestas, puedes revisar con Veylo el alcance y las pruebas de un agente antes de contratarlo. La conversación puede partir de una tarea concreta, los datos que utiliza y las acciones permitidas, para identificar qué necesitas comprobar y quién debe responder cuando algo se aparta de lo previsto.

Dudas comunes

¿Quién debería participar en la evaluación?

Incluye a quien conoce el proceso, a quien recibirá las excepciones y a quien administra los accesos o las conexiones. Cada rol puede revisar un riesgo distinto. Acuerda quién reúne la evidencia y quién decide si las condiciones observadas son suficientes para el alcance propuesto.

¿Qué hago si el proveedor no puede compartir una ejecución de otro cliente?

No necesitas información privada de otro negocio para revisar el funcionamiento. Pide una demostración con datos ficticios y un recorrido equivalente a tu tarea. La confidencialidad de terceros no impide explicar el alcance, los permisos, la forma de registrar acciones y el procedimiento de recuperación.

¿Cómo comparo propuestas que usan nombres técnicos diferentes?

Usa la misma tarea, las mismas exclusiones y los mismos casos de prueba para todas las propuestas. Registra qué evidencia presenta cada una y qué parte requiere una explicación adicional. Comparar resultados observables y responsabilidades ayuda más que contar funciones que podrían describir capacidades distintas.

¿Hay que repetir la evaluación después de contratar?

Conviene revisar nuevamente las partes afectadas cuando cambian herramientas, fuentes de datos, permisos o el alcance de la tarea. Conserva los casos de prueba para poder repetirlos. Una aprobación previa describe lo que se comprobó en una configuración; no demuestra por sí sola el comportamiento de una configuración posterior.