Governança de dados: dos pilares à prova

O essencial

• A governança de dados é o modelo operacional que define quem decide, segundo que regras, através de que processos e sobre que tecnologia. Neste ponto todos os guias disponíveis convergem.
• O que mudou foi o resultado exigível. Assim que entram sistemas de IA no perímetro, a governança de dados tem de produzir provas documentais e já não apenas decisões.
• O artigo 10.º do Regulamento da IA impõe oito requisitos expressos aos conjuntos de dados de treino, validação e teste.
• O DAMA-DMBOK, o DCAM, o DGI e o COBIT são anteriores à regulação dos dados de treino. Continuam a servir de esqueleto, mas nenhum indica o que é preciso arquivar.
• Uma única verificação é decisiva: consegue a sua organização apresentar, para qualquer modelo em produção, uma ficha do conjunto de dados, um registo de rastreabilidade e um relatório de exame de enviesamentos?

O que é realmente a governança de dados

A governança de dados é o modelo operacional que determina o modo como uma organização recolhe, conserva, protege e utiliza a sua informação. Assenta em quatro componentes recorrentes: políticas e normas que fixam as regras, funções e responsabilidades que sustentam a prestação de contas, processos que convertem as regras em rotina e tecnologia que guarda registo do que sucedeu.

Este consenso é correcto mas incompleto, porque descreve uma estrutura de decisão e quase nada diz sobre o que essa estrutura deve produzir. Durante vinte anos a omissão teve pouco alcance, uma vez que o destinatário do modelo era a própria organização, sob a forma de um painel de qualidade, de um comité de acompanhamento e de um catálogo destinado aos analistas.

Essa fase terminou. Quando os dados alimentam um sistema de IA, o destinatário da sua governança de dados pode ser um organismo notificado, uma autoridade de fiscalização do mercado ou um cliente empresarial que conduz a sua diligência sobre fornecedores. Estes leitores não aceitam um modelo operacional como resposta: pedem documentos. Um dispositivo incapaz de os fornecer configura uma narrativa de conformidade, o que é coisa distinta. O tema inscreve-se na questão mais ampla da governança de IA enquanto disciplina operacional.

Governança de dados e gestão de dados

A distinção é mais simples do que a maioria dos guias sugere. A gestão de dados pertence à execução: fluxos, armazenamento, regras de qualidade, dados mestre, integração. A governança de dados constitui a camada de autoridade acima dela: quem tem legitimidade para decidir, qual é a norma aplicável e de que modo a organização demonstra que a norma foi cumprida.

Uma fórmula útil para fixar a diferença consiste em dizer que a gestão responde ao como, ao passo que a governança responde a quem o determinou e onde está a prova. Quem apenas produz documentação de processo descreveu gestão e chamou-lhe governança.

Os quatro modelos de referência e a sua finalidade original

Todas as publicações sobre a matéria citam a mesma lista. Não são modelos concorrentes: foram concebidos para tarefas diferentes.

Modelo	Origem	Finalidade	Utilização recomendada
DAMA-DMBOK	DAMA International	Definir a prática de gestão de dados em onze áreas de conhecimento	Como referência de prática e léxico
DCAM	EDM Council	Medir a maturidade das capacidades face a um padrão	Como instrumento de avaliação
Quadro DGI	Data Governance Institute	Desenhar direitos de decisão e cadeias de responsabilidade	Como camada organizativa
COBIT	ISACA	Governar o sistema de informação e o risco tecnológico	Como léxico de auditoria e controlo

A combinação mais difundida em 2026 consiste em emparelhá-los: o DAMA-DMBOK define a boa prática e o DCAM mede a distância que dela o separa. A versão 3.0 do DMBOK, em preparação, alarga o seu âmbito à gestão de dados para aprendizagem automática, o que assinala com clareza a direcção do sector.

Porque nenhum foi escrito para sistemas de IA

Os quatro foram concebidos para governar o dado enquanto activo da organização. Nenhum foi concebido para o governar enquanto componente de um produto regulado. A deslocação nada tem de cosmético.

Na lógica do activo, a pergunta dirigida a um conjunto de dados incide sobre a exactidão, a localização, a segurança e a titularidade. Na lógica do produto a pergunta muda de natureza: aquele conjunto de treino concreto era pertinente e suficientemente representativo face à finalidade para a qual o modelo foi colocado no mercado, e consegue demonstrá-lo? Uma governança de dados construída sobre a lógica do activo responderá sem dificuldade à primeira pergunta e de modo algum à segunda.

O que muda quando a IA entra no património informacional

Três alterações ocorrem em simultâneo.

Em primeiro lugar, os dados de treino, validação e teste passam a ser um objecto regulado com critérios de qualidade fixados por lei. Deixam de ser meras entradas analíticas para se tornarem o fundamento probatório de uma afirmação de conformidade sobre um produto.

Em segundo lugar, cada conjunto passa a ter um responsável que tem de responder pela representatividade e não apenas pela exactidão. São propriedades distintas, pois um conjunto pode ser rigorosamente exacto a respeito da população errada.

Em terceiro lugar, o inventário em que assenta a sua governança de dados deixa de ser fiável. O modelo pressupõe que se sabe que sistemas consomem que dados, e as ferramentas não declaradas quebram esse pressuposto em silêncio: é por isso que a shadow AI constitui antes de mais um problema de dados e só depois um problema de segurança. Se uma equipa despeja fichas de clientes num assistente não autorizado, nenhum registo anota esse fluxo e nenhuma política chegou a aplicar-se.

Artigo 10.º do Regulamento da IA: as obrigações a cumprir

O artigo 10.º é a disposição que transforma a governança de dados de boa prática em obrigação jurídica para os sistemas de IA de risco elevado. Nos termos do artigo 10.º, n.º 1, os sistemas de risco elevado desenvolvidos mediante técnicas de treino devem assentar em conjuntos de dados de treino, validação e teste que cumpram os critérios de qualidade enunciados no preceito.

O n.º 2 exige que esses conjuntos sejam submetidos a práticas de governação e gestão adequadas à finalidade prevista e enumera oito aspectos a cobrir. Lidos como caderno de encargos, obrigam a documentar:

1. As opções de concepção, formalizadas em vez de pressupostas.
2. Os processos de recolha e a origem dos dados e, tratando-se de dados pessoais, a finalidade original da recolha.
3. As operações de preparação: anotação, rotulagem, limpeza, actualização, enriquecimento e agregação.
4. Os pressupostos sobre aquilo que os dados devem medir e representar.
5. A avaliação da disponibilidade, quantidade e adequação dos conjuntos necessários.
6. O exame de enviesamentos susceptíveis de afectar a saúde, a segurança ou os direitos fundamentais, incluindo efeitos discriminatórios.
7. As medidas adequadas de detecção, prevenção e atenuação desses enviesamentos.
8. A identificação de lacunas ou deficiências que obstem à conformidade e o respectivo suprimento.

O n.º 3 fixa o patamar de qualidade: os conjuntos devem ser pertinentes, suficientemente representativos e, na medida do possível, isentos de erros e completos face à finalidade prevista, com propriedades estatísticas adequadas às populações visadas. O n.º 4 obriga a atender às características próprias do contexto geográfico, comportamental ou funcional de utilização. Um modelo de recrutamento validado num mercado de trabalho nacional não transporta essa validação ao atravessar uma fronteira.

O n.º 5 contém uma permissão estreita e amiúde mal lida: o prestador pode, a título excepcional, tratar categorias especiais de dados pessoais quando tal seja estritamente necessário à detecção e correcção de enviesamentos, sob reserva de garantias adequadas e apenas quando outros dados não permitam cumprir essa finalidade. Trata-se de uma derrogação delimitada e não de uma licença para recolher atributos sensíveis por rotina, em linha com o princípio da minimização que a CNPD tem reiterado. O n.º 6 encerra o quadro para os sistemas que não aprendem a partir de dados, relativamente aos quais apenas relevam os conjuntos de teste. A arquitectura global destas obrigações é tratada no nosso guia operacional do Regulamento da IA.

O anexo IV e o dever de ficha descritiva

O artigo 10.º diz como devem ser os dados. O anexo IV diz o que tem de constar por escrito. O ponto 2, alínea d), do anexo IV exige que a documentação técnica inclua, quando pertinente, fichas que descrevam as metodologias e técnicas de treino e os conjuntos de dados utilizados: descrição geral, proveniência, âmbito e principais características, forma de obtenção e selecção dos dados, procedimentos de rotulagem e metodologias de limpeza. O ponto 2, alínea g), estende a mesma disciplina aos dados de validação e teste e às métricas de exactidão e robustez.

É esta a frase que altera a natureza do trabalho exigido. A rastreabilidade deixa de ser uma comodidade para os analistas e passa a ser um entregável documental em formato prescrito. A referência académica subjacente é o trabalho de Gebru e colegas, Datasheets for Datasets, que propunha exactamente esta forma: motivação, composição, processo de recolha, pré-processamento, utilizações, distribuição e manutenção. O nosso guia sobre documentação de sistemas de IA cobre o restante processo.

O que deve o responsável pela implantação nos termos do artigo 26.º, n.º 4

A literatura sobre o tema dirige-se quase sempre ao titular dos dados. O Regulamento vincula também a organização que se limita a adquirir o sistema. Nos termos do artigo 26.º, n.º 4, o responsável pela implantação que exerça controlo sobre os dados de entrada deve assegurar que esses dados são pertinentes e suficientemente representativos face à finalidade prevista do sistema de risco elevado. O n.º 6 impõe a conservação dos registos gerados automaticamente durante pelo menos seis meses.

Assim, se explorar sob licença um modelo de scoring alimentando-o com os seus próprios processos, a sua governança de dados suporta uma obrigação legal sobre esses processos. Adquirir o modelo não externaliza o dever relativo ao dado.

Alinhar os pilares com a ISO 42001 e o NIST AI RMF

O movimento útil não consiste em substituir o dispositivo existente, mas em redefinir aquilo que cada pilar deve entregar. O quadro seguinte apresenta a versão condensada.

Pilar clássico	ISO/IEC 42001 anexo A	NIST AI RMF	Documento a produzir
Políticas e normas	A.7.2 dados para o desenvolvimento, A.7.4 qualidade dos dados	MAP 2.3	Critérios de qualidade escritos por finalidade
Funções e responsabilidades	A.7.3 aquisição de dados	MAP 4.1, MAP 4.2	Responsável nomeado e revisão de dados de terceiros
Processos	A.7.6 preparação de dados	MAP 2.3	Protocolo de rotulagem e relatório de enviesamentos
Tecnologia	A.7.5 proveniência dos dados	MEASURE 2.2	Rastreabilidade da origem à entrada do modelo

A norma ISO/IEC 42001 reúne os seus requisitos sobre dados no controlo A.7 do anexo A, dedicado aos dados para sistemas de IA e desdobrado em A.7.2 dados para o desenvolvimento e melhoria, A.7.3 aquisição de dados, A.7.4 qualidade dos dados, A.7.5 proveniência dos dados e A.7.6 preparação de dados. Quem pretenda certificar-se trabalha exactamente contra esta lista, que se articula com o artigo 10.º sem o duplicar. Explicámos noutro lugar por que razão a ISO 42001 só por si não produz conformidade com o Regulamento.

O NIST AI RMF fornece, em contrapartida, um léxico de risco e não um alvo de certificação. A subcategoria MAP 2.3 trata da integridade científica e das actividades de teste, avaliação, verificação e validação, incluindo expressamente o desenho experimental e a recolha e selecção de dados. As subcategorias MAP 4.1 e 4.2 respeitam ao risco decorrente de dados de terceiros e ao dever de rever o material obtido no exterior sob a perspectiva do enviesamento, da privacidade e da segurança antes de qualquer autorização. Este último ponto pesa mais a cada ano, dado que a maioria das organizações treina já sobre dados que não recolheu. O cruzamento completo entre referências consta da nossa comparação entre NIST AI RMF, ISO 42001, Regulamento da IA e princípios da OCDE.

A lista de documentos a produzir

Esta é a tradução operacional. Uma governança de dados que abranja sistemas de IA tem de conseguir apresentar, a pedido e por sistema, os nove documentos seguintes.

1. Um registo de conjuntos de dados ligado ao inventário de sistemas de IA, para que qualquer modelo possa ser reconduzido aos dados que consumiu.
2. Uma ficha descritiva por cada conjunto de treino, validação e teste, no formato do anexo IV.
3. Um registo de rastreabilidade desde o sistema de origem até à entrada do modelo, incluindo as transformações.
4. Um relatório de exame de enviesamentos que indique as características protegidas examinadas e o método adoptado.
5. Um registo das decisões de atenuação, incluindo as decisões de aceitar enviesamento residual e quem as tomou.
6. Um registo de lacunas e deficiências com responsáveis e prazos, que dá corpo à alínea h) do n.º 2.
7. Um protocolo de anotação, com medida de concordância entre anotadores sempre que as etiquetas envolvam juízo.
8. Um registo de conservação e base jurídica, articulado com a avaliação de impacto sobre a protecção de dados quando estejam em causa dados pessoais.
9. Uma aprovação nominativa por versão do conjunto, pois um documento sem assinatura é uma afirmação e não um controlo.

Os pontos quatro e cinco são aqueles em que os programas se revelam mais frágeis e os primeiros que um auditor reclama. O nosso guia sobre viés da IA detalha os métodos de exame.

O registo de elementos de dados críticos, alargado à IA

As entidades reguladas mantêm já um registo de elementos de dados críticos. Não precisa de um segundo registo, mas de uma chave estrangeira.

Acrescente uma relação entre cada elemento crítico e os sistemas de IA que o consomem e o registo deixa de ser um artefacto de qualidade para passar a responder a questões de conformidade: que modelos ficam afectados se aquele elemento se degradar, que conjuntos herdaram os seus defeitos conhecidos e que responsáveis de modelo devem ser avisados quando a sua definição muda. Esta única junção converte trabalho já realizado em prova regulatória a custo marginal e é a alteração de maior rendimento sobre um dispositivo existente.

Uma implementação em noventa dias

Uma sequência realista para uma organização que já dispõe de governança de dados e tem de a estender à IA.

1. Semanas 1 e 2, âmbito e facto jurídico gerador. Determine que sistemas são de risco elevado, quais são modelos de fins gerais que apenas implanta e quais ficam fora do âmbito. As obrigações divergem acentuadamente e os erros de qualificação pagam-se mais tarde.
2. Semanas 3 e 4, inventário. Liste os sistemas de IA e os conjuntos que cada um consome. Conte com uma lista incompleta na primeira passagem e programe um levantamento das ferramentas não declaradas.
3. Semana 5, classificação. Qualifique cada conjunto por sensibilidade, base jurídica, origem (interna, de terceiros, sintética, extraída da web) e natureza de treino, validação ou teste.
4. Semana 6, responsabilidades. Atribua um responsável nomeado por conjunto. Uma pessoa, não uma equipa: uma responsabilidade partilhada é uma responsabilidade ausente.
5. Semanas 7 a 9, documentação. Redija as fichas no formato do anexo IV, começando pelo sistema mais exposto, pois é aí que o formato é verdadeiramente posto à prova.
6. Semanas 10 e 11, teste de representatividade. Compare as propriedades estatísticas dos conjuntos com a população destinatária e o contexto de implantação. Registe os desvios encontrados em vez de os corrigir em silêncio.
7. Semana 12, aprovação e cadência. Obtenha a aprovação nominativa e fixe o facto que desencadeia a revisão, ancorando-o aos retreinos e não ao calendário.

É justamente na cadência que mais programas falham. Se o seu quadro de governança da IA revir os dados uma vez por ano enquanto os modelos são retreinados todas as semanas, a documentação descreve um sistema que já não existe.

As cinco falhas recorrentes

A maturidade de fachada. O programa autoavalia-se face a um modelo de capacidades e comunica progressos sem qualquer prova por trás da pontuação. A declaração da administração não constitui evidência.

A ferramenta antes da regra. Adquire-se um catálogo antes de escrita a política que ele deveria aplicar. A ferramenta acaba por codificar as convenções de quem a configurou.

A ausência de responsável pelos dados de treino. Os sistemas de origem têm titular. O conjunto derivado, composto a partir de quatro deles, filtrado, novamente rotulado e congelado para uma versão do modelo, em regra não tem nenhum.

Registos nunca ligados. O catálogo de dados e o inventário de sistemas de IA residem em ferramentas distintas mantidas por equipas distintas, pelo que nenhuma consulta consegue apurar que modelo usou que dados. É a causa mais frequente de uma auditoria de IA que nada encontra de aproveitável.

Âmbito parado nos dados pessoais. Os programas de protecção de dados cobrem bem o dado pessoal. O artigo 10.º abrange a totalidade dos dados de treino, incluindo os operacionais, os de sensores e os sintéticos sem qualquer componente pessoal.

Perguntas frequentes

Quais são os quatro pilares da governança de dados?

Políticas e normas, funções e responsabilidades, processos e tecnologia. Alguns fornecedores desdobram-nos em cinco, sete ou dez componentes, mas os acrescentos são subdivisões e não categorias novas: qualidade, gestão de metadados e rastreabilidade cabem nos processos e na tecnologia. Quando estão em causa sistemas de IA, importa tratar como obrigatório um quinto aspecto raramente enumerado: as provas produzidas, isto é, as fichas, os registos de rastreabilidade e os relatórios de enviesamento que uma autoridade possa efectivamente ler.

Quais são os princípios fundamentais?

Prestação de contas com responsável nomeado por conjunto, transparência sobre origem e transformações, qualidade definida face a uma finalidade declarada e não em abstracto, protecção proporcionada à sensibilidade e à base jurídica, e rastreabilidade da origem ao consumo. Sob o Regulamento da IA, a qualidade e a rastreabilidade pesam mais, uma vez que o artigo 10.º, n.º 3, formula um critério referido à finalidade e não uma exigência geral.

Qual a diferença entre governança de dados e governança de IA?

A primeira governa o dado. A segunda governa os sistemas construídos sobre ele, a par dos modelos, das decisões de implantação, da supervisão humana e do tratamento de incidentes. Sobrepõem-se num único ponto, os dados de treino, e é exactamente aí que o Regulamento coloca as obrigações documentais mais pesadas. Na prática, ambas devem partilhar inventário e taxonomia de risco, mantendo responsáveis e cadências de revisão separados.

Que modelo adoptar: DAMA-DMBOK, DCAM ou DGI?

Raramente é preciso escolher em exclusivo. O DAMA-DMBOK fornece definição de prática e léxico, o DCAM a medida de maturidade e o DGI o desenho dos direitos de decisão. O padrão corrente combina o primeiro para a prática e o segundo para medir o avanço. Havendo sistemas de IA no âmbito, nenhum dos três basta isoladamente, porquanto nenhum especifica os documentos exigidos pelo anexo IV: importa sobrepor-lhes o anexo A.7 da ISO/IEC 42001.

O Regulamento da IA exige uma governança de dados?

Para os sistemas de risco elevado, na prática sim. O artigo 10.º, n.º 2, exige que os conjuntos de treino, validação e teste sejam submetidos a práticas adequadas de governação e gestão, enumerando depois oito aspectos a cobrir. O texto não designa qualquer quadro nem impõe um modelo determinado, pelo que um dispositivo existente e adaptado pode bastar. O que impõe é o resultado documental, por via do anexo IV.

A quem cabe a titularidade?

Cabe em regra ao responsável pelos dados ou a função equivalente, apoiado por um órgão de acompanhamento para as decisões transversais. Mais do que o título, contam duas condições: que a responsabilidade sobre cada conjunto seja pessoal e que quem a detém possa bloquear uma passagem a produção. Havendo sistemas de IA envolvidos, o responsável pela governança de dados e o da governança de IA têm de decidir conjuntamente sobre os dados de treino, porque nenhum deles pode aprovar sozinho.

Conclusão

As publicações disponíveis dir-lhe-ão que a governança de dados assenta em quatro pilares e que convém escolher um quadro. É verdade, e é aí que a maior parte do conselho se detém. A pergunta difícil é outra: o que entrega quando alguém externo à sua organização pergunta como foi composto o conjunto de treino de um modelo, se representava as pessoas a quem o modelo seria aplicado e quem o aprovou.

Se hoje a resposta honesta se resume a uma política e a uma captura de ecrã do catálogo, a fragilidade não está nos pilares, mas nos documentos que nunca lhes foram pedidos. Comece pelo registo de conjuntos ligado ao inventário de sistemas de IA: o resto da cadeia probatória encontrará onde se fixar.

Veja como a AI Sigil converte obrigações de governança de dados em provas oponíveis.