Durante los últimos años hemos aprendido a trabajar con chatbots capaces de resumir documentos, explicar código, redactar correos o responder preguntas sobre una base de conocimiento. Son útiles, pero casi siempre existe un límite claro: producen una respuesta y esperan que una persona haga el resto.

Los agentes de IA cambian esa frontera.

Un agente no solo puede decirte qué habría que hacer. Puede disponer de herramientas, consultar sistemas, mantener estado y ejecutar una secuencia de acciones hasta alcanzar un objetivo. El OpenAI Agents SDK, por ejemplo, articula este tipo de aplicaciones alrededor de agentes equipados con instrucciones y herramientas, un bucle de ejecución, guardrails, delegación entre agentes y trazabilidad.

La diferencia parece pequeña sobre el papel. En una empresa, sin embargo, cambia por completo el problema de arquitectura.

Un chatbot responde; un agente actúa

Imagina que un responsable de ventas escribe:

“Revisa las oportunidades que llevan más de dos semanas paradas y dime cuáles deberíamos priorizar.”

Un asistente convencional puede recibir datos y elaborar una lista.

Un agente podría ir más lejos:

1. Consultar el CRM;
2. Localizar oportunidades sin actividad reciente;
3. Contrastarlas con importe, probabilidad y fecha prevista;
4. Comprobar el histórico de interacciones;
5. Preparar una propuesta de prioridades;
6. Crear tareas para los responsables correspondientes;
7. Registrar lo realizado;
8. Devolver un resumen y señalar las excepciones que necesitan intervención humana.

Ahí aparece la característica decisiva: la IA ha pasado de producir información a intervenir sobre un proceso.

Por eso la pregunta relevante ya no es únicamente qué modelo utilizar. También hay que decidir qué herramientas recibe, con qué identidad actúa, qué permisos posee, qué información conserva, cómo se valida cada paso y cuándo debe detenerse.

Las seis piezas de un agente empresarial

1. Un objetivo suficientemente concreto

“Mejora nuestras operaciones” es una mala tarea para un agente.

“Cada mañana identifica pedidos bloqueados, busca la causa conocida, prepara la acción correctiva permitida y escala las excepciones” es mucho mejor.

Los agentes funcionan mejor cuando el resultado esperado y las condiciones de finalización pueden comprobarse. Si no sabemos qué significa “terminado”, será difícil saber cuándo el agente debe dejar de actuar.

Ese criterio también permite evaluar el sistema con métricas reales: porcentaje de tareas completadas, intervenciones humanas, errores, reversión de acciones, tiempo ahorrado o coste por ejecución.

2. Herramientas, no acceso indiscriminado

La capacidad práctica de un agente procede en gran medida de sus herramientas.

Puede disponer de funciones para consultar SQL, leer documentos, crear incidencias, actualizar un CRM, ejecutar código o interactuar con otros servicios. Estándares como Model Context Protocol están precisamente orientados a conectar aplicaciones basadas en modelos con datos y herramientas externas mediante interfaces estandarizadas.

Pero una herramienta debería representar una capacidad bien delimitada, no una puerta abierta al sistema.

Es preferible ofrecer:

consultar_estado_pedido(id)

o

crear_borrador_incidencia(...)

antes que conceder acceso genérico a toda la base de datos o permitir ejecutar cualquier operación posible.

Cuanto más pequeña y explícita sea cada capacidad, más fácil será autorizarla, probarla, registrarla y revocarla.

3. Identidad y permisos de mínimo privilegio

Este punto separa rápidamente una demostración de una implementación empresarial.

Si un agente puede actuar sobre sistemas reales, debemos saber quién es y qué puede hacer.

En 2026 ya vemos plataformas empresariales tratando la identidad de los agentes como un problema específico. Microsoft Entra, por ejemplo, documenta identidades especializadas para agentes con mecanismos de autenticación, autorización y gobierno diferenciados; Google también incluye identidad, políticas y gobierno entre las piezas de su plataforma empresarial de agentes.

La regla práctica debería ser la misma que aplicamos a cualquier servicio crítico: mínimo privilegio.

Si un agente solo necesita leer facturas, no debería poder modificarlas. Si puede generar un cambio, quizá no deba poder aprobarlo. Y si ejecuta una acción por delegación de un usuario, esa delegación debería estar claramente delimitada.

No conviene convertir la cuenta de una persona en la identidad permanente de una automatización.

4. Estado y memoria: recordar solo lo necesario

Un agente que ejecuta procesos de varios pasos necesita mantener contexto.

Pero conviene distinguir varias cosas que habitualmente llamamos “memoria”:

• Estado de la ejecución actual;
• Historial de la conversación;
• Datos recuperados de sistemas corporativos;
• Preferencias duraderas;
• Resultados intermedios;
• Conocimiento que puede reutilizarse en futuras sesiones.

No todos esos datos deberían persistirse.

Guardar todo “por si acaso” aumenta costes, ruido contextual y superficie de riesgo. En sistemas empresariales, una buena arquitectura decide explícitamente qué estado es efímero, qué información puede conservarse y durante cuánto tiempo.

La memoria útil debe ser intencionada, auditable y eliminable.

5. Guardrails y validaciones alrededor de las acciones

Un modelo puede equivocarse. También puede interpretar mal una instrucción o recibir contenido malicioso desde una página, un email o un documento.

OWASP identifica precisamente la prompt injection, incluida la indirecta mediante fuentes externas, el abuso de herramientas, la escalada de privilegios y la exfiltración de datos entre los riesgos relevantes para sistemas agentivos.

Por eso no deberíamos confiar exclusivamente en un prompt que diga “no hagas nada peligroso”.

Las restricciones importantes deben estar implementadas fuera del modelo.

Podemos validar:

• los parámetros antes de ejecutar una herramienta;
• que el usuario o agente tenga autorización;
• los límites económicos de una operación;
• que un identificador pertenezca al cliente correcto;
• el formato y contenido del resultado;
• si la acción exige aprobación;
• el número máximo de iteraciones;
• el tiempo y coste máximos de una ejecución.

Frameworks actuales ya incorporan este patrón. Los guardrails de herramientas del OpenAI Agents SDK, por ejemplo, permiten intervenir antes y después de determinadas llamadas, bloquearlas o detener la ejecución cuando una condición no se cumple.

El principio es sencillo: el modelo propone; el sistema autoriza.