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

Tecnología 🌐 ES · EN

Diseñar agentes sobre datos empresariales exige separar consulta y ejecución, aplicar permisos mínimos, dejar trazabilidad y evaluar con escenarios reales.

All articles include both versions in their content: Spanish first, then English.
The agent that reads data should not move operations

🎛️ El agente que consulta datos no debería mover la operació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

Versión en inglés

🎛️ The agent that reads data should not move operations

In the control room of a retail chain there is already an agent answering inventory gaps, checking delayed orders, and drafting explanations for stores. The atmosphere shifts when someone asks whether it should also reschedule a transfer between warehouses or touch the ERP, because the pilot looks helpful while it reads data, but its operating radius stops being harmless the moment it gets close to execution.

Designing agents over enterprise data looks more like enabling an operator in the cabin than opening another chat window, because the value depends on deciding what it can see, what it can execute, who can stop it, and how every step is written into the logbook.

The useful technical term here is an agent with tools over enterprise data, a system where the model does more than talk and instead queries sources, calls APIs, runs searches, or proposes actions over business systems. As a teaching aid for a non technical reader, it helps to picture a control center where each operator sees a specific set of monitors and only some can authorize dispatch, although that image is only a bridge and the correct term remains an agent with tools.

Anthropic published a guide in December 2024 based on real implementations and advised teams to start with the simplest possible solution, then add complexity only when outcomes improve, and Microsoft reached a similar conclusion in Architecture Center in 2026 by noting that a single agent with tools is often the reasonable starting point for enterprise cases and that multiagent patterns only justify themselves when specialization or security boundaries demand them. That convergence matters operationally because if the task fits retrieval, clear rules, and a reviewable output, there is still no reason to release an autonomous agent into live processes.

That is why the first serious architectural cut is the separation between reading and execution, so an agent that answers questions about receivables, inventory, or contracts should first go through approved views, semantic layers, or retrieval indexes that already respect business definitions and filters instead of speaking directly to transactional tables or write APIs. Microsoft also warns that every pattern carries its own failure modes, from tool loops to conflicts over shared state, so the architecture needs iteration limits, deterministic routes when the flow is predictable, and human escalation when the case leaves the script.

Identity and permissions come right after that, and least privilege matters more here than in a static dashboard, given that the agent often has more discovery power than an average user and can assemble fragments until it reveals something nobody intended to expose as a whole. Microsoft Architecture Center insists on security trimming in every agent, a rule that forces the answer to respect the scope of the user who asked and not the broad scope of the service performing the search, so the agent does not behave like a shift replacement that received access to every console even though it was only enabled to read one indicator.

NIST organizes this problem through four functions that are easy to remember, govern, map, measure, and manage, and the value of the framework is not turning it into a mechanical list because the playbook itself says it is not a universal checklist. Its real contribution is forcing every system to have an owner, a risk context, a measurement rule, and a containment response before it receives tools, which fits data agents especially well because the serious error rarely starts with a badly written sentence and usually appears when no one defined scope, evidence, and rollback.

Usable traceability enters at that point, so a data agent should leave a record of the original request, the plan it followed, the tools it invoked, the sources it touched, the policy it applied, and the result delivered to the user. Anthropic recommends stop conditions and environmental feedback at every step, while Microsoft calls for instrumenting operations and agent transfers end to end, which in less technical language means the cabin needs a logbook and a formal handover.

Evaluation demands a different discipline, because an agent that queries enterprise data cannot be validated only with a clean demo or exact string matching when its outputs can be useful, half correct, or dangerous even while sounding confident. AgentDojo, a benchmark from ETH Zurich and Invariant Labs published in 2024, assembled 97 realistic tasks and 629 security test cases where even leading models fail many tasks without any attack, and that finding reinforces Microsoft guidance to use rubrics for nondeterministic flows and to treat tool returned content as an active risk surface.

In a logistics operator the difference between improvisation and solid design shows up fast when an agent is asked to inspect inventory in Bogota, read delayed orders, and suggest replenishment between distribution centers. If the team gives it direct access to a production database with read and write privileges, plus a stock movement tool with no approval gate, the agent sits one step away from turning a doubtful inference into a real operational change.

Look at a simple contrast in a typical integration.

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

unsafe.run(
    "review Bogota inventory and move 200 units from Cali if you see shortages"
)

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

plan = safe.run("review Bogota inventory and propose replenishment")
safe.tools["ApprovalGate"].request(plan)

The first agent confuses observation with authority because it reads and acts through the same channel, with no layer separating visibility from intervention, no approved views, and no explicit approval step for the sensitive maneuver. The second agent still automates useful work, but it does so over a read only view, produces a legible proposal, and reserves execution for a supervisor, which for a non technical reader resembles separating monitoring, recommendation, and authorization inside the same cabin.

Something similar already happened with the automation wave that came before these agents, and the Nordea Bank case documented by Aalto University and Hanken School of Economics in 2021 did not revolve around whether software robots typed faster but around how to govern development, maintenance, and infrastructure once automation touched transactions, reporting, and regulated queries. The lesson still holds because when a new capability enters critical processes, the human load shifts toward exceptions, permissions, support, and operational accountability, not toward the speed of the demo.

That is why data agents do not erase the teams who understand the business and instead shift their work toward decisions that used to remain distributed or implicit. The process owner must define which decision can accept a suggestion and which one requires approval, the data team needs to publish views and dictionaries the agent can read without inventing unsafe joins, security and compliance must define which tools may exist and what evidence must remain, and operations keeps the right to stop the shift when a repeated deviation appears.

There is an important nuance so that this advice does not become dogma, because an internal agent that summarizes public manuals or explains ticket status can live with a much lighter architecture than one that queries personal data, touches prices, moves inventory, or prepares a regulatory answer. In low risk scenarios, controlled reading, visible citations, and an iteration cap are often enough, while in sensitive scenarios it makes sense to add a maker reviewer loop where one agent proposes and another validates against explicit criteria, human approval on specific calls, separated environments, and attack testing before opening production access.

A sober way to begin fits on a single design sheet with an allowed case, authorized sources, exposed tools, role scope, forbidden action, iteration limit, approval rule, expected logbook, and security test before shift. If that sheet still has blanks, the agent is not ready to sit in the cabin yet and operations should not find out about the experiment through a wrong dispatch.

Summary

Un agente que consulta datos empresariales vale menos por lo que redacta que por el radio de acción que se le asigna. La evidencia de NIST, Anthropic, Microsoft, AgentDojo y el antecedente de Nordea apunta a la misma conclusión, separar lectura y ejecución, aplicar permisos mínimos, dejar rastro de cada herramienta y evaluar por escenarios reales importa más que la espectacularidad de la demo.