Framework de governança de agentes de IA

1. Começar pelos princípios de governança

Um modelo de governança deve começar com poucos princípios consistentes aplicáveis a todo o portfólio de agentes. Eles precisam ser compreendidos por product owners, desenvolvedores, risk, compliance e áreas de negócio.

Os princípios principais são ownership rastreável, least privilege, controles proporcionais, accountability humana, evidence by design e mudanças controladas.

• Cada agente possui business owner e technical owner identificados.
• Cada agente opera dentro de uma finalidade e limite de autoridade explícitos.
• O acesso a sistemas, dados e ações segue o princípio de least privilege.
• A supervisão humana é proporcional às consequências potenciais de erro.
• Evidências de teste e aprovação são preservadas e reproduzíveis.
• Mudanças materiais acionam uma nova avaliação.

2. Manter um inventário confiável de agentes

Uma organização não pode governar agentes que não consegue identificar. Um inventário empresarial é, portanto, um controle fundamental.

O inventário deve ir além de uma lista de nomes e permitir compreender o que o agente faz, onde opera, quais sistemas acessa e quem é responsável por ele.

• Nome do agente, versão e status do ciclo de vida.
• Finalidade de negócio e usuários previstos.
• Business owner, technical owner e support owner.
• Ambiente Microsoft, solution e local de implantação.
• Sistemas conectados, conectores, ferramentas e categorias de dados.
• Permissões de ação e autoridade transacional.
• Classificação de risco e nível de aprovação necessário.
• Modelo de supervisão humana.
• Evidências de teste, status de certificação e data da última revisão.

3. Classificar o risco antes da implantação

A classificação de risco determina quanta governança um agente precisa. Não importa apenas o modelo utilizado, mas tudo o que o agente completo pode ver, decidir e fazer.

Um agente somente leitura é muito diferente de um agente capaz de aprovar transações, comunicar-se externamente, alterar registros ou iniciar processos.

O CAI Score é a abordagem estruturada da ColleagueAI para classificar riscos de agentes empresariais. Considera autonomia, impacto, sensibilidade de dados, acesso a ferramentas, reversibilidade, supervisão e requisitos de governança.

4. Separar responsabilidade de negócio e ownership técnico

Equipes técnicas podem construir e manter o agente, mas não devem ser as únicas responsáveis pelo resultado de negócio. A função que utiliza o agente permanece responsável pelo processo e pelas consequências.

Um modelo maduro distingue business ownership, technical ownership e governance assurance.

O modelo de responsabilidade também deve definir claramente os direitos de decisão. O responsável de negócio aprova o objetivo pretendido, os resultados aceitáveis e alterações materiais ao processo, enquanto o responsável técnico mantém a responsabilidade pela integridade dos componentes da solução, configuração e controlos técnicos. As funções de governance, risco, segurança ou compliance podem fornecer revisão independente sem substituir a responsabilidade do negócio.

5. Governar identidade, acesso e permissões de ferramentas

A capacidade de um agente depende fortemente dos sistemas e ações aos quais ele pode acessar. Conectores, credenciais, identidades de serviço e permissões devem ser tratados como controles principais.

As permissões devem ser limitadas ao mínimo necessário para a finalidade aprovada.

• Usar identidades dedicadas quando arquitetura e plataforma permitirem.
• Restringir conectores e ações aos use cases aprovados.
• Evitar permissões amplas concedidas apenas por conveniência de desenvolvimento.
• Registrar ações privilegiadas em logs auditáveis.
• Usar approval gates para ações irreversíveis ou de alto impacto.
• Revalidar permissões após mudanças em workflow ou integração.

6. Projetar a supervisão humana dentro do workflow

Supervisão humana não deve ser apenas uma declaração genérica de que uma pessoa continua responsável. É necessário identificar claramente onde as pessoas revisam, aprovam, intervêm ou interrompem o agente.

O modelo adequado depende do risco. Alguns agentes podem atuar autonomamente em tarefas de baixo risco e fortemente limitadas; outros exigem aprovação humana antes de ações relevantes.

O controlo deve especificar o ponto de intervenção, a pessoa que realiza a revisão, as informações disponíveis e as ações que essa pessoa está autorizada a executar. Uma etapa formal de aprovação não é suficiente se o revisor não consegue compreender ou impedir o resultado proposto. A supervisão humana deve, por isso, ser testada como um verdadeiro controlo operacional e não apenas documentada numa política.

7. Testar o agente como um sistema completo

O assurance do agente exige testes do workflow completo. São importantes prompt, permissões, chamadas de ferramentas, comportamento em falha, tratamento de dados, lógica de escalonamento, qualidade do output e resposta a entradas inesperadas.

Um pacote de produção deve preservar evidências do que foi testado, do comportamento esperado, das limitações conhecidas e da versão que passou nos testes.

• Testes funcionais e por cenário.
• Testes de permissões e conectores.
• Caminhos de falha e exceção.
• Caminhos de aprovação e escalonamento.
• Tratamento de dados sensíveis.
• Critérios de qualidade do output.
• Logging e geração de evidências.
• Regression tests após mudanças materiais.

8. Tornar a implantação uma transferência controlada

Um agente empacotado deve ter uma fronteira clara de implantação. O fornecedor pode fornecer uma solution testada, documentação, orientação de configuração, evidências de governança e instruções de deployment, mas o cliente controla o próprio tenant e ambiente operacional.

Nos produtos ColleagueAI, deployment e runtime permanecem no ambiente Microsoft do cliente. Configuração específica do tenant, integrações, deployment e operation são realizados pelo cliente ou pelo parceiro de implementação aprovado.

Uma passagem controlada deve também documentar pré-requisitos, variáveis de ambiente, referências de ligação, funções necessárias, limitações conhecidas e etapas de validação após a importação. Isto permite ao cliente ou parceiro de implementação reproduzir a configuração testada sem depender do conhecimento não documentado do criador original. A versão implementada deve permanecer rastreável ao pacote e às evidências que foram aprovados.

9. Monitorar risco operacional e mudanças materiais

A aprovação inicial não encerra a governança. O comportamento do agente pode mudar quando prompts, modelos, ferramentas, permissões, fontes de conhecimento ou sistemas conectados mudam.

A governança contínua deve acompanhar mudanças materiais, exceções, incidentes, padrões de uso e evidências de que a configuração implantada ainda corresponde ao design aprovado.

A monitorização deve estar ligada a gatilhos explícitos de nova revisão. Estes podem incluir um novo conector, permissões mais amplas, um modelo diferente, uma nova fonte de conhecimento, aumento de substituições manuais, exceções repetidas ou uma alteração no processo de negócio. Estes sinais devem determinar quando são necessárias investigação, correção, recertificação ou uma nova decisão de governance.

10. Governar a retirada com o mesmo rigor do lançamento

Agentes sem uso ou substituídos não devem manter acessos inativos indefinidamente. A retirada deve remover permissões, desativar integrações, arquivar evidências e atualizar o inventário.

Um processo limpo de retirada reduz a superfície de ataque e evita capacidades de IA sem owner.

A retirada de um agente deve também encerrar as respetivas dependências operacionais e de governance. Os responsáveis devem confirmar que os fluxos agendados foram desativados, as credenciais de serviço revogadas quando necessário, as integrações dependentes ajustadas e as evidências retidas de acordo com a política aplicável. O inventário deve registar a data da retirada e a disposição final do agente.

Perguntas frequentes