Sophos AI Defense: identificar e controlar a utilização de IA

O Sophos AI Defense torna visível a utilização de aplicações de IA e controla quais os serviços permitidos, sujeitos a aviso ou bloqueados. O add-on pago para ambientes Sophos EDR, XDR e MDR elegíveis está disponível de forma geral desde 13 de outubro de 2026. É gerido no Sophos Fusion e utiliza sensores Sophos existentes. No entanto, uma licença, um mosaico visível ou um assistente concluído não comprovam, por si só, uma recolha completa nem uma aplicação eficaz dos controlos.

Para a introdução, recomenda-se esta sequência: esclarecer a licença e o estado do Fusion, identificar as fontes de dados e as políticas existentes, implementar os pré-requisitos dos sensores de forma controlada e só depois testar uma política com âmbito muito limitado. A inspeção do conteúdo de prompts não é uma funcionalidade de proteção atual garantida: a comunicação do fabricante é contraditória neste ponto. O âmbito em que se pode basear um planeamento seguro neste artigo é a visibilidade, as políticas de acesso a aplicações e os relatórios, com verificação em 20 de outubro de 2026.

O que significa Shadow AI e que problema resolve o AI Defense

Shadow AI é a utilização de IA fora dos processos previstos de aprovação e controlo. Por exemplo, uma colaboradora utiliza um chat web adicional, um programador instala um assistente de programação ou uma aplicação existente recebe uma nova funcionalidade de IA. O serviço pode ser útil e, ainda assim, não ter regras esclarecidas para documentos carregados, código-fonte, utilização de dados para treino ou localização dos dados.

O AI Defense reúne três perguntas: que aplicações de IA são utilizadas, que risco lhes é atribuído e que política de acesso deve ser aplicada? A visão geral do produto menciona modelos de linguagem utilizados no browser, como ChatGPT, Claude.ai e Copilot, bem como aplicações mais recentes de programação, desktop e agentes, como Claude Code, Cursor e OpenClaw. Estes exemplos não garantem a deteção e o controlo de todas as variantes, ligações API ou atividades em todos os dispositivos. O sensor concreto e a cobertura efetivamente observada continuam a ser determinantes.

Nas análises, Unsanctioned significa que uma aplicação utilizada não é expressamente permitida por nenhuma política. Trata-se, em primeiro lugar, de um estado de aprovação, não de prova de malware ou de uma fuga de dados. Inversamente, permitir um serviço não torna automaticamente admissível qualquer utilização. Continua a ser necessária uma regra organizacional que defina quais os dados que podem ser enviados para cada serviço.

O AI Defense também não é o Sophos AI Assistant ou o AI Search para investigações XDR. Nesses casos, a IA apoia o trabalho dos analistas. O AI Defense controla a utilização de IA na organização. Nem o nome Fusion nem as funcionalidades Assistant existentes ativam automaticamente o add-on.

Esclarecer previamente a licença, o Fusion e os sensores

Antes da encomenda e antes da configuração, é necessário verificar pré-requisitos distintos:

Elegibilidade para compra: o AI Defense é um add-on pago para clientes Sophos EDR, XDR e MDR elegíveis. A Sophos indica ainda a utilização de Sophos EDR Endpoint Protection como pré-requisito. Por isso, uma licença Sophos Endpoint simples ou uma Sophos Firewall autónoma não bastam para comprovar a elegibilidade. Verifique o âmbito contratual concreto em Ativar e verificar licenças.
Acesso técnico: a configuração documentada exige uma conta Sophos Fusion atualizada para a nova plataforma com Security Operations. A verificação da transição para o Fusion distingue o nome do portal do upgrade efetivo do produto.
Exceção Taegis na compra: os clientes Taegis elegíveis podem comprar o add-on desde a disponibilidade geral, sem esperar pela migração para o Fusion. Não se trata de uma exceção documentada aos pré-requisitos técnicos da configuração. Antes da introdução, esclareça a elegibilidade, a forma de disponibilização e o estado do upgrade com o contacto Sophos responsável.
Sensores adequados: o assistente de configuração oferece atualmente Sophos Endpoint, Sophos Firewall e Sophos Linux Server. A visão geral do produto também menciona DNS Protection, Protected Browser e Sophos Data Lake como fontes de dados. Esta lista de arquitetura mais abrangente não deve ser interpretada como uma lista de seleção idêntica nem como prova de capacidades de aplicação de controlos iguais em todos os componentes.

Antes das alterações, documente os utilizadores, dispositivos e redes afetados, os valores anteriores das políticas, os administradores responsáveis e um procedimento de reversão. Os carregamentos de dados e a desencriptação HTTPS afetam a proteção de dados e as aplicações existentes. A respetiva aprovação deve preceder a ativação, não ficar para a análise posterior. Para o piloto, utilize um utilizador de teste autorizado num dispositivo de teste gerido; as alterações necessárias em políticas partilhadas não devem afetar inadvertidamente toda a organização.

Preparar os sensores e efetuar o onboarding

Abra o Sophos Fusion e depois My Products > AI Defense > Get started. O assistente pergunta pela função administrativa, experiência com ferramentas de IA, número de utilizadores e setor de atividade. Em Choose your sensors, selecione os sensores efetivamente utilizados. Em seguida, confirme os respetivos requisitos. Uma caixa de seleção confirma a sua verificação; não substitui a prova do efeito.

Sophos Endpoint

Para o sensor Endpoint, a Sophos documenta as seguintes definições:

Em Endpoint > Policies > Data Collection and Investigation, ative Upload to the Data Lake na política aplicável e selecione Process Data, HTTP Data, DNS Data e Network Data.
Em Endpoint > Policies > Threat Protection, ative SSL/TLS decryption of HTTPS websites e Block QUIC browser connections. A recolha documentada exige esta configuração; sem a verificar, não se deve pressupor uma visibilidade equivalente. A desencriptação HTTPS e o bloqueio de QUIC podem afetar aplicações. Por isso, teste as alterações num piloto controlado e não remova indiscriminadamente as exceções existentes.
Crie um perfil web em Global Settings > Protection and Remediation > Web Settings > Web Filtering Profiles. Em Endpoint > Policies > Web Control, associe-o às políticas novas ou existentes dos utilizadores e dispositivos previstos. Não é necessário utilizar o mesmo perfil em todo o lado.
Em Endpoint > Policies > Application Control, ative Detect controlled applications when users access them e selecione Block the detected application. Antes da alteração, verifique as associações de aplicações existentes e o respetivo efeito; o artigo Endpoint Application Control explica a configuração existente.

Take me to settings abre a configuração correspondente. Após a implementação, confirme novamente a atribuição efetiva ao dispositivo de teste e só depois confirme os requisitos no assistente.

Sophos Firewall e Linux Server

Para Sophos Firewall, as firewalls previstas têm de estar incluídas na gestão de grupos em Firewall Management > Firewalls. As firewalls fora da gestão de grupos não recebem regras de aplicação do AI Defense. Além disso, é necessário ativar a geração de logs em cada política web relevante: abra a administração web da firewall através do menu de três pontos, selecione a política correspondente em Web e ative os respetivos logs. Sem estes logs, falta a atividade necessária para a deteção. Antes de alterar, verifique a pertença ao grupo e as regras de grupo existentes, para que o onboarding não altere inadvertidamente outras definições da firewall.

Para Sophos Linux Server, a configuração exige Upload to the Data Lake ativado com Network Data, em Server > Policies > Data Collection and Investigation. Isto não significa que o Linux Server aplique os mesmos controlos de acesso a aplicações que o Endpoint ou a Firewall. A pré-visualização da política mostra posteriormente a que produto se aplica a regra concreta.

Se o assistente não conseguir verificar o estado dos sensores, apresenta Refresh. Se a verificação continuar a falhar, permite prosseguir. Isto não é um teste positivo do sensor: a divergência continua por resolver e tem de ser investigada antes da aceitação da proteção.

Não tratar a Base Policy como um rascunho sem efeito

Em Define your base protection, é criada uma Base Policy se ainda não existir. Aplica-se a todas as pessoas da organização. O Generative AI category default define Block, Warn ou Allow para aplicações sem regra própria. As regras específicas de cada aplicação têm prioridade sobre esta predefinição. Para isso, o assistente apresenta aplicações dos últimos 30 dias; não se trata de uma indicação sobre a conservação geral dos dados.

Create base policy and finish cria a Base Policy. Também é possível ignorar este passo. Se já existir uma Base Policy, o onboarding não a altera; Finish and take me to the policy abre o estado existente. Uma política preparada pelo parceiro deve ser verificada primeiro, não substituída preventivamente. Settings > Restart onboarding permite reiniciar o assistente; não é uma reposição nem uma reversão documentada das políticas existentes.

Num ensaio limitado, não crie uma regra de bloqueio para toda a organização com base em suposições. Esclareça primeiro qual a predefinição global aprovada do ponto de vista operacional. Crie depois a política de piloto com um âmbito expressamente limitado.

Criar políticas AI Defense em segurança

Em My Products > AI Defense > Policies > Create policy, atribua à nova política, por exemplo, o nome livremente escolhido IA-Piloto-Servicos-Autorizados. Uma descrição regista a finalidade, a pessoa responsável e a data de revisão prevista. A política é composta por Rules e Scope.

Regras e prioridades

Tanto a lista de políticas como as regras dentro de uma política são avaliadas de cima para baixo: a primeira entrada correspondente decide. Por isso, uma regra correta colocada abaixo de outra regra que já corresponda pode não ter efeito.

Uma nova política adicional contém, por predefinição, uma regra que bloqueia todas as aplicações de IA. A Sophos recomenda mantê-la no fim e colocar permissões específicas acima dela. No piloto, esta regra de bloqueio final só pode afetar o âmbito de teste aprovado. Uma ativação irrefletida para todos os utilizadores também poderia bloquear fluxos de trabalho anteriormente permitidos.

Com Add Rule, selecione a Action e, através de Add Filter, uma Dimension e o respetivo Value. As dimensões suportadas incluem, por exemplo, a aplicação, o nível de risco e as propriedades de conformidade disponibilizadas na interface. Em Application, selecione aplicações concretas da lista. Utilize apenas valores efetivamente disponíveis; uma classificação de risco não substitui a sua própria avaliação do serviço e do contrato subscrito.

Allow: permite a utilização da aplicação correspondente.
Warn: apresenta um aviso aos utilizadores, mas permite-lhes continuar a utilizar o serviço. Não substitui um bloqueio.
Block: destina-se a bloquear a utilização da aplicação correspondente através do produto suportado. O piloto tem de demonstrar se funciona para a via de acesso prevista.

Um exemplo de teste adequado é uma aplicação expressamente permitida acima da regra de bloqueio final e uma segunda aplicação autorizada para o ensaio, mas sem permissão própria na política. Assim, pode verificar a lógica de exceções pretendida sem utilizar conteúdos confidenciais reais. A organização determina os nomes das aplicações e aprova a sua utilização; os exemplos de produtos acima não são recomendações de utilização.

Âmbito e ativação

Em Scope, limite a política aos utilizadores, grupos ou redes previstos, por exemplo, a um grupo de teste existente através de Specific Users and Groups. A página mostra se a política se aplica a Sophos Endpoint ou Sophos Firewall. Em What will happen, as regras, o âmbito e o efeito no produto têm de estar coerentes antes de confirmar I’ve reviewed the rules and scope above.

Save guarda a política adicional sem a ativar. Isto permite verificar primeiro a sua posição na lista. Em contrapartida, Save & Enable ativa-a imediatamente com prioridade máxima. Por isso, para preparar o piloto, recomenda-se começar por Save; antes da ativação posterior, verifique novamente a posição e o âmbito. Esta distinção documentada entre os botões aplica-se a políticas adicionais e não deve ser generalizada à conclusão da Base Policy.

Os modelos em Browse templates > Use e Clone no menu de três pontos podem poupar trabalho. No entanto, já contêm regras predefinidas ou o âmbito copiado. Ambos têm de ser adaptados ao seu ambiente antes de guardar. As políticas existentes podem ser editadas através da respetiva entrada na lista, do ícone Edit de uma regra com Save Rule e de Scope > Edit.

Interpretar corretamente a utilização, os riscos e os relatórios

Em My Products > AI Defense, várias vistas ajudam a responder a perguntas diferentes. Comece sempre por selecionar o período adequado através do ícone de calendário:

Dashboard: mostra a atividade total, as atividades bloqueadas, as aplicações e os utilizadores únicos, bem como a distribuição por Allow, Block e Warn. Inclui também aplicações e utilizadores frequentes, Shadow AI, distribuição de risco, fluxo de utilização e evolução temporal. A pontuação de postura de segurança, até 100, considera a cobertura dos sensores, a maturidade das políticas e o risco de utilização. Um valor elevado não garante proteção completa.
AI Defense Activity: mostra a aplicação, Actor como dispositivo, risco, sensor, hora, ação e política que a desencadeou. Unknown significa que não foi registado um veredicto, não que a atividade tenha sido seguramente permitida. Os níveis de risco vão de Low, Medium e High até Critical. Os widgets permitem, por exemplo, filtrar atividades permitidas; Export fornece CSV.
Inventory > Apps ou Users: ajuda a verificar as aplicações e os utilizadores efetivamente observados. Unsanctioned Use indica a ausência de aprovação expressa; Trains on Data apresenta a informação registada sobre a utilização dos dados pelo fornecedor para treino. A classificação de risco da aplicação considera, entre outros aspetos, provas de conformidade e práticas de treino. Na utilização de aplicações, uma atividade agrupa a utilização de uma aplicação por um dispositivo em janelas de 10 minutos. Por isso, os números de atividade não correspondem ao número de prompts individuais. Ambas as listas de inventário podem ser exportadas como CSV.
Detections: mostra, por exemplo, uma aplicação detetada pela primeira vez, utilização de risco elevado ou utilização de uma aplicação não aprovada. Threat score vai de 0 a 10 e Severity de Info a Critical. Os filtros restringem os resultados por Severity, Threat Score ou título. A vista detalhada oferece uma descrição, o utilizador ou host afetado, a ação recomendada e, em JSON, os dados subjacentes. É possível exportar em CSV formatado, CSV ou JSON.

Os detalhes da aplicação permitem analisar melhor a sua função, o resumo de risco, as regras de treino, a conformidade e a utilização de dados; os detalhes da atividade também indicam Data Residency. Estas informações ajudam a decidir, mas não confirmam que o seu plano, conta ou acordo individual de tratamento de dados tenham condições idênticas.

Após investigar uma Detection, documente no painel de detalhes um estado fundamentado: True positive benign, True positive malicious, False positive ou Not actionable. Uma utilização corretamente detetada pode ser inofensiva; não deve ser classificada como um ataque bem-sucedido apenas por existir uma Detection.

Para criar um relatório, abra AI Defense > Reports > AI Risk Assessment Report > Generate, selecione Report period e, se necessário, Download PDF. O relatório reúne os riscos das aplicações, a exposição a Shadow AI e a comparação da redução de risco entre períodos de relatório. As listas dos cinco principais elementos são recortes, não um inventário completo. Trata-se de um relatório próprio do AI Defense, não de uma garantia de envio automático de relatórios MDR. As exportações podem conter dados de utilizadores e dispositivos e devem ser guardadas num local com acesso restrito e conservação acordada.

Validar um piloto e delimitar erros

A verificação seguinte é uma proposta de processo de aceitação, não um teste de tenant ou laboratório executado pela Avanet. Acorde previamente a janela de teste, o dispositivo, o utilizador, os serviços permitidos e as ações esperadas. Utilize apenas dados de teste sintéticos e aprovados, por exemplo, Apenas um teste funcional sem dados empresariais. Não envie para um serviço de IA dados de clientes, credenciais, documentos internos ou código-fonte real. Um simples teste de acesso não exige a introdução de conteúdos confidenciais.

Comece por uma aplicação expressamente permitida e depois verifique a regra de bloqueio ou aviso prevista para o piloto. Para cada ensaio, anote o serviço, o dispositivo, a hora e o comportamento efetivamente observado pelo utilizador. Com Warn, deve continuar a ser possível prosseguir; com Block, a via de acesso testada não pode ser utilizável.
Em AI Defense Activity, compare a aplicação, Actor, sensor, Action e Policy para o mesmo período. O bloqueio visível e a entrada correspondente têm de coincidir com o ensaio pretendido. Uma página de bloqueio, por si só, também pode ter origem numa regra anterior de Web Control ou Application Control.
Em Inventory, confirme se aparecem a aplicação e o estado de aprovação esperado. Devido ao agrupamento em janelas de 10 minutos, não compare os números de utilização com introduções individuais de dados. Utilize o mesmo período no relatório. Não está documentada uma latência fixa de apresentação; não tente disfarçar entradas em falta repetindo testes indefinidamente.
Faça uma verificação de controlo com um utilizador fora do grupo piloto ou com um dispositivo não envolvido. Os respetivos fluxos de trabalho autorizados devem manter-se inalterados. Alargue o âmbito gradualmente apenas após a aceitação documentada.

A aplicação não fica visível: verifique primeiro o período, a via de acesso efetivamente abrangida e o sensor. Em seguida, confirme os carregamentos de dados e, no Endpoint, as definições documentadas de Threat Protection, Web Control e Application Control. Na recolha pela Firewall, verifique também a geração de logs da política web. Um dashboard vazio não comprova a ausência de utilização de IA.

A aplicação aparece, mas a ação pretendida não é aplicada: compare o estado de ativação, a ordem das políticas, a ordem das regras, o âmbito e o produto apresentado em What will happen. Na aplicação de controlos pela Firewall, verifique também a gestão de grupos. Não tente corrigir o problema com um bloqueio abrangente para toda a organização nem desativando proteções existentes.

Uma aplicação de trabalho deixa de funcionar após uma alteração: compare a última alteração com os valores anteriormente documentados e reverta o piloto. Não crie exceções TLS genéricas nem regras Allow globais para ocultar o erro.

Se uma divergência continuar por esclarecer, reúna eventos sem dados sensíveis, o período com fuso horário, o sensor, o dispositivo, a ação esperada, o comportamento real, a ordem das políticas e o âmbito. Estes dados permitem abrir um pedido de suporte Sophos sem divulgar prompts confidenciais.

Reversão e limites da proteção

Antes do piloto, registe o conjunto de regras anterior, a ordem, o âmbito e as políticas de sensores alteradas. Para reverter, reponha uma regra piloto problemática no seu estado anterior através da edição documentada de políticas ou restitua o âmbito do piloto ao âmbito previamente aprovado. Em seguida, volte a verificar o fluxo de trabalho anteriormente permitido e a apresentação da atividade. Uma Base Policy alterada tem de ser restaurada de forma direcionada com base na predefinição e nas exceções de aplicações anteriormente documentadas. Restart onboarding não a repõe.

As alterações aos sensores só podem ser revertidas para os valores concretos anteriores se tiverem sido efetuadas especificamente para o ensaio e se nenhuma outra tarefa de proteção ou investigação depender delas. Em particular, não desative indiscriminadamente os carregamentos para o Data Lake, a desencriptação TLS ou o Application Control. A reversão das políticas não elimina automaticamente a telemetria já recolhida nem os relatórios exportados. O seu tratamento segue o processo acordado de proteção e conservação de dados.

Três limites continuam a ser importantes para o planeamento:

Visibilidade não é controlo sem lacunas. Uma política central, por si só, não protege um endpoint pessoal não abrangido, outra via de acesso ou a ausência de um pré-requisito do sensor. A deteção de aplicações também não comprova o controlo de todas as ações autónomas de um agente.
O controlo de acesso a aplicações não é uma DLP de prompts garantida. A comunicação de imprensa da disponibilidade geral já descreve a inspeção em tempo real de prompts e carregamentos como uma funcionalidade. A informação posterior para parceiros atribui expressamente a inspeção e a proteção de prompts a versões futuras. Enquanto o âmbito concreto não estiver confirmado de forma fiável, não conte com essa proteção e, em particular, não a teste com dados confidenciais reais.
Um roteiro de desenvolvimento não é um compromisso de aquisição. A distinção entre contas de IA pessoais e empresariais e as funcionalidades adicionais de proteção de agentes também são descritas como parte do roteiro, sem data vinculativa. Quem precisar exatamente destas funcionalidades tem de confirmar a sua disponibilidade para o próprio tenant antes da decisão e validá-las separadamente.

Por isso, o ponto de partida sólido não é «a IA está agora protegida», mas um inventário verificável, serviços expressamente aprovados, políticas limitadas e uma demonstração repetível do seu efeito real.