Use case · Updated August 26, 2026

What an AI system actually sees in your ERP

It's the first question any IT team asks, and it almost always gets a bad answer. This use case explains what a model can and can't see when it connects to your ERP, how that access is locked down, what happens to personal data, and the seven questions worth asking any vendor before you sign.

The answer you should be suspicious of

If you ask whether the AI will see your company's data and the answer is no, that the model never touches your database, there are two possibilities: either the system doesn't do anything useful, or the answer has been simplified to the point of being false.

An assistant that answers "how much did we sell yesterday at the Córdoba store?" has to query the data to answer that. There's no way around it. The useful question isn't whether it queries the data, but under what conditions, with what permissions, and with what limits.

The layers between your ERP and the model

What almost nobody explains is that the model doesn't connect to your ERP. There are several layers in between, and those layers are what make this secure and stable.

1. A replica, not your live system

Data is copied from a replica of the database, not from the one your team works in. The reason is operational before it's about security: analytical queries are heavy, and nobody wants the system to slow down on a Saturday afternoon because a report is running.

2. A dedicated data warehouse

From that replica, the tables that were agreed on, and only those, are copied into a separate warehouse. That's where the data gets normalized: codes each store enters differently are unified, dates are sorted out, and metrics are built. In a chain with one database per store, this is the step that turns several disconnected databases into a single source of truth you can query.

3. Metrics, not raw tables

The layer the assistant queries isn't the ERP's tables but metrics that are already built: sales by day and store, inventory by variant, reconciled payments. This matters for a practical reason on top of security: if the model had to interpret an ERP's raw schema on every question, it would get things wrong often, and in ways that are hard to catch.

4. Scoped tools, not open access

The model doesn't write freeform queries against the database. It uses predefined tools that can only read, with a maximum run time and a cap on rows returned. If a query goes past those limits, it gets cut off.

What it can and can't do, specifically

It can't write. And that's not a sales promise, it's a configuration you can verify: the user the system connects with has no write permissions on the database. Even if someone explicitly asked it to, the database would reject it. Your IT team can confirm this in two minutes by checking that user's permissions.

It can't see what wasn't declared. Only the agreed tables are copied. If a table isn't on that list, it doesn't exist as far as the system is concerned.

It doesn't change your ERP. Everything it produces lives on the warehouse side. Decisions made from its recommendations are carried out by your team, in your system, the way they always have been.

Personal data

An ERP holds customer names, ID numbers, addresses, and sometimes employee data. It's worth settling this before connecting anything, and the right question is simpler than it seems: does the system need that data to answer what we're going to ask it?

For almost everything operational, the answer is no. Knowing how much was sold, what inventory is short, or which payment didn't tie out doesn't require knowing who bought. When personal data isn't needed, the right move is for it to stay in the ERP, or to leave only as an identifier that can't be used to reconstruct who the person is.

When it is needed, for example to notify a specific customer, that should be explicit and limited to that use. The general rule: the convenience of copying everything just in case doesn't justify moving personal data.

The seven questions to ask any vendor

Use them to evaluate us, and anyone else. If any of them doesn't get a clear answer, that's a problem.

• What user does it connect with, and what permissions does that user have? The right answer can be checked in the database. You don't take it on faith.
• Does it connect to production or to a replica?
• Exactly which tables get copied? There should be a list, not "whatever we need."
• What path does the connection take? A private network or a tunnel, with no ports open to the internet.
• Where does the system run, and who can get in? And if your policy requires it, whether it can run inside your own infrastructure.
• What happens to personal data? See the section above.
• If we part ways tomorrow, what do I walk away with? The answer that holds up is a full export of the warehouse plus documentation for every metric, in an open format. Without that, what looked like a vendor is lock-in.

Why these questions come up late

These questions usually surface in the last meeting, when the decision has already been made and IT comes in to review. That's when the project stalls for weeks, not because the answers are bad but because nobody had written them down.

It works better the other way around: have them answered before the first technical meeting. If a vendor doesn't have them in writing, that tells you something on its own.