Como a Guidewire construiu uma plataforma federada de queries para ML em escala, e onde a governança de dados ficou exposta

A Guidewire usou o Trino para federar queries entre Iceberg, Redshift, OpenSearch e buckets S3 de clientes, mas não como um simples ‘SQL over everything’. A camada S3 do Trino lê diretamente os metadados da tabela (como o nome bruto do bucket) sem respeitar políticas de acesso baseadas em S3 Access Points. Isso quebra a governança multi-conta: quando uma política exige que o acesso ao bucket só ocorra via Access Point, o Trino falha, mesmo com ABAC no Lake Formation ativo. O problema não é falta de RBAC no Trino ou de ABAC no AWS, mas uma lacuna no nível de abstração do filesystem, o Trino ainda não suporta mapeamento de Access Points nativamente, conforme apontado em discussão pública no GitHub em fevereiro de 2026.

Isso contrasta com avanços recentes em governança federada: o Databricks Unity Catalog já aplica ABAC *durante o planejamento da query* em motores Iceberg externos; a Snowflake Horizon Catalog, lançada em junho de 2026, estende mascaramento de coluna e filtros de linha para motores compatíveis com Iceberg v3; e a Cloudera integrou Trino com Data Lineage em março de 2026, garantindo rastreamento completo mesmo em consultas cruzando fontes. A Guidewire está, portanto, na frente em escala, mas atrás em governança *operacional*, porque sua arquitetura pressupõe que o controle de acesso no S3 seja suficiente, ignorando que o motor de consulta precisa participar ativamente do fluxo de autorização.

Na cobertura anterior do CEVIU sobre Iceberg v3 (abril/2026), o foco era em features técnicas: Row Lineage, Deletion Vectors e tipo VARIANT. Agora, em junho/2026, a evolução não está apenas no formato da tabela, mas na forma como ele se integra à governança federada, com Unity Catalog, Horizon Catalog e Polaris operando como ‘camadas de decisão’ que interceptam queries antes da execução. A Guidewire, por usar Trino com catálogos Iceberg externos, fica fora desse ciclo: seu ABAC no Lake Formation protege o catálogo, mas não impede que o Trino leia objetos S3 sem filtragem de linha ou mascaramento, pois não há integração com Ranger ou Polaris. Ou seja: o que era uma questão de desempenho (v3) virou uma questão de controle (governança em tempo de execução).

Para equipes de dados que apostam em lakehouse federado, essa falha não é teórica: significa que dados sensíveis em buckets S3 podem ser expostos em consultas exploratórias de ML, mesmo com políticas rigorosas no Lake Formation. Não basta isolar tenants com catálogos, é preciso que o motor de consulta entenda e aplique regras de acesso *no nível do objeto*, não só no nível do catálogo. E isso exige integração com frameworks como Apache Ranger, Polaris ou Unity Catalog, não apenas configuração de RBAC no Trino. A lição prática é clara: em arquiteturas federadas, governança não é uma camada separada, é uma responsabilidade compartilhada entre catálogo, motor e infraestrutura de armazenamento.