The future of AI in ERP systems

Almost every ERP now “has AI”. That is as true as it is useless: the sentence never says where the AI sits, and that is the one thing you cannot change later. AI can be part of the core — another caller of the same API the screen uses, with no permissions of its own — or it can be bolted on the side: a separate service with its own key, reading a copy of the database and seeing everything. Both look identical in a demo. In daily use they differ in everything.

This piece is about that architectural line, not about model quality. A weaker model inside the core is safer than a stronger one on the side, because the question that decides finance software is never “how clever is it” but “what may it do, in whose name, and can that be proven afterwards”. Bolted-on AI usually cannot answer any of the three — and those are exactly the three questions an inspection, or a data-leak review, will ask.

Bolted-on AI has a recognisable shape

Bolted-on AI is recognisable by the way it sidesteps the permission model the ERP spent years building for humans. It is rarely malice, usually a shortcut: to get the “chat in the corner” working fast, someone gives it a service account that sees everything, or points it at a read-replica, or at an integration that scrapes screens. Each choice is reasonable in isolation; together they build a system where the AI has its own route to the data — one that runs around row-level security, segregation of duties, approval limits and the journal.

• A service account that sees everything — one technical user above the whole authorisation model.
• A copy of the data — a read-replica or separate index filled outside permissions, so it leaks independently of them.
• Its own data model — an “AI version” of a document with its own screen, which drifts away from the real one.
• Screen scraping — an integration impersonating a user through the UI: unverifiable, and broken by every layout change.
• Answers with no provenance — a claim you cannot take apart down to the record, because the AI does not know where its data came from.

The agent walks through the same door as the screen

An AI-native core inverts that mistake. The agent has no database connection and no permissions of its own; it gets the session of the user who invoked it and calls exactly the operations that user could already run on screen. Technically, the cleanest way to do this today is over MCP — a protocol that exposes the application's existing operations to the agent as named tools. The word that matters is existing: the tool behind MCP is the same API call a button in the interface makes, with the same authorisation, the same row-level security, the same guards and the same workflow.

So the agent can do nothing the user it acts for could not. If an accountant does not see another business unit's customers, neither does the agent answering that accountant. If a person may not approve above their limit, neither may automation acting in their name. This is not “AI security” as a separate layer — it is the authorisation model a serious ERP needs anyway, now pressed harder than by any user before the agent.

One gateway for the models

A native layer does not call a model directly from a hundred places in the code. It goes through one gateway, and every request to any model passes through it. In one place live the things that are usually missing on the side: which model may touch which class of data, where that data physically goes, which model version is pinned, how much per tenant, and a full record of input and output. A hundred scattered API keys can guarantee none of that; one gateway can.

Why a local model is not a luxury

In this market, choosing a model is not only about cost and quality but about where the data is allowed to travel. Contracts, payroll, customer lists with tax IDs — many businesses will not send these to an external provider, and some are not allowed to. The gateway solves this by routing on the class of data: sensitive classes go to a local or on-prem model that never leaves the company's own infrastructure, only non-sensitive and impersonal traffic goes to a hosted model — or the whole layer runs offline. Without a gateway that choice does not exist: the data goes wherever the first key was wired.

Why a native layer can be proven

With bolted-on AI, the traces of its actions live in an application log — text that rotates, is hard to search and sits apart from the business journal. A native layer is the opposite: because the agent went through the same API, its actions are already events in the same immutable journal as manual work — every proposal and action carries the input, the model and its version, the prompt version, the tools called, the output, and who confirmed and when. Why this is not bureaucracy shows up two years later, when an inspector asks who decided that a construction-services invoice belongs in part 8b of the POPDV schedule. “The AI suggested it” is not an answer; the answer is a record showing the model and version, the source document and the person who confirmed — the same standard as any posting.

That same path through the API is what makes the layer testable. A fixed set of documents and questions can be replayed through the agent in CI, and you can assert on what it proposed, which tools it called and what it refused to fill. A bolted-on integration that scrapes screens cannot: its test surface is the interface itself, so a regression is found when a client calls. A model version change alters the behaviour of the whole layer and arrives from outside, without your commit — golden sets in CI are the only way such a change fails the build before production rather than after it.

Where AI must not decide

A native architecture makes AI safe enough to use widely — but “safe to” is not “allowed to”. Some decisions stay human regardless of the model's confidence, because their effect is external, legal, and irreversible on your side. For these the agent may prepare everything down to the last field, but the act that creates the effect stays a human confirmation:

• Filing with the authorities — the VAT return, payroll filing and VAT ledgers go in under the company's signature and deadline, not the model's.
• Releasing a payment — money that has left the bank has no undo inside your system.
• Sending an e-invoice to SEF — a sent e-invoice is a legal document, not a draft.
• Closing a period — locking the journal is a decision with consequences for everything that follows.
• Approving above a limit — a price, discount or credit past the confirming person's ceiling.
• Any action whose undo is not in your system — every external, third-party, irreversible effect.

The common denominator of that list is not a weakness of today's models that a stronger one removes. It is the question of who answers to the tax authority and the court — and accountability never passes to the software. So these boundaries do not live in the prompt (which text in an attachment can override) but in the workflow: the operations that file a return or release a payment simply are not among the tools the agent may call.

How NG One approaches it

NG One is built AI-native in that exact sense. The agent is a caller of the same API the interface uses, over MCP, with no permissions of its own; it inherits the six-layer authorisation, database-level row isolation, the workflow guards and maker–checker. The model gateway routes on data class, supports local and on-prem models for sensitive classes and can run offline. Every proposal and action is a first-class event in the same immutable journal. Evals — replayed golden documents, tenant-isolation and prompt-injection probes, and a set that rewards refusal — gate an AI change into the branch. And the boundaries from the previous section are workflow, not prompt: the operations that file a return or release a payment are not on the agent's tool list.

The choice between native and bolted-on AI is made once, early, and cannot be retrofitted. A bolted-on copilot can be dressed up to look like part of the core for a demo, but the gaps in permissions and trail show at the first inspection and the first question of how data left the building. That leaves the buyer one honest test: ask the vendor to show the agent running from an account with narrower permissions, and to show the journal entry for what the agent did. If both exist, the AI is in the core. If not, it is bolted on — however well it talks.