Alex Karp na AIPCon 11: ontologia para preservar o valor da IA

Se sua empresa trocar de modelo de IA amanhã, quanto do que aprendeu sobre a própria operação continuará utilizável?

O histórico das decisões, as exceções negociadas e os critérios de aprovação precisam sobreviver a essa troca. Quando esse conhecimento fica disperso em conversas, prompts e adaptações que ninguém documentou, cada mudança de ferramenta pode exigir reconstruir parte do trabalho.

Na abertura da AIPCon 11, Alex Karp, cofundador e CEO da Palantir, defende preservar o valor que distingue uma organização por meio de uma camada de aplicação e de modelos adaptados à operação. Ao longo do evento, clientes e equipes técnicas descrevem como decisões de especialistas passam a orientar avaliações, modelos e processos.

A FSTech organiza contexto, regras e ações por meio da Ontologia Operacional. A metodologia conecta Dados, Lógica e Ação: o estado do negócio, as regras para decidir e as operações autorizadas que modificam esse estado. O registro do resultado oferece evidência para revisar o processo e orientar a próxima execução. A utilidade dessa estrutura pode ser testada em uma tarefa delimitada, inclusive quando o modelo muda.

O alpha empresarial na fala de Karp

Entre 4:12 e 5:42 de sua apresentação, Karp questiona o custo de consumir modelos e a perda de valor que atribui ao uso dessas ferramentas sem uma estrutura adequada. Em seguida, defende preservar o alpha da empresa em sua própria operação.

Na leitura da FSTech, o conhecimento operacional é uma das fontes desse alpha, a vantagem particular de uma organização. Pode estar no modo de priorizar uma entrega, reconhecer uma exceção contratual ou avaliar a relevância de uma informação antes de publicá-la.

Parte desse conhecimento aparece quando alguém experiente interrompe um procedimento que parecia correto: o cliente tem uma condição diferente, o dado chegou atrasado ou a autorização perdeu validade. Preservar a decisão exige registrar em que condições ela vale. Uma exceção isolada não deve virar regra geral por conveniência do software.

O argumento também favorece o negócio da Palantir, que fornece a integração e a camada operacional defendidas na fala. Os casos apresentados no evento ajudam a examinar o mecanismo proposto, embora seus resultados continuem sendo relatos das empresas envolvidas.

NVIDIA: a decisão do especialista vira referência para o sistema

Na apresentação da NVIDIA, a partir de 18:13, o problema é alocar componentes entre fabricantes para manter a produção em movimento. A disponibilidade de uma peça precisa ser interpretada junto das outras peças, dos prazos e da capacidade de cada fábrica.

Segundo o relato, o Command Center construído com a Palantir conecta esse contexto operacional. A ontologia reúne materiais, fabricantes, instalações, compromissos de produção e alocações. A otimização matemática calcula alternativas; os planejadores acrescentam informações qualitativas, como avisos de fornecedores e acontecimentos que ainda não estão adequadamente representados no cálculo.

O passo decisivo aparece em 24:06–26:35. A equipe descreve a construção dos fluxos de trabalho dos especialistas antes da adaptação dos modelos. Quando um planejador decide uma alocação, essa escolha pode ser registrada como referência de avaliação. O modelo candidato é então comparado com decisões históricas antes de voltar ao fluxo como apoio ao profissional.

O material descreve esta sequência:

Contexto operacional → decisão do especialista → referência de avaliação → modelo candidato → teste → uso assistido → novo resultado.

A NVIDIA relata que um modelo menor da família Nemotron, ajustado à tarefa, superou um modelo maior da mesma família no benchmark construído para o projeto. Também informa que a solução descrita opera em sua infraestrutura. Isso acrescenta um caso e um método à afirmação inicial de Karp, mas não demonstra superioridade geral de modelos pequenos nem permite reproduzir a comparação sem os dados e o protocolo completos.

A implicação que extraímos para a continuidade é esta: regras, exemplos autorizados e critérios de avaliação podem permanecer sob controle da organização e orientar o teste de outro modelo. O comportamento aprendido pelo modelo exige nova validação. O relato da NVIDIA descreve comparações dentro do projeto, sem demonstrar uma migração entre fornecedores.

Um log precisa de contexto e resultado para orientar aprendizado

Na conversa técnica em 1:29:45–1:32:53, a equipe aprofunda esse ponto. Um registro de execução ganha utilidade para avaliar o sistema quando pode ser associado ao que aconteceu no negócio.

Guardar que um agente recomendou enviar componentes a uma fábrica não basta. É preciso saber quais restrições existiam, o que o planejador decidiu e qual resultado foi observado. Essa ligação permite investigar a decisão; isoladamente, não prova que ela causou o resultado.

Os participantes descrevem a seleção de exemplos para um conjunto de validação separado do treinamento, usado para comparar novas versões do modelo. Assim, o modelo é avaliado em casos que não serviram para ensiná-lo.

Nossa leitura acrescenta dois cuidados operacionais. A decisão histórica de um especialista não é automaticamente a melhor decisão possível. E selecionar apenas casos bem-sucedidos pode esconder falhas. Uma avaliação útil precisa incluir exceções, informações ausentes e situações em que o comportamento correto é pedir esclarecimento ou parar.

Para a FSTech, esse é um critério de captura de conhecimento: preservar a decisão junto das condições em que foi tomada, da regra aplicável e da evidência disponível sobre o resultado. O registro pode orientar uma correção de processo, um novo teste ou uma mudança de regra. Treinar novamente o modelo é uma intervenção possível, não uma consequência obrigatória de cada interação.

Como a Palantir Ontology liga dados a decisões

A documentação oficial da Palantir define a Ontology como uma camada operacional que conecta ativos digitais, como dados e modelos, às entidades do mundo real que eles representam.

Objetos, propriedades e relações descrevem a organização. Tipos de ação e funções permitem alterar seu estado, com controles de acesso e governança. Recuperar o texto de um contrato pode ser uma etapa da análise. Confirmar sua vigência, aplicar a regra correta e autorizar a execução exigem capacidades adicionais do sistema.

Considere um exemplo hipotético de compras. A organização pode estruturar o processo assim:

Se o fornecedor estiver bloqueado, uma justificativa convincente não libera a compra. Se o valor mudar, a aprovação precisa ser revalidada. Se o registro não for confirmado, o sistema precisa conferir o estado antes de tentar novamente e arriscar uma duplicação.

Essas condições precisam ser verificadas pelo software que controla a ação. Escrevê-las no prompt ajuda a orientar o modelo, mas não substitui validação no serviço responsável pela compra.

A Ontologia Operacional FSTech é uma metodologia de estruturação e implementação, distinta da tecnologia Palantir Ontology. A aproximação técnica discutida aqui não implica parceria comercial nem equivalência de produtos, escala ou capacidades.

Novartis: contexto versionado e tarefas com limites claros

Em 2:12:31–2:13:48, Douglas Applegate, da Novartis, explica que harmonizar dados de estudos clínicos não elimina o trabalho de compreender o desenho e as particularidades de cada estudo. A eficácia do agente depende do conhecimento que especialistas prepararam para orientar a análise.

Na apresentação de um protótipo com Fractals, ele descreve contexto de conhecimento curado e versionado. Em 2:18:03–2:20:33, mostra a decomposição da investigação em sessões de agentes com entradas e saídas delimitadas. Verificações acompanham as etapas, e a revisão de um especialista pode revelar a necessidade de um novo controle.

É uma aplicação de engenharia de software a tarefas executadas por agentes: decompor o problema, definir expectativas e registrar o que precisa ser corrigido. O protótipo apresentado não demonstra, por si só, eficácia clínica ou redução no prazo de desenvolvimento de medicamentos.

A contribuição da FSTech: conhecimento que pode ser retomado

No framework público da FSTech, o protocolo Pin/Spec organiza o contexto de trabalho dos agentes. O Pin registra as condições que devem ser preservadas e os limites de atuação. O Spec registra o objetivo e o estado atual. A passagem de contexto entre sessões, chamada de handoff, e o registro das mudanças, ou write-back, permitem retomar o trabalho.

Esses artefatos ajudam a distinguir uma sugestão de uma decisão aprovada, ou uma implementação de um resultado aceito pelo responsável. Restringir quem pode executar uma ação e evitar registros duplicados continuam dependendo de controles implementados nos serviços responsáveis.

O princípio comum aos exemplos é tornar o conhecimento necessário à tarefa acessível e verificável. Na proposta de trabalho da FSTech, o registro da correção deve indicar quando ela se aplica e quem a validou, para orientar a próxima execução.

O caso público da FSTech com a Broadcast, da Agência Estado, exemplifica a preservação de uma decisão humana no fluxo. O caso publicado descreve um painel de acesso restrito para as editorias Mercado Brasil e Internacional. O fluxo reúne fontes, documentos e conteúdo audiovisual, com seleção humana antes da Leitura IA. Ganhos de tempo ou qualidade precisam ser medidos no uso.

O caso apresentado pelo USA Today, entre 47:18 e 50:06, trata da distribuição ao leitor. Mike Reed descreve uma demonstração ilustrativa em que agentes selecionam e ordenam jornalismo já produzido, sem criar jornalismo com IA, e as interações retornam à ontologia para orientar a próxima seleção. O fluxo ajuda a examinar quem controla a seleção editorial, quais evidências a orientam e como o retorno será utilizado.

Soberania de IA precisa incluir a possibilidade de sair

A partir desses casos, propomos uma definição operacional: soberania de IA é a capacidade de decidir onde os dados são processados, controlar a lógica e as ações do sistema e preservar condições de continuidade quando um componente ou fornecedor muda.

Essa capacidade pode ser examinada antes da contratação:

• Processamento: quais dados saem do ambiente, para qual finalidade, com quais condições de retenção e acesso?
• Lógica: regras, exceções e critérios de avaliação estão documentados, versionados e sob controle de quem responde pelo negócio?
• Execução: é possível limitar permissões, interromper ações futuras e reconstruir o que ocorreu?
• Saída: dados, configurações e histórico podem ser exportados em formatos utilizáveis? A troca foi ensaiada ou apenas prometida?

Executar um modelo localmente pode atender a uma restrição de processamento, mas não resolve sozinho backup, permissões, manutenção e portabilidade. Usar uma API externa também não demonstra automaticamente perda de propriedade ou reutilização dos dados para treinamento. É necessário verificar o contrato e a configuração do serviço utilizado.

Além de preservar os artefatos de conhecimento, a substituição exige avaliar o novo modelo e, quando necessário, adaptar integrações.

O teste de soberania deve alcançar todos os fornecedores relevantes, inclusive quem implementa a camada operacional. A empresa precisa saber o que continuará acessível e utilizável se encerrar aquela relação.

Como testar essa tese na sua operação

A primeira entrega deve caber em um processo cujo responsável consiga reconhecer o resultado correto.

No exemplo de compras, podemos começar pela preparação da recomendação, mantendo a aprovação e o registro final com as pessoas responsáveis. O recorte permite verificar se os documentos necessários são encontrados, se a regra é aplicada e se a proposta chega com evidências suficientes para decidir. Cada rodada registra o aceite ou o pedido de correção dessa recomendação.

As recomendações revisadas ajudam a definir os critérios de avaliação. É preciso separar exemplos que não serão usados para ajustar o modelo, destinados ao teste de novas versões. Um modelo alternativo pode ser testado sem executar compras, para conferir quanto da estrutura permanece reutilizável. O desempenho precisa considerar a correção da recomendação e o respeito às permissões.

Na comparação com a rotina anterior, entram tempo até a decisão, correções exigidas e custo completo, incluindo revisão humana, novas tentativas, manutenção e infraestrutura. Desenvolvemos a dimensão econômica na análise anterior sobre IA operacional e Palantir.

Na FSTech, aplicamos Dados, Lógica e Ação para que as decisões registradas possam orientar o trabalho seguinte. O ensaio com outro modelo permite verificar quanto desse conhecimento permanece utilizável, sem depender apenas da promessa de um fornecedor.

Avalie um processo da sua operação

Que conhecimento precisa continuar sob controle da sua empresa quando um fornecedor de IA muda? Para examinar essa questão em um processo concreto, solicite um diagnóstico com a FSTech. Começamos pelo fluxo e pelo resultado que precisa ser demonstrado, para definir o que vale a pena implementar.

Fontes e leituras relacionadas

• Alex Karp, abertura da AIPCon 11. Fonte da tese inicial sobre alpha e camada de aplicação.
• AIPCon 11 September 2026: transmissão ampliada. Os links no corpo identificam os trechos da NVIDIA, da conversa técnica, da Novartis e do USA Today. As descrições se baseiam na transcrição fornecida; relatos e demonstrações não equivalem a uma avaliação independente.
• Palantir: Ontology building. Definição e componentes da Ontology na documentação oficial.
• FSTech: Ontologia Operacional. Página de referência do conceito na abordagem FSTech.
• FSTech: Pin/Spec Protocol v2. Contexto, limites, registro e continuidade entre sessões.
• FSTech: clientes e casos públicos. Fonte da descrição do caso Broadcast usada neste artigo.
• A economia da IA operacional no resultado da Palantir. Análise anterior sobre custo por resultado e limites da atribuição de desempenho financeiro à arquitetura.