A dignidade dos dados começa antes do modelo.
O formulário na secretária errada
A discussão sobre a dignidade dos dados começa muitas vezes tarde demais. Começa depois de o modelo ter sido treinado, depois de o conjunto de dados ter sido recolhido, fundido, filtrado, deduplicado, normalizado, incorporado, avaliado, empacotado, implementado e defendido por alguém do departamento jurídico que não dormiu o suficiente. Nesse ponto, a conversa soa moral, o que é útil, e também ligeiramente teatral, o que é menos útil. As pessoas perguntam se o modelo respeitou as pessoas por detrás dos dados. A resposta honesta é, normalmente, que o modelo nunca teve oportunidade. A decisão foi tomada meses antes, num formulário que ninguém queria assumir.
Uma vez, vi uma equipa de investigação na área da saúde descobrir isto numa reunião que supostamente era sobre a qualidade do modelo. O modelo não era o problema. O problema era uma pequena coluna de entrada marcada como reutilização permitida. Tinha três valores possíveis: sim, não e em branco. Em branco significava que ninguém sabia. No pipeline de exportação, em branco tinha sido tratado como sim, porque, caso contrário, a experiência teria sido inconveniente. Isto não era maldade. Era pior para efeitos de governação: era um padrão. O campo mais silencioso da folha de cálculo tinha mais autoridade do que o comité de ética.
A equipa podia voltar a treinar, pedir desculpa, documentar e melhorar. Mas a questão da dignidade não começava na rede neuronal. Começava quando um registo chegava sem um propósito claro, sem um responsável, sem uma regra de retenção, sem uma forma de preservar a retirada e sem um contrato técnico que recusasse a incerteza. O modelo apenas tornou mais rápida a falta de respeito anterior. As máquinas são muitas vezes acusadas de serem frias, mas muitas das escolhas mais frias são feitas por humanos calorosos que clicam em importar.
A dignidade dos dados começa antes do modelo, porque os dados se tornam políticos no momento em que são recolhidos. Um registo não é apenas uma linha. É um fragmento de uma pessoa, de uma empresa, de uma comunidade, de um local de trabalho, de um percurso de doente, de um serviço público, de um ambiente de sensores ou de um julgamento profissional. Tratar esse fragmento com dignidade não é envolvê-lo em linguagem sentimental. É manter verdade suficiente à sua volta para que sistemas posteriores não possam fingir que ele apareceu do nada.
O consentimento não é um perfume
Muitas organizações tratam o consentimento como um aroma agradável adicionado a um processo depois do trabalho árduo estar concluído. Um parágrafo é colocado numa política. Uma caixa de verificação é adicionada a um portal. Uma linha no registo diz interesse legítimo. Todos relaxam, pelo menos até alguém perguntar o que o modelo foi realmente autorizado a aprender. Então a sala descobre que a redação legal e a permissão operacional estão relacionadas da mesma forma que um menu está relacionado com o jantar. Uma é uma promessa. A outra tem de ser cozinhada.
O consentimento operacional tem estrutura. Indica qual finalidade é permitida, quais intervenientes podem processar o registo, quais transformações são permitidas, quais derivados herdam o limite, durante quanto tempo o registo pode existir, como é tratada a retirada e que provas demonstram a escolha mais tarde. Se essas peças não forem suficientemente legíveis por máquina para afetar o pipeline, não são consentimento num sistema de IA. São documentação com tema de consentimento. A documentação tem o seu lugar, mas não deve ser solicitada a impedir uma tarefa em lote por força moral.
Isto torna-se especialmente importante quando os dados passam do seu primeiro propósito para a formação, recuperação, avaliação, monitorização ou análise de produto. Uma reclamação submetida a um município pode ser útil para melhorar um classificador. Uma nota clínica pode ser útil para extrair sintomas. Uma transcrição de apoio ao cliente pode ser útil para um chatbot. A utilidade não cria dignidade. Cria tentação. A questão da dignidade é saber se o novo propósito foi declarado, se as pessoas e instituições envolvidas podiam razoavelmente esperá-lo e se o sistema consegue impor a resposta quando os dados se tornam convenientes.
O consentimento também envelhece. Um registo recolhido há cinco anos pode ter sido obtido com pressupostos que já não correspondem à prática atual. Uma pessoa pode ter retirado o consentimento. Um contrato pode ter expirado. Um acordo de partilha de dados pode ter permitido análise, mas não formação de modelos. Um campo pode ter sido anonimizado suficientemente bem para um relatório, mas não suficientemente bem para um índice de incorporação que possa ser consultado o dia todo por funcionários criativos. A permissão antiga não deve ser tratada como um frasco de compota no fundo do armário. A data é importante.
O contexto é uma propriedade técnica
Existe o hábito preguiçoso de separar os dados do contexto, como se o contexto fosse suave e os dados fossem duros. Em sistemas reais, o oposto é frequentemente verdadeiro. O valor dos dados pode ser um número, um código, um nome, um carimbo temporal ou um campo de texto. O seu significado depende do método de recolha, da unidade, do âmbito, da incerteza, da autoridade da fonte, das regras de exclusão, do idioma, da ausência de valores e da situação em que foi registado. Se se retirar tudo isso, os dados não se tornam neutros. Tornam-se excessivamente confiantes.
Uma leitura de sensor de uma ponte não é apenas vibração. É vibração de um dispositivo específico, calibrado numa data específica, montado num local específico, medido sob condições meteorológicas específicas, amostrado a uma frequência específica e interpretado em relação a um histórico de manutenção. Um registo de pagamento não é apenas um montante. Está inserido num contrato, num processo de liquidação, num modelo de fraude, numa convenção monetária e num hábito humano de colocar vírgulas onde os decimais queriam viver. O modelo pode ver apenas tokens ou vetores, mas a instituição continua responsável pelos substantivos em falta.
A dignidade dos dados exige, portanto, a preservação do contexto como requisito de engenharia. As descrições de esquemas devem ter versões. Os sistemas de origem devem ser nomeados. As transformações devem ser registadas. Os valores em falta devem ser distinguidos de zeros, recusas, desconhecidos e estados não aplicáveis. Os rótulos devem indicar quem os atribuiu, segundo que diretriz e com que discordância. Os exemplos de avaliação devem indicar por que foram selecionados. Um conjunto de dados sem contexto não é matéria-prima. É um boato em forma de tabela.
Isto não é um apelo a metadados intermináveis. Metadados intermináveis são a forma como boas ideias vão passar a reforma num catálogo que ninguém abre. A questão são metadados seletivos e operacionais: o contexto necessário para decidir se o registo pode ser utilizado, se ainda significa o que o sistema pensa que significa e se uma pessoa posterior pode contestar o resultado. A dignidade não exige todos os factos sobre o registo. Exige os factos que impedem o registo de se tornar um estranho para si próprio.
A dívida de dignidade
A dívida técnica é familiar porque os engenheiros conseguem vê-la nas compilações, nos incidentes, nas mudanças lentas e nos pequenos impropérios escritos nas mensagens de commit. A dívida de dignidade dos dados é mais silenciosa. Acumula-se quando a origem é pouco clara, a permissão é ambígua, o contexto é descartado, a retenção é ignorada, os rótulos não são documentados, o acesso é demasiado amplo, ou os dados derivados são tratados como inofensivos porque já não se parecem com a fonte. A dívida pode não fazer falhar um teste. Espera por uma queixa, uma auditoria, uma disputa, um resultado prejudicial ou um jornalista com paciência.
O perigo da dívida de dignidade é que ela se agrava através da utilidade. Um conjunto de dados que é conveniente é copiado. Um conjunto de dados copiado torna-se uma loja de funcionalidades. A loja de funcionalidades alimenta um modelo. O resultado do modelo torna-se um registo. O registo torna-se feedback de treino. Cada passo parece prático. Cada passo também torna mais difícil responder à pergunta original: o que nos era permitido fazer com estes dados e o que devíamos às pessoas por detrás deles. Quando a pergunta chega à liderança, a resposta já foi distribuída por oito sistemas e por uma pessoa que entretanto mudou de departamento.
As equipas sérias tratam a dívida de dignidade como qualquer outro risco operacional. Registam-na, atribuem-lhe um custo, designam responsáveis e decidem quais os usos que ficam bloqueados até a dívida ser paga. Se um conjunto de dados não conseguir provar a sua origem, não deve entrar em treino de alto impacto. Se a retirada não puder ser propagada, a utilização deve ser limitada. Se os artefactos derivados não puderem ser rastreados, o modelo não deve sustentar decisões com consequências. Se os rótulos foram produzidos com orientações deficientes, a avaliação não deve ser usada como certificado de imparcialidade. Isto é aborrecido da melhor forma. É com aborrecimento que os adultos mantêm as pontes de pé.
Há a tentação de resolver a dívida de dignidade com uma grande plataforma. As plataformas podem ajudar, mas o primeiro passo é geralmente mais pequeno e mais disciplinado: recusar incógnitas na receção, separar a finalidade do armazenamento, registar a linhagem nas fronteiras de transformação, manter os direitos ligados aos derivados e tornar a eliminação testável. Um sistema que não consegue eliminar com confiança não pode afirmar honestamente que respeitou a retirada. Só pode afirmar que espera que os dados se tenham tornado tímidos.
Os dados derivados continuam a ser dados
A IA torna a dignidade dos dados mais difícil porque cria derivados que parecem inofensivos. Um documento transforma-se num fragmento. Um fragmento transforma-se numa incorporação. Uma conversa de apoio transforma-se num resumo. Uma nota clínica transforma-se num rótulo. Uma consulta de pesquisa transforma-se num evento de análise. Uma resposta do modelo transforma-se num novo registo. Uma correção humana transforma-se em dados de reforço. Cada artefacto pode perder a forma do original mantendo significado suficiente para importar. A máscara muda. A obrigação pode não mudar.
As incorporações são um exemplo útil porque são fáceis de interpretar mal. Não são texto legível, por isso as pessoas tratam-nas como se a dignidade tivesse evaporado. Mas uma incorporação pode ainda revelar semelhança, pertença, agrupamento sensível ou contexto de negócio. Pode ajudar a reconstruir ou inferir factos. Pode carregar as consequências de rótulos enviesados. Pode persistir depois de a fonte ter sido eliminada. Chamar-lhe vetor não a torna socialmente irrelevante. Muitas coisas na vida parecem inofensivas quando escritas em decimais. Saldos bancários, por exemplo.
Os dados derivados precisam de regras de herança. Que obrigações seguem da fonte para o fragmento, o vetor, a cache, o resumo, a caraterística, o registo de instruções, a amostra de avaliação e a saída do modelo. Que derivados devem ser eliminados quando a fonte é eliminada. Quais podem ser retidos por serem suficientemente agregados ou legalmente independentes. Quais precisam de consentimento separado. Quais são registos por direito próprio. Sem herança, cada sistema a jusante pode improvisar a dignidade. A improvisação é encantadora no jazz. Na governação de dados, produz frequentemente atas de reuniões.
Estas regras de herança devem ser concebidas antes da recolha, não depois do primeiro lançamento do modelo. A questão não é congelar a inovação. É dar um piso à inovação. Os engenheiros podem construir mais depressa quando sabem quais os derivados permitidos, que limites exigem revisão e que metadados têm de acompanhar. Os investigadores podem explorar sem transformar cada experiência numa sessão espírita jurídica. Os utilizadores e os titulares dos dados obtêm o benefício mais importante: a instituição pode explicar o que aconteceu aos seus dados sem consultar o folclore.
O modelo é uma testemunha tardia
Quando um sistema de IA se comporta mal, a investigação olha muitas vezes primeiro para o modelo. Isso é compreensível. O modelo é visível, caro e confiantemente errado de formas que dão bons ecrãs de captura. Mas o modelo é frequentemente uma testemunha tardia de decisões anteriores. Reflete escolhas de recolha, escolhas de rotulagem, escolhas de exclusão, escolhas de limpeza, escolhas de retenção e escolhas de avaliação. Pedir apenas ao modelo que se torne digno é como pedir à última pessoa numa corrida de estafetas que melhore o testemunho.
Os model cards, as auditorias, as avaliações, os exercícios de red team e as ferramentas de explicabilidade são todos importantes. Fazem parte da história da dignidade, sobretudo quando os sistemas afetam pessoas. Mas não conseguem recuperar a permissão que nunca foi captada, o contexto que foi descartado ou o histórico que não foi registado. Podem revelar a lacuna. Não conseguem tornar a lacuna moralmente aceitável. É por isso que os controlos precoces não são burocracia. São as condições que tornam a responsabilização posterior mais do que teatro.
O mesmo se aplica à equidade. Uma revisão de equidade após o treino pode detetar taxas de erro desiguais, grupos em falta, variáveis proxy ou limiares prejudiciais. Nem sempre consegue determinar se o conjunto de dados excluiu pessoas na recolha, se os rótulos captaram preconceitos institucionais, se um campo significava o mesmo em todos os locais ou se uma regra de consentimento filtrou a amostra de forma a alterar a população. A equidade sem dignidade dos dados é trabalhar com um espelho que pode ter sido curvado na fabricação.
Há também uma vantagem prática em começar cedo: quanto mais cedo uma regra de dignidade entra no pipeline, mais barato é aplicá-la. Um registo recusado na admissão custa pouco. Um conjunto de dados em quarentena antes do treino custa mais. Um modelo retirado de produção custa muito mais. Uma perda pública de confiança custa o número que as finanças registam depois de todos deixarem de fingir que é apenas uma questão de comunicação. A dignidade é muitas vezes descrita como um custo ético. Em sistemas sérios, é mais barata do que a limpeza.
A administração é um trabalho real
A dignidade dos dados precisa de administradores, não de mascotes. Um administrador não é a pessoa cujo nome aparece num diapositivo para que o diagrama de governação tenha um rosto humano. Um administrador tem autoridade para responder se um conjunto de dados pode ser utilizado, para bloquear uma finalidade arriscada, para exigir metadados, para aprovar a retenção, para tratar da retirada e para explicar uma decisão a auditores e às pessoas afetadas. Sem autoridade, a administração torna-se decorativa. A governação decorativa é fácil de identificar porque contém muitos comités e muito poucos verbos.
O administrador também precisa de alavancagem técnica. Precisa de painéis que mostrem o histórico e a utilização, não apenas o volume de armazenamento. Precisa de alertas quando um conjunto de dados é reutilizado fora da sua finalidade. Precisa de contratos com as equipas de engenharia sobre os metadados exigidos. Precisa de um caminho de eliminação que tenha sido testado. Precisa de uma forma de assinalar a incerteza sem ver o pipeline transformá-la silenciosamente em sim. Precisa de orçamento suficiente para corrigir a dívida de dignidade antes de esta se tornar manchete. Isto é trabalho, não um rótulo de virtude.
Uma boa administração é colaborativa. O jurídico compreende a autoridade. A segurança compreende o acesso. Os engenheiros de dados compreendem o movimento. Os especialistas de domínio compreendem o significado. As equipas de produto compreendem a utilização prevista. Os investigadores compreendem a incerteza. As operações compreendem o que acontece às três da manhã. A dignidade dos dados falha quando uma destas perspetivas é declarada dona de todo o problema e todos os outros regressam aos seus painéis. O registo atravessa funções; a responsabilidade também tem de atravessar.
Há aqui uma modéstia humana. A dignidade dos dados não exige que uma organização saiba tudo. Exige que a organização saiba o que sabe, o que não sabe, quem pode decidir e onde os limites são aplicados. Isso é menos glamoroso do que uma apresentação estratégica sobre IA responsável. Também tem mais probabilidade de sobreviver ao contacto com um trabalho de importação real.
Como é a dignidade na infraestrutura
A infraestrutura para a dignidade dos dados não é mística. É feita de registos de origem, etiquetas de finalidade, estados de consentimento, contratos de dados, eventos de linhagem, âmbitos de acesso, tarefas de retenção, provas de eliminação, diretrizes de rotulagem, versões de conjuntos de dados, registos de avaliação e filas de revisão. Se esta lista parece simples, ainda bem. Os sistemas éticos mais fiáveis parecem-se muitas vezes com canalização. Notam-se sobretudo quando alguém se esqueceu de os instalar.
Na recolha, um registo deve chegar com uma origem declarada, uma finalidade, uma base legal ou um estado de permissão, uma classe de sensibilidade e um steward. Na transformação, o sistema deve emitir eventos de linhagem e preservar os limites relevantes. Na utilização, o runtime deve verificar se a finalidade corresponde. No armazenamento, a retenção e a eliminação devem ser executáveis, não aspiracionais. Na avaliação, os exemplos devem incluir a origem e a lógica de seleção. Na revisão, as pessoas afetadas e os operadores internos devem ter uma via para contestar utilizações indevidas. Nada disto exige fingir que todos os dados são sagrados. Exige admitir que os dados têm uma vida.
A decisão de design mais importante é tornar o desconhecido um estado de primeira classe. Desconhecido não é sim. Desconhecido não é inofensivo. Desconhecido é um sinal para perguntar, colocar em quarentena, limitar ou recusar. Muitas falhas de dignidade acontecem porque os sistemas são alérgicos à incerteza. Preferem um booleano arrumado mesmo quando o mundo real não forneceu um. É assim que células vazias se tornam permissões. Um sistema digno deixa a incerteza abrandar as coisas. A máquina aguenta. Não foi convidada para almoçar por causa dos sentimentos dela.
Não existe uma arquitetura de dignidade perfeita. Existem padrões melhores e padrões piores. Padrões melhores mantêm o contexto próximo, propagam limites, registam movimentos, exigem utilização secundária explícita e tornam possível a reversão. Padrões piores achatam a finalidade, copiam livremente, confiam em toda a gente, eliminam apenas na política e descobrem obrigações quando o calendário de auditoria o exige. A escolha não é entre inovação e dignidade. A escolha é entre sistemas que se lembram do que devem e sistemas que esperam que ninguém pergunte.
A lição
A dignidade dos dados é muitas vezes discutida como um grande princípio, mas torna-se real em pequenas decisões técnicas tomadas antes de o modelo aparecer. O que deve ser conhecido na recolha. Que desconhecidos param o fluxo. Que direitos acompanham os derivados. Que contextos são preservados. Que finalidades são permitidas. Que stewards podem dizer não. Que eliminações podem ser provadas. Essas escolhas determinam se um modelo posterior pode ser responsabilizável ou apenas eloquente.
O caminho respeitoso não é contra os dados nem contra a IA. É a favor da memória. Insiste em que os registos contenham informação suficiente sobre origem, permissão, contexto e obrigação para se manterem ligados às pessoas e instituições que os produziram. Um modelo treinado com esses dados tem mais hipóteses de ser útil sem se tornar extrativo por acidente. Um modelo treinado sem esses alicerces pode continuar a impressionar. Tal como um edifício sem fundações impressiona durante um período curto e emocionante.
Comece antes do modelo. Comece pelo formulário, pelo contrato, pelo esquema, pelo estado de consentimento, pelas diretrizes de rotulagem, pela regra de retenção, pela política de derivados e pelo responsável com autoridade efetiva. É aí que a dignidade entra no sistema. Tudo o que vem depois é preservação ou controlo de danos.