Dados é pouco

Começo por uma cena que você talvez reconheça.

Uma empresa que fez a lição de casa decide levar a inteligência artificial a sério. E a lição foi feita: o datalake é maduro, os cadastros foram unificados, o catálogo documenta as colunas, a linhagem, as APIs. O piloto tampouco é trivial: um agente que analisa minutas de contrato contra as políticas da casa, aponta desvios e propõe redação corrigida. A equipe é boa e os testes vêm acima do esperado. Seis meses depois o projeto está parado mesmo assim, e o motivo não aparece em log nenhum: ninguém soube responder a três perguntas de fundamento. Como sabemos que a análise está certa? O que acontece quando está errada? Quem responde por ela?

A cena não é exceção; é o caso típico. Segundo a IDC, 88% das provas de conceito de IA nunca chegam à produção: de cada 33 POCs que uma empresa lança, quatro viram sistema em operação ^[1]. E quando se pergunta a quem constrói o que trava, a resposta número um não é custo, nem talento, nem integração: é qualidade. Na maior pesquisa com engenheiros de agentes feita até aqui (LangChain, 1.340 respondentes, fim de 2025), qualidade e confiabilidade lideram os bloqueadores com 32%, à frente de latência e segurança ^[2]; e os CIOs ouvidos pela a16z resumem o motivo com uma franqueza incomum: garantir a qualidade de agentes “não é exatamente fácil” ^[3]. Traduzo: as empresas construíram sistemas cujas respostas não sabem conferir. E se surpreendem com o resultado.

A escada de três degraus

Uma década atrás, o diagnóstico para qualquer fracasso digital era “organize os seus dados”, e o mercado obedeceu: datalakes, integrações, faxina de cadastros. Depois o diagnóstico subiu um tom: “documente os seus dados”, e o mercado obedeceu de novo. Catálogos, dicionários, especificações de API, linhagem de dados. Se você trabalha com isso, sabe que boa parte das empresas médias e grandes já cumpriu, razoavelmente, as duas etapas. É por isso que não vou lhe dizer que falta organizar dados; seria insultar o seu trabalho com um conselho de 2015.

O que vou dizer é mais incômodo: a escada tem um terceiro degrau, e é nele que o piloto morre. Organizar dados foi o primeiro; documentá-los foi o segundo; formalizar o conhecimento é o terceiro, e quase ninguém o subiu, porque até outro dia ele parecia luxo acadêmico.

A diferença entre o segundo e o terceiro degrau cabe numa frase: documentação descreve; formalização confere. O catálogo diz o que a coluna significa, o dicionário diz o que o campo contém, a especificação diz o que a API espera. Tudo prosa para humanos lerem. Nada disso é capaz do ato que a era dos modelos probabilísticos mais exige: recusar. Um catálogo de dados não sabe dizer não. E o problema inteiro trazido pelas LLMs, como veremos, se resume a ter, em cada ponto crítico, algo ou alguém que saiba dizer não.

O próprio mundo dos dados, aliás, já começou a inventar o terceiro degrau sem lhe dar esse nome. Data contracts, validação de schema, testes de pipeline; artefatos cuja única função é rejeitar o que chega errado. O instinto está certo. Falta reconhecer que isso não é uma feature de engenharia de dados; é o embrião de outra disciplina.

O que a documentação não contém

Porque pense no que a sua empresa realmente sabe, e compare com o que ela documentou.

Ela sabe que aquele cliente grande aceita atraso na entrega, mas não tolera surpresa no preço. Sabe que certo tipo de contrato exige uma cláusula que não está em template nenhum, porque um processo judicial de oito anos atrás ensinou a lição pelo método caro. Sabe qual desconto o vendedor dá sozinho, qual exige alçada e qual nunca, ainda que o sistema permita. Em que catálogo está isso? Em nenhum. Documentou-se o dado; não se formalizou a regra, a exceção, o limite, o significado. Michael Polanyi deu nome a esse resíduo há sessenta anos: conhecimento tácito, resumido na fórmula que todo gestor deveria ter na parede: sabemos mais do que conseguimos dizer ^[4]. Os dados, mesmo impecavelmente documentados, registram o que aconteceu; o conhecimento diz o que as coisas significam, como se relacionam e o que fazer a respeito.

Até outro dia, essa lacuna não doía: havia sempre um humano no circuito preenchendo-a com bom senso. A IA generativa acaba com a folga.

O sofista perfeito

Modelos de linguagem são uma conquista técnica extraordinária; nada aqui é ceticismo de torcida contra. Mas duas características precisam ser ditas sem eufemismo, porque nenhuma versão nova as elimina. Quem as omite não está simplificando; está vendendo.

Primeira: o indeterminismo é constitutivo, não é bug. Uma LLM é uma máquina probabilística; a mesma pergunta pode produzir respostas diferentes. Esperar “o modelo que não erra” é estratégia de quem não entendeu o instrumento que comprou.

Segunda, e mais grave: o erro vem impecavelmente escrito. O defeito específico da LLM não é errar; máquinas e pessoas erram. É que a fluência se descolou da verdade: o texto errado sai com a mesma sintaxe elegante, a mesma segurança de tom, a mesma formatação profissional do texto certo. Platão conheceu esse personagem há vinte e quatro séculos. No Górgias, o retórico se gaba de ser mais persuasivo que o médico, diante da multidão, em assuntos de medicina, sem saber medicina ^[5]; a persuasão como perícia autônoma, desacoplada do conhecimento. A LLM é o sofista perfeito: fala com autoridade sobre qualquer coisa, e a autoridade do tom não tem nenhuma relação interna com a verdade do conteúdo. E Borges, como de costume, chegou antes ao resto: em “Tlön, Uqbar, Orbis Tertius”, um verbete de enciclopédia sobre um país que não existe é formalmente indistinguível da erudição verdadeira; e a coerência da invenção é tão sedutora que a realidade vai cedendo a ela. “La realidad cedió en más de un punto. Lo cierto es que anhelaba ceder” ^[6]: a realidade cedeu porque ansiava ceder. A citação alucinada que o modelo fabrica, com autor plausível, revista plausível e ano plausível, é um verbete de Tlön; e a empresa que a aceita sem conferir é a realidade ansiando por ceder.

Junte as duas características. Um sistema que erra de forma imprevisível, escrevendo o erro com perfeição persuasiva, é inutilizável sem uma contraparte que confira. E note o que a LLM não pode oferecer por construção: julgamento. Julgar é responder pela resposta: nome, cargo, consequência. Responsabilidade não é uma função que se otimiza; é um lugar que se ocupa. Não há ninguém dentro do modelo. “Foi a IA” não é defesa; é confissão de que se automatizou justamente o que não se transfere.

A boa notícia, para quem subir o degrau

Nós sabemos conviver com instrumentos que erram; a engenharia não faz outra coisa há séculos. Não se exige do instrumento a infalibilidade: cerca-se o instrumento de verificação. A pergunta certa nunca foi “quando o modelo vai parar de errar?”. É outra: o que, no meu processo, me permite saber se esta resposta está certa, e a que custo?

Onde existe regra clara (um preço, um prazo, uma cláusula obrigatória), a verificação pode ser automática e barata; regras enumeráveis pertencem a código, que é determinístico e auditável, não ao modelo. Onde a leitura exige contexto e juízo, a hipótese do modelo passa por quem pode ratificá-la. E onde nem isso é possível, descobre-se algo igualmente valioso: o que não se delega.

Mas repare no pré-requisito: para conferir, é preciso ter contra o quê. As regras precisam estar explícitas; o vocabulário, compartilhado; o “sempre fizemos assim” precisa virar critério checável. É o terceiro degrau da escada. Quando esse trabalho é feito, o resultado tem um nome técnico que assusta mais do que deveria: ontologia. Não a da metafísica, embora a genealogia seja essa; uma ontologia empresarial é algo quase prosaico: o acordo explícito sobre quais entidades existem no seu negócio, como se chamam, como se relacionam e que regras as governam ^[7]. É a diferença entre “temos os dados dos contratos, documentados” e “sabemos o que é um contrato para nós, o que cada tipo exige, e uma máquina consegue conferir se esta minuta cumpre”.

Por isso a oportunidade que a IA abre não é primariamente tecnológica; é tripla. Tecnológica, claro: sistemas que combinam a flexibilidade dos modelos com a confiabilidade de regras explícitas e verificadores. Metodológica: redesenhar processos perguntando, etapa por etapa, o que é regra, o que é interpretação, o que exige um humano responsável. E cultural, a mais difícil: instalar o hábito de explicitar o que se sabe; tratar o conhecimento da casa como ativo que se constrói e se revisa, e não como folclore que mora em meia dúzia de cabeças e sai pela porta com elas.

Por que “contínuo”

O nome da série é um paralelo deliberado com a engenharia de software. Houve um tempo em que integrar software era um evento: trimestral, traumático, cerimonioso. A integração contínua transformou o evento em prática diária, em pedaços pequenos, com verificação a cada passo.

Defendo a mesma virada para o conhecimento. “Fizemos nossa ontologia em 2026” é frase tão absurda quanto “fizemos nossa integração em 2019”. O negócio muda; as exceções de ontem viram as regras de amanhã. O que se constrói é o processo permanente: capturar, explicitar, estruturar, revisar. E quem o constrói não fica apenas “pronto para a IA”; fica melhor em tudo, porque decide melhor, treina melhor e depende menos da memória heroica dos veteranos.

O que vem por aí

A série terá três movimentos. No primeiro, as lacunas: o indeterminismo por dentro, com o desfile das mitigações que a indústria foi inventando e o que elas confessam; a distinção entre decidir, interpretar e responder; e a lacuna em escala organizacional, quando todo mundo produz mais do que nunca e ninguém sabe quem conferiu o quê. No segundo, formalizar: conhecimento tácito e explícito; o que é uma ontologia empresarial na prática; quem a escreve, com que papéis e rituais; e o que o uso da IA faz com a competência de quem a usa. No terceiro, delegar: por que copiar o organograma para os agentes é o erro de arquitetura mais comum; por que autonomia se conquista com evidência, e o que os agentes que nunca desligam carregam consigo; de quem deve ser o conhecimento formalizado; e, ao final, o retrato da empresa que emerge disso tudo.

Um ensaio a cada duas semanas, em português e em inglês; quando eu especular, direi que estou especulando.

Termino como todos os ensaios desta série terminarão: com uma pergunta em dois tempos. Escolha um processo importante da sua empresa e pergunte: quanto do que faz esse processo funcionar está escrito em algum lugar? E, do que está escrito, quanto uma máquina conseguiria usar para dizer não?

Conhecimento Contínuo é uma série do Life After AI.