Ontologia Operacional: o Analista no Loop é o Que Sobra Quando a IA Executa Sozinha

A IA está absorvendo a execução. O que sobra não é uma tarefa menor para o humano. É a autoridade sobre o que o domínio considera verdadeiro, aceitável e acionável.

Durante anos, o pitch dominante foi confortável: a IA não substitui o profissional, ela aumenta o profissional. Isso ainda funciona como frase de apresentação. Mas descreve apenas uma fase intermediária da curva.

A execução está sendo comprimida.

Quando um modelo consegue operar por longos períodos, navegar por grandes bases de código, interpretar dependências, refatorar, testar, corrigir e seguir até uma entrega que antes tomaria semanas, a pergunta muda.

O centro da discussão deixa de ser quantas horas o profissional ganhou e passa a ser: quem ainda tem autoridade para decidir se o resultado é verdadeiro, aceitável e acionável dentro daquele domínio?

Esse é o papel real do analista no loop.

Não o revisor decorativo. Não o aprovador que clica em "sim" no final. O analista que detém autoridade de domínio.

E, se essa autoridade não está documentada, ela não é arquitetura. É conhecimento tácito na cabeça de três pessoas.

A curva que mudou a conversa

Dario Amodei já descreveu um deslocamento parecido no caso de programação: IA escrevendo grande parte do código, enquanto humanos ainda especificam condições, design, integração e segurança.

A lógica é simples: quando a IA absorve a maior parte da execução, o humano fica alavancado no restante. Isso parece ótimo. E é, por um tempo.

Mas existe um ponto em que a automação se aproxima de 100%.

Nesse ponto, a pergunta deixa de ser "como o humano opera melhor?" e vira "por que o humano ainda está operando?".

O lançamento do Claude Fable 5, anunciado pela Anthropic em 9 de junho de 2026, acelera essa conversa. Não porque um modelo específico resolva tudo. Esse não é o ponto. O ponto é estrutural: modelos estão ficando bons o suficiente para assumir blocos inteiros de execução genérica.

Segundo a própria Anthropic, em testes iniciais a Stripe relatou que Claude Fable 5 executou em um dia uma migração em uma base Ruby de 50 milhões de linhas que levaria mais de dois meses para uma equipe fazer manualmente.

Migração de código, refatoração em escala, tarefas longas por agentes, interpretação de gráficos e trabalho analítico já aparecem nas capacidades destacadas pela Anthropic. Tudo isso está se tornando infraestrutura.

Quando a execução vira infraestrutura, o diferencial migra.

Não para quem executa mais rápido. Para quem sabe o que deve ser considerado verdade.

Quando produtividade deixa de ser vantagem

A fase atual da IA ainda é vendida como aumento de produtividade.

Um operador com IA entrega mais. Um analista com IA processa mais. Um engenheiro com IA implementa mais. Um time com IA reduz backlog.

Isso é real, mas não é permanente como vantagem defensável.

Produtividade operacional deixa de ser diferencial quando qualquer organização pode usar modelos parecidos para executar as mesmas tarefas.

Se o valor de uma função está em executar tarefas bem especificadas, essa função está na zona de absorção. A IA primeiro aumenta. Depois comprime. Depois substitui o bloco inteiro.

A inversão é desconfortável:

Quanto mais produtivo o operador se torna em tarefas padronizadas, mais claramente a tarefa fica especificada para automação.

O que sobrevive não é a tarefa residual. O que sobrevive é a autoridade sobre o domínio:

• Isto conta como sessão realizada?
• Esta evidência é suficiente para faturar?
• Esta guia pode ser emitida?
• Esta exceção é aceitável?
• Este cliente está dentro da regra comercial?
• Esta saída da IA pode virar ação?
• Quem pode aprovar?
• Quem pode ver?
• Quem responde se der errado?

Essas perguntas não são execução. São autoridade operacional.

O que é o analista no loop?

O analista no loop não é um revisor genérico.

Ele é a fonte de autoridade sobre o que o domínio considera:

• verdadeiro;
• aceitável;
• acionável;
• seguro;
• auditável;
• reversível;
• proibido.

Essa distinção importa porque "humano no loop" virou uma expressão fraca. Em muitos sistemas, significa apenas que alguém precisa clicar em aprovar. Isso é teatro de compliance.

O analista no loop real tem três responsabilidades:

1. Definir verdade operacional: qual dado é confiável, qual fonte vence, qual exceção invalida o processo.
2. Definir limites de ação: o que pode ser automatizado, o que exige revisão, o que nunca deve ser executado sem confirmação.
3. Capturar decisão humana: transformar julgamento em regra, propriedade, exceção ou ação auditável.

Esse é também o ponto do PCWA, o problema do conhecimento prático que não está escrito: a IA não sabe o que não foi documentado. Ela pode inferir padrões, mas não conhece automaticamente o que uma operação considera legítimo. O analista sabe porque vive o domínio.

Mas, se esse conhecimento fica só na cabeça dele, a organização continua frágil.

A Ontologia Operacional existe para tirar essa autoridade do campo tácito e colocá-la em uma Spec executável.

O que é Ontologia Operacional?

Sem Ontologia Operacional, o analista no loop vira gargalo.

Com Ontologia Operacional, ele vira arquitetura.

A diferença está em tornar explícito o que antes era informal.

Exemplo simples:

Dado:
Sessão de terapia marcada para segunda-feira às 14h.

Lógica:
A sessão só pode ser faturada se houver status final,
psicóloga responsável, vínculo com guia válida e evidência suficiente.

Ação:
Secretária pode confirmar presença, anexar comprovante ou marcar ausência com motivo.
IA pode sugerir inconsistência, mas não emitir guia sem controle humano.

Isso é Dados, Lógica e Ação.

Dados sem Lógica viram cadastro morto. Lógica sem Ação vira relatório. Ação sem Ontologia Operacional vira risco.

A Ontologia Operacional conecta os três.

Ela transforma o conhecimento do analista em objetos, propriedades, links, funções e ações governadas. O sistema deixa de perguntar apenas "qual foi a saída?" e passa a perguntar:

• De onde veio?
• Qual regra validou?
• Qual objeto foi afetado?
• Quem pode agir?
• Qual ação é permitida?
• O que fica registrado?
• Como desfazemos se estiver errado?

Esse é o ponto em que o loop deixa de ser teatro e vira controle operacional.

Por que a vantagem defensável está no domínio, não na camada de IA

A camada de IA é importante: prompts, avaliações, roteamento, memória, ferramentas, agentes e contexto fazem diferença.

Mas essa camada é vantagem estreita em domínio genérico.

Se duas empresas usam modelos parecidos, frameworks parecidos e ferramentas parecidas, a vantagem não está em "ter um agente". Está em ter uma representação melhor do domínio.

A própria fronteira mostra isso.

No lançamento do Fable 5, a Anthropic explica que o modelo usa classificadores de segurança. Em certos temas sensíveis, como cibersegurança, biologia, química e destilação de modelos, a requisição pode ser roteada para Claude Opus 4.8 em vez de ser respondida pelo Fable 5. A empresa afirma que mais de 95% das sessões do Fable não envolvem fallback.

A leitura importante não é moral. Não depende de acreditar que a Anthropic é uma empresa moralmente confiável.

A leitura importante é arquitetural:

Quanto maior a capacidade do executor, mais importante se torna o ponto de controle de julgamento.

Esse ponto de controle não pode ser só um prompt dizendo "seja cuidadoso". Precisa estar no desenho da operação.

A Spec de domínio não se copia facilmente porque depende de decisões reais:

• como a empresa reconhece uma exceção;
• qual fonte vence em conflito;
• qual aprovação é necessária;
• qual risco é tolerável;
• qual dado é sensível;
• qual ação exige auditoria;
• qual processo nunca deve ser automatizado.

Isso é o que concorrentes não copiam com um repositório público ou com um modelo mais novo.

Eles podem copiar a interface. Podem copiar o prompt. Podem copiar a camada de IA.

Não copiam a autoridade de domínio codificada.

Na FSTech, a Ontologia Operacional é aplicada como método prático para mapear objetos, regras, permissões e ações auditáveis antes de conectar IA ao fluxo.

O que isso significa para sua operação?

A pergunta diagnóstica é simples:

Sua autoridade de domínio está documentada ou está na cabeça de três pessoas?

Se está na cabeça de três pessoas, sua operação não está pronta para IA autônoma. Ela está pronta para produzir decisões inconsistentes em velocidade maior.

Antes de automatizar, é preciso explicitar:

• quais são os objetos do negócio;
• quais propriedades importam;
• quais relações existem entre eles;
• quais regras definem validade;
• quais exceções exigem decisão humana;
• quais ações podem ser executadas;
• quem pode executar;
• como tudo fica auditável.

Esse é o trabalho da Ontologia Operacional.

Não é documentação por burocracia. É a camada que permite que IA execute sem destruir o critério de verdade do domínio.

Como começar sua primeira Ontologia Operacional

A forma prática de começar não é comprar mais uma ferramenta de IA.

É mapear sua primeira Ontologia Operacional:

1. Liste os objetos centrais da sua operação.
2. Separe referência, evento e exceção.
3. Defina quais propriedades tornam cada objeto confiável.
4. Nomeie os links entre objetos.
5. Transforme rotinas recorrentes em conjuntos operacionais.
6. Defina ações governadas, com permissão, validação e auditoria.
7. Só então conecte IA ao fluxo.

Para tornar isso aplicável, organizamos esse primeiro passo como Sua Primeira Ontologia Operacional.

A pergunta não é se sua empresa vai usar IA para executar mais.

A pergunta é se ela tem autoridade explícita para decidir o que deve ser executado.