Arquitetura de IA

Plugins de IA nas empresas: como governar

Aprenda a avaliar e governar plugins de IA nas empresas com inventário, permissões, dados, testes, aprovação, monitoramento e plano de retirada.

Um plugin pequeno pode receber uma autoridade grande

Uma equipe instala um plugin para resumir documentos. Outra conecta um aplicativo ao calendário para preparar reuniões. O comercial aprova uma extensão que lê e-mails e cria registros no CRM. A instalação leva minutos. A permissão concedida pode permanecer por meses, alcançar milhares de registros e continuar ativa depois que o uso perdeu valor.

O ponto crítico aparece na distância entre a interface e a consequência. Para o usuário, o plugin parece uma função adicional dentro de uma ferramenta conhecida. Para a empresa, ele pode representar um novo fornecedor, uma identidade com acesso contínuo, um caminho de saída de dados e uma capacidade de executar ações.

A governança de plugins de IA nas empresas precisa acompanhar esse alcance. O trabalho inclui descobrir o que está instalado, entender a tarefa, delimitar dados e ações, testar o comportamento, registrar o responsável e retirar acesso quando a finalidade termina.

O Shadow AI ajuda a localizar usos sem visibilidade. Este guia trata do passo seguinte: como administrar o ciclo de vida de plugins, extensões e aplicativos conectados que a empresa decidiu avaliar ou permitir.

O que entra na categoria de plugin de IA

O nome varia entre fornecedores. A mesma arquitetura pode aparecer como:

  • plugin instalado em um workspace corporativo;
  • aplicativo disponível em um diretório interno;
  • extensão de navegador;
  • conector com e-mail, calendário, documentos ou CRM;
  • integração OAuth;
  • recurso de IA ativado dentro de um SaaS;
  • servidor MCP adicionado a um cliente de IA;
  • bot instalado em chat ou reunião;
  • automação que expõe ações administrativas em linguagem natural;
  • skill ou pacote que amplia as capacidades de um agente.

A etiqueta comercial importa menos que três perguntas:

  1. Que informação o componente consegue ler?
  2. Que consequência consegue produzir?
  3. Em nome de qual identidade ele opera?

Uma extensão que só transforma texto selecionado possui uma fronteira diferente de um plugin capaz de consultar membros, alterar grupos, aprovar gastos ou modificar configurações. A governança deve seguir a autoridade efetiva, não o tamanho aparente da função.

Plugin, ferramenta do agente e integração cumprem papéis próximos

Um plugin costuma empacotar várias capacidades para uso dentro de uma interface. Uma ferramenta de agente representa uma operação executável, como consultar uma oportunidade ou criar uma tarefa. Uma integração conecta sistemas e transporta dados ou comandos entre eles.

Essas camadas podem coexistir. Um plugin administrativo pode expor diversas ferramentas e usar integrações com diretório, faturamento e comunicação. Por isso, aprovar o nome do produto não resolve a análise.

O catálogo de ferramentas para agentes de IA decompõe capacidades por verbo, efeito, identidade, entrada, saída e confirmação. O catálogo de plugins deve apontar para essas operações quando o componente consegue agir.

Comece pela tarefa, antes de olhar o diretório

Diretórios de plugins incentivam comparação por recurso. A empresa precisa começar pela unidade de trabalho.

Considere um pedido para instalar um plugin que “ajuda na administração do workspace”. Essa descrição pode esconder tarefas distintas:

  • gerar relatório de uso;
  • identificar contas inativas;
  • revisar permissões efetivas;
  • adicionar pessoa a um grupo;
  • ajustar limite de consumo;
  • aprovar solicitação de gasto;
  • remover membro;
  • alterar configuração global.

Cada tarefa exige dado, autoridade e evidência próprios. A solicitação inicial deve registrar:

  • problema atual;
  • usuário ou área solicitante;
  • frequência;
  • sistemas envolvidos;
  • dados necessários;
  • saída esperada;
  • ações pretendidas;
  • impacto de uma ação errada;
  • alternativa atual;
  • dono operacional.

Sem essa ficha, a avaliação corre o risco de aprovar uma superfície ampla para resolver uma tarefa estreita.

Faça um inventário por instalação e por uso

Uma lista de produtos contratados não mostra todas as instalações. Um mesmo plugin pode existir em vários workspaces, grupos ou contas, com permissões diferentes.

Registre pelo menos:

| Campo | O que precisa ficar visível | |---|---| | componente | nome, fornecedor, versão ou canal de distribuição | | instalação | workspace, ambiente, grupo e administrador responsável | | finalidade | tarefa e unidade de trabalho atendida | | usuários | quem pode usar e quem pode administrar | | identidade | conta do usuário, conta de serviço ou identidade do processo | | dados | categorias acessadas e sistemas de origem | | ações | leitura, preparação, escrita, comunicação ou administração | | permissões | escopos concedidos e restrições aplicadas | | decisão | aprovado, limitado, em teste, suspenso ou retirado | | validade | data de revisão e condição de renovação | | evidência | logs, testes, contrato e responsável pela aprovação |

Mantenha duas visões. A primeira mostra todos os componentes instalados. A segunda mostra os usos autorizados. Um plugin pode estar tecnicamente disponível e ainda ter uso permitido apenas para uma tarefa, área ou classe de dado.

Leia as permissões como capacidade de negócio

Escopos técnicos costumam ser difíceis de interpretar. Converta cada permissão em uma consequência legível.

Em vez de registrar apenas read:users, explique que o componente pode consultar nome, e-mail, grupo, status e atividade de membros. Em vez de write:settings, liste quais configurações podem mudar e qual alcance cada alteração possui.

Classifique as capacidades.

Leitura de baixa sensibilidade

Consulta catálogo público, documentação aprovada ou metadados sem conteúdo protegido.

Leitura de contexto interno

Acessa e-mails, calendários, documentos, tickets, código, relatórios de uso ou informações de pessoas.

Preparação sem efeito externo

Produz relatório, recomendação, rascunho ou pedido estruturado para revisão.

Escrita reversível

Cria registro, tarefa, grupo temporário ou configuração que pode ser desfeita com confirmação.

Alteração de acesso ou política

Concede permissão, modifica grupo, habilita recurso, muda limite ou altera regra aplicável a usuários.

Ação crítica

Remove identidade, amplia privilégio, autoriza gasto relevante, altera configuração global ou produz efeito difícil de reverter.

A matriz de autonomia para agentes ajuda a relacionar impacto, reversibilidade e evidência à autoridade concedida.

Separe permissão técnica de autorização operacional

Um plugin pode ter permissão técnica para alterar grupos porque essa função faz parte do produto. Isso não significa que qualquer instrução enviada pela interface esteja autorizada.

Use uma camada de política que avalie:

  • identidade solicitante;
  • papel atual;
  • objeto afetado;
  • ambiente;
  • finalidade;
  • alçada;
  • segregação de funções;
  • aprovação necessária;
  • janela de mudança;
  • estado atual;
  • risco de propagação;
  • condição de reversão.

A ação deve ser bloqueada quando o pedido ultrapassa a autoridade, mesmo que o modelo produza uma justificativa convincente. Para alterações relevantes, mostre o objeto, o estado atual, a mudança proposta, o alcance e o aprovador antes da execução.

Os guardrails para agentes de IA organizam essas barreiras entre pedido, contexto, ferramenta, confirmação e saída.

Avalie o caminho completo dos dados

A tela principal raramente mostra todo o fluxo. O componente pode enviar informação para modelos, serviços de observabilidade, bancos, subfornecedores e sistemas de suporte.

Mapeie:

  1. dado coletado;
  2. origem;
  3. finalidade;
  4. transformação;
  5. fornecedor e subfornecedor;
  6. região de processamento;
  7. armazenamento e logs;
  8. retenção;
  9. uso para treinamento ou melhoria;
  10. exportação e exclusão;
  11. retorno ao sistema oficial.

Confirme se o escopo muda entre consulta manual, automação recorrente e ação administrativa. Um recurso pode aplicar condições diferentes conforme produto, plano, região ou configuração.

Promessas como Zero Data Retention precisam ser avaliadas no serviço e no endpoint realmente usados. Uma política ampla do fornecedor não prova que cada plugin, log e subserviço segue a mesma regra.

Verifique identidade, instalação e administração

A empresa precisa saber quem instalou, quem usa e quem consegue mudar o componente.

Controles básicos incluem:

  • autenticação corporativa;
  • instalação restrita a administradores autorizados;
  • aprovação por grupo ou função;
  • conta de serviço exclusiva quando necessária;
  • proibição de credenciais pessoais compartilhadas;
  • escopos mínimos;
  • credenciais curtas quando disponíveis;
  • rotação e revogação;
  • separação entre teste e produção;
  • revisão periódica de administradores;
  • retirada automática no offboarding.

O plugin deve operar com a identidade e as permissões aplicáveis à ação. Se a ferramenta mascara tudo sob uma conta administrativa genérica, a empresa perde atribuição e tende a conceder alcance excessivo.

O guia de identidade e credenciais para agentes detalha contas, escopos, rotação e encerramento.

Teste antes de liberar para o workspace

Uma demonstração prova que o caminho feliz existe. A homologação precisa testar fronteiras.

Casos funcionais

  • pedido válido de leitura;
  • relatório com fontes e período corretos;
  • alteração reversível dentro da alçada;
  • confirmação no sistema de destino;
  • resposta quando faltam dados.

Casos de permissão

  • usuário sem papel necessário;
  • solicitação em nome de outra pessoa;
  • objeto fora do grupo permitido;
  • tentativa de ampliar o próprio acesso;
  • aprovação ausente ou vencida;
  • ambiente errado;
  • conflito de segregação de funções.

Casos de falha

  • API indisponível;
  • timeout antes da confirmação;
  • ação parcialmente concluída;
  • pedido repetido;
  • dado alterado entre leitura e escrita;
  • fila acumulada;
  • resposta ambígua do destino.

Casos adversariais

  • documento tenta instruir o plugin a chamar outra ação;
  • mensagem inclui identificador de outro cliente;
  • usuário pede para ignorar a política;
  • conteúdo tenta obter dado fora da finalidade;
  • instrução induz alteração em lote.

O ambiente de teste para agentes de IA ajuda a isolar credenciais, destinos e dados antes da liberação.

Libere por alcance e evidência

Evite a instalação global como primeiro passo. Comece com:

  • grupo pequeno;
  • tarefa delimitada;
  • dados permitidos;
  • ações de leitura ou preparação;
  • período de teste;
  • revisão humana;
  • volume limitado;
  • métricas e bloqueios definidos.

A progressão pode seguir leitura, recomendação, escrita reversível e alteração administrativa. Cada avanço precisa de evidência sobre qualidade, uso, falhas, correções e valor.

A implantação canário para agentes oferece um desenho para ampliar versões e capacidades sem expor toda a operação de uma vez.

Registre pedido, decisão, ação e confirmação

Logs precisam permitir reconstruir uma mudança. Para cada execução relevante, preserve de forma proporcional:

  • identidade solicitante;
  • plugin e versão;
  • finalidade e tarefa;
  • instrução recebida;
  • dados ou objetos consultados;
  • política aplicada;
  • ação proposta;
  • aprovação;
  • ferramenta chamada;
  • estado anterior e novo;
  • confirmação do destino;
  • falha ou pendência;
  • custo e duração;
  • identificador de rastreamento.

Proteja dados sensíveis nos registros. Auditoria não exige copiar todo conteúdo para sempre. Exige evidência suficiente para demonstrar quem fez o quê, sob qual autoridade e com qual resultado.

O log de auditoria para agentes de IA ajuda a definir eventos, integridade, acesso e retenção.

Monitore valor e exposição

Acompanhe quatro grupos de indicadores.

Adoção

  • usuários elegíveis e ativos;
  • tarefas concluídas;
  • recorrência por área;
  • abandono e motivo;
  • solicitações atendidas fora do plugin.

Qualidade

  • resultados aceitos;
  • correções humanas;
  • ações recusadas;
  • confirmações ausentes;
  • casos reabertos;
  • erros por classe.

Risco

  • permissões amplas sem uso;
  • acessos fora do padrão;
  • tentativas bloqueadas;
  • instalações não aprovadas;
  • administradores sem revisão;
  • incidentes e quase incidentes.

Economia

  • licenças atribuídas e ativas;
  • consumo por unidade de trabalho;
  • tempo humano restante;
  • custo de integração e suporte;
  • custo por resultado válido;
  • ferramentas redundantes.

Uso alto pode indicar valor ou apenas disponibilidade. Ligue atividade ao processo concluído e ao resultado que justificou a instalação.

Prepare renovação, mudança e retirada

Plugins envelhecem. O fornecedor altera permissões, modelo, subcontratados, preço, contrato ou comportamento. A empresa também muda sistemas e prioridades.

Defina eventos de revisão:

  • nova permissão solicitada;
  • mudança material de termos;
  • alteração no tratamento de dados;
  • novo subfornecedor;
  • expansão para outra área;
  • ação administrativa adicionada;
  • incidente;
  • queda de uso;
  • aumento de custo;
  • troca de dono;
  • vencimento contratual.

Na retirada:

  1. interrompa novas instalações;
  2. identifique usuários e workflows dependentes;
  3. exporte registros necessários;
  4. conclua ou transfira unidades pendentes;
  5. remova autorizações OAuth e tokens;
  6. desative contas de serviço;
  7. confirme exclusão conforme contrato;
  8. revise logs e cópias locais;
  9. atualize inventário e política;
  10. valide que nenhuma automação continua chamando o componente.

Desinstalar a interface sem revogar acesso deixa uma porta fechada só na aparência.

Responsabilidades precisam permanecer legíveis

Área solicitante

Explica a tarefa, valida a utilidade e nomeia o dono operacional.

Tecnologia ou segurança

Avalia identidade, instalação, permissões, integração, registros e contenção.

Privacidade, jurídico ou compliance

Analisa dados, finalidade, contrato, subfornecedores e obrigações aplicáveis.

Compras e financeiro

Consolida preço, renovação, consumo, dependências e condição de saída.

Dono do processo

Responde pelo resultado, pelas exceções e pela decisão de continuar, ampliar ou retirar.

Administrador do workspace

Aplica configurações aprovadas, preserva evidência e não substitui a autoridade do dono do processo.

Empresas menores podem acumular papéis. A decisão ainda precisa ter responsável, data e evidência.

Checklist para aprovar um plugin de IA

  • [ ] A tarefa e a unidade de trabalho estão definidas?
  • [ ] Existe dono operacional?
  • [ ] Instalação, usuários e administradores estão inventariados?
  • [ ] As permissões foram traduzidas em consequências de negócio?
  • [ ] Dados, sistemas e subfornecedores estão mapeados?
  • [ ] A identidade executora e os escopos são mínimos?
  • [ ] Autorização operacional é verificada além da permissão técnica?
  • [ ] Ações críticas exigem prévia e aprovação?
  • [ ] Testes cobrem falha, repetição, abuso e estado incerto?
  • [ ] A liberação começa com grupo e capacidades limitadas?
  • [ ] Toda ação relevante recebe confirmação do destino?
  • [ ] Logs preservam atribuição sem copiar dados em excesso?
  • [ ] Métricas ligam uso a resultado e custo?
  • [ ] Mudanças de permissão ou contrato disparam nova revisão?
  • [ ] Existe procedimento de retirada e revogação?

Governar o plugin significa governar sua autoridade

Plugins tornam recursos empresariais acessíveis dentro de uma conversa ou interface familiar. Isso reduz atrito e encurta tarefas. Também esconde parte da arquitetura que consulta dados, decide políticas e executa mudanças.

A empresa precisa tratar cada instalação como uma capacidade operacional. Comece pela tarefa, decomponha permissões, separe acesso de autoridade, teste as fronteiras e amplie por evidência. Quando o uso deixar de justificar a exposição, retire o componente e confirme a revogação.

A conveniência permanece útil quando dado, ação, identidade, dono e evidência continuam visíveis.