Imaginá el panel de aprobaciones de un agente un martes a la mañana. Cada vez que el agente quiere hacer algo, aparece un pedido: leer este archivo, correr este comando, actualizar este registro. La persona de guardia lee los primeros con cuidado. Para el mediodía ya aprueba con un clic, porque casi todo estaba bien. Si entre esos pedidos aparece uno malo, ¿lo frena?
Sobre las personas en el circuito hay creencias opuestas. Una dice que, si una persona aprueba cada acción del agente, el riesgo está controlado. También dice que una persona es más segura que un clasificador, un modelo que aprueba o frena acciones. Otra creencia dice lo contrario: si el agente ya acierta casi siempre, la revisión humana sobra. Las dos tratan a la persona como un interruptor. Pero una persona tiene atención limitada.
Hay una tercera creencia, más callada. Si el agente resuelve una tarea solo, también la resuelve cuando el cliente tiene que hacer su parte. En soporte, muchas tareas son así.
La supervisión humana es la norma en los equipos con agentes en producción. “Measuring Agents in Production” (la prueba 29) estudió 20 casos y encuestó a 86 practicantes de 26 dominios. El 74 % depende sobre todo de evaluación humana. El 68 % deja correr al agente como máximo 10 pasos antes de que intervenga una persona.
La regla de dos de Meta (la prueba 12) también usa a la persona como salida. Si la tarea combina contenido no confiable, datos sensibles y acciones hacia afuera, el agente no corre solo.
Un equipo de un SaaS mediano contó en Reddit cómo armó un agente de triage de soporte (la prueba 99). Triage es clasificar los pedidos y decidir quién los atiende. El equipo empezó por contraseñas y facturación. Durante los primeros 30 días, las personas revisaron el 100 % de las respuestas. La primera versión sin revisión inventó una función que no existía.
A los 90 días, el agente resolvía el 47 % de los tickets sin nadie. Redactaba otro 22 % que enviaba una persona. Son números autoinformados en un hilo chico.
47 % y 22 %
Tickets resueltos sin persona, y tickets redactados por el agente y enviados por una persona, a los 90 días. Prueba 99
La idea de que la revisión sobra tiene su mejor versión en dotnet/runtime. Stephen Toub, ingeniero de Microsoft, publicó diez meses de datos del agente de Copilot en ese repositorio (la prueba 68). El agente abrió 878 pull requests, es decir, propuestas de cambio al código. El 67,9 % salió bien. Los aceptados casi no se revirtieron después: 0,6 %, contra 0,8 % del resto.
El autor de un hilo de Hacker News ve un empuje a revisar poco o nada el código de agentes (la prueba 43). La consigna es: si pasan los tests, publicá. Si el agente rompe menos que las personas, ¿para qué revisar todo?
El autor de un juego compartió sus números en Hacker News (la prueba 122). En el juego, la gente aprueba o rechaza comandos de un agente. Hubo más de 40.000 partidas y 409.000 decisiones. Los jugadores aprobaron una de cada tres amenazas, aun con una advertencia al empezar.
El hilo lo leyó como fatiga de decisión: si una persona aprueba todo, deja de leer. Es un juego, sin consecuencias reales y con reloj.
Además, la persona interviene cada vez menos. Dentro de Anthropic (la prueba 28), el agente de código pasó de 9,8 a 21,2 llamadas seguidas a herramientas. Fue entre febrero y agosto de 2025. Los turnos humanos bajaron de 6,2 a 4,1.
Si una persona aprueba cada acción del agente, el riesgo está controlado.
Veredicto: No por sí sola. En más de 40.000 partidas de un juego, la gente aprobó una de cada tres amenazas. Pasó aun con una advertencia al empezar. Cuando todo pasa por una persona, deja de leer. Y la persona interviene cada vez menos. En un laboratorio de IA, el agente de código pasó de 9,8 a 21,2 llamadas seguidas a herramientas. Ese cambio llevó seis meses de 2025. La aprobación sirve si queda para pocas acciones destructivas, después de aislar al agente.
Criterio
Aislá primero y dejá la aprobación para pocas acciones irreversibles. Atá cada aprobación a la acción exacta, con sus parámetros, y hacé que venza y sirva una sola vez. Ante la duda, bloqueá.
Por qué confianza media. El dato de las amenazas viene de un juego sin consecuencias reales y con reloj, comentado en Hacker News. OWASP pide aprobación humana para lo destructivo. La regla de dos y el estudio de producción muestran que la supervisión es la norma. Pero no miden cuánto protege. Atar la aprobación a la acción exacta, con vencimiento y un solo uso, es una regla de diseño de este sitio. Ninguna fuente de la base la mide.
Ver el detalle de las 5 pruebasOcultar el detalle2 a favor, 1 en contra, 2 matizan
Regla de diseño: en una misma sesión, un agente debe tener como máximo dos de estas tres propiedades. Una, procesar entrada no confiable. Dos, acceder a datos o sistemas sensibles. Tres, cambiar estado (modificar algo) o comunicarse hacia afuera. Si la tarea necesita las tres, el agente no debe correr solo: necesita supervisión humana.
Números
2 de 3Propiedades que un agente puede combinar en una sesión sin supervisión humana.
Limitación En Hacker News, un coautor la llamó un piso mínimo y no un estándar suficiente. Otros críticos señalan que cambiar estado sin comunicar afuera también puede hacer daño. También dicen que poner a una persona a aprobar muchas acciones baja su atención.
“no more than two of the following three properties within a session”
Estudio de casos y encuesta a profesionales que tienen agentes en producción. La mayoría evalúa con personas y no con benchmarks (pruebas estándar), y deja pocos pasos al agente antes de que intervenga alguien. La confiabilidad, es decir, que el agente se comporte bien de forma sostenida, sigue siendo el principal desafío. Los equipos la atacan con diseño del sistema.
Números
20 casos y 86 practicantesBase del estudio: 20 entrevistas en profundidad y una encuesta a practicantes de 26 dominios.
74 %Depende sobre todo de evaluación humana.
68 %Corre como máximo 10 pasos antes de que intervenga una persona.
70 %Usa modelos comerciales con prompts en vez de reentrenarlos.
Limitación Muestra chica y elegida por los autores; no representa a todas las empresas. Preprint.
“Reliability (consistent correct behavior over time) remains the top development challenge”
En un juego, la gente aprueba o rechaza comandos de un agente, y su autor comparte los números. Aun con una advertencia al empezar, los jugadores aprobaron una de cada tres amenazas. El hilo lo lee como fatiga de decisión: si una persona aprueba todo, deja de leer. Proponen aislar primero al agente y reservar la aprobación para pocas acciones.
Números
1 de cada 3Amenazas que los jugadores aprobaron sin detectar.
más de 40.000 partidas y 409.000 decisionesBase de los números.
340 puntos y 245 comentariosTamaño del hilo.
Limitación Es un juego, no un estudio revisado por pares: no hay consecuencias reales y hay reloj. Se leyó en news.ycombinator.com y en la API pública de Algolia. Las citas del hilo no se cotejaron palabra por palabra en la verificación de origen y por eso no se usan.
Es la primera lista de consenso de OWASP hecha para agentes. Los diez riesgos van desde el secuestro del objetivo del agente (ASI01) hasta los agentes rebeldes (ASI10). Entre ellos están el mal uso de herramientas (ASI02) y el abuso de identidad y privilegios (ASI03). También están la cadena de suministro agéntica (ASI04) y las fallas en cascada (ASI08). Suma el principio de mínima agencia: no dar autonomía que no hace falta. Como mitigaciones pide perfiles de mínimo privilegio por herramienta, aprobación humana para acciones destructivas y controles fuera del modelo. También pide topes de costo, tasa o tokens con corte automático.
Números
10 riesgos (ASI01 a ASI10)Tamaño de la lista. ASI02 y ASI03 extienden la agencia excesiva (LLM06) de la lista de 2025 a flujos de varios pasos.
Limitación Es un marco voluntario de consenso: no obliga a nadie y no mide nada. En la lista de agentes, el consumo sin límites ya no es un ítem propio: aparece como escenario y mitigación dentro de ASI02. Se leyó el PDF completo (57 páginas).
“deploying agentic behavior where it is not needed expands the attack surface”
Huang, S., Seethor, B., Durmus, E., Handa, K., McCain, M., Stern, M., Ganguli, D. Anthropic
Dentro del propio laboratorio, la gente usa Claude en más trabajo y dice ser más productiva. Pero solo puede delegar del todo una parte chica. Los agentes encadenan más acciones con menos intervención humana. Preocupa perder justamente las habilidades que hacen falta para supervisar a la IA, y cómo van a aprender los perfiles junior.
Números
de 0 % a 20 %Parte del trabajo que la mayoría puede delegar del todo.
59 % y +50 %Trabajo en el que usan Claude (28 % un año antes) y productividad autorreportada (+20 % un año antes), en 132 encuestados.
de 9,8 a 21,2 llamadasLlamadas a herramientas seguidas del agente de código entre febrero y agosto de 2025; los turnos humanos bajaron de 6,2 a 4,1.
Limitación Autorreporte de empleados del proveedor, con datos de 2025 (encuesta de agosto de 2025, 53 entrevistas y 200.000 transcripciones).
“I am for sure atrophying in my skills as a software engineer”
Cita verificada contra el original
Leída en la fuente. Revisada el 2 nov 2026.
¿Y un clasificador lo hace mejor? Anthropic publicó un estudio sobre auto mode, su modo con clasificador (la prueba 123). Las personas frenaron 13,6 % de los comandos peligrosos. El clasificador, con los mismos comandos, frenaba 89 %. Después de más de 50 pedidos, las personas bajaron de cerca de 17 % a cerca de 5 %.
Comandos peligrosos que frenaron las personas (143 de 1.053) y que habría frenado el clasificador (937 de 1.053). Las personas bajan de cerca de 17 % a cerca de 5 % después de más de 50 pedidos.Prueba 123
Comandos peligrosos frenados, en %
Personas13,6 %
Clasificador89 %
0100 %
El sistema de Anthropic marcó algunas sesiones de usuarios para revisión. Ahí aparecieron acciones dañinas de nivel producción que nadie pidió. Fueron 6,3 % con aprobación manual y 2,4 % con auto mode. Lo publica el proveedor que vende el clasificador. El estudio con personas fue en un entorno controlado.
Anthropic hizo de auto mode el modo por defecto de su agente de código. Un hilo de Hacker News se partió en dos (la prueba 124). El comentario con más respuestas rechazó usar otro modelo para clasificar los comandos del primero. Pero tampoco defendió la aprobación manual.
Para ese comentario, revisar comandos uno por uno no hace segura a la herramienta. La seguridad la ponen controles como el control de versiones o los tokens de solo lectura. Un token es una clave de acceso. Otros corren el agente sin permisos dentro de un contenedor, un entorno aislado.
Una persona que aprueba cada comando es más segura que un clasificador automático.
Veredicto: En los datos que hay, no. En un estudio del proveedor, las personas frenaron 13,6 % de los comandos peligrosos. El clasificador habría frenado 89 %. Después de más de 50 pedidos, las personas bajaron de cerca de 17 % a cerca de 5 %. Pero ninguno de los dos es la seguridad de fondo. Esa seguridad la ponen controles fuera del agente, como tokens de solo lectura o un contenedor sin permisos.
Criterio
No cuentes la aprobación manual de cada comando como tu control principal. Tampoco la reemplaces por otro modelo y listo. Poné primero límites que el agente no pueda saltar, como permisos de solo lectura, un contenedor o control de versiones. Después medí qué frenan la persona y el clasificador.
Por qué confianza baja. La comparación entre personas y clasificador la publica el proveedor que vende el clasificador. El estudio se hizo en un entorno controlado. El juego confirma que la gente aprueba amenazas, pero sin consecuencias reales. Ninguna fuente de la base defiende con datos que la persona sea más segura. El hilo de Hacker News desconfía del clasificador. Pero tampoco cuenta la aprobación manual como la seguridad de fondo.
Ver el detalle de las 3 pruebasOcultar el detalle0 a favor, 2 en contra, 1 matiza
Un clasificador revisa cada llamada a herramienta en lugar de pedir aprobación por cada acción. Bloquea lo irreversible, lo destructivo o lo que apunta fuera del entorno del usuario, y siempre rechaza la filtración de datos. Si se acumulan bloqueos, vuelve a la aprobación manual. En un estudio, las personas aprobaron casi todo lo peligroso y con el tiempo se cansaban. El clasificador frenó mucho más.
Números
13,6 % contra 89 %Comandos peligrosos que frenaron las personas (143 de 1.053) y que habría frenado el clasificador (937 de 1.053). Las personas bajan de cerca de 17 % a cerca de 5 % después de más de 50 pedidos.
0 de 720Inyecciones indirectas exitosas contra tres modelos de Claude en auto mode, en una evaluación encargada a un tercero. Otro agente con revisión automática: 5,83 %; con acceso total: 19,03 %.
de 12 % a 7 %Ataques que el clasificador deja pasar en un ejercicio de ataque, antes y después de endurecerlo. La fuente dice que no es la tasa sobre tráfico real.
6,3 % contra 2,4 %Sesiones con una acción dañina no pedida de nivel producción (severidad 7 o más), con aprobación manual y en auto mode. Son sesiones de mayo y junio de 2026 que el sistema de seguridad marcó para revisión, de cuentas que aceptaron compartir sus datos.
Limitación Lo publica el proveedor que vende el producto, y la evaluación la encargó él. Los ataques se optimizaron contra otro modelo. El estudio con personas fue en un entorno controlado. Hay una nota de actualización del 22 de octubre de 2026.
“it relies on classification systems and therefore does not eliminate risk”
En un juego, la gente aprueba o rechaza comandos de un agente, y su autor comparte los números. Aun con una advertencia al empezar, los jugadores aprobaron una de cada tres amenazas. El hilo lo lee como fatiga de decisión: si una persona aprueba todo, deja de leer. Proponen aislar primero al agente y reservar la aprobación para pocas acciones.
Números
1 de cada 3Amenazas que los jugadores aprobaron sin detectar.
más de 40.000 partidas y 409.000 decisionesBase de los números.
340 puntos y 245 comentariosTamaño del hilo.
Limitación Es un juego, no un estudio revisado por pares: no hay consecuencias reales y hay reloj. Se leyó en news.ycombinator.com y en la API pública de Algolia. Las citas del hilo no se cotejaron palabra por palabra en la verificación de origen y por eso no se usan.
La discusión se parte en dos. El comentario con más respuestas dice que ni revisar comandos uno por uno ni usar otro modelo para clasificarlos hacen segura a la herramienta. La seguridad la ponen controles del desarrollador, como control de versiones, sistemas de archivos inmutables o tokens de solo lectura. Otros corren el agente sin pedidos de permiso dentro de un contenedor. Uno dice que, con decenas de agentes en paralelo, aprobar a mano no escala.
Números
292 puntos y 313 comentariosTamaño del hilo al 2 de noviembre de 2026; el comentario principal tiene 104 respuestas.
Limitación Opiniones de practicantes, no una medición. Se leyó con la API de Algolia (los 12 hilos con más respuestas).
“Using more Claude to categorize the safety of Claude commands is not the answer.”
Cita verificada contra el original
Leída en la fuente. Revisada el 2 nov 2026.
Sobre la revisión que sobra, los datos completos de dotnet/runtime cuentan otra historia. Algunos pull requests del agente tenían commits de una persona. Un commit es un cambio guardado en el repositorio. Con esos commits, el éxito fue 86,2 %. Sin ellos, 55,1 %.
Toub atribuye a la revisión experta que casi no se reviertan: “we cannot compromise on review quality, on expert and experienced eyes validating the changes”. Nueve pull requests que Toub abrió con el agente en un rato le generaron de 5 a 9 horas de revisión.
METR, un instituto que evalúa modelos de IA, sumó otra pieza (la prueba 67). Cuatro mantenedores de scikit-learn, Sphinx y pytest revisaron pull requests de agentes. Los mantenedores deciden qué cambios entran a un proyecto. Esos pull requests ya pasaban el corrector automático. Cerca de la mitad no se habría integrado.
Un ingeniero contó en Reddit que automatizó cerca del 80 % de su trabajo con un agente de código (la prueba 79). Dice que la calidad se mantiene porque revisa todos los cambios. Le dedica de 2 a 3 horas por día. Un comentarista contó lo contrario: cuando sacó la revisión, la calidad se degradó en una semana.
Cuando el agente ya acierta casi siempre, la revisión humana sobra.
Veredicto: No: buena parte de lo que acierta el agente pasa por personas. En dotnet/runtime, los pull requests del agente con commits de una persona tuvieron 86,2 % de éxito. Sin esos commits tuvieron 55,1 %. Mantenedores revisaron pull requests de agentes que pasaban el corrector automático. Cerca de la mitad no se habría integrado. Un comentarista cuenta que, sin revisión, la calidad se degradó en una semana.
Criterio
No saques la revisión porque los números se ven bien: los números son buenos por la revisión. Si querés aflojarla, hacelo por tipo de tarea, donde tests y compiladores ya verifican el resultado. Después medí cuántos cambios se revierten.
Por qué confianza media. Los datos de dotnet/runtime son de un solo repositorio con revisores muy expertos, publicados por un ingeniero del proveedor de la herramienta. La revisión de mantenedores es una nota de investigación con cuatro personas y tres repositorios. El relato de Reddit es de una persona. Todo es sobre código, donde hay tests que verifican.
Ver el detalle de las 5 pruebasOcultar el detalle0 a favor, 3 en contra, 2 matizan
Diez meses de datos del agente de código de Copilot en el repositorio dotnet/runtime. Más de la mitad de sus pull requests se aceptaron y casi no se revirtieron, porque cada uno pasó por revisión experta. Rindió mejor en tareas mecánicas y acotadas (limpieza, tests) y peor en las que piden juicio (rendimiento). Un archivo de instrucciones y la configuración del build casi duplicaron el éxito. El cuello de botella pasó de escribir código a revisarlo.
Números
878 PR, 67,9 % de éxitoPull requests del agente y tasa de éxito (87,1 % en los PR de personas de Microsoft; poblaciones no comparables).
0,6 % contra 0,8 %PR aceptados que después se revirtieron: del agente contra el resto.
de 38,1 % a 69 %Éxito antes y después de agregar instrucciones y configurar el build.
86,2 % contra 55,1 %Éxito con commits de una persona en el PR y sin ellos.
de 5 a 9 horasRevisión que generaron nueve PR abiertos por el autor en un rato.
Limitación Lo escribe un ingeniero de Microsoft sobre una herramienta de Microsoft. Es un repositorio con revisores muy expertos. El propio autor aclara que el agente y las personas no hacen el mismo tipo de tareas.
“we cannot compromise on review quality, on expert and experienced eyes validating the changes”
Cuatro mantenedores de scikit-learn, Sphinx y pytest revisaron pull requests de agentes que ya pasaban el corrector automático de SWE-bench Verified. Cerca de la mitad no se integraría. En los modelos nuevos, las fallas se corrieron hacia la calidad del código más que hacia funciones rotas. Los autores aclaran que no prueba un límite de capacidad: el agente tuvo un solo intento, sin poder iterar con el revisor.
Números
24,2 puntosCuánto más da el corrector automático que los mantenedores, normalizado contra pull requests humanos (error estándar 2,7). Sin normalizar, 34,9 puntos.
296 pull requests de agentesRevisados, junto con 47 humanos de referencia, en 95 de los 500 problemas. Los mantenedores integraron cerca de 68 % de los humanos.
unos 50 contra unos 8 minutosHorizonte de Claude Sonnet 4.5 con el corrector automático y con revisión de mantenedores; los autores dicen que esta cifra es muy ruidosa.
Limitación Nota de investigación, no paper revisado. Cuatro mantenedores y tres repositorios. Modelos desde Claude 3.5 Sonnet hasta Claude Sonnet 4.5 y GPT-5.
“roughly half of test-passing SWE-bench Verified PRs”
Un ingeniero con 11 años de experiencia cuenta que automatizó cerca del 80 % de su trabajo con un agente de código. El agente toma los issues y abre pull requests. Dice que la calidad se mantiene porque revisa todos los cambios. Le dedica 2 a 3 horas por día a revisar y probar. Un comentarista cuenta que, al sacar la revisión, la calidad se degradó en una semana. Otros discuten la ética de hacerlo a escondidas del empleador.
Números
cerca del 80 %Parte del trabajo que el autor dice haber automatizado.
2 a 3 horas por díaTiempo que dedica a revisar y probar.
1.200 puntos y 276 comentariosTamaño del hilo según el archivo.
Limitación Relato de una persona, con una semana de uso al momento del post. Los comentarios señalan que funciona porque el trabajo es simple. Se leyó en el archivo público Arctic Shift porque reddit.com bloquea la lectura automática. La cita se comparó letra por letra con el original.
Quien manda código tiene que mostrar que funciona: probarlo a mano y dejar tests automáticos que fallen si se revierte el cambio. A los agentes de código se les pide lo mismo, y la persona sigue siendo la responsable de lo que entrega.
Números
859 puntos y 658 comentariosTamaño de la discusión en Hacker News (item 46313297).
Limitación Ensayo de opinión de un especialista, sin datos propios.
“Your job is to deliver code you have proven to work.”
El autor ve un empuje a revisar poco o nada el código ("si pasan los tests, publicá"). En su código existente, la mitad del tiempo se le iba en arreglar errores sutiles. Quienes cuentan éxitos coinciden en las condiciones: código ya ordenado por personas, tipos estáticos, tests amplios, tareas acotadas y revisar el plan antes. Uno cuenta que el agente escribió tests que no probaban nada.
Números
461 puntos y 455 comentariosTamaño del hilo.
Limitación Opiniones de practicantes. Se leyó con la API de Algolia (post y respuestas de primer nivel con más respuestas).
Leída en la fuente. Revisada el 2 nov 2026.
Queda la tercera creencia. RealUserSim es un preprint de Salesforce, un estudio sin revisión de pares (la prueba 76). Mostró que los usuarios que simula un modelo son demasiado formales y cooperativos. Con usuarios más realistas aparecen fallas que el usuario cooperativo escondía. Pero el éxito baja poco: entre 3,2 % y 3,5 % en promedio.
τ-Knowledge (la prueba 63) es de un equipo de Sierra, que vende agentes de atención al cliente. Armó un dominio de atención de una fintech, una empresa de servicios financieros digitales. La mejor tasa de acierto fue 25,52 % en un intento. Acertar en los cuatro intentos de la misma tarea bajó a 13,40 %.
Ninguna fuente de la base mide hoy un agente que guía al cliente para que actúe sobre el sistema.
Si el agente resuelve la tarea solo, también la resuelve cuando el cliente tiene que hacer su parte.
Veredicto: No hay que darlo por hecho. Los usuarios que simula un modelo son demasiado formales y cooperativos. Con usuarios más realistas aparecen fallas escondidas, aunque el éxito baja poco: entre 3,2 % y 3,5 %. En atención al cliente de una fintech, la mejor tasa de acierto fue 25,52 % en un intento. En los cuatro intentos fue 13,40 %, con configuraciones distintas. Un caso de soporte que funcionó pasa a una persona lo que no cierra con confianza.
Criterio
Probá el agente con personas reales o con usuarios simulados que no colaboran del todo. Hacelo sobre todo en los casos donde el cliente tiene que hacer algo de su lado. Dejá un camino rápido hacia una persona para cuando el cliente se traba.
Por qué confianza baja. Ninguna fuente de la base mide hoy un agente que guía al usuario para que actúe sobre el sistema. Los dos benchmarks (pruebas estándar) usan usuarios simulados y son preprints, es decir, artículos sin revisión de pares. Uno es de una empresa que vende agentes de atención al cliente. El caso de soporte es autoinformado en un hilo chico.
Ver el detalle de las 3 pruebasOcultar el detalle0 a favor, 2 en contra, 1 matiza
Zhu, M., Tan, J., Murthy, R., et al. arXiv (Salesforce AI Research)
Los usuarios simulados con un modelo son demasiado formales y cooperativos, y no se parecen a los usuarios reales. Los autores arman simuladores con perfiles de comportamiento sacados de conversaciones reales. Con usuarios más realistas aparecen fallas del agente que el usuario cooperativo escondía. Además, baja el éxito en TauBench, una prueba estándar para agentes.
Números
7.275 perfilesPerfiles de comportamiento sacados de más de 14.000 conversaciones reales (WildChat).
de 24,2 % a 45,3 %Coincidencia de estilo con usuarios reales, sin y con el método. Sin restricciones, los simuladores coinciden de 6 % a 8 %.
de 3,2 % a 3,5 %Caída promedio del éxito del agente en TauBench con usuarios realistas.
Limitación Preprint; se leyó el resumen. La página de arXiv muestra envío el 7 de abril de 2026, aunque el número corresponde a mayo. La caída medida es chica. No repite la medición de un agente que guía al usuario.
Shi, Q., Zytek, A., Razavi, P., Narasimhan, K., Barres, V. arXiv (Sierra, Princeton)
El equipo de τ-bench suma un dominio nuevo: atención al cliente de una fintech, con unos 700 documentos de conocimiento enlazados. Aun los mejores modelos, con mucho razonamiento, resuelven cerca de un cuarto de las tareas. Además, la confiabilidad cae cuando repiten la misma tarea. Es parte de τ³-bench.
Números
25,52 %Mejor tasa de acierto en un intento (pass^1) con búsqueda realista: GPT-5.2 con razonamiento alto, sobre 97 tareas.
13,40 %Mejor tasa de acierto en los 4 intentos (pass^4).
39,69 % y 26,80 %Claude 4.5 Opus con los documentos correctos ya dados: pass^1 y pass^4.
Limitación Preprint de un equipo de una empresa que vende agentes de atención al cliente. Benchmark con usuario simulado.
Un SaaS mediano cuenta cómo armó un agente de triage de soporte, que clasifica los pedidos y decide quién los atiende. Empezó por contraseñas y facturación. El agente solo responde si puede citar un artículo o un dato de la base. Las personas revisaron el 100 % de las respuestas los primeros 30 días. Reembolsos, cancelaciones, clientes grandes y respuestas con poca confianza pasan a una persona. La primera versión sin revisión inventó una función que no existía. El equipo no se achicó: pasó a los casos difíciles.
Números
47 % y 22 %Tickets resueltos sin persona, y tickets redactados por el agente y enviados por una persona, a los 90 días.
0,18 contra unos 3,50 dólaresCosto por ticket con el agente contra el costo humano anterior.
0,85Umbral de confianza: debajo, la respuesta va a una persona.
Limitación Números autoinformados en un hilo chico (3 puntos y 7 comentarios en el archivo), sin verificación independiente. Se leyó el texto original del post en el archivo público Arctic Shift porque reddit.com bloquea la lectura automática.
Una persona en el circuito controla el riesgo si la ponés donde puede prestar atención.Si aprueba todo, aprueba también lo malo. Si revisa lo que importa, sostiene los buenos números del agente.
Aprobar cada acción da tranquilidad sin control. Sacar la revisión porque los números se ven bien olvida de dónde salen esos números. Cambiar a la persona por un clasificador frena más, según el proveedor, pero tampoco es la cerradura. La cerradura es lo que el agente no puede saltar.
Los practicantes proponen repartir las acciones en tres niveles: automáticas, a confirmar por una persona y prohibidas. El equipo de soporte de la prueba 99 manda a una persona estos casos:
Los reembolsos.
Las cancelaciones.
Los clientes grandes.
Toda respuesta con confianza debajo de 0,85.
OWASP es una fundación de seguridad de software. Su lista para agentes (la prueba 33) pide aprobación humana para lo destructivo y controles fuera del modelo.
Los niveles tienen dos trampas. La primera: si viven solo en el prompt, no son un control. Así leyó un hilo el caso del agente que borró la base de producción (la prueba 91). Está en el capítulo 5.
La segunda trampa: los niveles se corren. Un hilo de Reddit discutió quién responde por un agente (la prueba 104). Un comentarista dio un número. Según él, cerca del 40 % de las acciones pasa de confirmar a automática en unas tres semanas. El dato no tiene método, pero la deriva es fácil de ver.
Este sitio propone una regla de diseño: atar cada aprobación a la acción exacta, con sus parámetros. La aprobación vence y sirve una sola vez. La regla sale de la fatiga y de la deriva que muestran las pruebas. Pero ninguna fuente de la base mide cuánto protege.
Alcanza con separar las acciones del agente en automáticas, a confirmar y prohibidas.
Veredicto: Es un buen punto de partida si los niveles se hacen cumplir fuera del modelo. Una regla que solo vive en el prompt no es un control. OWASP pide lo mismo, con aprobación humana para lo destructivo. Un equipo de soporte manda a una persona los reembolsos y las cancelaciones. También manda toda respuesta con confianza debajo de 0,85. Pero los niveles se corren. Según un comentarista, cerca del 40 % de las acciones pasa a automática en unas tres semanas.
Criterio
Escribí la política en tres niveles y hacela cumplir en una capa que no sea el modelo. Registrá por qué el agente eligió cada acción y revisá cada mes qué acciones cambiaron de nivel.
Por qué confianza baja. OWASP es un marco voluntario de consenso que no mide. El resto viene de Reddit y Hacker News: hilos chicos, cifras autoinformadas y un 40 % sin método.
Ver el detalle de las 4 pruebasOcultar el detalle2 a favor, 1 en contra, 1 matiza
Un SaaS mediano cuenta cómo armó un agente de triage de soporte, que clasifica los pedidos y decide quién los atiende. Empezó por contraseñas y facturación. El agente solo responde si puede citar un artículo o un dato de la base. Las personas revisaron el 100 % de las respuestas los primeros 30 días. Reembolsos, cancelaciones, clientes grandes y respuestas con poca confianza pasan a una persona. La primera versión sin revisión inventó una función que no existía. El equipo no se achicó: pasó a los casos difíciles.
Números
47 % y 22 %Tickets resueltos sin persona, y tickets redactados por el agente y enviados por una persona, a los 90 días.
0,18 contra unos 3,50 dólaresCosto por ticket con el agente contra el costo humano anterior.
0,85Umbral de confianza: debajo, la respuesta va a una persona.
Limitación Números autoinformados en un hilo chico (3 puntos y 7 comentarios en el archivo), sin verificación independiente. Se leyó el texto original del post en el archivo público Arctic Shift porque reddit.com bloquea la lectura automática.
Es la primera lista de consenso de OWASP hecha para agentes. Los diez riesgos van desde el secuestro del objetivo del agente (ASI01) hasta los agentes rebeldes (ASI10). Entre ellos están el mal uso de herramientas (ASI02) y el abuso de identidad y privilegios (ASI03). También están la cadena de suministro agéntica (ASI04) y las fallas en cascada (ASI08). Suma el principio de mínima agencia: no dar autonomía que no hace falta. Como mitigaciones pide perfiles de mínimo privilegio por herramienta, aprobación humana para acciones destructivas y controles fuera del modelo. También pide topes de costo, tasa o tokens con corte automático.
Números
10 riesgos (ASI01 a ASI10)Tamaño de la lista. ASI02 y ASI03 extienden la agencia excesiva (LLM06) de la lista de 2025 a flujos de varios pasos.
Limitación Es un marco voluntario de consenso: no obliga a nadie y no mide nada. En la lista de agentes, el consumo sin límites ya no es un ítem propio: aparece como escenario y mitigación dentro de ASI02. Se leyó el PDF completo (57 páginas).
“deploying agentic behavior where it is not needed expands the attack surface”
Hilo sobre un agente de código que borró en unos 9 segundos un volumen con la base de producción y sus backups. Usó un token con más permisos de los necesarios, y los datos se recuperaron en parte. Para la mayoría, la causa es una falla de permisos y de diseño de backups, no una “IA rebelde”. Una regla en el prompt no es un control: proponen credenciales mínimas, backups en otra cuenta y protecciones fuera del alcance del agente.
Números
unos 9 segundosTiempo del borrado, según el relato del afectado.
860 puntos y 1.032 comentariosTamaño del hilo.
Limitación Los detalles técnicos son los del afectado; no hay una investigación independiente. Se leyó en news.ycombinator.com y en la API pública de Algolia. Las citas del hilo no se cotejaron palabra por palabra y por eso no se usan.
Hilo sobre quién responde por lo que hace un agente. Un comentario propone tres niveles de acción: automática, con confirmación de una persona y prohibida (por ejemplo, pagar o borrar datos). También cuenta que los umbrales se corren. Después de unas tres semanas, los operadores pasan cerca del 40 % de las acciones de confirmar a automáticas. Hay que vigilar esa deriva. Otro comentario pide registrar por qué el agente eligió cada acción.
Números
40 % en unas tres semanasAcciones que pasan de confirmar a automáticas, según un comentarista.
Limitación Hilo con muy poco puntaje (0 puntos y 16 comentarios en el archivo). El dato del 40 % es de un comentario, sin método. Se leyó en el archivo público Arctic Shift porque reddit.com bloquea la lectura automática. La cita se comparó letra por letra con el original.
“Capability without visibility into why it chose action X”
Poné a la persona donde su atención cambia el resultado, y hacé cumplir los límites fuera del modelo. Ahora:
Aislá primero, antes de pensar en aprobaciones. Dale al agente permisos de solo lectura, un contenedor o control de versiones. Aplicá la regla de dos del capítulo 5.
Escribí la política de acciones en tres niveles. Hacela cumplir en una capa que no sea el modelo.
Dejá la aprobación humana para pocas acciones irreversibles. Atá cada aprobación a la acción exacta, y hacé que venza y sirva una sola vez. Ante la duda, bloqueá.
Medí qué frenan la persona y el clasificador. Registrá por qué el agente eligió cada acción. Revisá cada mes qué acciones cambiaron de nivel.
No saques la revisión porque los números se ven bien. Si querés aflojarla, hacelo por tipo de tarea, donde tests y compiladores ya revisan el resultado. Medí cuántos cambios se revierten.
Si el cliente tiene que hacer algo de su lado, probá el agente con usuarios que no colaboren del todo. Dejá un camino rápido hacia una persona.
Si algo sale mal igual, el runbook de incidente, una guía para emergencias, ordena los primeros pasos.