Cinco regras da UE que hoje moldam a arquitetura de sistemas

A regulação costuma ser lida como uma lista de deveres a documentar. Os cinco instrumentos deste artigo leem-se melhor como uma lista de propriedades que um sistema tem de conseguir mostrar: onde passa uma fronteira, o que um build produz, quem pode aceder a um repositório e a partir de onde, para onde os dados têm de poder ir e quem responde quando algo corre mal. Cada um deles mudou de estado entre setembro de 2025 e setembro de 2026, e cada um foi lido na sua fonte primária em 17 de setembro de 2026. As datas são as dos próprios instrumentos, não as de relatos secundários.

Isto é um mapa, não aconselhamento. Saber se algum destes textos se aplica a um sistema concreto é uma determinação jurídica que depende do produto, do setor e do papel da organização, e nada do que se segue a substitui. O que o artigo faz é traduzir cada instrumento na pergunta arquitetural que ele impõe, porque essa pergunta tem de ser respondida no desenho, antes de se consultar um jurista.

O Regulamento (UE) 2024/1689, o AI Act, não se aplica a sistemas de IA na medida em que sejam colocados no mercado, colocados em serviço ou utilizados, com ou sem modificação, exclusivamente para fins militares, de defesa ou de segurança nacional (artigo 2.º, n.º 3). A palavra que importa é exclusivamente. Um sistema construído para uma utilização civil e para uma utilização de defesa não é exclusivamente militar, pelo que a sua utilização civil está inteiramente dentro do regulamento, seja qual for a sua utilização de defesa.

O calendário mudou neste verão. O Regulamento (UE) 2026/1744, o Digital Omnibus, entrou em vigor em 27 de julho de 2026 e recalendarizou o regime de risco elevado: as categorias autónomas do anexo III, como as decisões de emprego e o acesso a serviços essenciais, aplicam-se a partir de 2 de dezembro de 2027, e os sistemas incorporados em produtos regulados nos termos do anexo I a partir de 2 de agosto de 2028. As obrigações de transparência do artigo 50.º não foram adiadas e aplicam-se desde 2 de agosto de 2026, com uma transição até 2 de dezembro de 2026 apenas para o dever de marcação dos sistemas generativos já no mercado. As proibições do artigo 5.º aplicam-se desde 2 de fevereiro de 2025.

Para a arquitetura, o artigo 2.º, n.º 3, é uma fronteira que tem de existir no sistema, não apenas num contrato. Se um modelo treinado com dados civis for reutilizado num contexto de defesa, ou um componente de defesa for reutilizado num produto civil, as duas utilizações têm de ser separáveis a pedido: implantações separadas, pipelines que não partilhem dados de treino ou pesos por acidente, e proveniência para cada artefacto que diga a que lado pertence e a partir de que foi construído. É a lógica do passaporte digital de produto aplicada a modelos, conjuntos de dados e prompts. Um artefacto que não consegue indicar a sua origem não pode ser colocado de nenhum dos lados da linha.

O Regulamento (UE) 2024/2847, o Cyber Resilience Act, aplica-se na íntegra a partir de 11 de dezembro de 2027, mas o seu dever de notificação chegou primeiro. Desde 11 de setembro de 2026, o artigo 14.º exige que um fabricante que tome conhecimento de uma vulnerabilidade ativamente explorada num produto com elementos digitais, ou de um incidente grave que afete a sua segurança, o notifique através da plataforma única de notificação operada pela ENISA: um alerta precoce em 24 horas, uma notificação em 72 horas e um relatório final o mais tardar 14 dias depois de estar disponível uma medida corretiva, ou um mês no caso de um incidente. Os utilizadores afetados têm de ser informados sem demora injustificada, juntamente com as medidas que podem tomar (artigo 14.º, n.º 8). O capítulo IV, sobre os organismos que irão avaliar os produtos, aplica-se desde 11 de junho de 2026.

Um relógio de 24 horas não se cumpre com um processo que começa com alguém a abrir uma folha de cálculo. Pressupõe que o fabricante já sabe o que está em cada versão entregue, o que exige uma lista de materiais de software produzida pelo build e não escrita depois; que fica a saber da exploração a partir do terreno, o que exige telemetria do produto implantado e um canal para relatos de vulnerabilidades; e que consegue entregar uma versão corretiva em dias, o que exige um pipeline de entrega exercitado por rotina e não apenas em emergências. Na Alemanha, a diretriz técnica TR-03183 do Gabinete Federal para a Segurança da Informação descreve o conteúdo mínimo que uma lista dessas deve ter.

O Regulamento (UE) 2021/821 controla a exportação de produtos de dupla utilização, e a sua definição de exportação não termina nas mercadorias que atravessam uma fronteira. Inclui a transmissão de software ou de tecnologia por meios eletrónicos e a disponibilização dessa software ou tecnologia, em formato eletrónico, a pessoas fora do território aduaneiro da União (artigo 2.º, ponto 2). Quem, fora da União, recebe acesso a um repositório, a um armazenamento de objetos ou a um cluster com tecnologia controlada está, nos termos dessa definição, a receber uma exportação, e ela precisa da mesma autorização que uma remessa.

A lista de controlo, o anexo I, foi atualizada pelo Regulamento Delegado (UE) 2025/2003 da Comissão, em vigor desde 15 de novembro de 2025. A atualização incluiu computadores quânticos e os seus componentes criogénicos, equipamentos e materiais para o fabrico de semicondutores avançados, computação de alto desempenho, sistemas de fabrico aditivo para metais e os pós que utilizam, e outros materiais avançados. Boa parte dessa lista descreve aquilo para que uma empresa de software industrial constrói, ou sobre o que corre.

Em termos de arquitetura, isto transforma a gestão de identidades e acessos num instrumento de controlo de exportação. Uma decisão de acesso tem de conseguir avaliar onde está a pessoa e para onde iriam os dados antes de conceder o que quer que seja; quando há produtos de origem norte-americana envolvidos, as regras desse país acrescentam a nacionalidade como atributo, o que o direito europeu não faz. Ambos os atributos são dados pessoais, pelo que a sua recolha tem de ser justificada face à minimização dos dados do artigo 5.º, n.º 1, alínea c), do RGPD, e essa tensão tem de ser desenhada, não descoberta. E como uma classificação pertence a um artefacto e não a uma equipa, tem de viajar com o artefacto ao longo do build: um repositório, uma imagem de contentor e um checkpoint de modelo transportam cada um a sua classificação, e um pipeline que não a consegue ler não a consegue impor.

O Regulamento (UE) 2023/2854, o Data Act, aplica-se desde 12 de setembro de 2025. Dá aos utilizadores de produtos conectados, e dos serviços com eles relacionados, o direito de aceder aos dados que esses produtos geram e de os fazer partilhar com um terceiro à sua escolha (artigos 4.º e 5.º). Para os produtos colocados no mercado depois de 12 de setembro de 2026, o próprio produto tem de ser concebido de modo a que os dados sejam acessíveis por defeito, de forma fácil, segura e num formato abrangente, estruturado e legível por máquina (artigo 3.º, n.º 1).

O mesmo regulamento alcança os fornecedores de nuvem. Os prestadores de serviços de tratamento de dados têm de permitir que um cliente mude para outro prestador ou para a sua própria infraestrutura, com equivalência funcional quando o serviço é do mesmo tipo. As taxas de mudança estão reduzidas desde 11 de janeiro de 2024 e não podem ser cobradas de todo a partir de 12 de janeiro de 2027 (artigo 29.º).

Para uma arquitetura industrial ou de edge, a consequência é que uma interface de exportação de dados é uma funcionalidade do produto com definição legal, e que uma implantação capaz de sair do seu fornecedor de nuvem é um requisito e não uma preferência. O modelo de dados de uma máquina, e os formatos em que os dados a deixam, fazem agora parte do que um desenho tem de mostrar.

A Diretiva (UE) 2022/2555, a NIS2, obrigou os Estados-Membros a aplicar as suas medidas de transposição a partir de 18 de outubro de 2024. A Alemanha atrasou-se: a sua lei de transposição, a NIS2UmsuCG, entrou em vigor em 6 de dezembro de 2025 e reescreveu a lei do BSI. A estimativa do governo federal que acompanhou o projeto de lei apontou para cerca de 29 500 entidades abrangidas, em dezoito setores, com o Gabinete Federal para a Segurança da Informação (BSI) como autoridade de supervisão.

Duas disposições carregam o peso arquitetural. O dever de notificação de incidentes tem a mesma forma que no Cyber Resilience Act: um alerta precoce em 24 horas depois de tomar conhecimento de um incidente significativo, uma notificação em 72 horas e um relatório final no prazo de um mês (artigo 23.º da diretiva). E o § 38 da nova lei do BSI torna os membros da direção de uma entidade pessoalmente responsáveis por aprovar as medidas de gestão do risco, por acompanhar a sua execução e por participar em formação, e não permite que essa responsabilidade seja afastada.

A partir do momento em que uma direção responde pessoalmente, a segurança deixa de ser uma função de apoio e passa a ser uma propriedade que a arquitetura tem de demonstrar: um inventário do que corre, um percurso de incidente que consiga cumprir um prazo de 24 horas, resiliência durante um ataque e não apenas depois dele, e evidência de que as medidas aprovadas estão de facto implementadas. Uma medida que existe num documento de política e em lado nenhum do sistema é exatamente aquilo sobre que um supervisor vai perguntar.

Postos lado a lado, os cinco instrumentos pedem cinco propriedades arquiteturais. O AI Act pergunta onde passa a fronteira entre utilização civil e de defesa, e pede prova de que lado está cada artefacto. O Cyber Resilience Act pergunta o que um build produz e com que rapidez uma correção pode ser entregue. O controlo de exportação pergunta quem pode aceder a um repositório e a partir de onde. O Data Act pergunta para onde os dados têm de poder ir e em que forma. A NIS2 pergunta quem aprovou o risco e como se mostra que o que foi aprovado é o que corre.

O que os cinco partilham é uma exigência de proveniência e de evidência ao nível do artefacto individual: um modelo, um build, uma imagem de contentor, um conjunto de dados, o fluxo de dados de uma máquina, cada um com a sua origem, a sua classificação e as verificações que passou. É a propriedade que um passaporte digital de produto dá a um produto físico, e é a propriedade que estes textos passam agora a pedir ao software. Um sistema que a transporta responde às cinco perguntas a partir dos seus próprios registos. Um sistema que não a transporta tem de reconstruir a resposta de cada vez, com um prazo a correr.

Não diz que algum destes instrumentos se aplica a um determinado sistema, produto ou organização. O âmbito depende de factos que este artigo não tem e de definições, como produto com elementos digitais, entidade essencial ou detentor de dados, que cada texto define por si.

Não diz que a arquitetura aqui descrita é suficiente. Implantações separadas, uma lista de materiais, acesso baseado em atributos, uma interface de exportação e um percurso de incidente são o que os textos pressupõem; cada instrumento pede mais, e parte disso, como a avaliação de produtos ao abrigo do Cyber Resilience Act ou o registo junto do BSI, é processual e não técnica.

E não diz que as datas são definitivas. Três dos cinco instrumentos já mudaram uma vez. Cada data acima indica o instrumento de onde vem, para que possa ser confrontada com o texto no dia em que importar.