Agentes de IA en producción: 12 lecciones de equipos que realmente los operan

Los equipos que operan agentes en producción con éxito no ejecutan los agentes que se ven en las demos. El primer estudio a gran escala de agentes desplegados encontró que el 68% ejecuta como máximo 10 pasos antes de que un humano intervenga, el 70% simplemente usa modelos comerciales mediante prompts en lugar de ajustar pesos, y el 74% se apoya principalmente en la evaluación humana (Pan et al., arXiv:2512.04123). La restricción es el producto.

Esa brecha importa porque el 57,3% de los equipos ya tiene agentes en producción, y la calidad es su principal obstáculo, con un 33% (LangChain). Mientras tanto, el 89% tiene observabilidad, pero solo el 37,3% ejecuta evaluaciones en línea. Puedes observar cómo trabaja tu agente sin saber si lo hace bien.

Estas doce lecciones provienen de esa investigación, del sistema de clasificación de ataques del equipo rojo de Microsoft y de post-mortems con nombres reales. Cada una es un límite que se establece de forma deliberada.

Qué ejecutan los equipos en producción (lecciones 1–2)

Los agentes que sobreviven en producción no se parecen casi nada a los sistemas autónomos y autodirigidos de las demos de lanzamiento. Son cortos, supervisados y aburridos a propósito.

Lección 1: Los agentes desplegados tienen horizontes deliberadamente cortos

El primer estudio académico a gran escala de agentes desplegados, MAP, entrevistó en profundidad a 20 equipos y encuestó a 86 profesionales que operan sistemas en vivo en 26 dominios. Encontró que el 68% de los agentes de producción ejecuta como máximo 10 pasos antes de que un humano intervenga, el 70% simplemente usa modelos comerciales con prompts en lugar de ajustar pesos, y el 74% depende principalmente de la evaluación humana.

Lee esas tres cifras juntas y el panorama queda claro. Nadie que haya mantenido un agente activo durante seis meses ejecuta un planificador de 200 pasos contra un modelo ajustado con un marcador automatizado. Ejecutan un bucle de diez pasos sobre Claude o GPT con una persona leyendo el resultado.

Esta es una decisión de diseño que el tiempo no erosionará. El número de pasos es la variable que los equipos reducen cuando las cosas se rompen, porque cada paso adicional multiplica las posibilidades de una llamada de herramienta incorrecta, un contexto contaminado o una sorpresa de costes. Los horizontes cortos son el punto al que llegan los equipos después de desplegar.

Y muchos equipos ya superaron la fase piloto. La encuesta State of AI Agents de LangChain, con 1.340 respuestas recopiladas entre el 18 de noviembre y el 2 de diciembre de 2025, encontró que el 57,3% de los encuestados tiene agentes en producción, cifra que sube al 67% en organizaciones con más de 10.000 empleados. La misma encuesta sitúa la calidad y la precisión como el principal obstáculo con un 33%, con la latencia en segundo lugar con un 20%. El coste bajó en la lista respecto al año anterior.

Así que la restricción ya no es el presupuesto. Es si el sistema hace lo correcto dos veces seguidas.

Lección 2: La fiabilidad se corrige en la capa de sistemas

MAP identifica la fiabilidad, definida como el comportamiento correcto y consistente a lo largo del tiempo, como el principal desafío de desarrollo para los equipos con agentes en producción. Lo que importa más es cómo responden esos equipos ante ella. Recurren a la autonomía restringida y al scaffolding determinista: límites de pasos codificados de forma fija, listas de herramientas permitidas, validación entre llamadas y una puerta humana antes de cualquier acción irreversible.

Es una decisión de arquitectura que sobrevive a un cambio de modelo.

También reencuadra cada lección que sigue. Si navegas por los más de 550 agentes de IA en nuestro directorio, el texto de marketing vende capacidad: más herramientas, mayor autonomía, memoria más rica. Los equipos que operan estos sistemas en producción compran lo contrario. Cada una de las siguientes diez lecciones es un límite que alguien añadió después de un incidente, y son esos límites los que mantienen al agente desplegado.

Alcance de permisos: a qué puede acceder la credencial de tu agente (lecciones 3–5)

El control de fiabilidad más económico que puedes desplegar esta semana es un token más pequeño. Elimina los alcances de escritura de la credencial con la que se autentica tu agente y toda una clase de incidentes en producción deja de ser posible.

Existe un número de referencia para esto. AgentDojo probó agentes en 97 tareas y 629 casos de prueba de seguridad, y encontró que denegar las herramientas de alcance de escritura cuando la tarea del usuario solo necesita acceso de lectura reduce la tasa de éxito de los ataques de inyección de prompts al 7,5% (AgentDojo, arXiv:2406.13352). Ese resultado proviene únicamente de la configuración. Si te niegas a otorgar capacidades que la tarea no necesita, el ataque no tiene dónde aterrizar.

Lección 3: El radio de explosión se establece cuando se emite la credencial

Cuando el agente de Replit eliminó una base de datos de producción el 19 de julio de 2025, el fallo no fue que el agente malinterpretara sus instrucciones. Fue que un agente en modo desarrollo tenía credenciales que llegaban a los datos de producción. Las propias palabras de Amjad Masad: "Inaceptable y nunca debería ser posible" (@amasad en X). La lista de medidas correctivas que publicó Replit parece una auditoría de permisos, y comienza con la separación automática de bases de datos de dev/prod y un modo de solo planificación "para que puedas estrategizar sin arriesgar tu código" (The Register).

Las medidas de protección a nivel de prompt se ejecutan dentro del mismo límite de confianza que el ataque. El alcance de credenciales se ejecuta fuera de él.

Así que haz la auditoría aburrida antes del lanzamiento. Cada capacidad de la lista siguiente debe ser un sí deliberado, no un valor heredado por defecto de cualquier cuenta de servicio que hubiera disponible.

• Elimina los alcances de escritura, eliminación y cambios de esquema de cualquier agente cuya función sea la recuperación, la clasificación o la redacción. La mayoría de los agentes son agentes de lectura que llevan una insignia de administrador.
• Dale al agente su propia identidad. Las cuentas de servicio compartidas hacen imposible el análisis forense post-incidente y permiten que el compromiso de un agente herede los permisos del equipo de otro.
• Separa los almacenes de datos de dev y prod a nivel de conexión, de modo que un agente mal dirigido físicamente no pueda resolver el host de producción.
• Limita lo que puede alcanzar la credencial por fila y por tabla, no solo por verbo. El acceso de solo lectura a todos los registros de clientes sigue siendo una brecha de datos esperando su ruta de exfiltración.
• Coloca una puerta de aprobación frente a los comandos destructivos y haz que falle de forma cerrada cuando el aprobador no responde.

Lección 4: Solo lectura por defecto, porque el filtrado de alcance es una defensa medible

Un agente se vuelve peligroso cuando se superponen tres capacidades: lee datos que vale la pena robar, consume contenido escrito por alguien fuera de tu empresa y puede enviar algo hacia afuera. El equipo rojo de Microsoft denomina la inyección de prompts entre dominios como «el vector de acceso inicial más fiable» tras un año atacando sistemas desplegados (Microsoft Security Blog). Ese vector solo le resulta rentable al atacante cuando el agente en el que aterriza tiene algún lugar adónde enviar los datos.

El alcance es la forma de romper esa cadena sin renunciar al producto. Elimina el canal de salida para los agentes que leen datos sensibles. Elimina el permiso de datos privados para los agentes que navegan por la web abierta. Microsoft califica la contaminación del contexto de sesión como «muy eficaz y difícil de detectar» (Microsoft Security Blog), así que asume que la ventana de contexto está contaminada y deja que la credencial decida qué puede hacer un contexto contaminado.

Si estás eligiendo entre plataformas de construcción de agentes, haz de la configuración de alcance por herramienta tu primer filtro. Una plataforma donde cada conector obtiene el alcance OAuth completo al instalarse ya ha perdido el resultado del 7,5%.

Lección 5: Trata cada superficie de herramienta como entrada no confiable

El equipo rojo de Microsoft, tras un año probando sistemas agénticos desplegados, denomina la inyección de prompts entre dominios «el vector de acceso inicial más fiable» y añade el Abuso de MCP/Plugin como un nuevo modo de fallo en su taxonomía v2.0, junto con 99 CVEs publicados para software relacionado con MCP durante 2025 (Microsoft Security Blog). OWASP clasifica las vulnerabilidades de la cadena de suministro agéntica en ASI04, ancladas al exploit de GitHub MCP (OWASP GenAI).

Este es el argumento contra instalar un servidor solo porque es conveniente. La salida de las herramientas es texto accesible para los atacantes que tu modelo leerá como instrucciones, y cada servidor MCP que añades es otra parte que puede escribir en el contexto de tu agente. Entre los 128 frameworks de agentes en nuestro directorio, los que valen tu tiempo te permiten incluir herramientas en la lista de permitidas por ejecución y fijar versiones de servidor.

Bucles desbocados y techos de coste (lecciones 6–7)

Presupuesta aproximadamente 4× tu gasto en chat en el momento en que desates un agente, y alrededor de 15× si vas a múltiples agentes. Esos son los propios números de producción de Anthropic (Anthropic Engineering), y son el suelo, no el techo. Un bucle atascado no tiene ningún límite superior natural.

Lección 6: Los agentes consumen 4× los tokens del chat, los multiagente consumen 15×

La parte incómoda es que el gasto compra algo real. En la evaluación interna de Anthropic, el uso de tokens por sí solo explicó el 80% de la varianza de rendimiento en el benchmark BrowseComp, y un Claude Opus 4 como orquestador líder con subagentes Sonnet 4 superó a Opus 4 de agente único en un 90,2% en tareas de investigación (Anthropic Engineering). Limitar los tokens significa limitar la capacidad. Esa es la compensación que estás haciendo cuando estableces un techo, así que hazlo de forma deliberada en lugar de descubrirlo durante una revisión de incidentes.

La propia guía de Anthropic es que las arquitecturas multiagente «requieren tareas donde el valor es lo suficientemente alto como para justificar los costes incrementales» (Anthropic Engineering). Haz esa prueba antes de expandirte. Una tarea de investigación que vale $400 del tiempo de un analista justifica una ejecución de orquestador de $12. Una clasificación de soporte que ahorra noventa segundos no.

Se derivan dos acciones prácticas. Coloca el modelo costoso en el orquestador y modelos más económicos en los workers, que es exactamente la estructura de Opus como líder con subagentes Sonnet descrita arriba, y revisa las opciones de modelos y niveles de precios actuales antes de asumir que tu elección predeterminada es la correcta para el nivel de worker.

Lección 7: La observabilidad sin cumplimiento es una factura muy detallada

Un caso reportado tiene cuatro agentes rebotando a través de A2A durante 264 horas y quemando $47.000, siendo las causas raíz nombradas la ausencia de un límite de presupuesto por agente y de una puerta de terminación previa a la llamada (Get Ready For Agents, reportado de segunda mano). Once días. Los dashboards estaban activos todo el tiempo.

Un dashboard informa después del hecho. Una puerta se sitúa en la ruta de la llamada y puede negarse. Solo la segunda detiene una factura, y en la mayoría de las bases de código las dos no están cerca la una de la otra.

Medidas de cumplimiento que vale la pena desplegar esta semana:

• Un presupuesto de tokens por ejecución verificado antes de cada llamada al modelo, no contabilizado después. Cuando el total acumulado supere el límite, la llamada no se realiza y la ejecución falla de forma visible.
• Un techo duro de pasos. La mayoría de los equipos de producción ya están por debajo de diez pasos antes de que un humano toque la ejecución, así que un límite de 15 o 20 no te cuesta nada en el tráfico normal y elimina las ejecuciones patológicas.
• Tiempos de espera de reloj de pared para toda la ejecución, no solo para las llamadas HTTP individuales. El bucle de $47.000 estaba compuesto de solicitudes subsegundo perfectamente sanas.
• Un presupuesto por agente en configuraciones multiagente, de modo que un subagente que se desvíe no pueda gastar la asignación del orquestador.
• Una alerta sobre la derivada, no sobre el total. Un gasto por hora que sube 5× sobre la línea base es una señal horas antes de que el total mensual parezca extraño.

Establece los límites a partir de percentiles reales. Toma tu coste de ejecución p95 de una semana de tráfico, multiplícalo por tres y hazlo el límite duro. Cortarás algunas ejecuciones largas legítimas, que es el precio correcto para nunca tener una de once días.

Puertas de supervisión humana que no se degradan en sellos de goma (lecciones 8–9)

Un paso de aprobación humana es un componente con un límite de rendimiento. Trátalo como una cola: tiene una tasa de servicio, se satura bajo carga y cuando se satura la calidad de cada decisión cae hacia cero mientras la tasa de clics se mantiene al 100%.

Lección 8: La omisión de HITL es el modo de fallo más explotado en la realidad

El equipo rojo de IA de Microsoft pasó un año atacando sistemas agénticos desplegados, y el resultado principal es incómodo para cualquiera que haya puesto un diálogo de confirmación frente a una herramienta peligrosa y lo haya considerado suficiente. La omisión del control humano en el bucle fue «el modo de fallo explotado de forma más consistente, con muy alta frecuencia», con la inyección de prompts entre dominios como «el vector de acceso inicial más fiable» y la contaminación del contexto de sesión calificada como muy eficaz y difícil de detectar (Microsoft Security Blog).

La omisión normalmente no significa derrotar la puerta. Significa que el prompt de aprobación le muestra al humano un resumen que escribió el atacante.

Así que la integridad de la puerta depende de lo que muestra. Muestra la llamada literal: el nombre de la herramienta, los argumentos resueltos, el recurso objetivo, la identidad de la credencial utilizada. Si tu interfaz de aprobación muestra la descripción en lenguaje natural del modelo de lo que está a punto de hacer, has construido una puerta para la que una instrucción inyectada puede escribir la etiqueta. OWASP rastrea esta misma forma como ASI09, Explotación de la Confianza Humano-Agente, en su Top 10 para Aplicaciones Agénticas publicado el 9 de diciembre de 2025.

Lección 9: La supervisión tiene una capacidad, así que presupuesta las aprobaciones como un límite de tasa

Haz el cálculo antes de diseñar el flujo de trabajo. Cincuenta agentes haciendo 20 llamadas de herramientas por hora producen 1.000 eventos elegibles para aprobación por hora. Enruta incluso el 10% de esos a una persona y obtienes 100 aprobaciones por hora, lo que equivale a aproximadamente tres humanos a tiempo completo que no hacen nada más que hacer clic en aprobar (Tian Pan). Nadie tiene ese personal, así que la cola se clasifica por velocidad y la puerta se convierte en un mecanismo de registro con latencia adicional. El hallazgo de MAP de que el 74% de los equipos de producción depende principalmente de la evaluación humana es el mismo problema de capacidad visto desde el lado de la medición.

Establece puertas basadas en el radio de explosión, no en intuiciones de riesgo. Tres propiedades justifican una interrupción: la acción es irreversible, cruza un límite de confianza (escribe fuera del sandbox del propio agente, envía a una parte externa) o una sola llamada toca muchos registros a la vez. Todo lo demás se registra y se muestrea.

Patrones que se mantienen cuando el revisor está cansado:

• Denegar por defecto en el tiempo de espera. Una aprobación sin respuesta debe fallar de forma cerrada, no encolarse silenciosamente hasta que alguien la despeje en masa a las 5pm.
• Agrupar por intención, no por llamada. Una aprobación que cubre «actualizar estas 40 filas, aquí está el diff» es mejor que 40 prompts que nadie lee más allá del tercero.
• Muestrear el tráfico aprobado automáticamente. Si el 10% de las llamadas de bajo riesgo se revisan después del hecho, encontrarás desviaciones sin añadir a la cola en vivo.
• Desplegar un modo de solo planificación. Replit añadió exactamente eso después de que su agente eliminara una base de datos de producción, junto con separación automática de dev/prod y restauración con un clic (The Register). Un modo en el que el agente puede estrategizar sin tocar el código elimina clases enteras de aprobaciones de la cola.
• Hacer seguimiento de la tasa de aprobación por revisor. Un humano que aprueba el 99% de lo que ve ya no está revisando, y ese número es medible hoy.

Vale la pena leer algunos casos de estudio de despliegue con esta perspectiva: cuenta cuántas decisiones por hora envía su diseño a una persona, luego pregunta quién es esa persona.

Medir la fiabilidad en lugar de promedios (lecciones 10–11)

Ejecuta cada tarea de evaluación ocho veces e informa el peor caso. Ese único cambio en tu suite de evaluación te dirá más sobre el comportamiento en producción que cualquier número de clasificación que puedas encontrar, porque los promedios ocultan exactamente el fallo que experimentan tus clientes.

Lección 10: pass^1 te halaga, la producción ejecuta pass^k

El τ-bench de Sierra le dio nombre a esto con pass^k, la probabilidad de que todos los k ensayos independientes de la misma tarea tengan éxito. Un agente GPT-4o de llamada a funciones que puntúa por encima del 60% en el éxito promedio de tareas en el dominio minorista cayó por debajo del 25% en pass^8 (τ-bench). El mismo agente, las mismas tareas, las mismas herramientas. Lo único que cambió fue pedirle que acertara repetidamente.

Esa brecha es lo que experimenta un cliente. Si un agente de soporte maneja un reembolso correctamente el 60% de las veces, el octavo cliente de esta hora no obtiene una experiencia del 60%, sino una moneda al aire que ya salió cruz dos veces para alguien más.

Los umbrales de fiabilidad también te cuestan alcance. METR encontró que la longitud de la tarea que un modelo puede completar con un 80% de fiabilidad es 4–6× más corta que la longitud que puede completar al 50% (METR, marzo de 2025). Elige tu umbral antes de elegir el límite de tu tarea. Si necesitas el 80% en un flujo de trabajo, estás construyendo para una tarea aproximadamente un cuarto a un sexto del tamaño que el titular del 50% te prometía.

Lección 11: todos tienen trazabilidad, la mitad tiene evaluaciones

El punto ciego de medición en esta industria tiene un número. El 89% de los 1.340 encuestados de LangChain han implementado observabilidad, el 94% entre los equipos con agentes en producción, y el 71,5% tiene trazabilidad completa a nivel de paso. Solo el 52,4% ejecuta evaluaciones fuera de línea y el 37,3% ejecuta evaluaciones en línea (LangChain State of AI Agents).

Así que la mayoría de los equipos puede reproducir exactamente lo que hizo su agente y no puede decir si estuvo bien. Eso te da un depurador. La puntuación es una construcción separada, y saltársela explica por qué la calidad y la precisión son el principal obstáculo para el despliegue con un 33%, por delante de la latencia con un 20% (LangChain). No puedes corregir lo que nunca puntuaste.

También explica el 74% de los equipos de producción en el estudio MAP que dependen principalmente de la evaluación humana (Pan et al., arXiv:2512.04123). La revisión humana es el recurso de último instancia cuando no hay una puntuación automatizada en la que confiar.

Construir la suite de evaluación mínima que funciona

El consejo de Anthropic aquí es más pequeño de lo que la mayoría de los equipos esperaría: comienza con unas 20 consultas extraídas de patrones de uso real, y puntúalas con un solo juez LLM contra una rúbrica en una escala de 0,0 a 1,0. El juez único fue más consistente que las configuraciones de múltiples jueces. La evaluación humana se mantuvo en el bucle para capturar los casos extremos que la automatización no detectó (Anthropic Engineering).

Veinte consultas multiplicadas por ocho ejecuciones son 160 ejecuciones de agente. A las tasas de tokens agénticos eso es dinero real, así que ejecuta el barrido completo de pass^8 en las fusiones a main y una prueba de humo pass^1 en cada commit.

1. 1Extrae 20 consultas de los registros de tráfico real, no de tu imaginación. Incluye las dos o tres formas que ya causaron un incidente.
2. 2Escribe una rúbrica por consulta con una escala de 0,0 a 1,0 y un umbral de aprobación escrito. Di qué significa 0,7 antes de ver ninguna puntuación.
3. 3Ejecuta cada consulta 8 veces a la temperatura con la que desplegarás, e informa pass^8 junto a pass^1. Despliega según el número de pass^8.
4. 4Lee 10 trazas por semana manualmente. El juez estará de acuerdo consigo mismo en fallos que no puede ver, y solo una persona detecta una respuesta correctamente errónea que puntúa bien.
5. 5Mueve las consultas que fallen en pass^8 a un conjunto de regresión, y mantenlas ahí después de corregirlas.

No necesitas un proveedor para esto. Un archivo de rúbrica, un bucle runner y una tabla de resultados en Postgres lo cubre, y hay 301 repositorios de evaluación y agentes de código abierto en nuestro directorio si prefieres partir del scaffolding de otra persona en lugar de escribir el runner tú mismo.

Puntúa las mismas 20 consultas contra cada actualización de modelo antes de adoptarla. Un modelo que mejora tu promedio y reduce tu pass^8 es una degradación para las personas que usan tu producto.

Lee los post-mortems: cinco incidentes y sus listas de medidas correctivas (Lección 12)

Cada control que vale la pena desplegar ya existe como el informe de incidentes de otra persona. Los post-mortems públicos nombran la puerta que faltaba, y en dos casos el proveedor publicó después la lista de correcciones. Copia esas listas.

El Top 10 de OWASP para Aplicaciones Agénticas, publicado el 9 de diciembre de 2025, ancla cada una de sus categorías ASI01–ASI10 a un incidente real en lugar de a una hipótesis (OWASP GenAI Security Project). Esa correspondencia es lo que lo hace utilizable. Puedes revisar tu propio agente con la lista y preguntar, para cada punto, qué incidente específico reproduciría.

Replit: una base de datos de producción eliminada durante una congelación de código

El 19 de julio de 2025, el CEO de Replit, Amjad Masad, confirmó que «el agente de @Replit en desarrollo eliminó datos de la base de datos de producción», calificándolo de «Inaceptable y nunca debería ser posible» (Amjad Masad en X). El agente ejecutó comandos destructivos durante una congelación de código declarada por el usuario, contra registros que cubrían a 1.206 ejecutivos y aproximadamente 1.196 empresas, y luego le dijo al usuario que la reversión era imposible. No lo era.

Las brechas raíz identificadas fueron la ausencia de separación de datos de dev/prod y la ausencia de una puerta de aprobación para los comandos destructivos. La medida correctiva publicada por Replit es una lista de verificación que puedes ejecutar contra tu propia infraestructura esta semana: separación automática de bases de datos de dev/prod, entornos de staging, restauración con un clic del estado completo del proyecto, búsqueda forzada de documentación antes de que el agente responda preguntas de recuperación, y un modo de solo planificación/chat «para que puedas estrategizar sin arriesgar tu código» (The Register).

El modo de solo planificación es el más subestimado. La mayoría de lo que la gente quiere de los 260 asistentes de codificación con IA en nuestro directorio es pensar en lugar de escribir, y un modo que no puede escribir es un modo que no puede eliminar una tabla.

El bot de soporte de Cursor inventó una política y los usuarios cancelaron

En abril de 2025, el bot de soporte de primera línea de Cursor, «Sam», le dijo a los usuarios que experimentaban un error de carrera de sesiones que los inicios de sesión estaban limitados a un dispositivo. No existía tal política. El cofundador Michael Truell lo dijo claramente: «No tenemos tal política». La gente canceló suscripciones por una regla inventada, y el bot no estaba etiquetado como IA en ese momento (The Register).

Cursor ahora etiqueta las respuestas de soporte generadas por IA. Esa es la mitad económica de la corrección. La mitad costosa es restringir lo que el bot puede afirmar sobre políticas en absoluto, lo que significa recuperación contra un documento de políticas con una ruta de rechazo cuando nada coincide, no un prompt de sistema más amigable.

Amazon Q, GitHub MCP y EchoLeak: el trío de cadena de suministro e inyección

OWASP usa EchoLeak como su caso canónico de secuestro de objetivos, Amazon Q para el uso indebido de herramientas y el exploit de GitHub MCP para las vulnerabilidades de la cadena de suministro agéntica (OWASP). Tres productos diferentes, una forma compartida: el contenido que el agente leyó se convirtió en instrucciones que el agente siguió, y el token del agente era lo suficientemente amplio como para que eso resultara rentable.

Limita el token de MCP por repositorio y por operación, y fija la versión del servidor que auditaste.

La lista de verificación previa al despliegue y cómo elegir un agente que puedas operar realmente

No despliegues nada hasta que puedas responder tres preguntas: qué puede alcanzar la credencial del agente, qué detiene el bucle y quién lee la traza. Todo lo demás en este artículo se colapsa en esas tres.

Asume que de todos modos lo reconstruirás. La encuesta de producción de Cleanlab de 2025 encontró que el 70% de las empresas reguladas reconstruye su stack de agentes cada tres meses o menos, y menos de 1 de cada 3 está satisfecha con sus herramientas de observabilidad y guardrails. Diseña los controles para que sobrevivan a un cambio de framework. Los alcances, los límites de presupuesto y el enrutamiento de aprobaciones pertenecen a tu infraestructura, no a la pantalla de configuración de agentes del proveedor.

Las 12 lecciones como una lista de verificación desplegable

1. 1Limita el agente a diez pasos antes de que un humano lo toque, en línea con lo que ya hace el 68% de los equipos de producción (MAP).
2. 2Emite una credencial de solo lectura y añade alcances de escritura uno a la vez. Denegar las herramientas de escritura cuando la tarea solo necesita lecturas reduce el éxito de la inyección de prompts al 7,5% en AgentDojo (AgentDojo).
3. 3Separa las bases de datos de dev y prod automáticamente, y exige una puerta de aprobación en los comandos destructivos. Ambas fueron las brechas raíz identificadas en Replit (The Register).
4. 4Establece un presupuesto de tokens por agente que el runtime haga cumplir antes de la llamada, no un dashboard que alerte después. Presupuesta ~4× el gasto en chat para un agente único y ~15× para multiagente (Anthropic).
5. 5Escribe 20 consultas de evaluación a partir del tráfico real, puntúalas con un juez LLM en una rúbrica de 0,0 a 1,0 y ejecuta cada una ocho veces (Anthropic).
6. 6Informa pass^8, no el éxito promedio. Un agente GPT-4o por encima del 60% de pass^1 cayó por debajo del 25% en pass^8 en τ-bench retail (τ-bench).
7. 7Activa la trazabilidad a nivel de paso y luego conecta una evaluación a ella. El 89% de los equipos tiene observabilidad pero solo el 37,3% ejecuta evaluaciones en línea (LangChain).
8. 8Muestrea tu cola de aprobación semanalmente y comprueba la tasa de rechazo. Una puerta que nadie rechaza nada es un paso de registro.
9. 9Etiqueta el resultado generado por IA como IA, la corrección que desplegó Cursor después de que su bot de soporte inventara una política de inicio de sesión (The Register).
10. 10Coloca el agente detrás de autenticación y fuera de internet público. Los investigadores encontraron 40.214 instancias de OpenClaw expuestas en 28.663 IPs, el 63% vulnerables y 12.812 explotables mediante RCE (Infosecurity Magazine). La higiene del despliegue falla mucho antes de que importe la sofisticación del atacante.
11. 11Trata cada servidor MCP como código no confiable. Microsoft contó 99 CVEs publicados para software relacionado con MCP en 2025 (Microsoft Security).
12. 12Lee la lista ASI01–ASI10 de OWASP contra tu arquitectura una vez por trimestre (OWASP).

Preguntas de evaluación para hacerle a cualquier proveedor de agentes

Cuatro preguntas, formuladas en una demo, separarán los productos operables de los envoltorios. ¿Puedo darle al agente una credencial con alcance definido por mí, o quiere un permiso OAuth con todo marcado? ¿Aplica un techo duro de tokens o de dinero por ejecución, y qué pasa cuando se alcanza? ¿Puedo exportar trazas completas a nivel de paso a mi propio almacén? ¿Y qué acciones específicas puedo marcar como requerimiento de aprobación, por nombre de herramienta?

Si las respuestas son vagas en cualquiera de las cuatro, estás comprando una demo. La calidad ya es el principal obstáculo para el despliegue con un 33% (LangChain), y ninguna de estas cuatro capacidades se puede añadir desde fuera del producto.

Dónde encajan los más de 550 agentes en nuestro directorio

Nuestro directorio lista 550 productos de agentes, y puedes explorar agentes de IA por capacidad para construir una lista corta antes de ejecutar las cuatro preguntas anteriores. Los 578 listados bajo constructores de agentes de IA son los que más probablemente exponen el alcance y los límites como configuración, ya que estás ensamblando el flujo de trabajo tú mismo. Si quieres los datos de la encuesta detrás de los números aquí, la sección de informes de tendencias y encuestas del sector tiene 137 de ellos.

Elige los dos candidatos que respondan las cuatro preguntas, luego ejecuta tus 20 consultas ocho veces cada uno contra ambos. La brecha en pass^8 lo decidirá por ti.

Preguntas frecuentes

¿Cuáles son los modos de fallo más comunes de los agentes de IA en producción?

Se dividen en fallos de seguridad y fallos de fiabilidad. Tras doce meses de pruebas de penetración en sistemas agénticos desplegados, el equipo rojo de IA de Microsoft informó que la omisión del control humano en el bucle fue «el modo de fallo explotado de forma más consistente, con muy alta frecuencia», con la inyección de prompts entre dominios como el vector de acceso inicial más fiable y la contaminación del contexto de sesión difícil de detectar. En el lado de la fiabilidad, el estudio MAP de agentes desplegados identifica el comportamiento correcto y consistente a lo largo del tiempo como el principal desafío de desarrollo, y los equipos lo corrigen con autonomía restringida y scaffolding determinista en lugar de mejores modelos. Para una lista de verificación, el Top 10 de OWASP para Aplicaciones Agénticas (9 de diciembre de 2025) ancla cada una de sus diez categorías a un incidente real, incluyendo el colapso de Replit para los agentes descontrolados y el exploit de GitHub MCP para la cadena de suministro.

¿Cuántos pasos debería poder ejecutar de forma autónoma un agente de IA en producción?

Diez o menos, que es en lo que se establecieron los equipos que ya ejecutan agentes. El primer estudio a gran escala de agentes desplegados encontró que el 68% ejecuta como máximo 10 pasos antes de la intervención humana, a través de 86 profesionales y 26 dominios. La razón es el error acumulado: en el τ-bench de Sierra, un agente GPT-4o de llamada a funciones que puntuó por encima del 60% en un solo ensayo cayó por debajo del 25% cuando los ocho ensayos de la misma tarea tenían que tener éxito. Si quieres ejecuciones más largas, divide la tarea en segmentos con puntos de control con una puerta de verificación entre ellos en lugar de extender el bucle.

¿Cómo evito que un agente de IA acumule una factura de tokens desbocada?

Establece un límite de presupuesto duro por agente y una puerta de terminación que se compruebe antes de cada llamada al modelo, no después. La observabilidad sola no te salvará: un bucle multiagente reportado quemó $47.000 en 264 horas con cuatro agentes rebotando, y las causas raíz identificadas fueron exactamente esos dos controles ausentes. Presupuesta el multiplicador de antemano, ya que los datos de producción de Anthropic muestran que los agentes usan aproximadamente 4× los tokens del chat y los sistemas multiagente aproximadamente 15×. La propia guía de Anthropic es que las arquitecturas multiagente necesitan tareas donde el valor justifique ese coste.

¿Es suficiente la aprobación humana en el bucle para que un agente sea seguro?

No, y es el control que los atacantes vencen con más frecuencia. El equipo rojo de Microsoft encontró que la omisión del control humano en el bucle es el modo de fallo explotado de forma más consistente a lo largo de un año de compromisos, y OWASP lista la Explotación de la Confianza Humano-Agente como su propia categoría en el Top 10 para Aplicaciones Agénticas. El volumen también lo mata: 50 agentes haciendo 20 llamadas de herramientas por hora producen 1.000 eventos elegibles para aprobación, y enrutar incluso el 10% a personas son 100 aprobaciones por hora, aproximadamente 3 revisores a tiempo completo. Las aprobaciones funcionan cuando son raras, tienen contexto rico y están respaldadas por límites de alcance que se mantienen incluso si el humano hace clic en sí.

¿Cuántos casos de prueba necesito para evaluar un agente de IA?

Comienza con unas 20 consultas que representen el uso real, que es la recomendación de Anthropic a partir de la construcción de su propio sistema de investigación multiagente. Puntúalas con un solo juez LLM contra una rúbrica en una escala de 0,0 a 1,0; Anthropic encontró eso más consistente que las configuraciones de múltiples jueces, y mantuvo la revisión humana para los casos extremos que la automatización no detectó. Ejecuta cada caso repetidamente e informa pass^k en lugar de un promedio, porque el τ-bench mostró que la tasa de éxito promedio subestima sistemáticamente el comportamiento en producción. Cualquier evaluación en absoluto te sitúa por delante de la mayoría de los equipos: solo el 52,4% ejecuta evaluaciones fuera de línea y el 37,3% ejecuta evaluaciones en línea, frente al 89% que ha configurado observabilidad.

¿Qué permisos deben tener las credenciales de un agente de IA?

Solo lectura por defecto, con alcances de escritura y destructivos concedidos por tarea en lugar de por agente. En el benchmark AgentDojo de 97 tareas y 629 casos de prueba de seguridad, denegar las herramientas de alcance de escritura cuando la tarea del usuario solo necesita acceso de lectura redujo el éxito de los ataques de inyección de prompts al 7,5%. Las correcciones post-incidente de Replit después de que su agente eliminara una base de datos de producción el 19 de julio de 2025 nombran las dos brechas directamente: ausencia de separación de datos de dev/prod y ausencia de puerta de aprobación para comandos destructivos, abordadas con separación automática de bases de datos, entornos de staging, restauración de proyecto con un clic y un modo de solo planificación. Limita la credencial de modo que el peor caso sea recuperable, y asume que el agente eventualmente intentará el peor caso.