CEO Insights is a thought leadership series from Armando Huerta, CEO of i-Tech Support, sharing practical perspectives on AI, ERP, cybersecurity, and how growing businesses turn technology into results.
Over the past year, almost every AI conversation I have with a client starts the same way. A controller, an operations manager, or an owner shows me something their team does every week by hand, and asks whether AI can take it over.
It is usually the month-end close package. Or the weekly job-cost report. Or the Monday reconciliation between what shipped in the warehouse and what got invoiced in the ERP.
My answer is yes. But the follow-up question matters more than the first one: once AI has learned how you do it, should AI keep doing it every single time?
For most recurring business work, the answer is no. AI should learn the process once. Code should run it, the same way, every time after that. That distinction is the difference between an AI pilot that impresses people in a demo and an AI system your controller, your lender, and your auditor can actually rely on.
Why Does AI Give Different Answers to the Same Question?
AI gives different answers to the same question because large language models are probabilistic. A model reads your instructions fresh on every run and predicts the most likely response. Most of the time, that prediction lands where you want it. Not every time.
That is a feature when you are brainstorming, drafting an email, or exploring a question you have never asked before. It is a liability when the task is your accounts receivable aging report.
A recurring business process is a solved problem. Your team settled the rules years ago: which accounts roll up where, which jobs count as open, which exceptions get flagged. Asking a model to rediscover those rules on every run adds risk and buys nothing. “Usually right” is not a standard any finance team accepts for a number that goes to the bank.
Every run that depends on a model’s interpretation is another chance to drift from what you asked for.
What Does It Cost to Run Every Step Through AI?
Running every step through AI costs you on every run, forever. Each time an automation hands a step to a model, you pay for compute, you wait on a response, and you take on a small chance of error. Code that has already been written and tested runs for a fraction of that cost, in a fraction of the time.
For a single report, the difference is small. For a growing business running dozens of recurring workflows across finance, operations, and service, it compounds. Daily inventory checks, weekly job-cost rollups, monthly close packages, and quarterly compliance evidence all add up.
This is the part of AI economics most vendors do not put in the proposal. A demo runs once. Your business runs the same process 52 times a year, or 250, or every hour. The real cost of an AI automation is the cost per run multiplied by every run it will ever make.
Who Actually Has to Trust Your AI Automation?
The people who have to trust your automation are rarely the people who built it. They are your controller, your outside CPA, your lender, your cyber insurance underwriter, and in regulated industries, your auditor or compliance officer.
Those people do not ask whether the AI is impressive. They ask three things:
- What exactly does this process do?
- Will it do the same thing next month?
- Can you show me every step?
A process that a model reinterprets on every run cannot answer the second question with confidence. A process written as code can answer all 3. Anyone with the right access can open it, read each step, and know exactly what will run before it runs.
This matters for the businesses we serve. A distributor reconciling shipments against invoices needs the same result every time. A construction or trades contractor reporting job costs to a bonding company cannot have the numbers shift between runs. A healthcare or senior living organization producing compliance evidence has to show its work. Predictability is not a technical preference. For these businesses, it is a control.
What Is the Right Way to Split the Work Between AI and Code?
The right split is simple: use AI where judgment and interpretation add value, and use code where repetition and consistency matter. In practice, that means AI does the learning and code does the running.
| Stage | Who does it | What happens |
|---|---|---|
| Describe | Your team, in plain language | You explain the process the way you would explain it to a new hire |
| Build | AI | AI translates that description into a defined workflow: the queries, the logic, the outputs |
| Review | Your team | You check the workflow step by step and approve it |
| Run | Code | The approved workflow runs the same way every time, on schedule or on demand |
| Adapt | AI, with your approval | When a system changes or the business changes, AI proposes the update and you approve it again |
The value of AI here is speed of construction. Work that used to require a developer, a data warehouse, and a few weeks of back and forth can be described in a conversation and built in a fraction of the time.
The value of code is everything after that. Once the workflow is approved, it stops being a conversation and becomes a process your business owns.
How Alloy Puts This Into Practice
This is the principle behind Alloy, i-Tech’s AI intelligence layer. Alloy connects directly to Acumatica ERP and the other systems a business already runs, through direct API connections. There is no data lake to build, no warehouse to maintain, and no integration server in the middle.
Your team describes what it needs in plain language. Alloy builds the workflow. Your team reviews it. From that point forward, the approved workflow runs as a defined, repeatable process, not a fresh interpretation each time.
Alloy also works on an oversight spectrum that the business controls:
- Suggested: Alloy prepares the output or the change, and a person decides what to do with it.
- Approved: Alloy prepares the change, and a person approves it before it is written back.
- Automated: The workflow has earned trust, and it runs on its own within the rules you set.
That last point is where most AI tools stop short. Reading data and answering questions is table stakes. Alloy writes back into connected systems: updating records, creating entries, and moving work forward inside Acumatica and the tools around it. Writing back into your system of record is exactly where predictability stops being optional. A report that varies is an inconvenience. A journal entry that varies is a finding.
Does This Mean AI Should Stay Out of Daily Operations?
No. It means AI should be used where it is strongest, and kept out of the steps where it adds risk without adding value.
AI is the right tool when the question is new. “Why did margin on our top 10 jobs drop last quarter?” is not a recurring report. It is an investigation, and a model that can query your ERP, compare periods, and explain what it found is genuinely useful.
AI is the right tool when the input is unstructured. Reading a vendor invoice that arrives as a PDF, classifying an inbound service email, or summarizing a customer contract all require interpretation that code alone cannot do.
AI is the right tool when something changes. When a connected application redesigns its interface or a business rule changes, AI can propose the update to the workflow so your team is not rebuilding it from scratch.
The mistake is not using AI. The mistake is paying AI to rediscover, every single run, an answer your business settled a long time ago.
How Do You Decide Which Steps Should Run as Code?
You decide by asking 3 questions about every step in the process. If the answer to all 3 is yes, that step should run as code, and AI’s job is to build it, not to run it.
1. Is the Step Repeated?
If your team does it every day, every week, or every month the same way, it is a candidate. One-time analysis is not.
2. Is the Right Answer Already Known?
If 2 people on your team would produce the same result from the same data, the logic is settled. Settled logic belongs in code. If reasonable people would disagree, that step still needs judgment, human or AI.
3. Would a Different Result Cause a Problem?
If a variation would change a number on a financial statement, a payment, an inventory count, a compliance record, or a customer commitment, consistency is a requirement. That step should run the same way every time, and you should be able to show anyone exactly how it ran.
Most recurring work in finance, operations, and service passes all 3 tests. That is where the return on AI is largest, and where the risk of using it the wrong way is highest.
The Boardroom Question
Every leadership team evaluating AI right now is asking some version of “What can AI do for us?” It is the right starting point, but it is not the question that protects the business.
The better question is this:
“For every AI automation we run, can we open it, read every step, and know exactly what it will do next month?”
If the answer is no, you do not have an automation. You have a model making the same decision over and over, and hoping it lands the same way.
The businesses getting real value from AI are not the ones using it the most. They are the ones using it in the right places: to learn fast, to build fast, and to adapt fast, while their core processes run with the consistency their controllers, lenders, and auditors expect.
Continue the Conversation
i-Tech Support works with growing businesses across Florida and beyond to put AI to work inside the systems they already run, starting with Acumatica ERP. Alloy is how we do it: built in conversation, reviewed by your team, and run the same way every time.
