What Is an Enterprise AI Assistant, and Where Does Its Authority End?
An enterprise AI assistant is software that answers questions and drafts work using your own documents and records, not the public internet. KodDelta builds them with a grounding layer that cites the source of every answer and an authority boundary that decides what the assistant may read, draft, or write.
Somebody in your company answers the same twelve questions every week. Which discount tier applies to this dealer. What the lead time is on that part. Whether the warranty covers this failure. What clause 7 of the framework agreement says about late delivery. The answers all exist — in a price list, a contract, an ERP screen, a service record — but finding them takes a person who already knows where to look. That gap is what an enterprise AI assistant fills. It is not a smarter chatbot. It is a search-and-drafting layer over records you already own.
What an enterprise AI assistant actually is
Three components, and all three have to be present before the thing is useful:
- A connection to your own sources. Documents (contracts, manuals, price lists, procedures) and records (orders, customers, stock, service history). Without this you have a general chatbot with a company logo on it.
- A grounding step. Before the model writes anything, the system retrieves the passages or rows that relate to the question and restricts the answer to them. This is what makes an answer checkable.
- An authority boundary. An explicit list of what the assistant may read, what it may draft, and what — if anything — it may write without a person approving it.
Most disappointing AI projects have the first component and neither of the other two.
What it does well
The tasks below share one property: the answer already exists in writing somewhere, and the cost is the time spent locating it or reformatting it.
| Task | What the assistant does | Who still decides |
|---|---|---|
| Answering a document question | Finds the relevant passage across manuals, contracts or procedures and quotes it with a source reference | Nobody — the source is the answer |
| Looking up a record in plain language | Turns "which orders for this dealer are still unshipped" into a query and returns the rows | Nobody, as long as the query is read-only |
| Reading an inbound message | Extracts the customer, the machine, the fault description and the urgency from free text or a photographed note | A person confirms before a work order is created |
| Drafting a quote or a reply | Assembles a first version from the catalogue, the price rules and the previous correspondence | The salesperson edits and sends |
| Answering a new employee | Handles procedural questions from internal documentation instead of interrupting a colleague | Nobody — but the documentation has to be correct |
What it cannot do
This section matters more than the one above, because the pilots we get asked to review after they stall usually failed on one of these four points.
- It cannot know what is not written down. If the real discount rule is "whatever the sales director decides on the phone", the assistant has nothing to retrieve. It will either say it does not know or, if you configured it badly, guess.
- It cannot be more correct than your records. An assistant reading a stock table that is updated once a week gives you week-old stock answers, delivered confidently. The confidence is the dangerous part.
- It cannot carry accountability. Someone signs the quote, approves the discount, authorises the return. That signature belongs to a person with a name. An assistant can prepare the decision; it cannot own it.
- It cannot fix an undefined process. If three people handle the same request three different ways, the assistant learns nothing consistent. Define the process first — that work pays for itself whether or not you ever add AI. Our note on deciding what to automate first covers how to pick that process.
How grounding works, without the jargon
-
1. Your sources are indexed
PDFs, Word documents, spreadsheets and database tables are split into passages, each tagged with where it came from — file, page, record ID. Nothing is rewritten; the original stays the original and remains the thing you can point at in a dispute.
-
2. The question is turned into a search
The system runs both a meaning-based search and a plain keyword search. The first finds "delivery delay" when the document says "late shipment"; the second finds an exact part number that meaning-based search would blur into its neighbours.
-
3. Only the retrieved text reaches the model
A handful of matching passages are placed in front of the model with an instruction to answer from them alone. This is the step that separates a checkable answer from a merely plausible one.
-
4. The answer carries its source
Every answer shows which document, page or record it came from, so a reader can verify it in seconds. An assistant that cannot show its source cannot be audited, and one that cannot be audited will not be trusted by the people who have to rely on it.
The authority boundary: read, draft, write
This is a configuration decision rather than a technical limit, and it is the one worth agreeing in writing before the build starts. Three levels:
- Read. The assistant retrieves and answers. Nothing in any system changes. Almost every deployment should start here and stay here through its first weeks in production.
- Draft. The assistant prepares a record — a work order, a quote, a reply — and leaves it in a queue with a named owner who approves, edits or rejects it. You keep most of the time saving and all of the control.
- Write. The assistant commits the record itself. Reasonable for narrow, high-volume, low-consequence actions where the draft level has already run correctly for a while and an audit trail shows what it did and why.
Alongside the level, decide what the assistant must never touch: pricing overrides, credit limits, payroll, anything expensive to reverse. Write that list down. Access control matters as much as accuracy here, which is why it belongs in the same conversation as where your data is stored and who can reach it.
How it differs from a general chatbot
| Criterion | General chatbot | Corporate AI assistant |
|---|---|---|
| Source of the answer | Training data, plus whatever the user pastes in | Your indexed documents and records |
| Verifiability | No reference to check | Every answer names its source |
| Behaviour when it does not know | Tends to produce a plausible answer anyway | Says so and escalates to a person |
| Permissions | Whatever the user pastes into the window | Bound to that user's existing role and data access |
| Where the data goes | Governed by the terms of the account in use | A deployment model you choose and can document |
On the last row, the deployment choice is yours. Records can stay inside your own infrastructure with a locally hosted model, or run against a hosted model under an agreement that covers retention, with sensitive fields masked before anything leaves your network. What matters for compliance is not which option sounds safest, but that you can state which one you are on and show the contract behind it. Where the data actually goes on each question works through that in detail, including the transfer mechanism a Turkish supplier has to name.
You keep the source code
We build enterprise AI assistants and the internal systems around them — then hand over the source code, the database schema, and the architecture documentation. If your vendor disappears tomorrow, your assistant shouldn't. One-time payment, unlimited users, optional maintenance.
When not to build one
We have advised companies not to start, and the reasons repeat:
- The documents that would be indexed are out of date and nobody owns them. An assistant makes stale content easier to find, not more correct.
- The question volume is low. Twenty lookups a month does not repay a build, however irritating those twenty feel.
- The real bottleneck is a missing system, not a missing answer. If order status lives in one person's inbox, build the order system first — package versus custom is the relevant comparison there, not AI.
- The answers need judgement rather than retrieval: engineering sign-off, credit decisions, anything where being confidently wrong is expensive.
Cost, timeline and what is delivered
- Retrieval assistant grounded in your own sources: $5,000–12,000, depending on how many sources are connected and how clean they are.
- A single focused module when the assistant is one part of a wider system: $3,000–6,000 over 2–4 weeks.
- Multi-department system: $8,000–15,000 over 4–8 weeks. Platform scope: $20,000+ over 3–6 months.
- Annual maintenance: optional, 12–25% of build cost.
- Licence: perpetual, unlimited users, source code delivered.
Those are build figures. The monthly bill that follows behaves differently, and it is the number most proposals leave out: what an enterprise AI assistant costs to run covers the volume threshold below which it does not pay.
To see which bracket your own case falls into before talking to anyone, run the numbers in the AI assistant payback calculator — it takes two minutes and hands the result straight into the quote form.
A working prototype lands within the first two weeks, so the decision to continue is made against something your team has actually asked questions of rather than a specification. Systems built on this pattern include Elevatora SAHA for lift maintenance and field service, Elevatora İMALAT for lift-component manufacturing, and PAP for pharmaceutical import and export process tracking.
Bring the twelve questions your team answers every week and we will tell you which are retrieval problems and which are process problems. Request a quote, read the AI integration page, or compare delivery bands on the pricing page.
Frequently asked questions
What is an enterprise AI assistant?
An enterprise AI assistant — sometimes called an enterprise digital assistant — is software that answers questions and drafts work using a company's own documents and records rather than the public internet. It retrieves the relevant passage or row first, answers only from that text, and cites the source, so every answer can be checked.
What is the difference between an enterprise AI assistant and ChatGPT?
A general chatbot answers from what it learned during training and has no access to your price lists, contracts, stock levels or service history. An enterprise AI assistant is connected to those specific sources, answers only from what it retrieves, and shows which document or record each answer came from.
What can an enterprise AI assistant not do?
It cannot make a decision that requires accountability, cannot know anything that is not written down somewhere it can read, and cannot be trusted to be right when the underlying records are wrong or out of date. It also cannot repair a process nobody has defined yet.
How does an enterprise AI assistant avoid making up answers?
It is restricted to retrieved text. Before answering, the system searches your indexed documents and database records, places the matching passages into the model context, and instructs it to answer only from that text. If nothing relevant is found, the correct behaviour is to say so and hand the question to a person.
Can the assistant write data into our existing systems?
It can, but that is a separate decision from letting it answer questions. Write access should start narrow: draft a record for a person to approve rather than commit it directly. Direct writes become reasonable once the same action has run correctly under review for a period you are comfortable with.
What data do we need before an AI assistant is useful?
A source of truth that is current and reachable. That usually means documents in a known location rather than scattered across personal drives, and records in a system with an API or an export. If the answers exist only in people's heads, the first project is writing them down, not buying AI.
What does an enterprise AI assistant cost at KodDelta?
A retrieval assistant grounded in your own documents and records is $5,000–12,000. If the assistant is one part of a larger system, a single focused module is $3,000–6,000 over 2–4 weeks. The licence is perpetual with unlimited users and the source code is delivered to you.
Ask any vendor one question first
Do you hand over the source code, with the schema and the docs? We do — it is how we have worked since 2019, across six named systems. A single module runs $3,000–6,000 over 2–4 weeks; the discovery call is free. If an assistant doesn't fit your data, we say so — you lose 30 minutes, not a budget.