Quando uma empresa começa a usar IA com os próprios dados, uma pergunta aparece cedo ou tarde, geralmente vinda do jurídico, da segurança ou da auditoria: como garantimos que a IA só usa o que pode usar, e como provamos isso depois? Responder bem exige governança de dados de verdade, não um documento de política guardado numa pasta. Neste artigo, mostramos como estruturar essa governança na AWS e por que ela é a base de qualquer IA segura.
O que muda com a IA
Antes, o acesso a dados era quase sempre direto: uma pessoa abria uma tabela, um relatório ou uma pasta. Com assistentes e agentes de IA, surge um intermediário que consulta muitas fontes em nome de quem pergunta. Isso cria três exigências novas:
- O acesso precisa ser decidido por pessoa, não por aplicação. Se o assistente usa uma credencial com acesso amplo, todo mundo que conversa com ele passa a ter esse acesso.
- O controle precisa ser fino. Muitas vezes a pessoa pode ver a tabela, mas não todas as colunas ou todas as linhas.
- Tudo precisa ser rastreável. Para investigar uma resposta, é preciso saber quais dados foram consultados.
As peças da governança na AWS
Catálogo como fonte única. O AWS Glue Data Catalog registra tabelas, esquemas e localização dos dados no lakehouse. Sem catálogo, não há como governar: cada serviço enxerga os dados de um jeito.
Permissões centralizadas com o Lake Formation. O AWS Lake Formation concentra as permissões sobre os dados catalogados. Ele permite controlar acesso por banco, tabela, coluna, linha e até célula. Em vez de manter políticas espalhadas por buckets e serviços, a regra fica em um só lugar e vale para quem consulta pelo Amazon Athena, pelo Amazon Redshift, pelo AWS Glue ou pelo Amazon EMR.
Permissões por tags. Com o controle baseado em tags (LF-TBAC), as tabelas e colunas recebem rótulos como "área: financeiro" ou "sensibilidade: pessoal", e as permissões são dadas aos rótulos. Quando uma tabela nova entra no catálogo com a tag certa, ela já nasce protegida. Em ambientes que crescem rápido, isso evita que alguém precise lembrar de configurar cada tabela.
Camada de negócio. O Amazon DataZone, que também está por trás do catálogo do Amazon SageMaker Unified Studio, acrescenta o que o catálogo técnico não tem: glossário de termos, donos de cada conjunto de dados e um fluxo de solicitação e aprovação de acesso. A pergunta "quem decidiu que essa equipe pode ver esse dado?" passa a ter resposta registrada.
Qualidade com regras. O AWS Glue Data Quality aplica regras verificáveis a cada carga. Dado sem qualidade medida é dado que a IA não deveria usar sem ressalva.
Auditoria. O AWS CloudTrail registra os acessos aos dados e às permissões. Somado ao log de invocações do Amazon Bedrock, dá para reconstruir o caminho de uma resposta: quem perguntou, quais dados foram consultados e o que foi respondido.
Como isso se conecta à IA
Com a governança no lugar, a IA herda as regras em vez de criar regras novas. Um agente que consulta o lakehouse em nome de um analista recebe as permissões desse analista no Lake Formation. Uma base de conhecimento no Bedrock usa os metadados de sensibilidade para filtrar a busca. E as perguntas de auditoria passam a ter resposta técnica, não apenas uma política escrita.
Por onde começar
Governança não precisa começar grande. Uma sequência que costuma funcionar:
- Catalogar os dados do primeiro caso de uso de IA, com descrição e dono.
- Definir poucas tags de sensibilidade e aplicar as permissões por tag no Lake Formation.
- Ligar a auditoria e combinar com a segurança quanto tempo os registros ficam guardados.
- Expandir a cada novo caso de uso, reaproveitando as tags e o catálogo.
Conclusão
IA segura não é uma configuração no modelo. É a consequência de saber quais dados existem, quem pode ver cada um e como provar o que foi acessado. Na AWS, catálogo, Lake Formation, DataZone, regras de qualidade e CloudTrail formam essa base de forma integrada. Com ela pronta, cada novo projeto de IA começa com as regras já definidas, e a conversa com jurídico e auditoria fica bem mais curta.