Understanding AI

AI in your application — what you should know.

You want the AI solution. What you do not want: to be the person explaining afterwards why the application did something nobody wanted.
This page is not about what AI can do. It is about which mechanisms have to be built in so that you can rely on an application — and how you tell whether they are there.
The real objection

Five sentences you never want to say

Nobody stops an AI project because the technology is unproven. Projects get stopped because of these five sentences — and because nobody could name what prevents them. Each one has a concrete counterpart built into the application.

«It read what it was not allowed to.»

The application inherited a person's permissions and saw salaries, contracts, other clients' files. **What holds it:** its own account with its own, smaller slice — never yours.

«It just ran through.»

A step that should have been prepared and checked ran to the end without stopping. **What holds it:** fixed, versioned steps. Whatever is not on the list stops and waits.

«It did that without asking.»

Money moved, a message left the building, a record changed — with no human in between. **What holds it:** every irreversible action has a named approval and a preview before it.

«Somebody told it — and it obeyed.»

An instruction hidden in an email, a PDF or a web page was followed like your own. **What holds it:** everything the application reads counts as content. Instructions come only from you.

«It said something that was never approved.»

Internal margins, a draft policy, another client's name turned up in an answer. **What holds it:** an approval list. What is not on it does not go out — even if the model knew it.

What carries it

Reliability is not the model — it is the application around it

As long as AI was a tool operated by a human, safety was a question of operation. Today it sits inside the process — and its uncertainty becomes a property of your application.

The component is not guaranteed

It is right most of the time — not always, and nobody can say in advance when not. That is exactly what the application has to be built for.

The tenth case decides

A component that is right in nine out of ten cases carries an application you can rely on — if the tenth case is caught before it takes effect. The same component ruins it when that case runs unchecked into a payment, a customer email or a contract.

The difference is never in the component

It is in what is built around it. You are not buying a reliable model. You are having a reliable application built around an unreliable part.

You already know this

A new employee who is fast and occasionally confidently wrong

No company is reliable because every employee is infallible. It is reliable because controls catch mistakes before they get expensive. Exactly the same applies to AI in the system — and they are the same mechanisms you already have.

Signature rules

Above a certain amount, the person who orders no longer signs. For AI that means: above a threshold it no longer acts alone.

Access permissions

Not everyone sees every file. The AI gets no all-access pass, but its own account with a small slice.

Four-eyes principle

Sensitive things get a second look. For AI the second pair of eyes is first a rule — and for anything irreversible, a human.

Audit readiness

What was done stays traceable. For AI: every case replayable, even half a year later.

The level rarely asked about

How much does the system learn — and when does replaying stop working?

This level is almost never asked about at purchase. It is the only one that can make a promise from this morning worthless.

L0 — Frozen

Behaviour changes only when someone deliberately ships a new version. **Consequence:** yesterday's test holds. Checking before each release is enough.

L1 — Knowledge grows

The model stays the same but reads documents someone maintains. Change a document and the answer changes. **Consequence:** document upkeep becomes part of quality assurance. Whoever maintains it decides with you.

L2 — Renewed on plan

The model is retrained periodically, a planned change with a date. **Consequence:** every change is a release: check first, compare results, only then switch.

L3 — Gathers experience

The application remembers cases and feedback and behaves differently after a thousand cases than on day one. **Consequence:** the knowledge state has to be versioned like software — otherwise «how could that happen» only gets a guess.

L4 — Learns in operation

The system changes continuously while it works. **Consequence:** for an SME almost never the right answer. If it is: only with shadow operation, tight limits and constant monitoring.

Questions

What decision-makers ask us about this

Which AI approach fits your case?

This page says what has to be built in. Which kind of AI your case actually needs — rules, prediction, language or an agent — is answered by the technology page, including a free advisor.

Michael

Ready for the next step?

MichaelUse our enterprise portal software to build innovative digital products. Michael is happy to advise you.