El problema no es solo responder: es actuar
Un agente puede resumir una solicitud correctamente y, aun así, ejecutar una acción que la empresa no autorizó. Modificar un registro, enviar una propuesta o cerrar un caso de atención tiene consecuencias distintas a preparar un borrador. Cuando la IA obtiene acceso a los sistemas, la pregunta deja de ser únicamente “¿la respuesta es buena?” y pasa a incluir “¿debería realizarse esta acción?”.
Para los gestores, el desafío es transformar esa distinción en reglas operativas. ¿Quién define los límites? ¿Quién analiza una excepción? ¿Cómo se interrumpe el proceso? Recomendamos responder estas preguntas antes del piloto, junto con las personas que conocen el trabajo cotidiano. La autonomía debe ser una decisión explícita sobre cada actividad, no una configuración genérica aplicada a toda la empresa.
Empiece por el camino más sencillo
Anthropic distingue los flujos con pasos previamente definidos de los agentes que deciden dinámicamente cómo utilizar herramientas. En su guía de arquitectura, recomienda aumentar la complejidad solo cuando sea necesario. Esta distinción ayuda a evitar que una secuencia predecible de validaciones se convierta, sin justificación, en una decisión abierta del modelo.
En la práctica, dibuje primero el proceso: entrada, consulta, interpretación, propuesta de acción y ejecución. Identifique dónde existe ambigüedad que requiere interpretación y dónde basta una regla determinista. Un sistema puede utilizar IA para comprender un mensaje y código convencional para validar campos obligatorios. No es necesario delegar todas las etapas al mismo componente.
Separe tres niveles de actuación
Como punto de partida, proponemos tres niveles. En el primero, el agente solo consulta información autorizada y prepara sugerencias. En el segundo, ejecuta acciones delimitadas y reversibles, como añadir una etiqueta interna. En el tercero, prepara acciones sensibles, pero espera una aprobación explícita antes de ejecutarlas. Esta clasificación es una propuesta de diseño, no una norma universal.
La clasificación depende del contexto. Una etiqueta puede modificar la prioridad de un caso de atención y afectar a un cliente; por tanto, “reversible” no significa “sin riesgo”. Para cada acción, registre el impacto posible, el alcance de los datos, el responsable y la condición de interrupción. Si el equipo no puede explicar cómo detectar y corregir un error, mantenga la ejecución supervisada.
Ejemplo hipotético: una solicitud comercial
Imagine una distribuidora que recibe solicitudes de cambio de plazo por correo electrónico. Este es un ejemplo hipotético, no un caso de cliente de NM Solutions. El agente lee el mensaje, identifica el pedido y consulta los datos permitidos. Después prepara un resumen con la solicitud, los registros consultados y la información que falta.
Si el identificador no corresponde a un pedido válido, el flujo deriva el caso para su revisión, sin adivinar. Si existe un pedido válido, el agente puede elaborar una respuesta preliminar. La modificación del plazo y el envío al cliente se mantienen separados: el responsable ve exactamente qué cambiará y aprueba o rechaza esa propuesta específica.
Tras la aprobación, una integración ejecuta el cambio y registra el resultado. Si el sistema de pedidos no está disponible, la solicitud permanece pendiente. El cliente no recibe una confirmación falsa. También es necesario reconocer los intentos repetidos: reenviar un mensaje o repetir una llamada no debe producir un segundo cambio ni un envío duplicado indebido.
La aprobación debe ser útil, no simbólica
Una pantalla que solo ofrece “aprobar” y “rechazar” transfiere trabajo sin aportar contexto. Recomendamos presentar la solicitud original, los datos relevantes, la acción propuesta y su efecto esperado. Si la propuesta cambia después de la revisión, la autorización anterior no debe aplicarse automáticamente a una acción diferente.
OWASP relaciona el riesgo de autonomía excesiva con funcionalidades, permisos y libertad de acción que superan lo necesario. Entre las medidas de mitigación están limitar las herramientas y los accesos y exigir aprobación humana para acciones de alto impacto. Estos controles deben existir en el sistema que ejecuta la acción, no solo en las instrucciones enviadas al modelo.
También es importante tratar los mensajes, documentos y páginas consultadas como datos, no como autorización para modificar el proceso. Un texto externo puede intentar inducir al agente a realizar otra tarea. Las reglas de acceso, las validaciones independientes y la supervisión ayudan a reducir la exposición, pero no eliminan todos los riesgos.
Mida la calidad antes de ampliar la autonomía
Antes del piloto, registre cómo trabaja el equipo actualmente. Observe el tiempo total por caso, el retrabajo, los errores de derivación y la cantidad de casos que necesitan análisis especializado. Durante la prueba, incluya el costo por caso completado, las propuestas rechazadas, los fallos de integración y el esfuerzo dedicado a la revisión. Una respuesta rápida que exige muchas correcciones puede no mejorar la operación.
Defina criterios de avance y suspensión con los responsables del proceso. Pruebe situaciones incompletas, contradictorias y repetidas, además de los ejemplos sencillos. No utilice una tasa global de acierto para ocultar errores graves en una categoría específica. Ampliar el alcance debe depender de evidencias y de la capacidad del equipo para supervisar el cambio.
Un primer paso con responsabilidad
Elija un proceso con límites claros, un responsable disponible y una forma verificable de evaluar el resultado. Mantenga una vía manual para las excepciones y documente quién puede detener al agente. El objetivo inicial no es eliminar toda intervención humana, sino descubrir dónde ayuda la automatización sin trasladar riesgos de manera silenciosa.
NM Solutions ayuda a mapear procesos, integraciones y límites de actuación para estructurar iniciativas de IA conectadas a la operación. Si su empresa está evaluando este camino, una conversación de diagnóstico puede ayudar a definir el alcance del primer piloto.