Dónde necesitan los agentes de IA una aprobación humana

01Los agentes actúan, y eso cambia la pregunta

Un asistente conversacional redacta un texto y una persona decide qué hacer con él. Un agente va más allá: invoca herramientas. Actualiza un registro, reserva una cita, deriva un expediente, envía un mensaje o prepara un pago. En cuanto el software ejecuta acciones, la pregunta útil ya no es solo «¿es buena esta respuesta?», sino «¿quién responde de esta acción y cuándo dio su conformidad?».

La comunidad de seguridad tiene un nombre para cuando esto sale mal. El OWASP Top 10 para aplicaciones de modelos de lenguaje de gran tamaño recoge la agencia excesiva (se abre en un sitio externo) como un riesgo central: un agente con más funciones, más permisos o más autonomía de los que exige su tarea. La aprobación humana es uno de los controles. Si se aplica en todas partes, ralentiza el trabajo y acostumbra a la gente a pulsar «aprobar». Si no se aplica en ninguna, deja acciones que nadie ha decidido. El trabajo está en saber dónde colocarla.

02Empiece por las acciones, no por el modelo

Haga un inventario de todas las herramientas que el agente puede invocar. Para cada una, responda a cuatro preguntas. Se refieren deliberadamente a la acción y a su efecto, no al modelo.

1. 01¿Se puede deshacer? ¿Y a qué coste: un clic, una carta de rectificación, un reembolso, un procedimiento judicial?
2. 02¿A quién afecta? ¿A un borrador interno, a un compañero, a un cliente o a un ciudadano, a dinero, a un tercero?
3. 03¿Genera un compromiso o un efecto jurídico? Una decisión sobre una persona, un pago, un contrato, un mensaje enviado en nombre de su organización.
4. 04¿Con qué frecuencia y a qué velocidad? Una acción que se repite miles de veces al día necesita un control distinto del de una que ocurre dos veces por semana.

Las respuestas sitúan cada acción en uno de cuatro niveles. La mayoría de las organizaciones descubren que un puñado de acciones concentra casi todo el riesgo, y es una buena noticia: ahí es donde debe ir el esfuerzo de aprobación.

Los niveles son una herramienta de diseño, no una clasificación jurídica. Contrástelos con las normas que le sean aplicables. El RGPD reconoce a las personas derechos específicos frente a las decisiones basadas únicamente en el tratamiento automatizado (se abre en un sitio externo) que produzcan efectos jurídicos o les afecten significativamente de modo similar (artículo 22). En el caso de los sistemas de alto riesgo, el Reglamento de IA exige que puedan ser vigilados de manera efectiva por personas (se abre en un sitio externo) (artículo 14). Es en el nivel 4 donde suelen recaer esas obligaciones.

03Señales que siempre deben llegar a una persona

Hay situaciones que deberían subir una acción de nivel, sea cual sea su posición habitual. Configúrelas como comprobaciones explícitas del flujo de trabajo, para que no dependan de que el agente las detecte.

• La entrada queda fuera de aquello con lo que se probó el agente: un tipo de documento nuevo, un idioma poco habitual, campos que faltan o se contradicen.
• Las fuentes que ha recuperado el agente se contradicen, o la acción propuesta se apoya en algo que no puede citar.
• El importe, el alcance o el número de registros afectados supera un umbral que usted ha fijado.
• El caso toca una categoría sensible: datos de salud, menores, una queja, un litigio o un recurso en curso.
• El agente ya ha reintentado la acción, o un sistema posterior ha devuelto un error.

Hay una señal que falta a propósito en esa lista: la confianza que el propio modelo declara. Los modelos de lenguaje pueden afirmar cosas erróneas con total fluidez, lo que el Instituto Nacional de Estándares y Tecnología de Estados Unidos (NIST) denomina confabulación (se abre en un sitio externo) en su perfil de riesgos de la IA generativa. Una puntuación autodeclarada puede ser un dato más, pero debe acompañar a comprobaciones externas, como reglas de validación y el contraste con el sistema de referencia, nunca sustituirlas.

04Diseñar una aprobación que las personas puedan dar de verdad

Una sucesión de avisos de «¿aprobar?» enseña a la gente a aprobar. El Reglamento de IA nombra el riesgo de forma explícita: las personas que supervisan un sistema de alto riesgo deben poder seguir siendo conscientes del sesgo de automatización.

Cuatro decisiones de diseño hacen que esa conciencia sea practicable.

Muestre la evidencia, no solo la respuesta

Presente la acción propuesta en lenguaje claro, las fuentes en las que se apoya (con enlaces que se abran en el pasaje exacto), la regla o la política que ha aplicado y qué cambiará exactamente y en qué sistema. Quien tiene que abrir tres aplicaciones para comprobar una propuesta dejará de comprobar en cuanto apriete el tiempo.

Haga que el «no» sea tan fácil como el «sí»

Rechazar y editar son resultados normales, no excepciones. Colóquelos junto al botón de aprobar, pida un motivo breve cuando alguien rechace y utilice esos motivos en la evaluación. Si editar una propuesta cuesta más que redactarla desde cero, la gente acabará aprobando propuestas imperfectas.

Confíe la aprobación a un rol con autoridad

La aprobación corresponde a un rol designado que tenga la competencia, la formación y la autoridad necesarias para imponerse al sistema; para los sistemas de IA de alto riesgo, el Reglamento de IA exige exactamente eso a los responsables del despliegue (artículo 26, apartado 2 (se abre en un sitio externo)). Prevea un suplente y una vía de escalado, y mida cuánto tiempo esperan los asuntos. Una cola que no es de nadie se convierte en el cuello de botella que empuja a los equipos a saltarse el control.

Agrupe solo lo que de verdad es de bajo riesgo

Revisar uno por uno cuarenta asuntos casi idénticos no hace a nadie más cuidadoso. Para las acciones de nivel 2, permita la revisión agrupada con muestreo aleatorio. Mantenga la revisión individual en los niveles 3 y 4.

05Aplique el control en el sistema, no en el prompt

Una instrucción en un prompt no es un control de acceso. Los textos que lee el agente, como un correo electrónico, un documento o una página web, pueden contener instrucciones propias, lo que OWASP describe como inyección de prompts (se abre en un sitio externo). Si lo único que separa a un agente de una acción irreversible es una frase en sus instrucciones, dé por hecho que algún día esa frase quedará anulada.

• Dé al agente una identidad propia con los privilegios mínimos que necesita cada herramienta, y haga que actúe con los derechos del usuario que realiza la solicitud cuando la plataforma lo permita.
• Aplique las aprobaciones en la capa de integración: el servicio que envía la carta rechaza la llamada salvo que exista un registro de aprobación válido para esa acción concreta.
• Establezca límites de importe, de volumen y de frecuencia en las herramientas, con independencia del agente.
• Separe las herramientas de lectura de las de escritura, para poder ampliar lo que el agente puede ver sin ampliar lo que puede hacer.

06Registre lo que necesitaría para dar explicaciones después

De cada ejecución del agente, conserve la solicitud, las fuentes recuperadas, cada llamada a herramientas con sus parámetros, la acción propuesta, la persona que aprueba, la decisión, las modificaciones y las marcas de tiempo. En el caso de los sistemas de IA de alto riesgo, los responsables del despliegue deben conservar los registros generados automáticamente durante al menos seis meses, salvo que otra norma disponga otra cosa (artículo 26, apartado 6 (se abre en un sitio externo)). Aunque ninguna norma lo exija, consérvelos de todos modos: el registro es la forma de aprender.

Revise los registros con una periodicidad fija. Las acciones que siempre se aprueban sin cambios son candidatas a bajar de nivel. Las que se editan a menudo apuntan a una debilidad del agente, o deberían estar un nivel más arriba. Los rechazos que se concentran en una fuente, un formulario o un equipo suelen revelar un problema de proceso que ningún modelo va a resolver.

07Empiece con un alcance acotado y baje después las acciones de nivel

Arranque con la mayoría de las acciones de mayor consecuencia en los niveles 3 y 4. Acuerde de antemano qué se considera un buen resultado: qué desenlaces cuentan como correctos, qué errores son aceptables y cuáles no. Después, mida con esos criterios; por ejemplo, con las funciones de medición del Marco de Gestión de Riesgos de IA del NIST (se abre en un sitio externo) como lista de comprobación.

Pase una acción a un nivel más ligero solo con evidencia: un periodo en el que las aprobaciones no hayan requerido cambios sustanciales, pruebas con los casos que salieron mal y el visto bueno del responsable del proceso. Documente esa decisión como cualquier otro cambio del sistema y conserve la opción de dar marcha atrás.

Los resultados de la IA pueden ser erróneos. No es un motivo para mantener a los agentes alejados del trabajo real; es el motivo para diseñar dónde conservan el control las personas. Los agentes son útiles porque pueden actuar. Situar los puntos de aprobación de forma deliberada es lo que le permitirá confiarles más trabajo con el tiempo.