Qué debe aprender un equipo para trabajar con agentes de IA

Para una empresa, un agente de IA es un sistema que recibe un objetivo y puede dividirlo en pasos, consultar información, usar herramientas, ejecutar acciones y comprobar lo que obtiene hasta terminar. La guía Building effective agents de Anthropic (2024) lo distingue de un workflow: en este los pasos están fijados en el código; en un agente, el modelo dirige su propio proceso y decide qué herramientas usar.

Un ejemplo lo aclara. Un asistente puede redactar un correo de seguimiento a un cliente potencial. Un agente comercial podría revisar la lista de leads de la semana, consultar la información disponible de cada empresa, priorizarlos con los criterios acordados, preparar borradores personalizados, registrar la actividad en el CRM y dejar el envío pendiente de que un comercial lo apruebe.

Lo que un agente puede hacer depende de las herramientas, los permisos y la arquitectura en la que se integra. Sin acceso a herramientas externas, su capacidad para actuar directamente sobre sistemas y datos reales es mucho más limitada; conectado a los sistemas de la empresa, como el correo o el ERP, puede actuar sobre ellos. En OSWorld, un benchmark que evalúa agentes realizando tareas en entornos de ordenador, los mejores sistemas han pasado de alrededor de un 12 % a cerca de un 66 % de éxito, según el AI Index 2026 de Stanford. Es un salto importante, pero también recuerda que la autonomía completa sigue lejos de ser fiable en cualquier contexto.

Las cuatro formas de trabajar con IA no se sustituyen, se acumulan, y la supervisión no llega después de la delegación: es lo que la hace viable.

Trabajar con un agente se parece menos a hacer una pregunta y más a encargar un trabajo a alguien capaz que no conoce la empresa. Un encargo mal definido produce un resultado inútil por competente que sea quien lo recibe, y un agente, además, no pregunta cuando algo no está claro salvo que se haya diseñado para hacerlo.

De ahí el paso de prompt engineering a task delegation. El prompting no desaparece: pasa a formar parte de una competencia más amplia, la de definir bien un encargo.

Un caso de administración lo muestra bien. «Revisa las facturas de proveedores de este mes» es una petición. Un encargo delegable sería: concilia las facturas de proveedores de agosto con los pedidos del ERP, marca las que difieran más de un 2 % o no tengan pedido asociado, no modifiques ningún registro y devuelve una tabla con factura, importe, discrepancia y acción propuesta. Lo que cambia no es el agente, sino la calidad del encargo y, con ella, la posibilidad de revisar el resultado.

Un objetivo verificable. «Toma estos datos y analízalos» deja al sistema decidir qué significa analizar. «Analiza las ventas del trimestre buscando caídas superiores al 10 % por zona, compáralas con el mismo trimestre del año anterior y devuelve una tabla con zona, variación y posible causa» define qué buscar, con qué comparar y qué forma debe tener el resultado. Sin esa precisión, ni el agente sabe cuándo ha terminado ni quien lo supervisa puede comprobarlo.

El contexto necesario, y solo ese. El agente necesita la documentación, los procedimientos y las políticas que usaría una persona del equipo, pero no datos personales que la tarea no requiere, información confidencial de terceros ni credenciales. Actúa con los permisos que se le dan, no con los que la tarea necesita, y ambos deberían coincidir.

Un agente no debería recibir acceso ilimitado a nada. La competencia práctica consiste en graduar su autonomía según el impacto de cada acción: cuanto más costoso o difícil de revertir es un error, menos puede hacer sin intervención humana, y algunas acciones deben seguir el mismo circuito que se aplica a las personas, como una pull request revisada antes de llegar a producción.

La autonomía no se concede al agente de forma global. Se concede por tipo de acción y según su impacto. El mismo sistema puede clasificar tickets por su cuenta y, a la vez, necesitar aprobación para enviar un correo a un cliente.

Supervisar lo que ha hecho, no cómo «piensa». No hace falta entender el funcionamiento interno del modelo, sino comprobar qué acciones ejecutó el agente, qué información usó y si el resultado cumple los criterios del encargo. Es la idea de human-in-the-loop: que una persona intervenga donde su criterio es imprescindible, con puntos de control en los que el agente se detiene a pedir confirmación y condiciones de parada, como recomienda la guía de Anthropic.

Validar los resultados. Un agente entrega resultados con aspecto de trabajo terminado, y una respuesta convincente no es necesariamente correcta. Validar es contrastar las fuentes que dice haber usado, rehacer por muestreo los cálculos relevantes, revisar las excepciones y comparar el resultado con criterios de aceptación fijados de antemano. Cuando el agente se usa a diario, esa revisión debe complementarse con evaluaciones sistemáticas.

Gestionar las excepciones. Un pedido sin proveedor, un cliente con dos fichas, dos políticas que se contradicen: los agentes encuentran situaciones que el encargo no preveía. Un equipo formado sabe reconocerlas y redacta los encargos para que el agente se detenga y avise, en lugar de improvisar.

La autonomía tiene un coste. Para completar una sola tarea, un agente puede hacer decenas de llamadas al modelo y a herramientas, cada una con su consumo de tokens, y Anthropic advierte de que los sistemas agénticos suelen intercambiar latencia y coste por un mejor rendimiento, con el riesgo de que los errores se acumulen. Un responsable no necesita dominar la facturación de una API, pero sí entender que el número de pasos, las llamadas a herramientas y la elección del modelo determinan el coste por tarea, como detallamos en cuánto cuesta de verdad la IA en producción.

Formar a toda la plantilla en arquitecturas agénticas es tan poco útil como limitar a los desarrolladores a un curso de prompting. Cada perfil debería llegar hasta donde su trabajo lo requiere, y muchas organizaciones no necesitarán llevar nunca a su personal al cuarto nivel.

Empieza a repetirse una paradoja: se despliegan agentes técnicamente avanzados mientras quienes deben supervisarlos todavía no han aprendido a hacerlo. En la demostración funcionan; conectados al correo, al CRM o al ERP, nadie tiene claro qué revisar ni cuándo detenerlos.

Los riesgos son concretos: acciones incorrectas a escala, datos usados fuera del contexto autorizado, automatizaciones imposibles de auditar, costes sin medir y una dependencia que acaba ocultando los errores. Gartner predijo en junio de 2025 que más del 40 % de los proyectos de IA agéntica se cancelarán antes de finales de 2027, por costes crecientes, valor de negocio poco claro o controles de riesgo insuficientes. Ninguna de esas causas es un problema del modelo: tienen que ver con cómo se define, se controla y se mide su uso.

Todavía se está a tiempo de hacerlo en el orden correcto: según el mismo AI Index 2026, el despliegue de agentes seguía en cifras de un solo dígito en casi todas las funciones de negocio, frente a un uso general de la IA en el 88 % de las organizaciones encuestadas.

La seguridad debe tratarse de forma práctica: qué información confidencial y qué datos personales no entran en un encargo, por qué un agente no maneja credenciales en texto plano, cómo se conceden y revisan los permisos de acceso a herramientas y por qué cada acción relevante queda registrada. Solo se puede supervisar lo que se puede reconstruir, y por eso la observabilidad de los agentes importa también a quien no la programa.

Todo ello forma parte de la alfabetización en IA, o AI literacy, que en la Unión Europea tiene reflejo normativo. Tras el Reglamento (UE) 2026/1744 (Digital Omnibus), en vigor desde el 27 de julio de 2026, el artículo 4 del AI Act pide a proveedores y responsables del despliegue que adopten medidas para apoyar la alfabetización en IA de su personal, sin exigir un nivel concreto a cada persona. Según las preguntas frecuentes de la Comisión Europea, no hace falta un certificado y las organizaciones pueden llevar un registro interno de las formaciones e iniciativas. Ningún curso asegura por sí solo el cumplimiento, pero documentar un programa ajustado al uso real de la IA es el tipo de medida que la norma contempla.

Las herramientas cambian en meses, así que una formación sobre agentes debería girar alrededor de criterios que sirven con cualquiera de ellas —cómo definir un encargo, dónde poner una aprobación, cómo validar un resultado— y combinar seis elementos.

• Fundamentos, para entender qué pueden y qué no pueden hacer estos sistemas.
• Casos reales, sobre procesos parecidos a los de la organización y no sobre ejemplos genéricos.
• Práctica de los participantes, porque ver al formador delegar una tarea no enseña a delegarla.
• Gobernanza, para acordar qué se delega y qué requiere aprobación.
• Evaluación, para comprobar que cada persona usa las herramientas con criterio, no solo que asistió.
• Aplicación: que cada participante termine con uno o dos procesos de su trabajo donde aplicar lo aprendido.

Una secuencia razonable, que cada organización debe ajustar a su punto de partida:

Una buena formación empresarial no debería terminar solo con empleados que saben más de IA. La organización debería salir con cuatro piezas que pueda aplicar al día siguiente.

Formar no es adoptar. Una organización puede impartir cursos a cientos de personas y comprobar, meses después, que el uso real de la IA es marginal. La explicación suele estar fuera del aula: el Work Trend Index 2026 de Microsoft, basado en una encuesta a 20.000 trabajadores de diez países, atribuye a los factores organizativos —cultura, apoyo de los mandos y prácticas de talento— más del doble del impacto declarado que a los factores individuales, y cuando los responsables usan la IA de forma visible, sus equipos declaran 30 puntos más de confianza en la IA agéntica.

Por eso la adopción hay que medirla. El número de asistentes, las horas impartidas o los cursos completados miden actividad formativa, no uso. Una estrategia de adopción necesita además casos de uso identificados, acompañamiento y seguimiento de señales como el uso real y su frecuencia, los procesos y casos implantados, la calidad de los resultados, el tiempo ahorrado cuando pueda medirse y las incidencias o riesgos detectados.