The bot answered the password-reset question exactly as the knowledge base instructed it to. The instructions described a self-service portal the company had retired six months earlier. Until the bot went live, service desk agents had been correcting the article from memory. The model was not hallucinating. It was quoting you.
When a support bot gives a bad answer, the immediate instinct is to blame the large language model. If you check the retrieval logs, the model usually did exactly what it was supposed to do. It found a deprecated runbook from 2018 that someone left in a public SharePoint folder, and it summarized it. Generative AI does not fix a broken knowledge base. It weaponizes it. It is a flawless machine for executing bad documentation at scale.
Human service desk agents survive a bad knowledge base through tribal knowledge. They know to ignore the official VPN troubleshooting guide because the night shift supervisor told them the real fix in a chat message. They know to skip step four of the printer installation because step four was removed in a patch three years ago. The bot lacks that instinct. It only reads the dead documents. Every unarchived draft from an abandoned migration is now a loaded gun.
Retrieval mechanisms expose the flaws in how articles are written. Vector search pulls chunks of text based on semantic similarity. If a deprecated Windows 7 troubleshooting guide is longer and contains more keyword overlap with a user’s problem than a brief, accurate Windows 11 guide, the search ranks the deprecated guide higher. When a user asks how to reset a mobile token, the system retrieves the top results. If those results include instructions for three different authenticator apps the company has used over the last decade, the model often synthesizes them into a single, physically impossible hybrid procedure.
Chunking changes the writing requirement. A technician reading a full page notices the warning under the exceptions section at the bottom. A bot retrieves a short passage containing the procedure and drops the warning. A successful retrieval can still produce a bad answer.
Vendors sell these tools as a six-week implementation. Four weeks to establish the API connections to the ITSM platform, two weeks for testing. They assume your existing knowledge base is ready to go. The project stalls in month three when you realize you have to pause the deployment to manually review, rewrite, or delete 15,000 articles. The bot license is a linear cost. Content remediation is a massive step function. You budgeted for an API integration, but you are going to pay for a technical writing team. The actual cost of the project becomes two contractors for nine months, a portion of the senior engineer’s time, and a project manager who was supposed to be done in the second quarter and is still working in the fourth. The software license ends up being the cheapest line item.
At the project kickoff, someone asks who owns the knowledge base. The service desk manager looks at the application owners. The application owners look at the CIO. The knowledge base was never a deliverable. It was an assumption. The bot turns it into a deliverable retroactively. There is no such thing as a content problem. There is only an ownership problem. Someone has to have the authority to say an article is wrong and have it stick. That is usually not the person who writes the articles. It is the person who can allocate time to fix them. If the knowledge base is owned by nobody, the bot will be owned by whoever complains the loudest.
The steering committee will ask if you can just filter the ingestion by the last-updated date. Recency does not equal accuracy. A foundational guide to mapping a network drive might not have been updated since 2020 because it has not changed, while a rushed remote-work policy uploaded last Tuesday is already wrong. They will ask if the vendor’s professional services team can clean it up. The vendor will sell you a block of hours to write exclusion scripts and filter out folders containing the word archive. They do not know your business processes, and they cannot tell you which of your two concurrent mobile device policies is the real one. They will suggest letting users downvote bad answers. Downvoting tells the model the interaction was poor, but it does not delete the source document. The bot will just retrieve a different bad document next time. A human still has to go into the system and retire the article.
You do not need to rewrite everything before go-live. Triage first. Fix the articles that answer the highest-volume questions. Accept that the long tail will take a year. Restrict the bot’s access to a vetted folder if you have to, even if it drops your projected deflection rate from thirty percent to one percent for the first month. The success metric for the first three months of an AI deployment is not ticket deflection. It is the number of legacy articles you successfully retire.
The content project continues after launch. Every platform change can alter an answer the bot gives, even when nobody touches the bot. If a system changes, the article changes. If that is not a gate in your change management process, it will not happen. Documentation debt compounds faster than technical debt because nobody tracks the interest. The bot did not create your content problem. It just made it impossible to ignore. You can automate the retrieval, but you still need a human with the authority to say an article is wrong.