Inteligência artificial e cibersegurança: menos incerteza, mais direção

Mais capacidade. O mesmo dever de controlo.

Pedir a uma assistente que resuma um incidente não é o mesmo que lhe permitir isolar um servidor. Nos dois casos podemos estar perante inteligência artificial. A diferença decisiva está na autoridade que lhe concedemos, nos dados a que acede e nas consequências de uma resposta errada.

É a partir desta distinção que propomos olhar para a evolução recente da IA na cibersegurança. Não como uma escolha entre entusiasmo e receio, mas como uma questão de engenharia, responsabilidade e gestão do risco: onde acrescenta valor, que exposição introduz e como demonstramos que continua sob controlo?

O guia BP/36 do CCN-CERT, publicado em junho de 2026, é um ponto de partida útil. Liga a aceleração de técnicas ofensivas à necessidade de rever processos, reforçar a arquitetura e governar os agentes defensivos. A sua mensagem não se esgota na aquisição de ferramentas: exige capacidade de prevenir, detetar, responder e recuperar. [1] [1.1]

Uma retrospetiva: do modelo ao ecossistema

Esta preocupação não começou com os assistentes conversacionais. Em 2020, a ENISA já analisava os ativos, o ciclo de vida e as ameaças dos sistemas de IA. Em 2023, organizou as boas práticas em três camadas: fundamentos de cibersegurança, medidas específicas para IA e adaptação ao setor de atividade. A segurança da IA não surge, portanto, desligada da segurança que as organizações já deveriam praticar. [2] [3]

Também em 2023, as orientações lideradas pelo NCSC britânico e pela CISA norte-americana estruturaram a proteção desde a conceção até à operação e manutenção. Em 2024, a ANSSI francesa aprofundou a segurança dos sistemas de IA generativa, enquanto o perfil do NIST para IA generativa complementou a gestão de risco com preocupações próprias destes sistemas. [4] [5] [6]

Em Portugal, o relatório do CNCS sobre riscos e conflitos de 2025, relativo sobretudo a 2024, já assinalava o uso de IA generativa na engenharia social. Trata-se de uma leitura situada no tempo, não de uma medição universal dos ataques com IA. Em 2026, o BP/36 e o plano de ação europeu sobre cibersegurança e IA prolongam esta trajetória de atenção institucional. [7] [1] [8]

A conclusão que retiramos desta evolução é simples: a unidade de proteção já não pode ser apenas o modelo. É necessário considerar a aplicação, os dados, as identidades, as integrações, as pessoas e os processos que lhe dão capacidade para atuar.

Três problemas diferentes, uma responsabilidade comum

Falar genericamente em “riscos da IA” pode esconder problemas muito diferentes. Para decidir onde investir, a Cyberprotech propõe distinguir três frentes complementares. Esta organização é uma síntese editorial, apoiada nas famílias de risco descritas pelo CCN-CERT e nos riscos técnicos identificados pela OWASP. [1] [9]

A IA utilizada por quem ataca

A primeira frente é a utilização de IA para apoiar reconhecimento, produção de mensagens fraudulentas, suplantação e desenvolvimento de código. O BP/36 descreve-a como um multiplicador de capacidades: técnicas conhecidas podem ser preparadas e repetidas com menor esforço. Isso não significa que todos os ataques sejam autónomos, que a intervenção humana desapareça ou que qualquer modelo consiga explorar qualquer sistema. [1]

A recomendação prática é reforçar os pontos de controlo que não dependem de uma mensagem “parecer verdadeira”. Uma alteração de IBAN, um pedido de acesso privilegiado ou uma ordem financeira devem ser confirmados através de procedimentos e canais independentes, usando contactos previamente validados. Uma voz familiar não deve substituir uma autorização verificável. Esta necessidade de verificação fora do canal original é destacada pelo guia. [1]

A IA adotada sem conhecimento da organização

A segunda frente está dentro de portas: ferramentas utilizadas sem inventário, contas pessoais, extensões e conteúdos copiados para serviços externos sem avaliação. O termo shadow AI descreve este uso fora dos mecanismos formais de governação. A exposição não exige um atacante sofisticado: pode começar numa decisão quotidiana sobre onde colocar um contrato, uma conversa de cliente ou um registo técnico. [1]

Propomos que a resposta combine regras claras com alternativas utilizáveis. Uma política que apenas proíbe, sem explicar nem oferecer um caminho aprovado, não constitui por si só um controlo técnico. A organização deve definir os usos autorizados, os dados excluídos e a forma de pedir avaliação de uma nova ferramenta.

Os próprios sistemas de IA como alvo

A terceira frente aparece quando a organização integra modelos com documentos, bases de conhecimento ou ferramentas. A OWASP identifica, entre outros, injeção de instruções, divulgação de informação sensível, problemas na cadeia de fornecimento e autonomia excessiva. Não basta perguntar se o modelo responde bem; é preciso perguntar o que a aplicação lhe permite fazer. [9]

Exemplo ilustrativo

Uma assistente de suporte lê um documento externo que contém instruções maliciosas. Se puder consultar dados internos e enviar mensagens sem restrições, uma interpretação errada pode transformar-se numa fuga de informação. Se os acessos e as operações forem validados fora do modelo, o mesmo erro encontra uma barreira independente.

É esta separação entre conteúdo e autoridade que deve orientar a arquitetura. A OWASP salienta que não existe uma prevenção infalível de prompt injection e que ligar o modelo a fontes documentais através de RAG não elimina, por si só, o problema. A defesa tem de combinar várias camadas. [10]

SOC/CSIRT: começar pela assistência, não pelo controlo autónomo.

Num centro de operações de segurança (SOC) ou numa equipa de resposta a incidentes (CSIRT), o ponto de partida que defendemos é a assistência à decisão. A IA pode ajudar a organizar informação e preparar trabalho; a passagem para ações sobre sistemas reais exige uma avaliação diferente, proporcional ao impacto. O BP/36 recomenda precisamente limitar alcance, permissões e autonomia, mantendo supervisão e capacidade de interrupção. [1]

Como primeiros casos de uso, propomos o resumo de alertas com ligação às evidências, a preparação de cronologias, a comparação de hipóteses e a redação inicial de relatórios. Uma consulta sugerida pode ser revista antes de ser executada. Uma conclusão deve distinguir factos observados, inferências e informação em falta. O analista continua responsável pela validação, não apenas por clicar em “aprovar”.

O perfil de risco muda quando a ferramenta pode bloquear uma conta, alterar uma regra de rede, isolar um equipamento, encerrar um incidente ou enviar uma comunicação externa. Nesses casos, recomendamos que a autorização identifique a operação, o alvo, o âmbito e as condições em que pode ocorrer. A execução não deve resultar apenas de uma frase gerada pelo modelo.

Começar pela assistência não significa rejeitar a automatização. Um procedimento determinístico, testado e previamente autorizado pode conter uma ameaça sem aguardar aprovação manual a cada ocorrência. O que importa é não confundir essa automatização delimitada com a liberdade de um agente escolher novos alvos, privilégios ou ações. O guia também contempla respostas preautorizadas, em articulação com controlo e resiliência. [1]

Modos de utilização e limites de autoridade

Autonomia é uma escolha, não uma obrigação

Maior autonomia não é um objetivo obrigatório. Para alguns serviços, permanecer no modo de assistência será a decisão mais adequada. O critério deve ser o valor demonstrado e o risco aceite, não a pressão para anunciar um “SOC autónomo”.

“A confiança não se mede pela liberdade concedida ao agente, mas pela capacidade de limitar e verificar o que ele faz.”

Os limites têm de existir fora do modelo

As orientações do CCN-CERT sobre agentes e as recomendações de desenvolvimento seguro do NCSC e da ANSSI apontam para controlos ao longo do ciclo de vida. A sua aplicação, na nossa perspetiva, pode começar por seis decisões concretas. [1] [4] [5]

1. Definir a finalidade antes da integração

Cada utilização deve ter um responsável, uma tarefa delimitada e critérios de aceitação. O inventário deve identificar modelo e versões, fornecedor, dados utilizados, fontes de conhecimento, ferramentas disponíveis e dependências. Um assistente de informação pública e um agente com acesso administrativo não devem partilhar automaticamente o mesmo perfil de risco.

2. Dar a cada agente apenas o acesso necessário

Uma identidade própria permite atribuir e revogar permissões sem depender de contas genéricas. Recomendamos separar leitura de escrita, ambientes de teste de produção e informação de diferentes clientes. Credenciais devem ser geridas fora das instruções e do código, com duração e âmbito limitados sempre que a integração o permita. O princípio é o mínimo privilégio, não a conveniência inicial.

3. Validar operações por regras independentes

Os componentes que executam ações devem verificar identidade, autorização, destino e parâmetros. Nas integrações, o controlo de acesso tem de acompanhar o utilizador e o contexto real. Uma resposta que afirma ter autorização não é prova dessa autorização. Também devem existir limites para consumo, duração, número de chamadas e destinos externos permitidos.

4. Governar os dados e o fornecedor

Antes de enviar informação, importa fechar finalidade, condições contratuais, localização e fluxos dos dados, retenção, subcontratantes e eventual utilização para treino. Propomos começar com informação pública ou dados de teste adequados, evitando dados de clientes até à validação dos controlos. Alojamento local ou numa região europeia não dispensa a análise do tratamento e das dependências.

5. Testar falhas, não apenas respostas corretas

O teste deve incluir documentos manipulados, pedidos fora do âmbito, tentativa de acesso indevido, respostas sem suporte e falhas das ferramentas. As alterações de modelo, configuração, dados ou conectores justificam reavaliação. A OWASP e o MITRE ATLAS ajudam a estruturar cenários adversariais; não substituem testes adaptados à aplicação e às consequências do seu uso. [9] [10] [11]

6. Conservar a capacidade de parar e recuperar

Recomendamos testar a revogação de credenciais, a desativação das integrações e o procedimento alternativo sem IA. Um interruptor que apenas fecha a interface não basta se subsistem tarefas em execução ou autorizações válidas. O plano deve considerar efeitos já produzidos e operações em curso, além do restabelecimento do serviço.

Estes controlos complementam, não substituem, o essencial: inventário de ativos, correção de vulnerabilidades, autenticação robusta, segmentação e recuperação. O BP/36 pede priorização pela exposição e exploração efetiva, sem dispensar validações ou medidas compensatórias. Em ambientes industriais, a monitorização passiva e a continuidade do processo exigem cuidados próprios; não se deve acelerar alterações ignorando o risco operacional. [1]

Rastreabilidade: saber o que aconteceu, sem guardar tudo

Quando uma resposta de IA influencia uma decisão, uma pergunta passa a ser central: conseguimos reconstituir o que aconteceu? Não basta guardar o texto final. Interessa conhecer as fontes consultadas, a configuração em vigor, as ferramentas chamadas, a autorização aplicável e os resultados observados. O BP/36 relaciona esta rastreabilidade com a monitorização, a auditoria e a resposta a incidentes. [1]

Para tornar esse princípio operacional, propomos um registo mínimo por interação relevante: identificador, data e hora, identidade do utilizador ou agente, versão da aplicação e do modelo, referência às fontes, operação pedida, validação efetuada e resultado. A granularidade deve aumentar com o impacto, e não com uma intenção indiscriminada de recolher tudo.

Este registo não revela necessariamente o raciocínio interno do modelo nem transforma uma resposta em verdade. Permite antes documentar o percurso observável da aplicação: entradas autorizadas, decisões de controlo, ações e efeitos. Uma cronologia gerada por IA deve continuar ligada às evidências originais, distinguindo observação de interpretação.

Mais registos também podem significar mais exposição

Conversas, documentos e registos técnicos podem conter dados pessoais, informação confidencial ou segredos de acesso. O RGPD exige, entre outros princípios, limitação das finalidades, minimização e limitação da conservação. A segurança e a proteção de dados desde a conceção continuam relevantes quando se acrescenta IA; a avaliação de impacto é exigível quando o tratamento seja suscetível de implicar elevado risco para as pessoas. [14]

Por isso, recomendamos selecionar a evidência necessária, restringir o acesso e definir prazos de conservação por finalidade. Mascarar um segredo é diferente de conservar a sua cópia integral “para auditoria”. Também é importante distinguir registos operacionais correntes de evidência preservada no âmbito de um incidente, sujeita a critérios específicos de integridade, acesso e conservação.

A CNPD divulgou, em abril de 2025, um relatório disponibilizado pelo Comité Europeu para a Proteção de Dados com uma metodologia para gerir riscos de privacidade em sistemas de IA. É um apoio metodológico, não uma certificação. Por sua vez, o Parecer 28/2024 do Comité esclarece que o anonimato de um modelo treinado com dados pessoais exige apreciação caso a caso: não é uma característica que se deva presumir. [12] [13]

A evidência deve sobreviver à dúvida

Na nossa abordagem, preparar a investigação significa definir antecipadamente quem preserva os artefactos, como se protege a sua integridade e quem pode consultá-los. Em caso de incidente, a equipa deve conseguir identificar a versão afetada, interromper acessos, preservar os registos relevantes e avaliar o impacto sem depender exclusivamente da explicação produzida pelo próprio sistema.

“Rastreabilidade útil é conseguir demonstrar o que foi feito, com que dados e sob que autorização — sem criar um arquivo desnecessário de informação sensível.”

Portugal e Europa: escolher o referencial para a pergunta certa

Não existe um único documento que resolva, simultaneamente, governação, segurança técnica, proteção de dados e conformidade. Importa distinguir legislação aplicável, normas de gestão e orientações de boas práticas. Uma lista extensa de referenciais não demonstra, por si só, que os controlos estão implementados.

O ponto de partida português

O Decreto-Lei n.º 125/2025 aprovou o Regime Jurídico da Cibersegurança, transpondo a Diretiva NIS2. O Regulamento n.º 756/2026 aprovou o Quadro Nacional de Referência para a Cibersegurança, a matriz de risco e medidas mínimas, nos termos e âmbitos nele definidos. Para as entidades abrangidas, a adoção de IA deve ser considerada na gestão do risco e nos processos relevantes, em vez de ser tratada como um universo separado. [15] [16]

O BP/36 está ancorado no contexto espanhol e no Esquema Nacional de Seguridad. O seu valor técnico não transforma o ENS no enquadramento português, nem substitui uma análise de aplicabilidade nacional. A transposição útil faz-se dos princípios para controlos e evidências adequados à entidade, não pela importação automática de obrigações. [1] [15] [16]

O que cada família de referenciais acrescenta

Gestão e aplicabilidade

A ISO/IEC 42001 estabelece requisitos para um sistema de gestão de IA. Deve ser entendida nesse âmbito: não constitui uma garantia de invulnerabilidade nem uma aprovação automática de cada aplicação. O NIST AI RMF, de utilização voluntária, complementa a gestão com as funções Govern, Map, Measure e Manage, articuladas com a avaliação do contexto e do risco. [18] [6]

O Regulamento da IA exige igualmente uma análise concreta do papel da organização, da finalidade e da classificação do sistema. Nem toda a IA é de risco elevado e nem todas as obrigações são idênticas. A análise deve considerar a redação e o calendário aplicáveis, incluindo as alterações de 2026, bem como as disposições pertinentes sobre literacia e transparência. Um chatbot informativo não deve ser equiparado automaticamente a um sistema que decide sobre direitos ou acesso a serviços. [17]

Da intenção à prática: um plano inicial de 90 dias

Uma organização não precisa de começar por um programa de grande dimensão. Precisa de conhecer o que utiliza, escolher um caso de uso delimitado e estabelecer condições para decidir. O plano seguinte é uma proposta da Cyberprotech: os períodos são indicativos, não prazos legais nem uma garantia de execução para todas as entidades.

Primeiros 30 dias: conhecer e delimitar

Identificar ferramentas e integrações em uso, atribuir responsáveis e classificar os dados envolvidos. Rever acessos, fornecedores, retenção e condições contratuais. Selecionar um caso de uso de baixo impacto, com utilidade mensurável, e definir quem autoriza a sua evolução. Em paralelo, corrigir exposições evidentes: chaves em locais indevidos, permissões excessivas ou acessos sem responsável.

Dos 31 aos 60 dias: testar em ambiente controlado

Executar o piloto sem poderes de alteração em produção. Comparar o trabalho assistido com o procedimento existente, usando casos equivalentes e critérios comuns. Testar respostas sem suporte, manipulação de conteúdos, acessos indevidos, falhas de integração e limites de consumo. Formar os utilizadores na validação de resultados e ensaiar a desativação do serviço. Documentar os problemas encontrados e as correções efetuadas.

Dos 61 aos 90 dias: decidir com base em evidência

Rever os resultados com os responsáveis de segurança, tecnologia, negócio e proteção de dados, conforme necessário. A decisão pode ser avançar, manter assistência, reduzir o âmbito ou suspender. Qualquer capacidade de ação deve acrescentar autorização delimitada, controlo técnico, monitorização e recuperação. Uma demonstração convincente não substitui critérios de aceitação nem um registo de risco residual.

Medir utilidade, não apenas velocidade

Propomos avaliar o tempo até uma conclusão validada, a frequência de erros materiais, o retrabalho necessário e a percentagem de operações com autorização e evidência verificáveis. Convém ainda acompanhar tentativas de ação fora do âmbito, falhas na proteção de dados, custo por tarefa e capacidade de interrupção e recuperação. As metas devem ser definidas pela organização e pelo caso de uso, não copiadas de uma promessa comercial.

No SOC, reduzir o tempo de produção de um relatório só representa um ganho se a qualidade das conclusões e a preservação da evidência forem mantidas. Uma redução aparente do tempo de resposta pode esconder encerramentos precipitados ou trabalho transferido para uma fase posterior. Por isso, a comparação deve considerar resultados validados e consequências, não apenas o número de tarefas executadas.

A decisão de avançar

Antes de aumentar a autonomia, deve ser possível demonstrar quem é responsável, que dados são necessários, quais as ações permitidas, como se deteta uma falha e como se interrompe a execução. Quando uma destas respostas falta, o passo seguinte deve ser reforçar o controlo, não ampliar os privilégios.

Investigar para adotar com confiança

O BP/36 é útil pela forma como relaciona processos, arquitetura e agentes. Mas uma leitura responsável também exige distinguir orientações de resultados demonstrados. O guia reúne referências de natureza diferente e não deve ser utilizado para extrapolar uma percentagem única de eficácia dos ataques ou para garantir ganhos de automatização numa organização concreta. O seu contributo mais sólido, para esta análise, está nos princípios e no programa de adaptação. [1]

É com esta perspetiva que a Cyberprotech acompanha a evolução da segurança da inteligência artificial e aprofunda trabalho de investigação e desenvolvimento aplicado. O objetivo é transformar conhecimento técnico e referências de governação em critérios que ajudem as organizações a avaliar o uso de IA, limitar a exposição e preservar a capacidade de resposta.

Esta linha de trabalho centra-se na visibilidade sobre ferramentas e integrações, na proteção da informação partilhada, no controlo de identidades e permissões e na rastreabilidade das operações. Interessa-nos compreender não apenas o que um sistema consegue produzir, mas também que acesso necessita, que dependências introduz e que evidência permanece quando algo corre mal.

A investigação aplicada deve permitir comparar abordagens, identificar limitações e testar condições de utilização antes de as transformar em recomendações. Não substitui a validação em contexto nem autoriza promessas de risco zero. Reforça, antes, a preparação técnica necessária para apoiar uma adoção proporcional, informada e verificável.

Mais capacidade, sem abdicar da responsabilidade

A lição que retiramos desta retrospetiva não é que todas as organizações devam construir agentes autónomos. É que a utilização de IA deve ser acompanhada por uma capacidade equivalente de governação, proteção e verificação. A tecnologia pode evoluir depressa; a responsabilidade por aquilo que lhe permitimos fazer continua a exigir decisões claras.

Para a Cyberprotech, o caminho começa por tarefas delimitadas, dados adequados e resultados verificáveis. Prossegue com testes, aprendizagem e revisão do risco. Só depois faz sentido discutir poderes adicionais — e apenas quando o benefício justifica a exposição e os controlos demonstram que conseguem contê-la.

“SOC/CSIRT: começar pela assistência, não pelo controlo autónomo.”

Este princípio não trava a inovação. Dá-lhe uma direção. Porque o indicador de maturidade não é o número de agentes implementados: é a capacidade de demonstrar o que cada um pode fazer, com que dados, sob que autorização e como pode ser interrompido.

Nota de leitura

Este artigo é uma análise original da Cyberprotech, não uma tradução do BP/36. Os exemplos, os modos de utilização e o plano de 90 dias são propostas editoriais. A informação regulamentar deve ser aplicada ao caso concreto. O documento de origem regista consulta das fontes em 15 de setembro de 2026; a edição web foi revista em 6 de outubro de 2026.

A referência a organismos, publicações e normas não implica parceria, certificação ou validação deste artigo por essas entidades. Os quadros e a proposta de implementação são sínteses originais da Cyberprotech.