«¿Cuánto tarda esto?» es casi siempre la primera pregunta que hace un responsable de negocio cuando se plantea incorporar un agente de IA basado en un LLM a un proceso concreto: atención al cliente, back office, cualificación de leads o revisión documental. Es una pregunta razonable y, al mismo tiempo, de las más difíciles de responder con una fecha cerrada. El calendario de un proyecto de agentes depende mucho menos del modelo de lenguaje elegido que de cuántas herramientas debe manejar el agente, cuánta autonomía se le va a permitir y cuánto tiempo puede dedicar el negocio a supervisar sus primeras decisiones. Este artículo recoge las fases, los hitos y los factores que marcan ese calendario, para que la planificación se apoye en algo más sólido que una fecha comercial optimista.
Por qué «¿cuánto tarda un agente?» no tiene una respuesta única
Dos empresas del mismo tamaño y sector pueden necesitar plazos muy distintos para poner en marcha un proyecto de agentes de IA para back office. La diferencia rara vez está en el modelo de lenguaje: los proveedores actuales ofrecen prestaciones parecidas para la mayoría de tareas empresariales. Está en lo que el agente tiene que hacer una vez recibe la orden: a cuántos sistemas debe conectarse, qué acciones puede ejecutar sin pedir confirmación y quién revisa esas acciones mientras el equipo gana confianza en el sistema.
Conviene por tanto tratar el calendario de un proyecto de agentes como una sucesión de fases con hitos de salida, no como una fecha de entrega fija anunciada antes de conocer el alcance real de las tareas que va a automatizar. Nuestro artículo sobre los errores más caros al implantar agentes y LLM repasa qué falla cuando se salta esta lógica de fases; aquí nos centramos en cómo planificar el tiempo que hace falta para evitarlos.
El calendario de un agente no lo marca el modelo, lo marca lo que el agente tiene que hacer: cuántas herramientas usa, qué nivel de autonomía tiene sobre cada una y cuánto tiempo puede dedicar el negocio a supervisar sus primeras decisiones antes de ampliar su alcance.
Los cuatro factores que fijan el calendario real
Antes de fijar cualquier fecha, conviene revisar estos cuatro puntos. Son, en la práctica, los que más mueven el calendario de un extremo a otro en un proyecto de agentes.
1. Número y estabilidad de las herramientas que el agente debe usar
No es lo mismo un agente que solo consulta información en un sistema que otro que además escribe en un CRM, envía correos o modifica registros en un ERP. Cada herramienta adicional que el agente puede invocar añade trabajo de integración y, sobre todo, trabajo de definición: hay que decidir qué parámetros puede rellenar por su cuenta, qué respuestas de la herramienta debe interpretar como error y qué pasa si esa herramienta no responde a tiempo. Cuando las integraciones dependen de sistemas de terceros con APIs poco documentadas o inestables, el calendario se resiente antes incluso de escribir la primera instrucción del agente.
2. Complejidad de la lógica de decisión y los guardrails
Un agente con dos o tres pasos lineales es rápido de diseñar y de probar. Un agente que debe decidir entre varias rutas posibles, encadenar llamadas a distintas herramientas y saber cuándo detenerse a pedir confirmación humana necesita bastante más tiempo de diseño, porque cada rama de decisión hay que probarla por separado. Los guardrails —los límites que impiden que el agente ejecute una acción fuera de su alcance— deben cubrir también los casos poco frecuentes, no solo el camino habitual.
3. Nivel de autonomía y necesidad de supervisión humana
Cuanto más impacto tiene una acción del agente —enviar un correo a un cliente, confirmar un pedido, modificar una condición económica—, más conviene que un humano la revise antes de que se ejecute, al menos en las primeras semanas. Si las personas que deben hacer esa revisión solo tienen disponibilidad limitada, el calendario se alarga aunque el equipo técnico haya terminado su parte: la supervisión humana suele ser, igual que ocurre en otros proyectos de IA, el cuello de botella real de la fase de piloto.
4. Si ya existe un conjunto de casos de prueba o hay que crearlo desde cero
Contar de antemano con un listado de situaciones reales —incluidas las situaciones límite, no solo las habituales— y con la acción correcta esperada en cada una adelanta semanas de trabajo. Si no existe, hay que construirlo junto con las personas del negocio que mejor conocen el proceso, y eso no se puede comprimir sin perder fiabilidad en las pruebas posteriores: un conjunto de casos improvisado en un par de días rara vez incluye los escenarios donde el agente puede hacer más daño si se equivoca.
Calendario orientativo por fases
Las duraciones que siguen son orientativas: varían según el número de herramientas, el nivel de autonomía objetivo y la disponibilidad del equipo del cliente para supervisar el piloto. Sirven como punto de partida para planificar, no como un compromiso cerrado antes de conocer el proyecto concreto.
| Fase | Semanas orientativas | Qué debe estar cerrado para avanzar |
|---|---|---|
| 0 · Alcance y caso de uso | 1-2 | Proceso acotado, propietario del proyecto y criterio de éxito por escrito |
| 1 · Diseño de herramientas y permisos | 2-4 | Listado de herramientas con su propietario, sus parámetros y sus límites de uso |
| 2 · Orquestación y guardrails | 3-6 | Lógica de decisión probada sobre un subconjunto real, límites de autonomía definidos |
| 3 · Conjunto de casos de prueba | 2-4 (en paralelo con la fase 2) | Casos reales, incluidos los casos límite, con la acción correcta acordada con el negocio |
| 4 · Piloto supervisado | 3-6 | Umbrales de calidad superados, revisión humana activa en acciones de alto impacto |
| 5 · Producción con autonomía ampliada | a partir de la semana 10-18 | Plan de monitorización y calendario de revisión de herramientas aprobado |
Fase 0: Alcance y caso de uso
Antes de definir una sola herramienta, conviene acotar el proceso concreto que el agente va a asumir —un tipo de consulta, un tramo del back office, un canal de atención— y nombrar a la persona responsable de decidir sobre su comportamiento. En esta fase también se fija por escrito qué significa que el proyecto ha funcionado: qué porcentaje de casos debe resolver sin intervención, qué tipo de decisiones quedan fuera del alcance inicial y quién revisa los resultados del piloto.
Fase 1: Diseño de herramientas y permisos
Se identifican las herramientas que el agente va a poder usar, se asigna un propietario a cada integración y se decide qué acciones quedan dentro y cuáles fuera del proyecto en esta primera versión. Esta fase suele revelar el primer desajuste entre el calendario deseado y el real: es habitual descubrir APIs sin documentar, sistemas sin entorno de pruebas o herramientas que nadie sabe si siguen dando datos fiables. Resolver esas dudas antes de conectar nada evita tener que rehacer el trabajo más adelante.
Fase 2: Orquestación y guardrails
Se diseña la secuencia de decisiones del agente y se implantan los límites de autonomía desde el principio: qué puede hacer solo, qué requiere confirmación y qué queda completamente fuera de su alcance. Cuando el proyecto necesita conectar varios sistemas de origen —un ERP, un CRM, una intranet—, conviene evaluar si una integración MCP simplifica esas conexiones frente a desarrollar un conector distinto para cada sistema.
Fase 3: Conjunto de casos de prueba
En paralelo a la orquestación, se construye el conjunto de casos reales con los que se medirá el comportamiento del agente: casos sencillos, casos que combinan varias herramientas, casos sin una acción clara y situaciones donde lo correcto es que el agente se detenga y pida ayuda. Cuanto antes empiece esta fase, menos presión sufre al final del proyecto, porque construir un buen conjunto de casos con el negocio lleva tiempo de coordinación, no solo de redacción.
Fase 4: Piloto supervisado
El agente se despliega sobre un grupo reducido de casos reales, con revisión humana de las acciones de mayor impacto antes de que se ejecuten. Aquí se miden de forma sistemática las métricas definidas en la fase 0: porcentaje de casos resueltos sin corrección, calidad de las decisiones cuando hay ambigüedad y frecuencia con la que el agente se detiene correctamente en lugar de actuar por su cuenta. La autonomía solo se amplía cuando el piloto supera los umbrales acordados, no cuando se cumple la fecha inicialmente prevista.
Fase 5: Producción con autonomía ampliada
Una vez superado el piloto, el agente se abre a más casos o más volumen de forma progresiva, reduciendo la supervisión humana solo en las acciones donde el histórico lo respalda. Esta fase no tiene una fecha de cierre real: el proyecto entra en un ciclo continuo de monitorización que conviene planificar desde el principio, como se explica más abajo. Nuestro artículo sobre agentes de IA y LLM: comparativa de opciones reales puede ayudar a decidir, antes de llegar a esta fase, qué tipo de arquitectura de agente encaja mejor con el nivel de autonomía que busca la empresa.
Hitos que conviene fijar por escrito antes de arrancar
Cada cambio de fase debería depender de un hito comprobable, no de que haya pasado un número determinado de semanas en el calendario. Algunos hitos habituales en un proyecto de agentes:
- Cada herramienta que el agente puede usar tiene propietario asignado y ha sido probada en condiciones reales antes de conectarla a la orquestación.
- Los límites de autonomía se han probado con casos límite antes de dar acceso a acciones de alto impacto.
- El conjunto de casos de prueba ha sido revisado por al menos una persona experta del negocio, no solo por el equipo técnico.
- El piloto ha superado los umbrales de calidad acordados antes de ampliar la autonomía o el volumen de casos.
- Existe un responsable designado para monitorizar el comportamiento del agente una vez está en producción.
Avanzar de fase sin cerrar estos hitos suele generar el efecto contrario al buscado: se gana unos días en el calendario a corto plazo y se pierden varias semanas más adelante corrigiendo decisiones que el hito habría detectado a tiempo.
Qué suele alargar el calendario en la práctica
Más allá de la lista de factores anterior, hay causas concretas que aparecen una y otra vez en proyectos reales de agentes:
- Herramientas sin entorno de pruebas. Si no existe una copia segura donde probar las acciones del agente, cada prueba se hace sobre datos reales y el equipo avanza con más cautela, lo que alarga la fase de diseño.
- Cambios de alcance a mitad de proyecto. Añadir una nueva herramienta o un nuevo tipo de decisión después de haber cerrado el conjunto de casos obliga a rehacer parte del trabajo de validación.
- Ausencia de casos de prueba al inicio. Empezar a construirlos solo cuando el piloto ya está listo para lanzarse retrasa la fecha real de salida.
- Guardrails definidos de forma genérica. Límites de autonomía redactados en términos vagos —«el agente debe actuar con prudencia»— obligan a volver atrás cuando aparece el primer caso ambiguo en producción.
- Poca disponibilidad del negocio para supervisar. Si las personas que deben revisar las acciones de alto impacto solo pueden dedicar una hora a la semana, el piloto se alarga aunque el sistema esté técnicamente listo.
El calendario no termina en el lanzamiento
Un error habitual es tratar la fecha de salida a producción como el final del proyecto. Las herramientas que usa el agente cambian: se actualizan las APIs de los sistemas externos, se sustituye el modelo de lenguaje, se añaden nuevos casos de uso. Por eso conviene incluir desde el principio un calendario de mantenimiento con, al menos, estos elementos:
- una cadencia de revisión para las herramientas más críticas, distinta de la de las integraciones de uso ocasional;
- un proceso claro para retirar acciones que ya no aplican y evitar que el agente intente ejecutarlas;
- una revisión periódica del conjunto de casos de prueba, para que siga representando las situaciones reales del negocio;
- un canal para que las personas que trabajan con el agente señalen decisiones incorrectas o inesperadas.
Sin este calendario de mantenimiento, el comportamiento del agente tiende a degradarse con el tiempo aunque el diseño inicial fuera sólido: no por un fallo del modelo, sino porque las herramientas y los guardrails dejan de reflejar la realidad de los sistemas que el agente usa cada día. El servicio de LLMOps y evaluación de agentes IA de Summum IA está pensado precisamente para sostener ese ciclo una vez el agente está en producción.
El calendario regulatorio corre en paralelo
Si el agente interactúa directamente con personas —atención al cliente, cualificación de leads por chat— entra en juego el artículo 50.1 del Reglamento (UE) 2024/1689 (AI Act): informar de que se está interactuando con un sistema de IA. Esa obligación es exigible desde el 2 de agosto de 2026 y no tiene periodo transitorio, así que conviene tratarla como un hito más del calendario del proyecto, no como un trámite de última hora antes del lanzamiento: el aviso de transparencia se diseña junto con el resto de la interfaz, no se añade encima al final. El texto del Reglamento (UE) 2024/1689 detalla el alcance exacto de esta obligación.
Cómo comunicar un calendario realista
De cara al equipo directivo, suele funcionar mejor comunicar un rango con hitos verificables que una fecha única cerrada de antemano. En lugar de «el agente estará listo el día X», resulta más honesto y más útil plantear algo como: «el piloto empieza cuando las herramientas estén probadas y el conjunto de casos aprobado por el negocio; a partir de ahí, necesitamos entre tres y seis semanas de piloto supervisado antes de decidir si ampliamos la autonomía». Ese formato traslada la responsabilidad del calendario a los hitos, no a una fecha que puede incumplirse por causas ajenas al equipo técnico, como una API de terceros que cambia sin aviso.
Si tu empresa está valorando un proyecto de agentes y quiere partir de un calendario realista en lugar de una fecha comercial optimista, el equipo de agentes de IA para back office de Summum IA puede ayudar a mapear las herramientas, los guardrails y el nivel de autonomía adecuado antes de comprometer ninguna fecha.
Preguntas frecuentes
¿Cuánto tarda de media un proyecto de agentes de IA con LLM?
Depende sobre todo del número de herramientas que el agente debe usar, del nivel de autonomía que se le va a permitir y de la disponibilidad de un entorno de pruebas donde validar sus acciones sin riesgo. Un agente con pocas herramientas estables y un alcance acotado puede llegar a piloto supervisado en unas ocho semanas; un agente que debe orquestar varios sistemas críticos y actuar con autonomía amplia necesita bastante más tiempo, sobre todo en la fase de guardrails y evaluación.
¿Se puede acortar el calendario limitando el número de herramientas del agente?
Sí. Empezar con dos o tres herramientas bien probadas, en lugar de conectar de entrada todos los sistemas que el agente podría usar algún día, es la palanca más eficaz para adelantar el piloto. Además reduce el riesgo de tener que rediseñar los guardrails si alguna integración resulta más frágil de lo previsto.
¿Qué alarga más el calendario: el modelo o las integraciones y los guardrails?
En la mayoría de proyectos, las integraciones y los guardrails. Elegir y conectar un modelo de lenguaje es relativamente rápido; lo que consume semanas es definir con precisión qué acciones puede tomar el agente, probar cada herramienta en condiciones reales y construir los límites que evitan que una decisión equivocada llegue a producción sin supervisión.
¿Cuándo conviene ampliar la autonomía del agente sin supervisión humana constante?
Solo después de que el piloto supervisado demuestre, con datos reales, que el agente respeta sus límites de actuación y que las intervenciones humanas necesarias han bajado a un nivel asumible. Ampliar la autonomía antes de tener esos datos suele obligar a revertir el cambio en cuanto aparece el primer incidente.
¿Hay que seguir revisando el calendario después del lanzamiento?
Sí. Los sistemas externos que el agente usa cambian sus APIs, el negocio añade nuevos casos de uso y los modelos se actualizan, así que el calendario debe incluir ciclos periódicos de revisión de herramientas, guardrails y casos de prueba, no solo las fases previas al lanzamiento.
En resumen: hitos, no fechas
Un calendario de agentes bien planteado no promete una fecha única desde el primer día: define hitos comprobables, se apoya en el número real de herramientas y en el nivel de autonomía que el negocio está dispuesto a asumir, y sigue vivo después del lanzamiento. Si quieres revisar el alcance de tu proyecto antes de fijar una fecha, el equipo de Summum IA puede acompañar el diagnóstico inicial y el diseño de las herramientas y los guardrails que suelen condicionar el calendario.