Piloto de agente de IA en 30/60/90 días: el plan de despliegue a producción para pymes austriacas

Un despliegue realista de un agente de IA dura unos 90 días. En los días 0 a 30 acotas y reduces el riesgo: eliges un flujo de trabajo delimitado y de alto volumen, lo mapeas, defines la métrica de éxito y un criterio de abandono por adelantado, inventarías los sistemas y permisos que el agente necesita, y montas el logging y un conjunto de evaluación con casos reales. En los días 31 a 60 construyes contra un sandbox y operas en modo sombra, donde el agente propone y una persona aprueba, mientras mides contra el conjunto de evaluación y ajustas los permisos al mínimo privilegio. En los días 61 a 90 despliegas sobre una porción del volumen real con puertas de aprobación, vigilas el coste por acción y la tasa de error, escribes un runbook y un rollback, entregas la propiedad al equipo y decides: ampliar, iterar o detener. Las partes difíciles son los permisos, el diseño de la aprobación, las evaluaciones, el logging y una entrega limpia, no el modelo.

Esto es el cómo, escrito desde la práctica. Para el porqué mueren estos proyectos, nuestro artículo complementario sobre por qué se cancelan los proyectos de agentes de IA cubre los grupos de fallos; este es el plan que los evita. Las fechas regulatorias son de mediados de 2026 y van matizadas allí donde están en movimiento.

Primero: ¿es un agente siquiera la herramienta correcta?

Un agente de IA es un sistema en el que el modelo decide sus propios pasos y ejecuta acciones contra tus sistemas a través de herramientas, trabajando en varios pasos hacia un objetivo con poca intervención humana. Quita cualquiera de esos elementos y se reduce a algo más simple y normalmente mejor. La mayoría de los proyectos de "agente" fallidos deberían haber sido un asistente RAG o un flujo de trabajo programado. Elige la herramienta más barata que haga el trabajo.

La regla práctica: reserva los agentes para flujos de trabajo donde el razonamiento adicional cambia el resultado de negocio. Si los pasos nunca varían, un agente es la herramienta equivocada, más cara y menos auditable.

Días 0 a 30: acotar y reducir el riesgo

Todo el piloto se gana o se pierde aquí. Elige un flujo de trabajo de alto volumen y con límites claros, y anota, antes de construir nada: el único número que intentas mover, la línea base previa a las herramientas (empieza a medir ya) y un criterio de abandono (por ejemplo, detener si la adopción está por debajo de un umbral fijado en la semana cuatro, o si los datos están demasiado sucios, o el impacto es demasiado pequeño). Inventaría cada sistema y permiso que el agente tocará y planifica el mínimo privilegio desde el principio. Monta el logging y la observabilidad, y construye un pequeño conjunto de evaluación con casos reales; 20 a 50 tareas extraídas de fallos reales son un gran comienzo. Decide qué acciones necesitan una puerta de aprobación humana, sobre todo cualquier cosa irreversible.

Días 31 a 60: construir y operar en sombra

Construye contra un sandbox, nunca contra sistemas en vivo. Luego opera en modo sombra: el agente procesa las mismas entradas reales que tu equipo y registra lo que haría, pero las personas siguen siendo quienes deciden al final, así que mides su juicio antes de que toque nada. Usa una escalera de autonomía, primero supervisada, luego aprobaciones solo por excepción o por muestreo cuando las métricas se lo ganen. Puntúa de forma ligera en el día 30 y el día 60 contra el conjunto de evaluación, para que la decisión del día 90 sea una confirmación, no una sorpresa. Baja los permisos al mínimo privilegio y haz red-teaming deliberado de los modos de fallo: inyección de prompts, llamadas inseguras a herramientas y la petición ambigua del mundo real que nunca aparece en una demo. Diseñar para la entrada desordenada, no para el camino feliz, suele ser lo que separa un piloto que llega a producción de uno que no.

Días 61 a 90: producción limitada y entrega

Despliega sobre una porción del volumen real con las puertas de aprobación todavía activas, y empieza con una postura de auditoría primero: observa el comportamiento, luego aprieta los controles. Monitoriza el coste por acción y la tasa de error, y aplica presupuestos estrictos de tokens y coste en la capa de infraestructura antes de cada llamada, no en un informe posterior. Escribe el runbook y el rollback: define el disparador que revierte automáticamente a la versión anterior si una métrica empeora. Luego haz la parte que la mayoría de los equipos se salta: entrega la propiedad al equipo. La autoridad de decisión, quién puede cambiar el agente y quién es responsable, debe definirse antes del despliegue más amplio, y el equipo tiene que ser capaz de leer las trazas y ejecutar el runbook sin las personas que lo construyeron. Por último, toma la decisión contra tu métrica del día 0 y tu criterio de abandono: ampliar, iterar o detener.

Las partes difíciles, y cómo acertar con ellas

• Permisos y mínimo privilegio. El riesgo de "excessive agency" de OWASP se remonta a un exceso de funcionalidad, permisos y autonomía. Da al agente acceso de mínimo privilegio, acotado a la tarea y limitado en el tiempo, y su propia identidad, para que puedas aplicar el mínimo privilegio y reconstruir lo que pasó tras un incidente.
• Diseño de la aprobación humana. El patrón es proponer y luego aprobar: el agente se detiene ante una acción de alto impacto o irreversible y una persona la aprueba, edita o rechaza con todo el contexto. No necesitas aprobar cada acción, pero sí necesitas poner una puerta a las que pueden causar daño.
• Evaluaciones y regresión. Tres capas: comprobaciones deterministas por paso, muestreo en producción para detectar la deriva y revisión humana periódica para calibrar. Probar un agente significa probar su juicio, no solo una salida.
• Logging y rastro de auditoría. Registra cada llamada al modelo, cada invocación de herramienta y cada decisión. Sin ello no puedes depurar, mejorar ni demostrar lo que hizo el agente, y bajo el RGPD tienes que poder demostrarlo.
• Coste por acción y fallback. Los flujos agénticos pueden costar varias veces más por tarea que un chatbot porque el contexto se reenvía en cada paso. Mide el coste por resultado desde el primer día, enruta los pasos baratos a modelos pequeños y define qué pasa cuando una herramienta o el modelo falla.
• Entrega limpia. Un agente que solo entiende tu proveedor es un lastre, no una victoria. El equipo debe ser su dueño.

"El modelo es ahora la parte fácil. Los 90 días tratan de permisos, puertas de aprobación, evaluaciones y una entrega limpia. El modo sombra es el paso de mayor apalancamiento: deja que el agente demuestre su juicio con entradas reales mientras una persona sigue al volante, y la decisión de salida a producción se toma sola."

Por qué fracasan tantos proyectos de agentes

Gartner prevé que más del 40 por ciento de los proyectos de IA agéntica se cancelarán para finales de 2027, citando costes crecientes, valor de negocio poco claro y controles de riesgo inadecuados. Los fracasos se agrupan en formas reconocibles: alucinación, latencia, deuda de evaluación, coste por acción descontrolado, entrega ausente, datos sucios, ambición de alcance y lagunas de auditoría. El plan de 90 días de arriba está construido para sacar a la luz cada una de ellas pronto, en los primeros 30 días, donde son baratas de corregir, en lugar del sexto mes, donde matan el proyecto. Desglosamos los grupos en por qué se cancelan los proyectos de agentes de IA, y las habilidades de orquestación detrás de operar bien varios agentes en el foco es el cuello de botella.

La parte de la UE y Austria

Un agente que actúa sobre datos personales cae de lleno en el RGPD. Debes mantener un rastro de auditoría (el principio de responsabilidad proactiva implica que tienes que demostrar lo que pasó), aplicar la minimización de datos y el mínimo privilegio, y proporcionar una supervisión humana significativa para cualquier decisión automatizada relevante, no un sello de goma simbólico. También necesitas un acuerdo de tratamiento de datos firmado con cada proveedor de modelo y de nube antes de que les fluyan datos personales, y los proveedores estadounidenses conllevan un riesgo residual de transferencia incluso con residencia en la UE. La autoridad austriaca de protección de datos te trata a ti, la empresa que despliega, como el responsable del tratamiento, así que la responsabilidad es tuya. Sobre el EU AI Act, las obligaciones de transparencia del Artículo 50, incluido informar a las personas de que tratan con una IA, se aplican desde el 2 de agosto de 2026, igual que la mayoría de las obligaciones de alto riesgo. Un Digital Omnibus propuesto que aplazaría algunos plazos de alto riesgo se acordó provisionalmente en 2026 pero todavía no es ley, así que planifica contra la fecha del 2 de agosto de 2026.