Governança de agentes de IA: como evitar riscos, shadow AI e vazamento de dados

Pergunte a qualquer CISO se a empresa tem uma política formal para o uso de IA e a resposta, na maioria dos casos, vai ser algo entre “estamos trabalhando nisso” e um silêncio constrangido. Pergunte se colaboradores já usam ferramentas de IA no trabalho hoje, sem essa política existir, e a resposta muda para um “sim” imediato. Esse é o descompasso em que praticamente toda empresa está operando agora: a adoção correu na frente, o controle ficou para trás, e a distância entre os dois só aumenta conforme a IA deixa de ser um chatbot que alguém usa escondido e passa a ser um agente com permissão real de acesso a sistemas.

Este artigo trata de como fechar essa distância — não com um manual de 40 páginas que ninguém vai ler, mas com um conjunto pequeno de decisões que, tomadas cedo, evitam a maior parte dos problemas. O ponto de partida para pensar nisso é o artigo sobre agentes de IA para empresas, que descreve o que esses sistemas fazem; aqui, o foco é em quem responde por eles e o que pode dar errado quando ninguém responde.

Riscos que existem hoje, mesmo sem nenhum agente sofisticado em produção

Shadow AI

A comparação mais direta é com o shadow IT que equipes de segurança já lidam há anos, com uma diferença que piora tudo: quando alguém guardava um arquivo num Dropbox pessoal não autorizado, o dado ficava parado ali. Um risco, mas contido. Quando alguém cola informação da empresa num assistente de IA gratuito, esse dado é processado, e frequentemente enviado para um servidor de terceiro fora de qualquer contrato que a empresa tenha assinado — sem que a pessoa que colou saiba exatamente para onde foi, nem se algum dia aquilo pode reaparecer em uma resposta para outra pessoa.

O exemplo mais repetido no setor é o da Samsung: engenheiros colaram código-fonte proprietário e sequências de teste de chip num assistente de IA de uso geral, num único mês, sem má intenção nenhuma — só queriam trabalhar mais rápido. A empresa reagiu banindo a ferramenta. O que ficou como lição, depois, não foi “banir funciona”. Foi o contrário: proibição total não segura ninguém por muito tempo, porque ferramenta nova aparece toda semana e quem precisa usar acha um jeito, geralmente pelo celular pessoal, fora de qualquer controle. O que reduz o uso não autorizado de verdade é dar uma alternativa aprovada que seja boa o bastante para que ninguém sinta necessidade de contornar.

E o problema está prestes a mudar de forma. A próxima onda de shadow AI não vai ser sobre alguém usando um chatbot às escondidas — vai ser sobre agentes com permissão de leitura e escrita em sistemas reais, criados sem passar por nenhuma revisão, rodando sem que ninguém no time de segurança saiba que aquilo existe.

O agente “legítimo” que vaza dado por descuido de configuração

Um agente criado dentro do Copilot Studio, com toda a boa intenção, também pode virar problema. O cenário mais comum: alguém conecta o agente a um site inteiro do SharePoint, em vez de a uma biblioteca específica, porque é mais rápido configurar assim. O agente passa a ter acesso a documentos de RH, contratos, dados financeiros que “estavam ali por perto” — e como ninguém aplicou classificação de sensibilidade antes de conectar a fonte, o agente não tem como saber que aquilo não deveria estar no seu escopo.

Um segundo cenário, mais sutil: um agente com acesso a dados de RH e, separadamente, a dados financeiros, pode combinar fragmentos das duas fontes numa única resposta — algo que nenhum usuário conseguiria fazer acessando cada sistema isoladamente. Ninguém planejou essa combinação. Ela simplesmente aconteceu porque nada impedia.

A conta de serviço com acesso amplo demais

Configurar um agente usando uma conta de serviço com privilégio administrativo amplo economiza alguns minutos no momento da configuração. O custo aparece depois: qualquer falha de segurança nesse agente herda o mesmo nível de acesso da conta que ele usa — não o que ele realmente precisava para funcionar.

Ações executadas sem ninguém revisar

Agentes que criam registros, enviam comunicações ou atualizam sistemas podem interpretar mal uma solicitação e executar a coisa errada. Sem uma etapa de confirmação humana para o que tem mais impacto, esse erro só aparece depois que já causou efeito — e quanto mais autonomia o agente tem, maior a distância entre “algo deu errado” e “alguém percebeu”.

Ninguém responde por aquilo

O risco mais silencioso de todos é o agente sem dono. Ele continua rodando, com a base de conhecimento cada vez mais desatualizada, com pequenas falhas se acumulando, e ninguém tem no seu escopo de trabalho a tarefa de notar isso. O problema só vira visível quando já é grande — geralmente na forma de reclamação, ou de incidente.

Um jeito de organizar isso que não vira burocracia

Governança de IA tem fama de processo pesado, mas o que realmente funciona em empresas de médio porte é mais simples do que parece: saber o que existe, saber o que é sensível, limitar o acesso ao necessário, olhar de tempos em tempos, e ter clareza de quando um agente nasce e quando ele deveria morrer.

Primeiro, descobrir o que já existe

Antes de escrever qualquer política, vale um levantamento honesto: quantos agentes já foram criados no Copilot Studio, visíveis via Power Platform Admin Center, e que uso de ferramentas de IA externas — via navegador, extensão, integração feita por algum desenvolvedor — já está acontecendo sem aprovação formal. A maioria das empresas fica surpresa com o resultado desse levantamento. É normal. É exatamente por isso que ele precisa ser feito primeiro, não depois.

Depois, classificar antes de conectar

A pergunta que deveria vir antes de qualquer agente ser conectado a uma fonte de dados: esse conteúdo é público, interno, confidencial ou altamente restrito? Um agente de FAQ pode consultar material público sem restrição alguma. Um agente com qualquer acesso a dado de RH ou financeiro precisa de camadas adicionais de autenticação e DLP antes de ir ao ar. A diferença entre os dois só existe se a classificação foi feita — sem ela, tudo recebe o mesmo tratamento, o que na prática costuma significar tratamento insuficiente para o que era sensível.

Acesso do tamanho certo, não do tamanho conveniente

Autenticação via Microsoft Entra deveria ser a regra para qualquer agente corporativo — exceções (um agente de atendimento público, por exemplo) precisam de justificativa registrada, não de ser o caminho mais fácil por padrão. E cada agente deveria ter só o acesso que seu propósito exige: se o trabalho é responder sobre política de RH, não há razão para ele enxergar o repositório financeiro. As políticas de DLP configuradas no Power Platform Admin Center são o controle técnico que sustenta essa regra — definindo quais conectores podem se combinar num mesmo agente e o que pode sair para fora do ambiente.

Olhar de novo, com regularidade

Um agente aprovado hoje pode ficar arriscado com o tempo, sem que nada de dramático tenha acontecido — uma integração nova foi somada sem revisão, uma fonte de conhecimento passou a incluir um documento que não deveria estar ali, um padrão de uso revelou uma lacuna que não era visível na aprovação inicial. Política escrita e treinamento, sozinhos, não seguram isso — a pesquisa do setor é bem consistente nesse ponto. O que segura é alguém de fato olhando os logs de tempos em tempos, não só confiando que a regra vai ser seguida porque está escrita em algum lugar.

E, em algum momento, desligar

A parte que quase sempre falta: um processo formal para desativar um agente que já cumpriu seu propósito ou foi substituído por outro. Agentes esquecidos — ainda ligados, sem manutenção, sem dono, respondendo cada vez pior — são um dos padrões mais comuns em empresas que até têm alguma maturidade de governança, mas nunca fecharam esse ciclo até o fim.

Quem faz o quê

Uma política sem responsável nomeado é uma política que existe no papel e não em lugar nenhum. A estrutura mínima que funciona, mesmo sem uma área dedicada a governança de IA:

O dono do negócio — normalmente o gestor da área que pediu o agente, seja RH, TI ou atendimento — decide o que o agente deve responder, valida se o conteúdo está certo e atualizado, e é quem alguém procura primeiro se uma resposta parecer estranha. Sem essa pessoa, o conteúdo do agente fica parado no tempo, porque atualizar não é função de ninguém.

O dono técnico, geralmente de TI, garante que a configuração — autenticação, permissões, DLP — segue o padrão de segurança da empresa antes do lançamento e continua seguindo depois. É quem interpreta um alerta estranho e decide se uma mudança na configuração precisa passar por nova avaliação de risco.

Segurança da informação e compliance definem as regras gerais de DLP e classificação que valem para todo agente, revisam o inventário completo procurando shadow AI, e garantem alinhamento com obrigações regulatórias — no Brasil, isso passa direto pela LGPD. Esse papel não aprova cada agente individualmente; define o território dentro do qual os outros dois papéis se movem.

Para empresas com vários agentes em produção, vale ter um ponto central — nem sempre uma área nova, muitas vezes é uma responsabilidade a mais de alguém que já está em TI ou segurança — que mantém o inventário vivo, aprova o que tem risco mais alto, e revisa periodicamente se a política ainda bate com a realidade do que está rodando. Sem esse ponto central, a governança vira um PDF que alguém escreveu uma vez e nunca mais abriu.

Checklist de governança de agentes de IA

Visibilidade

• ☐ Existe inventário atualizado de todos os agentes do Copilot Studio, com dono e propósito registrados?
• ☐ Já foi avaliado o uso de ferramentas de IA externas fora do controle da empresa?
• ☐ Novo agente entra em um processo de registro antes de ir ao ar, ou cada equipe cria por conta própria?

Dados

• ☐ Documentos usados como fonte de conhecimento têm classificação de sensibilidade antes de serem conectados?
• ☐ RH, financeiro e jurídico estão isolados de agentes de escopo geral?
• ☐ Existe rotina para remover fonte de conhecimento que ficou desatualizada?

Acesso

• ☐ Todo agente usa autenticação Microsoft Entra, com exceções justificadas por escrito?
• ☐ Contas de serviço seguem o menor privilégio necessário, não o mais conveniente?
• ☐ DLP está configurado no Power Platform Admin Center para os conectores em uso?

Responsabilidade

• ☐ Cada agente em produção tem dono de negócio e dono técnico nomeados?
• ☐ Existe uma política de uso de IA que os colaboradores realmente conhecem, não só assinaram?
• ☐ Há alguém com a visão consolidada de tudo que está rodando?

Ciclo de vida

• ☐ Existe revisão programada para cada agente, não apenas quando algo dá errado?
• ☐ Logs de conversa são olhados de tempos em tempos, não só armazenados?
• ☐ Há um processo real de desativação para agentes que já cumpriram seu papel?

Para controles técnicos específicos por canal, vale complementar com o artigo sobre Copilot Studio e WhatsApp e com o panorama mais amplo de segurança Microsoft 365.

Um alerta sobre a própria governança

Vale terminar com uma ressalva que a maioria dos artigos sobre esse tema evita fazer: governança também pode ser feita mal. Um checklist preenchido uma vez e nunca revisado é tão inútil quanto não ter checklist nenhum — só dá uma falsa sensação de segurança, que às vezes é pior do que reconhecer abertamente que o controle ainda não existe. Um comitê que trava toda criação de agente atrás de semanas de aprovação também tem um custo real: empurra as áreas de negócio de volta para o caminho não governado, porque esperar seis semanas por aprovação é exatamente o tipo de fricção que faz alguém abrir uma aba anônima e resolver sozinho. Governança que funciona é rápida o suficiente para não ser contornada, e rigorosa o suficiente para pegar o que importa. Equilibrar isso é mais difícil do que qualquer checklist consegue capturar — e é, honestamente, trabalho contínuo, não um projeto que termina.

Para fechar

O que separa uma empresa que escala IA com confiança de uma que vive apagando incêndio raramente é o tamanho do orçamento de segurança. É ter respondido, cedo, três perguntas simples para cada agente: quem é o dono, o que ele pode acessar, e quem está olhando isso daqui a três meses. Empresas que resolvem essas três perguntas antes de escalar constroem uma base sobre a qual o próximo agente entra mais rápido, não mais devagar — porque o processo de aprovação já existe e já foi testado, em vez de reinventado a cada nova ideia.

Se sua empresa já tem agentes rodando e nunca fez esse levantamento — ou está prestes a criar o primeiro e quer começar do jeito certo —, a InfoB ajuda a construir esse modelo, como parceira certificada Microsoft com experiência prática de implementação, não só de leitura de política.

Perguntas frequentes

O que é shadow AI, na prática?

Um colaborador usando uma ferramenta de IA sem passar pela TI. Pode ser algo tão simples quanto colar um trecho de contrato num chatbot pessoal, ou tão sério quanto um agente do Copilot Studio que ninguém revisou. O fio comum é a empresa perder de vista onde os dados estão sendo processados.

Quem deveria responder por um agente de IA dentro da empresa?

Duas pessoas, no mínimo: alguém do negócio que decide o que o agente pode dizer e mantém o conteúdo atualizado, e alguém de TI que garante que a configuração técnica está correta. Um agente sem essas duas pessoas nomeadas é um agente que ninguém está de fato olhando.

Como saber quantos agentes já existem rodando na empresa?

Levantando o que foi criado no Copilot Studio via Power Platform Admin Center, e cruzando com uma checagem de uso de IA externa pelo navegador. Sem esse retrato inicial, qualquer política nova está sendo escrita sobre um cenário que ninguém enxerga por completo.

Bloquear o uso de IA resolve o shadow AI?

Na prática, raramente. Ferramenta nova aparece toda semana, e quem quer usar encontra um jeito. O que costuma funcionar é dar uma alternativa boa o suficiente para que ninguém sinta necessidade de contornar a regra.