Quando a documentação técnica se aplica e o que fazer depois

A documentação técnica é uma obrigação específica do AI Act quando uma empresa é prestadora de um sistema de risco elevado. O artigo 11 exige que seja preparada antes da colocação no mercado ou entrada em serviço, mantida atualizada e suficientemente clara para autoridades e organismos notificados avaliarem a conformidade. O anexo IV define o conteúdo mínimo.

Isto não significa que toda empresa SaaS que usa uma API de IA precise de um processo completo. A resposta depende dos limites do sistema, da função da empresa e da classificação. Mesmo sem obrigação direta, documentação proporcional apoia governação, avaliação de fornecedores, clientes, incidentes e reavaliações.

Confirmar sistema, função e classificação

Descreva o sistema inteiro: finalidade prevista, utilizadores, pessoas afetadas, entradas, saídas, integrações, contexto e influência do resultado. Um modelo externo pode ser apenas um componente do produto SaaS.

Determine depois a função. Quem desenvolve e comercializa em nome próprio um sistema de risco elevado é normalmente prestador; o cliente pode ser responsável pela implantação. Mudança de marca, alteração substancial ou nova finalidade podem deslocar responsabilidades. Avalie por fim as duas vias principais do artigo 6: produtos regulamentados do anexo I e utilizações do anexo III. Consulte o guia para prestadores SaaS.

Quando o artigo 11 se aplica

O artigo 11 e o anexo IV tratam da documentação dos sistemas de risco elevado e colocam a obrigação principal no prestador. Após o Regulamento (UE) 2026/1744, as regras para sistemas do anexo III aplicam-se a partir de 2 de dezembro de 2027 e as regras para sistemas integrados em produtos do anexo I a partir de 2 de agosto de 2028.

Não espere. Direito setorial, proteção de dados, contratos, segurança e revisões de clientes já podem exigir provas semelhantes. Começar cedo evita reconstruir versões, dados, testes e decisões.

Se o sistema não for de risco elevado ou a empresa apenas o implantar, o processo completo pode não ser exigido. Registe ainda assim a decisão, factos, revisor e gatilhos de reavaliação. Nova finalidade sensível, alterações materiais ao modelo ou dados, novos mercados ou maior impacto nas pessoas exigem nova análise.

Cobertura mínima

O anexo IV exige pelo menos:

1. Identidade, finalidade, versões, utilizadores e condições de operação.
2. Desenvolvimento, arquitetura, componentes e decisões de conceção.
3. Proveniência dos dados, validação, testes e limites de desempenho.
4. Riscos, controlos, supervisão humana, registos e escalonamento.
5. Robustez, cibersegurança e resultados indesejados previsíveis.
6. Alterações, incidentes e monitorização pós-comercialização.
7. Normas, via de conformidade e aprovações.
8. Rastreabilidade de cada afirmação a uma prova controlada.

O processo pode ser um índice com ligações para registos controlados. Ligações estáveis, permissões, versões e conservação importam mais do que o número de páginas.

Fluxo prático

1. Aprovar o âmbito: registar identificador, finalidade, limite, função, classificação e pressupostos.
2. Criar o índice do anexo IV: incluir fonte, proprietário, versão, estado, revisor e gatilho.
3. Manter a prova com o dono real: produto responde pela finalidade; engenharia, pela arquitetura; dados ou ML, pelas avaliações; segurança, pelos controlos; conformidade, pelo mapeamento.
4. Fechar primeiro as lacunas críticas: classificação, desempenho, riscos, supervisão e aprovação do lançamento.
5. Ligar alterações: finalidade, modelos, dados, limiares, utilizadores, integrações ou controlos devem acionar atualizações e, quando necessário, novos testes.
6. Testar a recuperação: um revisor independente deve seguir uma afirmação de desempenho, um controlo, um percurso de supervisão e uma versão até às provas.

A checklist de documentação técnica oferece uma estrutura detalhada. As respostas a clientes também devem corresponder aos controlos de IA pedidos pelos compradores.

Erros comuns

• Começar por um modelo antes de definir âmbito e provas.
• Documentar o modelo, não o sistema completo.
• Tratar documentos do fornecedor como prova da própria configuração.
• Nunca reavaliar uma conclusão de baixo risco.
• Manter um processo de auditoria desligado dos lançamentos e alterações.

Exemplo: seleção assistida de candidatos

Numa função que ordena candidaturas, a equipa deve definir finalidade, prestador, limite e análise do anexo III. Se fornecer um sistema de risco elevado, o processo cobre versões em produção, dados, fluxo do cliente, avaliações por grupos, métricas, limitações, revisão humana, registos, segurança e monitorização. Uma mudança de modelo ou limiar deve reabrir os registos relacionados.

FAQ

Quando se aplica às equipas SaaS?

O artigo 11 aplica-se a prestadores de sistemas de risco elevado. Confirme limite, função e classificação antes de considerar o processo completo legalmente obrigatório.

O que documentar primeiro?

Finalidade, limite, função, classificação, versão de produção, arquitetura, riscos, avaliações, controlos, instruções e proprietários.

Podem reutilizar-se registos de engenharia?

Sim. Ligue fontes atuais e controladas e mostre no índice qual requisito e versão cobrem.

Fontes

• Regulamento (UE) 2024/1689, artigos 6 e 11 e anexos I, III e IV.
• Regulamento (UE) 2026/1744 sobre documentação e datas de aplicação.
• Comissão Europeia, “AI Act”, calendário atual de execução.