Sobre nósServiçosProjetosArtigos

Engenharia de conformidade com o Regulamento da Inteligência Artificial: documentação técnica, registos, supervisão humana e governação de dados

Quase tudo o que se escreveu sobre o Regulamento da Inteligência Artificial da UE (AI Act) trata do âmbito: em que nível de risco fica o seu sistema, se a sua empresa é prestador ou responsável pela implantação, se o sistema cai no Anexo III. Essa resposta cabe aos seus assessores jurídicos.

Quase ninguém fala do que acontece depois dessa resposta. Se o seu sistema for de risco elevado, o regulamento exige um sistema de gestão de riscos que acompanhe todo o ciclo de vida, uma governação de dados que se possa demonstrar, registos automáticos com prazos de conservação definidos, documentação técnica numa estrutura prescrita, supervisão humana concebida de raiz (e não apenas declarada) e uma monitorização pós-comercialização que recolha de facto alguma coisa. Tudo isto são entregáveis de engenharia. É essa a parte que construímos.

Em que ponto estão os prazos

O Regulamento da Inteligência Artificial (Regulamento (UE) 2024/1689) entrou em vigor em agosto de 2024 e aplica-se por fases. O calendário mudou em 2026, e convém ser rigoroso, porque essa mudança deslocou orçamentos e atenção.

  • 2 de fevereiro de 2025: passaram a aplicar-se as práticas proibidas e as obrigações de literacia no domínio da IA.
  • 2 de agosto de 2025: passaram a aplicar-se as obrigações relativas aos modelos de IA de finalidade geral.
  • 2 de agosto de 2026: passaram a aplicar-se as obrigações de transparência do artigo 50.º: informar o utilizador de que está a interagir com um sistema de IA, marcar os conteúdos sintéticos, divulgar o reconhecimento de emoções e a categorização biométrica e identificar as falsificações profundas (deep fakes).
  • 2 de dezembro de 2027: obrigações de risco elevado para sistemas autónomos, na sequência do Omnibus Digital. O Conselho e o Parlamento acordaram o adiamento em maio de 2026, e a aprovação final chegou em junho de 2026.
  • 2 de agosto de 2028: obrigações de risco elevado para sistemas de IA integrados em produtos regulamentados.

Se a sua empresa é prestador de um sistema de risco elevado, o adiamento deu-lhe cerca de dezasseis meses. Não reduziu o trabalho e não alterou as duas obrigações que já estão em vigor: a transparência do artigo 50.º e a literacia no domínio da IA para quem opera estes sistemas.

O que construímos

Documentação técnica, gerada como um artefacto

O Anexo IV define o que a documentação técnica tem de conter: descrição do sistema, opções de conceção, arquitetura, requisitos de dados, metodologia de treino quando aplicável, procedimentos de validação e de teste, métricas, medidas de gestão de riscos e as alterações feitas ao longo do ciclo de vida.

Escrito à mão, este documento fica desatualizado uma semana depois de assinado. Nós construímo-lo como algo que o seu pipeline produz: model cards e fichas de dados gerados a partir das execuções de treino e de avaliação, descrições da arquitetura e dos fluxos de dados mantidas junto ao código, resultados de avaliação associados à versão que descrevem e um histórico de alterações que sai do controlo de versões, e não da memória de alguém. O documento passa a ser um resultado do build.

Registos automáticos que cumprem o artigo 12.º

Os sistemas de risco elevado têm de registar eventos automaticamente durante toda a sua vida útil, com um nível que permita a rastreabilidade do funcionamento e a monitorização pós-comercialização, com conservação adequada à finalidade e, em alguns casos, de pelo menos seis meses.

Na prática, isto significa decidir o que é um «evento» no seu sistema, captar entradas, saídas, versão do modelo, percurso da decisão e a identidade da pessoa envolvida, guardar tudo num formato que se possa consultar anos depois e fazê-lo sem acumular dados pessoais que não tem fundamento para conservar. Essa tensão (registar o suficiente para o Regulamento da IA, guardar o mínimo para o RGPD) é o verdadeiro problema de conceção, e trabalhamo-lo de forma explícita com os responsáveis pela proteção de dados da sua empresa.

Governação de dados nos termos do artigo 10.º

Os conjuntos de dados de treino, validação e teste têm de ser pertinentes, suficientemente representativos e, tanto quanto possível, isentos de erros e completos, com análise de enviesamentos. Cumprir isto exige uma linhagem de dados demonstrável, proveniência documentada, uma metodologia de avaliação de enviesamentos com resultados e a capacidade de reproduzir que dados deram origem a que versão do modelo.

Construímos o pipeline que torna essas afirmações verificáveis, e não meras intenções: conjuntos de dados versionados, divisões reproduzíveis, verificações automáticas da qualidade dos dados e avaliação de enviesamentos nas características protegidas relevantes para o seu caso de utilização.

Supervisão humana, construída e não apenas declarada

O artigo 14.º exige que os sistemas de risco elevado sejam concebidos de modo a que uma pessoa consiga compreender o resultado, manter-se atenta ao enviesamento de automação, interpretar corretamente o resultado, decidir não o usar e intervir ou parar o sistema.

Isso é uma especificação de interface. Integramos a supervisão no produto: confiança e incerteza mostradas com honestidade, os fatores por trás de cada resultado tornados visíveis, uma forma de contrariar a decisão tão fácil de usar como a de a aceitar, um comando de paragem que funciona e o registo de cada intervenção humana, para que a monitorização pós-comercialização tenha com que aprender.

Monitorização pós-comercialização e comunicação de incidentes

É obrigatório ter um plano de monitorização e comunicar os incidentes graves à autoridade competente. Construímos a telemetria que o alimenta: desempenho medido face às métricas da sua documentação, deteção de desvios nas entradas e nas saídas, um canal para os problemas comunicados pelos utilizadores que chegue à engenharia e um fluxo de tratamento de incidentes com os prazos obrigatórios já incorporados, em vez de descobertos a meio de um incidente.

Obrigações de transparência do artigo 50.º

Já estão em vigor. Informar o utilizador de que está a lidar com um sistema de IA, marcar de forma legível por máquina o áudio, a imagem, o vídeo e o texto sintéticos, identificar as falsificações profundas e divulgar o reconhecimento de emoções. Implementamos os elementos de divulgação e a marcação da proveniência dos conteúdos (credenciais de conteúdo C2PA, quando esse é o mecanismo certo) e garantimos que sobrevivem aos percursos de exportação e recodificação que normalmente as eliminam.

Apoio ao registo e à avaliação da conformidade

Os sistemas de risco elevado das áreas do Anexo III têm de ser registados na base de dados da UE antes de serem colocados no mercado, e os prestadores têm de realizar uma avaliação da conformidade. Preparamos os contributos técnicos (a documentação, o dossiê de evidências e, do lado da engenharia, os artefactos do sistema de gestão da qualidade) e trabalhamos em conjunto com o seu organismo notificado ou com o seu processo de avaliação interna.

O que não fazemos

Não prestamos aconselhamento jurídico nem lhe dizemos em que nível de risco está o seu sistema. Essa determinação é jurídica, tem consequências reais e cabe a um advogado ou a um consultor de conformidade qualificado.

Também não vendemos uma plataforma de governação de IA. Há muitas no mercado e, se precisa de um registo de sistemas de IA e de um fluxo de políticas, uma delas servi-lo-á melhor do que nós. O que fazemos é a engenharia dentro dos próprios sistemas.

A quem se destina

Prestadores de sistemas de IA de risco elevado abrangidos pelo Anexo III (recrutamento e gestão de trabalhadores, avaliação de crédito, tarifação de seguros, avaliação no ensino, elegibilidade para serviços essenciais, sistemas biométricos), que têm agora até dezembro de 2027 e muito para construir.

Fabricantes que integram IA em produtos regulamentados (dispositivos médicos, máquinas, veículos), em que o Regulamento da IA se sobrepõe a um regime de conformidade já existente e os dois conjuntos de documentação têm de bater certo.

Empresas que implantam sistemas de risco elevado comprados a terceiros, que têm obrigações próprias: supervisão humana, pertinência dos dados de entrada, monitorização e conservação dos registos.

Quem disponibiliza funcionalidades generativas a utilizadores na UE, já sujeitas hoje à transparência do artigo 50.º, seja qual for o nível de risco.

Como decorre o trabalho

Avaliação técnica de lacunas, de duas a quatro semanas. Partimos da classificação a que a sua equipa jurídica chegou e avaliamos os seus sistemas face às obrigações de engenharia que dela decorrem. O resultado é um registo de lacunas (obrigação, situação atual, o que é preciso construir, esforço) com que as suas chefias de conformidade e de engenharia podem trabalhar.

Construção, por fases, normalmente a começar pelos registos e pela geração da documentação, porque tudo o resto produz evidências que têm de ficar guardadas algures.

Revisão de prontidão antes da avaliação da conformidade, com o dossiê de evidências montado e as lacunas que faltam identificadas com honestidade.

Normas e referenciais

O Regulamento (UE) 2024/1689 e os seus Anexos III e IV; as normas harmonizadas que estão a sair do CEN/CENELEC JTC 21; a ISO/IEC 42001 para sistemas de gestão de IA e a ISO/IEC 23894 para a gestão de riscos de IA; o NIST AI Risk Management Framework, quando uma empresa-mãe nos EUA precisa de alinhamento; e o RGPD, que não desaparece e condiciona a maioria das decisões sobre registos.

Perguntas frequentes

O Regulamento da IA foi adiado?

Em parte. O Omnibus Digital adiou as obrigações de risco elevado para 2 de dezembro de 2027 no caso dos sistemas autónomos e para 2 de agosto de 2028 no caso da IA integrada em produtos regulamentados. As práticas proibidas, a literacia no domínio da IA, as obrigações dos modelos de IA de finalidade geral e as regras de transparência do artigo 50.º não foram adiadas e estão em vigor.

Só usamos sistemas de IA desenvolvidos por terceiros. Temos obrigações?

Sim, como responsável pela implantação. Incluem utilizar o sistema de acordo com as instruções, atribuir a supervisão humana a pessoas com competência e autoridade para a exercer, garantir que os dados de entrada são pertinentes para a finalidade prevista, monitorizar o funcionamento e conservar os registos. São obrigações mais leves do que as de um prestador, mas reais. E atenção: alterar substancialmente um sistema ou colocar-lhe o seu nome pode fazer da sua empresa um prestador.

O nosso sistema não é de risco elevado. Há alguma coisa a fazer?

Provavelmente duas. A transparência do artigo 50.º aplica-se a certos sistemas seja qual for o nível de risco, incluindo chatbots e geração de conteúdos sintéticos. E a literacia no domínio da IA, prevista no artigo 4.º, aplica-se a prestadores e responsáveis pela implantação em geral. Para além disso, vale a pena conseguir demonstrar a decisão de classificação, caso um regulador alguma vez a peça.

A documentação técnica pode mesmo ser gerada?

Na sua maior parte, sim. A arquitetura, as descrições dos conjuntos de dados, os resultados de avaliação, as métricas, as versões dos modelos e o histórico de alterações já existem nos seus sistemas; o trabalho está em captá-los numa estrutura estável no momento do build. As secções verdadeiramente narrativas (finalidade prevista, análise de riscos, fundamentação da conceção) são escritas por pessoas e guardadas no mesmo repositório, para que tenham versões como tudo o resto.

Como se relaciona o Regulamento da IA com o RGPD?

Sobrepõem-se e, por vezes, puxam em sentidos opostos, sobretudo nos registos. O Regulamento da IA quer rastreabilidade; o RGPD quer minimização e apagamento. A solução passa normalmente pela pseudonimização, por delimitar com cuidado o que se regista e por prazos de conservação definidos e ligados a uma finalidade documentada. É uma decisão de conceção, tomada uma vez e de forma deliberada.

Usar um modelo de terceiros faz de nós prestadores desse modelo?

Não, mas construir um sistema de IA sobre esse modelo pode fazer da sua empresa a prestadora desse sistema, com as obrigações que lhe estão associadas. Onde passa a fronteira depende do que constrói e de como o apresenta, o que é uma questão jurídica; a consequência para a engenharia é que deve partir do princípio de que vai precisar, em qualquer caso, de documentação do seu próprio sistema.

Começar

Diga-nos o que fazem os seus sistemas e a que classificação chegaram os seus assessores jurídicos. Avaliamos o que as obrigações significam em código e entregamos-lhe um registo de lacunas com o esforço estimado para cada linha.

Contacte-nos para marcar uma avaliação técnica de lacunas face ao Regulamento da IA.

Serviços relacionados

Pronto para avançar com este serviço?

Contacte-nos
← Voltar a todos os serviços