Agentes de IA en producción: qué comprobar antes del lanzamiento
24 set.. 2026
Lectura rapida
Aquí puedes agregar un video
Aquí puedes agregar dos culumnas
Aquí puedes agregar un testimonio
Aquí puedes agregar una caja de texto
El piloto ya conversa con soltura, consulta información y propone respuestas útiles. El equipo comercial quiere incorporarlo a su rutina. Antes de conectarlo con clientes y registros reales, conviene cambiar la pregunta de evaluación: ¿qué evidencia demuestra que completa el trabajo correctamente, dentro de sus permisos y con una salida segura cuando algo falla?
Imaginemos un caso hipotético. Un agente recibe una consulta comercial, responde con información correcta y anuncia que registró la oportunidad. Al revisar el CRM, la oportunidad existe, pero está asociada al contacto equivocado: eligió a una persona con el mismo apellido. La conversación parece exitosa; la gestión no lo fue. Si evaluamos solo la respuesta, ese error obtiene el visto bueno.
Definir el éxito en el sistema donde ocurre el trabajo
Anthropic distingue entre el registro de una ejecución y su resultado: un agente puede afirmar que reservó un vuelo, mientras que la evidencia relevante es la reserva existente en la base de datos.[1] Para nuestro ejemplo, la prueba debe consultar el CRM después de la acción y comprobar contacto, empresa, oportunidad, campos obligatorios y ausencia de duplicados.
Negocio y tecnología deben acordar esos criterios antes de evaluar. “Atender bien” es demasiado abierto. Una definición comprobable sería: identificar al contacto sin ambigüedad, registrar únicamente los datos autorizados y dejar la gestión asignada al responsable correspondiente. Si faltan datos para distinguir entre contactos, pedir aclaración o derivar puede ser el resultado correcto.
También hay que delimitar qué queda fuera. Un agente autorizado para preparar una oportunidad no tiene por qué cambiar descuentos ni cerrar una venta. Esa frontera debe formar parte de las pruebas y de la configuración de acceso.
Probar lo habitual y lo que rompe el proceso
Construye un conjunto de casos representativos con información ficticia o debidamente anonimizada. Incluye solicitudes completas, nombres repetidos, datos contradictorios y conversaciones que cambian de intención. Añade fallos de integración: credenciales vencidas, respuestas incompletas del CRM o una conexión que se corta después de guardar.
Este último caso merece atención. Si el agente interpreta el corte como un fracaso y vuelve a crear la oportunidad, puede duplicarla. La prueba debe demostrar que verifica el estado antes de repetir una escritura y que puede dejar una operación pendiente de revisión sin anunciar un éxito inexistente.
Repite los casos relevantes: Anthropic recomienda varios intentos porque las salidas del modelo varían entre ejecuciones.[1] Conserva los fallos y vuelve a probarlos cuando cambien el modelo, las instrucciones o las integraciones. Separa los errores por gravedad; una asociación incorrecta no debe desaparecer dentro de un promedio favorable de respuestas amables.
Dar la mínima autoridad y exigir aprobaciones externas
OWASP identifica el exceso de funciones, permisos y autonomía como causas de acciones perjudiciales en aplicaciones con modelos de lenguaje.[2] Aplica el principio de mínima autoridad: habilita solo las operaciones y los datos necesarios para ese proceso. Una integración de lectura no necesita permisos para borrar contactos; tampoco necesita acceso a todas las unidades de negocio.
Esos límites deben existir fuera del texto de instrucciones. OWASP recomienda que los sistemas conectados apliquen la autorización, en lugar de confiar en que el modelo decida si una acción está permitida.[2] Prueba que una solicitud prohibida se bloquea realmente, incluso cuando llega disfrazada de instrucción dentro de un correo o documento.
Para acciones de alto impacto, OWASP propone aprobación humana previa.[2] En la práctica, conviene vincularla a una acción concreta: destinatario, contenido y cambios previstos. Un “adelante” ambiguo no debería autorizar operaciones diferentes. Si la acción cambia, se solicita otra aprobación; si nadie responde, queda pendiente. El agente no puede aprobarse a sí mismo.
Poder reconstruir y recuperar una gestión
Los registros deben permitir averiguar qué solicitud originó la operación, qué versión del agente intervino, qué herramienta utilizó, qué cambió y quién autorizó la acción. Guarda identificadores y resultados suficientes para reconstruir el incidente, con acceso restringido y plazos de conservación definidos. Evita convertir el registro en otra copia indiscriminada de datos personales.
Ensaya la recuperación en un entorno de prueba. Para la oportunidad asociada al contacto equivocado, el procedimiento debería identificar el registro afectado, detener acciones posteriores y permitir una corrección revisada. Volver a una versión anterior del agente no corrige por sí solo los datos que ya modificó.
Designa un responsable operativo con capacidad para pausar el servicio, gestionar pendientes y coordinar correcciones. Debe tener suplencia y un canal de escalamiento. “Lo ve el equipo de IA” deja demasiadas decisiones sin dueño cuando el área comercial necesita una respuesta.
Medir el trabajo bien completado, también después del lanzamiento
Anthropic plantea combinar evaluaciones con monitoreo en producción y revisión humana para comprender el comportamiento del agente.[1] Empieza con un alcance acotado y revisa resultados reales antes de ampliarlo. Vigila asociaciones erróneas, duplicados, derivaciones, intentos bloqueados y pendientes acumulados, además de tiempos de respuesta.
Para valorar la viabilidad económica, proponemos medir el costo por gestión completada correctamente: costo operativo del período dividido entre las gestiones verificadas como correctas. Incluye consumo del modelo, herramientas, reintentos, supervisión y correcciones; declara qué costos quedan fuera. Compara el mismo tipo de trabajo con el proceso anterior. Una respuesta barata puede salir cara si alguien debe reparar después el CRM.
Acuerda qué situaciones activan una alerta o una pausa y quién responde. Los límites deben justificarse según el daño posible y la capacidad de revisión, no copiarse de una tasa de éxito ajena.
Checklist de salida: pedir evidencia antes del sí
Antes de autorizar producción, solicita un expediente breve que permita comprobar:
- Criterios de éxito aprobados y resultados verificados en el sistema de destino, incluida la identidad del contacto.
- Casos habituales, ambiguos y fallidos ejecutados, con repeticiones y errores clasificados por impacto.
- Permisos mínimos documentados y pruebas de bloqueo de acciones fuera de alcance.
- Aprobaciones externas ensayadas, incluidas ausencia de respuesta y modificación de la acción aprobada.
- Registros suficientes y un ejercicio de recuperación completado sin duplicar operaciones.
- Responsable operativo, suplencia, alertas y mecanismo de pausa comprobados.
- Costo por gestión correcta calculado con datos del piloto y límites de esa medición explícitos.
Si falta una evidencia, mantén restringida la capacidad correspondiente. No hace falta conceder toda la autonomía de una vez.
Si tu empresa ya tiene un piloto, puedes conversar con Blue Nose sobre qué proceso conviene revisar primero. Lleva un flujo concreto y ejemplos anonimizados de aciertos y fallos: permiten discutir los datos del CRM, las integraciones y las responsabilidades antes de ampliar el alcance.
Sources
Aquí puedes agregar una firma
SUSCRIBETE A NUESTRO BLOG
