Field note
When not to use AI in field operations
Do not use AI where a wrong answer can hurt someone, move money, bind the company to a customer, or decide someone's job without a person approving it. Do not use it where the data does not exist yet, or where a plain rule, a form or a checklist would do the job. AI earns its place in the messy gap between what the crew produces and what the office needs, with a person checking the result.
An owner tells us he wants AI in the company. We ask where. He says everywhere. We say no, politely, and then we explain why.
That is not a pitch against AI. We build tools with AI inside them. It is a pitch for knowing where it belongs. In a company whose work happens on job sites, in trucks and in a shop, there are places where AI makes a specific person's day easier with very little risk. There are also places where it adds risk, adds cost, or simply does a worse job than a plain checklist. Knowing the difference is most of the skill.
Here is where we say no.
Where safety or people are at stake
Anything that controls safety-critical equipment, decides whether a site is safe to work, or replaces a required inspection is off the table for us. AI can be wrong in ways that look confident. On a spreadsheet, that is a correction. On a job site, it can be an injury.
That does not mean AI has no role near safety work. It can help a supervisor get a site safety report written up from photos and notes, so the paperwork is not days behind. Our guide on safety and compliance paperwork that is behind covers that kind of problem. But the judgment about whether something is safe stays with a qualified person, and the tool should make that person's review easier, not replace it.
The line is simple. AI can help document safety work. It should not decide it.
The same goes for decisions about people. Hiring, firing, discipline, pay and performance ratings are off limits. AI can help organize information, such as scheduling interviews or collecting training records. It should not score, rank or decide about the people who work for you.
These decisions carry legal weight and human weight. A crew that believes a machine is judging them will not trust any other tool you bring in either. That cost spreads well beyond the one decision.
Where money moves or the company makes a promise
AI can draft an invoice, suggest a purchase order, or flag a vendor bill that does not match. Those are useful. What it should not do is send the invoice, place the order or pay the bill on its own.
Money that moves is hard to take back. A wrong invoice damages a customer relationship. A wrong payment can be very hard to recover. And a tool that moves money without a person approving is exactly what fraud looks for.
So every AI tool we build that touches money ends with a person approving before anything leaves the building. That is sometimes slower. It is also the reason the owner can trust the tool. If slow approvals are the real problem, the fix is to make the approval faster and clearer, not to remove it. Our guide on purchase approvals that leave crews waiting is about exactly that.
The same logic covers promises. A quote, a schedule commitment, a warranty answer, a change order. Each of these is the company making a promise to a customer. AI can draft them well. It should not send them on its own.
The reason is not only that the AI might be wrong. It is that someone has to own the promise. When a customer calls about a price or a date, "the system said so" is not an answer anyone wants to give. A named person who approved it is.
The same goes for anything that goes outside the company on its own, such as automated messages to customers or vendors. We decline tools that act outside the company without a person in the loop.
A good way to hold all of these lines at once is to ask one question about any AI idea: if this is wrong, who finds out, and how late? If the answer is a customer, a crew member on a site, or an auditor, months from now, a person has to approve before the tool acts. If the answer is someone in the office, within the hour, before anything leaves the building, the risk is usually one worth taking. Most useful AI tools in a field company live on the second side of that question, and they are designed to stay there.
Where the data does not exist yet
This is the most common reason we say no, and the least dramatic. Someone wants AI to predict which jobs will run over, or which customers will call back, or which trucks need service. The idea is sound. But nobody has been recording the information the prediction would need, or it is scattered across paper, texts and memory.
AI does not create data. It works with what exists. If the data is not there, the first project is not an AI project. It is a project to start capturing the information, reliably, in a way the crew will actually keep doing. That is a real project, and often a valuable one. It just needs to be called what it is.
Where a plain tool does the job
Many workflow problems do not need AI at all. If the job is to make sure a form has the right fields, a form does that. If the job is to route an approval to the right manager, a rule does that. If the job is to remind a tech of the five steps for a preventive maintenance visit, a checklist does that.
Plain tools are cheaper, faster and easier to trust. They do the same thing every time. When they break, it is obvious why. We reach for AI only when the input is messy and varied enough that no simple rule can handle it: handwritten tickets, voice notes, photos, free-text descriptions from different people with different habits.
A useful test is to try writing the rule down. If you can, and it holds for nearly every case, use the rule. If every attempt to write it turns into a list of exceptions, that is the exception swamp, and it may be a place where AI earns its keep, with a person handling what it flags.
There is a cost side to this too. An AI tool has running costs, needs someone to watch its output, and can change behavior when the model underneath it changes. A form or a rule has none of those problems. Choosing the plain tool where it fits is not being behind. It is keeping the company's attention for the places where AI actually pays for that attention.
Where AI does belong
After all those no answers, the yes is fairly specific. AI fits best in the gap between what the crew already produces and what the office needs it to become, with a person checking the result before it matters. It turns a voice note into a draft report. It reads a ticket and fills in a work order. It matches a vendor invoice to a purchase order and flags what does not fit.
In each case:
- the input already exists
- the output has a clear shape
- a person reviews before anything leaves the building
- someone's day gets easier in a way they can feel
That is a narrower picture than "AI everywhere". It is also the one that tends to get used.
What to do next
Take any AI idea on the table at your company and run it through the questions above. Could a mistake hurt someone, move money, make a promise or decide about a person? Does the data exist? Would a plain rule do? If it passes, it may be worth building.
How we work lists what we decline at the fit call and at the Spec, in plain words, so you know before we start. And our overview of what an operator-led workflow deployment firm is explains why we treat AI as a way of delivering a tool, not the product.
Questions people ask
Is AI safe to use in field operations at all?
Yes, in the right places. It works well turning messy field input into drafts the office reviews. It should not act on its own where a mistake could hurt someone, move money or commit the company to a customer.
What if our competitors are using AI everywhere?
Using AI everywhere is not a strategy. Using it where it clearly makes a specific person's work easier, with a check in place, is. That is also what tends to stick.
How do we know if a plain tool would be better than AI?
If you can write the rule down and it holds for nearly every case, use the rule. AI is worth its cost when the input is messy and varied enough that no simple rule can handle it.
Will you build AI tools that act without a person approving?
Not for safety-critical equipment, money that moves, employment decisions or binding customer commitments. We decline those at the Spec rather than discover the risk at go-live.