An internal AI assistant that can answer questions from your contracts, policies, tickets and operational data is one of the more useful applications of current language models. It is also one of the easier ways to expose information to people who should not see it. The difference lies almost entirely in how the assistant is deployed and governed, not in which model it uses.
This article describes the architecture we use, the controls that matter, and the obligations the EU AI Act places on organisations that deploy such systems.
What "inside your own tenant" means
The phrase covers three commitments:
- The model is accessed through your cloud subscription, using the enterprise offerings of a major provider, under terms that exclude your prompts and documents from training. The provider's data-handling terms are read and filed, not assumed.
- Your documents stay in your storage. The assistant retrieves relevant passages at question time; it does not copy your document library into a third-party service.
- Identity is yours. People sign in with your identity provider, and every action the assistant takes is attributed to a named employee.
Meeting all three is possible today on Microsoft Azure, AWS and Google Cloud, and it is the baseline for anything beyond a pilot.
Retrieval, and why permissions must travel with it
Most useful assistants use retrieval: the question is used to find relevant passages in an index of your content, and those passages are given to the model along with the question. The quality of the answer depends on the quality of the retrieval, and the safety of the answer depends on what the retrieval is allowed to return.
The mistake that causes most incidents is indexing content with a privileged service account and then letting any employee ask questions. The assistant can now cite an HR file or a board paper to anyone who phrases the question well enough.
The correct pattern is permission-aware retrieval: at question time the index is filtered to documents the signed-in person can already open in the source system. The assistant can only tell someone what they could have found themselves. This requires the index to store access-control information alongside content and to refresh it when permissions change, which is more engineering than the demo suggests and is exactly where a pilot should spend its time.
Grounding, citations and refusal
An assistant used for operational decisions must show its sources. Every answer should cite the passages it relied on, with links back to the originals, so the person can check. When the retrieved material does not contain an answer, the assistant should say so rather than produce a plausible one. These behaviours are configured and tested, not hoped for.
Evaluation before and after release
Define what a correct answer is before building. With the subject-matter experts who own the content, assemble a set of representative questions and the answers a competent colleague would give, including questions that should be refused. Run the assistant against this set before release and every time the model, prompts or index change. Report accuracy, the rate of unsupported answers and the cost per question.
This evaluation set is the most durable asset the project produces. Models will change; the definition of a good answer for your organisation will not change nearly as fast.
Logging and human oversight
Log every question, the passages retrieved, the answer given and the person who asked, with retention aligned to your existing policies. Logs support three things: investigating a wrong answer, demonstrating compliance, and improving the evaluation set with real questions.
For assistants that act rather than just answer, such as drafting a document or updating a record, put a person in the loop for anything with financial, legal or personnel consequences. Approval can be lightweight, but it must exist and be recorded.
What the EU AI Act asks of deployers
Organisations that use an AI system in the course of their activities are "deployers" under the EU AI Act, with obligations that depend on the system's risk classification. Most internal knowledge assistants fall outside the high-risk categories, but some obligations still apply and some uses change the classification.
- Transparency. People interacting with an AI system must be informed that they are doing so, unless it is obvious from the context. An internal assistant should identify itself as such and explain its limitations.
- AI literacy. Staff who operate or use AI systems should have a sufficient level of understanding of how they work and their limitations. Training is part of deployment, not optional.
- High-risk uses. If the assistant is used to make or materially influence decisions about employment, such as evaluating candidates or allocating tasks, or in other listed areas such as access to essential services, it may be high-risk. Deployers of high-risk systems must use the system according to the provider's instructions, ensure human oversight, keep logs, and in some cases carry out a fundamental rights impact assessment.
- General-purpose models. Obligations on the providers of the underlying models fall on the model provider, but deployers should record which models they use and under which terms, so they can respond when providers publish required documentation.
The practical advice is to document the classification for each assistant with your legal team, keep the logs and evaluation results that demonstrate how the system behaves, and revisit the assessment when the use case changes. Many of these controls are ones a well-run deployment would have anyway.
Data protection is still the first question
The AI Act does not replace the GDPR. Before deployment, establish the lawful basis for processing the personal data the assistant will retrieve, update your record of processing, and carry out a data protection impact assessment where the processing is likely to result in a high risk. Retention of logs containing questions and answers needs a policy of its own.
Where to start
Pick one use case with a clear owner, a defined audience and content that is already well managed. Procurement contracts, IT policies and product documentation are good candidates; unstructured shared drives are not. Build the permission-aware retrieval and the evaluation set first, then the interface. Measure for eight weeks. Expand only when the numbers justify it.
An assistant built this way is less exciting in a demonstration and considerably more useful in a business.