Organisations that want a model to answer questions about their own operations discover that the model is the straightforward component. The difficulty lies in the material it is supposed to read.
Why a general model is not enough
A general model knows public information and nothing about a particular company's processes, products, decisions or customers.
Asked an internal question without internal context, it produces a plausible general answer, which is worse than no answer because it looks specific.
The standard remedy is retrieval: search internal sources for relevant material and supply it with the question.
This shifts the problem from what the model knows to what the search can find, and the second problem is the harder one.
Every difficulty that follows is a property of the organisation's information rather than of the technology.
Where company knowledge actually lives
A minority of what an organisation knows is written in documents intended to be authoritative.
The rest is in message threads, meeting notes, spreadsheets with undocumented assumptions, email chains, ticket histories and the memories of people who have been there a long time.
Written sources are also incomplete in a specific way: they record decisions and omit the reasoning, which is exactly what a question usually asks for.
Retrieval systems index what is written and inherit its gaps, so the answer quality is capped by documentation quality.
Organisations that document well get good results quickly, and the causation runs from the documentation to the result rather than the other way.
Why permissions are the first wall
Internal material is access-controlled, and a retrieval system must respect those controls per user rather than in aggregate.
A system that indexes everything and answers everyone will surface salary information, legal advice and unannounced plans to people who should not see them.
Implementing per-user filtering means the search layer must know each document's permissions and each requester's entitlements at query time, which is more engineering than it sounds.
Existing permission structures are also frequently wrong, having accumulated over years with departed owners and inherited groups nobody has reviewed.
Building this capability tends to expose those errors, which stalls the project while a separate access review runs.
How stale documents poison answers
Document stores contain multiple versions of the same policy, drafts that were never approved and material describing systems that were replaced.
Search returns whatever matches best textually, and an obsolete document often matches better than the current one because it uses older terminology.
The model then answers accurately from a source that is wrong, and the citation makes the answer look verified.
Filtering by recency helps and fails on documents that are old and still correct, which is common for foundational policies.
The durable fix is marking authoritative versions explicitly, which is a governance task that predates any AI system and is rarely complete.
Why formats resist extraction
Much internal material sits in formats that lose structure when converted to text.
Presentation decks carry meaning in layout and are extracted as disconnected fragments. Spreadsheets encode logic in formulas and relationships that flatten into number grids.
Scanned documents depend on optical recognition, which interleaves columns and dissolves tables into sequences that read as nonsense.
Diagrams, screenshots and images with embedded text are frequently the clearest explanation of a process and the least accessible to a text pipeline.
Checking what the extraction actually produced, rather than assuming the file contents arrived intact, resolves a large share of unexplained failures.
The maintenance problem
An index reflects the state of the sources when it was built, and organisations produce documents continuously.
Keeping it current requires change detection, re-indexing, permission updates and removal of deleted material, all running reliably without supervision.
Failures here are silent. The system keeps answering, using material that is progressively more out of date, with no external symptom until someone notices a wrong answer.
Ownership of that pipeline is frequently unassigned after the project team disperses, which is how systems degrade within a year of launch.
The running cost of an internal knowledge system is mostly maintenance rather than compute, and it is the line item most often omitted.
How teams scope around it
Projects that succeed narrow the scope hard, covering one well-maintained source for one team with one clear class of question.
A support team answering from a curated product documentation set is a solvable problem. The same team answering from everything the company has ever written is not.
Narrow scope also makes evaluation feasible, since a limited domain has a limited set of questions to test against.
Expansion then proceeds source by source, with each addition assessed for quality before it is indexed.
The temptation to connect everything at once is strong and is the most reliable way to produce a system nobody trusts.
What good groundwork looks like
The preparatory work is unglamorous and determines the outcome more than any model choice.
It means identifying which sources are authoritative, retiring superseded documents, fixing permissions, recording ownership for each source, and converting critical material into formats that extract cleanly.
Organisations discover during this work that a portion of what they believed was documented is not, and that some documented processes are no longer followed.
Both discoveries have value independent of any AI deployment, which is the honest argument for doing the work even if the project is cancelled.
Teams that treat the data preparation as the project, and the model as a component added at the end, consistently deliver something that survives contact with real users.