A Databricks publicou em 28 de maio, nas release notes de maio, que engines externos agora conseguem ler tabelas gerenciadas do Unity Catalog (Delta e Iceberg) com attribute-based access control (ABAC), row filters e column masks aplicados no lado servidor. Antes isso só funcionava quando a query rodava dentro do próprio Databricks.

O que muda na prática

ABAC é controle de acesso baseado em atributos: você define que usuários com o atributo “region=BR” podem ler apenas linhas onde a coluna country é ‘BR’. Row filter restringe quais linhas aparecem; column mask substitui valores sensíveis (CPF, e-mail) por hash ou null pra quem não tem permissão.

Até ontem, essas políticas só eram garantidas pelo Spark do Databricks. Se o time da área financeira lia a mesma tabela Delta via Trino independente, ou via DuckDB local, as regras não se aplicavam — todo mundo via tudo. Era um furo de governança que muitos times trataram com replicação e camadas de view.

O que está disponível hoje

A aplicação agora é server-side: o próprio serviço Unity Catalog filtra e mascara antes de devolver dados pro engine externo. Vale pra tabelas Delta e Iceberg gerenciadas via UC. Engines como Trino, Spark externo, DuckDB com Delta plugin, e qualquer um que fale o protocolo aberto Delta ou Iceberg passam a respeitar as políticas automaticamente.

A Databricks não detalhou se existe degradação de performance comparada a acesso direto, e esse ponto precisa de verificação em benchmarks próprios. Em geral, server-side enforcement adiciona uma camada de avaliação de políticas — o overhead vai depender da complexidade dos filtros.

Também no mesmo release: Claude Opus 4.8 no Model Serving

O Databricks Model Serving passou a suportar Claude Opus 4.8 como modelo hospedado pelo Databricks. Antes a Anthropic estava disponível via parceria com pass-through; agora roda dentro do plano de instância gerenciada pela Databricks. Pra clientes que precisam manter dados em uma única fronteira (compliance, região de processamento), isso reduz uma camada de provedor.

Implicações pra LGPD e GDPR

O ganho mais imediato é pra times com requisitos regulatórios. ABAC mais row/column policies server-side significa que é viável auditar uma única fonte de verdade de política em vez de garantir manualmente que cada engine respeita. Pra LGPD em particular, mascarar CPF ou e-mail no UC e ter certeza de que vale também em DuckDB local de analista é ganho de risco gerenciado.

Cuidados antes de adotar

Clientes Iceberg e Delta precisam estar em versões recentes pra entender o que o UC retorna como dado mascarado. Versões antigas podem ter comportamento inconsistente — a Databricks não publicou matriz de compatibilidade por engine ainda, e esse ponto precisa de verificação caso a caso.

Times multi-engine devem rodar testes de regressão pra confirmar que políticas existentes não quebram queries em produção em Trino ou em Spark externo. Antes de habilitar em produção, vale subir em ambiente isolado e medir o overhead.

O ponto que importa

O Unity Catalog vinha sendo posicionado pela Databricks como “sistema operacional de dados”. Esse release confirma a tese: a inteligencia de governança passa a viver no catálogo, não no engine. Pra quem operava semantica de política duplicada em multiplos engines, é economia real de codigo de segurança.

Reportado originalmente por Databricks Release Notes em 2026-05-28.