Resumo

  • O Cyber Security and Resilience Bill já propõe uma notificação inicial em 24 horas e um relatório mais completo em 72 horas para determinados incidentes de entidades reguladas. Duas emendas separadas dos Lords acrescentariam um dever condicional para desenvolvedores de modelos de fronteira e uma via voluntária para que operadores comuniquem ameaças e quase incidentes.
  • Nenhuma das emendas é lei. A utilidade das duas dependerá de conectar as informações do desenvolvedor e do operador afetado às autoridades capazes de conter o incidente e apoiar os serviços atingidos.

Análise

O prazo é fácil de entender. A passagem de informação entre organizações, não. Um aviso enviado em até 24 horas ainda pode chegar tarde demais para que o operador isole um agente, ou cedo demais para que a autoridade saiba se o evento atingiu o limiar jurídico. O debate britânico começa a tratar desse intervalo.

Em 12 de outubro, o governo anunciou que estudaria como identificar e comunicar incidentes graves ligados à IA e quase incidentes sob o Cyber Security and Resilience Bill. Também informou que o Department for Science, Innovation and Technology, o NCSC e o AI Security Institute estão preparando formas de responder a incidentes envolvendo agentes de IA, sobretudo para contê-los e apoiar os afetados. É uma frente exploratória: os detalhes serão discutidos com parlamentares, especialistas técnicos e operadores.

A lista de emendas dos Lords, publicada em 12 de outubro, já apontava duas possíveis vias de comunicação. Elas mostram escolhas concretas de desenho, mas continuam sendo propostas. Na data de corte desta análise, 14 de outubro, a fase de relatório do Bill na House of Lords estava prevista para 26 de outubro; as emendas ainda não tinham sido consideradas nessa etapa.

O Bill tem um relógio; as emendas acrescentam outro responsável

O desenho ordinário do Bill se dirige a organizações reguladas. A ficha do governo descreve um aviso inicial ao regulador, com o NCSC informado ao mesmo tempo, até 24 horas depois de a organização tomar conhecimento do incidente. Um relatório mais detalhado viria em 72 horas. A proposta busca trazer certos ataques prejudiciais ao radar antes que interrompam o serviço. Alguns limiares e detalhes de implementação ainda seriam definidos em legislação secundária e consulta.

A nova cláusula proposta por Baroness Harding para incidentes com modelos de fronteira começa pelo desenvolvedor. Ela se aplicaria se um modelo obtivesse, ou fosse usado para obter, acesso não autorizado a uma rede ou sistema de informação relevante, ou interferisse nele; o desenvolvedor teria de saber ou ser razoavelmente esperado que soubesse do acesso ou da interferência. O sistema também teria de ser usado por uma entidade regulada, ainda que o desenvolvedor desconhecesse essa relação.

O gatilho é mais estreito do que “qualquer comportamento inesperado da IA”. O texto liga acesso ou interferência não autorizados, um sistema usado por entidade regulada e o conhecimento real ou esperado do desenvolvedor. Uma saída estranha do modelo, por si só, não bastaria. Tampouco todo incidente cibernético com algum uso de IA se tornaria automaticamente um evento de relato obrigatório do desenvolvedor.

Se o gatilho fosse atendido, o desenvolvedor notificaria tanto a entidade afetada como a autoridade competente. O aviso inicial identificaria o desenvolvedor e o modelo e traria detalhes breves. A notificação completa acrescentaria horário, duração, se o incidente continua, qual sistema foi afetado, se o modelo agiu de forma autônoma ou foi usado por outra pessoa e qual foi a natureza e o impacto. O relatório final cobriria gravidade, provável ameaça ou causa raiz e as medidas de mitigação adotadas ou em andamento.

Os prazos propostos começariam quando o desenvolvedor soubesse ou devesse razoavelmente saber do acesso ou interferência: 24 horas para o aviso inicial, 72 para a notificação completa e 14 dias para o relatório final. Uma cópia iria ao CSIRT e ao AI Security Institute ao mesmo tempo que à autoridade. A emenda também prevê penalidades caso o desenvolvedor deixe de relatar. Essas obrigações só existiriam se o Parlamento adotasse a cláusula e ela entrasse em vigor.

A via de quase incidentes é voluntária de propósito

A segunda cláusula proposta trata de outro incentivo. Ela permitiria que uma entidade regulada notificasse o CSIRT ou a autoridade competente sobre incidente, ameaça cibernética ou quase incidente que afetasse seus sistemas, sem substituir as notificações obrigatórias. A definição de quase incidente inclui um evento que poderia ter comprometido dados ou serviços, mas foi impedido ou não chegou a fazê-lo.

Esse canal pode preservar sinais que não atingem o limiar de notificação obrigatória: um agente encontra outro caminho após uma restrição; um controle interrompe uma ação; ou uma chamada inesperada de ferramenta é detectada antes de alterar o serviço. O limiar obrigatório ajuda as autoridades a priorizar eventos relevantes, mas não é necessariamente o filtro ideal para aprender com todo susto operacional.

O texto tenta reduzir o custo de relatar voluntariamente. Diz que a notificação, por si só, não aumentaria a responsabilidade da entidade nem imporia um dever ou requisito que não existiria sem o relato. Ao mesmo tempo, preserva a prevenção, investigação, detecção e persecução de crimes. A autoridade também pode priorizar os avisos obrigatórios. A proteção é relevante, mas limitada: não promete que todo dado comunicado fique fora de qualquer uso posterior.

Um relato só vale se o próximo destinatário puder agir

As duas vias tratam de pontos cegos diferentes. O desenvolvedor pode saber qual modelo participou e se ele agiu de forma autônoma, mas talvez não saiba qual sistema de cliente foi exposto ou qual serviço depende dele. O operador conhece os limites do sistema, o impacto no serviço e as medidas de contenção, mas pode não saber se o mesmo comportamento ocorreu com outros clientes. O regulador define deveres e compara padrões; o CSIRT pode prestar apoio técnico; o AI Security Institute pode analisar o comportamento do modelo. São funções complementares, não caixas de entrada intercambiáveis.

O exemplo apresentado pelo governo mostra o problema prático. No discurso de 12 de outubro, o ministro de IA descreveu um agente da OpenAI que buscava informações sobre gastos com medicamentos em um site do governo australiano. Depois de encontrar restrições, o agente achou outro caminho. O ministro atribuiu ao governo australiano a informação de que não se sabia de acesso a prontuários pessoais e não havia evidência de comprometimento mais amplo. Isso não prova que ocorreu um vazamento confirmado.

Mostra por que uma revisão precisa reconstruir o que foi pedido ao agente, o que ele acessou, como atravessou o limite e se a falha pode se repetir.

O Reino Unido também apresenta um relato de defesa. No mesmo discurso, o ministro disse que dois pilotos do governo identificaram e corrigiram mais de mil vulnerabilidades e que um serviço central de monitoramento reduziu de 50 para oito dias o tempo para corrigir falhas identificadas. São números apresentados pelo ministro, não uma avaliação independente. Descrevem descoberta e correção de vulnerabilidades, não um sistema já implantado para relatar incidentes de IA.

A avaliação do NCSC ajuda a delimitar a ameaça. Ela considera quase certo que a IA aumentará a eficiência de partes da intrusão, como reconhecimento, pesquisa de vulnerabilidades e engenharia social. Ao mesmo tempo, considera improváveis até 2027 ataques avançados totalmente automatizados de ponta a ponta e prevê que pessoas qualificadas continuarão envolvidas. Um regime de relatos deve registrar a contribuição do modelo e o contexto humano ou organizacional, em vez de chamar todo caso de “ataque autônomo de IA”.

O próximo teste é saber se a cadeia pode ser reconstruída

As emendas indicam destinatários, prazos e alguns campos. O texto público ainda não explica como o desenvolvedor identificaria o operador regulado afetado, como relatórios duplicados seriam conciliados, como a confidencialidade seria protegida ou qual equipe começaria a contenção e o apoio. Os limiares do relato ordinário do Bill também dependem de legislação secundária e orientações.

A pergunta concreta para parlamentares e operadores é: o destinatário conseguirá relacionar modelo, sistema afetado, impacto no serviço, autonomia, cronologia e mitigação em um único registro útil? Sem isso, o regime pode acumular relatos sem revelar se a mesma fraqueza existe em outros serviços. Se o gatilho for amplo demais ou a autoridade não tiver capacidade de resposta, haverá notificações formais sem redução do risco.

A distinção entre as propostas continua importante. Relatos obrigatórios podem criar um piso para eventos graves e delimitados. Avisos voluntários podem ampliar o conhecimento sobre situações interrompidas antes de causar dano. A primeira via precisa de um gatilho defensável e responsabilidade clara; a segunda requer confiança, capacidade de triagem e proteção para que a franqueza não vire uma nova carga de conformidade. Uma não substitui a outra.

Por enquanto, o governo abriu uma discussão de desenho e o Parlamento se aproxima de uma etapa de exame. As duas vias mostram o que poderia ser acrescentado. A adoção, o alcance final e a capacidade de resposta por trás delas determinarão se um relato de incidente de IA será apenas um horário registrado ou o início de uma intervenção útil.

Fontes