Seu Código Escrito por Agente Agora Entra em um Relógio de 24 Horas

A janela é de 24 horas. É o que um fabricante tem agora para registrar um alerta inicial assim que toma conhecimento de uma vulnerabilidade ativamente explorada em um produto com elementos digitais colocado no mercado da União Europeia. A obrigação começou em 11 de setembro de 2026 e vale também para produtos que já estavam no mercado, não apenas para o que for lançado daqui em diante. O restante do Cyber Resilience Act, as obrigações gerais de conformidade de produto, só se aplica a partir de 11 de dezembro de 2027. O relógio de notificação não esperou.

As obrigações são curtas o bastante para citar como a nossa fonte as descreve. O alerta inicial é devido “sem demora indevida e, em todo caso, em até 24 horas depois de o fabricante tomar conhecimento da vulnerabilidade ou do incidente”. Em até 72 horas, o fabricante precisa enviar uma notificação mais detalhada cobrindo “as informações disponíveis sobre o produto afetado, a natureza, a gravidade e o impacto da vulnerabilidade ou do incidente, bem como quaisquer medidas corretivas ou mitigadoras tomadas ou disponíveis”. Depois vem um relatório final: para uma vulnerabilidade ativamente explorada, em geral em até 14 dias depois de uma medida corretiva ou mitigadora ficar disponível; para um incidente grave, em até um mês depois da notificação de 72 horas.

Lido como requisito de engenharia, e não como requisito jurídico, esse cronograma faz uma pergunta bem específica à sua base de código: em 24 horas, alguém na sua empresa consegue dizer o que um trecho de código faz, por que ele foi escrito daquele jeito e o que mais ele toca?

O relógio pressupõe uma base de código que alguém saiba explicar

Dois eventos disparam o relógio. O primeiro é a vulnerabilidade ativamente explorada, definida como uma fragilidade de segurança “para a qual há evidência confiável de que um agente malicioso a explorou”. O segundo é um incidente grave que afete a segurança de um produto. Os dois partem do momento em que você toma conhecimento, e esse momento é produzido pela sua própria detecção. Um monitoramento melhor faz você saber mais cedo, o que dispara o relógio mais cedo. O resultado é o correto e também é desconfortável.

O que a notificação de 72 horas exige merece planejamento. Natureza, gravidade e impacto da vulnerabilidade. Medidas corretivas ou mitigadoras tomadas ou disponíveis. Isso é um relato causal de um defeito: como ele entrou, o que ele alcança, o que o fecha. Na minha experiência, produzir esse relato em três dias depende de algo informal: a existência de alguém que lembra da mudança, ou um rastro de revisão detalhado o bastante para substituir essa pessoa.

Código escrito por agente e mesclado com rastro de revisão magro enfraquece os dois. Ninguém guarda a memória, e o artefato que substituiria a memória é a revisão, e a revisão é o passo que eu esperaria ver comprimido primeiro quando o código chega mais rápido do que um humano consegue ler. A pergunta sobre autoria mede tempo de recuperação sob um prazo que você não escolheu, e culpa fica de fora.

Quem carrega o dever

A parte obrigada nomeada no regime é o fabricante. A fonte não nomeia mais ninguém: nem o fornecedor do agente, nem o provedor do modelo, nem o mantenedor open-source cuja biblioteca o agente trouxe para dentro. Quem colocou o produto no mercado europeu responde ao relógio.

Isso importa porque o reflexo que eu vejo quando código escrito por agente causa um problema é olhar para cima na cadeia. Esse reflexo não tem em que se apoiar no dever de notificação como esta fonte o descreve. Seja qual for a origem do código, é o fabricante que registra o alerta inicial, escreve o relato de 72 horas e entrega o relatório final. Já escrevemos sobre como os requisitos de conformidade se acumulam sobre quem detém o artefato, e o dever de notificação do CRA é um caso limpo disso: o custo cai onde está a propriedade, independentemente de onde a digitação aconteceu.

O escopo vai além de hardware. Como a análise resume, o Act “se aplica a produtos de hardware e software disponibilizados na UE cujo uso pretendido ou razoavelmente previsível envolva conexão direta ou indireta a um dispositivo ou rede”, e isso inclui explicitamente “aplicações de software … software de contabilidade e finanças, jogos e apps, bem como software open-source fornecido no curso de uma atividade comercial”.

Uma ressalva, porque a tentação de ler demais é grande. A fonte em que esta análise se apoia trata de produtos de software disponibilizados na UE. Ela não resolve se um serviço entregue puramente pela rede cai na mesma definição, e não usa as palavras SaaS ou nuvem em nenhum momento. Se o seu produto é um serviço hospedado, e não algo que o cliente instala, trate a questão de escopo como aberta e leia o Artigo 2 e a definição de “produto com elementos digitais” do Artigo 3 antes de concluir qualquer coisa.

O pré-requisito que tem prazo de maturação

Os relatórios vão para a plataforma única de notificação do CRA, operada pela Agência da União Europeia para a Cibersegurança (ENISA), e ficam disponíveis para o CSIRT coordenador. Registro prévio na plataforma fica dispensado.

A conta EU LOGIN é outra história. A orientação é explícita: ela deve ser criada com antecedência, e quem submete precisa ter essa conta e estar registrado como “Assigned Representative” do fabricante. Os dois são passos de identidade, e passos de identidade em qualquer organização são os que levam dias por motivos que nada têm a ver com o trabalho técnico. Alguém está de férias, alguém precisa aprovar, alguém precisa decidir de quem é o nome que vai na submissão.

Descobrir isso na hora dois de uma janela de 24 horas é uma falha evitável. Também é o item mais barato desta página, e dá para resolver esta semana com uma pessoa que nem precisa tocar na base de código.

Uma obrigação separada corre em paralelo à submissão ao regulador. O fabricante precisa informar os usuários impactados sem demora indevida e, quando apropriado, todos os usuários. Nenhuma contagem de horas é anexada a essa. O momento certo vira um julgamento que o seu processo de comunicação precisa conseguir fazer rápido. Planejamento em cima de data marcada fica de fora.

O que ter pronto antes de precisar

A submissão de 24 horas é um alerta inicial; a fonte detalha o conteúdo exigido apenas para a notificação de 72 horas. A notificação de 72 horas é onde o trabalho se concentra, e os insumos dela são coisas que você já tem ou que passa três dias tentando reconstruir.

A reconstrução é onde o código escrito por agente cobra o preço. Se o seu registro de revisão diz que uma mudança passou, mas não diz o que ela mudou nem por que o revisor aceitou, você tem um rastro de auditoria que comprova processo e não explica nada. O mesmo modo de falha aparece em operações que derivam sem ninguém perceber, onde o registro do que rodou existe e o registro do significado se perde. Um prazo de notificação transforma isso de incômodo em exposição jurídica.

A disciplina útil é a que faz o harness produzir a explicação como subproduto, em vez de pedir para um humano escrevê-la depois. Governar o processo que gera o código, e não o modelo que o escreve, deixa você com algo para entregar a um investigador: o que o livro de regras exigia, quais verificações mecânicas rodaram, por qual portão de revisão a mudança passou e o que o revisor de fato olhou.

Faça isto agora

Crie a conta EU LOGIN e nomeie o “Assigned Representative” ainda esta semana, antes de qualquer incêndio. Depois faça um ensaio com um defeito real de um produto que você colocou no mercado europeu: escolha uma vulnerabilidade que você já corrigiu e cronometre quanto tempo o seu time leva para produzir o conteúdo de 72 horas dela, o produto afetado, a natureza e o impacto, as medidas disponíveis. Se passar de um dia, a falta está no seu registro de mudanças, e a correção é fazer o harness escrever por que uma mudança era segura no momento em que ela é mesclada, em vez de meses depois, quando um regulador pergunta.

Fontes

Squire Patton Boggs / The National Law Review. “Cyber Resilience Act: 11 September 2026 as Key Starting Point for Reporting Obligations.” Setembro de 2026.

A Victorino ajuda times de engenharia a tornar mudanças escritas por agentes explicáveis rápido o bastante para sobreviver a um prazo regulatório: contato@victorino.com.br | www.victorino.com.br