# Superficiality and risks in AI

- Date: 2026-09-01
- Category: Processes and risks
- Canonical URL: https://babovak.cz/en/blog/superficiality-and-risks-in-ai/

> Risk does not begin when something goes wrong. It begins when you do not know what you are doing.

When people talk about risk, they often say that it must be “eliminated”. But that wording is somewhat misleading.

We can reduce risk, prevent it, limit its consequences or consciously accept it. Completely removing a particular risk, however, usually means removing its cause. With a product, for example, that can mean changing the design so that the given failure mode can no longer occur. The same principle applies to a process, software or AI automation: if I do not want to allow a certain situation, I have to change the design of the system itself.

But something else is even more important.

First, I need to know that a risk exists at all.

## You can live with risk. But you have to know about it.

Imagine a simple automation.

I know that an external API can fail. I account for it with a timeout, retry or fallback. I have not removed the risk, but I am managing it consciously.

I may also conclude that a potential failure would not have serious consequences and that no additional measure is worth the effort. That is a legitimate decision too. I have consciously accepted the risk.

The situation is entirely different when I do not know that the problem exists. I have nothing to monitor, nothing to prevent, and I cannot even decide whether the risk is acceptable to me.

And this, in my view, is where one of the problems with today's approach to AI begins.

## Copy this into the terminal and it will work

Social media — and, unfortunately, sometimes paid courses too — now offer a huge number of guides:

“Build your own AI agent in five minutes.”

“Install an automation with these three commands.”

“Copy this script into the terminal.”

And it may genuinely work.

But that does not mean the person knows what they have just done.

What does the command change? What permissions does it run with? Where is the data sent? Where are the credentials stored? What happens if a part of the system stops responding? What is the agent allowed to do?

If someone does not know the answers, the problem is not only a lack of technical knowledge. Above all, they cannot assess the risks of the system they have just created.

Knowing about a risk and choosing to accept it is very different from not knowing about it at all.

## The tip of the iceberg

AI tools are a little like an iceberg in this respect.

Above the surface is a prompt, a working n8n workflow, an agent calling an API or a command copied into the terminal. The result looks simple.

Beneath the surface are authentication, permissions, network communication, data handling, dependencies, API limits, failure modes, logging, updates, backups and security.

This does not mean that everyone must be an expert in everything. But they should at least know that the part below the surface exists. And if something important depends on the system, someone must understand that part deeply enough.

## Social media mainly shows what is above the surface

The way we communicate about technology today amplifies the problem.

Social media rewards simplicity. A working demo is interesting. An explanation of failure modes, permissions or the security model is much less so.

A short video can easily fit this:

> “Look, I built an AI application in five minutes.”

It is much harder to fit in everything that can fail, why the system has this particular architecture, how its permissions are restricted and what happens when there is a problem.

We see the result. We do not see the work and complexity underneath it.

We see the tip of the iceberg.

## I do not want to teach only the procedure. I want to teach what lies beneath it too.

That is also something I place great emphasis on in my training.

My aim is not for a participant to leave with a few commands they can copy into a terminal, or with a workflow that works only because we assembled it together by following a guide.

I want them to take away a broader understanding as well. A single course does not have to turn them into a developer, infrastructure administrator or security expert. But they should understand, at least to some degree, what is happening in the system, why they are taking each step and where problems may arise.

When they copy a command, they should have a rough idea of what it will do. When they connect AI to a service, they should consider what data they are sharing with it. When they build an automation, they should know that failure modes exist and that a working demo is not the same as a reliable system.

Not so that they become afraid to experiment. Quite the opposite: so that they can use new tools independently and make informed decisions even when the trainer is no longer standing beside them.

In my view, the goal is not to teach someone a handful of procedures that work today. The tools and the specific procedures will change anyway.

It is more important to teach them to look beneath the surface too.

Then they can prevent a risk, limit its impact or consciously choose to accept it.

But first, they have to know it is there.

Source: https://babovak.cz/en/blog/superficiality-and-risks-in-ai/