An assistant that answers from your data, and shows where the answer came from

What is an enterprise AI assistant?

An enterprise AI assistant is a question-answering layer that runs on your organisation’s own documents and records rather than on general internet knowledge. It retrieves the relevant passages at the moment of the question, answers only from what it retrieved, cites the source it used, and returns nothing the asking user is not already entitled to open.

The market calls the same thing several names. Enterprise AI assistant, enterprise digital assistant and enterprise AI virtual assistant all describe this pattern; the useful distinction is not the label but whether the system is grounded in your data and whether it can show its source. An ungrounded chat window with your logo on it is not an enterprise assistant, however it is marketed.

Enterprise AI assistant vs. a general chatbot

Where an enterprise digital assistant fits

The pattern earns its cost where a defined body of text is queried repeatedly by many people: product and technical specifications, warranty and contract terms, internal procedures and HR policy, supplier documentation, and resident or tenant handbooks in property operations. A support assistant over a defined document set is the same build as an internal knowledge assistant; only the audience and the permission rules differ.

What it is not suited to: questions whose answer is not written down anywhere, decisions with legal or financial consequence, and any output nobody checks.

The gap between what is asked for and what works

The request usually arrives as “we want an AI that knows our company”. Underneath it there are almost always three concrete problems, and they have different solutions.

• The answer exists but nobody can find it. A technical specification, a warranty condition, a procedure step, a clause in a supplier contract. It is in a PDF somewhere, and the person who knows which PDF is on holiday. This is a retrieval problem, and the one RAG solves well.
• The answer exists in a database and someone has to look it up. Order status, current balance, next service date, stock on hand. Not a document problem at all; the assistant should query the system through its ordinary interface and report the result.
• The input is unstructured and someone has to re-type it. An order arriving as free text in an email, a fault description in a message, a scanned delivery note. Here the model reads and drafts; the system validates and stores.

Being clear about which of the three you have is most of the specification. What to automate before reaching for a model is on business process automation, and a plainer introduction is in what an enterprise AI assistant is.

How retrieval-augmented generation actually works

RAG means the model is never asked to remember your company. It is handed the relevant passages at the moment of the question. Five stages, each of which can be got wrong in a specific way.

1. Ingestion and parsing

   Documents are read into plain text with their structure preserved: headings, tables, lists, page numbers. Scanned pages go through OCR. Repeated headers and footers are stripped, because they otherwise dominate the index. Each document keeps its metadata — name, version, date, owner, and the permission tags that decide who may retrieve it. Tables are the usual failure point: a specification table flattened into a run-on sentence produces confident nonsense later.

2. Chunking

   Text is split into passages at semantic boundaries — a section, a procedure step, a table with its caption — rather than at a fixed character count, with a small overlap so a sentence spanning a boundary is not lost. Chunks that are too large dilute the match and waste context; chunks that are too small lose the surrounding meaning, so a clause is retrieved without the condition it depends on. This stage is tuned against your actual documents, not chosen from a default.

3. Embedding and indexing

   Each passage is converted by an embedding model into a numeric vector that represents its meaning, and stored in a vector index alongside its metadata. Passages about the same subject in different words end up near each other, which is what allows a question phrased in the user's language to find a passage written in the manual's language.

4. Retrieval

   At question time the query is embedded and the closest passages are found, combined with an ordinary keyword search. Both are needed: semantic search finds meaning but is unreliable on part numbers, article codes and model designations, where exact matching wins. The combined candidates are re-ranked and the best few are selected. If nothing clears the relevance threshold, that is a valid outcome and the assistant is built to report it.

5. Generation with citation

   The model receives the question, the selected passages, and an instruction to answer only from them. The answer names its sources — document, section or page — and links to them, so a user can verify rather than trust. Every answer is logged with the passages that produced it, which is what makes a wrong answer diagnosable rather than a matter of opinion.

There is a sixth stage that gets forgotten: refresh. Documents are revised. If the index is not updated when a procedure changes, and the superseded version is not removed, the assistant will quote the old rule with the same confidence as the new one. Keeping the index current is part of the build, not an afterthought.

What it can do on your data, and what it cannot

The honest boundary matters more here than in most technology, because the failure mode is a fluent wrong answer rather than an error message.

Works well:

• Answering a factual question whose answer is written somewhere in your documents, with the source shown
• Finding the relevant clause, specification or procedure across thousands of pages in seconds
• Summarising a long document or a service history for someone who has to act on it
• Extracting fields from an unstructured document into a draft record for a person to confirm
• Classifying and routing inbound messages, with the reasoning attached
• Drafting a reply, a report section or a document from templated parts and retrieved facts
• Translating between the customer's wording and your internal terminology

Does not work, and we will say so:

• Answering what is not written down. If the rule lives only in a colleague's head, retrieval has nothing to find. The assistant will either say it does not know, or, if built carelessly, guess. The fix is to write the rule down, which is worth doing regardless.
• Reliable arithmetic across many records. Totals, ageing, margins and stock positions should come from a database query, not from a model adding figures it read in prose. We wire the assistant to the query and let it report the result.
• Compensating for data that is wrong. An assistant over a stale price list answers with stale prices, faster and more convincingly than before.
• Judgement that carries consequence. Whether to extend credit, whether a warranty claim is fair, what discount to concede. A model can assemble the evidence; the decision stays with a person who can be accountable for it.
• Guaranteeing a fixed accuracy figure. Anyone quoting a precise accuracy percentage for your data before seeing your documents is guessing. Accuracy is measured against your own question set during the build, and that measurement is what we report.

Controlling hallucination

A language model produces plausible text by construction. Grounding it is engineering, done with several overlapping mechanisms rather than one clever prompt.

The permission boundary

One rule governs the whole design: a user must not be able to reach through the assistant to anything they could not open directly. Meeting that rule is a matter of where the check happens.

• Permission tags are attached at ingestion. Every document and every passage carries the access classification of its source location, so the index knows who may see what before any question is asked.
• Retrieval is filtered by the asking user. The search runs against the subset that user's roles permit. Passages they may not see are never candidates, so the model is never given them.
• Structured lookups use the user's own identity. Queries against the operational system go through the same authorisation layer as the ordinary screens, with that user's token. A service account holding unrestricted rights would turn the assistant into a way around your access control.
• Instructions are not controls. Telling the model “do not reveal salary data” after handing it the payroll file protects nothing. If the model can see it, treat it as disclosed.
• Everything is logged with the user identity. Who asked what, and what was returned. This is both an audit requirement and the fastest way to detect misuse.

Three data architectures

Where inference happens is a governance decision, taken before the build because it changes the design.

Where records physically live, and why that question is asked before the design rather than after, is covered in where is your data.

Which jobs go to an agent, and which do not

An agent is an assistant allowed to call functions in your systems rather than only produce text. That makes the boundary a safety question rather than a preference.

Give it:

• Reversible actions: creating a draft, a proposal, a suggested classification
• High-volume, low-consequence routing and triage, with the reasoning recorded
• Field extraction into a record that a person confirms before it takes effect
• Read-only lookups the user is entitled to make anyway
• Work whose output is checked by the next step in the process as a matter of course

Do not give it, or only behind a human confirmation:

• Anything irreversible. Releasing a payment, deleting records, cancelling an order, sending a message to a customer under your name.
• Anything that binds you commercially. Committing a price, a discount or a delivery date. Let it prepare the quote; let a person send it.
• Decisions with legal or financial consequence. Credit approval, warranty adjudication, disciplinary or regulatory judgement.
• Work nobody checks. If an error would pass unnoticed into a customer's hands, the process needs a review step before the agent is allowed near it.
• Tasks with no ground truth. If you cannot say afterwards whether the output was right, you cannot measure it, and an unmeasurable agent silently degrades.

A practical way to phase this: run the agent in suggestion mode first, where it proposes and a person accepts, and count how often the suggestion is accepted unchanged. That number, on your own work, is what should decide whether it is ever allowed to act directly. The operational patterns are set out in AI agents for business operations.

How a build starts

1. Collect fifty real questions

   Not example questions — the actual ones your staff or customers ask, with the correct answers and where they come from. This set defines the scope, exposes which questions are document questions and which are database questions, and becomes the test the system is measured against.

2. Assess the documents

   Volume, format, quality, how often they change, and who is allowed to see what. A week of this usually reveals that a third of the corpus is superseded, which is a finding worth having on its own.

3. Working assistant, 2–4 weeks

   Ingestion, index, retrieval, citation and permission filtering over the real corpus, at $5,000–12,000, measured against the question set from step one. Where it sits inside a wider system we are building, module pricing applies instead: $3,000–6,000 for one focused module over 2–4 weeks. The bands are on pricing.

4. Add actions, one at a time

   Each function the agent may call is added individually, in suggestion mode first, with its own acceptance measurement before it is allowed to act. This is deliberately slower than enabling everything at once, and it is the reason these systems stay trusted.

The source code is delivered to you, the licence is perpetual with no per-user fee, and maintenance is optional at 12–25% of build cost. Model API usage or server cost is a separate running cost and we tell you what it is before you commit. Systems we have built that this layer sits on include Elevatora SAHA, Elevatora İMALAT, SEMP Group, SmartHukuk and a pharmaceutical import and export process tracking system; Elevatora PROJE is still in development. See cases, and the reporting layer on business intelligence.

Frequently Asked Questions