O alerta sobre IA obscura da Bonfy expõe o próximo problema de governança da segurança

O CEO da Bonfy, Gidi Cohen, identificou uma preocupante lacuna de governança dentro de sistemas empresariais de IA aprovados. Ter acesso legítimo já não garante um resultado apropriado.

Cohen chama o problema de “IA obscura”. O termo descreve uma IA aprovada que usa dados autorizados de maneiras que violam a intenção do negócio, políticas ou as expectativas dos clientes. Ao contrário da IA paralela, o próprio sistema não está oculto das equipes de segurança.

O alerta alcançou um público mais amplo por meio da cobertura de segurança e do Google News. Ainda assim, a história importante não é mais um rótulo chamativo de cibersegurança. Trata-se do colapso de uma premissa conhecida: tecnologia aprovada operando com permissões válidas é tecnologia governada.

Essa premissa funcionava melhor quando os softwares seguiam instruções previsíveis. Um funcionário abria um registro, alterava um campo ou exportava um documento. As equipes de segurança podiam vincular a ação a uma pessoa, permissão, aplicação e registro de data e hora.

A IA muda essa relação. Um sistema pode recuperar milhares de registros autorizados, inferir conexões entre eles e gerar um resultado que ninguém solicitou diretamente. Cada acesso individual pode ser permitido, enquanto o resultado combinado ultrapassa um limite.

Esse conflito coloca as equipes de segurança empresarial entre duas escolhas insatisfatórias. Elas podem desacelerar a adoção de IA com controles rígidos ou permitir uma implementação rápida sem entender todos os usos posteriores dos dados da empresa.

Nenhuma das escolhas resolve o problema central. As organizações precisam de controles que avaliem por que os dados estão sendo usados, e não apenas se uma aplicação consegue acessá-los.

A IA obscura leva o risco para dentro de sistemas aprovados

A IA obscura transforma um fluxo de trabalho aprovado em um problema de governança sem exigir um funcionário mal-intencionado, uma aplicação desconhecida ou uma credencial roubada.

Cohen apresentou o termo ao discutir como a IA distingue relevância de adequação. Seu argumento se concentra em sistemas que operam dentro de plataformas aprovadas e fluxos de trabalho intencionais.

O usuário pode ter a função correta. A aplicação pode ter passado por uma revisão de segurança. Os registros subjacentes podem estar disponíveis por meio de permissões legítimas.

Ainda assim, a ação resultante pode entrar em conflito com a política. Um assistente de IA pode combinar comunicações de clientes, detalhes de contratos e histórico de suporte para produzir um perfil de risco não autorizado. Cada fonte parece relevante, mas seu uso combinado altera a finalidade dos dados.

A distinção de Cohen importa porque os programas de segurança normalmente tratam a aprovação como uma importante fronteira de controle. Depois que um fornecedor, aplicação, integração e identidade passam pela revisão, o monitoramento frequentemente se concentra em acessos não autorizados ou comportamentos suspeitos.

A explicação da Bonfy sobre o conceito afirma que um sistema de IA pode recuperar informações permitidas e ainda assim produzir um resultado que conflita com as expectativas dos clientes. A empresa descreve isso como uma IA aprovada indo além dos limites pretendidos em seu resumo do conceito de IA obscura.

Isso continua sendo um enquadramento apoiado por um fornecedor, e não uma categoria regulatória reconhecida. Nenhum órgão independente estabeleceu “IA obscura” como um termo padrão ou uma classe mensurável de incidentes.

Ainda assim, o comportamento subjacente é suficientemente real para ser examinado. Sistemas generativos podem sintetizar dados entre repositórios, inferir atributos sensíveis e iniciar ações por meio de ferramentas conectadas. Essas capacidades ampliam o significado do acesso autorizado.

Considere um assistente de trabalho conectado a e-mails, documentos, calendários e registros de clientes. Um gerente pede que ele identifique contas com probabilidade de cancelar dentro do trimestre.

O assistente poderia inferir estresse financeiro a partir de disputas de faturamento. Poderia extrair insatisfação de conversas privadas de suporte. Também poderia relacionar essas descobertas a datas de renovação de contratos e comentários de funcionários.

Todas as fontes poderiam estar dentro das permissões técnicas do gerente. No entanto, a organização talvez nunca tenha aprovado essa finalidade combinada de criação de perfis. Ela também pode não ter um registro dos fatores que moldaram a recomendação.

Isso é diferente da IA paralela comum. IA paralela geralmente se refere a funcionários que usam modelos não aprovados, contas pessoais de chatbot, extensões de navegador ou agentes não autorizados.

Nesses casos, o problema de segurança começa com a visibilidade. As equipes precisam descobrir quais ferramentas estão ativas, determinar que dados foram inseridos nelas e decidir se devem bloquear ou governar seu uso.

The Hacker News descreveu outra versão desse risco dentro de softwares aprovados. Recursos de IA podem aparecer em help desks existentes, sistemas de documentos e plataformas de clientes após a revisão original do fornecedor.

Sua visão geral dos riscos da IA paralela argumenta que avaliar previamente um software não governa todos os recursos de IA ativados posteriormente. Essa observação reduz a distância entre a IA paralela e o enquadramento mais recente de Cohen.

Os dois conceitos ainda descrevem falhas de controle diferentes.

A IA paralela pergunta se a organização sabe que uma ferramenta ou recurso existe. A IA obscura pergunta se o comportamento de um sistema aprovado permanece apropriado para um usuário, finalidade e relacionamento específicos.

O Google News pode colocar ambas as histórias sob o mesmo tema amplo de segurança em IA. Os defensores empresariais não podem se dar ao luxo de tratá-las como o mesmo problema operacional.

Ferramentas de descoberta podem revelar um chatbot desconhecido. Elas não conseguem decidir automaticamente se um assistente aprovado deve usar uma conversa sensível de cliente para influenciar uma decisão de vendas.

Essa decisão exige contexto. Também exige políticas que o software possa avaliar antes da recuperação, geração ou ação.

Por que controles de identidade e acesso já não bastam

Os controles de identidade respondem quem pode acessar dados, mas a IA obscura força as organizações a decidir quais relacionamentos e finalidades tornam esse acesso apropriado.

O controle de acesso tradicional concede permissões por meio de funções, grupos, propriedade de recursos e regras de política. Um gerente de suporte ao cliente pode ler todos os casos atribuídos a uma região. Um analista financeiro pode revisar todas as faturas de uma unidade de negócios.

Esses controles continuam essenciais. Eles impedem que muitos usuários e aplicações não autorizados acessem sistemas sensíveis. Também criam registros que os investigadores podem examinar após um incidente.

No entanto, permissões amplas frequentemente existem porque as pessoas precisam de flexibilidade. Um funcionário sênior pode acessar milhares de documentos enquanto usa apenas um pequeno subconjunto em cada tarefa.

O julgamento humano fornece uma segunda camada informal. Os funcionários normalmente entendem que ter acesso a um registro de cliente não autoriza todos os usos possíveis de seu conteúdo.

Não se pode presumir que a IA compartilhe esse entendimento. Um modelo otimiza sua resposta usando o contexto disponível, instruções e padrões aprendidos. Ele não conhece inerentemente os limites não escritos de uma organização.

Isso cria um problema de finalidade. Dados coletados para suporte ao cliente podem estar tecnicamente disponíveis para um assistente de vendas. Essa disponibilidade não autoriza necessariamente o uso de linguagem emocional de chamadas de suporte para ajustar o tratamento comercial.

Também cria um problema de relacionamento. Um médico, advogado, gestor de recursos humanos e administrador de sistemas podem acessar o mesmo registro sob diferentes deveres profissionais.

Uma permissão convencional pode representar o recurso e o usuário. Raramente ela captura a relação completa que envolve cada inferência que uma IA pode fazer.

Os agentes elevam ainda mais os riscos. Um agente de IA é um software que seleciona e executa ações por meio de ferramentas conectadas, em vez de apenas produzir texto.

Um agente aprovado pode ler e-mails, consultar um banco de dados, atualizar um registro de cliente e enviar uma mensagem. Suas permissões podem ser válidas em cada etapa.

A sequência combinada ainda pode ser insegura. Uma instrução não confiável escondida em um e-mail poderia redirecionar o comportamento do agente. Um objetivo amplo também poderia incentivar recuperação excessiva ou ação desnecessária.

A OWASP descreve a injeção de prompt como instruções que manipulam um modelo por meio de entrada direta ou conteúdo que o modelo processa posteriormente. O impacto depende fortemente das ferramentas e da autoridade disponíveis ao sistema, segundo sua orientação sobre injeção de prompt.

Essa ameaça conecta explorações de segurança a falhas de governança. Uma instrução maliciosa pode causar uma ação inadequada, mas uma política pouco clara pode produzir resultado semelhante sem a presença de um atacante.

A OWASP também alerta separadamente para a agência excessiva, quando um sistema de IA tem mais funcionalidades, permissões ou autonomia do que precisa. Seu exemplo inclui um e-mail malicioso instruindo um agente a pesquisar uma caixa de entrada e encaminhar informações sensíveis.

O princípio do menor privilégio continua sendo parte da resposta. Um assistente não pode usar indevidamente dados ou funções aos quais não tem acesso.

No entanto, reduzir permissões por si só tem limites. As organizações frequentemente implementam IA justamente porque ela pode conectar informações entre sistemas. Remover toda capacidade entre sistemas pode eliminar o valor de negócio que justificou a implementação.

A tarefa mais difícil é tornar a autorização mais específica. Uma decisão deve considerar a identidade solicitante, a finalidade de negócio, o relacionamento com os dados, a ação, o destino e o contexto atual.

Por exemplo, um assistente de atendimento ao cliente pode resumir uma reclamação para o caso atribuído. O mesmo assistente não deveria adicionar informações de saúde dessa reclamação a um perfil de marketing.

Ambas as ações envolvem a mesma identidade e os dados subjacentes. A diferença está na finalidade, no público e no uso esperado.

É por isso que a IA obscura é, fundamentalmente, um desafio de governança. As equipes de segurança podem definir limites técnicos, mas os responsáveis por jurídico, privacidade, conformidade, produto e negócios devem definir o comportamento apropriado.

Essa responsabilidade compartilhada é desconfortável. As organizações de segurança preferem regras aplicáveis, enquanto as equipes de políticas frequentemente escrevem princípios que dependem de interpretação humana.

Os sistemas de IA expõem a lacuna entre essas abordagens. Uma política que afirma que os dados de clientes devem ser usados “apropriadamente” oferece pouca proteção, a menos que a organização transforme essa palavra em controles testáveis.

O Google News está destacando uma mudança do acesso para a intenção

A discussão mais ampla sobre segurança está mudando da descoberta de ferramentas de IA para a governança do que modelos e agentes aprovados fazem com acessos legítimos.

O aparecimento da IA obscura no Google News reflete uma mudança maior na cobertura de segurança empresarial. A primeira onda de preocupação concentrou-se em funcionários colando dados sensíveis em chatbots públicos.

Esse risco não desapareceu. Contas pessoais, aplicações não aprovadas e recursos de IA incorporados ainda criam problemas de visibilidade e perda de dados.

No entanto, implementações empresariais aprovadas agora apresentam uma questão mais complexa. As organizações estão conectando assistentes e agentes a sistemas valiosos porque interfaces de chat isoladas oferecem valor operacional limitado.

As conexões criam contexto. Também criam autoridade.

Um modelo conectado a uma base de conhecimento da empresa pode localizar informações internas. Um agente conectado a software operacional pode agir com base nessas informações. Portanto, a governança deve abranger tanto a interpretação quanto a execução.

A pesquisa da IBM sobre violações de 2025 encontrou uma lacuna substancial de supervisão em torno da IA empresarial. Seu comunicado oficial afirmou que 13 por cento das organizações estudadas relataram violações envolvendo modelos ou aplicações de IA.

Entre essas organizações, 97% não tinham controles adequados de acesso à IA. A IBM também afirmou que 63% das organizações pesquisadas não possuíam políticas de governança de IA ou ainda estavam desenvolvendo-as.

Esses números vêm de uma pesquisa patrocinada por fornecedor e não devem definir o risco de todas as organizações. Ainda assim, mostram por que a segurança de IA foi além de ataques hipotéticos a modelos.

As constatações da IBM sobre violações descrevem uma adoção que avança mais rápido que a governança. A Shady AI identifica um possível resultado desse desequilíbrio dentro de sistemas autorizados.

Os frameworks existentes fornecem bases úteis. O framework de IA do NIST organiza a gestão de riscos de IA em torno de governar, mapear, medir e gerenciar riscos.

O NIST também lançou um perfil de IA generativa que adapta o framework a riscos específicos de modelos. Ele enfatiza responsabilidades documentadas, testes, processos de incidentes e medição contínua.

Essas práticas ajudam as organizações a ir além da aprovação única. Elas incentivam as equipes a tratar a IA implantada como um sistema em mudança que exige supervisão contínua.

Ainda assim, um framework não pode fornecer as regras de negócio de cada empresa. Um banco, hospital, fornecedor de software e universidade definirão de maneira diferente o uso apropriado de dados.

A regulamentação acrescenta outra camada. As regras da União Europeia impõem obrigações a fornecedores e implantadores com base na função e na classificação de risco de um sistema de IA.

A Comissão Europeia afirma que as obrigações para modelos de uso geral começaram a valer em 2 de agosto de 2025. Elas incluem requisitos de documentação e transparência, com deveres adicionais para modelos classificados como de risco sistêmico.

Essas regras se concentram fortemente em fornecedores e casos de uso designados. Elas não resolvem automaticamente todas as decisões contextuais tomadas por um assistente corporativo que usa dados internos autorizados.

Uma organização pode atender aos requisitos de documentação do fornecedor e ainda implantar um assistente com finalidades internas mal definidas. Conformidade legal e adequação operacional se sobrepõem, mas não são idênticas.

A mesma distinção aparece na legislação de privacidade. O consentimento ou outra base legal pode autorizar o processamento de dados em alto nível. Uma nova inferência ou um conjunto de dados combinado ainda pode criar consequências inesperadas.

É aqui que a expressão “relevância não é permissão” se torna útil. Uma informação pode melhorar a resposta de um modelo sem ser apropriada para aquela decisão.

Mecanismos de busca e o Google News tendem a favorecer categorias simples, como shadow AI, agentes de IA e vazamento de dados. A Shady AI não se encaixa perfeitamente em nenhuma delas.

Ela abrange gestão de acesso, privacidade, comportamento de modelos, governança de dados e desenho de processos de negócio. Essa sobreposição torna mais difícil atribuir responsabilidade e mais fácil ignorar o problema.

Portanto, a organização sob pressão não é apenas o centro de operações de segurança. Chief information security officers, líderes de privacidade, equipes jurídicas, proprietários de dados e gestores de aplicações herdam todos uma parte do problema.

Eles precisam de uma visão única e aplicável do comportamento permitido. Sem isso, cada equipe pode acreditar que outro grupo é responsável pelo risco.

A Parte Difícil É Transformar Políticas em Decisões de Tempo de Execução

Uma resposta crível precisa aplicar o contexto durante a recuperação de dados e a execução de ações, e não apenas publicar outra política de uso aceitável.

Muitas organizações começaram a governança de IA com listas. Uma lista nomeia as ferramentas aprovadas. Outra identifica dados proibidos. Uma terceira atribui proprietários de aplicações e datas de revisão.

Esses inventários são necessários, especialmente para descobrir shadow AI. Eles não tratam integralmente de um sistema aprovado que produz um resultado inadequado a partir de recursos permitidos.

A Shady AI exige controles mais próximos do tempo de execução. Tempo de execução é o momento em que uma IA recebe uma solicitação, recupera informações, gera uma saída ou chama uma ferramenta conectada.

Nesse momento, o sistema possui mais contexto do que um processo estático de aprovação. Ele conhece o usuário, a solicitação, os dados selecionados, o destino pretendido e a ação proposta.

Uma camada de governança pode avaliar esses fatores antes de permitir que o fluxo de trabalho continue. Ela pode negar acesso, remover contexto sensível, exigir aprovação ou limitar a ação disponível.

A política deve ser específica o suficiente para ser aplicada. “Proteger a confiança dos clientes” é um princípio importante, mas o software precisa de uma regra mais precisa.

Uma regra pode proibir um assistente de usar conversas de suporte para determinar descontos. Outra pode restringir a sumarização de informações médicas de funcionários fora de um fluxo de benefícios autorizado.

As organizações também precisam de proveniência, que registra de onde uma resposta de IA obteve suas informações. A proveniência ajuda revisores a entender quais fontes influenciaram uma resposta ou ação.

Registrar apenas o prompt e a resposta finais é insuficiente para muitos fluxos de trabalho agênticos. Investigadores podem precisar dos documentos recuperados, chamadas de ferramentas, avaliações de políticas, versão do modelo e histórico de aprovações.

Esse registro apoia auditorias e resposta a incidentes. Ele também pode revelar regras de política que bloqueiam trabalho inofensivo ou permitem combinações arriscadas.

Os testes devem refletir relações reais de negócio. Benchmarks genéricos de modelos não podem determinar se uma mensagem específica de cliente deve fazer parte de uma recomendação de renovação.

As equipes devem criar cenários em torno de seus próprios dados, funções, fluxos de trabalho e resultados proibidos. Os testes devem incluir tanto prompts maliciosos quanto solicitações comuns com finalidades ambíguas.

A aprovação humana pode reduzir o risco de ações de alto impacto. Ela é mais útil quando o revisor recebe o contexto relevante e uma razão compreensível para o alerta.

Um botão com o rótulo “aprovar” pouco faz se o revisor não consegue ver quais fontes sensíveis moldaram a ação. A fadiga de aprovação também pode transformar um controle formal em um clique automático.

Por isso, as organizações devem reservar a revisão humana para limites significativos. Fluxos de trabalho de menor risco podem usar restrições automatizadas, amostragem e monitoramento retrospectivo.

A minimização de dados é outro controle prático. Um assistente deve receber apenas as informações necessárias para sua tarefa atual, mesmo quando sua conta de serviço pode acessar mais.

Sistemas de recuperação podem aplicar essa restrição antes que o conteúdo entre no contexto do modelo. Gateways de ferramentas podem, de forma semelhante, limitar quais operações um agente pode executar.

Para trabalhadores do conhecimento, o contexto local pode reduzir transferências desnecessárias para serviços externos amplos. Uma base de conhecimento pessoal bem projetada pode preservar limites mais claros entre informações pessoais e organizacionais compartilhadas.

No entanto, a arquitetura por si só não garante o uso apropriado. O processamento local pode reduzir a exposição e ainda produzir uma inferência injusta, intrusiva ou não autorizada.

Este é um ponto cético importante. Fornecedores de segurança podem descrever a aplicação contextual como uma resposta completa, mas a interpretação de políticas continua difícil.

A linguagem natural é ambígua. As relações de negócio mudam. Uma regra que funciona para um departamento pode obstruir outra equipe ou não detectar um uso indevido sutil.

Falsos positivos podem levar funcionários a buscar contornos. Falsos negativos podem criar uma confiança injustificada em uma camada automatizada de governança.

O comportamento do modelo também muda após atualizações. Um prompt, estratégia de recuperação ou teste de política que funcionou com uma versão pode se comportar de maneira diferente com outra.

As organizações devem tratar os controles contextuais como parte de um programa em camadas. Identidade, privilégio mínimo, classificação de dados, filtragem de recuperação, restrições de ferramentas, avaliação e supervisão humana continuam necessários.

Nenhum controle isolado estabelece que todos os resultados são apropriados. O objetivo é tornar violações de política visíveis, testáveis e mais difíceis de executar na velocidade das máquinas.

Três Sinais Mostrarão se a Shady AI se Tornará uma Categoria Real de Segurança

A Shady AI só terá importância se as organizações puderem medi-la, aplicar controles significativos e conectar falhas a responsáveis identificáveis.

O primeiro sinal é se os principais frameworks de segurança distinguem o uso autorizado inadequado da IA não autorizada convencional. O NIST, o OWASP e grupos do setor já tratam de elementos relacionados.

A injeção de prompts abrange comportamento de modelo manipulado. A agência excessiva abrange autonomia perigosa. A shadow AI abrange sistemas desconhecidos ou não autorizados.

Nenhum desses rótulos descreve perfeitamente um sistema aprovado que toma uma decisão contextualmente inaceitável sem a ação de um atacante. Uma taxonomia mais clara ajudaria as equipes a reportar incidentes de maneira consistente.

Observe novas orientações de frameworks que tratem de finalidade, relacionamento e inferência. Essas orientações reforçariam o argumento de Cohen de que os controles convencionais de acesso deixam uma lacuna relevante.

Esse julgamento se enfraqueceria se as categorias existentes já capturassem esses incidentes sem confusão operacional. Uma nova terminologia tem pouco valor quando apenas renomeia falhas estabelecidas.

O segundo sinal é a chegada de controles mensuráveis em tempo de execução. Fornecedores prometerão governança contextual, mas compradores devem buscar evidências além de painéis de políticas.

Evidências úteis incluem restrições de finalidade aplicáveis, logs de decisão, controles no nível de recuperação, aprovações de chamadas de ferramentas e testes reproduzíveis. Os produtos também devem explicar por que uma política permitiu ou negou uma ação.

Avaliações independentes seriam especialmente valiosas. Um fornecedor não deveria ser a única parte a definir o risco, medir seu produto e declarar o controle bem-sucedido.

Compradores devem testar cenários realistas antes de uma implantação ampla. Devem perguntar se o sistema interrompe combinações inadequadas de dados, e não apenas prompts maliciosos conhecidos.

Eles também devem examinar os modos de falha. Um controle que bloqueia fluxos de trabalho legítimos com demasiada frequência perderá apoio, mesmo que sua lógica de segurança pareça sólida.

O terceiro sinal é a responsabilização organizacional. A Shady AI atravessa responsabilidades de segurança, privacidade, jurídico, dados e produto.

Um comitê de governança pode coordenar essas equipes, mas comitês frequentemente produzem orientações sem responsabilidade operacional. Todo sistema implantado ainda precisa de um tomador de decisão responsável.

Esse responsável deve aprovar finalidades pretendidas, relações aceitáveis entre dados, resultados proibidos e regras de escalonamento. As equipes de segurança podem então traduzir essas decisões em controles técnicos e testes.

O reporte de incidentes revelará se esse modelo funciona. As organizações devem ser capazes de distinguir uma ferramenta desconhecida, um agente comprometido, uma falha de permissão e uma ação autorizada inadequada.

Essas categorias levam a soluções diferentes. Bloquear um domínio pode resolver um chatbot não autorizado, mas não pode governar um modelo aprovado já incorporado a uma aplicação de negócio.

A exposição no Google News atrairá mais atenção para a shady AI, mas a atenção por si só não estabelecerá o termo. Evidências de sistemas implantados devem mostrar uma falha recorrente que os controles existentes deixam de detectar de forma consistente.

Líderes de segurança devem começar com um inventário restrito de fluxos de trabalho de IA aprovados que envolvam dados sensíveis ou decisões consequentes. Para cada fluxo de trabalho, devem fazer quatro perguntas.

Que informações o sistema pode recuperar? Quais finalidades justificam essa recuperação? Que ações ele pode tomar? Quem pode explicar e interromper um resultado inadequado?

Se essas perguntas produzirem respostas vagas, a lacuna de governança já existe. As equipes não precisam esperar uma violação, regulamentação ou nova categoria de produto para examiná-la.

O próximo passo prático é selecionar um fluxo de trabalho de alto impacto e rastreá-lo da solicitação ao resultado. Registre identidades, dados recuperados, políticas, decisões do modelo, chamadas de ferramentas e aprovações humanas.

Em seguida, teste solicitações tecnicamente permitidas, mas contextualmente erradas. Esse exercício mostrará se “aprovado” realmente significa governado ou apenas conectado e confiável.