Enterprise AI is the application of artificial intelligence to a company’s internal operation: its systems, its data, its permissions and whichever actions are authorised. It is implemented with two approaches — a connected enterprise agent for concrete use cases, or a conversational operating system as a cross-cutting working layer — and also with a combined architecture of both. You start with a repetitive process that has written rules and a clear owner; not with “implementing AI in the company”.
The question almost always arrives the same way: “we want to use AI, where do we start?”. And it almost always comes after a trial with a generic assistant that answered well and was useless, because it knew nothing about the company and could do nothing inside it.
What changes the result isn’t the model but the architecture: which systems it connects to, which data it sees, what it can do with them and who authorises it. This article explains the two approaches we work with, when each one fits and what you need in place before starting.
What is Enterprise AI, and which two approaches exist?
Enterprise AI isn’t a product: it is an architecture that connects models to the systems where the work already lives. The connected enterprise agent resolves one or several defined use cases: it queries information, works with documents, uses tools and executes authorised actions. The conversational operating system goes beyond the use case: it is a cross-cutting working layer from which a team queries, writes, analyses and launches tasks across several systems at once.
There is also a combined architecture: the cross-cutting layer for daily work, with specialised agents underneath for the critical processes. It is the most common place to end up when the project grows well.
When does each approach fit?
The choice depends on what needs solving, not on the size of the company. Four frequent situations:
No AI architecture fixes a process nobody can explain. If it can’t be written on one page, it can’t be automated either.
What needs defining before starting?
Four decisions, and none of them is about the model. They are taken before connecting anything:
- Systems. What it connects to: CRM, ERP, invoicing, inventory, calendar, document repositories. Every integration has its own cost and its own risk.
- Data. Which information falls within scope and which stays out. Not “all the data”: the use case’s data, with minimisation rules where sensitive information is involved.
- Permissions. Who can query what, by area and by role. The control is implemented technically, not with an instruction written inside a prompt.
- Actions. What it can execute on its own, what requires human confirmation and how it is logged. The list starts short and grows with evidence of use.
With that defined, the implementation is progressive: one use case connected and working, real measurement, and only then the next. It is slower to announce and far faster to finish.
What usually goes wrong?
Three failures repeat, and none of them is the model’s:
How does it differ from AI Hub and from chatbots?
They are three different things and often get confused. The difference lies in who operates and what it acts on:
A platform of AI tools the client’s own team uses to create content, images, video, automations and agents. It is self-service: it doesn’t integrate with the company’s internal systems and doesn’t execute actions inside them.
Conversation with customers on web, messaging or phone: serving, qualifying and routing. It looks outward. Enterprise AI looks inward: the operation, the data and the authorised actions inside the company’s systems.
Four questions for your next team meeting
History:v1.1 — the point on write permissions was corrected, having been poorly explained.