O ataque em si parece quase comum. Algo analisou ficheiros genéricos em busca de pontos fracos, encontrou uma forma de entrar e iniciou sessão com sucesso. Depois, continuou: procurou mais vulnerabilidades na aplicação, explorou-as, alterou dados pessoais e emitiu faturas. O que distinguiu esta notificação foi quem, ou o que, realizou a pesquisa. De acordo com a organização afetada, tratou-se de um agente de IA que utilizou um modelo de linguagem bem conhecido.

A AEPD apressou-se a acrescentar algumas ressalvas quando publicou o caso. A informação provém da própria notificação da organização e ainda tem de ser analisada. A utilização de um modelo específico não significa que o modelo, ou a infraestrutura do seu fornecedor, tenha sido comprometida. E uma única notificação não constitui uma tendência estatística. Trata-se, na opinião da Agência, de um sinal de que os ataques assistidos por IA estão a começar a surgir em incidentes que envolvem dados pessoais reais.

O que tornou este ataque diferente

A IA já faz parte dos ciberataques há algum tempo: em e-mails de phishing, em mensagens fraudulentas traduzidas, na análise de código. Um agente acrescenta algo mais. É capaz de definir um objetivo, dividi-lo em etapas, utilizar ferramentas, analisar os resultados e ajustar o que faz a seguir, com pouca ou nenhuma intervenção humana entre essas etapas.

Neste caso, isso significou que um único sistema encadeou toda a sequência, desde a deteção de uma vulnerabilidade até à alteração de dados pessoais. A AEPD aponta para um risco específico por trás disso: um agente que se aproprie de uma conta, de uma chave API ou de um token com permissões mais amplas do que as necessárias pode mover-se entre serviços antes que alguém repare em atividade invulgar. O pormenor notável no caso espanhol é o quão banal foi a entrada: o agente iniciou sessão.

Isso desvia a atenção da defesa do perímetro para uma questão menos glamorosa: que contas, chaves e tokens existem na sua organização, a que é que cada um deles tem acesso e com que rapidez pode revogar um?

O prazo do RGPD não muda. O que muda é o tempo que temos para compreender.

O RGPD é tecnologicamente neutro e o caso da AEPD não altera nenhuma obrigação. O artigo 32.º continua a exigir medidas de segurança adequadas ao risco. O artigo 33.º continua a exigir que os responsáveis pelo tratamento notifiquem a autoridade de controlo sem demora injustificada e, sempre que possível, no prazo de 72 horas após terem tomado conhecimento de uma violação de dados pessoais, a menos que seja improvável que tal resulte num risco para as pessoas.

A diferença reside na lacuna entre tomar conhecimento e compreender. Uma equipa pode saber que um atacante acedeu a uma aplicação, mas ainda estar a determinar quais os registos que foram afetados, se os dados foram copiados e, como neste caso, se foram alterados. Os dados alterados transformam uma questão de confidencialidade também numa questão de integridade, o que torna a investigação mais difícil. Se o agente tiver utilizado credenciais válidas, também pode ser difícil separar as suas ações da atividade legítima.

Daí decorrem duas consequências para quem lida com incidentes. A avaliação jurídica tem de começar enquanto a investigação técnica ainda está em curso, e não depois de o relatório forense chegar. E o RGPD já antecipa isso: quando nem toda a informação estiver disponível de imediato, o artigo 33.º permite que seja fornecida por fases, sem atrasos indevidos. Um plano que trate a notificação como um documento único e definitivo terá dificuldades a lidar com um ataque que se desenvolve à velocidade de uma máquina.

Dependendo da organização, o mesmo incidente pode também dar origem à obrigação de notificação ao abrigo da NIS2, do DORA ou da Lei da Resiliência Cibernética, cada uma com os seus próprios limiares, prazos e autoridades competentes. É na primeira hora que essas decisões são tomadas.

O que o Regulamento da IA tem a ver com isto

É tentador interpretar este caso como uma história relacionada com o Regulamento da IA. Para a organização que foi atacada, não é bem assim. O Regulamento da IA da UE regula a forma como os sistemas de IA são criados, colocados no mercado e utilizados. Não se aplica ao atacante, e nada no processo da AEPD sugere que a vítima estivesse a utilizar a IA em questão.

O regulamento da IA pode tornar-se relevante do outro lado: quando a sua organização implementa os seus próprios agentes de IA. Agentes que consultam registos de clientes, atualizam um CRM, enviam e-mails ou acionam pagamentos possuem exatamente o tipo de acesso sobre o qual a AEPD alerta. Se um deles, ou as suas credenciais, fossem comprometidos, a mesma cadeia de eventos poderia ocorrer nos seus sistemas, tendo início a partir do interior.

É aí que a privacidade e a governação da IA se cruzam:

• Nos termos do RGPD, o que os seus próprios agentes fazem com os dados pessoais requer uma base jurídica, muitas vezes uma avaliação de impacto em matéria de proteção de dados, e salvaguardas nos casos em que as decisões são automatizadas.

• Ao abrigo do Regulamento da IA, os sistemas de IA de alto risco devem atingir níveis adequados de precisão, robustez e cibersegurança, nos termos do Artigo 15.º. De acordo com o Pacote Digital sobre IA, estas obrigações aplicam-se a partir de 2 de dezembro de 2027 para sistemas autónomos e a partir de 2 de agosto de 2028 para a IA incorporada em produtos regulamentados. Os fornecedores dos modelos de IA de uso geral mais avançados já têm, atualmente, obrigações em matéria de cibersegurança e de incidentes graves.

• Em ambos os casos, as questões práticas são as mesmas: que agentes executa, quem é o proprietário de cada um, a que dados e sistemas tem acesso e quem aprovou esse acesso?

A nossa opinião: as organizações que tratam o RGPD e o Regulamento da IA como projetos separados irão responder a essas perguntas duas vezes, em locais diferentes e, provavelmente, de forma diferente. Trata-se de um único conjunto de perguntas.

Como é que o Formalize contribui para isso

Uma plataforma de GRC não deteta nem bloqueia um agente de IA. Essa é a função das ferramentas de segurança, desde a gestão de identidades até à monitorização. O que uma plataforma de GRC faz é garantir que a parte organizacional se mantém sólida quando ocorre um incidente e que é possível demonstrar que assim foi.

Na Formalize, isso significa:

• Avaliações de risco com os proprietários, atualizadas à medida que ameaças como os ataques assistidos por IA alteram o panorama.

• Controlos como tarefas recorrentes e comprovadas, tais como revisões de acesso a contas de serviço e chaves API, em vez de boas intenções num documento de política.

• Fluxos de trabalho de incidentes que registam quem avaliou o quê, quando e porquê, desde o primeiro alerta até à decisão de notificação.

• O RGPD e o Regulamento da IA funcionam no mesmo sistema, com modelos para ambos, para que os seus registos de tratamento e os seus sistemas de IA sejam regulados em paralelo.

Quando, mais tarde, uma entidade reguladora perguntar o que sabia, quando tomou conhecimento disso e o que fez, a resposta já deverá estar preparada. Veja como a Formalize aborda a conformidade com o RGPD e com o Regulamento da IA.