Two generative assistant licences switched on in January, a handful of people using them every day. By September the question reaches the board: «why can’t the assistant say where a customer order stands?» Nobody connected it to the ERP. The model reads mail and documents inside the tenant, while the ERP and the document archive sit beyond its reach. Putting AI on company data requires a step that no licence includes.
This is where many projects stall for months. The company has already paid for a tool that can reason, then discovers it reasons over a narrow perimeter. From there it starts evaluating extra subscriptions, hoping one of the three covers the missing case. The owner of a distribution firm put it in his own words: the worry is finding ourselves in four months saying how nice, yet this is not the right tool.
The model does not know the company, and training it is not the answer
A general-purpose language model holds no data belonging to a single business, and it does not need retraining to hold it. The information is handed over at the moment the question is asked.
The training question comes up at almost every first meeting, usually from someone worried that internal documents will end up inside a public model. In a call with an automotive group the wording was exactly that. Does handling our data require specific training, or does it rely on an external engine that already exists? In the projects Aesir Srl follows the answer is the second one. The engine stays general and the knowledge stays corporate: the link is made when the request arrives.
The mechanism is called retrieval augmented generation. A user question triggers a search across corporate sources; the relevant fragments travel to the model together with the question. Sources stay where they are. No document is absorbed into the model, and revoking an access removes that content from future answers.
The connector is the missing piece for AI on company data
A connector exposes the data held in a business system to a language engine, in a form the engine can query. The MCP protocol defines how that exposure works.
The technical detail that follows answers two questions every board asks: whether the systems already in place are compatible, and what is paid on top. Compatibility rests on one thing, namely whether the source system exposes full APIs or only periodic exports. Cost sits with the integration project: the language engine is already paid for through existing licences, and a connector the vendor has already written adds no subscription.
Before the standard, every integration was a separate job: one for the ERP, one for the document platform, one for the next ERP. The Model Context Protocol changed the cost of integrations. Whoever owns a system writes one connector, and that connector serves any engine speaking the same protocol.
In one AI on company data project followed by Aesir the chain runs like this. The integration platform talks to the ERP and exposes the connector. The assistant the customer already uses adds it to its own sources. From that moment the same licence that answered only on mail and documents answers on orders too. No extra subscription is needed, and no additional platform has to be learned.
One point stays open, and the IT manager usually raises it. Once there are two connectors, authentication between systems needs designing: the engine has to present an identity, and that identity must map to verifiable permissions. It is the most delicate part of the architecture, and the reason many prototypes never reach production.
Permissions remain those of the person asking
An assistant wired into business systems inherits the authorisations of whoever queries it. Anyone who cannot see a document in the application will not see it in the answer either.
The objection stops many projects at approval stage, and a precise technical answer exists. Document platforms carry layered permissions. Confidentiality rules tied to document classes, a split between reading and downloading, authorisations linked to process stages, groups inheriting in cascade. The assistant queries the platform using the identity of whoever typed the question, and receives only what that identity may read.
An accounts clerk asking for the total of a job receives the total. The same question, asked by someone without access to that job, returns an empty answer. Quality in an AI on company data project is therefore measured on the map of authorisations, well before the choice of model.
Insight: a badly wired assistant can hand correct answers to people who are not authorised to read them, and nobody ever reports that kind of error.
Where the data sits once a language model is involved
The correct question covers two separate aspects: in which geography content is processed, and whether that content feeds the training of third-party models.
In the configurations Aesir proposes the platform stays on premises or on a private cloud, and the language engine is reached through a dedicated environment. Calls do not pass through the public interfaces of the model vendor, and content does not feed training. The selected platforms process data in European Union data centres, with certifications from the ISO/IEC 27001 family and requirements in line with the NIS2 directive. These are the same standards applied to our own infrastructure.
The European regulation on artificial intelligence added an obligation that concerns people before systems. Organisations deploying these tools must ensure an adequate level of literacy among those who use them. The obligation applies to every company, whatever the use case, and belongs in the plan alongside the technical work.
AI on company data: built-in modules cover only their own ground
Artificial intelligence features embedded in an application work well inside that application’s perimeter, and stop at its boundary. An AI on company data project almost always starts from a need that crosses several boundaries.
The module inside a document system reads invoices, extracts data with a confidence threshold, searches the archive by meaning. On that ground it beats any agent built from scratch, because it knows the document classes and respects native permissions. Beyond that it does not reach: the feature is built into the interface and does not answer a cross-system chat.
The comparison has to be framed by problem, and the outcome is hardly ever a single tool. In a call with an electric mobility operator two needs surfaced within the same hour. One was a conversational assistant facing a network of external dealers, with profiling of the person on the other side and a dedicated knowledge base. Another was internal access to company documentation for employees. Two distinct tools were recommended: an agent platform for the outside, the native document module for the inside, which draws on the entire archive with the correct authorisations.
Four routes for AI on company data, and how to choose
The choice follows the problem, not the technology on offer. The table sets out the four routes that recur most often in these projects.
| Route | When it fits | What has to exist first |
|---|---|---|
| AI module inside the application | The need lives inside one system: documents, invoices, archive search | Tidy document classes and permissions already correct |
| Connector to the assistant already in use | People already work inside a suite and must query the ERP as well | Source system APIs and a shared identity model |
| Dedicated agent on a multi-agent platform | The counterpart is external and needs profiling, across several channels | A written knowledge base, answer rules and handover cases |
| Automation without conversation | The process repeats and the text only needs interpreting, as with inbound orders | Validation rules and a threshold beyond which a person steps in |
An AI on company data case: order intake, told to the end
The fourth row deserves an example, because it is the least visible and the most profitable. Not every AI on company data project ends up in a chat window.
A distribution firm received between twenty and fifty orders a day, in PDF, with a different layout for each customer. Four to six lines on average, entered by hand. The problem was not the time spent, but the errors surfacing once goods had shipped. Analysis showed the case did not call for a conversational assistant. It was enough to reduce the model’s role to reading the document, leaving application logic to validate item codes, price lists and availability.
That was the choice, and it carries two measurable consequences. The first touches the errors that started the project: lines with a non-existent item code or an inapplicable price list are stopped before entry, so they never reach dispatch. The second is time. A hundred-line order enters the ERP in a minute instead of a quarter of an hour. Human checking narrows to the lines the system flags as doubtful. Across a stable customer base, the share of orders passing with no intervention settles between seventy and seventy-five per cent. The rest still goes through a person, which is exactly what should happen.
Checks to run before connecting a model to the systems
- Write down the typical question the system must answer, naming the role who will ask it.
- Check whether the source system exposes full APIs or only periodic exports.
- Review the map of authorisations and fix it before the connection, not after.
- Establish where content is processed and whether it feeds the training of third-party models.
- Define the threshold beyond which an answer passes to a person, and name that person.
- Measure the pilot on one contained process, recording a baseline before starting.
Questions the board asks about AI on company data
Do we need our own server?
In most cases no. Computation stays on the language engine. The platform exposing the data can sit on premises or on a private cloud, according to corporate security policy.
Can an assistant invent an answer?
It can produce generic answers when the knowledge base is incomplete or contradictory. Control is built before release: a base written by the company, explicit answer rules, test cases repeated at every change.
How long does a pilot take?
A contained use case takes a few weeks to set up when data is reachable through APIs. Timelines are set by the state of the documentation and of the permissions.
What happens to the work done by hand today?
The point where a person intervenes shifts. Data entry disappears, checking of exceptions remains and becomes more skilled, because it arrives with an indication of what the system failed to understand.
Let’s talk
An AI on company data project starts from three questions, in this order: which sources must be reached, with which identity, and who checks the result. The choice of model comes afterwards, and binds the least of the three decisions. Projects that reach production almost always rest on work to tidy data and permissions, work nobody talks about and that costs more than the technology installed above it. A similar path is described in our article on the knowledge base for AI agents, and in the piece on compliant digital preservation.
If you would like to explore the subject or assess the situation in your own company, you can fill in the form at the bottom of this page or write to support@aesir-tech.it: we will arrange a free consultation and start from your numbers.