Governança de agentes de IA no Snowflake começa por controles sólidos de dados

O texto descreve como governar dados e agentes de IA no Snowflake, a partir de notas de campo de um engenheiro de dados baseadas na documentação e em testes próprios. A tese: quando um LLM roda SQL em nome do usuário, cada lacuna numa política de masking vira um caminho aberto para o agente. Tudo se apoia no Horizon Catalog, tratado como plano de controle, com três pilares em ciclo: entender (descobrir dados sensíveis), proteger (masking, row access, projection) e monitorar (qualidade, acesso e linhagem). O autor sugere um banco e um papel dedicados à governança, para separar quem é dono do dado de quem decide como ele é mascarado.

No pilar de entendimento, a classificação automática amostra os valores das colunas, não só os nomes, e grava duas tags de sistema (SEMANTIC_CATEGORY e PRIVACY_CATEGORY). Os limites aparecem no próprio texto: nada tinha sido classificado 15 minutos após anexar o perfil no teste do autor, o modo AI (preview público desde agosto de 2026) é cobrado à parte e falhou na região do teste, e um CREATE OR REPLACE do perfil desliga a classificação automática. Na proteção, o masking por tag cobre colunas futuras, mas exige uma política por tipo de dado: uma coluna NUMBER com a mesma tag voltou em texto claro, sem erro. Políticas de row access, projection, aggregation e join por tag estão em preview público, e quase tudo exige Enterprise Edition ou superior. Uma política de row access por tag que não encontra a coluna correspondente simplesmente não é aplicada, sem aviso.

Para quem opera pipelines no Snowflake, a leitura é que governança para agentes é, antes de tudo, higiene de dados: classificar, atribuir políticas por tag e auditar com POLICY_REFERENCES. Os silêncios que o autor relata (NULL mascarado, tipo sem política, coluna ausente no row access) merecem teste antes de liberar um agente com acesso a SQL. Nada disso substitui validar o status de preview de cada recurso.