Registo e conservação: guia prático para equipas SaaS

No AI Act, registo e conservação são controlos de rastreabilidade, não uma ordem para recolher indefinidamente todos os dados possíveis. Para sistemas de IA de risco elevado, o artigo 12 exige capacidade técnica de registar eventos automaticamente durante o ciclo de vida. Fornecedores e responsáveis pela implantação devem conservar os logs automáticos sob o seu controlo por um período adequado à finalidade e, em regra, pelo menos seis meses, salvo disposição legal diferente.

As obrigações não se aplicam automaticamente a qualquer função de IA ou empresa SaaS. Primeiro é preciso identificar sistema, finalidade, papel e classificação, distinguindo logs do fornecedor dos controlados pelo cliente ou fornecedor a montante. O objetivo é uma cadeia de prova proporcional que permita ligar um evento relevante à versão, contexto de entrada e saída, ação humana, controlo e decisão.

Mesmo antes da aplicação das regras de risco elevado, esta disciplina apoia investigações, segurança, respostas a clientes, gestão de alterações e decisões de produto defensáveis. Não se trata de vigilância indiscriminada, mas de logging deliberado com finalidades, acesso, gatilhos e limites.

Começar pelo âmbito, não pela plataforma

Documente função, modelos e serviços terceiros, finalidade, utilizadores, pessoas afetadas, entradas, saídas, integrações, ambientes e decisões influenciadas. Registar apenas a chamada à API de um modelo de base pode omitir dados de retrieval, regras de negócio, intervenções do utilizador ou ações posteriores que formam o fluxo SaaS completo.

Determine depois o papel. Quem desenvolve ou comercializa em seu nome um sistema de risco elevado pode ser fornecedor; um cliente que usa o sistema de outro pode ser responsável pela implantação. Rebranding, modificação substancial ou alteração da finalidade podem transferir responsabilidades. A terminologia contratual não basta.

Avalie a classificação. O artigo 6 cobre sistemas ligados a produtos do anexo I e casos do anexo III, com condições e exclusões. Classificar candidatos exige análise diferente de redigir marketing interno. Registe fundamento, revisor, data, pressupostos e gatilhos. Veja também como a AI governance muda as expectativas de compliance.

O que exige o AI Act

Segundo o AI Act, o artigo 12 exige registo automático de eventos no ciclo de vida. As funções devem garantir rastreabilidade adequada, ajudar a detetar riscos ou alterações substanciais, apoiar monitorização pós-comercialização e permitir aos responsáveis pela implantação supervisionar a operação.

Os eventos dependem do sistema. Para determinados sistemas de identificação biométrica à distância do anexo III, o artigo 12 especifica informação mínima adicional. Copiar esse esquema especializado para outro produto não demonstra conformidade. Os eventos devem derivar da finalidade, riscos, limites de desempenho, supervisão humana, instruções e plano de monitorização.

O artigo 19 exige que fornecedores conservem logs automáticos sob o seu controlo por período adequado de pelo menos seis meses, salvo regra da UE ou nacional, sobretudo sobre dados pessoais, em contrário. O artigo 26 impõe mínimo paralelo aos responsáveis pela implantação. Não é autorização para conservação ilimitada. O calendário deve conciliar rastreabilidade, minimização, limitação, segurança, trabalho, regras setoriais, contratos e incidentes.

Após o Regulamento (UE) 2026/1744, os requisitos aplicam-se a 2 de dezembro de 2027 ao anexo III e a 2 de agosto de 2028 aos sistemas em produtos regulados do anexo I. O calendário da Comissão reflete estas datas.

O que registar

Um evento útil responde a uma pergunta de revisão, não apenas prova que o servidor funcionava:

1. Sistema e versão: identificador, modelo ou componente, configuração, ambiente e release.
2. Tempo e correlação: timestamp fiável, ID do pedido ou transação e ligações entre eventos.
3. Contexto operacional: função, fluxo previsto, papel do utilizador ou serviço e definições relevantes.
4. Entrada e saída: referências, hashes, resumos ou snapshots protegidos suficientes para reconstrução justificada.
5. Supervisão humana: revisão, aprovação, rejeição, override, escalamento e autoridade.
6. Controlos: verificações, limiares, filtros, acesso, erros, alternativas e resultado.
7. Alteração e monitorização: deployments, mudanças de modelo ou dados, drift, incidentes, reclamações e correções.
8. Integridade: origem, histórico de acesso, preservação e transformação ou eliminação.

Não armazene automaticamente prompts, documentos, respostas ou identidades completos. Por vezes o conteúdo é indispensável para investigar dano; noutros casos bastam identificador pseudónimo, hash, categoria, métrica ou amostra protegida. Decida campo a campo conforme finalidades e riscos documentados.

Fluxo operacional

1. Formalizar a decisão

Para cada sistema, registe âmbito, finalidade, papel, classificação, obrigações, objetivos, categorias e responsáveis. Separe logs próprios dos dependentes de cliente ou fornecedor. Indique pressupostos e gatilhos.

2. Ligar perguntas a eventos

Comece pelas perguntas: que versão produziu o resultado? A revisão humana era exigida e ocorreu? Um controlo foi ativado? A utilização respeitou a finalidade? O que mudou antes da degradação? Associe campos mínimos fiáveis e fontes.

3. Distribuir responsabilidades

Engenharia assume normalmente instrumentação; segurança, acesso, integridade, alertas e preservação; produto, fluxo e releases; data/ML, identificadores de modelos, datasets e avaliações; privacidade, licitude e minimização; compliance, mapa de requisitos. Um responsável coordena sem inventar factos dos outros.

4. Definir acesso e conservação

Separe acesso operacional de investigação. Aplique menor privilégio, autenticação, logging de acesso, cifragem e controlo de exportação. Defina início, eliminação, exceções, holds e backups, bem como responsabilidades entre fornecedor e responsável pela implantação.

5. Ligar revisões a gatilhos

Reavalie após mudança de modelo, prompt, retrieval, limiar, dados, integração, finalidade ou supervisão e após incidente, reclamação, desempenho inesperado, uso não autorizado ou aviso do fornecedor. Ligue o resultado à versão em produção.

6. Testar reconstrução e eliminação

Peça a um revisor independente que reconstrua versão, controlos, ações humanas e seguimento. Teste depois a eliminação no armazenamento principal, analytics, exportações e backups. Ambos precisam de prova.

Erros comuns

Registar tudo. Mais dados aumentam riscos de privacidade, segurança, litígio e custo sem garantir rastreabilidade.

Confundir telemetria e audit trail de IA. Disponibilidade e erros raramente identificam modelo, configuração, supervisão e prova do resultado.

Aplicar seis meses a todos os registos. O mínimo refere-se a logs automáticos de risco elevado sob controlo do operador e está sujeito a outras leis.

Ignorar fronteiras de controlo. O fornecedor não conserva logs que nunca recebe; o responsável pela implantação não deve presumir que o vendor guarda o seu contexto.

Recolher conteúdo sensível sem garantias. Prompts e saídas podem conter dados ou segredos. Minimize, separe, cifre e monitorize.

Guardar eventos não interpretáveis. Sem esquema, tempo, versão ou correlação podem ser inúteis.

Exemplo: recrutamento assistido por IA

Um fornecedor SaaS classifica candidaturas. Documenta finalidade, limites, papel e classificação. Os eventos ligam modelo e configuração de produção a cada ranking, referências de entrada, saída e contexto, limiares, avisos, revisão humana, override e ação final.

O acesso ao conteúdo limita-se a investigações autorizadas; a monitorização regular usa agregados quando possível. A decisão de conservação explica artigo 19, limites de dados, responsabilidade do cliente e períodos setoriais. Mudar modelo, limiar ou revisão aciona avaliação e mantém a ligação entre provas.

O desenho não garante sozinho conformidade, mas permite verificar operação, supervisão humana e resposta responsável a alterações e incidentes.

FAQ

Qual é a finalidade prática?

Tornar a atividade relevante rastreável ao ligar evento, versão, contexto, controlos, ações humanas e seguimento sem dados alheios.

Quando se aplicam os deveres às equipas SaaS?

Os artigos 12, 19 e 26 dizem respeito a sistemas de risco elevado e distribuem requisitos por papel e controlo. Confirme sistema, finalidade, classificação e papel.

É preciso guardar cada prompt e resposta?

Não. Rastreabilidade adequada não significa retenção indiscriminada. Escolha campos necessários e proteja-os.

Durante quanto tempo guardar os logs?

Em regra, logs automáticos de risco elevado sob controlo de fornecedores ou responsáveis pela implantação são conservados por período adequado de pelo menos seis meses. Outra lei pode exigir ou limitar outro prazo.

Por onde começar?

Inventarie sistema, papel, classificação, fontes e perguntas; depois defina esquema mínimo, responsabilidade, acesso, conservação, gatilhos e teste de reconstrução.

Fontes

• Regulamento (UE) 2024/1689, sobretudo artigos 6, 12, 19 e 26.
• Regulamento (UE) 2026/1744 e datas alteradas.
• Comissão Europeia, “AI Act”, calendário e obrigações de risco elevado.