A adoção de Inteligência Artificial nas empresas está criando um desafio importante para as arquiteturas tradicionais de segurança. Durante muito tempo, conseguimos organizar boa parte dos controles em torno de identidades, dispositivos, aplicações, redes e informações. A IA não elimina essas dimensões, mas cria novas relações entre elas, especialmente quando deixa de ser apenas uma ferramenta de consulta e passa a participar de processos corporativos, acessar dados e executar ações.
Uma pessoa pode utilizar um chatbot corporativo para resumir documentos, uma extensão de navegador para analisar páginas, uma ferramenta de desenvolvimento para gerar código ou um agente capaz de consultar aplicações e executar tarefas. Em todos esses casos, existe uma relação entre uma identidade humana, uma tecnologia de IA e algum conjunto de informações ou recursos corporativos.
O problema é que essa relação raramente aparece de forma completa nas ferramentas tradicionais de segurança.
Uma solução de CASB pode identificar o acesso a uma aplicação de IA. O DLP pode detectar uma tentativa de compartilhar informação sensível. O IAM pode mostrar quais permissões aquela identidade possui. O EDR pode fornecer contexto sobre o dispositivo utilizado. Uma plataforma de conscientização pode indicar se aquela pessoa recebeu treinamento sobre uso seguro de IA.
Cada ferramenta observa uma parte do problema. Nenhuma dessas informações, isoladamente, representa necessariamente o risco completo. É justamente nessa correlação que Human Risk Management pode assumir um papel importante.
O conceito de Shadow AI normalmente está associado ao uso de ferramentas de Inteligência Artificial sem conhecimento, aprovação ou governança adequada da organização. Isso pode incluir chatbots públicos, extensões de navegador, aplicações SaaS com funcionalidades de IA, APIs externas e ferramentas utilizadas diretamente por equipes de negócio. O primeiro desafio é descobrir essas aplicações.
Dependendo da arquitetura existente, soluções de Secure Web Gateway, CASB, SSE, DNS Security e outras ferramentas de monitoramento de tráfego podem ajudar a identificar acessos a serviços de IA. Em ambientes corporativos, também é possível utilizar mecanismos de descoberta de aplicações e controles específicos para serviços autorizados ou não autorizados. Essa visibilidade é importante, mas possui limitações.
Identificar que determinada pessoa acessou uma ferramenta de IA não significa que houve compartilhamento de informação sensível. Da mesma maneira, identificar uma aplicação autorizada não significa que todas as interações realizadas nela são seguras.
Uma organização pode bloquear ferramentas desconhecidas e ainda enfrentar riscos relevantes dentro de aplicações oficialmente aprovadas. O inverso também é verdadeiro: o acesso a uma aplicação não autorizada pode representar uma violação de política sem necessariamente envolver exposição de informações críticas.
Por isso, descobrir Shadow AI é apenas a primeira etapa. Para compreender risco, precisamos avançar da identificação da aplicação para o contexto de sua utilização.
Uma arquitetura de HRM orientada ao uso de IA precisa começar pela identidade. Isso acontece porque as diferentes fontes técnicas normalmente representam a mesma pessoa de maneiras distintas. Uma ferramenta pode registrar um endereço de e-mail, outra utiliza o identificador do Microsoft Entra ID, uma terceira registra um usuário local e outra associa o evento a um dispositivo.
Sem resolver essas diferenças, podemos acabar interpretando eventos relacionados à mesma pessoa como se pertencessem a identidades diferentes.
O problema se torna mais complexo quando incluímos contas administrativas, identidades de serviço, tokens de API e agentes de IA. Uma pessoa pode possuir diversas contas, utilizar diferentes aplicações e autorizar integrações que continuam funcionando mesmo quando ela não está diretamente interagindo com o sistema.
Por isso, a arquitetura precisa manter relações entre a identidade humana e os recursos associados a ela.
Uma representação inicial pode conectar a pessoa às suas contas corporativas, aos dispositivos utilizados, às aplicações acessadas e aos privilégios concedidos. A partir daí, podemos acrescentar ferramentas de IA, integrações e agentes relacionados àquela identidade.
Essa estrutura permite responder perguntas que um log isolado dificilmente conseguiria esclarecer. Quem está utilizando determinada aplicação? Qual função essa pessoa exerce? Quais dados normalmente acessa? Possui privilégios elevados? É responsável por algum agente? A aplicação utiliza permissões delegadas ou uma identidade própria? Essas relações são fundamentais para transformar eventos técnicos em contexto de risco.
Nem todas as ferramentas de Inteligência Artificial apresentam a mesma exposição. Uma aplicação utilizada apenas para gerar textos públicos possui características diferentes de uma ferramenta conectada ao repositório de código-fonte da empresa. Um chatbot sem acesso a dados corporativos representa uma superfície diferente de um assistente integrado ao Microsoft 365. Um agente que apenas consulta documentos possui capacidades diferentes de outro autorizado a modificar registros ou executar transações.
Isso significa que a classificação da aplicação não deveria considerar apenas seu nome ou fornecedor. Precisamos compreender suas capacidades, integrações e permissões. Entre os atributos relevantes estão os tipos de informação acessíveis, os mecanismos de autenticação utilizados, a existência de integrações com aplicações corporativas, a possibilidade de executar ações e o nível de autonomia permitido.
Também é importante distinguir permissões concedidas diretamente à aplicação daquelas utilizadas em nome de uma pessoa. Uma integração que utiliza permissões delegadas pode depender do contexto da identidade humana. Outra que utiliza permissões próprias pode continuar executando operações independentemente da sessão daquele usuário.
Essas diferenças modificam significativamente o impacto potencial de um comprometimento ou de uma configuração inadequada. Em outras palavras, o risco de uma aplicação de IA não depende apenas de sua utilização. Depende também daquilo que ela está tecnicamente autorizada a fazer.
[](#fale-com-especialista)
Considere dois eventos aparentemente semelhantes: duas pessoas enviam arquivos para uma ferramenta de IA. No primeiro caso, o arquivo contém informações públicas que serão utilizadas para produzir um material de marketing. No segundo, contém informações financeiras confidenciais ou dados pessoais protegidos.
A ação técnica pode ser muito parecida. O risco não é. É por isso que a integração entre HRM e controles de proteção de dados se torna importante. Ferramentas de DLP e classificação de informações podem contribuir com sinais sobre sensibilidade, tipo de conteúdo, política aplicável e resultado de uma tentativa de compartilhamento. Dependendo do ambiente, também podem indicar se determinada operação foi permitida, bloqueada ou submetida a uma justificativa.
O HRM não precisa necessariamente receber o conteúdo integral do arquivo para utilizar essas informações. Em muitos casos, um evento normalizado contendo a classificação, a aplicação envolvida, a identidade, a ação observada e o resultado do controle já fornece contexto suficiente.
Essa abordagem reduz a necessidade de replicar informações sensíveis e evita transformar a plataforma de gestão de risco humano em mais um repositório de dados corporativos. O objetivo é compreender a exposição associada ao comportamento, não armazenar tudo aquilo que a pessoa compartilhou.
Até aqui, estamos falando principalmente de aplicações utilizadas diretamente por pessoas. A arquitetura começa a mudar quando incluímos agentes capazes de executar tarefas com algum grau de autonomia.
Um agente pode consultar documentos, interagir com APIs, atualizar registros, produzir relatórios ou acionar outros sistemas. Dependendo de sua implementação, pode utilizar permissões delegadas de uma pessoa, credenciais próprias ou identidades não humanas criadas especificamente para sua operação.
Isso cria uma relação que precisa ser representada explicitamente. Não basta saber que determinado funcionário utiliza uma ferramenta de IA. Precisamos compreender se existe um agente associado, quem é seu responsável, quais identidades ele utiliza, quais recursos consegue acessar e quais ações está autorizado a executar.
Um agente também pode representar risco mesmo quando seu responsável humano apresenta comportamento adequado em treinamentos e simulações. Permissões excessivas, configurações inadequadas, exposição de credenciais ou integrações inseguras podem criar risco independentemente de uma falha comportamental recente. Por isso, considero importante manter uma distinção entre o risco associado à identidade humana e o risco associado ao agente.
O HRM pode utilizar a relação com agentes como parte do contexto de exposição e impacto da pessoa. Entretanto, a avaliação técnica do agente precisa considerar características próprias, como autonomia, permissões, recursos acessíveis, controles de execução e capacidade de produzir ações com impacto.
Essa separação evita que o Human Risk Score se transforme em um indicador genérico para qualquer tipo de identidade.
Imagine uma pessoa responsável por um agente que possui acesso a informações comerciais e consegue atualizar registros em um CRM. Se analisarmos apenas o comportamento humano, talvez encontremos uma identidade com bom histórico de conscientização, baixo índice de interação com phishing e utilização adequada dos mecanismos de reporte.
Se analisarmos apenas o agente, podemos identificar permissões amplas, acesso a informações sensíveis e capacidade de executar determinadas ações. Mas a análise mais interessante surge quando relacionamos os dois.
Quem pode modificar as instruções do agente? Quem pode conceder novos acessos? O agente executa ações mediante aprovação humana? Quais sistemas são alcançáveis? Existe possibilidade de utilizar dados de uma aplicação para executar ações em outra? Uma identidade humana comprometida permitiria alterar o comportamento ou as permissões do agente? Essas perguntas ajudam a compreender o alcance potencial de um incidente.
A análise também precisa considerar o caminho inverso. Um agente comprometido ou manipulado pode executar ações em nome de uma pessoa, produzir informações incorretas ou utilizar permissões concedidas anteriormente.
Nesse cenário, a identidade humana e a identidade do agente possuem riscos próprios, mas também criam riscos decorrentes da relação entre elas. Essa é uma das razões pelas quais modelos de risco baseados apenas em eventos individuais podem se tornar insuficientes.
Uma maneira de representar tecnicamente esse problema é construir uma cadeia de contexto:
**Pessoa → Identidade → Aplicação de IA → Dados → Permissões → Agente → Ação → Impacto**
Essa cadeia não precisa representar uma sequência obrigatória. Nem toda utilização de IA envolve agentes, e nem toda ação percorre todas essas etapas. Ela funciona como um modelo para identificar quais relações precisam ser compreendidas.
A pessoa fornece contexto organizacional, responsabilidades e comportamento. A identidade representa contas e mecanismos de autenticação. A aplicação de IA indica o serviço utilizado. Os dados mostram quais informações podem estar envolvidas. As permissões definem o que a aplicação ou agente consegue acessar. O agente representa capacidades de execução. As ações mostram o que efetivamente aconteceu, enquanto o impacto ajuda a estimar as possíveis consequências.
Na prática, essa estrutura pode ser implementada por meio de um modelo de entidades e relacionamentos, alimentado por diferentes fontes de telemetria. O valor não está em construir um inventário visualmente sofisticado. Está em conseguir responder perguntas relevantes a partir dessas relações.
Se uma identidade humana for comprometida, quais aplicações de IA e agentes podem ser afetados? Se uma aplicação apresentar comportamento suspeito, quais pessoas e dados estão relacionados a ela? Se um agente receber permissões adicionais, qual exposição foi criada? Se uma ferramenta de IA começar a interagir com informações mais sensíveis, quais controles precisam ser reavaliados?
Essas perguntas aproximam a arquitetura de HRM de uma visão contextualizada de risco.
Para que esse modelo funcione, não basta conectar ferramentas e acumular eventos. Precisamos de uma camada de normalização. Um evento proveniente de DLP possui estrutura diferente de um registro de IAM ou de um alerta de CASB. Para correlacioná-los, é necessário transformar essas informações em atributos comuns, preservando identidade, origem, tipo de evento, recurso envolvido, classificação, severidade, horário e outros elementos relevantes.
Também precisamos distinguir eventos de estados. Uma tentativa de compartilhamento de informação é um evento. Uma permissão administrativa concedida a um agente é um estado que pode permanecer ativo durante meses. O acesso recorrente a uma aplicação de IA representa um padrão de utilização, enquanto a criação de uma nova integração pode representar uma mudança de exposição.
Misturar essas dimensões sem tratamento adequado produz modelos de risco instáveis. A arquitetura precisa compreender o que aconteceu, o que continua verdadeiro e o que mudou em relação ao estado anterior.
Outro aspecto importante é a confiança no sinal. Um acesso identificado por DNS pode indicar utilização de determinado domínio, mas não necessariamente comprova que informações foram compartilhadas. Um evento de DLP pode fornecer evidência mais específica sobre uma operação. Uma integração de inventário pode confirmar permissões, mas não demonstrar que elas foram efetivamente utilizadas.
Essas diferenças precisam ser preservadas na correlação. Mais dados não significam automaticamente mais precisão. A qualidade do modelo depende da capacidade de interpretar corretamente aquilo que cada fonte consegue demonstrar.
Existe um erro de modelagem que precisamos evitar desde o início: considerar o uso de Inteligência Artificial como um comportamento negativo por definição. Uma pessoa que utiliza frequentemente uma ferramenta corporativa aprovada, com controles adequados e informações permitidas, não deveria ser penalizada simplesmente por utilizar IA.
Da mesma maneira, uma pessoa que utiliza pouco essas ferramentas não está necessariamente mais segura. O risco precisa considerar as condições da utilização.
Uma aplicação não autorizada pode representar exposição adicional. Uma tentativa de compartilhar informação sensível pode indicar comportamento que merece atenção. Um agente com permissões excessivas pode aumentar o impacto potencial associado àquela identidade. Uma integração recém-criada pode modificar a superfície de acesso.
Por outro lado, a utilização de ferramentas aprovadas, o respeito às políticas de proteção de dados e a adoção de mecanismos de revisão podem fornecer contexto favorável. Isso não significa que todos esses sinais devam ser convertidos automaticamente em pontos positivos ou negativos.
O modelo precisa preservar a diferença entre comportamento, exposição, contexto e impacto. O uso de IA pode modificar uma ou mais dessas dimensões, dependendo da situação. Essa abordagem também ajuda a manter o Human Risk Score explicável. Se o risco associado a determinada identidade mudou, precisamos conseguir demonstrar quais condições foram alteradas e por que elas são relevantes.
Uma arquitetura de Human Risk Management não precisa executar todas as funções de segurança relacionadas à Inteligência Artificial.
A descoberta e o controle de aplicações continuam pertencendo a ferramentas como CASB, SSE e soluções específicas de governança de IA. A proteção de informações permanece relacionada a DLP, classificação e controles de acesso. IAM e IGA continuam responsáveis por identidades e permissões. EDR, XDR e SIEM permanecem importantes para detecção e investigação.
Da mesma forma, a segurança de agentes exige controles próprios para execução, autorização, isolamento, validação de ações e monitoramento. O papel do HRM é utilizar sinais relevantes dessas camadas para compreender como o risco se relaciona com pessoas e seus contextos.
Isso permite que a gestão de risco humano funcione como uma camada de correlação e priorização, sem tentar substituir ferramentas que já possuem responsabilidades especializadas. A consequência prática é que uma mudança de risco pode gerar tratamentos diferentes.
Se o problema está relacionado ao comportamento de compartilhamento de informações, uma intervenção educacional pode ser apropriada. Se existe uma permissão excessiva, o tratamento pertence ao processo de gestão de acessos. Se uma aplicação não autorizada está sendo utilizada, pode ser necessário aplicar controles de governança. Se um agente possui capacidade excessiva de execução, talvez seja necessário reduzir seu escopo ou introduzir aprovações.
O Human Risk Score pode ajudar a priorizar. A causa precisa determinar a resposta.
A correlação entre identidade, comportamento e uso de IA cria uma responsabilidade importante.
Uma plataforma de HRM não deveria se transformar em um mecanismo de vigilância sobre tudo aquilo que os colaboradores perguntam, escrevem ou produzem utilizando Inteligência Artificial.
Esse tipo de coleta pode gerar riscos de privacidade, problemas de governança e perda de confiança, além de ampliar desnecessariamente a quantidade de informações sensíveis armazenadas. O desenho técnico precisa partir de uma pergunta: qual é o mínimo de informação necessário para compreender determinado risco?
Em muitos casos, metadados, classificações e eventos normalizados são suficientes. Não precisamos armazenar o conteúdo integral de um prompt para saber que determinada política de DLP foi acionada. Não precisamos copiar documentos corporativos para compreender que uma aplicação possui acesso a determinada categoria de informação.
Também precisamos estabelecer controles de acesso, retenção, segregação entre organizações, rastreabilidade e critérios claros para utilização dos sinais.
A explicabilidade é igualmente importante. Uma identidade não deveria receber uma classificação elevada simplesmente porque “o sistema identificou uso de IA”. O modelo precisa demonstrar quais condições foram observadas, qual sua relevância e quais limitações existem na evidência disponível. O objetivo é medir risco, não julgar pessoas.
Um desafio prático é que poucas organizações possuem hoje um inventário completo de todas as aplicações de IA, integrações, agentes e identidades não humanas existentes. Se exigirmos esse nível de maturidade como condição inicial, muitos projetos nunca começarão.
Uma abordagem mais realista é permitir evolução progressiva. A organização pode começar utilizando informações disponíveis em ferramentas de descoberta de aplicações, registros de identidade e controles de proteção de dados. Pode complementar esse contexto com inventários existentes ou cargas estruturadas de informações. Conforme amadurece, pode adicionar integrações específicas para aplicações e agentes.
Também é importante permitir que administradores revisem e complementem as características descobertas automaticamente. Nem toda informação relevante estará disponível em uma API. Responsabilidade organizacional, finalidade de um agente, criticidade de um processo ou classificação de determinados recursos podem depender de informações fornecidas pelas áreas responsáveis.
Esse modelo permite começar com visibilidade parcial, desde que as limitações sejam conhecidas, e melhorar a qualidade da avaliação conforme novas fontes são incorporadas. O mais importante é não confundir ausência de telemetria com ausência de risco.
A evolução da Inteligência Artificial nas empresas está criando uma realidade em que identidades humanas e não humanas passam a trabalhar de forma cada vez mais conectada. Pessoas utilizam aplicações de IA, autorizam integrações, criam agentes, concedem permissões e aprovam ações. Agentes, por sua vez, podem consultar informações, interagir com sistemas e executar tarefas utilizando diferentes mecanismos de identidade e autorização.
Nesse ambiente, analisar apenas o comportamento humano oferece uma visão incompleta. Analisar apenas as permissões e capacidades dos agentes também pode deixar de fora aspectos importantes.
Precisamos compreender as relações.
Human Risk Management pode contribuir para essa evolução ao incorporar o uso de IA como parte do contexto das identidades humanas. Paralelamente, modelos específicos de risco de agentes podem avaliar capacidades, autonomia, permissões, exposição e impacto das identidades não humanas.
Essas duas perspectivas não precisam ser confundidas para funcionar de maneira integrada. A primeira procura compreender o risco associado às pessoas. A segunda procura compreender o risco associado aos agentes. A correlação entre ambas permite identificar situações em que o risco emerge justamente da interação entre elas.
No final, o desafio técnico não é simplesmente descobrir quantas pessoas estão utilizando Inteligência Artificial ou quantos agentes existem na organização.
É conseguir responder a uma pergunta muito mais importante: **quando uma pessoa, uma identidade, uma aplicação de IA e um conjunto de permissões se conectam, qual capacidade de ação está sendo criada e qual risco essa combinação representa para a organização?**
É essa capacidade de correlação que pode transformar a visibilidade sobre IA em gestão efetiva de risco.