Antes de liberar IA Aplicada em produção, relacione escopo, dados, autorização, trilha de auditoria e recuperação a responsáveis e evidências. Verifique onde RBAC e ABAC limitam ações e como reconstruir pedido, autorização, tentativa e confirmação. A decisão precisa separar controle declarado de controle testado e interrupção de recuperação dos efeitos já ocorridos.
Qual deve ser a unidade de avaliação?
Escolha uma operação empresarial e identifique os agentes, fornecedores, modelos, ferramentas, canais e equipes que participam dela. Registre a finalidade, os dados utilizados e as ações possíveis. Um inventário inicial pode ser parcial; mantenha visíveis os trechos ainda desconhecidos e quem vai investigá-los, sem apresentar a lista como descoberta completa da empresa.
Avalie a consequência da ação no contexto. Preparar um rascunho, consultar um documento e alterar um cadastro exigem perguntas diferentes. Defina quem pode aceitar o resultado e quem pode autorizar mudanças no escopo. Negócio, segurança e tecnologia precisam compartilhar essa descrição para evitar que cada área avalie uma versão diferente da mesma operação.
Como transformar política em uma verificação concreta?
Escreva a regra em termos que a equipe possa testar: qual identidade pode executar qual operação, sobre quais recursos e em quais condições? Em seguida identifique onde a verificação acontece. Uma regra pode depender de autorização na ferramenta, validação dos parâmetros, revisão humana ou restrição no sistema de destino. Anote os caminhos que não passam por esse ponto.
RBAC relaciona papéis às operações permitidas. ABAC considera atributos do recurso, da ação e do contexto, como finalidade ou limite aprovado. Aplique a autorização no ponto que efetiva a ação: ferramenta, integração ou sistema de destino. Uma recusa do modelo não bloqueia uma credencial que permite acesso direto. Verifique também rotinas administrativas, chamadas alternativas e reprocessamentos que podem contornar esse ponto.
Vincule a aprovação aos parâmetros que serão executados e confira sua validade no momento da ação. Mudança de destinatário, escopo ou valor exige nova autorização. Teste ação permitida, papel sem permissão, condição fora do limite, aprovação expirada e tentativa pelo caminho alternativo. Registre o efeito observado no destino.
Separe controle declarado, configurado e verificado. Uma documentação descreve a intenção; uma configuração mostra parte da implementação; um teste representativo demonstra comportamento sob condições específicas. Nenhum desses registros, isoladamente, comprova proteção universal. Evidências precisam indicar escopo, versão e condições de verificação sem expor dados pessoais, segredos ou conteúdo desnecessário.
Como avaliar dados, ferramentas e conteúdo externo?
Acompanhe a circulação dos dados por armazenamento, busca, modelos, ferramentas e suporte. O fato de um documento permanecer no ambiente da empresa não informa quais trechos serão enviados a outro serviço. Registre destino, finalidade, acesso e condições de retenção a confirmar. A modalidade de infraestrutura deve ser avaliada junto com esses caminhos.
Considere que uma mensagem, um documento ou uma resposta de ferramenta pode conter instruções inadequadas ao objetivo da operação. A integração precisa manter a autoridade nas regras e permissões definidas pela aplicação, em vez de concedê-la ao conteúdo recebido. Inclua tentativas de induzir ações fora do escopo nos testes e observe os efeitos no sistema, não apenas a resposta textual do agente.
Como auditar o que um agente de IA fez?
Auditar um agente de IA é conseguir reconstruir, para uma ação concreta, quatro elos: o pedido recebido, a autorização concedida ou negada, a tentativa enviada e a confirmação no sistema de destino. O transcript da conversa ajuda a entender o contexto, mas não prova nenhum desses elos. Uma auditoria útil começa por uma operação delimitada, com responsável e critério de verificação definidos, e testa se uma pessoa autorizada encontra a evidência sem depender do relato do agente. Resultado desconhecido fica registrado como pendência. Volume de logs não demonstra cobertura: o que importa é saber quais elos ainda faltam.
Evidência não é transcript. Como discute o artigo “Sua IA respondeu ‘feito’. Mas a tarefa foi concluída?”, a resposta do agente, a execução de uma ação e a confirmação no sistema de destino são estados diferentes. Guardar a conversa registra o que foi dito; não registra o que o sistema de destino aceitou. Para cada elo, indique onde ele fica registrado: o pedido no canal ou na fila, a decisão de autorização no ponto que aplica a política, a tentativa na integração e a confirmação no próprio sistema de destino.
Registre, em cada elo, momento, decisão, versão da política e resultado, com o mínimo de informação necessário. Uma resposta do modelo ou uma chamada enviada não comprova conclusão. Ausência de retorno deve permanecer como resultado desconhecido até a consulta e a reconciliação no destino.
Defina retenção, acesso, proteção contra alterações e procedimento de investigação. Mantenha dados pessoais, segredos, prompts, tokens e valores sensíveis fora dos logs. Use referências protegidas para correlacionar a evidência autorizada e acessar material de recuperação em armazenamento separado, com permissões e retenção próprias; não copie o conteúdo anterior do cadastro para a trilha. A referência também precisa de proteção e não deve expor identificadores sensíveis.
Teste se uma pessoa autorizada consegue reconstruir uma tentativa bloqueada e uma execução confirmada e se acessos indevidos à evidência são recusados. O volume de registros não demonstra cobertura: a equipe precisa localizar os elos ausentes e manter explícito o que ainda não consegue verificar.
Sabemos o que nossos agentes estão fazendo? Ler as conversas não é o mesmo que ligar pedido, autorização, tentativa e confirmação. Comece por uma operação e liste os elos que ainda faltam.
Como interromper, reverter ou compensar uma ação?
Combine quem recebe uma ocorrência, quem pode suspender uma integração e como o trabalho continua com a equipe. Interromper bloqueia novas ações; não desfaz uma alteração já confirmada. Antes de repetir ou recuperar, confira o destino e as ações em andamento para não duplicar efeitos.
Reversão restaura um estado anterior quando o sistema permite; compensação trata a consequência por outra ação, como um estorno autorizado. Um envio externo pode não ser recuperável. Para cada efeito, defina responsável, condição, limite e evidência de conclusão. O material necessário à recuperação deve ser acessado por referência protegida, não pela cópia de valores sensíveis em logs.
No caso de confirmação ausente ou reversão parcial, mantenha a pendência e encaminhe à equipe responsável. Se não houver recuperação viável, reduza a autonomia e exija aprovação humana antes da ação de maior impacto. Exercite o procedimento de parada e recuperação antes de ampliar o escopo.
Que evidência permite liberar ou retomar a operação?
Revise a matriz com negócio, segurança e tecnologia. Cada controle precisa de ponto de aplicação, evidência a conferir, responsável e pendência explícita. Registre a decisão sobre o recorte, as limitações aceitas e quem autoriza a liberação. Não trate uma linha preenchida como controle já comprovado.
Revise o desenho quando mudarem modelo, fonte, ferramenta, permissão, fornecedor ou finalidade. A revisão deve ser proporcional ao impacto da mudança e registrar o que foi reavaliado. O NIST AI RMF oferece uma referência voluntária para organizar esse trabalho; seguir um roteiro não equivale a obter uma certificação nem comprova conformidade de uma implantação.
Exemplo ilustrativo · sem dados de cliente
Um reembolso que exige decisão de uma pessoa
Exemplo fictício: o agente organiza os comprovantes e identifica uma solicitação fora da condição prevista. O processo permite preparar o dossiê, mas reserva a aprovação a uma pessoa responsável. O controle deve atuar na integração que efetivaria o pagamento, além de orientar o agente.
A verificação precisa mostrar que a tentativa sem aprovação foi bloqueada, que a equipe recebeu a pendência e que uma decisão posterior corresponde aos mesmos parâmetros. Documentação completa continua sendo um estado diferente de pagamento autorizado ou realizado.
Se o retorno do pagamento não chegar, a equipe consulta o destino antes de tentar novamente. Uma interrupção impede novos pagamentos; eventual estorno exige outro procedimento e autorização. Os comprovantes e o material de recuperação ficam em repositório protegido, referenciado pela evidência autorizada, sem copiar valores sensíveis para logs. A matriz mostra o que conferir neste cenário; não relata testes realizados em um cliente.
| Controle | Ponto de aplicação | Evidência a conferir | Responsável | Pendência antes da liberação |
|---|---|---|---|---|
| Restringir escopo e dados | Fontes autorizadas e saída para ferramentas/modelos | Mapa dos destinos e teste de saída fora do escopo bloqueada. | Negócio e responsável pelos dados | Confirmar fontes, destinos e condições de retenção. |
| Aplicar RBAC/ABAC e aprovação | Integração de pagamento e sistema de destino | Tentativa sem papel ou atributo permitido bloqueada; aprovação ligada aos parâmetros executados. | Segurança e responsável pela integração | Testar credencial direta, aprovação expirada e alteração após aprovação. |
| Reconstruir pedido, autorização, tentativa e confirmação | Trilha protegida da integração | Eventos correlacionados, decisão da política e confirmação ou estado desconhecido; sem conteúdo sensível. | Operação e segurança | Validar acesso, retenção e reconstrução de tentativa bloqueada e execução confirmada. |
| Interromper novas ações | Integração e fila de pagamentos | Teste de suspensão e consulta das ações que já estavam em andamento. | Responsável de plantão pela operação | Definir autoridade de parada e continuidade pela equipe. |
| Reverter ou compensar efeitos | Sistema financeiro e repositório protegido de recuperação | Consulta antes de repetir; referência protegida e confirmação de estorno autorizado, quando possível. | Financeiro e responsável pelo sistema | Exercitar retorno ausente e compensação parcial; registrar efeitos sem reversão. |
| Autorizar liberação e retomada | Revisão da versão e do escopo | Decisão registrada com resultados dos testes, limites e pendências. | Negócio, segurança e tecnologia | Resolver bloqueios e definir mudanças que exigem nova avaliação. |
Use uma linha por controle da sua operação. Indique onde ele é aplicado, que evidência será examinada, quem responde e o que falta. Neste exemplo todas as evidências são propostas de verificação; a liberação depende dos resultados e da decisão dos responsáveis.
Quando o caminho precisa mudar
Se não há evidência suficiente, registre o controle como não verificado e defina a próxima checagem. Quando não for possível limitar uma credencial ao escopo necessário, reduza as ações disponíveis ou mantenha o trabalho em uma etapa de preparação com revisão. Restrições e decisões precisam ser confirmadas na implantação específica.
Um ponto de atenção: considerar uma política escrita ou uma resposta correta como evidência suficiente de proteção.
O roteiro está pronto para avançar quando…
- Escopo, dados e responsabilidades estão identificados.
- Cada controle possui ponto de aplicação, evidência, responsável e pendência registrada.
- Pedido, autorização, tentativa e confirmação podem ser reconstruídos com acesso restrito e conteúdo minimizado.
- Interrupção, reversão ou compensação têm procedimentos e limites explícitos.
- A liberação e a retomada dependem de evidências e de responsáveis definidos.
Leve a matriz para a equipe e selecione uma ação para verificação. A avaliação Starya ajuda a organizar as perguntas; não inspeciona sistemas nem emite certificação.
Seu roteiro
Preencha com sua equipe.
Registre o que já sabe e o que ainda precisa confirmar. As respostas permanecem em memória, sem envio.
Referências para aprofundar
- OWASP — Agentic AI: Threats and Mitigations ↗
Referência para modelar ameaças de sistemas de agentes e discutir mitigações. O roteiro e os cenários abaixo são propostas de trabalho da Starya, não uma reprodução integral do documento.
- NIST AI RMF Playbook ↗
Referência voluntária para organizar governança, entendimento do contexto, medição e gestão de riscos de IA. Não é uma certificação da Starya nem substitui a avaliação do caso concreto.