O que é governança do uso de IA?
Governança do uso de IA é o conjunto de políticas, responsabilidades, controles e evidências usado para determinar e verificar como pessoas, aplicações e agentes podem usar IA em uma organização.
Essa definição operacional conecta um uso aprovado à atividade que vem depois. Ela abrange quem pode usar uma ferramenta, com qual finalidade e quais dados, o que pode ser feito com o resultado e quem revisa mudanças nessas condições. Uma ferramenta pode continuar na lista de aplicações aprovadas enquanto um novo uso exige outra decisão.
O programa de governança de IA, mais amplo, estabelece as responsabilidades da organização e os riscos aceitáveis. A governança do uso torna essas decisões aplicáveis a um fluxo de trabalho: uma pessoa preparando um documento, uma aplicação processando registros ou um agente executando uma tarefa delegada.
Por que governar o uso difere de governar o modelo
A avaliação de um modelo pode produzir evidências sobre sua adequação a uma tarefa. Ela não estabelece que um funcionário específico pode enviar determinado documento ou compartilhar a análise resultante com determinado público. Essas decisões dependem do contexto de uso, inclusive de informações que o próprio modelo talvez nunca receba.
As duas formas de governança continuam conectadas. Mudar a finalidade de uma aplicação pode exigir outra avaliação do modelo e permissões diferentes. Da mesma forma, manter o modelo não preserva uma aprovação quando o fluxo de trabalho muda. O AI RMF Playbook do NIST, em MAP 1.1, enfatiza a documentação da finalidade prevista, dos usuários e do contexto de implantação. A questão prática é quais premissas daquela revisão continuam válidas para a atividade realizada.
Uma ferramenta aprovada, um contexto diferente
Exemplo hipotético: uma equipe de compras aprova uma aplicação de IA, acessada por uma conta gerenciada pela organização, para elaborar comparativos internos a partir de descrições públicas de produtos. Depois, um analista quer acrescentar preços negociados com fornecedores e enviar o comparativo pronto a potenciais fornecedores.
A aplicação e o modelo não mudaram. Os dados de entrada e o público pretendido, sim. A aprovação original não cobre essas mudanças apenas porque a interface é familiar. As decisões abaixo ilustram condições para esse fluxo hipotético; não são funcionalidades da KonaSense nem achados em um ambiente de cliente.
| Uso ou mudança proposta | Decisão necessária na organização | Evidências relevantes para a decisão |
|---|---|---|
| Elaborar um comparativo interno a partir de descrições públicas | Confirmar que a atividade atende à finalidade aprovada e às condições de uso da conta | Referências das fontes, aprovação aplicável e contexto disponível da conta |
| Acrescentar preços negociados | Determinar se esses dados podem ser processados nessa aplicação e configuração | Decisão do responsável pelos dados e condições aplicáveis ao processamento |
| Enviar o comparativo a fornecedores | Decidir quais informações podem ser divulgadas e quem precisa revisá-las | Versão revisada, destinatários previstos e autorização para divulgação |
O responsável pelos dados pode decidir se os termos negociados podem entrar na aplicação. Quem responde pela comunicação com fornecedores pode revisar a divulgação proposta. O responsável pela aplicação precisa estabelecer quais configurações e controles sustentam cada decisão. A aprovação de um desses papéis não deve substituir implicitamente as demais.
Quem e o que usa IA dentro de uma empresa
A forma de acesso muda os pontos em que uma condição pode ser aplicada e as evidências disponíveis. O mesmo fluxo pode atravessar várias superfícies; identificar apenas a aplicação desktop não descreve um agente incorporado a ela ou um serviço conectado.
IA no navegador
Revise a aplicação, a conta, a funcionalidade e o material enviado pelo navegador. Uma regra que permite pesquisar informações públicas pode exigir uma verificação diferente daquela que exige uma conta gerenciada pela organização. O nome de domínio da aplicação não expressa integralmente nenhuma dessas condições.
IA em aplicações desktop
Examine os arquivos, as pastas, os conectores e outros elementos de contexto disponíveis à aplicação. Ter permissão para abrir um documento local e poder enviar seu conteúdo a outro serviço são questões distintas. A telemetria exportada pode ajudar a descrever a atividade, mas seus campos precisam ser examinados antes de usá-la como evidência dos dados processados.
Assistentes de código
Distinga o acesso ao contexto do projeto, a geração de uma sugestão e sua incorporação ao código. Aprovar um repositório para um assistente não estabelece automaticamente permissão para incluir credenciais, projetos não relacionados ou arquivos restritos. Revise a configuração e o fluxo reais, em vez de tratar a instalação como o limite da aprovação.
Agentes de CLI
Identifique o ambiente de trabalho e a identidade cujas permissões o processo utiliza. Pedir a explicação de um comando e conceder autoridade para executá-lo produzem efeitos diferentes. Para ferramentas que delegam a execução, a governança de agentes de IA detalha os acessos às ferramentas, as aprovações e as evidências das ações.
Fluxos autônomos
Defina um responsável pelo trabalho que continua sem uma pessoa iniciar cada passo. Documente suas fontes de entrada, destinos permitidos, condições de operação e formas de suspensão. Um processo agendado também precisa ser revisto quando mudam sua fonte de dados, suas permissões ou sua finalidade; executar sem acompanhamento contínuo não elimina essa responsabilidade.
A política de dados também abrange as saídas
Uma política de uso precisa acompanhar as informações ao longo do trabalho, inclusive depois que o modelo retorna um resultado. No exemplo de compras, autorizar a aplicação a processar preços negociados não autorizaria, por si só, a divulgação desses preços a outros fornecedores. Um comparativo gerado pode levar adiante informações presentes nos dados de entrada.
A política deve, portanto, distinguir permissão para processar de permissão para divulgar. Especifique o público permitido, o local de armazenamento e a revisão exigida para a saída. Se pessoas usam o resultado para tomar uma decisão, defina a revisão adequada àquela finalidade. A permissão para gerar um rascunho não comprova que suas afirmações foram conferidas nas fontes.
O tratamento das informações também se aplica ao processo de governança. Um coletor de prompts ou registro de investigação pode criar outra cópia do material governado. Decida quais evidências são necessárias, quem pode acessá-las e por quanto tempo devem ser mantidas. Um histórico completo de conversa não é automaticamente necessário para verificar uma aprovação ou decisão de divulgação específica.
A descoberta fornece contexto para a decisão sobre o uso
A descoberta pode revelar uma aplicação ou interação. A governança do uso precisa relacioná-la às condições relevantes para a tarefa. Um registro da aplicação, um registro de identidade e uma aprovação podem descrever escopos ou momentos diferentes. É preciso estabelecer a relação entre eles antes de reuni-los em uma conclusão.
Para ferramentas conhecidas, mantenha os usos aprovados junto ao inventário de aplicações. Inclua o responsável e as condições que exigiriam outra revisão. Isso permite avaliar uma mudança de uso sem transformar cada interação em um novo processo de aquisição nem tratar a compra inicial como permissão para tudo o que vier depois.
Quando a aprovação ou a atividade relevante for desconhecida, preserve essa incerteza e atribua a questão a alguém que possa resolvê-la. O pilar sobre Shadow AI aborda a investigação de sinais incompletos e de usos fora da aprovação ou gestão. Um campo ausente não deve virar uma conclusão de uso aceitável nem uma alegação de divulgação de informações.
Faça a política considerar o contexto relevante
Uma política que considera o contexto usa os fatos necessários à decisão. No fluxo de compras, eles incluem o material de origem, as condições aprovadas de processamento e os destinatários previstos. Um identificador de dispositivo pode ajudar a localizar a atividade, mas não estabelece a finalidade de negócio nem autoriza uma divulgação.
Separe a finalidade declarada das observações técnicas e de uma decisão tomada por alguém autorizado. O analista pode explicar a tarefa. Uma integração pode informar a aplicação e o conteúdo enviado. Um responsável designado decide se o uso proposto atende à política. Alguns fatos podem ser verificados automaticamente; outros exigem uma revisão com responsável definido. Indique qual tipo de evidência sustenta cada condição.
Uma exceção deve identificar a mudança específica que permite, seu responsável e seus limites. Se dados confidenciais forem aprovados para um comparativo interno, a exceção não deve se estender implicitamente à distribuição externa. O próximo usuário ou revisor precisa conseguir entender o que continua restrito sem reconstruir a discussão original.
Aplique cada condição em um ponto capaz de produzir efeito
Condições diferentes exigem pontos de implementação diferentes. O acesso à aplicação pode ser limitado pelos mecanismos disponíveis de identidade e permissão. O envio de dados pode ser verificado por uma integração compatível no caminho de entrada. A revisão de um documento destinado a compartilhamento externo precisa fazer parte de um processo capaz de reter essa divulgação. Não atribua a um controle efeitos fora da etapa que ele governa.
Valide tanto o uso permitido quanto um uso que deveria receber outro tratamento. Para o comparativo hipotético, verifique como entradas restritas são tratadas e se uma saída não revisada pode chegar aos destinatários propostos. Identifique os caminhos não cobertos pela validação. Essas são verificações propostas, não testes realizados para esta página.
A governança de IA em runtime contribui nos pontos em que uma política é avaliada durante uma interação ou ação. Essa avaliação ainda precisa do contexto adequado e de um componente capaz de aplicar a decisão. Os processos de revisão e as permissões continuam relevantes nas demais etapas do fluxo; a existência de uma verificação em runtime não completa o programa de governança do uso.
Mantenha evidências que sustentem a próxima revisão
Um registro útil conecta as condições aprovadas ao uso examinado. Ele identifica a aplicação e a configuração relevantes, a origem das evidências de atividade, a decisão ou exceção aplicada e o que foi possível verificar sobre o resultado. Mantenha distinguíveis a aprovação, a atividade observada e a saída revisada para que outro revisor veja a qual pergunta cada registro responde.
Reavalie as condições quando mudarem as entradas, os destinatários, as permissões, o comportamento da aplicação ou a finalidade de negócio. O AI RMF Playbook do NIST, em GOVERN 1.5, orienta planejar monitoramento e revisões periódicas com responsabilidades definidas. O intervalo de revisão deve refletir o uso e seus riscos; um lembrete no calendário não substitui a revisão de uma mudança relevante.
Para a equipe de compras, o resultado útil é uma descrição clara de quais comparativos continuam dentro da aprovação, quais precisam de revisão e quem responde pelas questões pendentes. O volume de atividade, sozinho, não demonstra que as condições foram respeitadas. Os relatórios devem preservar o período, a fonte das evidências e os limites de cobertura que sustentam suas conclusões.
Como a KonaSense aborda a governança do uso de IA
A KonaSense oferece caminhos de integração diferentes para o uso de IA. Seu papel deve ser avaliado conforme as condições do fluxo, sem presumir que ofereçam coberturas equivalentes.
O Kona for Browser permite avaliar prompts conforme políticas em aplicações de IA na web compatíveis. Sua documentação de privacidade, em inglês, descreve o envio do conteúdo do prompt ao tenant KonaSense da organização para avaliação. A intervenção disponível depende da integração, da configuração e do modo de inspeção.
Para fluxos com agentes, o Kona for Agents conecta eventos de runtime compatíveis à avaliação de políticas. No caminho PreToolUse da implementação do adaptador Claude Code revisada para esta página, uma negativa pode ser devolvida como negação do uso da ferramenta, e um encaminhamento para aprovação como pedido de aprovação ao usuário. Essa implementação retorna Allow quando a avaliação falha; seu comportamento não deve ser generalizado para outros runtimes ou instalações.
O caminho de ingestão de traces OTLP de aplicações desktop examinado processa eventos exportados em segundo plano e retorna uma resposta OTLP sem decisão de intervenção para a aplicação. O contexto disponível depende dos atributos exportados. Esse caminho pode contribuir com evidências de atividade, mas não deve ser apresentado como mecanismo para impedir a operação registrada.
Esses mecanismos apoiam partes de um processo de governança. A organização ainda precisa definir os usos permitidos, atribuir decisões aos responsáveis adequados e verificar os controles e as evidências disponíveis em cada fluxo.