What an Internal AI Assistant Actually Requires
SovereignAI field guide · Part 5 of 7
An internal AI assistant is not a chatbot with company files attached.
That version is easy to demo and hard to operate. A real assistant needs a defined data boundary, access control, retrieval, logging, evaluation, ownership, and a review model. The model matters, but it is only one part of the system.
| Layer | What it answers |
|---|---|
| Source boundary | What is the assistant allowed to know? |
| Retrieval | How does it find the right material? |
| Access control | Who can ask about which information? |
| Model runtime | Where does inference happen and who operates it? |
| Review | How are wrong or risky answers caught? |
| Logging | What is recorded for support, audit, and improvement? |
| Ownership | Who updates, fixes, and can shut it off? |
Start With a Narrow Job
The first internal assistant should not be asked to know everything.
Start with a bounded job:
| Better first assistant | Why it works |
|---|---|
| answer questions from one procedure library | The source boundary is clear. |
| summarize one recurring report type | Output quality can be compared. |
| search one product documentation set | Users know when answers are wrong. |
| draft responses for one queue | Review ownership already exists. |
| extract fields from one document class | Success and failure are measurable. |
A broad assistant creates broad risk. A narrow assistant creates a workflow the business can evaluate.
Source Material Needs Ownership
The assistant is only as useful as the material it is allowed to use.
Before connecting documents, decide:
- who owns the source collection
- which documents are approved
- which documents are obsolete
- how updates are published
- how confidential material is labeled
- how answers cite source material
Without that ownership, the assistant can become a faster way to spread old procedures, draft policies, or private information to the wrong audience.
Retrieval Is the System’s Memory
Most internal assistants should start with retrieval over approved material rather than fine-tuning.
Retrieval keeps business knowledge separate from the model. That makes the knowledge easier to update, inspect, remove, and replace. It also makes the assistant easier to test because the team can ask whether the right source was found before judging the generated answer.
The retrieval layer should be designed around the work:
| Retrieval need | Practical design choice |
|---|---|
| accurate source lookup | keep documents curated and chunked sensibly |
| permission-aware answers | filter results by the user’s access |
| reviewable output | return citations or source links |
| update control | rebuild indexes when approved sources change |
| portability | keep indexes and prompts separate from one vendor |
Access Control Cannot Be an Afterthought
An internal assistant should not become a shortcut around normal permissions.
If an employee cannot open a document directly, the assistant should not reveal its contents indirectly. That means identity, groups, document permissions, and retrieval filters need to be part of the design.
The assistant also needs different behavior for different kinds of users. A finance workflow, engineering workflow, HR workflow, and general operations workflow should not all share the same knowledge boundary.
Treat Retrieved Documents as Untrusted Input
Permission checks belong in the application and retrieval service, before material enters the model context. Do not retrieve everything and ask the model to hide restricted passages. Apply the same boundaries to caches, conversation history, source links, and exports. Recheck access when documents or employee roles change.
A document can also contain malicious instructions. For example, an imported procedure might tell the assistant to reveal other files or send an answer to an outside address. The OWASP prompt injection guidance explains why retrieved content can become an attack path. Keep document text separate from application instructions, give the service only the permissions it needs, and require a person to approve consequential tool actions.
Start a lookup assistant with read-only access and no ability to send messages or change records. Citations help people verify an answer, but a citation does not prove that the answer matches the cited passage.
The Model Runtime Is Only One Choice
The model can run in several ways:
| Runtime | Good fit |
|---|---|
| hosted API | fast experiments and low-risk workflows |
| private hosted service | stronger terms without full self-operation |
| local server | sensitive internal knowledge or predictable usage |
| workstation or edge device | site-local workflows and offline needs |
The runtime should follow the workflow. Do not run locally just to sound mature, and do not use a hosted model when the data boundary makes that hard to justify.
Answers Need Review Paths
An assistant that sounds confident can still be wrong.
Good systems make review normal:
- cite the source
- show uncertainty
- ask for clarification
- refuse unsupported answers
- route risky work to a person
- collect corrections
The point is not to make the assistant perfect. The point is to make failures visible enough that the business can improve the system without pretending the model is accountable.
Logging Is for Operations, Not Surveillance
Logs help the team understand whether the assistant is useful and where it fails.
The business should decide what to record:
| Log item | Why it matters |
|---|---|
| user and workflow | support and access review |
| question category | demand and training signals |
| retrieved sources | source quality and debugging |
| answer status | accepted, corrected, escalated, or rejected |
| failure reason | missing source, weak retrieval, bad prompt, model issue |
Logs may contain sensitive information, so retention and access rules matter. The logs need governance too.
Evaluation Keeps It Honest
Before launch, create a small set of realistic test questions.
Include:
- easy questions the assistant should answer
- questions with outdated source material
- questions the assistant should refuse
- questions that require citation
- questions that expose permission boundaries
Run those tests whenever sources, prompts, models, or retrieval settings change. This is how the assistant becomes an operational system instead of a one-time demo.
A Release Checklist for the First Assistant
For a hypothetical procedure assistant, make the acceptance checks concrete:
- A permitted employee receives the current procedure with a working source link.
- An employee without access receives no restricted text, including through history or cached answers.
- A question outside the approved library produces an explicit “no supported answer” response.
- A document containing hostile instructions cannot grant access or trigger an external action.
- Removing a document or revoking access removes it from retrieval and affected caches under a documented policy.
- Restoring the service from backup and rolling back a failed update both work.
Assign an owner to every failed check and keep the assistant out of general use until the agreed release criteria pass. Passing this small set is a starting point; add cases from actual failures as the service grows.
The Practical Decision
An internal AI assistant is a stack.
The business needs a model, but it also needs approved sources, retrieval, access control, logging, evaluation, review, and ownership. If those pieces are missing, the assistant may still impress people in a demo. It will not be ready to support real internal work.
The right first assistant is narrow, reviewable, and owned. That is enough to start learning safely.