Un agente IA puede resumir información, preparar una propuesta o crear una tarea en otro sistema. Antes de darle acceso a datos y acciones reales, conviene comprobar qué hace en situaciones normales, ambiguas y erróneas. Las pruebas de aceptación convierten esa comprobación en un criterio de paso: el agente no se conecta a producción porque “parece funcionar”, sino porque ha superado escenarios acordados.
Este enfoque no requiere convertir cada proceso en un laboratorio. Sirve para empezar por un caso acotado —por ejemplo, clasificar solicitudes, preparar un borrador o proponer una actualización— y decidir con claridad qué puede hacer el agente, qué debe dejar preparado y qué debe escalar a una persona.
Definir la acción que se quiere validar
El primer paso no es elegir un modelo ni escribir prompts. Es describir la tarea con un verbo y un resultado comprobable. “Ayudar con ventas” es demasiado amplio; “extraer los datos de una solicitud y crear un borrador de oportunidad sin enviarla” permite probar entradas, salidas y límites.
Para cada acción, documenta:
- el evento que inicia el trabajo;
- los sistemas y fuentes autorizados;
- el resultado esperado y dónde se guarda;
- las acciones que el agente nunca puede ejecutar por sí solo;
- la persona o equipo que resuelve las excepciones.
Si el alcance incluye acciones sobre CRM, ERP, correo o herramientas de soporte, el diseño debe separar la recomendación de la ejecución. Un agente puede preparar una propuesta de cambio; la aplicación efectiva puede requerir una regla determinista, una aprobación o ambas. En KMOOPS diseña e integra agentes IA con ese reparto de responsabilidades desde el inicio.
Convertir el proceso en casos de aceptación
Una prueba de aceptación se formula como una situación concreta, una entrada controlada y un resultado que alguien puede revisar. No basta con preguntar si la respuesta suena razonable. Hay que poder distinguir entre un resultado aceptable, uno incompleto y uno que debe detener el flujo.
Casos normales
Incluye los casos que el proceso espera recibir con más frecuencia: una solicitud completa, un documento legible o una consulta que coincide con una fuente autorizada. Define qué campos debe devolver el agente, qué fuente ha usado y cuál es el siguiente paso permitido.
Casos incompletos o ambiguos
Prueba entradas sin datos esenciales, con instrucciones contradictorias o con varias interpretaciones posibles. El comportamiento correcto no siempre es completar la información: puede ser pedir una aclaración, marcar el expediente para revisión o no ejecutar ninguna acción.
Casos que deben bloquearse
Incluye peticiones fuera de alcance, intentos de alterar instrucciones, datos que no pertenecen al proceso y solicitudes de acciones sensibles. El criterio de éxito aquí es que el agente no improvise: conserva el contexto necesario para investigar y escala el caso por la ruta definida.
Preparar un conjunto de pruebas representativo
El conjunto no tiene que ser enorme para ser útil. Debe reflejar el trabajo real sin exponer datos innecesarios. Se pueden usar registros históricos previamente revisados, datos anonimizados o expedientes creados para la prueba.
Etiqueta cada caso con su propósito: extracción, clasificación, consulta de conocimiento, creación de borrador, propuesta de acción, excepción o bloqueo. Añade además la decisión esperada y quién la valida. Así se evita que la evaluación dependa de la memoria de una sola persona o de una demostración puntual.
Cuando un agente consulta documentación interna, prueba también versiones antiguas, documentos retirados y fuentes a las que no debería acceder. Un resultado correcto necesita apoyarse en información vigente y dentro del permiso del usuario o del proceso.
Medir lo que importa sin inventar una nota global
Un único porcentaje puede ocultar errores relevantes. Es más útil revisar varios criterios por tipo de tarea:
- Completitud: devuelve los campos y pasos necesarios.
- Fidelidad a la fuente: no atribuye a un documento algo que no contiene.
- Respeto de políticas: aplica las reglas y límites definidos.
- Escalado: deriva los casos dudosos al responsable adecuado.
- Seguridad de la acción: no ejecuta cambios fuera de su autorización.
Los criterios deben adaptarse al riesgo de la acción. Un agente que resume una incidencia puede tolerar un borrador mejorable si hay revisión posterior. Uno que propone cambios en datos maestros, envía comunicaciones o activa una operación necesita condiciones más estrictas y una barrera antes de ejecutar.
Separar evaluación, aprobación y ejecución
El mismo resultado no debería servir como prueba, autorización y registro final. Diseña tres capas:
- El agente prepara una respuesta, clasificación o propuesta con sus fuentes y datos de entrada.
- Una persona o una regla verificable decide si el resultado cumple las condiciones.
- El sistema autorizado ejecuta la acción y registra qué se aplicó, cuándo y con qué aprobación.
Esta separación ayuda a detectar errores sin que el propio agente se valide a sí mismo. También facilita revisar después una decisión, repetir una prueba tras cambiar una integración o explicar por qué un caso se detuvo.
Probar el flujo completo, no solo la conversación
Un agente puede responder bien en una interfaz y fallar al llamar a una herramienta, transformar un dato o recibir una respuesta inesperada de una API. Las pruebas de aceptación deben incluir el recorrido completo: entrada, recuperación de contexto, reglas, llamada a la integración, resultado y registro.
Para las integraciones, usa un entorno de prueba o acciones simuladas cuando sea posible. Comprueba especialmente duplicados, reintentos, falta de permisos, respuestas lentas, indisponibilidad de un sistema y cambios de formato. El objetivo es confirmar que el proceso se detiene o se recupera de forma segura, no demostrar que nunca fallará.
Definir condiciones de paso a producción
Antes de activar el agente, deja por escrito qué debe cumplirse. Por ejemplo: todos los casos de bloqueo se detienen, las acciones reales requieren la aprobación prevista, los resultados conservan la referencia a su fuente y las excepciones llegan a una cola con responsable.
También decide qué impide el paso. Un error que cambia un dato sensible, envía un mensaje a un destinatario incorrecto o usa una fuente no autorizada no se compensa con buenos resultados en otros casos. Debe corregirse, volver a probarse y documentarse.
Mantener las pruebas cuando cambia el proceso
La aceptación no termina con el despliegue. Un cambio de modelo, prompt, herramienta, permiso, fuente de conocimiento o regla de negocio puede modificar el comportamiento. Conserva los casos que detectaron problemas, incorpora las incidencias reales revisadas y vuelve a ejecutar las pruebas relevantes antes de ampliar alcance.
Programa además una revisión cuando cambie la política que gobierna la acción. Si el negocio modifica las condiciones para aprobar una solicitud, el agente no debe seguir usando el criterio anterior por inercia.
Cuándo merece la pena pedir ayuda externa
Conviene estructurar esta validación cuando el agente consulta información interna, conecta varios sistemas, prepara decisiones con impacto económico o puede actuar sobre clientes, proveedores o empleados. En esos casos, el reto no es solo técnico: hay que acordar el proceso, los controles y la evidencia necesaria.
Si quieres delimitar un caso de uso, diseñar su conjunto de pruebas e integrarlo con tus aplicaciones, habla con KMOOPS. El objetivo es desplegar un agente que aporte trabajo útil dentro de unos límites que tu equipo pueda revisar y mantener.