The biggest obstacle to AI isn't AI. It's knowledge.

At a recent industry presentation, the chief scientific officer of a European nuclear technology company named a challenge that had nothing to do with reactors. His concern was documentation: how do you make sure technical knowledge is captured properly and, just as importantly, can still be found when someone needs it. He raised artificial intelligence in the same breath. That pairing stayed with me, because it inverts the conversation most engineering leaders are having right now.

The question in most boardrooms is how do we use AI. The more useful question is whether our knowledge is in a state that AI, or anyone else, can actually use. If you lead engineering, innovation, or documentation at a technical company, that second question is the one that decides whether the first one pays off. I have written before about AI in technical writing, and the same principle runs through everything here: the tool is never the constraint; the knowledge is.

The problem is rarely a shortage of information

Most technical organisations do not suffer from a lack of documentation. They suffer from the opposite. Thousands of documents sit across SharePoint sites, network drives, PDFs, reports, specifications, supplier files, and email threads. The design decision exists. The test result exists. The safety analysis exists. The maintenance procedure exists. Somewhere.

I have worked with manufacturers who could not produce a current version of their own user instructions during a tender, not because the document was never written, but because nobody could say which of the four files on the shared drive was the live one. The information was not missing. It was scattered. And scattered knowledge behaves, in practice, like knowledge you never had.

When information cannot be found, it does not exist

An engineer looking for a design rationale, a test report, or a residual-risk assessment is working against a deadline. If the answer takes an afternoon to locate, the rational response is to redo the work or make a fresh assumption. That is how you get duplicated effort, delayed projects, and quiet inconsistencies between what the documentation says and what the product actually does.

The cost is not abstract. It is engineering hours spent searching instead of designing, decisions remade because the original reasoning was lost, and institutional memory that walks out of the door when an experienced colleague retires. The IAEA made this point about nuclear plants decades ago in its guidance on procedure development, TECDOC-1058: knowledge held in people's heads rather than in controlled documents is a structural vulnerability, not a staffing inconvenience. The observation transfers cleanly to any company building complex products.

Why the problem keeps getting worse

Three forces are compounding. The workforce is ageing, and the engineers who hold the undocumented context are retiring. Regulation is getting denser, so there is more to capture and more to prove. And the volume of information produced per project keeps climbing. Knowledge is accumulating faster than our ability to retrieve it, and the gap widens every year it goes unaddressed.

Why AI suddenly changes the picture

Here is what makes this moment different. Traditional search looks for words. You ask it for document X and it matches a filename or a string. AI can search for meaning. Instead of hunting for a file, an engineer can ask why a particular sealing method was chosen on the 2021 variant and get an answer drawn from across the archive.

That is a real shift, and I am genuinely enthusiastic about it. Retrieval-augmented generation, the technique behind most credible enterprise AI tools, lets a model answer from your own documents rather than from the open internet. Used well, it turns a decade of scattered files into something closer to an institutional memory you can interrogate in plain language.

But AI inherits your knowledge problem

AI can only work with the knowledge it can reach. Point it at a clean, structured, well-labelled body of documentation and it performs. Point it at the same scattered PDFs, conflicting Word files, and undated email attachments your engineers already struggle with, and it becomes a faster way to surface the wrong answer with total confidence. The principle is old and unforgiving: garbage in, garbage out. Retrieval-augmented generation does not repair a weak knowledge base, it amplifies whatever is already there, including the contradictions. The people who run these systems in production say the same thing: a RAG system is only as strong as the information it retrieves, which is why data governance is treated as foundational, not optional.

This is where my standing position on AI applies. The capability is real. The judgement still has to be human. An AI assistant that cannot tell a superseded procedure from the current one is not a documentation system, it is a liability waiting for an audit.

The real question is not how do we use AI

So the question worth asking is not how to deploy a chatbot. It is how to organise knowledge so that people and machines can both use it. That is a question about structure, metadata, the relationships between documents, and content management. It is about whether a document knows what it is, which product variant it belongs to, and whether it has been superseded. None of that is a prompt-engineering problem.

This is familiar territory for anyone who has worked to a real documentation standard. EN IEC/IEEE 82079-1, the international standard for instructions for use, already requires information to be structured so that users can find what they need at the point of need, rather than reading a manual end to end. Structured, modular approaches such as S1000D go further, breaking documentation into discrete, classified, reusable data modules. These methods were designed for human findability. They happen to be exactly what an AI system needs as well.

What this means for technical documentation

I think the role of technical documentation shifts over the next few years. Today most companies treat documentation as an output: you finish the product, then you produce the manual. The more durable view is that documentation is infrastructure. It is the organised, trusted knowledge layer on which manuals, training, support systems, and AI tools are all built.

That reframing has a sharp edge. The accumulation of unstructured, outdated, and unfindable files is a real liability, what we call documentation debt, and AI does not erase it. AI raises the return on having paid it down. The companies that will get the most from AI are not the ones with the cleverest tools. They are the ones whose knowledge is already organised so it can be found, trusted, and reused.

The knowledge layer comes first

So the biggest AI challenge in an engineering business may not be building a clever assistant. It may be making sure the knowledge that assistant depends on can still be found in ten years. That is a knowledge problem, not an AI problem, and it is solvable now.

Solve the knowledge layer first, and the AI question answers itself.

CONTACT US