Estratégias de governança de dados para IA

Um cliente escreve para o suporte pedindo que você apague os dados dele. Você sabe exatamente onde estão: a tabela customers no S3. Você apaga as linhas e responde que está resolvido.

Seis semanas depois, uma revisão jurídica lista onde os dados daquele cliente de fato estavam no dia do pedido. O export bruto na landing zone. A tabela curada que a exclusão tocou. Os chunks da knowledge base montados a partir dos tickets de suporte dele, ainda parados no vector store como embeddings. O log group do CloudWatch com todo prompt e resposta do assistente, incluindo três conversas em que um atendente colou o registro completo da conta dentro do prompt. Um CSV que uma cientista de dados puxou para um notebook em março. E um modelo com fine-tuning que leu tudo isso durante o treinamento.

Você apagou uma de seis cópias e disse ao cliente que estava feito.

Nada disso foi falha de segurança. Todo bucket estava criptografado, toda role tinha escopo, todo caminho de rede era privado. O que faltava era a outra metade: um conjunto de regras dizendo por quanto tempo cada uma daquelas cópias pode existir, onde ela pode morar, para que pode ser usada e quem decide. Isso é governança de dados, e o guia do exame nomeia o assunto em seis palavras: ciclo de vida, logging, residência, monitoramento, observação e retenção.

Governança é o regulamento, segurança é a fechadura

Mantenha as duas separadas, porque elas falham de formas diferentes.

Segurança pergunta: alguém não autorizado consegue chegar a este dado? E responde com IAM, criptografia, isolamento de rede e detecção de ameaças. O tópico anterior foi quase todo segurança.

Governança pergunta: sob quais regras este dado vive, não importa quem chegue até ele? Por quanto tempo podemos guardar, quais países podem processar, para quais finalidades ele está aprovado, quem assina embaixo de um uso novo e como provamos qualquer uma dessas coisas depois.

Um dataset perfeitamente protegido ainda pode ser uma falha de governança. Ninguém invadiu o log group da história acima. Ele estava autorizado, criptografado e retido para sempre porque ninguém definiu um número. A fechadura funcionou; o regulamento não existia.

Essa distinção é também o motivo de questões de governança soarem diferente de questões de segurança na prova. Enunciados de segurança dizem "impedir o acesso". Enunciados de governança dizem "não pode ser guardado por mais de", "precisa permanecer dentro de", "precisa conseguir demonstrar".

O ciclo de vida, e onde a IA multiplica ele

Todo dataset passa pelas mesmas etapas: ele é criado ou adquirido, armazenado, usado, arquivado e por fim destruído. Aplicações tradicionais mantêm esse caminho estreito. Um banco de dados, um backup, um arquivo morto.

Sistemas de IA abrem o caminho em leque. Um único ticket de suporte faz este percurso:

1. Cai como texto bruto em uma landing zone no S3.
2. É redigido e gravado em uma tabela curada em um segundo bucket.
3. É fatiado em chunks e transformado em embeddings dentro de um vector store, para recuperação.
4. Entra em um corpus de fine-tuning, e o conteúdo dele influencia os pesos do modelo.
5. Aparece em um prompt na hora da inferência, e o prompt e a resposta caem em um log.
6. É puxado para um conjunto de avaliação em uma revisão de qualidade.

Seis lugares a partir de um registro, com donos diferentes, serviços de armazenamento diferentes e tempos de vida naturais diferentes. A pergunta de governança não é "temos uma política de retenção". É "a política nomeia os seis".

Um desses seis é diferente dos outros, e é justamente o que as pessoas esquecem. As etapas 1 a 3, 5 e 6 guardam dados que você consegue apagar. A etapa 4 não: o que um modelo aprendeu durante o fine-tuning não sai apagando um arquivo. É por isso que os controles de pré-ingestão do tópico anterior também são controles de governança. Todo dado que você se recusa a treinar é uma cópia que você nunca precisa prestar contas.

Retenção: a configuração cujo padrão é "para sempre"

Retenção é onde a política escrita encontra um valor de configuração de verdade, e os padrões raramente são o que a sua política diz.

Leia a linha do CloudWatch Logs de novo. Por padrão, os dados de log ficam armazenados no CloudWatch Logs indefinidamente. Para um log comum de aplicação isso é um problema de custo. Para uma aplicação de IA com model invocation logging ligado, o log group contém os corpos completos de requisição e resposta, ou seja, é um depósito permanente de tudo que os usuários escreveram para o modelo e de tudo que o modelo respondeu. Ele herda a sensibilidade da conversa, não a sensibilidade de um log normal.

Um plano de retenção resolvido para um assistente interno fica assim:

Repare que "apagar depois de N dias" e "guardar por N anos" usam a mesma ferramenta em direções opostas, e que duas das seis linhas não são regra de lifecycle nenhuma. Governança não é um recurso só.

Uma correção que vale dizer em voz alta, porque a suposição é comum: reduzir o período de retenção não remove o dado na hora. O CloudWatch marca os eventos expirados para exclusão e normalmente conclui a remoção em até 72 horas. Se a política exige exclusão comprovada até um prazo, embuta o prazo nessa conta.

Residência: onde o dado tem permissão de estar

Residência de dados é a exigência de que o dado seja armazenado, e muitas vezes processado, dentro de uma geografia nomeada. Ela aparece em bancos, saúde e setor público, e a AWS responde a ela primeiro pela escolha de Region: você escolhe a Region, o seu dado fica lá até você mover.

A IA generativa acrescenta uma dobra de que a prova gosta, porque é o único ponto em que um serviço da AWS pode processar a sua requisição em uma Region que você não escolheu.

A inferência cross-Region no Amazon Bedrock roteia a requisição para a Region do conjunto que tiver capacidade, o que aumenta a taxa de transferência e absorve picos de tráfego. Existem dois tipos de perfil, e só um deles respeita uma fronteira de residência:

A recomendação da AWS é direta: escolha o geográfico quando houver requisitos de residência de dados, e o global quando você quiser taxa de transferência máxima e economia sem restrição geográfica.

Três detalhes mantêm isso honesto. A inferência cross-Region pode rotear para Regions que você nunca habilitou manualmente na conta, então "a gente nunca ligou essa Region" não é controle. Todo o tráfego permanece na rede da AWS e é criptografado em trânsito, então a questão aqui é de jurisdição, não de exposição. E toda requisição cross-Region é registrada no CloudTrail na sua Region de origem, com um campo additionalEventData.inferenceRegion dizendo onde ela foi processada de fato, que é como você audita residência depois em vez de supor.

Se a sua organização precisa da fronteira imposta em vez de escolhida, isso é uma service control policy sobre aws:RequestedRegion no nível do AWS Organizations, acima do que qualquer time individual configure.

Logging: dois registros de uma chamada de IA

Para um serviço comum da AWS, "habilitar logging" significa uma coisa. Para uma chamada de IA generativa significa duas, e cada uma captura uma metade diferente.

A consequência de governança daquela última linha é a que você leva embora. Ligar o invocation logging é a decisão certa para auditabilidade e investigação de incidente, e cria um novo depósito do seu texto mais sensível. Ele precisa do mesmo tratamento dado à fonte: uma chave do KMS, uma política de acesso apertada, uma configuração de retenção e um lugar no seu mapa de exclusão. Times ligam isso por conformidade e depois reprovam em outro item de conformidade por causa dos logs que criaram.

Monitoramento e observação

O guia do exame lista monitoramento e observação como palavras separadas, e a divisão é útil mesmo com a fronteira sendo macia.

Monitoramento é baseado em limiar e é automático. Você define como é o "errado" em forma de número, e alguma coisa aciona um alerta quando aquilo acontece. Numa carga de IA: taxa de erro e throttling de invocação no CloudWatch, contagem de intervenções de guardrail, custo por mil invocações, latência no percentil 99 e uma regra do Config ficando noncompliant quando alguém desliga o model invocation logging.

Observação é o olhar contínuo sobre o que o sistema está de fato fazendo, inclusive coisas para as quais você nunca escreveu um limiar. Drift de dados e de qualidade do modelo pelo SageMaker Model Monitor, métricas de viés recalculadas sobre tráfego real pelo SageMaker Clarify, revisão humana amostral das saídas e leitura periódica dos prompts que os usuários enviam. Observação é como você descobre que o assistente está sendo usado para algo que ninguém projetou, que é um achado de governança para o qual nenhum alarme foi configurado.

Os dois importam, e o motivo é específico de IA: um sistema de IA não falha de forma limpa. Um servidor web mal configurado devolve erro 500. Um modelo em drift devolve respostas fluentes, bem formadas e plausíveis que estão piorando. Monitoramento de disponibilidade não vai perceber.

A parte que não é um serviço

Dois elementos de governança não têm console na AWS, e os dois vêm primeiro.

Classificação coloca cada dataset em uma faixa (público, interno, confidencial, restrito, por exemplo) e prende as regras à faixa em vez de a buckets individuais. Requisitos de criptografia, Regions aprovadas, períodos de retenção e a permissão de usar aquilo para treinar modelo ficam todos pendurados nesse rótulo único. Sem ele, cada dataset novo reinicia a discussão.

Propriedade nomeia um humano responsável por cada dataset. O data owner classifica o dado, aprova pedidos de acesso e aprova usos novos, incluindo "podemos fazer fine-tuning com isto?". A AWS te dá a ferramenta para registrar e impor essas decisões, com tags, o Glue Data Catalog e permissões do Lake Formation. Tomar a decisão ela não pode.

Tagging é onde os dois encontram a máquina. Uma tag consistente como DataClassification=Restricted em buckets, log groups e training jobs é o que permite a uma regra do Config checar conformidade por faixa de política em vez de por nome de recurso, e o que permite quebrar relatórios de custo e de acesso por sensibilidade.

Dicas para a prova

• "Governança de dados" no enunciado aponta para regras sobre o dado (retenção, residência, finalidade, propriedade), não para controle de acesso. Se o cenário diz "impedir acesso não autorizado", você voltou para segurança.
• A retenção do CloudWatch Logs é "nunca expira" por padrão. Esse fato sozinho responde a vários formatos de questão sobre logs crescendo sem fim ou guardando dado além do prazo da política.
• O event history do CloudTrail é 90 dias de eventos de gerenciamento e não é configurável. Retenção maior significa trail para o S3 ou event data store do CloudTrail Lake.
• Regras de S3 Lifecycle são o mecanismo tanto para mover dado para armazenamento mais barato quanto para apagá-lo em uma agenda.
• "O dado precisa permanecer na UE" mais Amazon Bedrock significa geographic cross-Region inference profile, não global.
• O CloudTrail registra a chamada; o model invocation logging do Bedrock registra o conteúdo. Uma questão perguntando o que havia dentro de um prompt precisa do segundo, que vem desligado.
• Drift, recálculo de viés e revisão humana amostral são observação. Alarmes e limiares são monitoramento.

A regra para levar: governança é o conjunto de decisões que precisa existir antes de um controle ter o que impor. Períodos de retenção, fronteiras de residência, classificações e donos são entradas, e todo serviço da última lição deste tópico apenas confere se a realidade bate com elas. A próxima lição trata de onde essas decisões nascem, começando pelo framework que a AWS nomeia para dimensionar um caso de uso generativo.