Sovereign AI in document and information management

A document and information management system is the company’s memory. Contracts, personnel files, procedures, customer correspondence and the audit trail behind them all live there, under permissions that took years to get right. That makes it the most useful place to put an AI assistant, and also the most sensitive. “Sovereign AI” is the shorthand for keeping the decisions where they belong: the organisation decides where the processing happens, what the model may read, what is kept afterwards, and who can change those answers later.

It is not a product category, and it is not a badge a vendor can award itself. It is a set of questions, and the answers are either written down and under your control, or they are not.

A document system is not a chatbot#

The difference matters because of what the content is. A general chatbot handles whatever someone chooses to type. An assistant over a document system reads what is already there, and what is there was put there under rules: who may open a file, how long a record is kept, which versions are the approved ones, and what has to be shown to an auditor. Personal data is on almost every page.

Every one of those rules can be undone by one careless integration. An assistant that reads through an account of its own, rather than as the person asking, can answer with content that person was never allowed to open. An index built for faster search is a second copy of the documents, living somewhere else, under nobody’s retention schedule. A conversation log kept by the provider is a third copy. None of this is dramatic on the day it is set up. It is dramatic on the day someone asks where the data went.

Four decisions that make AI sovereign#

Where the processing happens#

Every question sent to a language model, with whatever document text goes along with it, is processed somewhere. For a European organisation the difference between a data centre inside the EU or EEA and one outside it is not academic: personal data that leaves the area needs a legal basis for the transfer, and the people responsible for that are in your organisation, not the vendor’s.

There is a difference between a provider that is available in Europe and one that is used by default. Most products can be configured to a European region if someone reads the settings. The real test is what happens on the day of installation, before anyone has read the settings. If the default sends content outside the EU, that is what most installations will do for years.

What the model may read#

This is where document assistants most often go wrong, and it is the question to ask first. The right answer is that the assistant reads as the person asking, under that person’s own rights in the system, so that the permission model you already maintain is the filter. Two colleagues asking the same question should get different answers when their rights differ, and an answer that touches something the person may not open should say so rather than quote it.

The wrong answer is a separate account with broad rights, “so the assistant can be helpful”. It will be helpful. It will also hold the widest read access in the company, and nobody will think of it as a user.

What is kept, and by whom#

Conversations, files people upload into a chat, and any search index built from the documents are all copies of your content. Each copy needs three things: an owner, a location you can name, and a way to switch it off. The retention and deletion duties that apply to the originals apply to the copies as well, which is easy to forget when the copy was created by a feature rather than by a person.

Some of those copies are worth having. A conversation history lets people pick up where they left off; a semantic index makes searching by meaning possible. The sovereign version of each is the one that lives inside your own system, is visible only to its owner, and is off until someone decides to turn it on.

Who decides, and whether you can change your mind#

The model should be a replaceable part. The provider you use this year may not be the one you want next year, whether because of price, policy, a new European option, or a decision to run a model on your own servers. If changing provider means rebuilding the integration, you do not have a choice; you have a dependency.

The key that opens the provider’s service, and the settings around it, belong with your administrators: visible to as few people as possible, and never written into a document or shown on a screen a user can see.

What a sovereign setup looks like in practice#

Put the four decisions together and a shape emerges for any AI over a document system, whatever the product:

• The model is a part you can replace. It sits behind one address your administrator chose, and the system sends content there.
• The assistant inherits the system’s permissions. It has no rights of its own. What it finds, reads and shows is what the person asking could have found, read and seen by hand.
• Changes are proposals until a person approves them. An assistant that can write to the system shows what it would do, and a named person says yes, so the audit trail stays a record of people’s decisions.
• Nothing leaves without a decision. Uploads, indexes and histories are each a setting with an owner, not a side effect.
• The configuration is yours. Provider, key, scope and retention are settings your administrators hold, and they can be changed without starting over.

Questions to put to any vendor#

If you are evaluating an AI assistant for your document system, these are the questions worth putting in writing, and the answers worth keeping with the contract:

1. Where is the model hosted by default, and can we choose a provider in the EU or run one on our own servers?
2. Does the assistant read with its own account, or as the person asking?
3. Where are conversations and uploaded files stored, and who can read them?
4. Is anything indexed or copied out of the system, and can that be switched off?
5. Can the assistant change records, and if so, who approves each change?
6. Where is the provider key kept, and who can see it?
7. If we change provider, what has to be rebuilt?

A vendor who answers all seven plainly has done the thinking. A vendor who answers with “enterprise-grade security” has not.

How CtrlScout fits#

We built CtrlScout, our AI assistant for M‑Files, around these four decisions, because the vaults it is installed in are exactly the kind of system described above.

An administrator chooses the AI provider for each vault. The preset provider is hosted in the EU, so a vault where nobody changes that choice sends its questions to a European data centre. Another compatible service can be configured instead, including a model running on your own servers, and the vault then talks to nothing outside your network. Whichever is chosen, content goes only where your administrator has set it to go. The key setting is visible to system administrators alone, and a saved key is never shown again.

CtrlScout has no account of its own. Everything it does runs as the person asking, under their M‑Files permissions: every search, every document it opens and every name it looks up. A change it proposes is made only when that person approves it from a preview, and in their name. Conversation history lives in the vault and is visible only to the person it belongs to; chat attachments can be switched off; an administrator decides whether search by meaning runs, and when it does, every passage is re-read under the asking person’s rights before it reaches the model.

The CtrlScout page explains how it works in its sections for administrators and in the questions at the bottom. If you want to see it working, we will show you CtrlScout and help set up a demo environment so you can try it for yourself.