Use case assessment
Is AI knowledge search worth building?
Often the best first AI project a company can do — and the permissions question decides whether it ships.
Real AI, immediate value, low regulatory surface. The thing that stops it is almost always access control rather than retrieval quality.
What it usually means
Letting employees ask questions in natural language and getting answers drawn from internal documentation, wikis, tickets and policies.
Is it genuinely AI?
Yes, and this is one of the clearest cases. Keyword search fails on internal knowledge because the person asking does not know the vocabulary the document was written in. Retrieval over meaning rather than terms is exactly the problem current models solve.
It also has an unusually good risk profile: internal users, no regulatory classification in most contexts, and errors that surface quickly because the audience knows the subject.
The thing that actually stops it
Permissions. Your documents have access controls. Your retrieval system needs to respect them per user, per query, at retrieval time — not by filtering afterwards, which leaks through the answer even when the source is hidden.
Many implementations discover this after indexing everything, at which point HR documents are one question away from anyone. That is the failure that gets projects cancelled rather than fixed.
Design for it first. It is architectural, not a setting.
What the simpler version looks like
Better conventional search, scoped to one well-maintained document set. If your documentation is poor, retrieval surfaces that faster and more publicly than anything else you could build.
Start with one domain where the content is genuinely good. Expanding scope over bad content is how these become distrusted.
What it costs to run
Embedding and re-embedding as documents change. Inference per query. Evaluation against a set of real questions with known answers — and internal knowledge drifts fast, so this is ongoing.
The hidden cost is content maintenance. A confidently wrong answer from a document that was superseded two years ago is worse than no answer, and the fix is editorial rather than technical.
Where it sits under the EU AI Act
Internal knowledge search is not an Annex III high-risk use.
Article 50 disclosure applies if the interface is conversational — users should know they are interacting with an AI system, and that has been enforceable since 2 August 2026. For an internal tool that is usually obvious from context, but obvious is doing work in that sentence and it is cheap to be explicit.
When it is worth building
When you have a body of documentation that is genuinely maintained, when people demonstrably cannot find things in it, and when you will solve permissions properly at the retrieval layer.
Not as a way to avoid maintaining documentation. It makes the decay legible, which is useful, but it does not stop it.
Common questions
Why is knowledge search a good first AI project?
Internal users, immediate and visible value, low regulatory surface, and errors that surface fast because the audience knows the subject. It also fails safely compared with customer-facing or decision-making systems.
What usually stops internal AI search projects?
Permissions. Retrieval has to respect document access controls per user at retrieval time, not by filtering results afterwards, because content leaks through the answer even when the source is hidden. That is architectural and has to be designed in first.
Do we need to disclose an internal AI assistant?
Article 50 requires disclosure where a person interacts with an AI system unless it is obvious from context, enforceable since 2 August 2026. For internal tools context often covers it, but being explicit costs nothing.
Lifting AI adoption without retraining the model — where a capability sits relative to the work deciding whether it gets used at all.