A fatura de tokens é a parte mais visível do custo da inteligência artificial. A parte decisiva quase nunca aparece nela: quanto controle sua empresa preserva sobre dados, regras, memória, modelos e ações quando a IA entra na operação.

Em uma entrevista à CNBC publicada em 1º de julho de 2026, Alex Karp, CEO da Palantir, afirmou que algo havia dado "completamente errado" na forma como a IA vinha sendo vendida às empresas. O diagnóstico dele foi agressivo: organizações pagariam por tokens sem capturar valor e ainda correriam o risco de transferir seu alpha, termo que ele usa para a vantagem competitiva e a lógica proprietária do negócio, para fornecedores externos.

Karp tem interesse comercial evidente nessa tese. A Palantir vende justamente a camada que ele apresenta como solução. Esse interesse exige separar a retórica comercial, as condições reais dos contratos e as dependências técnicas que permanecem.

Quando sua empresa adota IA, qual parte da inteligência operacional continua sob seu controle? Aqui, controlar um modelo significa principalmente poder escolhê-lo, avaliá-lo e substituí-lo. Não exige necessariamente possuir seus arquivos internos ou hospedá-lo.

Modelo, Camada Operacional e Compute

No trecho mais útil da entrevista, Karp resume a arquitetura em três componentes:

"It's the model plus an application layer plus compute. It is really all three."

Em português: o sistema precisa do modelo, de uma camada de aplicação e da infraestrutura que executa ambos. O modelo interpreta contexto e gera respostas. A camada operacional conecta essas respostas à realidade da organização. A infraestrutura computacional define onde e como o sistema é executado.

Considere uma cobrança. Antes de agir, o sistema precisa saber qual cliente está envolvido, qual contrato está vigente, se existe pagamento anterior, quem pode aprovar uma exceção e qual ação é permitida. Na documentação oficial da Palantir, a Ontology é a camada operacional que conecta esses objetos do mundo real aos dados, às regras, às funções, às ações e aos controles de segurança.

A FSTech expressa essa camada como Dados, Lógica e Ação:

  • Dados: qual é o estado verificável da operação.
  • Lógica: quais regras transformam esse estado em decisão.
  • Ação: o que o sistema pode executar, com quais limites e autorização.

Sem essa estrutura, o modelo pode produzir uma resposta plausível sem saber se ela respeita o contrato, o estado atual, a alçada do operador ou o risco de uma ação externa.

Um caso real mostra a diferença. Em uma operação auditada pela FSTech, um painel administrativo omitia parte dos membros e sugeria que os cadastros não existiam. A consulta paginada encontrou 1.736 registros únicos, sem duplicação, e confirmou que os dados estavam corretos. A falha estava na visualização limitada ao primeiro bloco da API. Tratar o painel como fonte definitiva teria levado a uma mutação desnecessária de dados válidos.

Esse é o papel da camada operacional: preservar o estado verificável, expor a regra aplicada e impedir que uma interpretação provável vire ação irreversível sem evidência.

Onde a Crítica de Karp Acerta

A corrida por modelos criou uma ilusão recorrente: escolher o modelo mais poderoso resolveria a implantação. Uma demonstração pode impressionar sem provar que o sistema conhece o estado atual, respeita permissões ou executa com segurança. O caminho entre resposta convincente e operação confiável está justamente nas camadas que a demonstração costuma ocultar.

O modelo não carrega automaticamente:

  • o significado das entidades do seu negócio;
  • as exceções acumuladas pela operação;
  • as permissões de cada pessoa ou agente;
  • o histórico que precisa permanecer auditável;
  • os critérios que autorizam ou bloqueiam uma ação;
  • a responsabilidade quando a execução produz um efeito incorreto.

Também existe risco econômico. Se prompts, regras, avaliações, memória e integrações forem construídos dentro de um único fornecedor, trocar de modelo deixa de ser uma escolha técnica simples. A dependência pode estar no contrato, no formato dos dados, nas ferramentas proprietárias ou na forma como o processo inteiro foi desenhado.

Nesse ponto, Karp está correto: o modelo, isoladamente, raramente sustenta diferenciação durável quando seus concorrentes também podem comprá-lo. O alpha aparece quando conhecimento institucional vira artefato operável: dados específicos, regras, exceções, decisões, avaliações e memória versionada.

Onde a Crítica Exagera

A entrevista mistura riscos legítimos com generalizações que não se sustentam para todos os fornecedores e contratos.

Usar uma API comercial fechada não significa automaticamente entregar propriedade intelectual para treinamento. Treinamento, retenção, localização, acesso e exclusão são controles diferentes e precisam ser avaliados separadamente.

A OpenAI declara que dados de produtos empresariais e da API não são usados para treinar modelos por padrão. Os logs de monitoramento de abuso podem conter prompts e respostas e, por padrão, são retidos por até 30 dias. Já arquivos, ajustes personalizados, avaliações e outros estados persistentes seguem regras específicas por recurso e podem permanecer até exclusão. Zero Data Retention depende de aprovação e está disponível apenas para clientes e endpoints elegíveis.

A Anthropic declara nos termos comerciais que o cliente mantém os direitos sobre entradas, possui as saídas permitidas por lei e que a empresa não pode treinar modelos com o conteúdo comercial do cliente. Para a API padrão, a empresa informa exclusão de entradas e saídas em até 30 dias, com exceções para recursos persistentes, acordos específicos, aplicação da política de uso e obrigações legais. Feedback enviado voluntariamente pode ser retido por até cinco anos e usado para melhoria dos modelos.

Essas políticas demonstram por que a análise precisa ser específica. Produto para consumidor, ambiente empresarial, API, integração de terceiros e contrato sob medida podem ter condições diferentes.

Outras simplificações também precisam ser evitadas:

  • Possuir os parâmetros internos do modelo, os chamados pesos, não garante soberania. A empresa ainda pode depender da infraestrutura, da aplicação ou de formatos proprietários.
  • Modelo de pesos abertos não garante segurança. Configuração, acesso, observabilidade e proteção dos dados continuam necessários.
  • Ontologia não torna um sistema seguro sozinha. Permissões, isolamento, auditoria, validação e governança precisam existir e ser testados.
  • Trocar de modelo não é sempre gratuito. Modelos apresentam comportamentos, custos, limites de contexto e interfaces diferentes.

Uma contratação responsável exige clareza sobre o serviço, o estado que permanece sob controle da empresa e o plano de saída.

As Sete Perguntas Antes de Contratar IA

Karp formula uma sequência útil na entrevista: quem possui os dados, onde eles ficam em cache, se os prompts estão seguros e o que está sendo transferido ao fornecedor. Para uma decisão empresarial, essa sequência precisa ser ampliada.

1. Quem possui os dados enviados e os artefatos produzidos?

O contrato deve distinguir entradas, saídas, arquivos, representações vetoriais, modelos personalizados, feedback e logs. "Seus dados são seus" é insuficiente quando não define quais dados, sob quais condições e até quando.

Evidência a solicitar: cláusulas de propriedade, confidencialidade e exportação. Sinal de risco: o fornecedor não diferencia conteúdo do cliente de telemetria e artefatos derivados.

2. Onde prompts, contexto, respostas e logs ficam armazenados?

Treinamento e retenção são perguntas diferentes. Um fornecedor pode não treinar com seu conteúdo e ainda mantê-lo por um período operacional ou de segurança. Verifique prazo, região, subprocessadores, exceções legais e procedimentos de exclusão.

Evidência a solicitar: tabela de retenção por recurso, região de processamento e lista de empresas terceirizadas que processam dados. Sinal de risco: uma resposta genérica para produtos que armazenam estados diferentes.

3. O conteúdo pode ser usado para melhorar modelos?

A resposta precisa identificar o produto e a configuração. Políticas de API podem diferir de contas individuais. Botões de feedback, conectores e ferramentas externas também podem introduzir condições próprias.

Evidência a solicitar: política comercial vigente e configuração de opt-in ou feedback. Sinal de risco: a equipe avalia termos de uma conta individual para aprovar uma integração empresarial.

4. Podemos trocar de modelo sem reconstruir a operação?

Uma arquitetura saudável separa a capacidade do modelo da camada onde vivem estado, regras, memória e ações. A troca nunca será perfeita, mas não deveria exigir reescrever o negócio inteiro.

Evidência a solicitar: teste com um segundo modelo e inventário das dependências proprietárias. Sinal de risco: regras críticas existem apenas em ferramentas ou formatos que não podem ser exportados.

5. Onde vivem as regras proprietárias do negócio?

Se políticas, exceções e critérios estiverem espalhados por prompts privados de um fornecedor, a empresa reduz sua visibilidade sobre a própria lógica. Essas regras precisam ser versionáveis, auditáveis e compreensíveis fora do modelo.

Evidência a solicitar: repositório ou catálogo exportável das regras e suas versões. Sinal de risco: ninguém consegue explicar qual regra produziu uma decisão depois que o prompt muda.

6. Quem autoriza ações com efeito real?

Responder uma pergunta e alterar um contrato envolvem riscos diferentes. O sistema precisa distinguir leitura, recomendação, proposta de ação e execução. Quanto maior o impacto, mais rigorosa deve ser a autorização.

Evidência a solicitar: matriz de permissões, trilha de auditoria e teste de bloqueio sem autorização. Sinal de risco: o mesmo agente que recomenda também executa sem confirmação ou limite de escopo.

7. O que conseguimos levar se o contrato terminar amanhã?

Exporte não apenas documentos, mas também estado, regras, histórico de decisões, avaliações e trilhas de auditoria. Sem isso, a empresa pode manter seus dados brutos e perder a inteligência acumulada sobre como operá-los.

Evidência a solicitar: exportação real em formato reutilizável e procedimento de encerramento testado. Sinal de risco: o fornecedor promete portabilidade, mas nunca executou uma saída completa.

As perguntas formam um teste simples de D+L+A. Os dados precisam ser identificáveis e exportáveis. A lógica precisa permanecer versionada e auditável. As ações precisam respeitar permissões e produzir novos registros de estado. Se uma dessas camadas desaparecer com o fornecedor, o plano de saída está incompleto.

Soberania Não Exige Hospedar Tudo

Soberania operacional costuma ser confundida com isolamento total. Essa leitura leva empresas a manter modelos e infraestrutura que não possuem capacidade de operar com segurança.

Uma organização pode usar Claude, modelos da OpenAI, infraestrutura NVIDIA, modelos de pesos abertos ou uma combinação deles e continuar soberana. O critério é manter sua diferenciação em uma camada exportável, auditável e controlada pelo operador:

  • registro oficial e atualizado da operação;
  • regras e critérios proprietários;
  • memória institucional;
  • permissões e limites de ação;
  • testes que continuam válidos quando o modelo é trocado;
  • capacidade de migração e continuidade.

Para trocar de modelo sem descartar a operação, esses componentes precisam continuar existindo fora dele.

A Camada Que Permanece Quando o Modelo Muda

A discussão sobre soberania revela por que uma ontologia operacional tem valor. Ela mantém fora do modelo aquilo que a organização precisa possuir: objetos, relações, regras, eventos, decisões e ações autorizadas.

A camada operacional mantém os objetos, as evidências atuais, as regras e as autorizações usadas pelo modelo para interpretar e propor ações.

Isso também muda a forma de avaliar custo. O preço por token continua relevante, mas é apenas uma variável. A conta completa reúne três grupos:

  • Implantação e operação: integração, infraestrutura, monitoramento e manutenção.
  • Governança e segurança: retenção, proteção de dados, avaliações e erros não detectados.
  • Dependência e saída: migração, formatos proprietários, perda de lógica institucional e continuidade quando o fornecedor muda.

A escolha do modelo continua importante. Antes do contrato, porém, existe uma pergunta mais durável:

Qual parte da inteligência operacional continuará pertencendo à nossa organização quando esse modelo for substituído?

Sem uma resposta verificável, a arquitetura carrega um risco que a fatura não mostra.

Fontes

Políticas de dados mudam e podem variar por produto, configuração e contrato. Consulte a documentação vigente e revisão jurídica antes de contratar serviços para dados regulados ou sensíveis.

Aplicar D+L+A à arquitetura de IA