Ask in any company where the returns procedure is, which is the latest version of the framework contract, or why they dropped a particular supplier last year. The answer is almost always a person's name, not a place. "Ask her, she knows."
That is what most companies' memory looks like: documents scattered across folders, in several versions, emails where decisions were made that nobody can find any more and, above all, people who know. It works as long as those people are around. When they are on holiday, things slow down. When they leave, part of the company leaves with them.
The problem is not new. What has changed is that there is now a reader that can use this memory at scale: AI. And that changes both its value and the risk of doing it badly.
Why now, and why not a wiki
Many companies have already tried to document what they know. An internal wiki, a "Procedures" folder, an onboarding manual. Most died the same way: written once, read by nobody, gone stale, and people went back to "ask her".
The reason was simple: asking a person was faster than searching a document. An AI assistant built on the company's knowledge reverses that. You ask in plain language and get an answer in seconds, with a reference to the document it came from. For the first time, documenting something is more useful than remembering it.
That is where the idea you see more and more under the name "company second brain" comes from: a company knowledge base organised so that both people and AI systems can use it. It is not a product you buy. It is a discipline: what you document, how you organise it, who is responsible for each part.
And it is the foundation of any AI process automation. An automatically generated quote is only right if the system knows today's prices. A generated contract is only right if the system knows which clauses the company uses now.
The most common mistake: connecting everything
Once a company decides to use AI on its own knowledge, the reflex is to connect everything: every folder in SharePoint or Google Drive, the whole email archive, everything there is. The logic seems sound. The more data, the better.
It doesn't work, for two reasons.
AI doesn't know what is current. A folder that has grown for years holds today's procedure, the one from three years ago and the draft that was never approved. To a language model they are all equally valid. The result is a system that quotes the rule in force and the abandoned one with the same confidence, and the person receiving the answer has no way to tell which is which.
AI sees what the user sees, and permissions are usually wrong. AI assistants built into the company's platform, such as Copilot in Microsoft 365, answer from everything the person asking can open. A sensitive document put in a folder open to everyone a few years ago was not a problem as long as nobody went looking for it. An assistant that searches on everyone's behalf finds it. That is not an AI problem. It is a permissions problem that existed before, and AI makes it visible.
Company memory is built deliberately, not obtained by connecting everything you have.
What goes into company memory
The starting point is not "what documents do we have" but "what questions do we get asked, and what does a system need to know to work correctly". The answer usually falls into a few categories:
- Procedures in force. How something is actually done, not what the manual said five years ago.
- Product and service offers. What we sell, with what features, at what price, with what discount rules.
- Approved templates and clauses. Framework contracts, annexes, standard terms, the wording legal has signed off.
- Decisions and their reasons. Not just "we work with supplier X", but why, since when and which alternatives were rejected. The reason is the part that gets lost first and is hardest to reconstruct.
- Recurring customer questions and the answers given. Including the edge cases someone solved once and everyone has since forgotten.
- Communication rules. Tone, wording to avoid, visual identity, how the company addresses its customers.
Just as important is what stays out: drafts, old versions (which go to the archive, kept separately), personal data that isn't needed, and any document nobody takes ownership of.
How to organise it
A knowledge base that works for AI does not look very different from one that works for people. The difference is that AI doesn't forgive the mess a person compensates for with experience.
A few rules make the difference:
Every document has an owner, a date and a status. Who is responsible for it, when it was last updated, whether it is in force or archived. Without these three pieces of information, neither a person nor a system can decide how far to trust it.
What is current is kept apart from the archive. The archive is not deleted. Sometimes it needs to be consulted. But it doesn't sit in the same place as what is in force, and it is not the default source for answers.
One source for each piece of information. The price list exists in exactly one place. If it also appears in a presentation, an email and a spreadsheet, at least one of them is wrong, and the system doesn't know which.
The structure follows the company's areas. Sales, operations, finance, HR, technical. That way responsibility and access line up naturally with the structure.
Who keeps it current
This is where most knowledge bases fail. Not when they are built, but in the months after.
The rule that works: each area has an owner, and every process change starts with changing the source. The returns policy changes? First the procedure in the company memory is updated, then the team is told. The other way round, the procedure falls behind and AI keeps answering with the old version.
An unexpected advantage of an assistant built on company memory is that it shows you where the gaps are. The questions it couldn't answer, or escalated to a person, are exactly the list of things that need documenting. Reviewed regularly, that list keeps the company memory alive without a separate documentation project.
Who has access to what
The same access rules that apply to people apply to systems. Sales doesn't see salaries. An assistant that answers customers doesn't see margins, other customers' contracts or internal discussions about them. An internal operations assistant doesn't need the financial data.
In practice, this means company memory is not a single block. It is organised by area, with role-based access, and each assistant or automation gets access only to the areas it needs. The tiered data classification we described in the article on bringing AI into your company without losing control of it applies directly here.
How it gets used
Once built, company memory works in several ways:
Answers with the source cited. A colleague asks what the procedure is for a situation and gets the answer together with the document it came from. They can check it. And if the answer is wrong, you fix the source, not the answer.
Escalation when it doesn't know. A good assistant says "I couldn't find that" and passes the question to the area owner instead of inventing a plausible answer.
Context for automations. Automatically generated quotes, contracts and reports take their prices, clauses and rules from the company memory. When the source changes, everything generated from it changes too.
Onboarding new people. A new employee no longer depends on who has time to explain things. They can ask anything, any time, and get the same answers experienced colleagues would have given.
How to start
Not with the whole company. With one area and one measurable problem.
The best starting point is usually the person who gets the most repeated questions. Their questions show exactly which knowledge is asked for most often and where it is missing from the documents. You build the memory for that area, put an assistant on top of it and measure: how many questions get answered without escalation, how much time the person who used to answer has won back, which gaps came to light.
Only when that area works and has an owner keeping it current do you move to the next one.
We compared the right tools, from a team assistant to a custom-built integration, in the article on AI process automation. Whatever the tool, the rule here stays the same: put the permissions in order before the assistant is connected to the company memory.
What we do
We start with an analysis of the existing knowledge sources: where they live, in how many versions, who is responsible for them and which questions get asked most often. Together we pick the first area, build the structure and the rules (owners, status, separation from the archive, role-based access), put the assistant on top and connect it to the automations that need it. Then we set the update rhythm, so the memory stays alive after the project has ended.
The details of how we work are on the AI consulting and process automation page. And if the answer you hear most often in your company is a person's name rather than a document, that is where to start.
