What is AI knowledge management?

AI knowledge management captures what an organization knows, keeps it current, and answers questions from it with the sources attached.

Knowledge management itself is old. IBM’s explainer defines it as “the process of identifying, organizing, storing and disseminating information within an organization.” What AI changes is the work in the middle. Records no longer have to be rewritten as articles before anyone can find them, and one question can be answered across many systems at once.

It differs from two neighbors. A classic knowledge base holds the articles someone wrote and keeps up. Enterprise search finds records across systems and returns a ranked list, as What is enterprise search? explains. AI knowledge management adds an answer on top of that search, and a loop that writes new knowledge back.

Most of it was never written as knowledge. It sits in a closed ticket that says what fixed a fault, and in a field report from a site visit. It sits in revision notes on drawings, in supplier notices, and in the email where an engineer explained why a design changed.

IBM separates explicit knowledge, already in documents, from tacit knowledge, learned by experience and hard to put into words. Between them is what people know how to do and have not written down yet. A classic knowledge base needs someone to turn all of it into articles. An AI system can start from the records as they are. It reads the ticket, the log and the thread, and links them to the part or project they are about.

• Connect. Read the systems where knowledge already lives: document stores, wikis, ticket systems, email and chat, project archives. Each record stays in the system that owns it, along with who may open it.
• Organize. Read the text, scans included, and link each record to the things it mentions: a part, a customer, a project, a person. A knowledge graph holds those links, as What is a knowledge graph? explains. What is intelligent document processing? covers the reading.
• Find. Search as the person who asked, then write an answer from the records found, each one cited.
• Capture. When the answer is not there, the person who works it out writes it down while solving the problem. It goes next to the ticket or the part it is about.
• Maintain. Mark what is superseded, merge duplicates, and fix what reuse shows to be wrong.

The last two steps come from service desks. Knowledge-Centered Service, a method the Consortium for Service Innovation publishes, puts it in one line: “Knowledge is the by-product of interaction.” Its rule for upkeep is that reuse is review. Each person who uses an article checks it, and fixes or flags what is wrong.

In an organization that has run for decades, the answer to most questions has been written down somewhere. The cost is in finding it. An engineer who cannot find a closed ticket opens a new investigation. A new joiner interrupts the one colleague who remembers. When that colleague retires, the reasons behind a design decision leave with them.

An assistant also changes what people expect. A list of twelve documents asks the reader to do the work. An answer with three citations does the reading for them. So whether that answer is right, current and allowed matters more than it did for a list.

Stale content. An assistant answers from what it finds. If the 2019 revision of a procedure and the 2024 one are both indexed, it may quote the old one. IBM notes that wikis, easy to edit, also collect wrong and outdated entries. A record needs a status the system can read, and a superseded record has to say what replaced it.

Permissions. An assistant over every system can read far more than any one person may. Access has to be checked per record before anything is ranked or read by a model, as What is permission-aware retrieval? explains. Syncing permissions from the source also syncs its mistakes: a folder shared with everyone years ago becomes easy to find.

Answers without sources. A fluent answer with no record behind it is hard to check and easy to trust. NIST’s profile for generative AI warns that output can include “confabulated logic or citations that purport to justify or explain the system’s answer.” A citation has to open the record it names, at the place that says it.

Knowledge that never gets written down. If capture is a separate task after the work, it rarely happens. The answer stays in one inbox and leaves with its owner.

Near duplicates. The same procedure sits in three folders, each slightly different. An answer built from two of them can mix revisions without saying so.

Test it with questions your people actually ask, signed in as them.

• Collect a few dozen real questions from tickets and team chats. Have the people who know mark the records that answer each one.
• Check every citation. Does it open the record, and does the record say what the answer claims?
• Ask about something that changed. Does the answer use the current revision, and say when there are several?
• Ask as two people with different access, and compare the records each answer cites.
• Ask something the archive does not hold. The right answer says so.
• Follow one new answer through capture: who writes it, who checks it, and when the next person can find it.

Knowledge management is one of the use cases Curiosity Studio is built for. Connectors bring documents, wikis and intranets, email and chat, and project archives from more than 70 systems into one typed graph. Each record stays in the system that owns it. Access is synced from the source systems and checked per record at query time, so a person only sees what the source would show them.

A question across everything connected is answered with the record it came from: see search for developers. When a question keeps coming back, a team can describe a tool for it in Studio instead of answering it by email every quarter. A system with no built in connector, such as a SQL database, needs a connector you write with the connector SDK.

At Airbus Customer Services, the knowledge sat in CRM systems, network drives and engineering databases covering more than forty years of history. The Airbus story describes how Curiosity connected those sources, extracted the engineering references in the documents and linked them in a knowledge graph.