AI in enterprise systems: where it actually helps

The board meeting ends with a new task for the operations manager: "we need to use AI". Nobody says where. The following week three proposals arrive: a chatbot for the website, a dashboard with forecasts and an assistant that "answers any question about the operation". Meanwhile the field team still spends the evening putting together photo reports, and the office still retypes into the system whatever came in as a PDF.

This article helps separate real use from fashion. You will see which kinds of task suit AI, which only need well-built automation, and a list of questions to decide case by case before paying for a pilot. If the earlier question is whether to build your own system or buy a product, start with custom software vs. off-the-shelf.

What does using AI in an enterprise system mean?

Using AI in an enterprise system means having an artificial intelligence model perform one step of an existing process, inside the system the team uses, with a defined input and output. The model receives a photo, a document or a piece of text, returns an answer in an agreed format, and the system decides what to do with it.

In practice, that is different from giving every employee a chat assistant. The assistant helps a person write or search. AI inside the system is part of the workflow: the photo goes in, the classification comes out and is saved with the record, like any other field.

To think about risk, NIST, the US standards institute, published the AI Risk Management Framework in January 2023, a voluntary guide for managing risks in AI systems. It organises the work into four functions: govern, map, measure and manage. For a mid-sized company, the most useful part is the idea of mapping the context of use before choosing a tool: who uses it, with what data, and what happens when the answer is wrong.

Why does pressure to "use AI" usually go wrong?

It usually goes wrong because it starts with the tool instead of the task. When the starting point is "where can we fit AI?", the answer tends to be a visible project that few people use, such as a chatbot nobody opens after the first month.

The second problem is using AI where a rule would do. A request to "automate with AI" often describes a business rule. In the field ERP for industrial tank cleaning, general downtime hours are split equally among the service lines that actually started. That is arithmetic, and arithmetic has to give the same result every time. A language model can get that sum wrong, costs money per call and is harder to audit.

The third problem is forgetting about errors. An AI model gives probable answers, not guaranteed ones. The OWASP Top 10 for LLM Applications, a list maintained by the OWASP foundation with the most common risks in systems that use language models, includes in its 2025 edition misinformation (the model states something false with confidence), prompt injection hidden in content the model reads, and excessive agency, when the model is allowed to act without a check. All three show up when AI gets too much freedom inside the process.

Which tasks suit AI and which call for plain automation?

AI suits tasks where the input varies a lot and a person has to interpret it: photos, documents with different layouts, free text. Plain automation suits tasks with a fixed rule, where the same input must always give the same output. The table sums up that split with tasks that are common in operations-heavy companies.

The last row deserves attention. In the vessel inspection and maintenance system, pressure and temperature readings are compared with each piece of equipment's historical median, and the system flags values outside the norm. There is no AI model in that. Start with this kind of rule and only consider something more sophisticated if it stops being enough.

What usually stays out of a first project is the assistant that "knows everything about the company". It depends on organised documents, on control over who can see what and on a lot of review. It is a possible project, but rarely the best first step.

How do you decide whether a task should go to AI?

Decide task by task, with questions about the input, the answer, the error and the cost. The list below gathers the questions we ask before proposing any model.

Use the list with a concrete task in hand, not a theme. "Use AI in HSE" is too broad. "Suggest the non-conformity category from the description the technician typed" can be assessed. If the task passes the first group and gets stuck in the third, it can still go to AI, but with a person confirming each answer.

The question about two people reaching the same answer is the one that rules out the most projects. If two experienced supervisors disagree on how to classify a finding, the model will waver too, and the right discussion is about the criterion, before anyone talks about AI.

How do you take AI to production without surprises?

Take AI to production like any new system feature: small scope, a pilot with real data and a manual path that keeps working.

1. Pick one task and write down what goes in and what comes out. For example: a photo goes in, a category from a closed list and a one-sentence tip come out.
2. Define when the model must decline. In the health app we built, the vision model classifies the photo on a clinical scale and is instructed to ask for a better photo when it cannot assess it and never to give a diagnosis.
3. Run the pilot with real data and a small group of users. Store each answer next to its input so you can compare it with what the person would have done.
4. Measure the cost per use. It depends on the volume and size of each call, and only shows up with real data. The system should log consumption from day one.
5. Keep a person in the loop where an error has consequences. The AI suggests and someone confirms, at least until the history shows where it gets things right.
6. Guarantee the manual path. If the AI provider goes down, the technician keeps recording and the classification stays pending, without blocking the job.
7. Design the integration so the model can be swapped. In the health app, calls go through a model router, and changing provider does not require rebuilding the system.

This plan fits inside a software project like any other. If you have never hired development and want to understand the stages, the article on custom software projects walks from diagnosis to production.

What if the data is sensitive or the system is old?

When the data is sensitive, the first step is to send the model only what the task needs. Personal data that does not affect the answer is removed or masked before sending, and we choose API services whose terms do not use submitted data to train models. Brazil's LGPD, the national personal data protection law (similar in spirit to Europe's GDPR), gives data subjects in article 20 the right to request review of decisions made solely through automated processing that affect their interests. If AI takes part in decisions about people, such as screening candidates or assessing employees, the company needs a way to review those decisions. Your data protection officer and legal team confirm what applies in your case and in your jurisdiction.

When the system is old, AI rarely needs to wait for a rewrite. In most cases it comes in as an integration: the current system sends the photo or document, receives the answer and saves it in a new field. The care goes into the foundation. If the old system does not store the original record well or lacks role-based access control, fix that first, and that is the work we do in support and modernization.

Then there is the area with no signal. On vessels and in isolated industrial areas, the call to the model only happens when there is a connection. The field record cannot depend on it: the technician saves the photo, and classification runs when the device syncs.

When is AI not the next step?

AI is not the next step when the process is still on paper, in spreadsheets or scattered across messaging groups. Without a structured record, the model has nothing to read and nowhere to save its answer. In those cases the bigger gain comes from digitising the process first, and AI comes in later, at one specific step. The article on the digital inspection checklist shows how that record starts.

It is also not the next step when the task is rare, when an error is serious and nobody can review it, or when the rule is simple. Much of what is sold as AI, such as the report that is produced on its own when a job closes or the alert that reaches a dispatched technician, is well-designed plain automation. In the tank cleaning case, closing a job generates the PDFs, the photo report, the certificate and the billing spreadsheet without any AI model.

If you have a list of candidate tasks and want to separate what deserves AI from what deserves a rule, boosting.tech is a custom software company that builds these features inside the system your team already uses. We can go through your list in a diagnostic conversation, at no charge. What we deliver in this area is described under AI and automation.