El agente que consulta datos no debería mover la operación

🎛️ El agente que consulta datos no debería mover la operación

Separar consulta, propuesta y ejecución

En la mesa de control de una cadena de retail ya hay un agente que responde quiebres de inventario, revisa pedidos demorados y redacta explicaciones para las tiendas. El ambiente cambia cuando alguien pregunta si también puede reprogramar una transferencia entre bodegas o tocar el ERP, porque el piloto luce útil mientras consulta datos, pero su radio de acción deja de ser inocente cuando se acerca a la maniobra.

Diseñar agentes sobre datos empresariales se parece más a habilitar un operador en cabina que a abrir otro chat, porque el valor nace de decidir qué ve, qué puede ejecutar, quién lo frena y cómo queda la bitácora de cada paso.

El término técnico útil aquí es agente con herramientas sobre datos empresariales, un sistema donde el modelo no solo conversa sino que también consulta fuentes, llama APIs, ejecuta búsquedas o propone acciones sobre sistemas del negocio. Como recurso pedagógico para el lector no técnico, ayuda imaginar un centro de control donde cada operador ve ciertos monitores y solo algunos tienen permiso de despacho, aunque la imagen sirve solo para traducir la idea y el término correcto sigue siendo agente con herramientas.

Anthropic publicó en diciembre de 2024 una guía basada en implementaciones reales donde recomienda arrancar con la solución más simple posible y subir complejidad solo cuando mejore el desempeño, y Microsoft llegó a una conclusión parecida en Architecture Center en 2026 al señalar que un agente único con herramientas suele ser el punto de partida razonable para muchos casos empresariales y que el patrón multiagente solo vale la pena cuando la especialización o los límites de seguridad lo exigen. Esa convergencia importa operativamente porque si la tarea cabe en recuperación de información, reglas claras y una salida revisable, todavía no hay motivo para soltar un agente autónomo sobre procesos vivos.

Por eso el primer corte serio de arquitectura pasa por separar consulta de ejecución, de modo que un agente que responde preguntas sobre cartera, inventario o contratos entre primero por vistas aprobadas, capas semánticas o índices de recuperación que ya respeten definiciones y filtros del negocio, en lugar de hablar directo con tablas transaccionales o APIs de escritura. Microsoft advierte además que cada patrón trae fallas propias, desde bucles de herramientas hasta conflictos sobre estado compartido, así que la arquitectura debe fijar límites de iteración, rutas deterministas cuando el flujo sea predecible y escalamiento a humano cuando el caso se salga del guion.

Después aparece identidad y permisos, y allí el principio de privilegio mínimo importa más que en un tablero estático, ya que el agente suele tener más capacidad de descubrimiento que un usuario promedio y puede juntar fragmentos dispersos hasta revelar algo que nadie quiso exponer completo. El Architecture Center de Microsoft insiste en aplicar security trimming en cada agente, una regla que obliga a que la respuesta respete el alcance del usuario que pregunta y no el alcance amplio del servicio que ejecuta las búsquedas, de modo que el agente no termine operando como un relevo de turno con acceso a todas las consolas cuando solo fue habilitado para leer un indicador.

NIST ordena este problema con cuatro funciones fáciles de recordar, gobernar, mapear, medir y gestionar, y el valor del marco no está en convertirlo en una lista mecánica, porque el playbook aclara que no funciona como checklist universal. Su aporte real es obligar a que cada sistema tenga dueño, contexto de riesgo, criterio de medición y respuesta de contención antes de recibir herramientas, algo que encaja muy bien con agentes sobre datos porque el error serio rara vez nace en una frase mal redactada y suele aparecer cuando nadie definió alcance, evidencia y plan de reversa.

A partir de ahí entra la traza usable, así que un agente sobre datos debería registrar pedido original, plan seguido, herramientas invocadas, fuentes consultadas, política aplicada y resultado entregado al usuario. Anthropic recomienda condiciones de parada y verdad del entorno en cada paso, mientras Microsoft plantea instrumentar operaciones y transferencias entre agentes de extremo a extremo, una exigencia que en lenguaje menos técnico equivale a pedir bitácora y relevo formal para que un incidente no termine reducido a la última respuesta del chat.

La evaluación pide otra disciplina y no solo brillo de demo, porque un agente que consulta datos empresariales puede producir salidas útiles, correctas a medias o peligrosas aun cuando suenen seguras y por eso Microsoft recomienda usar rúbricas para flujos no deterministas. AgentDojo, un benchmark de ETH Zurich e Invariant Labs publicado en 2024, reunió 97 tareas realistas y 629 pruebas de seguridad donde incluso modelos de punta fallan muchas tareas aun sin ataque, y además mostró que la inyección de prompts puede entrar por la información que devuelve una herramienta y desviar al agente hacia una acción maliciosa.

En un operador logístico la diferencia entre improvisar y diseñar bien aparece rápido cuando se le pide a un agente revisar inventario de Bogotá, leer órdenes atrasadas y sugerir una reposición entre centros de distribución. Si el equipo le da acceso directo a una base productiva de lectura y escritura, más una herramienta que mueve stock sin aprobación, el agente queda a un salto de convertir una inferencia dudosa en un cambio real de operación.

Mire un contraste simple en una integración típica.

unsafe = Agent(tools=[
    SqlTool(conn="erp_prod_rw"),
    MoveStockTool(),
])

unsafe.run(
    "revisa inventario de Bogota y mueve 200 unidades desde Cali si ves faltantes"
)

safe = Agent(tools=[
    ApprovedViewQuery(view="inventory_readonly"),
    ReplenishmentProposalTool(),
    ApprovalGate(role="supervisor_operaciones"),
])

plan = safe.run("revisa inventario de Bogota y propone reposicion")
safe.tools["ApprovalGate"].request(plan)

El primer agente confunde observación con facultad porque consulta y actúa dentro del mismo canal, sin una capa que distinga leer de intervenir, sin vistas aprobadas y sin un paso explícito de aprobación para la maniobra sensible. El segundo todavía automatiza trabajo útil, pero lo hace sobre una vista de solo lectura, produce una propuesta legible y reserva la ejecución para un supervisor, algo que para un lector no técnico se parece a separar monitoreo, recomendación y autorización en la misma cabina.

Algo parecido ya pasó con la automatización anterior a esta ola de agentes y el caso de Nordea Bank documentado por Aalto University y Hanken School of Economics en 2021 no giró alrededor de si los robots de software escribían más rápido, sino de cómo gobernar desarrollo, mantenimiento e infraestructura cuando la automatización ya tocaba transacciones, reportes y consultas reguladas. La lección sigue vigente porque cuando una capacidad nueva entra a procesos críticos, la carga humana se mueve hacia excepciones, permisos, soporte y responsabilidad operativa, no hacia la velocidad con que la demo impresiona.

Por eso los agentes sobre datos tampoco borran a los equipos que conocen el negocio, más bien les desplazan la carga hacia decisiones que antes quedaban repartidas o implícitas. El dueño de proceso debe definir qué decisión admite sugerencia y cuál exige aprobación, el equipo de datos necesita publicar vistas y diccionarios que el agente sí pueda leer sin inventar uniones peligrosas, seguridad y cumplimiento deben fijar qué herramientas pueden existir y qué evidencia debe quedar, y operaciones conserva el derecho de apagar el turno cuando aparezca una desviación repetida.

Hay un matiz importante para no convertir esta recomendación en dogma, porque un agente interno que resume manuales públicos o explica el estado de un ticket puede vivir con una arquitectura mucho más ligera que otro que consulta datos personales, toca precios, mueve inventario o prepara una respuesta regulatoria. En escenarios de bajo riesgo basta muchas veces con lectura controlada, citas visibles y un límite de iteraciones, mientras que en escenarios sensibles conviene sumar un ciclo creador revisor donde un agente propone y otro valida contra criterios explícitos, aprobación humana sobre llamadas específicas, entornos separados y pruebas de ataque antes de abrir el acceso a producción.

Una forma sobria de empezar cabe en una sola hoja de diseño con caso permitido, fuentes autorizadas, herramientas expuestas, alcance por rol, acción prohibida, límite de iteraciones, criterio de aprobación, bitácora esperada y prueba de seguridad antes de turno. Si esa hoja todavía tiene vacíos, el agente aún no está listo para sentarse en la cabina y la operación no debería enterarse del experimento por un despacho equivocado.

Recursos para revisar

#AgentesIA #GobiernoDeDatos #ArquitecturaDeDatos #SeguridadIA #Trazabilidad #OperacionesDigitales

Referencias
National Institute of Standards and Technology. (2024). Artificial Intelligence Risk Management Framework Generative Artificial Intelligence Profile. NIST. https://doi.org/10.6028/NIST.AI.600-1
National Institute of Standards and Technology. (2023). NIST AI RMF Playbook. NIST. https://airc.nist.gov/AI_RMF_Knowledge_Base/Playbook
Kittel, C., Siemens, C., Alaganandam, H., Lee, J., Modi, R., Setayesh, M., Taylor, M., & Vaknin, Y. (2026). AI agent orchestration patterns. Microsoft Architecture Center. https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/ai-agent-design-patterns
S. Erik, & Zhang, B. (2024, diciembre 19). Building effective agents. Anthropic Engineering. https://www.anthropic.com/engineering/building-effective-agents
Debenedetti, E., Zhang, J., Balunović, M., Beurer Kellner, L., Fischer, M., & Tramèr, F. (2024). AgentDojo, a dynamic environment to evaluate prompt injection attacks and defenses for LLM agents. arXiv. https://arxiv.org/abs/2406.13352
Kedziora, D., & Penttinen, E. (2021). Governance models for robotic process automation, the case of Nordea Bank. Journal of Information Technology Teaching Cases, 11(1), 20-29. https://doi.org/10.1177/2043886920937022