Data isn't enough

Let me start with a scene you may recognize.

A company that has done its homework decides to take artificial intelligence seriously. And the homework was done: the data lake is mature, the master records have been unified, the catalog documents the columns, the lineage, the APIs. The pilot is not trivial either: an agent that reviews draft contracts against the house policies, flags deviations and proposes corrected wording. The team is good and the tests come in above expectations. Six months later the project is stalled anyway, and the reason shows up in no log: nobody could answer three fundamental questions. How do we know the analysis is right? What happens when it is wrong? Who answers for it?

The scene is not the exception; it is the typical case. According to IDC, 88% of AI proofs of concept never reach production: of every 33 POCs a company launches, four become systems in operation ^[1]. And when you ask the people who build them what gets in the way, the number one answer is not cost, nor talent, nor integration: it is quality. In the largest survey of agent engineers to date (LangChain, 1,340 respondents, late 2025), quality and reliability lead the blockers at 32%, ahead of latency and security ^[2]; and the CIOs interviewed by a16z sum up the reason with unusual candor: quality assurance of agents “is not super easy” ^[3]. Let me translate: companies have built systems whose answers they do not know how to check. And they are surprised by the outcome.

The three-step ladder

A decade ago, the diagnosis for any digital failure was “organize your data”, and the market obeyed: data lakes, integrations, cleaning up the master records. Then the diagnosis went up a notch: “document your data”, and the market obeyed again. Catalogs, dictionaries, API specifications, data lineage. If you work in this field, you know that a good share of mid-sized and large companies has already completed, reasonably well, both stages. That is why I am not going to tell you that you still need to organize your data; it would insult your work with advice from 2015.

What I am going to say is more uncomfortable: the ladder has a third step, and that is where the pilot dies. Organizing data was the first; documenting it was the second; formalizing knowledge is the third, and almost nobody has climbed it, because until recently it looked like an academic luxury.

The difference between the second and the third step fits in one sentence: documentation describes; formalization checks. The catalog says what the column means, the dictionary says what the field contains, the specification says what the API expects. All of it prose for humans to read. None of it is capable of the act the era of probabilistic models demands most: refusing. A data catalog does not know how to say no. And the whole problem brought by LLMs, as we will see, comes down to having, at every critical point, something or someone who knows how to say no.

The data world itself, incidentally, has already started inventing the third step without giving it that name. Data contracts, schema validation, pipeline tests; artifacts whose only function is to reject what arrives wrong. The instinct is right. What is missing is recognizing that this is not a data engineering feature; it is the embryo of another discipline.

What documentation does not contain

Because think about what your company really knows, and compare it with what it has documented.

It knows that that big client accepts a late delivery but will not tolerate a surprise in the price. It knows that a certain type of contract requires a clause that is in no template, because a lawsuit eight years ago taught the lesson the expensive way. It knows which discount the salesperson grants alone, which requires sign-off and which never, even though the system allows it. In which catalog is that? In none. The data was documented; the rule, the exception, the limit, the meaning were not formalized. Michael Polanyi named this residue sixty years ago: tacit knowledge, summed up in the formula every manager should have on the wall: we can know more than we can tell ^[4]. Data, even impeccably documented, records what happened; knowledge says what things mean, how they relate, and what to do about them.

Until recently, that gap did not hurt: there was always a human in the loop filling it with common sense. Generative AI removes the slack.

The perfect sophist

Language models are an extraordinary technical achievement; nothing here is skepticism from the opposing stands. But two characteristics need to be stated without euphemism, because no new version eliminates them. Whoever omits them is not simplifying; they are selling.

First: indeterminism is constitutive, not a bug. An LLM is a probabilistic machine; the same question can produce different answers. Waiting for “the model that does not err” is the strategy of someone who has not understood the instrument they bought.

Second, and more serious: the error arrives impeccably written. The specific defect of the LLM is not that it errs; machines and people err. It is that fluency has come unglued from truth: the wrong text comes out with the same elegant syntax, the same confident tone, the same professional formatting as the right text. Plato met this character twenty-four centuries ago. In the Gorgias, the rhetorician boasts of being more persuasive than the physician, before the crowd, on matters of medicine, without knowing medicine ^[5]; persuasion as an autonomous skill, decoupled from knowledge. The LLM is the perfect sophist: it speaks with authority about anything, and the authority of the tone has no internal relation to the truth of the content. And Borges, as usual, got to the rest first: in “Tlön, Uqbar, Orbis Tertius”, an encyclopedia entry about a country that does not exist is formally indistinguishable from genuine erudition; and the coherence of the invention is so seductive that reality gradually yields to it. “La realidad cedió en más de un punto. Lo cierto es que anhelaba ceder” ^[6]: reality yielded because it longed to yield. The hallucinated citation the model fabricates, with a plausible author, a plausible journal and a plausible year, is an entry from Tlön; and the company that accepts it without checking is reality longing to yield.

Put the two characteristics together. A system that errs unpredictably, writing the error with persuasive perfection, is unusable without a counterpart that checks. And note what the LLM cannot offer by construction: judgment. To judge is to answer for the answer: name, role, consequence. Responsibility is not a function to be optimized; it is a place to be occupied. There is nobody inside the model. “It was the AI” is not a defense; it is a confession that what was automated was precisely what cannot be transferred.

The good news, for those who climb the step

We know how to live with instruments that err; engineering has done nothing else for centuries. Infallibility is not demanded of the instrument: the instrument is surrounded with verification. The right question was never “when will the model stop erring?”. It is another one: what, in my process, lets me know whether this answer is right, and at what cost?

Where there is a clear rule (a price, a deadline, a mandatory clause), verification can be automatic and cheap; enumerable rules belong in code, which is deterministic and auditable, not in the model. Where the reading requires context and judgment, the model's hypothesis passes through someone who can ratify it. And where not even that is possible, something equally valuable is discovered: what cannot be delegated.

But notice the prerequisite: to check, you need something to check against. The rules must be explicit; the vocabulary, shared; the “we have always done it this way” must become a verifiable criterion. That is the third step of the ladder. When that work is done, the result has a technical name that scares more than it should: ontology. Not the one from metaphysics, although that is its genealogy; an enterprise ontology is something almost prosaic: the explicit agreement about which entities exist in your business, what they are called, how they relate and which rules govern them ^[7]. It is the difference between “we have the contract data, documented” and “we know what a contract is for us, what each type requires, and a machine can check whether this draft complies”.

That is why the opportunity AI opens is not primarily technological; it is threefold. Technological, of course: systems that combine the flexibility of models with the reliability of explicit rules and verifiers. Methodological: redesigning processes by asking, step by step, what is a rule, what is interpretation, what requires a responsible human. And cultural, the hardest: installing the habit of making explicit what is known; treating the house's knowledge as an asset that is built and revised, not as folklore that lives in half a dozen heads and walks out the door with them.

Why “continuous”

The name of the series is a deliberate parallel with software engineering. There was a time when integrating software was an event: quarterly, traumatic, ceremonious. Continuous integration turned the event into a daily practice, in small pieces, with verification at every step.

I argue for the same turn for knowledge. “We did our ontology in 2026” is as absurd a sentence as “we did our integration in 2019”. The business changes; yesterday's exceptions become tomorrow's rules. What gets built is the permanent process: capture, make explicit, structure, revise. And whoever builds it does not merely become “ready for AI”; they become better at everything, because they decide better, train better and depend less on the heroic memory of veterans.

What comes next

The series will have three movements. In the first, the gaps: indeterminism from the inside, with the parade of mitigations the industry has been inventing and what they confess; the distinction between deciding, interpreting and answering; and the gap at organizational scale, when everyone produces more than ever and nobody knows who checked what. In the second, formalizing: tacit and explicit knowledge; what an enterprise ontology is in practice; who writes it, with which roles and rituals; and what the use of AI does to the competence of those who use it. In the third, delegating: why copying the org chart onto agents is the most common architectural mistake; why autonomy is earned with evidence, and what agents that never switch off carry with them; whose the formalized knowledge should be; and, at the end, the portrait of the company that emerges from all this.

One essay every two weeks, in Portuguese and in English; when I speculate, I will say that I am speculating.

I end the way every essay in this series will end: with a question in two parts. Pick an important process in your company and ask: how much of what makes that process work is written down somewhere? And, of what is written, how much could a machine use to say no?

Continuous Knowledge is a series by Life After AI.