Discuss a project

Decisions under uncertainty

AI solutions

The answer is never guaranteed correct. So the most important design question is what happens when it is wrong.

An AI solution differs from ordinary software in one decisive way: it produces a likely answer rather than a computed one. The same question can return a slightly different answer, and a mistake looks exactly as convincing as a correct result. That is why the work begins not with a model but with the question of which errors are acceptable and who will notice them. If the answer must be right every time, the appropriate solution is usually a written rule, not AI.

Discuss a task

In short: where this fits and where it does not

AI is useful where a decision depends on free-form content — text, documents, correspondence — and where a mistake is recoverable. It is a poor fit where the answer must be exact and verifiable every time: accounting, settlements, legal thresholds. In those cases a written rule is not only safer but cheaper. In practice most tasks that first look like AI work are better solved by workflow automation.

When an AI solution is the right answer

  • The decision depends on free-form content that cannot be expressed as conditions.
  • The volume is too large for people to review, but a mistake does not cause an irreversible consequence.
  • The output is used as a suggestion to a person rather than as a final action.
  • There are enough real examples to measure accuracy rather than merely demonstrate it.

When something simpler is enough

  • The rule can be written down — then workflow automation gives the same result every time and stays verifiable.
  • The problem is not the decision but that the data is unreachable — an integration or a tidy source comes first.
  • The task is rare — human review will cost less than something that has to be measured and maintained.

What kind of error is possible, and how it is checked

Every task has its own kind of error, and that determines whether the output can be used without a person. Below is an illustrative comparison of task types. It is not a price list, not a model comparison, and not a promise about accuracy — accuracy can only be stated after measuring it on your own examples.

Illustrative task types: what kind of error is possible and how output is checked before use
Task typeWhat kind of error is possibleHow output is checked before use
Classifying contentA record is assigned to the wrong category; the error is silent and surfaces later.Accuracy is measured on your examples; unclear cases go to a person instead of being assigned by guess.
Extracting data from documentsA field is read incorrectly, or invented when the document does not contain it.Each field is tied to a location in the document; a field not found stays empty and is flagged, not filled.
Search and answers over internal documentsThe answer sounds convincing but matches no source.Answers are shown with their source; without a source, it is not presented as an answer.
Drafting textThe tone or a fact is wrong, and the error is noticed only after sending.Output is presented as a draft for a person; automatic sending is not used.
Calculations and totalsThe result looks right but was not computed.AI is not used for these — the calculation is done by a rule.

How the work runs

  1. 01

    The decision and the acceptable error

    We describe which decision is being made, who relies on it, and which errors are recoverable and which are not. This often shows the task splits in two: part can be solved by a rule, and only the remainder needs judgement.

  2. 02

    The data and its limits

    We establish what content the solution may see and what it may not, and record where data travels and who has access. Personal and customer data is included only where the task requires it, and only under an explicit agreement.

  3. 03

    Implementation with a human checkpoint

    The solution is built so an unclear case is routed to a person rather than filled in by guess. Output carries its source, or a pointer to the place in the document, so it can be checked without trusting the answer’s tone.

  4. 04

    Measuring accuracy and handover

    Accuracy is measured on your real cases, not demonstration ones. We agree which threshold is good enough to use, how it is tracked afterwards, and what to do when quality drops. Handover includes who may change the settings.

What drives cost and duration

  • Whether there are enough real examples to measure accuracy — without them, nobody can say the solution is usable.
  • How tidy the content is: uniform documents and clear structure cost considerably less than varied free-form input.
  • The accuracy level required and how many cases may be routed to a person.
  • Data sensitivity and any limits on where content may be processed.
  • Whether integration with existing systems is needed for the output to reach the actual workflow.

Worth considering before we talk

  1. 01Which decision should this work support, and who relies on that decision?
  2. 02Can the decision be described as a rule, or does it require judgement?
  3. 03Which errors are recoverable, and which are unacceptable?
  4. 04Do you have real examples that accuracy could be measured against?
  5. 05What content may the solution see, and what must it not?

Let us look at the task

Describing the decision you want supported and what content it would need to read is enough. Please do not send real documents or personal data at this stage. If it turns out a rule solves the task better, we will say so.

Discuss a task