No panorama financeiro atual, e em particular no setor do crédito habitação, o verdadeiro valor não reside apenas nas bases de dados estruturadas, mas numa mina de ouro frequentemente inutilizada: os documentos não estruturados. Recibos de vencimento, avaliações imobiliárias, escrituras notariais e documentos de identificação constituem aquilo que é frequentemente definido como Dark Data. O desafio para os CTOs e Arquitetos de Dados em 2026 já não é apenas arquivar estes ficheiros, mas torná-los consultáveis em tempo real juntamente com os dados transacionais.

Neste artigo técnico, exploraremos como projetar e implementar uma arquitetura data lakehouse google cloud capaz de derrubar os silos entre o data lake (onde residem os PDFs) e o data warehouse (onde residem os dados de CRM). Utilizaremos a potência do BigQuery, a inteligência da Document AI e as capacidades preditivas da Vertex AI para transformar um processo de análise de crédito manual numa pipeline automatizada e segura.

O Paradigma Data Lakehouse na Fintech

Tradicionalmente, os bancos mantinham duas stacks separadas: um Data Lake (ex. Google Cloud Storage) para os ficheiros brutos e um Data Warehouse (ex. bases de dados SQL legacy ou os primeiros MPP) para a Business Intelligence. Esta abordagem implicava duplicação de dados, latência elevada e desalinhamento da informação.

O Data Lakehouse na Google Cloud Platform (GCP) resolve este problema permitindo tratar os ficheiros arquivados no armazenamento de objetos como se fossem tabelas de uma base de dados relacional, mantendo, no entanto, os custos baixos do armazenamento e o desempenho elevado do warehouse.

Componentes Chave da Arquitetura

• Google Cloud Storage (GCS): O nível de armazenamento físico para os documentos (PDF, JPG, TIFF).
• BigQuery (BQ): O coração do Lakehouse. Gere tanto os dados estruturados (CRM) como os metadados dos ficheiros não estruturados através de Object Tables.
• Document AI: O serviço de processamento inteligente de documentos (IDP) para extrair entidades chave.
• Vertex AI: Para o treino de modelos de credit scoring baseados nos dados unificados.

Fase 1: Design da Arquitetura e Ingestão

O primeiro passo para construir um data lakehouse google cloud eficaz é estruturar corretamente o nível de ingestão. Não estamos simplesmente a carregar ficheiros; estamos a preparar o terreno para a análise.

Configuração das Object Tables no BigQuery

A partir das atualizações recentes da GCP, o BigQuery permite criar Object Tables. Estas são tabelas de apenas leitura que mapeiam os ficheiros presentes num bucket GCS. Isto permite-nos ver os PDFs dos recibos de vencimento diretamente dentro do BigQuery sem os mover.

CREATE OR REPLACE EXTERNAL TABLE `fintech_lakehouse.raw_documents`
WITH CONNECTION `us.my-connection`
OPTIONS (
  object_metadata = 'SIMPLE',
  uris = ['gs://mutui-docs-bucket/*.pdf']
);

Com esta única instrução SQL, tornámos o nosso arquivo documental acessível via SQL. Podemos consultar os metadados (data de criação, dimensão, nome do ficheiro) como se fossem colunas estruturadas.

Fase 2: Extração Inteligente com Document AI e Remote Functions

Ter os ficheiros listados no BigQuery não basta. Precisamos de ler o seu conteúdo. Aqui entra em jogo a integração entre o BigQuery e a Document AI através das Remote Functions (Funções Remotas).

Em vez de construir pipelines ETL complexas com Dataflow ou scripts Python externos, podemos invocar o modelo de extração diretamente a partir de uma query SQL. Imaginemos que temos de extrair o “Rendimento Líquido” e a “Entidade Patronal” dos recibos de vencimento.

1. Criação do Processador Document AI

Na consola GCP, configuramos um processador Lending Document Splitter & Parser (específico para o setor de crédito) ou um processador Custom Extractor treinado nos recibos de vencimento específicos.

2. Implementação da Remote Function

Criamos uma Cloud Function (Gen 2) que serve de ponte. Esta função recebe o URI do ficheiro do BigQuery, chama a API da Document AI e devolve um objeto JSON com as entidades extraídas.

3. Extração via SQL

Agora podemos enriquecer os nossos dados brutos transformando-os em informações estruturadas:

CREATE OR REPLACE TABLE `fintech_lakehouse.extracted_income_data` AS
SELECT
  uri,
  remote_functions.extract_entities(uri) AS json_data
FROM
  `fintech_lakehouse.raw_documents`
WHERE
  content_type = 'application/pdf';

O resultado é uma tabela que contém o link para o documento original e uma coluna JSON com os dados extraídos. Este é o verdadeiro poder do data lakehouse google cloud: dados não estruturados convertidos em estruturados on-the-fly.

Fase 3: Modelação de Dados e Otimização de Esquema

Uma vez extraídos os dados, como devemos armazená-los? No contexto do crédito habitação, a flexibilidade é fundamental, mas o desempenho das queries é prioritário.

Abordagem Híbrida: Colunas Estruturadas + JSON

Desaconselhamos “achatar” completamente cada campo extraído numa coluna dedicada, pois os formatos documentais mudam. A melhor abordagem é:

• Colunas Core (Estruturadas): ID do Processo, NIF (Código Fiscal), Rendimento Mensal, Data de Admissão. Estas colunas devem ser tipificadas (INT64, STRING, DATE) para permitir joins rápidos com as tabelas do CRM e otimizar os custos de armazenamento (formato BigQuery Capacitor).
• Coluna Payload (JSON): Todo o resto da extração (detalhes menores, notas à margem) permanece numa coluna do tipo JSON. O BigQuery suporta nativamente o acesso aos campos JSON com uma sintaxe eficiente.

Exemplo de query analítica unificada:

SELECT
  crm.customer_id,
  crm.risk_score_preliminare,
  docs.reddito_mensile,
  SAFE_CAST(docs.json_payload.dettagli_extra.bonus_produzione AS FLOAT64) as bonus
FROM
  `fintech_lakehouse.crm_customers` crm
JOIN
  `fintech_lakehouse.extracted_income_data` docs
ON
  crm.tax_code = docs.codice_fiscale
WHERE
  docs.reddito_mensile > 2000;

Fase 4: Segurança e Conformidade RGPD (Row-Level Security)

Ao tratar dados sensíveis como rendimentos e avaliações, a segurança não é opcional. O RGPD impõe que o acesso aos dados pessoais seja limitado ao pessoal estritamente necessário.

Num data lakehouse google cloud, não é necessário criar vistas separadas para cada grupo de utilizadores. Utilizamos a Row-Level Security (RLS) do BigQuery.

Implementação das Políticas de Acesso

Suponhamos que temos dois grupos de utilizadores: Analistas de Risco (acesso completo) e Agentes Comerciais (acesso limitado apenas aos seus próprios processos).

CREATE ROW ACCESS POLICY commercial_filter
ON `fintech_lakehouse.extracted_income_data`
GRANT TO ('group:agenti-commerciali@banca.it')
FILTER USING (agente_id = SESSION_USER());

Com esta política, quando um agente executa um SELECT *, o BigQuery filtrará automaticamente os resultados, mostrando apenas as linhas onde o agente_id corresponde ao utilizador com login efetuado. Os dados sensíveis dos outros clientes permanecem invisíveis, garantindo a conformidade normativa sem duplicar os dados.

Fase 5: Credit Scoring Preditivo com Vertex AI

A última milha do nosso Lakehouse é a ativação do dado. Agora que unimos os dados comportamentais (histórico de pagamentos do CRM) com os dados de rendimento reais (extraídos dos recibos de vencimento), podemos treinar modelos de Machine Learning superiores.

Utilizando a Vertex AI integrada com o BigQuery, podemos criar um modelo de regressão logística ou uma rede neuronal para prever a probabilidade de incumprimento (PD).

1. Feature Engineering: Criamos uma vista no BigQuery que une as tabelas CRM e Documentais.
2. Training: Usamos CREATE MODEL diretamente em SQL (BigQuery ML) ou exportamos o dataset para a Vertex AI para o AutoML.
3. Prediction: O modelo treinado pode ser invocado em batch todas as noites para recalcular a pontuação de risco de todos os processos abertos, sinalizando anomalias entre o rendimento declarado e o extraído dos documentos.

Conclusões

Implementar um data lakehouse google cloud no setor do crédito habitação transforma radicalmente a operacionalidade. Não se trata apenas de tecnologia, mas de velocidade de negócio: passar de dias para minutos na pré-aprovação de um crédito.

A arquitetura apresentada, baseada na integração estreita entre BigQuery, GCS e Document AI, oferece três vantagens competitivas imediatas:

1. Unificação: Uma única fonte de verdade para dados estruturados e não estruturados.
2. Automação: Redução da intervenção humana na extração de dados (Data Entry).
3. Conformidade: Controlo granular dos acessos nativo na base de dados.

Para as instituições financeiras que olham para 2026 e mais além, esta convergência entre gestão documental e análise de dados representa o padrão de facto para permanecerem competitivas num mercado cada vez mais guiado pelos algoritmos.

Perguntas frequentes