Agentes low-code conectados directo a tus datos en vivo

En Sapphire este año, SAP mostró Joule Studio 2.0 generando un agente completo a partir de una sola descripción en lenguaje natural — no solo el código, sino la especificación del producto, la lógica del flujo de trabajo, la configuración multiagente, e incluso la suite de evaluación. Y los agentes que construye están "anclados de forma nativa en los datos de negocio en vivo y en los procesos de extremo a extremo de todo tu entorno SAP." OutSystems lanzó una plataforma agéntica low-code comparable. La promesa es la misma: describe el agente que quieres, y aparece, ya conectado a tus sistemas reales.

Esto es un salto real, y no quiero ser quien lo descarte con un gesto de la mano. Dejar que un analista de negocio construya un agente funcional sobre el sistema de producción sin esperar semanas en una cola de ingeniería es genuinamente valioso. Pero vale la pena tener claridad sobre lo que acaba de volverse fácil — porque construir el agente nunca fue la parte riesgosa. Conectarlo a tus datos en vivo y dejarlo actuar sí lo era.

Qué significa de verdad «low-code sobre datos en vivo»

Quita la magia de la demo y este es el arreglo: una persona que no es ingeniero describe lo que quiere en una frase, y una herramienta produce un agente capaz de leer y actuar sobre tus sistemas de negocio reales —pedidos, finanzas, registros de clientes— a velocidad de máquina. El anclaje en datos en vivo es exactamente lo que lo hace útil. También es exactamente lo que lo hace peligroso, y esos dos hechos son inseparables.

Lo que determina cuánto daño puede hacer un agente no es qué tan inteligente es. Es cuánto puede tocar. Una evaluación reciente encontró que la ejecución de herramientas —lo que a un agente se le permite hacer de verdad— es el mayor predictor individual del radio de impacto, explicando el 76% de él. Un agente low-code que nace ya conectado a un ERP en vivo empieza su vida con alcance máximo. Esa es toda la funcionalidad, y todo el problema.

La mayoría de las empresas no puede contener lo que ya está corriendo

Si la historia de la contención fuera sólida, esto estaría bien. No lo es. Los números sobre organizaciones que ya corren agentes son aleccionadores: el 63% no puede imponer límites a lo que un agente tiene permitido hacer, el 60% no puede apagar rápidamente un agente que se porta mal, y el 55% no puede aislarlo del resto de la red. El setenta por ciento tiene agentes en producción, y la mayoría de esos agentes tienen más acceso que los humanos que hacen el trabajo equivalente.

Ahora entrega la capacidad de crear esos agentes a personas sin formación en ingeniería, sobre una plataforma que los conecta a datos en vivo por defecto, y puedes ver hacia dónde va esto. No obtienes un agente cuidadosamente acotado. Obtienes docenas de agentes sin gobierno, cada uno con amplio alcance, levantados por personas a quienes nunca se les pidió pensar en permisos, y que nadie puede ver ni detener por completo. Eso no es hipotético; es el patrón del desarrollador-ciudadano chocando con la realidad de exposición-por-defecto sobre la que escribí, a una escala mucho mayor.

Las barandillas aburridas importan más, no menos

El reflejo es decir «entonces no dejes que los no ingenieros construyan agentes». Eso es irreal y además está equivocado — la productividad es real y la cola era un problema genuino. La respuesta correcta es que cuando la creación se democratiza, las barandillas tienen que estar integradas en la plataforma, no dejadas a la buena voluntad de quien sea que tecleó la frase. Algunas cosas que tienen que ser innegociables:

• Privilegio mínimo por defecto, no alcance máximo. Un agente debería empezar con el acceso más estrecho que le permita hacer su trabajo y ganar más de forma deliberada — lo opuesto a «nacer conectado a todo». Si la plataforma trae acceso amplio por defecto, ese es el error.
• Un botón de apagado que funcione de verdad. Si el 60% de las organizaciones no puede detener un agente que se porta mal, eso es lo primero que hay que arreglar. Deberías poder pausar cualquier agente al instante, sin importar quién lo construyó.
• Una frontera real entre los sistemas deterministas y el juicio del agente. Esta es la misma lección que rediseñar los flujos de trabajo para agentes: las reglas, los límites y las aprobaciones que protegen los datos en vivo deben ser compuertas duras y deterministas dentro de las cuales el agente razona, no cosas sobre las que puede actuar libremente.
• El sandboxing como requisito de compra. La misma investigación encontró que un sandboxing probado reduce el riesgo residual cerca de 2.6×. Si una plataforma low-code no puede mostrarte cómo aísla lo que sus agentes pueden tocar, esa es tu respuesta.

En resumen

Los agentes low-code sobre datos en vivo van a estar en todas partes, rápido, porque la ventaja es obvia y la demo es irresistible. No te estoy diciendo que los evites — te estoy diciendo que la parte fácil acaba de volverse más fácil y la parte difícil no se movió. Generar un agente a partir de una frase está resuelto. Asegurarte de que ese agente no pueda arruinar en silencio los datos en vivo de tu negocio, y de que alguien pueda verlo y detenerlo, es exactamente tan difícil como siempre lo fue.

Así que cuando una plataforma se ofrezca a dejar que cualquiera construya un agente conectado a tus sistemas reales, haz las preguntas poco glamorosas antes de celebrar: qué puede tocar, quién puede detenerlo, y dónde está el muro entre su juicio y tu fuente de verdad. Si la plataforma tiene buenas respuestas, esto es un regalo. Si no las tiene, no estás democratizando agentes — estás democratizando el radio de impacto.