Can we maintain an AI assistant's knowledge base ourselves after launch?
Yes—but self-service maintenance must be designed and included in the project scope. A usable handover needs a knowledge operations console, role-based permissions, review and publishing, version rollback, and a way to verify that a change is active. A file-upload button alone is not safe maintenance.
Prices, policies, manuals, and internal procedures all change after launch. A system that needs a developer for every wording update will quickly become stale. Yet allowing any upload to take effect immediately can expose old prices, unpublished policy, or hostile content. The sound division is for business teams to operate day-to-day content while technical teams maintain parsers, integrations, retrieval, and the platform itself.
When defining model, data, and production boundaries, also compare How do you build an order-OCR workflow that people can trust? and How do you build a reliable enterprise AI knowledge base?; the linked guidance adds context that should be considered in the same decision.
| Content | Business users should control | Publishing safeguard | Technical change remains necessary when… |
|---|---|---|---|
| Approved Q&A and scripts | Create, edit, retire, and scope | Draft, review, schedule, rollback | Answer logic or presentation changes |
| Word, PDF, and web sources | Upload, replace, name owner and validity | Parse preview, duplicate check, sample test | Scans, complex tables, or parsing fail |
| Product and price records | Import tables or synchronize a system | Field validation, diff preview, approval | A source or field mapping changes |
| Live order and stock data | Manage authorization boundaries | Read at query time, not into static knowledge | APIs, authentication, or actions change |
“Upload and answer instantly” should not be the default. Show the extracted text, heading hierarchy, tables, and attachments; expose indexing state, failure reason, and activation time. After publication, run a small set of predefined questions to confirm that the new version is retrieved and the retired version no longer appears.
Permissions should follow information risk, not merely admin-menu access. Editors maintain drafts, content owners decide business wording, reviewers approve external release, and administrators manage users and sources. Public support material, dealer policy, and internal procedures belong in separate knowledge spaces, filtered by identity before retrieval. Prompting a model not to disclose material it has already seen is not access control.
Every knowledge item should record its source, product or regional scope, owner, effective and expiry dates, author, reviewer, change reason, and version. The W3C PROV-O recommendation offers a formal way to express relationships among entities, activities, and responsible parties; a project need not adopt that ontology, but must answer who produced the current content, when, and from what evidence. ISO 30401:2018 likewise treats knowledge management as an operating system requiring maintenance, review, and improvement, not a one-time import.
Acceptance should be performed by the client's operator, not demonstrated only by developers. The operator uploads a revision, checks parsing, submits it for review, publishes, tests expected answers, identifies a fault, and rolls back. An unauthorized account must fail to preview or publish. Also export the source files, knowledge register, and version history to prove that the client can take its content assets elsewhere.
The contract should state the support boundary. Clients can own content, validity periods, and routine answer tests; parser upgrades, new sources, permission-model changes, retrieval algorithms, and console features are technical changes. Managed content operations may be an optional service, never the only way a normally functioning system can be updated. Wavesteam cannot claim universal self-service from this article alone—the project SOW, tested console, and handover list are the controlling evidence.