A customer asked me recently what I thought about giving AI access to their business systems.
They were looking at read access across the organization, and in some cases write access, so AI could automate work, design things, and build things for them. They could see the potential clearly. What they wanted to know was how to let AI do those operations safely.
It's a good question, and it's the one a lot of people are working through right now. There isn't a silver bullet answer. But there is a way to think about it that makes the decisions easier.
You're onboarding someone who can work at an incredible speed and doesn't know your business yet. They don't know which systems are fragile. They don't know what shouldn't be touched during month-end. They don't know the guardrails because nobody has told them.
That's not a knock on the technology. It's just the honest situation. And it means the questions you should ask are the same ones you'd ask about any new person getting access to your systems. What can they see, what can they change, and what happens when they get it wrong.
Start with read-only, because it feels like the safe one and it still deserves thought.
Where is that data going? Who is going to see it, who owns it, who has access to it? If you're using an outside model provider, is your business information now being leveraged for someone else's benefit? That can become a real issue, especially if sensitive data gets disclosed.
What you want to know is whether your data is siloed and corralled off so it remains your intellectual property. At Kodaris we run in AWS, and we've designed everything our customers use on the AI side so it's exclusive to them. We don't use it, and it isn't submitted anywhere for anyone else to use. Some other providers do the same thing. The point is to ask and get a clear answer.
You can give AI access to run queries and pull data, and with read-only permissions it can't break anything. But AI works extremely fast.
Your provider, your ERP, or whoever is hosting your data may suddenly see a huge spike in usage. That has consequences. It could be what you have to pay. It could be your ERP slowing to a crawl, or going down, in the middle of a business day.
Whatever mechanism you use, make sure the permissions really are read-only, and think about the load before you turn it loose.
Write access is where this becomes critical, because AI can wipe out a huge amount of data very quickly. There are really two ways to handle it, and which one you pick depends on whether you can put a person in the loop.
If you can, build in a QA step. AI assembles the updates it intends to make. A person reviews them, confirms they're exactly what was wanted, and allows it to proceed. Nothing moves until that happens. That's my recommendation wherever it's practical, because it catches the problem before it reaches your data.
If you're not going to have a person reviewing, then the permissions have to carry the weight instead. Keep them very narrow. It should be able to update exactly what you want updated and nothing else. This is no different from setting up security in your ERP, where you'd limit a user down to exactly what they should and shouldn't be able to do. Giving AI permissions that are too wide is the same mistake, with a faster clock on it.
What you don't want is neither. Broad write access with nobody checking is the combination that hurts.
And this gets tricky for the same reason it does with a person. AI might decide to do something you didn't authorize. It may conclude something is a good idea and generate a whole series of updates off the back of that. If nobody is checking those updates, and you don't have a solid rollback or restore plan, that can seriously affect your business.
Something will eventually go wrong. So plan for it before it does. What's the consequence of a bad set of updates? How do you restore? How do you get back to where you were?
That's just good normal business practice. It carries more weight here because you're dealing with something built to be human-like, to reason and make decisions. One day it may decide to do something because it concluded that was a good idea. And as the models evolve and get more capable, what worked a month ago may not work the same way today.
At Kodaris we're building AI tools that do reads, writes, and create work. We're also developing skill builders that can interact with the ERP as well as the Kodaris system and make decisions.
There's a large amount of time spent on what goes into the rules, guidelines, skills, and guardrails. That is the majority of the work. Building something that can perform the task is the smaller part of the job. Controlling it is the bigger part.
But that's also where the trade-off sits. On a repetitive task, the payback can be very large, because you build the guardrails once and run the task thousands of times. On a one-off, it's not worth it. You're better off having AI generate the content and then checking it and doing the import, the writing, or the mass maintenance yourself.
If you leave it wide open to save that setup time, it's going to do a lot of things that cost you more than they save. Controlled and narrow on a repetitive task is where the real efficiency shows up.
There's no silver bullet answer to the question my customer asked. But a lot of due diligence up front, and real testing, goes a long way. The efficiencies on the other side of that work are genuinely significant.
And the key questions aren't new ones. They're the same questions you'd ask before handing systems access to a person you'd just met. Where does the data go and what happens to it. What can this thing change, and what could it destroy without the right training, guidelines, and controls. What's your disaster recovery plan.
That's how we think about it, and it's the approach we follow at Kodaris. Answer those questions first, and the technology decisions get a lot clearer.