001 · Ponto de partida: as decisões antes do produto

Este diário documenta, em aberto, a preparação do nosso produto de IoT agrícola para o Cyber Resilience Act — incluindo as decisões que vierem a revelar-se erradas. O produto está em fase de protótipo, com ensaio de campo em Coruche, e a previsão de mercado é 2027–2028. Ou seja, se tudo correr como planeado, o produto nasce já dentro da aplicação plena do regulamento, sem período de transição para nós. Foi uma escolha deliberada.

O que já está decidido

1. A classificação de trabalho é “produto por omissão”. Monitorização agrícola não consta do Anexo III. A hipótese fica documentada com a fundamentação e revisita-se a cada alteração de âmbito funcional — a lição do artigo sobre classificação é que uma funcionalidade acrescentada pode mudar a categoria, e connosco a tentação existirá (um sensor que “também deteta intrusão” seria outra conversa).

2. SBOM desde o primeiro build com tag. Gerada pelo sistema de build, nunca à mão, arquivada com o binário. A escolha concreta de tooling depende do build system que fixarmos no fim da fase de protótipo; o critério já está fixado: só entra na shortlist o que gerar SBOM nativamente. As lacunas (blobs de fornecedor) serão declaradas como lacunas.

3. O período de suporte é restrição de design, não campo de formulário. Alvo de trabalho: cinco anos. Consequência imediata, já em vigor na fase de protótipo: nenhum componente entra na BOM sem data de fim de vida conhecida e compatível, e o custo anual da infraestrutura de atualização entra no modelo de custos do produto desde já.

4. O processo de reporte monta-se antes de haver o que reportar. As obrigações do artigo 14.º só nos tocarão quando houver produto no mercado — mas o processo (triagem, decisão de conhecimento, modelos das três notificações) fica escrito e ensaiado muito antes, porque é também o que recomendamos a clientes e não recomendamos o que não fazemos.

5. Divulgação coordenada desde o site. O security.txt deste site é o embrião da política de divulgação coordenada que o CRA exigirá para o produto. Próximo passo documentado aqui: publicar chave PGP e política formal.

O que ainda não sabemos

Com a honestidade que um diário exige: não temos ainda resposta fechada para (a) a arquitetura de atualização OTA num contexto de conectividade intermitente rural — que é o nosso contexto — e as suas implicações no requisito de atualizações seguras; (b) se o processamento remoto que planeamos será “integral às funções do produto” no sentido do regulamento, o que definiria o perímetro da documentação técnica; (c) o estado das normas harmonizadas do CRA à data em que precisarmos delas.

Cada uma destas terá a sua entrada quando a resposta existir — ou quando a primeira tentativa falhar.

Porque é que isto é público

Um caso de estudo de cliente nunca pode ter este detalhe; o nosso próprio produto pode. Se o leitor estiver a fazer o mesmo percurso e discordar de alguma decisão, o email está no rodapé — a discordância fundamentada é mais útil do que a leitura silenciosa.