When AI is the wrong tool for a business workflow

A language model produces a plausible output, not a guaranteed one. Give it the same input twice and you may get two different answers; give it an input slightly outside its experience and it will still answer confidently. That behaviour is acceptable for drafting, summarising, classifying, and extracting. It is unacceptable for calculating what a customer owes.

So the first question about any workflow is not "could AI do this?" but "does this task have exactly one correct answer, and must we be able to prove afterwards why we produced it?" If yes, write the rule. A rule is cheaper, faster, testable, and explainable to an auditor.

This is the reasoning behind the principle we publish on the homepage: we use AI where it creates measurable value — not where conventional software would work better.

Exact authorisation and access decisions

Who may approve a refund, release a payment, view a record, or sign off a change is a permissions question. It belongs in explicit, inspectable rules — not in a model's judgement about whether a request looks reasonable.

Financial correctness

Invoicing, tax, payroll, commissions, pricing, ledger reconciliation. These must be arithmetically exact and reproducible. A model may help read a supplier invoice; the totals must be computed by code and validated against source data.

Safety and physical consequence

Anything that controls equipment, dispatch, clinical information, or physical access needs deterministic control paths and hard interlocks, whatever else assists the operator.

Regulatory and legal responsibility

Where a named person or the business is accountable for a decision, that accountability cannot be delegated to a probabilistic system. AI can prepare the material; a responsible human decides and the system records who.

Structured data that is already structured

If the data arrives as fields in a database or an API response, parse it. Sending clean structured data through a model to get structured data back adds cost, latency, and a new failure mode for nothing.

Broken or undefined processes

If nobody can describe how a process is supposed to work, AI will not discover the answer. Redesign first. Automating an unclear process produces confident, fast confusion.

Low-volume, high-nuance judgement

Twelve difficult decisions a month made by an experienced person is not an automation problem. The engineering effort exceeds the saving, and the nuance is the value.

• ▸Rules and validation — for eligibility, pricing, permissions, thresholds, and any calculation that must be exact.
• ▸Integrations — when the real problem is that two systems do not talk, which is a data-movement problem, not an intelligence problem.
• ▸Conventional automation — scheduled jobs, triggers, workflow engines, and templated documents handle repeatable work reliably. See business automation.
• ▸Process redesign — removing a step is better than automating it, and costs nothing to run.
• ▸Better interfaces — a well-designed screen that makes the right action obvious often removes the error the AI was being asked to catch.
• ▸Human judgement, supported — give the person the information assembled and the decision stays theirs.

Birchline builds AI systems when the conditions are right, and they often are:

• ▸Unstructured input — documents, email, transcripts, notes, images — that must become structured data.
• ▸Retrieval and knowledge work: finding the relevant passage across a large body of material a person could not read in time.
• ▸Drafting where a human reviews and owns the final output.
• ▸Classification and routing at a volume that makes a small error rate acceptable and correctable.
• ▸Summarisation and triage that shortens how long a person spends locating what matters.

The pattern in all five: the model reduces effort, and something deterministic or human still decides.

Where AI is appropriate, the controls are part of the engineering, not an afterthought. We design them during the Architect stage of our process.

• ▸Approval before consequence. Anything that sends, pays, commits, or publishes passes through a human or a deterministic check first.
• ▸Deterministic verification. Model output that represents a fact is checked against the system of record before it is used.
• ▸Confidence and escalation. Low-confidence or out-of-pattern cases route to a person rather than proceeding.
• ▸Bounded scope. The model is given the narrowest task and the least data that does the job.
• ▸Auditability. Inputs, outputs, and the human decision are recorded so the result can be explained later.
• ▸A working path without AI. If the model is unavailable or degraded, the operation continues.

• ▸Does this task have exactly one correct answer? If yes, write the rule.
• ▸Is the input already structured? If yes, parse it.
• ▸What is the cost of a wrong output — and who absorbs it?
• ▸Would a person accept being wrong at this rate in this task?
• ▸Can a human review the output before the consequence lands?
• ▸Can we tell afterwards why the system produced this result?
• ▸Is the process itself clearly defined? If not, fix that first.

Related reading: build vs. buy and how long custom software takes.