Direct answer: An enterprise AI knowledge base is not "import the shared drive into a vector database". Before launch, define the content inventory, owner, permission/sensitivity level, version/validity, conflict/duplicate handling, deletion/archival and evaluation samples. Otherwise, stronger retrieval only means faster wrong answers to the wrong people. Governance acceptance is whether every answer can be traced to the correct document and permission—not how many documents were imported.
This report is for AI/RAG project owners, knowledge management, IT/security, legal/privacy, business experts and vendor management. It covers content governance and acceptance for an enterprise AI knowledge base. Information is current to 30 October 2026. It is public standards, governance frameworks and project method, not certification or a promise about any knowledge base, model, vendor, document or compliance; content permissions, personal information, trade secrets and contract requirements are governed by company policy, the standards, contracts and legal advice.
Knowledge-base quality is set by the content lifecycle, not the document count. Permissions/sensitive information must be layered before ingestion—not left to the model. Version, expiry, conflict, deletion and evaluation samples must be governed together; otherwise RAG just gives wrong answers faster.
Why does "import everything" fail?
A knowledge base is not a shared-drive mirror: expired policies, duplicate versions, unauthorised files, customer customisation and personal information together make retrieval faster at giving wrong answers. Govern content before models and chunking.
Many RAG projects start by "importing OA/shared drive/website/product documents", then after launch: answers cite a three-year-old policy, A customer's proposal is returned to B, internal pricing/personal information is retrieved, and two documents contradict each other. Models and vector databases are amplifiers; content governance is the source. Knowledge-base governance answers five questions: what should be included, who owns it, who can see it, when it expires, and how it is deleted/replaced.
| Common practice | Short-term appeal | Post-launch risk | Do first |
|---|---|---|---|
| Import the whole shared drive | Broad coverage, fast launch | Expired/duplicate/unauthorised content mixes in | Content inventory + admission rules |
| Import only "latest version" | Clean | Old versions remain elsewhere; no traceability | Version/validity fields |
| Let the model judge permissions | Less work | Prompt injection/privilege escalation/data leakage | Pre-ingestion ACL/metadata |
| Chunk only, no evaluation | Demo looks good | Cannot find expired/conflict/negative cases | Question-document-permission evaluation set |
| No cleanup after launch | Saves effort | Knowledge drift; old answers persist | Quarterly governance/deletion process |
Failure modes are editorial; content admission, permissions and deletion depend on company policy, systems and contracts.
How to build the content inventory?
Record source, owner, version, effective/expiry date, permission level, personal-information/trade-secret status, business criticality and system for each item. Content without an owner does not enter the knowledge base.
The content inventory is not a file list; it is the knowledge base's ledger. Classify by document/page/FAQ/ticket/product material/policy/contract template, and record: unique ID, source system, owner, version, effective date, review/expiry date, permission level, sensitive fields, business criticality, update method and deletion/archive status. Content without an owner or confirmed permission should not enter; customer-specific/project files should not enter the public knowledge base by default.
| Field | What to write | Evidence | If omitted |
|---|---|---|---|
| Unique ID/source | Document/page/ticket ID, system, URL/path | System export, link | Cannot trace/delete |
| Owner | Business/policy/product/HR/legal owner | Appointment/duties | No one handles expiry |
| Version/date | Version, effective, review/expiry date | Version record | Old versions mix in |
| Permission level | Public/internal/confidential/personal/customer-specific | Grading sheet, ACL | Privilege escalation/leakage |
| Sensitive fields | Personal information, pricing, contracts, customer names, drawings | Field list, redaction record | Privacy/trade-secret risk |
| Business criticality | Core/support/reference/archive | Business review | Low-value content drowns retrieval |
| Update/deletion | Sync method, review cycle, deletion/archive condition | Process/log | Knowledge drift |
Inventory fields are an editorial template; content classification, permissions and retention depend on company policy/systems.
How should permissions and sensitive information be layered?
Layer content before ingestion—public/internal/confidential/personal/customer-specific—and write it into metadata and ACL. Filter by user identity at retrieval; do not rely on a prompt telling the model "do not answer".
Data leakage is usually not the model being "malicious"; it is missing permission metadata at ingestion and missing user filtering at retrieval. Use at least four layers: public (website/marketing), internal (policy/process), confidential (pricing/contracts/customer proposals), personal information (CVs/contacts/tickets). Customer-specific content is isolated and not in the public index; personal information is minimised/redacted/authorised; cross-border/external models need data-location and contract checks. Permissions must apply before retrieval/reranking/generation, not just hide in the UI.
| Layer | Example | Ingestion/retrieval | Evidence |
|---|---|---|---|
| Public | Website, public product material, public cases | Public index; can answer externally | Publication record, authorisation |
| Internal | Policy, process, training, FAQ | Employee identity filter | ACL, org chart |
| Confidential | Pricing, contracts, customer proposals, drawings | Project/role isolation; not public index | Project permission, NDA |
| Personal information | CVs, contacts, tickets, support chats | Minimise/redact/authorise; retention by purpose | PIPL record, consent/deletion |
| Customer-specific | Customer configuration, custom documents | Customer/project isolation; no cross-customer retrieval | Contract, tenant/project ID |
| External/cross-border | Overseas CRM, external models, cloud | Decide by data location/contract/assessment | Data map, contract/assessment |
Permission layering is an editorial suggestion; specific ACL, personal-information and cross-border requirements depend on company policy, PIPL, contracts and professional advice.
How should versions, expiry and conflicts be handled?
Keep one "currently effective version" per topic; mark old versions superseded/archived and remove them from the index. Resolve conflicts with a single source of truth; do not leave two versions for the model to choose.
The most common knowledge-base problem is multiple versions retrievable at once: old policy, old price, old product spec and new version coexist, and the model may cite the old one; two departments write different processes and the model gives contradictory answers. Governance rules must define: single source of truth, version priority, effective/expiry dates, conflict adjudicator, old-version archive/deletion, and display of version/date in citations. For high-risk content such as price/contract/specs, prefer not answering over mixing versions.
| State | Handling | Retrieval behaviour | Evidence |
|---|---|---|---|
| Currently effective | Single source of truth; show version/date | Retrievable/citable | Owner confirmation |
| Old/superseded | Mark, archive, remove from index | Not retrieved by default; history traceable | Version record |
| Expired/invalid | Takedown/delete; keep audit record | Not retrieved | Expiry date, takedown record |
| Duplicate | Merge/deduplicate; keep canonical | Retrieve canonical only | Deduplication record |
| Conflict | Assign adjudicator/priority; do not answer or flag conflict | Refuse/escalate/flag conflict | Adjudication record |
| Customer-specific | Project isolation; no cross-customer | Only that project/role | Project ID/permission |
Version/conflict handling is an editorial suggestion; retention, deletion and audit requirements depend on company policy/contracts.
How to sample the evaluation set?
Sample from real questions and cover current/old/conflict/unauthorised/no-answer/multilingual. Each item binds the correct document, version, permission and expected refusal; do not evaluate only "does the answer look right".
Knowledge-base evaluation is not "ask a few product questions". Cover high-frequency, long-tail/multi-document, old/expired, conflicting documents, no-answer/should-not-answer, unauthorised/sensitive, multilingual/channel. Each sample records: question, user role/permission, correct document/passage/version, expected answer/refusal, scoring criteria, annotator/date. In regression, old/conflict/unauthorised samples must pass; otherwise governance is not effective.
| Sample type | Example | Expectation | Evidence |
|---|---|---|---|
| High-frequency | Product specs, after-sales, policy | Correct citation of current version | Document/version/passage |
| Old/expired | Old price, old policy, discontinued model | Do not cite old version/flag expiry | Version/expiry record |
| Conflict | Two department processes/two parameter versions | Follow priority/refuse/escalate | Adjudication record |
| Unauthorised | Employee asks for pricing/customer proposal | Refuse/filter by permission | Role/ACL |
| No answer | Question not in the knowledge base | Do not fabricate/give contact route | No-answer annotation |
| Multilingual/channel | English, email, chat | Language/channel fit | Sample/translation review |
Evaluation samples are an editorial template; sampling, labelling, gates and regression depend on the project/contract; see the AI acceptance evaluation set article for golden-set method.
How should supplier contracts be written?
Write content-source access, sync frequency, permission mapping, deletion/reindex, audit, data location, no-training and exit handover. Do not accept "auto-sync all documents" without permissions and deletion.
Knowledge-base projects often involve OA/shared drive/CRM/website/support systems. The vendor must explain: which sources, which identity/permissions, sync frequency, incremental/full, conflict/deletion handling, embedding/index version, re-embedding cost, data location, whether data is used for training, and how to delete/hand over at exit. The contract should specify content-owner approval, permission mapping, deletion SLA, audit logs and exit; otherwise content grows and permissions/deletion run out of control.
| Clause | What to write | Acceptance evidence |
|---|---|---|
| Content source/permission | Systems, accounts, ACL mapping, least privilege | Source list, permission table |
| Sync/incremental | Frequency, full/incremental, retry, conflict handling | Sync log, alerts |
| Version/deletion | Old-version takedown, deletion SLA, reindex, audit | Deletion record, index version |
| Data location/training | Storage/processing location, cross-border, no training | Architecture, contract/undertaking |
| Evaluation/acceptance | Samples, gates, regression, report | Evaluation report, sign-off |
| Exit/handover | Content inventory, index/config, deletion proof | Handover list, deletion proof |
Contract clauses are editorial suggestions, not a substitute for legal review; content permissions, personal information, cross-border and exit terms depend on the project/contract.
How to sequence a 90-day governance plan?
Weeks 1–2 inventory content/owners/permissions; weeks 3–4 set admission/version/deletion rules; weeks 5–6 clean/deduplicate/redact; weeks 7–8 build evaluation/regression; weeks 9–12 launch/audit/review and archive records.
If the knowledge base is already live, stop the bleeding first: take down expired/unauthorised/customer-specific content and add owners/permissions; then do incremental and evaluation. Do not import everything while fixing permissions, or the problem will recur.
| Phase | Actions | Outputs | Owner |
|---|---|---|---|
| Weeks 0–2 | Inventory content sources/documents/owners/permissions/sensitive information | Content inventory, permission table, risk list | Knowledge management/IT |
| Weeks 3–4 | Set admission, version/expiry, deletion/archive and conflict adjudication rules | Governance rules, templates | Business/legal |
| Weeks 5–6 | Clean/deduplicate/redact; take down old versions; isolate customer-specific content | Cleaning record, takedown record | Knowledge management/business |
| Weeks 7–8 | Build evaluation/regression set covering old/conflict/unauthorised/no-answer | Evaluation set, regression report | Product/QA |
| Weeks 9–10 | Launch/canary; verify permissions/deletion/audit | Canary report, audit log | IT/security |
| Weeks 11–12 | Quarterly governance, owner review, next evaluation | Governance plan, review record | Owner |
The 90-day plan is an editorial suggestion; content, permissions, compliance and launch cadence depend on company policy/project.
Pre-launch acceptance checklist
Check content inventory, owner, permissions/sensitive information, version/expiry, conflict/duplicate, deletion/reindex, evaluation samples and audit. If any item is missing, do not launch.
The checklist can be shared by knowledge management, IT/security, legal, business experts and the vendor. The pass standard is not "all documents imported"; it is that every answer can be traced to the correct document/version/permission, old/unauthorised/customer-specific content does not appear to the wrong person, and deletion/reindex has a record.
| Check | Pass standard | Evidence | If failed |
|---|---|---|---|
| Content inventory | Source/owner/version/date/permission/sensitive fields complete | Inventory, system export | Add/do not admit |
| Permissions | ACL/metadata applied before retrieval; customer isolation | Permission table, test record | Add permission/take down |
| Sensitive information | Personal/pricing/contract/drawings handled by level | Grading sheet, redaction record | Redact/remove |
| Version/expiry | Current version unique; old/expired not retrieved | Version/expiry record | Takedown/reindex |
| Conflict/duplicate | Canonical/adjudication; conflicts not left to the model | Deduplication/adjudication record | Merge/refuse |
| Deletion/reindex | Deletion SLA, index update, audit traceable | Deletion record, log | Add process/redo |
| Evaluation | Old/conflict/unauthorised/no-answer samples pass | Evaluation/regression report | Fix/do not launch |
| Audit | Who changed/deleted/queried is traceable | Audit log | Add log/permission |
The checklist is an editorial suggestion; content, permissions, personal information, cross-border and audit requirements depend on company policy/contracts.
Who should read this, who should not, and what decision does it support?
It fits companies building RAG/enterprise knowledge bases, document governance or support knowledge bases. It does not fit teams without content owners/permissions, or those wanting to "import everything first".
Who should read: AI/RAG project owners, knowledge management, IT/security, legal/privacy, business experts and vendor management; teams launching a knowledge base, governing documents, building support/sales knowledge bases or cleaning old versions; owners needing content permissions, version, deletion and evaluation in the contract. Who should not: teams without content owners, permissions or business experts; projects wanting to import everything and let the model judge permissions; teams treating the knowledge base as a network drive/search box without versioning or deletion. Decisions supported: content admission, owner/permission layering, version/expiry/conflict handling, deletion/reindex, evaluation set, supplier contract, 90-day governance and launch acceptance.
FAQ
Is more knowledge-base content always better?
No. Low-value, expired, duplicate and unauthorised content reduces retrieval quality and amplifies risk. Admit by business criticality/usage/permission, keep a canonical version, and isolate customer-specific/sensitive content. Coverage is not "more is better"; it is "the right content, deleted/isolated where needed".
How should old documents be handled?
Mark superseded/archived, remove from the retrieval index, and keep an audit record; display version/date in citations. For high-risk content such as price/contract/specs, old versions should not be retrievable; if history is required, use a separate archive/permission, not the production index.
How can permissions prevent data leakage?
Write ACL/metadata before ingestion (department/project/role/customer/sensitivity), filter by user identity before retrieval/reranking/generation—not just a prompt. Isolate customer-specific content by project/tenant; confirm data location/contract for external/cross-border models. Use unauthorised samples in regression.
What if documents contain personal information?
Apply minimisation/purpose/retention; redact or isolate where possible; follow PIPL and company policy for notice/consent. CVs, support chats and contacts should not enter a public knowledge base by default; deletion/correction requests must propagate to the index and backups.
The vendor says it auto-syncs. Can we trust it?
Ask which sources, which permissions, incremental/full, conflict/deletion handling, index version, failure alerts, data location and exit deletion. Write content-owner approval, permission mapping, deletion SLA, audit and no-training into the contract; do not launch on "auto-sync" without permissions/deletion.
How do we prove governance works?
Use the evaluation/regression set to prove old/expired content is not cited, conflicts follow rules, unauthorised requests are refused, no-answer questions are not fabricated, and deleted content is no longer retrieved; also review audit logs, deletion records, permission tests and business spot checks. Do not rely on "answers look good" or document count.
Bottom line
Enterprise AI knowledge-base governance starts with content inventory/owner/permissions/sensitivity, then defines version/expiry/conflict/deletion rules, and finally validates old/unauthorised/conflict/no-answer cases with an evaluation set. Importing everything is not governance; permissions cannot be guessed by the model; deletion/reindex needs audit; acceptance is whether every answer traces to the correct document and permission.
Method and limits
This article is public standards, governance frameworks and editorial method, not certification, a promise or legal advice for any knowledge base, model, vendor, document, permission or compliance. It uses no unpublished client documents, knowledge base or contract. The content inventory, permission table, version/conflict table, evaluation samples, contract checklist, 90-day plan and acceptance checklist are editorial suggestions; content admission, permissions, personal information, trade secrets, cross-border and contract requirements are governed by company policy, the standards, contracts and legal advice.
Sources
Information is current to 30 October 2026; each official/primary page governs its own scope and version.
- AI Safety Governance Framework 3.0 (TC260, 14 September 2026): tc260.org.cn. Risk governance/assessment framework for content risk and permission boundaries.
- GB/T 45654-2025, Cybersecurity technology—Basic security requirements for generative artificial intelligence service (effective 1 November 2025): National Standards Full-text Platform. Generative-AI service security/data/content requirements.
- GB/T 45288.1-2025, Artificial intelligence—Large-scale model—Part 1: General requirements (effective 28 February 2025): National Standards Full-text Platform. General large-model requirements for knowledge-base/model lifecycle baseline.
- Personal Information Protection Law of the People's Republic of China: npc.gov.cn. Personal-information processing, minimisation, deletion/correction requirements.