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.
Em resumo
Muitas empresas chegam ao tema com um agente de IA já escolhido e uma dúvida ainda aberta: por onde começar a organizar o contexto que ele vai consumir. Para construir um Company Brain, a empresa passa por etapas que misturam conexão de sistemas, acordo entre áreas e regras de acesso, e cada uma tem um ponto em que o projeto costuma travar. O Company Brain é a camada que conhece a empresa: quais dados existem, onde vivem, como se relacionam e quem pode ver o quê.
A parte técnica tem componentes conhecidos, da conexão com as fontes à entrega ao modelo. O prazo costuma ser definido pelas decisões que dependem de pessoas fora da tecnologia, como o comercial e a logística concordarem sobre quando uma entrega está atrasada.
Referências de gestão de IA seguem a mesma ordem. O framework de gestão de risco de IA publicado pelo NIST em 2023, depois de estabelecer a governança, parte da função que mapeia o contexto em que o sistema vai operar, antes de medir e gerenciar. Para construir um Company Brain, o raciocínio é parecido: primeiro o recorte do negócio, depois a tecnologia.
Cada uma das sete etapas tem uma exigência e um erro frequente.
A pergunta que abre o trabalho de construir um Company Brain precisa ser recorrente, ter dono e atravessar dois ou três sistemas. Um exemplo é saber quais pedidos de grandes clientes estão bloqueados por crédito e têm entrega prometida para a semana. O erro comum é escolher uma pergunta ampla demais, como entender o cliente, que não define fontes nem entidades.
A pergunta indica os sistemas: a promessa de entrega no CRM, o bloqueio de crédito no ERP, a agenda de saída na logística. A etapa exige acesso de leitura negociado com tecnologia e segurança. Ela costuma travar quando o acesso a um sistema antigo depende de uma aprovação sem dono claro.
O mesmo produto pode ter um código no ERP, uma descrição livre no CRM e outra referência na logística. Antes de ligar registros no grafo de conhecimento, é preciso reconhecer quais deles representam a mesma coisa. Juntar dois itens diferentes contamina as respostas seguintes, e por isso os casos ambíguos passam por alguém da área.
Para o comercial, entrega no prazo é a que chega na data prometida ao cliente. Para a logística, é a que sai na data agendada com a transportadora. A ontologia registra qual definição vale em cada pergunta e quem responde por ela. O erro comum é deixar a escolha com a equipe técnica, que não tem autoridade para defendê-la.
A camada semântica traduz a pergunta em linguagem natural para os registros e termos corretos. A permissão vem do sistema de origem: quem não vê o limite de crédito no ERP também não o recebe pela IA. A dificuldade aparece quando as regras de acesso vivem em perfis antigos ou em planilhas mantidas à mão.
O contexto chega ao agente pelo MCP, o protocolo aberto que conecta modelos a fontes de dados, com a origem de cada informação indicada. O erro comum é conectar vários agentes antes de o primeiro estar em uso.
A medição acompanha uso real, respostas corrigidas e perguntas que ficaram sem resposta. A expansão escolhe a próxima pergunta pelas fontes e definições que ela reaproveita. Quem pula a medição expande sobre uma base que ninguém validou.
Algumas escolhas aparecem sempre que uma empresa decide construir um Company Brain, e todas dependem de repertório:
Na Strattum, o forward deployed engineer (FDE) trabalha dentro da empresa, ao lado das áreas, durante a implantação. Ele conhece a plataforma por dentro e ajuda a escolher quais perguntas funcionam como primeiro recorte e onde a resolução de entidades tende a falhar.
As decisões continuam com a empresa. O FDE organiza as alternativas, registra na ontologia o que foi decidido e conecta as fontes. O que ele constrói fica no ambiente do cliente, e o segundo caso de uso parte do que o primeiro deixou resolvido.
Três condições sustentam o projeto. Um patrocinador com autoridade para destravar acessos e arbitrar definições. Fontes acessíveis por API ou banco de dados. Tempo reservado das pessoas que conhecem o processo, porque são elas que validam entidades e termos.
O Company Brain reduz as respostas erradas causadas por falta de contexto. A qualidade da resposta continua dependendo do cadastro na origem, e um ERP com produtos duplicados exige limpeza antes ou durante o projeto.
O primeiro passo prático é escrever a pergunta candidata e listar os sistemas que ela toca e os termos que geram discussão entre as áreas. Esse exercício mostra o tamanho do esforço para construir um Company Brain naquele recorte.
A Strattum faz conversas de diagnóstico sobre esse primeiro recorte: qual pergunta escolher, quais fontes ela exige e quais definições precisam de dono. Para empresas que estão decidindo por onde começar, é uma forma de enxergar o caminho com quem conhece a plataforma por dentro.