GUÍA DE REFERENCIA
Qué es un agente de IA y cómo funciona en profundidad
Un agente de IA no es un modelo que ha recibido permiso para hacerlo todo. Es un sistema diseñado para avanzar hacia un objetivo, elegir entre opciones y actuar dentro de un marco que también define qué no puede hacer.
RESPUESTA RÁPIDA
Un agente de IA es un sistema que utiliza un modelo, instrucciones y contexto para decidir cómo avanzar hacia un objetivo. Cuando la tarea lo requiere, puede consultar información o ejecutar acciones mediante herramientas. Lo hace dentro de reglas, permisos y controles definidos. Debe contar con criterios para terminar o detenerse y, cuando el proceso lo requiera, escalar a una persona.
Esta guía explica de qué piezas se compone, qué ocurre durante una ejecución, en qué se diferencia de soluciones próximas, cuánta autonomía puede tener y qué condiciones ayudan a decidir si merece la pena utilizarlo.
¿Qué es un agente de IA?
Una definición operativa, no una frontera universal
En esta guía llamamos agente de IA a un sistema orientado a un objetivo en el que un modelo interpreta la situación y puede decidir el siguiente paso entre varias opciones. El sistema recibe instrucciones y contexto; cuando procede, utiliza herramientas para consultar datos o realizar acciones; después observa lo ocurrido y decide si continúa, termina, se detiene o necesita intervención humana.
La definición es deliberadamente operativa. Sirve para examinar cómo se comporta el sistema sin exigir una etiqueta universal que hoy no existe. Algunas fuentes reservan “agente” para implementaciones en las que el modelo controla dinámicamente el flujo; otras incluyen sistemas más pautados que combinan rutas definidas con decisiones del modelo. Esa diferencia puede verse, por ejemplo, al comparar las formulaciones de OpenAI, Anthropic y las orientaciones de la Agencia Española de Protección de Datos.
La etiqueta importa menos que tres preguntas observables:
- ¿Quién decide los pasos: una secuencia programada, una persona o el modelo dentro de una orquestación?
- ¿Puede el sistema consultar herramientas o producir efectos fuera de la conversación?
- ¿Qué límites, permisos y criterios determinan si continúa o devuelve el control?
Un modelo es una pieza del sistema. Puede clasificar, redactar, extraer información o proponer una acción, pero no contiene por sí solo los accesos, el estado del proceso, las reglas de negocio ni los mecanismos de aprobación. El agente aparece cuando esas piezas se organizan alrededor de un objetivo y el modelo participa de forma relevante en la elección de cómo avanzar.
Propiedades frecuentes y propiedades opcionales
No todos los agentes tienen la misma arquitectura. Conviene separar la base operativa de las características que se añaden cuando la tarea las necesita.
| Tipo | Propiedad | Qué significa en la práctica |
|---|---|---|
| Base operativa | Objetivo e instrucciones | Existe un resultado buscado y un marco que orienta la actuación. |
| Base operativa | Decisión contextual | El siguiente paso puede depender de la entrada, del estado o de una observación reciente. |
| Frecuente | Herramientas | El sistema puede consultar una fuente, calcular, registrar o ejecutar una acción. No necesita usarlas en cada paso. |
| Frecuente | Verificación y criterio de salida | Se comprueba lo ocurrido y se decide si continuar, terminar, detenerse o escalar. |
| Opcional | Memoria persistente | Se conserva información entre sesiones o ejecuciones cuando aporta valor y está permitido. |
| Opcional | Planificación explícita | Se formula o actualiza un plan con varios pasos; muchas tareas no lo requieren. |
| Opcional | Autonomía elevada | Algunas acciones se ejecutan sin aprobación previa dentro de umbrales definidos. |
| Opcional | Varios agentes | Se reparten responsabilidades entre componentes especializados. |
| No implícita | Aprendizaje continuo | Guardar estado o recibir feedback no significa reentrenar ni mejorar automáticamente el modelo. |
Qué no convierte por sí solo a un sistema en agente
Una interfaz de chat no basta: describe una forma de interacción. Tampoco basta una llamada aislada a un modelo, una respuesta construida con documentos recuperados o el uso de una API. Esas capacidades pueden formar parte de un agente, pero no demuestran que el sistema elija dinámicamente entre pasos y gestione lo que ocurre después.
Una automatización que recorre siempre la misma ruta no se convierte por ello en un agente al incluir una generación de texto. Puede formar parte de un sistema agéntico entendido como categoría más amplia, pero esta guía reserva “agente” para el control dinámico descrito por su definición operativa. La ruta fija puede ser una solución excelente y más previsible. La distinción útil no es “lleva IA o no”, sino qué decisiones se han delegado al modelo y cuáles siguen fijadas por código, reglas o personas.
Qué significa IA agéntica
IA agéntica —también escrita como “IA agentiva” o agentic AI— funciona como término paraguas para describir sistemas o comportamientos orientados a objetivos que combinan interpretación, decisión y acción. Puede referirse a un agente individual, a un flujo con componentes agénticos o a una arquitectura con varios agentes.
Por eso, leer “sistema agéntico” no permite deducir por sí solo cuánta autonomía posee, si mantiene memoria o si actúa sin aprobación. Esas propiedades deben explicarse. La terminología abre la conversación; la arquitectura y los controles muestran qué hace realmente el sistema.
Un agente interpreta una situación, decide entre opciones y, cuando procede, actúa dentro de límites definidos.
Anatomía de un agente de IA
La anatomía responde a de qué está hecho el sistema y cómo se relacionan sus piezas. No describe todavía el orden de una ejecución. En una solución concreta, algunos componentes pueden estar unidos, repartidos entre varios servicios o ausentes si no hacen falta.
Objetivo y criterio de finalización
El objetivo expresa qué resultado debe perseguirse: responder una consulta con fuentes, clasificar una solicitud, preparar un registro o coordinar una tarea. Para que sea operable necesita criterios de salida. El sistema debe reconocer no solo que ha completado la tarea, sino también que falta información, que ha alcanzado un límite o que no existe una acción segura.
Un objetivo como “gestiona este correo” es demasiado abierto si no aclara qué resultados son válidos, qué compromisos no puede asumir y cuándo debe intervenir una persona.
Instrucciones, reglas y límites
Las instrucciones orientan la interpretación del modelo: función, prioridades, formato, fuentes permitidas y condiciones de escalado. Como el comportamiento de un modelo es variable, una instrucción no debe confundirse con un control infalible.
Las reglas aplicadas por código pueden imponer condiciones cuyo cumplimiento no depende de que el modelo siga una instrucción: impedir importes superiores a un umbral, rechazar un formato inválido o bloquear una herramienta fuera de un entorno autorizado. Los límites también pueden fijar número de pasos, tiempo, coste o tipos de acción.
Contexto, estado y memoria
El contexto es la información disponible para resolver el paso actual: la petición, instrucciones, documentos pertinentes, resultados de herramientas y datos de la ejecución. No equivale a “todo lo que sabe la empresa”. Debe seleccionarse y mantenerse dentro de límites técnicos y de autorización. La explicación de ingeniería de contexto de Anthropic subraya precisamente que el contexto es finito y debe organizarse.
El estado registra dónde se encuentra el proceso: qué pasos se han completado, qué datos se han obtenido y qué aprobaciones están pendientes. La memoria puede conservar parte de ese estado durante una conversación o recuperarlo en futuras sesiones. Es opcional y debe tener propósito, vigencia y permisos. Recordar información no significa que el modelo haya actualizado sus parámetros ni que aprenda por sí solo.
Modelo
El modelo interpreta entradas y produce una salida que la orquestación puede usar como respuesta, decisión, clasificación, parámetros para una herramienta o propuesta de siguiente paso. Diferentes pasos podrían emplear modelos distintos según dificultad, coste o latencia.
Cuando se habla de “razonamiento” en este contexto se describe un mecanismo computacional para elaborar una respuesta o seleccionar pasos. No implica conciencia, intención propia ni pensamiento humano, y tampoco garantiza que la conclusión sea correcta.
Herramientas y acciones
Una herramienta expone una capacidad concreta: buscar en una base documental, consultar un CRM, calcular un importe, crear un borrador o actualizar un estado. Puede estar implementada mediante una función, una API, una consulta a una base de datos o una interfaz controlada.
La descripción de la herramienta ayuda al modelo a entender cuándo usarla y qué parámetros necesita. Su esquema debe limitar entradas y salidas, y la ejecución debe validar ambos lados. Una herramienta disponible amplía lo que el sistema puede hacer; no demuestra que deba hacerlo en cualquier situación.
Orquestación, verificación y salida humana
La orquestación conecta las piezas. Conserva estado, prepara contexto, llama al modelo, ejecuta herramientas autorizadas, aplica reglas y decide qué ruta del sistema se activa con cada resultado. Puede incluir pasos deterministas alrededor de una decisión probabilística.
La verificación comprueba aspectos observables: formato, presencia de fuentes, coherencia con reglas, estado devuelto por una API o necesidad de aprobación. No toda corrección puede verificarse automáticamente; en tareas sensibles puede ser necesaria una revisión humana competente.
Las excepciones no son un borde accidental. Forman parte del diseño: falta un dato, dos fuentes discrepan, una acción no es reversible o una integración no responde. El escalado humano necesita trasladar el contexto suficiente para que una persona pueda entender qué ocurrió y decidir con autoridad.
Anatomía de un agente de IA
Un sistema de piezas coordinadas dentro de permisos, reglas y controles; la salida humana queda fuera de esa envolvente.
Equivalente textual del diagrama
Permisos, reglas y controles envuelven objetivo e instrucciones, contexto, orquestación, modelo, herramientas, estado o memoria, acciones y verificación. La orquestación ocupa el centro y se relaciona con el resto. Excepción, aprobación y escalado humano permanecen fuera y se conectan con orquestación, verificación y acciones.
La capacidad surge de varias piezas; los límites acotan su alcance y el control comprueba los puntos críticos.
Cómo funciona un agente de IA paso a paso
El ciclo describe qué ocurre durante una ejecución. A diferencia de la anatomía, aquí sí importa el tiempo. Un patrón habitual alterna interpretación, acción y observación, una idea estudiada en trabajos como ReAct; no obstante, una implementación real puede simplificar, dividir o acotar ese patrón.
1. Recibe una entrada y reúne contexto
La ejecución puede comenzar con una petición de una persona, un documento nuevo, un cambio de estado o una señal programada. La orquestación identifica el objetivo, recupera solo la información pertinente y comprueba qué identidad, permisos y reglas se aplican.
Si falta un dato imprescindible, el sistema no debería inventarlo. Puede solicitarlo, abstenerse o trasladar la tarea a una persona.
2. Interpreta la situación y decide el siguiente paso
El modelo relaciona la entrada con las instrucciones y el contexto disponible. Puede decidir responder, consultar otra fuente, llamar a una herramienta, preparar una acción o declarar que no puede continuar.
La decisión no ocurre en el vacío: la orquestación restringe las opciones y puede imponer rutas obligatorias. En un diseño híbrido, el modelo resuelve la parte ambigua y el código conserva las decisiones estables.
3. Utiliza una herramienta o genera una acción
Si hace falta actuar, el sistema selecciona una herramienta permitida y prepara sus parámetros. Antes de ejecutarla, puede validar el formato, comprobar un umbral o solicitar aprobación. La herramienta puede devolver datos, confirmar un cambio o informar de un error.
4. Observa y verifica el resultado
El agente incorpora la observación al estado actualizado. No basta con que la llamada técnica haya respondido: puede ser necesario comprobar que el registro correcto cambió, que las fuentes respaldan la respuesta o que el resultado satisface el criterio de aceptación.
5. Continúa, termina, se detiene o escala
Con la nueva información, el sistema puede dar otro paso, presentar el resultado, detenerse por un límite o escalar una excepción. Si una herramienta falla, los reintentos deben estar acotados. Si una acción necesita aprobación, la ejecución puede quedar pausada. Si ya no existe una ruta válida, terminar con una explicación es preferible a improvisar.
Pensemos en una consulta interna: el sistema recibe una pregunta, recupera documentos permitidos, encuentra dos versiones contradictorias y verifica sus fechas. En lugar de elegir una al azar, detiene la respuesta definitiva y deriva el conflicto al responsable del procedimiento. La salida útil no siempre es completar la tarea; a veces es identificar con precisión por qué no debe completarla.
Ciclo de funcionamiento
La ejecución alterna decisión, acción, observación y verificación hasta terminar, detenerse o escalar.
Equivalente textual del diagrama
Secuencia principal: recibe, reúne contexto, interpreta, decide, usa una herramienta o actúa, observa y verifica. Después continúa, termina, se detiene o escala. Si continúa, vuelve al contexto actualizado.
Salidas laterales: falta información, fallo de herramienta, aprobación necesaria, límite alcanzado o ausencia de una acción segura o válida.
El sistema puede actuar, necesita observar el resultado y, con esa evidencia, decidir cómo continúa.
Agente de IA vs chatbot, copiloto y automatización
Las etiquetas comerciales se solapan. Un chatbot puede usar herramientas; un copiloto puede ejecutar pasos con aprobación; una automatización puede combinar reglas con una decisión del modelo. Para comparar conviene observar el control del proceso, la ruta, las herramientas y la supervisión.
| Dimensión | Chatbot | Copiloto | Automatización basada en reglas | Agente de IA |
|---|---|---|---|---|
| Función habitual | Suele conversar o facilitar una interacción | Suele asistir a una persona durante su trabajo | Suele ejecutar una ruta predefinida | Suele avanzar hacia un objetivo dentro de límites |
| Quién dirige los pasos | Habitualmente, la persona o el flujo conversacional | Normalmente, la persona | El código y las reglas predefinidas | El modelo puede elegir pasos dentro de la orquestación |
| Ruta | Conversacional; puede ser fija o flexible | Suele estar guiada por la persona | Predefinida y habitualmente determinista | Puede variar según contexto y observaciones |
| Herramientas | Opcionales | Frecuentes, normalmente bajo control del usuario | Integraciones predefinidas | Selección dinámica o condicionada entre herramientas permitidas |
| Capacidad de acción | Variable | Suele proponer, preparar o asistir | Puede ejecutar acciones predefinidas | Puede ejecutar acciones dentro de permisos y controles |
| Estado o memoria | Opcional | Frecuente, según producto | Puede mantener el estado del flujo | Opcional, según la tarea |
| Supervisión | Habitualmente durante la conversación | Normalmente, la persona mantiene el control | Suele concentrarse en controles o excepciones | Varía según impacto, permiso y nivel de autonomía |
| Mejor encaje habitual | Información e interacción | Trabajo asistido | Proceso estable y previsible | Variabilidad que exige decidir entre pasos o herramientas |
Chatbot, copiloto, automatización y agente
Cuatro categorías comparadas en paralelo mediante las mismas dimensiones; ninguna representa una etapa superior.
Equivalente textual del diagrama
La tabla «Comparación por dimensiones observables» situada antes de esta figura ofrece el equivalente textual completo para las cuatro categorías y sus ocho dimensiones.
La tabla describe tendencias, no fronteras absolutas ni una escala de calidad.
Agente vs chatbot
“Chatbot” describe sobre todo una interfaz conversacional. Puede limitarse a responder, pero también puede consultar datos, llamar a herramientas y activar un proceso. En ese segundo caso, la experiencia sigue siendo un chat aunque parte del sistema tenga comportamiento agéntico.
La diferencia útil no está en la ventana de conversación. Está en quién controla el recorrido y si el sistema puede seleccionar y ejecutar acciones más allá de producir una respuesta.
Agente vs copiloto
“Copiloto” suele indicar que la persona conserva el mando: el sistema propone, redacta, resume o prepara una acción que alguien revisa. No es una especificación técnica universal. Un producto con esa etiqueta puede incluir decisiones agénticas, herramientas y automatizaciones.
El patrón resulta valioso cuando el juicio humano forma parte del trabajo y la asistencia reduce fricción sin delegar la decisión final.
Agente vs automatización basada en reglas
Una automatización basada en reglas sigue decisiones programadas: si ocurre A, ejecuta B; si falta C, envía D. Es más previsible y fácil de comprobar cuando las entradas y excepciones están bien definidas.
Un agente introduce decisión contextual en los puntos donde la ruta no puede enumerarse de forma razonable de antemano. Muchas arquitecturas útiles son híbridas: reglas para lo estable, modelo para lo variable y aprobación humana para lo consecuente. Incluir un agente no mejora por sí mismo un proceso que ya puede resolverse con reglas.
¿Y un SaaS?
SaaS describe principalmente una forma de ofrecer software como servicio. No especifica cómo decide ese software por dentro. Un producto SaaS puede incorporar chatbots, automatizaciones basadas en reglas, copilotos, agentes o una combinación de ellos.
Por tanto, “SaaS frente a agente” mezcla dos planos distintos: forma de entrega y arquitectura de decisión. La pregunta adecuada es si un producto existente resuelve el proceso y, dentro de él, qué mecanismos utiliza.
Las etiquetas orientan; las dimensiones permiten comparar el comportamiento real.
Autonomía, permisos y supervisión
La autonomía es un continuo
La autonomía no es una casilla activada o desactivada. Puede variar por acción y por situación dentro del mismo sistema. Un agente podría consultar datos automáticamente, preparar una actualización, pedir aprobación antes de enviarla y escalar cualquier excepción fuera de un umbral.
Como escala orientativa utilizada por esta guía —no como estándar universal—, el continuo contiene cinco niveles:
- Responde o recomienda. No modifica sistemas; aporta información para que una persona decida.
- Prepara una acción. Construye un borrador o una propuesta, pero no la ejecuta.
- Actúa tras aprobación. Pausa el proceso y muestra qué hará antes de continuar.
- Actúa dentro de umbrales y permisos. Ejecuta acciones acotadas y deriva lo que queda fuera.
- Opera por excepción en un alcance limitado. Completa tareas permitidas y solicita intervención ante señales definidas.
Ningún nivel es el destino obligatorio. La elección depende del impacto de la acción, su reversibilidad, el importe o consecuencia, los datos implicados, la confianza obtenida mediante pruebas, la herramienta y el contexto. Un mismo agente puede ocupar varios niveles a la vez según lo que intente hacer.
Más autonomía no significa mejor diseño.
Delegar más decisiones puede reducir intervenciones, pero también amplía las consecuencias de un error y dificulta la evaluación. Un diseño mejor concede únicamente la autonomía que aporta valor y que puede controlarse. La aprobación no representa un fracaso de la automatización: en algunas decisiones es parte correcta del sistema.
Capacidad técnica no equivale a autorización
Que una herramienta permita enviar un correo, modificar un registro o iniciar un pago no significa que el agente deba poder hacerlo. La capacidad responde “qué operación existe”; el permiso responde “quién puede ejecutarla, sobre qué recursos y en qué condiciones”.
Este principio exige separar lectura, escritura y comunicación externa; limitar credenciales y ámbitos; aplicar el mínimo privilegio; y registrar acciones relevantes. El trabajo inicial de NIST y NCCoE sobre identidad y autorización de agentes ayuda a formular estas preguntas, aunque no constituye un estándar final ni una certificación.
Patrones de supervisión
La supervisión puede adoptar formas distintas:
- Automático dentro de límites: el sistema actúa solo cuando la operación, los datos y el impacto están acotados.
- Aprobación previa: una persona acepta o rechaza una acción concreta antes de ejecutarla.
- Revisión por excepción: la ruta normal avanza y se escala una baja confianza, una incoherencia o una condición sensible.
- Escalado humano: el agente se detiene y transfiere objetivo, contexto, acciones realizadas y motivo del bloqueo.
Una aprobación útil requiere contexto, competencia, tiempo y autoridad. Pedir a una persona que pulse “aceptar” en cada paso sin explicar consecuencias crea una apariencia de control, no necesariamente control real. Los mecanismos de human-in-the-loop pueden pausar y reanudar ejecuciones, pero el criterio sobre qué debe aprobarse pertenece al diseño del proceso, no a la herramienta concreta.
Espectro de autonomía
Cinco niveles equivalentes describen formas distintas de delegación; no son una escalera de madurez.
Equivalente textual del diagrama
- Responde o recomienda: No modifica sistemas; aporta información para que una persona decida.
- Prepara una acción: Construye un borrador o una propuesta, pero no la ejecuta.
- Actúa tras aprobación: Pausa el proceso y muestra qué hará antes de continuar.
- Actúa dentro de umbrales y permisos: Ejecuta acciones acotadas y deriva lo que queda fuera.
- Opera por excepción en un alcance limitado: Completa tareas permitidas y solicita intervención ante señales definidas.
Primero se define qué puede hacer el sistema; después qué tiene permitido hacer y ante qué situación debe devolver el control.
Tres ejemplos empresariales
Ejemplos orientativos — no son casos de cliente
Los siguientes escenarios no describen implantaciones de Agentes Como Servicio ni resultados obtenidos. Sirven para mostrar cómo se relacionan entrada, contexto, decisión, herramienta, acción y excepción en un flujo comprensible.
A. Solicitud recibida por correo y contexto empresarial
Una persona escribe para solicitar información sobre un servicio y menciona datos incompletos.
- Entrada: correo o formulario recibido.
- Contexto: contenido del mensaje, identidad si está disponible, criterios de clasificación y datos del CRM a los que existe acceso autorizado.
- Decisión: clasificar el tipo de solicitud, comprobar si ya existe un registro y detectar qué información falta.
- Herramienta: consulta limitada al CRM y, cuando proceda, servicio de correo configurado en modo borrador.
- Acción: el modelo redacta una propuesta; el sistema registra la solicitud y guarda la respuesta como borrador. Enviarla exige que el permiso y las condiciones estén definidos.
- Excepción o supervisión: un duplicado dudoso, un dato sensible, baja confianza o un compromiso comercial pasa a una persona.
El componente agéntico no consiste en “responder correos”. Consiste en decidir qué información consultar, qué ruta corresponde y cuándo no debe completar el flujo.
Ejemplo A: Solicitud recibida por correo y contexto empresarial
El flujo conserva la misma gramática: entrada, contexto, decisión, herramienta, acción y excepción o supervisión.
Equivalente textual del diagrama
Entrada: Correo; Contexto: Contexto autorizado; Decisión: Clasificación y datos faltantes; Herramienta: CRM / borrador; Acción: Registro o respuesta; Excepción / supervisión: Excepción humana. Excepciones: Duplicado dudoso · dato sensible · baja confianza · compromiso comercial. Límite: Preparar ≠ enviar.
B. Consulta de conocimiento interno
Un miembro autorizado del equipo pregunta qué procedimiento se aplica a una situación concreta.
- Entrada: pregunta y contexto de la solicitud.
- Contexto: identidad, permisos, documentos internos vigentes y metadatos de versión.
- Decisión: localizar fuentes pertinentes y comprobar si existe evidencia suficiente y coherente.
- Herramienta: recuperación de información en repositorios permitidos.
- Acción: responder con referencias visibles o explicar qué información falta.
- Excepción o supervisión: fuentes contradictorias, documento restringido o decisión sensible se derivan al responsable.
El sistema no “conoce toda la empresa”. Responde desde una selección autorizada de fuentes y debe distinguir una ausencia de evidencia de una respuesta negativa.
Ejemplo B: Consulta de conocimiento interno
El flujo conserva la misma gramática: entrada, contexto, decisión, herramienta, acción y excepción o supervisión.
Equivalente textual del diagrama
Entrada: Pregunta e identidad; Contexto: Fuentes permitidas; Decisión: Evaluación de suficiencia; Herramienta: Recuperación; Acción: Respuesta con referencias o abstención; Excepción / supervisión: Responsable. Excepciones: Fuentes contradictorias · documento restringido · decisión sensible. Límite: Evidencia insuficiente → abstención.
C. Documento y proceso administrativo
Llega un formulario, factura u otro documento que debe alimentar un registro administrativo.
- Entrada: archivo recibido y datos de procedencia.
- Contexto: esquema esperado, reglas del proceso y registro relacionado.
- Decisión: extraer campos, identificar faltantes y elegir el siguiente paso permitido.
- Herramienta: lector de documentos y acceso acotado al sistema administrativo.
- Acción: crear un borrador de registro o actualizar un estado reversible.
- Excepción o supervisión: documento ilegible, inconsistencia, importe fuera de umbral o acción final sensible requiere revisión.
La extracción puede ser solo una pieza. Lo importante es qué ocurre después: validar, actualizar de forma reversible, detenerse ante una anomalía y conservar trazabilidad.
Ejemplo C: Documento y proceso administrativo
El flujo conserva la misma gramática: entrada, contexto, decisión, herramienta, acción y excepción o supervisión.
Equivalente textual del diagrama
Entrada: Documento; Contexto: Esquema y registro; Decisión: Extracción y decisión; Herramienta: Lector / sistema administrativo; Acción: Borrador o estado reversible; Excepción / supervisión: Revisión. Excepciones: Ilegibilidad · inconsistencia · importe fuera de umbral · acción sensible. Límite: Estado reversible antes de acción final.
¿Cuándo tiene sentido utilizar un agente?
Un agente resulta candidato cuando el proceso necesita adaptación entre casos y esa variabilidad no puede resolverse de forma razonable con una secuencia fija. No existe una checklist universal, pero estas condiciones ayudan a investigar el encaje.
Hay un objetivo y un resultado evaluable
Debe poder describirse qué entrada recibe el sistema, qué salida o efecto se espera y cómo se reconocerá un resultado aceptable. “Ayudar al equipo” no basta; “preparar una respuesta respaldada por documentos vigentes y escalar contradicciones” ofrece algo que probar.
Las entradas contienen variabilidad o información no estructurada
Correos, documentos y lenguaje natural pueden expresar la misma necesidad de formas distintas. Un modelo puede ser útil para interpretar esa variación, siempre que la tarea tenga límites y que los errores puedan detectarse o gestionarse.
El siguiente paso depende del contexto
El sistema necesita consultar estado, recuperar información o elegir entre herramientas según lo que observa. Si cada caso recorre exactamente la misma ruta, una automatización basada en reglas probablemente sea suficiente.
Existen datos, accesos y responsables
El agente solo puede operar sobre la información y los sistemas que se le exponen. Hace falta saber quién autoriza el acceso, quién mantiene las fuentes, quién asume las excepciones y quién puede detener o modificar el proceso.
El impacto justifica coste y complejidad
Cada decisión dinámica, llamada a modelo, integración, evaluación y control añade coste operativo. El valor esperado debe justificar esa arquitectura frente a una solución más simple. No basta con que el caso sea técnicamente posible.
El problema determina qué variabilidad importa; el criterio permite evaluarla y la arquitectura debe ser proporcional.
¿Cuándo no necesitas un agente?
Puede que no necesites un agente.
Decidir que no hace falta uno puede ser la conclusión técnicamente más sólida. Un agente introduce variabilidad donde el modelo elige entre opciones; esa flexibilidad solo tiene sentido si resuelve una dificultad real.
Las reglas son simples y estables
Si el proceso puede expresarse con condiciones conocidas y una ruta determinista, el código o una automatización basada en reglas ofrecen más previsibilidad, menor coste y pruebas más directas. Añadir un modelo puede crear nuevas formas de fallo sin aportar una decisión útil.
Un producto existente resuelve suficientemente el problema
Un SaaS estándar puede cubrir la necesidad con funciones mantenidas por el proveedor. Construir una arquitectura propia solo por usar agentes no aporta valor si el producto ya encaja en el proceso y sus límites son aceptables.
El problema todavía no está definido
Cuando cada persona describe un objetivo distinto, nadie conoce las excepciones o el resultado aceptable no puede medirse, el primer trabajo es comprender y ordenar el proceso. Un agente no corrige esa falta de definición; puede esconderla detrás de respuestas plausibles.
Faltan datos, accesos o responsables
Sin fuentes fiables, permisos viables y personas responsables de las excepciones, el sistema no dispone de una base operativa. La posibilidad técnica de conectar una herramienta no sustituye la autorización ni la gobernanza del dato.
El riesgo no puede acotarse
Si un error puede causar una consecuencia grave, difícil de revertir o imposible de detectar a tiempo, quizá la decisión deba permanecer en una persona o en controles deterministas. También puede rediseñarse el agente para limitarlo a preparar información, no a ejecutar la acción.
La complejidad cuesta más que el problema
Mantener contexto, herramientas, permisos, evaluaciones y monitorización tiene un coste. Para poco volumen o una tarea esporádica, un procedimiento claro, una función de software o trabajo asistido puede ser mejor decisión de negocio.
Elegir la solución más simple no es renunciar a capacidad; es comprobar qué resulta suficiente.
¿Qué puede salir mal y cómo se controla?
Un agente combina capacidades probabilísticas con acciones de software. Eso amplía lo que puede resolver y también crea puntos de fallo que deben diseñarse. El marco útil no termina en enumerar riesgos: relaciona capacidad → riesgo → control → riesgo residual.
| Capacidad | Riesgo | Control posible | Riesgo residual |
|---|---|---|---|
| Generar o interpretar lenguaje | Respuesta incorrecta o afirmación no fundada | Contexto trazable, salida estructurada, validación y revisión cuando proceda | El modelo todavía puede producir una respuesta plausible e incorrecta. |
| Recuperar contexto | Fuente incompleta, desactualizada o no autorizada | Permisos por fuente, metadatos de vigencia, filtros y referencias visibles | Una fuente permitida también puede estar equivocada o incompleta. |
| Elegir una herramienta | Selección incorrecta o parámetros erróneos | Herramientas acotadas, descripciones claras, esquemas, validación y pruebas | La selección o los parámetros todavía pueden fallar. |
| Ejecutar acciones | Permisos excesivos o acción inadecuada | Mínimo privilegio, credenciales limitadas, listas permitidas y aprobación | Una acción técnicamente permitida puede ser incorrecta en ese caso. |
| Modificar sistemas o comunicar | Consecuencia difícil de revertir | Vista previa o borrador, aprobación previa, límites, confirmación antes de ejecutar y mecanismos reversibles o transaccionales cuando existan | Algunas consecuencias externas no pueden revertirse por completo. |
| Repetir el ciclo | Bucle, latencia o consumo excesivo | Límites de pasos, tiempo y coste; criterio de parada | El sistema puede detenerse sin haber resuelto la tarea. |
| Usar una integración | Caída, timeout o respuesta inesperada | Reintentos acotados, validación de estado y escalado | La dependencia externa puede impedir completar el proceso. |
| Completar información | Inferencia sobre datos insuficientes | Pedir datos, abstenerse o devolver el control | La información aportada después también puede contener errores. |
| Depender de proveedores | Cambio, indisponibilidad o degradación externa | Monitorización, tiempos de espera, reintentos acotados, rutas alternativas o funcionamiento degradado cuando sea viable | No todos los fallos de un tercero pueden absorberse. |
Los guardrails o controles pueden validar entradas, salidas y llamadas a herramientas, pero cada uno protege puntos concretos; no forman una barrera universal. La documentación de guardrails de OpenAI distingue, por ejemplo, ámbitos diferentes dentro de la ejecución. Que exista un control no demuestra seguridad absoluta ni cumplimiento legal.
Evaluación antes y después del despliegue
Probar un agente exige observar el resultado final y el recorrido seguido. Dos ejecuciones con la misma intención pueden tomar rutas distintas. Las evaluaciones deberían incluir casos normales, límites, excepciones y entradas adversas; comprobar uso de herramientas, cumplimiento de criterios y calidad del estado final; y combinar revisiones automáticas con juicio humano cuando el dominio lo requiera.
La guía de Anthropic sobre evaluaciones de agentes propone separar tareas, intentos, criterios de evaluación y trazas. Es un enfoque útil, no una métrica universal: cada proceso necesita definir qué considera correcto y qué errores son inaceptables.
Trazas, observabilidad y monitorización
Una traza registra los pasos de una ejecución: llamadas al modelo, herramientas, resultados, controles y transferencias. La observabilidad permite investigar patrones mediante trazas, registros y métricas. Ayuda a detectar errores, latencia, consumo o cambios de comportamiento, pero ver el sistema no equivale a garantizar su calidad.
Además, el registro puede contener información sensible. Debe diseñarse con acceso, minimización y conservación apropiados. Las trazas sirven para comprender y mejorar una ejecución; no sustituyen la evaluación ni la responsabilidad sobre sus efectos.
Capacidad, riesgo, control y riesgo residual
Cinco capacidades representativas muestran que un control reduce una exposición, pero no la hace desaparecer.
Equivalente textual del diagrama
La tabla anterior contiene nueve filas y cuatro columnas: capacidad, riesgo, control posible y riesgo residual. Esta figura resume las filas de lenguaje, contexto, herramienta, modificación de sistemas y repetición del ciclo.
Cada capacidad abre una superficie de riesgo; el control la reduce y deja un riesgo residual que todavía debe gestionarse.
Agente único, workflow agéntico y sistema multiagente
Agente único
Un solo agente puede disponer de varias herramientas y resolver un recorrido completo. Reduce transferencias, estado compartido y puntos de coordinación. Suele ser el punto de partida razonable cuando una única orquestación puede mantener instrucciones y selección de herramientas comprensibles.
“Único” no significa simple ni sin controles. Puede incluir pasos deterministas, aprobaciones, recuperación de información y distintas rutas de excepción.
Workflow con componentes agénticos
Un workflow organiza pasos y dependencias. Puede ser enteramente determinista o incluir puntos donde un modelo clasifica, elige una ruta, utiliza una herramienta o evalúa un resultado. Algunas fuentes reservan “agente” para el control dinámico y llaman workflow a las rutas predefinidas; otras utilizan “workflow agéntico” para cualquier combinación de ambos.
La etiqueta es menos importante que documentar qué pasos están fijados y cuáles dependen de una decisión probabilística.
Sistema multiagente
Un sistema multiagente reparte responsabilidades entre varios agentes y define cómo se coordinan: de forma secuencial, paralela, jerárquica o mediante transferencias. Puede ayudar cuando existen dominios claramente separables o trabajo paralelo real.
También añade más llamadas, latencia, estados, mensajes, permisos y posibles fallos de coordinación. Hay que evaluar no solo cada agente, sino sus interacciones y el resultado conjunto. Tanto Anthropic como la orientación de Microsoft sobre patrones de orquestación de agentes recomiendan justificar la complejidad en lugar de asumir que más componentes producen un mejor sistema.
La regla práctica es empezar con la arquitectura más sencilla que cumpla los criterios. Se añaden agentes cuando una necesidad observable —separación de contexto, responsabilidad especializada o paralelismo— compensa el coste de coordinarlos.
Antes de especializar conviene saber por qué; después hay que coordinar y observar el conjunto.
¿Qué tecnologías suelen intervenir?
Una arquitectura se entiende mejor por responsabilidades que por marcas. No todas las capas aparecen en todos los sistemas, y una misma tecnología puede asumir varias.
Modelos e interfaces de inferencia
El modelo interpreta texto, imágenes u otros datos y produce respuestas o decisiones estructuradas. La interfaz de inferencia permite enviar contexto y recibir una salida. La elección depende de la tarea, la calidad necesaria, el tiempo de respuesta, el coste y las condiciones de uso.
APIs, herramientas y tool calling
Una API expone datos u operaciones de otro sistema. El tool calling permite que el modelo solicite una función con parámetros estructurados; la orquestación valida y ejecuta esa solicitud. El modelo no obtiene credenciales por describir una herramienta: autenticación y permisos se aplican fuera de él.
Bases de datos, recuperación y RAG
Las bases de datos conservan información estructurada o documental. La generación aumentada por recuperación, conocida como RAG, localiza fragmentos pertinentes y los incorpora al contexto antes de una inferencia, una decisión o una respuesta. Recuperar información mejora el apoyo disponible, pero no garantiza que la fuente sea correcta ni que el modelo la interprete bien.
Estado y memoria
El estado permite reanudar una ejecución y conocer qué ocurrió. La memoria puede conservar historial o recuperar hechos entre sesiones. Debe definirse qué se guarda, durante cuánto tiempo, para quién y con qué propósito. No es sinónimo de aprendizaje del modelo.
Autenticación, identidad y permisos
Estas capas determinan quién inicia la operación, a qué recursos puede acceder el sistema y qué acciones están autorizadas. Las credenciales deberían estar acotadas y gestionarse fuera del texto que recibe el modelo.
Orquestación y ejecución
La orquestación administra el bucle, el estado, las herramientas, los reintentos, las aprobaciones y los criterios de parada. Puede combinar decisiones del modelo con reglas programadas. La infraestructura ejecuta esas piezas y conecta servicios internos o externos.
Evaluaciones y observabilidad
Las evaluaciones contrastan comportamiento y resultado con criterios. La observabilidad recoge señales para entender ejecuciones reales: trazas, errores, latencia y uso. Juntas permiten detectar problemas y orientar cambios, pero ninguna convierte el sistema en infalible.
La función define la responsabilidad; el componente se elige después. Una lista de marcas no sustituye esa arquitectura.
Cómo se diseña para un proceso empresarial
Llevar un agente a una empresa empieza por el proceso, no por el modelo. El objetivo es convertir una necesidad en un sistema que pueda delimitarse, probarse y operarse.
1. Definir el problema y el resultado
Hay que describir situación actual, personas implicadas, entrada, salida esperada y valor del cambio. También qué queda fuera. Si el resultado no puede reconocerse, tampoco puede evaluarse con responsabilidad.
2. Mapear datos y herramientas
Se identifican fuentes, propietarios, vigencia, calidad y permisos. Después se determinan las operaciones que el sistema necesitaría: consultar, crear un borrador, actualizar o comunicar. Una integración se considera viable solo cuando existen acceso y condiciones técnicas suficientes.
3. Delimitar decisiones y excepciones
Conviene separar lo determinista de lo variable. Para cada decisión dinámica se define qué contexto necesita el modelo, qué alternativas puede elegir y qué situaciones exigen abstención, aprobación o escalado.
4. Fijar permisos y supervisión
Cada herramienta recibe el alcance mínimo necesario. Las acciones se clasifican por impacto y reversibilidad para elegir ejecución automática, aprobación previa o revisión por excepción. También se asignan responsables capaces de intervenir.
5. Convertir el resultado en criterios de aceptación
Los criterios incluyen calidad de salida, uso correcto de fuentes y herramientas, respeto a límites, tratamiento de excepciones y comportamiento ante fallos. Las pruebas deben cubrir escenarios habituales, límites y casos adversos.
6. Desplegar por alcance y observar
Un alcance acotado facilita comparar comportamiento con criterios, detectar fallos y decidir si aumentar permisos o cobertura. La operación necesita registros, revisión y mantenimiento proporcionales al proceso. Ampliar autonomía debe ser una decisión respaldada por evidencia, no el valor predeterminado.
Primero se define el proceso, después se prueba el comportamiento y solo entonces se decide qué delegar.
Glosario
- Agente de IA
- sistema orientado a un objetivo en el que un modelo participa en la elección de pasos y puede utilizar herramientas dentro de reglas, permisos y controles.
- IA agéntica (agentic AI)
- término paraguas para sistemas o comportamientos que combinan interpretación, decisión y acción orientadas a un objetivo.
- LLM o modelo de lenguaje grande
- modelo entrenado para trabajar con lenguaje y producir salidas a partir del contexto recibido. Puede ser un componente del agente, no el sistema completo.
- Contexto
- información disponible para resolver el paso actual: instrucciones, entrada, historial pertinente, datos recuperados y resultados de herramientas.
- Estado
- registro de la situación de una ejecución: pasos realizados, datos obtenidos y decisiones pendientes.
- Memoria
- mecanismo para conservar o recuperar información entre pasos o sesiones. No implica reentrenamiento ni aprendizaje automático.
- Herramienta
- capacidad externa que permite consultar información, calcular o ejecutar una acción.
- Tool calling
- mecanismo por el que un modelo solicita el uso de una herramienta y proporciona parámetros estructurados para que la orquestación los valide y ejecute.
- API
- interfaz mediante la que un sistema expone datos u operaciones a otro software.
- RAG
- recuperación de información pertinente para incorporarla al contexto antes de una inferencia, una decisión o una respuesta.
- Workflow
- secuencia y dependencias que organizan un proceso; puede ser fija, dinámica o híbrida.
- Orquestación
- capa que coordina modelo, contexto, estado, herramientas, reglas, controles y salidas.
- Guardrail o control
- validación o restricción aplicada en un punto concreto para prevenir, detectar o detener un comportamiento no deseado.
- Human-in-the-loop
- patrón en el que una persona interviene dentro del flujo para aprobar, corregir o resolver una excepción.
- Sistema multiagente
- arquitectura que coordina varios agentes con responsabilidades delimitadas.
- Evaluación
- comprobación del resultado y, cuando importa, del recorrido de una ejecución frente a criterios definidos.
- Traza
- registro estructurado de los pasos, llamadas y resultados de una ejecución.
- Observabilidad
- capacidad de comprender el comportamiento del sistema mediante trazas, registros, métricas y otras señales.
Preguntas frecuentes
¿Qué es un agente de IA en una frase?
Es un sistema que utiliza un modelo, instrucciones y contexto para decidir cómo avanzar hacia un objetivo y, cuando procede, usar herramientas dentro de límites definidos.
¿Un agente de IA es un chatbot?
No necesariamente. Chatbot describe una interfaz conversacional; un agente describe un comportamiento orientado a objetivos y acciones. Un chatbot puede incorporar capacidades agénticas, y un agente puede funcionar sin una interfaz de chat.
¿Un agente necesita memoria?
No. Necesita el contexto suficiente para la tarea, pero la memoria persistente es opcional. Se utiliza cuando conservar o recuperar información entre sesiones aporta valor y existe una base legítima para hacerlo.
¿Un agente aprende mientras trabaja?
No de forma implícita. Puede actualizar el estado, conservar memoria o recibir feedback sin que cambien los parámetros del modelo. Hablar de aprendizaje exige explicar qué mecanismo se modifica y cómo se valida.
¿Puede utilizar APIs?
Sí. Una API puede exponer datos o acciones como herramientas. La orquestación debe aplicar autenticación, permisos, validación y tratamiento de errores; que una API exista no autoriza cualquier uso.
¿Puede actuar sin supervisión humana?
Puede ejecutar ciertas acciones sin aprobación previa si el alcance, los permisos y el riesgo lo permiten. Otras pueden requerir aprobación o escalado. La supervisión se diseña por acción y contexto, no como un sí o no para todo el agente.
¿Puede equivocarse?
Sí. Puede interpretar mal, usar contexto incorrecto, elegir una herramienta inadecuada o fallar por una integración externa. Validaciones, permisos, evaluaciones y supervisión reducen el riesgo, pero no garantizan ausencia de errores.
¿Qué diferencia hay entre un agente y una automatización basada en reglas?
La automatización sigue decisiones programadas de antemano. En un agente, el modelo puede elegir dinámicamente entre pasos o herramientas según el contexto. Una solución híbrida puede usar reglas para lo estable y decisiones del modelo para lo variable.
¿Qué diferencia hay entre IA generativa e IA agéntica?
La IA generativa produce contenido a partir de una entrada. La IA agéntica organiza capacidades de interpretación, decisión y acción alrededor de un objetivo. Un sistema agéntico puede utilizar un modelo generativo como componente.
¿Todos los agentes son autónomos?
Tienen algún margen de decisión dentro del sistema, pero ese margen puede ser muy acotado. No todos mantienen memoria, planifican varios pasos ni ejecutan acciones sin aprobación.
¿Cómo sabe un agente que ha terminado?
Mediante criterios de finalización definidos en el flujo: resultado obtenido, validación superada, límite alcanzado o ausencia de una acción válida. También puede detenerse o escalar si no puede completar la tarea con seguridad.
¿Cuándo no merece la pena utilizar uno?
Cuando reglas simples resuelven el proceso, un producto existente es suficiente, el problema aún no está definido, faltan datos o responsables, el riesgo no puede acotarse o la complejidad supera el valor esperado.
¿Cuándo hace falta un sistema multiagente?
Solo cuando repartir responsabilidades o ejecutar trabajo en paralelo aporta una ventaja comprobable frente a un agente único. Varios agentes añaden coordinación, latencia, estado y nuevos puntos de fallo.
¿Cómo se evalúa antes y después del despliegue?
Con escenarios representativos y adversos, criterios sobre resultado y recorrido, revisión del uso de herramientas y excepciones, trazas y observación del comportamiento real. Las pruebas deben adaptarse al proceso y revisarse cuando cambian sus condiciones.
Fuentes y lecturas recomendadas
Estas fuentes primarias respaldan los conceptos utilizados en la guía. Sus definiciones y recomendaciones pertenecen a contextos distintos; ninguna acredita por sí sola una arquitectura concreta ni elimina la necesidad de evaluar cada caso.
- 01A practical guide to building agents — OpenAI (enlace externo)openai.com
definición operativa, componentes y criterio de agente único frente a varios.
- 02Building effective agents — Anthropic (enlace externo)anthropic.com
distinción entre workflows predefinidos y control dinámico del proceso.
- 03Inteligencia artificial agéntica desde la perspectiva de protección de datos — AEPD (enlace externo)aepd.es
autonomía como grado, variación terminológica, actores y riesgos sobre datos.
- 04ReAct: Synergizing Reasoning and Acting in Language Models — Google Research y Princeton (enlace externo)arxiv.org
patrón de alternar razonamiento, acción y observación.
- 05Effective context engineering for AI agents — Anthropic (enlace externo)anthropic.com
selección y organización de contexto limitado.
- 06Human-in-the-loop — OpenAI Agents SDK (enlace externo)openai.github.io
patrón técnico para pausar, aprobar o rechazar acciones y reanudar estado.
- 07Guardrails — OpenAI Agents SDK (enlace externo)openai.github.io
validaciones de entrada, salida y herramientas, junto con sus límites de alcance.
- 08Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization — NIST/NCCoE (enlace externo)csrc.nist.gov
identidad, autorización y auditoría; documento inicial, no estándar final.
- 09Demystifying evals for AI agents — Anthropic (enlace externo)anthropic.com
evaluación de tareas, intentos, criterios, trazas y estado final.
- 10AI Agent Orchestration Patterns — Microsoft (enlace externo)learn.microsoft.com
criterios de complejidad y coordinación al elegir una arquitectura.
Sobre el autor
Elvis Mendoza, fundador de Agentes Como Servicio. Trabaja en el diseño de producto, la arquitectura de soluciones, el diseño de agentes y flujos de trabajo y la construcción de software asistida por IA para conectar procesos, datos, herramientas y supervisión humana alrededor de necesidades empresariales concretas.
¿Hay un proceso de tu empresa que podría funcionar así?
Si ya puedes describir el objetivo, las decisiones, las herramientas y las excepciones, el siguiente paso es comprobar si un sistema personalizado tiene encaje en la operación real.
Solicitar acceso