AI in business software: where it adds value, and where a fixed rule is better

A fixed rule says: when an invoice is 30 days overdue, send a reminder; when stock falls below a set level, reorder. An AI model can do work that no such rule can, such as drafting a reply or reading a document. So the useful question is not whether your software should use AI, but where. One question helps to sort each case: what happens when the AI gets it wrong?

Where does AI add value in business software?

Where the input is loose and the result can be checked. AI is good at work that has no exact formula: drafting a text in the right tone, reading figures out of a document, sorting incoming messages or explaining a result in plain words. In each case more than one answer is acceptable, and a person or a fixed rule can check the result before it does harm.

Jobs that suit AI in business software:

• Drafting: a first reply to a customer, a summary of a long email thread, or the text of an offer that a person then edits.
• Reading documents: pulling the supplier, the date and the amount out of an invoice, or recognising whether a document is an invoice, a contract or a delivery note. Our article on back-office automation has more examples.
• Sorting: deciding which team an incoming request belongs to, or which project an expense belongs to.
• Explaining: turning a calculated result into a few sentences a customer understands.

What these jobs share is that a slightly different answer is still a good answer. A reply can be phrased in many ways. A total cannot.

Where should a fixed rule decide?

Wherever the result must be exact and the same every time: prices, discounts, VAT, invoice totals, credit limits, deadlines and who may see what. A fixed rule gives the same result for the same input, and you can show why. A large language model (LLM), the kind of AI that drafts and reads text, does not promise that: Anthropic, which makes the Claude models, writes that "identical inputs may produce different outputs".

Its documentation says this holds even with the setting that controls randomness turned down to zero. Language models can also be wrong in a convincing way: OWASP's list of the top risks in software built on language models describes "hallucination" as content "that seems accurate but is fabricated". In a draft reply, a person can catch that before it is sent. In an invoice total, nobody might.

The two work well together: a rule decides, and AI prepares or explains. A fixed formula calculates a customer's credit limit, for example, and the AI writes the two sentences that explain it to the customer. If the AI phrases it badly, the limit is still right.

How does a person stay in control?

By deciding in advance what the software may do with an AI result on its own, and what waits for a person. Drafts wait for a click. Values the AI is unsure of go to a review list. Anything that spends money, sends something out or changes what a customer owes can require a person's approval. And each AI result can be logged, so it can be checked later.

These limits belong in the software as rules it enforces, not as instructions to the AI. Text the AI reads can change how it behaves; OWASP calls this "prompt injection". A button that only a manager can press cannot be argued with. OWASP's advice is to enforce permissions in the software "rather than relying on an LLM to decide if an action is allowed or not". For software in which the AI takes several steps on its own, see AI agents in business software.

Swiss law sets a minimum. The Federal Act on Data Protection covers decisions "based exclusively on automated processing" that have "a legal consequence for or a considerable adverse effect" on a person. The company must inform that person and, on request, let them state their point of view, and the person "may request that the automated individual decision be reviewed by a natural person" (Art. 21, which also sets out exceptions). Software that may make such decisions needs a way for a person to look at them again.

The Federal Data Protection and Information Commissioner (FDPIC) wrote in May 2025 that the Act "is directly applicable to AI-supported data processing". Those who make, offer or use AI systems "must make the purpose, functionality and data sources of AI-based processing transparent", and where a language model communicates with people directly, they "have a legal right to know whether they are speaking or corresponding with a machine".

If the AI service runs outside Switzerland, sending it personal data means transmitting that data abroad, and the Act sets conditions for disclosing personal data abroad (Art. 16 and 17). Which provider, and in which country, is therefore a decision for the start of a project, not a detail for later. None of this replaces legal advice for your own case.

Three examples

Three invented examples from everyday work in a Swiss SME. Each asks the same question: which step has no exact formula, and which must come out the same every time? In all three the answer is a mix: AI where the input is loose, a fixed rule where the result must be exact, and a person where something is paid or sent.

Supplier invoices at a joinery

A joinery receives its supplier invoices as PDFs by email. AI reads the supplier, the date, the amounts and the VAT from each one and suggests the order it belongs to. A fixed rule then checks the total against that order and the VAT against the rate that applies. Anything the AI is unsure of, and any mismatch, goes to a person, and no invoice is paid without a person's approval.

AI or a fixed rule? AI for reading, a rule for checking, a person for paying.

Quotes at a garden-maintenance company

A garden-maintenance company sends quotes for hedge cutting, lawn care and winter service. The price comes from a fixed rule: the areas, the hours per task and the agreed rates, the same every time and easy to explain. AI drafts the covering text from the notes of the site visit, and a person reads it before the quote goes out.

AI or a fixed rule? A rule for the price, AI for the words around it.

Tenant messages at a property management firm

A property management firm receives messages from tenants: the heating has failed, a key is lost, a question about the service charges. AI sorts each message by topic and urgency and drafts a reply for the person in charge. Amounts owed, notice periods and deadlines come from the records and fixed rules, never from the AI's draft. A heating failure in winter is also marked urgent by a fixed rule, so it never depends on the AI's judgement alone, and every reply is sent by a person.

AI or a fixed rule? AI for sorting and drafting, rules for amounts, dates and what is urgent, a person for what is sent.

The pattern is the same each time: the AI prepares, and a rule or a person sets the limits.

How are AI features tested?

Like every other feature, and then for the ways AI fails on its own: an instruction hidden in the input, an answer in the wrong form, costs that run away, and a model that changes underneath. Because the wording can differ from one run to the next, the tests check the form and the limits of an answer rather than its exact words.

• Hidden instructions: OWASP describes input that alters a model's "behavior or output in unintended ways", including content from "external sources, such as websites or files". A test feeds the software a document with such an instruction inside and checks that the software does not follow it.
• The wrong form: when the software expects a date, or one category from a fixed list, it checks the answer before using it, and a test sends answers that break the form. OWASP lists "insufficient validation, sanitization, and handling of the outputs" of a language model as a risk of its own.
• Costs: cloud AI services are paid per use (OWASP speaks of their "cost-per-use model"), so a limit per user or per day keeps a loop, or an attack, from running up the bill.
• A fixed model version: providers release new models. Anthropic, for example, states that the model behind a model ID "remains constant for the lifetime of that ID", and that for its current models an updated version "ships under a new model ID". The software names a fixed version, and the tests run again before it moves to a new one.

In the software we build, this happens before launch like all other testing: the software first runs in a test version that you can try, we test it there right through from start to finish, and it goes live only when everything works.