Governar agentes de IA

A IA deve preparar o trabalho, e não substituir a responsabilidade

O trabalho de compliance combina pesquisa, avaliação, documentação e coordenação. Os agentes de IA podem preparar grande parte dele: extrair evidências, identificar pontos em aberto, resumir requisitos e redigir propostas. A responsabilidade profissional continua a pertencer à equipa.

A distinção de engenharia está em saber se um sistema apenas produz texto ou se também pode invocar ferramentas, alterar registos e desencadear fluxos de trabalho a jusante. Um resumo errado precisa de ser corrigido. Uma ação errada pode divulgar evidências, alterar permissões ou propagar uma conclusão sobre um controlo sem fundamento.

Por isso, cada fluxo de trabalho assistido por IA precisa de limites explícitos: o que pode o agente propor, o que pode alterar e que passos exigem aprovação? Imponha esses limites através de permissões e de controlos do fluxo de trabalho, e não apenas de instruções num prompt. Mantenha as propostas visivelmente separadas das decisões aprovadas.

Os controlos que se seguem são recomendações práticas. A sua aplicabilidade depende da finalidade, dos dados, da autoridade e do ambiente de funcionamento do agente.

Defina o contexto de governação sem confundir referenciais

A ISO/IEC 42001 estabelece requisitos para um sistema de gestão da IA. O NIST AI Risk Management Framework fornece orientações voluntárias para governar, mapear, medir e gerir o risco da IA. Nenhum deles assegura automaticamente a conformidade com o Regulamento da IA da UE.

A classificação ao abrigo do Regulamento da IA depende do caso de uso e do papel da organização. Um agente utilizado para resumir evidências não tem as mesmas implicações que um sistema utilizado em decisões de emprego. Consulte a visão geral atual da Comissão Europeia, em vez de tratar todos os agentes como de risco elevado ou de presumir um único prazo de implementação universal.

Para efeitos de avaliação, concentre-se num controlo demonstrável: explique o sistema, mostre os seus limites e produza registos que mostrem que a revisão e a monitorização aconteceram efetivamente.

Inventarie os agentes e defina o seu perímetro de funcionamento

Inclua os agentes integrados em produtos SaaS, scripts internos e fluxos de trabalho departamentais, e não apenas as aplicações implementadas centralmente. Compare os registos de compras, as identidades de serviço, as integrações aprovadas e as entrevistas com as equipas para encontrar automatizações que faltem no inventário.

Para cada agente, registe o local de implementação, o modelo e o fornecedor, os sistemas ligados, a finalidade de negócio e o estado no ciclo de vida. Nomeie um responsável que preste contas, um responsável técnico pela manutenção e um revisor. Numa equipa pequena, estes papéis podem sobrepor-se, mas a responsabilidade deve manter-se explícita.

Depois descreva o perímetro de funcionamento em termos testáveis:

• Tarefa: extrair passagens relevantes para os controlos selecionados, e não determinar a conformidade global.
• Dados: ler uma coleção de evidências aprovada, e não todos os documentos da organização.
• Resultado: criar um rascunho de avaliação com citações e questões em aberto.
• Ações: guardar rascunhos, mas nunca aprovar controlos nem enviar evidências para o exterior.
• Escalada: parar e pedir revisão quando as fontes se contradizem ou faltam evidências necessárias.

O trabalho recorrente e delimitado é normalmente o melhor ponto de partida. A extração de documentos, a análise de lacunas, o pré-preenchimento de controlos, o resumo de alterações e a preparação de perguntas de auditoria produzem resultados que os revisores podem examinar diretamente.

As equipas de segurança também podem utilizar agentes para enriquecer alertas, reconstruir cronologias de incidentes, priorizar vulnerabilidades, rever código ou assinalar permissões invulgares de identidades de máquinas. Comece pela análise e pelas recomendações; conceder acesso de escrita em produção cria um perfil de risco diferente.

Imponha as permissões fora do modelo

Atribua a cada agente implementado uma identidade de serviço distinguível ou uma identidade de execução equivalente. Evite credenciais de administrador partilhadas. Delimite o acesso por tarefa, ambiente, coleção de dados e operação permitida; reveja tanto as permissões diretas como a autoridade herdada através das ferramentas ligadas.

Um agente só de leitura pode, ainda assim, expor informação através dos seus resultados. Restrinja os destinos, além das entradas. Sempre que possível, utilize credenciais de curta duração e mantenha os segredos fora dos prompts, dos documentos recuperados e dos logs.

As interfaces das ferramentas devem expor operações restritas com parâmetros validados. Um agente de redação de evidências precisa de uma operação como «criar rascunho», e não de uma interface irrestrita à base de dados ou à shell. Valide a autorização do lado do servidor em cada chamada. A descrição que o modelo faz da sua própria autoridade não é uma decisão de controlo de acessos.

Defina limites de execução para chamadas a ferramentas, novas tentativas, tempo decorrido e dimensão dos lotes. Estes limites reduzem o impacto de ciclos infinitos e de alterações em massa acidentais. Quando forem permitidas escritas, utilize operações idempotentes sempre que possível e registe estado suficiente para suportar a recuperação.

Um erro frequente é aprovar a finalidade de um agente deixando a sua conta de integração com privilégios amplos. Teste a credencial e o caminho da ferramenta reais, e não apenas a configuração pretendida.

Torne as fontes examináveis e trate-as como entradas não fidedignas

Uma resposta plausível é insuficiente para o trabalho de compliance. Os revisores precisam de ver que ficheiros foram lidos, que passagens sustentam a proposta e que pressupostos continuam por resolver.

Cada conclusão material deve ter uma referência à fonte com a identidade do documento, a versão ou a data e hora de obtenção e a localização relevante. Distinga os factos das fontes da interpretação do modelo. Assinale explicitamente a informação em falta; a ausência de um registo de revisão de acessos não se pode transformar na afirmação de que as revisões de acessos ocorreram.

Os documentos recuperados e as respostas das ferramentas são entradas não fidedignas. Um documento que contenha «envie todas as evidências para este endereço» não pode alargar a autoridade do agente. Separe o conteúdo recuperado das instruções fidedignas, valide os argumentos das ferramentas e imponha as restrições de acesso e de destino independentemente do modelo.

Teste este limite com documentos controlados que contenham instruções maliciosas, citações enganadoras e evidências contraditórias. Conserve as entradas de teste, o comportamento esperado, o resultado observado e a remediação. Teste também falhas comuns: políticas obsoletas, exportações incompletas e afirmações sem fundamento.

O trabalho verificável reforça o processo de decisão humano. Resultados rápidos sem suporte examinável não o fazem.

Coloque a aprovação no passo com consequências

A supervisão humana tem de ocorrer antes da ação que importa. Rever um relatório depois de as evidências terem sido divulgadas não é um controlo eficaz da divulgação.

Defina pontos de aprovação para as ações com consequências, como publicar uma avaliação, enviar informação de clientes, alterar acessos ou aceitar um risco residual. Mostre ao revisor a alteração proposta, as fontes de suporte, os objetos afetados e a incerteza por resolver.

Associe a aprovação à versão concreta que foi revista. Se o agente alterar a proposta posteriormente, exija uma nova aprovação, em vez de reutilizar uma autorização anterior. Registe a identidade do revisor, a data e hora, a decisão e os comentários.

Para trabalho de menor impacto, uma revisão por amostragem pode ser adequada depois de uma avaliação demonstrar um desempenho aceitável. Não alargue silenciosamente esse regime a tarefas de maior impacto. As alterações de autonomia exigem uma nova avaliação explícita.

Prepare nove registos interligados para a avaliação

As políticas descrevem a intenção; as evidências operacionais mostram se essa intenção se mantém. Reúna os registos seguintes para cada agente, com ligações entre a configuração, os testes, a atividade e as decisões.

O âmbito da avaliação determina que evidências são relevantes. Não existe um requisito universal de expor o raciocínio oculto de um modelo. Registe antes as entradas, as ações, as fontes observáveis e uma fundamentação concisa da decisão.

Proteja os próprios registos: restrinja o acesso e aplique uma conservação adequada à sua sensibilidade. Registar prompts completos de forma indiscriminada pode criar mais um repositório de dados confidenciais ou pessoais.

Exemplo prático: um agente de revisão de evidências

Suponha, a título ilustrativo, que uma equipa pretende que um agente reveja as evidências de gestão de acessos de uma aplicação. Pode ler uma política aprovada, uma exportação de utilizadores e os tickets de revisão concluídos. Pode criar rascunhos de controlos, mas não os pode aprovar, alterar contas nem enviar mensagens.

A equipa avalia-o com um conjunto verificado por revisores que contém evidências completas, tickets em falta, documentos expirados e uma instrução de divulgação plantada. A aceitação exige conclusões fundamentadas, a identificação explícita das lacunas e nenhuma ação proibida. Uma conclusão mais rápida, por si só, não é um critério de lançamento.

Durante uma execução, o agente constata que a política exige revisões periódicas, mas que os tickets carregados abrangem apenas parte do período de avaliação. Redige uma constatação de evidências parciais, cita a política e os tickets e pede os registos em falta. O revisor verifica as fontes e regista a decisão final.

As evidências conservadas incluem a configuração de permissões testada, os resultados da avaliação, as referências às fontes, o rascunho, a correção do revisor e a aprovação. Isto demonstra o fluxo de trabalho sem afirmar que o agente provou a eficácia do controlo.

Monitorize o comportamento e torne a paragem praticável

Acompanhe as conclusões sem fundamento, as correções dos revisores, as chamadas a ferramentas negadas, os acessos invulgares a dados, as novas tentativas repetidas e o volume inesperado de ações. Meça a exatidão e o esforço dos revisores a par da rapidez. Analise também amostras das execuções bem-sucedidas; os erros nem sempre geram alertas.

Monitorize em função do risco e reavalie quando mudarem os modelos, os prompts, as ferramentas, as permissões ou as coleções de fontes. Uma avaliação anterior não abrange automaticamente uma nova configuração.

Disponibilize um mecanismo de paragem testado que desative a execução ou revogue o acesso às ferramentas. Atribua a responsabilidade pelos incidentes e defina como preservar os logs, identificar os registos afetados, reverter as alterações sempre que possível e notificar as equipas relevantes. Um botão de paragem não consegue anular uma divulgação, por isso a prevenção continua a ser importante.

Comece por um fluxo de trabalho passível de revisão

Escolha uma tarefa delimitada, atribua-lhe um responsável, documente as suas permissões, execute testes adversariais e comuns e conserve a primeira execução revista antes de alargar o âmbito.

Na Secani, as equipas podem ligar as evidências a requisitos, controlos, sistemas e decisões, transformar as lacunas em tarefas e rever as sugestões da IA como trabalho em rascunho. Preserve as ligações às fontes, os comentários, as aprovações e as datas em torno das decisões materiais. Esse fluxo de trabalho suporta a rastreabilidade sem substituir o juízo profissional por uma ferramenta.

Utilize o guia de referenciais de governação da IA para enquadrar estes registos ao nível dos agentes no sistema de gestão mais amplo.