Onde precisan aprobación humana os axentes de IA

01Os axentes actúan, e a pregunta cambia

Un asistente conversacional redacta texto e unha persoa decide que facer con el. Un axente vai máis alá: chama ferramentas. Actualiza un rexistro, reserva unha cita, encamiña un expediente, envía unha mensaxe ou prepara un pagamento. Cando o software executa accións, a pregunta útil xa non é só «é boa esta resposta?», senón «quen responde por esta acción e cando deu o seu acordo?».

A comunidade de seguridade ten un nome para este erro. A lista OWASP Top 10 para aplicacións de modelos de linguaxe inclúe o exceso de autonomía (abre un sitio web externo) («excessive agency») entre os riscos principais: un axente con máis funcións, máis permisos ou máis autonomía dos que precisa a súa tarefa. A aprobación humana é un dos controis. Se se aplica en todas partes, fai o traballo máis lento e acostuma as persoas a premer «aprobar». Se non se aplica en ningunha, quedan accións que ninguén decidiu. O traballo está en situala ben.

02Partir das accións, non do modelo

Faga un inventario de cada ferramenta que o axente pode chamar. Para cada unha, responda catro preguntas. Refírense á acción e ao seu efecto, non ao modelo, e iso é deliberado.

1. 01Pódese desfacer? E a que custo: un clic, unha carta de corrección, unha devolución, un preito?
2. 02A quen afecta? Un borrador interno, unha persoa da mesma organización, a clientela ou a cidadanía, diñeiro, un terceiro?
3. 03Crea un compromiso ou un efecto xurídico? Unha decisión sobre unha persoa, un pagamento, un contrato, unha mensaxe enviada no nome da súa organización.
4. 04Con que frecuencia e a que velocidade? Unha acción que se repite miles de veces ao día precisa un control distinto do dunha acción que ocorre dúas veces por semana.

As respostas sitúan cada acción nun de catro niveis. A maioría das organizacións descobre que un puñado de accións concentra case todo o risco, e iso é unha boa noticia: é aí onde debe ir o esforzo de aprobación.

Dous casos ilustrativos. Nun concello, un axente prepara as solicitudes dunha liña de axudas: comproba que a documentación está completa, extrae os datos e redacta a proposta. A resolución segue sendo do persoal tramitador, que a asina no expediente (nivel 4). Nunha empresa que recibe facturas electrónicas estruturadas dos seus provedores (obrigatorias desde o 6 de outubro de 2027 para quen as emite e supera os 8 millóns de euros de volume de operacións), o axente casa cada factura co pedido e coa recepción; por riba dun importe fixado, o pagamento agarda a aprobación dunha persoa (nivel 3).

Os niveis son unha ferramenta de deseño, non unha clasificación xurídica. Contrásteos coas normas que lle son aplicables. O RXPD dálles ás persoas dereitos específicos fronte ás decisións baseadas unicamente no tratamento automatizado (abre un sitio web externo) que producen efectos xurídicos nelas ou que as afectan significativamente de modo similar (artigo 22). Para os sistemas de alto risco, o Regulamento de IA da UE esixe que poidan ser vixiados de maneira efectiva por persoas (abre un sitio web externo) (artigo 14). Polo xeral, é no nivel 4 onde recaen esas obrigas.

03Sinais que sempre deben chegar a unha persoa

Algunhas situacións deberían subir unha acción de nivel, sexa cal sexa o seu lugar habitual. Constrúaas como comprobacións explícitas no fluxo de traballo, para que non dependan de que o axente se decate delas.

• A entrada está fóra do que se probou co axente: un tipo de documento novo, unha lingua pouco habitual, campos baleiros ou contraditorios.
• As fontes que recuperou o axente contradinse, ou a acción proposta depende de algo que non pode citar.
• O importe, o alcance ou o número de rexistros afectados supera un limiar que vostede fixou.
• O caso toca unha categoría sensible: datos de saúde, menores, unha queixa, un litixio ou un recurso en curso.
• O axente xa volveu intentalo, ou un sistema posterior devolveu un erro.

Desa lista falta un sinal a propósito: a propia confianza do modelo. Os modelos de linguaxe poden afirmar cousas erradas con fluidez, o que o Instituto Nacional de Estándares e Tecnoloxía dos Estados Unidos (NIST) describe como confabulación (abre un sitio web externo) no seu perfil de riscos da IA xenerativa. Unha puntuación que o propio modelo declara pode ser unha entrada máis, pero debe ir xunto a comprobacións externas, como regras de validación e a comparación co sistema de referencia, e nunca substituílas.

04Deseñar unha aprobación que as persoas poidan dar de verdade

Unha serie continua de avisos «aprobar?» ensina a aprobar. O Regulamento de IA nomea o risco directamente: as persoas que vixían un sistema de alto risco deben poder ser conscientes do nesgo de automatización.

Catro decisións de deseño fan práctica esa conciencia.

Mostrar as probas, non só a resposta

Presente a acción proposta con palabras claras, as fontes nas que se apoia (con ligazóns que abran no fragmento exacto), a regra ou a política que aplicou e que cambiará exactamente e en que sistema. Unha persoa revisora que ten que abrir tres aplicacións para comprobar unha proposta deixará de comprobar cando teña présa.

Que dicir «non» sexa tan doado como dicir «si»

Rexeitar e editar son resultados normais, non excepcións. Póñaos xunto a aprobar, pida un motivo breve cando alguén rexeite e use eses motivos na avaliación. Se editar unha proposta custa máis que escribila desde cero, as persoas aprobarán propostas imperfectas.

Dar a aprobación a un rol con autoridade

A aprobación correspóndelle a un rol designado coa competencia, a formación e a autoridade necesarias para corrixir o sistema; para os sistemas de IA de alto risco, o Regulamento de IA pídelles exactamente isto aos responsables do despregamento (artigo 26.2 (abre un sitio web externo)). Engada unha persoa suplente e unha vía de escalado, e mida canto tempo agardan os elementos. Unha cola sen responsable convértese no atasco que leva os equipos a saltar o punto de aprobación.

Agrupar só o que é realmente de baixo risco

Revisar corenta elementos case idénticos un por un non fai a ninguén máis coidadoso. Para as accións de nivel 2, permita a revisión en bloque con mostraxe aleatoria. Manteña individuais os elementos dos niveis 3 e 4.

05Aplicar o punto de aprobación no sistema, non nas instrucións

Unha instrución dada ao modelo non é un control de acceso. O texto que le o axente, como un correo electrónico, un documento ou unha páxina web, pode conter instrucións propias, o que OWASP describe como inxección de instrucións (abre un sitio web externo) («prompt injection»). Se o único que separa un axente dunha acción irreversible é unha frase nas súas instrucións, dea por feito que algún día esa frase quedará sen efecto.

• Déalle ao axente unha identidade propia cos privilexios mínimos que precisa cada ferramenta, e faga que actúe cos dereitos da persoa que fai a solicitude cando a plataforma o permita.
• Aplique as aprobacións na capa de integración: o servizo que envía a carta rexeita a chamada se non existe un rexistro de aprobación válido para esa acción concreta.
• Poña nas ferramentas límites de importe, de volume e de frecuencia, independentes do axente.
• Separe as ferramentas de lectura das de escritura, para poder ampliar o que o axente pode ver sen ampliar o que pode facer.

06Rexistrar o que precisará explicar máis adiante

En cada execución do axente, garde a solicitude, as fontes recuperadas, cada chamada a unha ferramenta cos seus parámetros, a acción proposta, quen a aprobou, a decisión, as edicións e as horas. Para os sistemas de IA de alto risco, os responsables do despregamento deben conservar os rexistros xerados automaticamente polo menos seis meses, salvo que outra norma dispoña outra cousa (artigo 26.6 (abre un sitio web externo)). Onde ningunha norma o esixa, gárdeos igualmente: o rexistro é a forma de aprender.

Revise os rexistros cun ritmo fixo. As accións que sempre se aproban sen cambios son candidatas a baixar de nivel. As que se editan a miúdo apuntan a unha debilidade do axente, ou pertencen a un nivel superior. Os rexeitamentos que se concentran nunha fonte, nun formulario ou nun equipo adoitan revelar un problema de proceso que ningún modelo vai arranxar.

07Comezar en pequeno e despois baixar accións de nivel

Comece coas accións de máis consecuencias nos niveis 3 e 4. Acorde de antemán que se considera un bo resultado: que resultados contan como correctos, que erros son aceptables e cales non. Despois mida contra eses criterios, por exemplo coas funcións de medición do marco de xestión de riscos da IA do NIST (abre un sitio web externo) como lista de comprobación.

Pase unha acción a un nivel máis lixeiro só con probas: un período no que as aprobacións non precisaron edicións relevantes, probas sobre os casos que saíron mal e a conformidade da persoa responsable do proceso. Rexistre esa decisión como calquera outro cambio no sistema, e conserve a opción de volver atrás.

Os resultados da IA poden ser erróneos. Iso non é motivo para manter os axentes lonxe do traballo real; é o motivo para deseñar en que puntos as persoas manteñen o control. Os axentes son útiles porque poden actuar. Situar os puntos de aprobación con criterio é o que permite confiarlles máis tarefas co tempo.