An AI assistant that searches 30,000 documents without metadata finds the 2019 price list as readily as the 2026 one. A short metadata schema (type, product, customer, validity, owner, language), filled partly by a small language model and checked by people, lets the assistant filter before it ranks. This is unglamorous work, but it often decides whether a RAG assistant is useful or embarrassing.
Problem & value
- Who: every SMB that wants an assistant over its own documents (offers, contracts, manuals, quality documents). Files sit in folders named by person, project or year; nobody knows which version is valid.
- Today: retrieval relies on folder paths and file names. Metadata fields in SharePoint or the DMS exist but are empty, because filling them by hand is tedious and nobody owns it.
- Why AI helps: a small model reads the first pages and proposes type, product, customer, validity and language. People confirm the uncertain cases. Metadata then serves as a filter ("only valid contracts for customer X") and as a ranking signal, which reduces wrong or outdated answers.
- Value: better answers from RAG assistants, faster manual search, and a base for access rules and retention. We quote no percentages; measure your own hit rate on a test set (see KPIs).
Variants
- Folder-first: derive tags from path and file name with rules; no AI, cheapest, often covers 30-50 percent of the schema in practice.
- DMS-based: Paperless-ngx correspondents, document types, tags and custom fields, filled by matching rules plus an LLM step.
- Microsoft 365: SharePoint columns, content types and managed metadata; optional AI autofill.
- Chunk-level metadata: tags are copied onto each text chunk in the vector index so that the retriever can filter. Out of scope: dataset catalogues (DATA-007) and retention labels (KNOW-025).
How it works
documents (share / SharePoint / DMS)
-> text extraction (native text, OCR for scans)
-> rules from path and file name (customer folder, year)
-> small LLM with JSON schema proposes missing fields + confidence
-> confidence >= threshold: write back | below: review queue
-> metadata into SharePoint / Paperless-ngx / vector index
-> retrieval filter + ranking in the assistant
- Schema first: 5-8 fields, closed value lists for type and product, free text only for customer. See PREP-019 for category schemes.
- Constrained output: the model must return JSON that fits the schema (structured outputs in Ollama or vLLM), so invalid tags cannot appear.
- Human in the loop: a reviewer sees document, proposed tags and confidence; corrections become test data (PREP-018).
- Validity: dates extracted by AI are checked by simple rules (valid-from before valid-to); "superseded by" links stay a human task.
Data preparation
Which data: the documents themselves, the metadata schema, customer and product lists from the ERP or CRM as allowed values, and 50-100 hand-tagged examples as test set.
Where it lives: file shares, SharePoint and OneDrive, Google Drive, Nextcloud, mailbox exports, a DMS, and scans.
Typical gaps: scans without text, near-duplicate versions ("final_v3_NEU"), documents without date, customer names written five ways, personal data inside, over-broad permissions.
Preparation steps: 1. Agree the schema and allowed values with two departments (half a day workshop). 2. Remove duplicates and obvious rubbish; decide which version counts as valid (PREP-009). 3. OCR scans so text exists (PREP-006); take customer and product names from ERP exports (PREP-005). 4. Tag 50-100 documents by hand as test set and for few-shot prompts. 5. Fix permissions before indexing (PREP-023) and define confidentiality levels (PREP-024).
Tools: Excel or a SharePoint list for the schema, Paperless-ngx, n8n or Power Automate, Docling or the DMS OCR, a script for duplicates.
Rough share of effort: high, roughly half of the project. Schema, clean-up and review take longer than the model run. See GUIDE-003.
Implementation paths
Which path for whom
- SMB - Path C: contracts, HR and customer documents are sensitive, and a simple open-source stack (Paperless-ngx or n8n plus a small Ollama model) runs on HW1/HW2 with one admin. The same server later serves RAG (PREP-013), classification and summaries (Baukasten effect).
- Enterprise - Path B: large, mixed repositories in Microsoft 365 or Google Workspace; cloud APIs in an EU region plus Microsoft Graph connectors integrate with existing governance. Path A (Purview, SharePoint Premium) suits where licences already exist.
- Developer - Path C: open-weight models, Docling and a vector database give control over schema and filters.
Path A - Buy (off-the-shelf)
- Microsoft 365: SharePoint content types and managed metadata, Microsoft Purview sensitivity labels and auto-labelling, SharePoint Premium (formerly Syntex; Microsoft has renamed this product family repeatedly, so check current name and pricing) for autofill and document processing. EU hosting via the EU Data Boundary.
- DMS products (EU vendors): DocuWare, d.velop, ELO, Ceyoniq with built-in classification; check EU hosting and AVV.
- Choose A when: you already license these tools and the document types are standard.
Path B - Build on cloud APIs
- Models: Mistral (EU provider), or Azure OpenAI / Google Gemini / Claude in EU regions, with structured outputs.
- Orchestration: n8n or Power Automate reads files via Graph or Drive APIs, calls the model, writes columns back.
- Choose B when: many repositories, custom schema, no sensitive categories or an AVV with EU processing is in place.
Path C - Self-host (open source)
- Stack: Paperless-ngx (custom fields, auto-matching), n8n self-hosted, Docling or OCR, Ollama or vLLM with a small open-weight model (for example Qwen or Mistral Small class); embeddings via an open model.
- Hardware: HW1 handles a few thousand documents overnight with a small model; HW2 for faster runs and longer documents.
- Effort: 3-5 days setup, then review. Nextcloud users can add tags through flows and the Nextcloud Assistant integrations.
Path D - Custom training
Fine-tune a small classifier only after thousands of reviewed documents exist and the schema is stable; usually not worth it.
State of the art (2026)
- Small instruction-tuned models extract type, dates and parties reliably from clean text; schema-constrained decoding removes format errors.
- Metadata filtering plus hybrid search (keyword and vector) is standard in RAG frameworks and vector databases, and improves precision compared with pure vector search.
- Limits: the model guesses validity from context, confuses similar customers, struggles with scans, and cannot know that a document was withdrawn. Never let AI alone decide "valid" for contracts or regulated documents.
Shared resources & combinations
- Same stack: PREP-013 (knowledge base for RAG), PREP-014 (AI-ready authoring), PREP-015 (terminology lists), PREP-019 (category schemes), DOC-008 mailroom classification.
- Upstream: PREP-006, PREP-009. Downstream: PREP-023 (permissions), RAG assistants.
- Hardware: one HW1/HW2 server for all small-model tasks.
Effort, cost & KPIs
- Path C: about 3-5 days setup, 5-10 days of review for 10,000-30,000 documents (planning estimate, not a benchmark).
- Path A: licence cost; configuration 2-5 days.
- Path B: per-token API cost, small for tagging, plus 3-5 days integration.
- KPIs: share of documents with complete metadata, tag accuracy against the hand-tagged test set, share routed to review, retrieval precision of the assistant before and after, time to find a document.
People & change
Involve early: department leads (schema and owners), end-users (reviewers), IT, data owners, and the DPO. Works council: depends. Tagging reads documents, not behaviour, but a review queue records who tagged what; objective suitability to monitor suffices for §87(1) no. 6 BetrVG (BAG), so agree this in a works agreement. §90(1) no. 3 requires timely information when work processes are planned with AI; §80(3) lets the works council engage an expert. Public bodies involve the Personalrat (GUIDE-004).
Data protection: documents hold customer and employee data; check legal basis, AVV (Art. 28 GDPR) for cloud models and a DPIA (Art. 35) if HR files are evaluated (GUIDE-005). AI literacy: Art. 4 AI Act, as amended by Regulation (EU) 2026/1744, requires measures that support staff's AI literacy; brief reviewers (GUIDE-006).
Pilot and tone: start with one department and one document type, frame it as "less searching", name a champion, and keep every tag overridable (GUIDE-008). Concern: "AI decides what my document is" - it only proposes.
Risks, regulation & compliance
- EU AI Act: minimal risk. If metadata drives HR selection decisions, high-risk rules may apply from 2 Dec 2027 (Annex III); do not use tags for that.
- GDPR: tags can themselves be personal data (customer names); keep them in your systems and register the processing.
- Risks: wrong "valid" flags, leakage of confidential documents via new filters, tag drift. Mitigations: review queue, permissions inherited into the index, regular sampling (GUIDE-011, GUIDE-013).
Getting started
- Pick one use case (for example contract assistant) and define the schema with the department.
- Tag 50-100 documents by hand.
- Run rules plus a small model on 500 documents; compare with the test set.
- Set confidence thresholds and start the review queue with two reviewers.
- Write tags into the index and test retrieval with and without filters (GUIDE-009).
Sources
- Microsoft - Managed metadata in SharePoint - https://learn.microsoft.com/sharepoint/managed-metadata
- Microsoft - EU Data Boundary for the Microsoft Cloud - https://learn.microsoft.com/privacy/eudb/eu-data-boundary-learn
- Paperless-ngx - Documentation - https://docs.paperless-ngx.com/
- Ollama - Structured outputs - https://docs.ollama.com/capabilities/structured-outputs
- n8n - Documentation (self-hosting) - https://docs.n8n.io/hosting/
- Regulation (EU) 2024/1689 (AI Act) - https://eur-lex.europa.eu/eli/reg/2024/1689/oj
- Regulation (EU) 2016/679 (GDPR) - https://eur-lex.europa.eu/eli/reg/2016/679/oj