El punto de partida incómodo
Empecemos por el dato más reciente y más duro, porque condiciona todo lo demás.
En un ensayo clínico aleatorizado y simple ciego, 44 médicos resolvieron seis casos clínicos en 75 minutos. Un grupo recibió recomendaciones de IA correctas; el otro, erróneas a propósito en tres de los seis casos. Consultar a la IA era voluntario, y todos los participantes habían pasado antes por veinte horas de formación en alfabetización sobre IA.
| Indicador | Con recomendación correcta | Con recomendación errónea | Diferencia ajustada |
|---|---|---|---|
| Precisión del razonamiento diagnóstico | 84,9 % | 73,3 % | −14,0 puntos porcentuales |
| Diagnóstico situado en primer lugar | 90,5 % | 76,1 % | −18,3 puntos porcentuales |
Las dos diferencias son claramente significativas. La tercera columna es la diferencia ajustada del estudio con su intervalo de confianza (entre −8,3 y −19,7 y entre −26,6 y −10,0 puntos, respectivamente), no la resta de las dos columnas.
Por qué es la piedra angular del artículo: los participantes no eran legos y los habían preparado expresamente para los riesgos de la IA. Y aun así. Preparar a quien aprueba no basta por sí solo.
Y esto no se arregla con formación
No es un fenómeno nuevo, solo un contexto nuevo. La revisión de referencia del campo, con más de mil doscientas citas, dice tres cosas al respecto:
- la complacencia aparece cuando varias tareas compiten a la vez por la atención, es decir, justo en la situación laboral real;
- afecta por igual a usuarios expertos y novatos, y la práctica no la elimina;
- se resiste a las intervenciones formativas, tanto en el individuo como en el equipo.
Dentro hay dos tipos de error, y conviene nombrar los dos: el error por omisión (el sistema no avisó y la persona tampoco se dio cuenta) y el error por comisión (el sistema dijo algo mal y la persona lo siguió).
¿Cuántas aprobaciones hacen falta para que la aprobación deje de existir?
Para agents en concreto no hay datos medidos. Sí hay, en cambio, una analogía casi perfecta y con cifras duras: la fatiga de alertas clínicas.
Según una revisión sistemática que procesó 23 estudios, la tasa de anulación de las alertas del sistema iba del 46,2 % al 96,2 %, y solo una parte de esas anulaciones estaba justificada profesionalmente (entre el 29 % y el 100 %, según el tipo).
Lee otra vez el valor superior: 96,2 %.
Donde de cada veinticinco alertas se descartan veinticuatro, el punto de aprobación ha dejado de existir: solo queda en el registro. Formalmente todo está en orden: hay control, hay aprobación, hay rastro. En la práctica, no.
Este es el mejor argumento para tener pocos puntos de aprobación, pero reales. La pregunta no es en cuántos sitios los pones. Es si donde están se miran de verdad.
¿Dónde lo exige la norma?
Cuatro fuentes, de cuatro niveles.
La legislación. El artículo 14 del reglamento de IA de la UE exige supervisión humana para los sistemas de alto riesgo: hay que diseñarlos de modo que personas físicas puedan supervisarlos de forma efectiva mientras se usan. Quien supervisa debe poder ignorar la salida, anularla y detener el sistema.
Y hay un punto que viene al caso directamente: el reglamento menciona expresamente el sesgo de automatización; la persona encargada de la supervisión debe ser consciente de ese riesgo.
(Fechas importantes: las obligaciones para los sistemas de alto riesgo del anexo III se aplican desde el 2 de diciembre de 2027; las normas de transparencia, en cambio, están vigentes desde el 2 de agosto de 2026, y el plazo de cumplimiento para marcar el contenido sintético es el 2 de diciembre de 2026.)
El protocolo. El estándar que se usa para conectar herramientas dice que el host debe obtener el consentimiento expreso del usuario antes de invocar cualquier herramienta, y que el usuario tiene que entender qué hace esa herramienta. El mismo documento añade que a nivel de protocolo no puede imponerlo.
La lista sectorial de riesgos. La lista de riesgos de los grandes modelos de lenguaje tiene una entrada propia para el exceso de agencia, con tres causas: demasiadas funciones, demasiados permisos, demasiada autonomía. Una de sus ocho recomendaciones: pedir aprobación humana para las acciones de alto impacto. Y hay una entrada que señala como riesgo aparte que la persona confíe demasiado en el agent.
La herramienta de desarrollo. Los frameworks prácticos ofrecen un interruptor de aprobación a nivel de herramienta: o pide aprobación siempre, o lo decide una función llamada a llamada. Hay también una opción «pegajosa» que hace que la misma decisión valga para todas las llamadas siguientes, y eso es exactamente institucionalizar la complacencia. Herramienta de doble filo: es cómoda, y justo por eso el control se vuelve formal.
¿Qué hacen en la práctica?
Según una encuesta de 2026 a más de 1.300 profesionales, la mayoría de los equipos hace una de estas dos cosas: o da al agent permiso solo de lectura, o pide aprobación humana para escribir y borrar. Muy pocos dejan que el agent lea, escriba y borre libremente.
Las grandes empresas son más prudentes: se inclinan con fuerza hacia el permiso de solo lectura.
Y un dato revelador de la misma fuente: como principal obstáculo para llevarlo a producción no señalaron ni el coste ni la seguridad, sino la calidad del rendimiento, con más del doble de peso que los demás factores.
Tres sitios donde la aprobación protege de verdad
Se deduce de todo lo anterior, y los tres se remiten a un mismo principio: hace falta aprobación allí donde el error no se puede deshacer.
1. OPERACIÓN IRREVERSIBLE
Borrar, pagar, sobrescribir datos en producción,
cursar un pedido. Lo que ya no tiene botón "atrás".
2. COMUNICACIÓN HACIA FUERA
Correo, mensaje, publicación, respuesta a un cliente.
Aquí no se daña el sistema, sino la confianza — y eso
no se restaura desde una copia de seguridad.
3. AMPLIACIÓN DE PERMISOS O DE ALCANCE
Conectar una herramienta, un acceso o una regla nueva.
Es el paso que cambia también todos los demás.
El tercero es el menos evidente y el más importante. Si el agent puede ampliar él mismo su propio alcance, todos tus demás límites son provisionales.
Donde, en cambio, solo frena
Y aquí viene la otra cara, porque una aprobación mal colocada no solo es cara, sino que hace daño activamente: la tasa de anulación del 96 % de antes sale justo de ahí.
- Lectura, búsqueda, consulta. Si no cambia nada, no hay nada que aprobar.
- Un borrador que no va a salir solo. El borrador lo lees cuando lo usas; no hace falta hacerlo dos veces.
- Nota interna, etiqueta, clasificación. Reversible, barato, frecuente.
- Cambio versionado. Si hay histórico y restauración, la aprobación se sustituye por el botón de restaurar.
- Operaciones repetitivas e idénticas. Justo ahí se forma el «sí» mecánico, y a partir de ese momento el resto de tus aprobaciones también empeora.
El último punto es el más importante. Los puntos de aprobación no son independientes entre sí: si una persona hace clic en «sí» cincuenta veces al día, también hará clic en «sí» la quincuagésima primera, aunque esa sea la importante.
¿Cuánto cuesta?
Sobre cuánto frena el proceso un punto de aprobación no hay medición directa. La analogía más cercana sí es reveladora, y encima es contradictoria consigo misma.
En un experimento aleatorizado de julio de 2025, con 16 desarrolladores experimentados y 246 tareas, aleatorizando por tarea, usar IA aumentó el tiempo de finalización un 19 %. Esas mismas personas esperaban de antemano un 24 % de aceleración, y después seguían creyendo en un 20 %.
El mismo grupo lo repitió en febrero de 2026 con una muestra bastante mayor —57 desarrolladores, 143 repos, más de 800 tareas—: un 18 % de aceleración en la submuestra de los participantes originales y un 4 % en los recién reclutados.
Mismo grupo de investigación, mismo método, signo contrario con siete meses de diferencia, y ellos mismos avisan de que el segundo hay que leerlo con cuidado: entre el 30 % y el 50 % de los desarrolladores no envió tareas que no habría querido hacer sin IA, lo que supone un sesgo de selección serio.
La lección para la aprobación: el frenazo es un coste real, pero medirlo es difícil y la autoevaluación en este asunto está demostrado que es mala. Por eso conviene contar los puntos de aprobación, no intuirlos.
Malentendidos habituales
- «Si lo aprueba alguien formado, es seguro.» Los participantes del ensayo citado recibieron veinte horas de formación y aun así cayeron 14 puntos porcentuales con recomendaciones erróneas.
- «Más puntos de aprobación, más seguridad.» Al revés. Muchas preguntas generan un sí mecánico, y ese sí mecánico también estará en el punto importante.
- «Ya se acostumbrará y lo hará mejor.» Las revisiones dicen que el fenómeno afecta también a usuarios expertos y que se resiste a la formación.
- «Hay aprobación, luego hay control.» Si la tasa de anulación es del 96 %, el control existe en el registro, no en la realidad.
- «El agent solo lee, no hace falta aprobación.» Hasta que puede conectar una herramienta nueva o conseguir un permiso. Ese paso pasa por encima de todo lo demás.
- «La aprobación frena, así que es cara.» Puede ser, pero no hay medición de eso, y el mejor dato aproximado sobre la misma pregunta cambió de signo en siete meses.
Lo que conviene llevarse
La aprobación no es una cuestión de cantidad, sino de colocación.
Ponla en tres sitios: operación irreversible, comunicación hacia fuera, ampliación de alcance. Son los tres donde el error ya no se puede arreglar después.
Quítala de todos los demás. No por comodidad, sino porque cada aprobación superflua empeora la calidad de las que quedan.
Y un indicador que merece la pena llevar: qué proporción se aprueba. Si se mantiene por encima del 95 %, lo que tienes no es un control, sino un ritual. En ese caso, o el punto está mal colocado, o tienes demasiados.
Cuántos permisos debería tener el agent —y por qué el alcance es el límite más importante— lo cuenta con incidentes documentados el post el agente con los permisos mínimos , uno a uno; y la relación entre el número de pasos y la fiabilidad la calcula el post la matemática de la fiabilidad con tablas propias.