Arthur Guttilla Head of Product Marketing, Strattum Com passagens na Amazon Web Services e no Google, Guttilla trabalhou diretamente com fundadores de startups e empresas de capital de risco, compreendendo as necessidades de empresas tecnológicas em estágio inicial na interseção entre tecnologia e negócios.
TL;DR: Um data lake resolve armazenamento, escala e custo por terabyte, entregando dado bruto disponível para processamento. Um Company Brain resolve contexto: conecta as fontes uma vez, declara uma ontologia com as entidades e regras do negócio, mantém memória do que já foi perguntado e decidido, aplica permissão herdada e devolve resposta com origem. As duas camadas resolvem problemas diferentes, e o lake costuma ser uma das fontes do Company Brain.
Data lakes existem por um motivo sólido: armazenar volume grande de dado heterogêneo sem exigir esquema definido na escrita. Isso resolve quatro problemas reais.
Custo por terabyte baixo, porque o armazenamento de objeto é barato e separado do processamento. Ingestão sem modelagem prévia, o que permite guardar primeiro e decidir depois. Suporte a dado estruturado, semiestruturado e binário no mesmo lugar. E escala de processamento sob demanda, com engines que leem direto dos arquivos.
Para analytics, ciência de dados e retenção histórica, esse conjunto é adequado e continua sendo. O problema aparece quando a empresa assume que, por ter o dado reunido, ele está pronto para alimentar aplicações de IA.
Um data lake com 400 tabelas de ERP, extrações diárias de CRM, logs de produto e uma pasta de contratos em PDF tem tudo que uma pergunta de negócio precisa. E não consegue respondê-la.
Faltam cinco coisas, e nenhuma delas é volume.
Identidade. Nada no lake declara que account_id do CRM, cod_cliente do ERP e organization do sistema de chamados apontam para a mesma empresa. Quem sabe disso é a pessoa que escreve a query.
Semântica. A coluna status com valores de 1 a 7 está guardada com fidelidade perfeita e significado nenhum. Três desses valores caíram em desuso em 2023 e isso não está registrado em lugar algum.
Regra de negócio. O que a empresa considera cliente ativo, inadimplência para efeito comercial ou chamado crítico não é campo. É decisão, e ela vive fora do lake.
Permissão no momento da consulta. O lake tem controle de acesso por camada, tabela ou arquivo. Ele não sabe traduzir a permissão que uma pessoa tem no sistema de origem para o recorte que ela pode ver em uma resposta gerada.
Recuperação orientada a pergunta. Engines de query respondem a SQL. Uma aplicação de IA precisa transformar uma pergunta em linguagem natural em recuperação correta, o que exige as quatro coisas acima declaradas de forma executável.
O resultado prático é conhecido: times de dados maduros, com lake e warehouse bem operados, ainda assim penam para colocar um agente respondendo com precisão sobre clientes.
O que um Company Brain acrescenta se organiza em cinco componentes. Eles se sustentam uns nos outros, e pular um deles costuma aparecer como qualidade irregular de resposta mais tarde.
Conexão única com cada fonte: ERP, CRM, banco transacional, warehouse, data lake, repositório de documentos e as planilhas que sustentam decisão. O conector resolve autenticação, paginação, limite de requisição, mapeamento de campo e política de atualização.
Dois critérios separam um conector de plataforma de um script de integração. Ele absorve mudança de schema sem quebrar quem consome, e ele propaga a identidade de quem está perguntando em vez de usar credencial de serviço compartilhada.
Para dado que muda no segundo, como saldo e status de pedido, o conector consulta a fonte no momento da pergunta. Para conteúdo estável, mantém índice com política de invalidação declarada.
A ontologia declara o que existe no negócio e como as coisas se ligam. Entidades como cliente, contrato, produto, pedido, chamado e usuário. Relações entre elas, com cardinalidade e caminho. Atributos com significado e origem. Regras que definem estados e transições.
É aqui que a diferença com um catálogo de dados fica clara. Catálogo documenta para pessoas lerem. Ontologia é declaração executável, consultada pela camada de recuperação para transformar uma pergunta em busca correta.
Uma ontologia útil também carrega o que costuma ficar implícito: a precedência entre fontes quando elas discordam, as exceções que a regra geral não cobre e a vigência de cada definição, porque regra de negócio muda e respostas históricas precisam continuar explicáveis.
Aqui está a camada que quase nunca aparece em projeto de data lake, e que separa uma aplicação que responde de uma que opera junto com a empresa.
Memória de trabalho. O estado da conversa ou da tarefa em andamento, com o que já foi recuperado e decidido nos passos anteriores.
Memória episódica. O registro de consultas anteriores, respostas dadas e ações tomadas. É o que permite responder "o que mudou desde a última análise desta conta" sem refazer tudo.
Memória semântica acumulada. Correções que as pessoas fizeram, definições refinadas em uso e padrões que se confirmaram. Quando um analista corrige uma classificação, essa correção precisa virar conhecimento da camada, e não permanecer no histórico de uma conversa isolada.
Memória de procedimento. Como a empresa executa tarefas recorrentes, com as etapas e verificações que um agente deve seguir.
Memória cria dois requisitos que não existiam antes: política de retenção, porque o histórico contém conteúdo sensível, e mecanismo de esquecimento, porque conhecimento desatualizado é pior que ausência de conhecimento. Uma regra revogada que permanece na memória produz resposta confiante e errada.
Permissão herdada do sistema de origem, aplicada na recuperação e não na exibição. Cada pessoa alcança pela IA apenas o que já alcançava nos sistemas. Cada resposta indica sistema, registro e data. Cada consulta fica registrada com usuário, pergunta, fontes recuperadas e filtros aplicados.
Isso precisa viver na camada de dados. Implementado na interface, deixa de valer no primeiro agente que consumir a plataforma por API.
O componente que recebe a pergunta, identifica entidades e período, aplica os filtros estruturais e de permissão, escolhe a estratégia adequada, recupera o recorte necessário e devolve com procedência.
A escolha da estratégia fica aqui e não na aplicação. Consulta estruturada para dado tabular, busca semântica para conteúdo textual, navegação por relação para perguntas que atravessam entidades e chamada direta à fonte para dado volátil.
| Dimensão | Data lake | Company Brain |
|---|---|---|
| Problema central | Armazenar volume heterogêneo | Entregar contexto correto a cada consulta |
| Unidade de trabalho | Arquivo, tabela, partição | Entidade, relação, regra |
| Momento da modelagem | Na leitura, por quem escreve a query | Declarada uma vez, aplicada em toda consulta |
| Identidade entre sistemas | Resolvida caso a caso | Declarada e reaproveitada |
| Regra de negócio | Fora do escopo | Componente central |
| Memória de uso | Inexistente | Trabalho, episódica, semântica e procedimento |
| Permissão | Por camada ou objeto | Herdada da origem, aplicada na recuperação |
| Consumidor típico | Analista, engenheiro, pipeline | Agente, assistente, automação |
| Resposta | Resultado de query | Contexto com origem e trilha |
A linha do consumidor explica boa parte do desalinhamento. Lake foi desenhado para quem sabe o que está procurando. Contexto é para quem pergunta em linguagem de negócio e não conhece o schema.
Uma operadora logística com data lake maduro, três anos de histórico e governança de qualidade implantada decidiu colocar um agente para o time de contas estratégicas.
A primeira versão gerava SQL a partir da pergunta, direto contra o lake. Funcionava em consultas simples e errava nas que importavam. Três causas apareceram na investigação.
O mesmo cliente tinha três identificadores, e o agente somava volumes de dois deles e ignorava o terceiro, que concentrava as operações de importação. A definição de entrega no prazo tinha duas versões no lake, uma calculada sobre a data prometida original e outra sobre a data repactuada, ambas corretas para propósitos diferentes. E as condições especiais dos 40 maiores clientes viviam em contratos digitalizados, fora do lake.
A construção do Company Brain manteve o lake como fonte principal de dado histórico. Foram acrescentados conectores para o sistema de ocorrências e para o repositório de contratos, uma ontologia com cliente, contrato, operação e ocorrência, resolução de identidade entre os três cadastros e declaração das duas definições de prazo com a regra de qual usar em cada tipo de pergunta.
A memória entrou depois e mudou o uso: o agente passou a registrar as análises feitas por conta, o que permitiu perguntas sobre variação desde a última revisão, e passou a incorporar as correções dos analistas sobre classificação de ocorrência.
Nenhum dado foi movido do lake.
Três consequências financeiras merecem atenção de quem aprova o investimento.
A conta de analytics e a de IA são diferentes. O lake reduz custo de armazenamento. A camada de contexto reduz custo por consulta de IA, porque envia recorte em vez de volume, e permite rodar boa parte das tarefas em modelo mais barato.
O ativo construído é distinto. Um lake bem operado é infraestrutura replicável por qualquer concorrente com o mesmo orçamento. Ontologia e memória carregam o conhecimento específico da empresa, que não se compra pronto e melhora com uso.
O prazo do segundo caso de uso muda. Com lake apenas, cada nova aplicação de IA refaz identidade, semântica e regra. Com contexto declarado, ela reaproveita, e a diferença aparece na terceira iniciativa.
Não. A camada consome fontes estruturadas e não estruturadas diretamente. O lake ajuda quando já existe, principalmente para histórico.
Resolve parte: semântica sobre dado estruturado e métricas consistentes. Continua faltando documento, memória e permissão herdada aplicada na recuperação por pessoa.
Vira longo quando tenta cobrir a empresa inteira antes da primeira entrega. Começando por três entidades e cinco definições, cabe em semanas.
Engenharia de dados mantém a implementação, e as áreas de negócio são donas das definições. Mudança de regra precisa entrar no processo da área, com vigência registrada.
Com prazo de validade por tipo de conhecimento, marcação de origem de cada item aprendido e revisão das correções antes de promovê-las a definição.
Fale com um especialista da Strattum e avalie a distância entre o seu data lake e um Company Brain.