Agente de IA
Un agente de IA es un sistema basado en inteligencia artificial capaz de ejecutar tareas con cierto grado de autonomía a partir de instrucciones, contexto, herramientas y mecanismos de control. En equipos ágiles con IA, un agente no sustituye la responsabilidad humana: actúa como colaborador operativo bajo supervisión, límites y criterios de verificación definidos por el equipo.
Un agente de IA no es simplemente un modelo de lenguaje ni un chatbot más sofisticado. La diferencia está en su capacidad de actuar dentro de un entorno: leer información, usar herramientas, consultar fuentes, modificar artefactos, ejecutar pasos, mantener estado de una tarea y producir resultados verificables.
Una forma útil de entenderlo es:
El modelo aporta la capacidad de razonar sobre lenguaje, generar respuestas, reconocer patrones y proponer acciones. El arnés aporta el entorno operativo: instrucciones, contexto, herramientas, permisos, memoria, sensores de verificación, límites y reglas de supervisión.
Sin arnés, el modelo responde. Con arnés, el agente puede trabajar.
Qué distingue a un agente de IA
El término “agente de IA” se usa de forma amplia y, a veces, confusa. No existe una única definición universal asentada para todos los contextos, pero en el trabajo profesional suele implicar varios elementos.
| Elemento | Función |
|---|---|
| Modelo | Interpreta instrucciones, razona sobre el contexto y genera respuestas o acciones. |
| Instrucciones | Definen el objetivo, el rol operativo, los límites y la forma esperada de trabajar. |
| Contexto | Proporciona información relevante: documentación, specs, historial, arquitectura, datos o criterios de decisión. |
| Herramientas | Permiten actuar sobre el entorno: buscar, leer archivos, ejecutar código, llamar APIs, crear documentos o modificar sistemas. |
| Memoria o estado | Ayuda a mantener continuidad entre pasos, sesiones o tareas. |
| Sensores de verificación | Comprueban si el resultado cumple criterios: tests, linters, revisiones, fact-checking, validaciones o revisión humana. |
| Gobernanza | Establece permisos, límites, trazabilidad, políticas de uso y responsabilidad. |
Un agente de IA no necesita tener todos estos elementos al máximo nivel para ser considerado agente. Pero cuanto más actúa sobre tareas reales, más necesarios son los controles.
Diferencia entre modelo, chatbot, asistente y agente
Conviene distinguir términos que suelen mezclarse.
| Concepto | Qué es | Ejemplo de uso |
|---|---|---|
| Modelo de IA | Sistema entrenado para procesar y generar información. | Un LLM que responde a una pregunta. |
| Chatbot | Interfaz conversacional que permite interactuar con un modelo o sistema. | Un chat que responde dudas frecuentes. |
| Asistente de IA | Herramienta que ayuda a una persona a realizar tareas, normalmente bajo instrucciones directas. | Ayudar a redactar un correo, resumir un documento o explicar código. |
| Agente de IA | Sistema que puede perseguir un objetivo mediante varios pasos, usando contexto, herramientas y controles. | Leer una spec, modificar código, ejecutar tests, corregir errores y preparar un resumen de revisión. |
La frontera no siempre es limpia. Un asistente puede comportarse como agente si dispone de herramientas, instrucciones persistentes, memoria de tarea y capacidad de ejecutar acciones encadenadas. Por eso es mejor observar el sistema de trabajo que quedarse solo con la etiqueta comercial.
Grados de autonomía
No todos los agentes tienen el mismo nivel de autonomía. En equipos profesionales conviene hablar de grados, no de una autonomía absoluta.
| Nivel | Descripción | Riesgo principal |
|---|---|---|
| Asistencia puntual | El agente responde a instrucciones concretas y espera nuevas indicaciones para cada paso. | Baja productividad si todo requiere microgestión. |
| Ejecución guiada | El agente sigue una spec, una lista de tareas o un flujo definido por el equipo. | Mala ejecución si el contexto o los criterios son ambiguos. |
| Autonomía supervisada | El agente decide algunos pasos intermedios, usa herramientas y reporta resultados para revisión humana. | Aceptar resultados sin revisar evidencia. |
| Autonomía extendida | El agente trabaja durante más tiempo, coordina subtareas o interactúa con varios sistemas. | Pérdida de control, errores acumulados o acciones no deseadas. |
En contextos ágiles, el nivel más útil suele ser la autonomía supervisada: suficiente para descargar trabajo operativo, pero con límites claros y revisión humana.
Qué puede hacer un agente de IA en un equipo ágil
Un agente de IA puede apoyar muchas actividades del trabajo ágil, siempre que el equipo defina bien el alcance y los controles.
Puede ayudar en:
- análisis de información de discovery;
- síntesis de entrevistas o feedback de usuarios;
- refinamiento de historias de usuario;
- generación de criterios de aceptación;
- escritura o revisión de specs;
- creación de prototipos mediante vibe coding;
- implementación guiada por Spec-Driven Development;
- generación inicial de tests;
- revisión de código con foco en riesgos;
- documentación técnica;
- preparación de materiales para una sprint review;
- análisis de patrones en retrospectivas;
- detección de inconsistencias, duplicados o riesgos.
Pero estas tareas no tienen el mismo nivel de riesgo. No es lo mismo pedir a un agente que resuma notas que permitirle modificar código de producción, tocar permisos, procesar datos sensibles o ejecutar acciones sobre clientes reales.
Agente de IA en Scrum con IA
En Scrum con IA, el agente no se convierte en un nuevo rol Scrum. No es product owner, no es scrum master y no es developer en sentido responsable. Es un participante operativo del sistema de trabajo.
La responsabilidad sigue siendo humana:
- El product owner o product architect decide qué merece ser construido y qué hipótesis conviene validar.
- Los product builders definen specs, revisan outputs, integran resultados y responden por la calidad técnica.
- El scrum master o agile enabler facilita el sistema humano-IA: flujos, límites, gobernanza, confianza y mejora continua.
El agente puede ejecutar parte del trabajo, pero no asume accountability. Si un incremento falla en producción, la responsabilidad no puede delegarse en “la IA lo hizo”.
Relación con la Definition of Ready para IA
Antes de asignar trabajo a un agente, el equipo debe comprobar que el ítem está preparado. Esta idea puede entenderse como una Definition of Ready específica para IA.
Un ítem está listo para un agente cuando:
- la spec está completa y revisada;
- el agente tiene acceso al contexto necesario;
- los criterios de aceptación son verificables;
- se han definido restricciones técnicas y de seguridad;
- los prompts o instrucciones son suficientemente precisos;
- se ha reservado tiempo para revisión humana;
- está claro quién revisará y asumirá el resultado.
Sin este onboarding, el agente puede producir outputs rápidos pero irrelevantes, incompletos o peligrosos.
Relación con la Definition of Done reforzada
El trabajo de un agente no está terminado cuando el agente declara que ha terminado.
En un equipo con IA, la Definition of Done debe reforzarse con controles específicos:
- revisión humana del output;
- pruebas automatizadas cuando aplique;
- análisis estático o de calidad;
- revisión de seguridad;
- verificación contra la spec;
- comprobación de duplicaciones o dependencias problemáticas;
- trazabilidad de decisiones relevantes;
- aceptación explícita por parte de una persona responsable.
El agente puede producir el output. El equipo valida si ese output puede formar parte del incremento.
Tipos frecuentes de agentes
Los agentes pueden clasificarse según la función que desempeñan.
| Tipo de agente | Función habitual | Ejemplo |
|---|---|---|
| Agente de investigación | Busca, organiza y sintetiza información. | Preparar un resumen de evidencias para discovery. |
| Agente de producto | Ayuda a estructurar hipótesis, criterios, historias o specs. | Convertir una hipótesis en criterios de aceptación verificables. |
| Agente de código | Implementa, modifica o revisa software. | Ejecutar una tarea definida en una spec y pasar tests. |
| Agente revisor | Evalúa outputs de otro agente o de una persona. | Revisar riesgos, inconsistencias o vulnerabilidades. |
| Agente de QA | Genera o ejecuta pruebas y analiza fallos. | Proponer casos límite para una funcionalidad. |
| Agente de documentación | Produce o actualiza documentación a partir de cambios. | Actualizar una guía técnica tras una modificación. |
La clasificación no es rígida. Un mismo agente puede cumplir varias funciones si el arnés lo permite, pero para trabajos críticos suele ser mejor acotar la misión.
Un agente no debe corregir sus propios deberes
Una regla práctica importante: no conviene confiar en que el mismo agente que generó un output sea el único responsable de verificarlo.
Si un agente escribe código y después se le pide que lo revise, tenderá a validar sus propias decisiones o a pasar por alto supuestos que ya arrastraba. Esto no significa que la auto-revisión no sirva para nada, pero no debe ser el único control.
Para tareas importantes, conviene combinar:
- sensores computacionales: tests, linters, análisis estático, validadores;
- revisión humana;
- agentes revisores con instrucciones distintas;
- ejemplos verificables;
- criterios de aceptación externos al agente que implementa.
La verificación debe estar fuera del optimismo del generador.
Relación con prompt engineering y context engineering
El prompt engineering ayuda a comunicarse mejor con un agente: formular instrucciones, delimitar tareas, pedir formatos, establecer criterios y evitar ambigüedad.
El context engineering se ocupa de qué información ve el agente en cada momento: documentos, ejemplos, historial, restricciones, fuentes, herramientas o estado de la tarea.
Ambos son importantes, pero no bastan por sí solos. Un agente fiable necesita además herramientas adecuadas, permisos limitados, sensores, revisión y gobernanza.
Un buen prompt puede mejorar una respuesta. Un buen arnés mejora el sistema de trabajo.
Riesgos principales
Los agentes de IA introducen riesgos específicos porque no solo responden: pueden actuar.
Alucinación operativa
El agente puede inventar datos, fuentes, APIs, dependencias, rutas, decisiones previas o resultados de pruebas. Cuanto más convincente sea la respuesta, más peligroso puede ser el error.
Prompt injection
Si el agente procesa contenido externo, ese contenido puede incluir instrucciones maliciosas o engañosas. Por ejemplo, una página web, un issue, un correo o un documento podrían intentar modificar el comportamiento del agente.
Acciones no deseadas
Un agente con demasiados permisos puede borrar, modificar, enviar, publicar o ejecutar acciones sin suficiente control.
Pérdida de trazabilidad
Si no se registran decisiones, fuentes, prompts, outputs y revisiones, el equipo no podrá reconstruir por qué se hizo algo.
Dependencia excesiva
El equipo puede perder criterio si acepta outputs por defecto, delega decisiones sustantivas o deja de entender el trabajo generado.
Agent washing
Algunas herramientas se presentan como “agentes” aunque solo sean automatizaciones simples o chatbots con una capa comercial. La etiqueta no garantiza autonomía útil ni calidad.
Buenas prácticas
Para integrar agentes de IA con rigor, conviene aplicar estas prácticas:
- Empezar con tareas acotadas. Cuanto más crítico sea el trabajo, menor autonomía inicial.
- Definir permisos mínimos. El agente solo debe acceder a lo necesario.
- Separar generación y revisión. Quien produce no debe ser el único que verifica.
- Usar specs y criterios verificables. La ambigüedad aumenta el coste de revisión.
- Mantener trazabilidad. Registrar decisiones, fuentes, acciones y outputs relevantes.
- Proteger datos sensibles. No exponer secretos, credenciales o información confidencial sin garantías.
- Diseñar sensores. Tests, checklists, validadores, revisores y controles antes de producción.
- Revisar el coste real. Medir no solo generación, sino revisión, retrabajo, errores y valor entregado.
- Mantener responsabilidad humana. El agente ejecuta; el equipo responde.
Cuándo no usar un agente
No todo trabajo mejora por convertirlo en una tarea agéntica.
Puede ser mejor no usar un agente cuando:
- la tarea es simple y una automatización determinista la resuelve mejor;
- el coste de revisar el output supera el beneficio;
- no hay criterios claros para saber si el resultado es correcto;
- el agente necesitaría acceso a datos sensibles sin controles adecuados;
- una acción incorrecta tendría consecuencias graves;
- el equipo no tiene capacidad de supervisión;
- la tarea requiere una decisión ética, legal o estratégica que debe tomar una persona.
Una regla sencilla: si no puedes revisar el resultado, no deberías delegarlo.
Error frecuente
Tratar al agente de IA como si fuera un miembro responsable del equipo. Un agente puede colaborar, ejecutar tareas y producir outputs valiosos, pero no asume responsabilidad profesional. La accountability sigue siendo humana. Si el equipo no define límites, contexto, verificación y responsables, el agente se convierte en una fuente de velocidad aparente y riesgo real.
Recursos
🏦 Harness EngineeringSkill Arena · Scrum Manager
🏦 SDD - Spec Driven Development en equipos ágilesSkill Arena · Scrum Manager
📊 Guía didáctica SDDRecursos · Scrum Manager
Referencias
- Anthropic. (2024). “Building Effective AI Agents”, Anthropic.
- Anthropic. (2025). “Writing effective tools for AI agents”, Anthropic.
- IBM. (2025). “What Are AI Agents?”, IBM Think.
- NIST. (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). National Institute of Standards and Technology.
- OpenAI. (2025). “Agents SDK”, OpenAI API Documentation.
Véase también
¿Quieres avanzar en agilidad? Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a Skill Arena: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.