Safe zones and forbidden zones: where AI helps and where it gets in the way

#

After talking about simplification, authority, bias, and responsibility, a reasonable reaction shows up:

“Ok, but then… what do we do with AI?”

It’s a good question.
And also a dangerous one, if answered too quickly.

Because the problem isn’t deciding whether to use AI, but where, for what, and under what conditions. Not all tasks are the same. Not all errors cost the same. And not everything that can be automated should be done without thinking about consequences.

This is where it’s useful to abandon binary thinking—AI yes / AI no—and start talking about zones.

For years we’ve learned to work with powerful tools by setting limits. Not every script goes straight to production. Not every change ships without review. Not every critical system is touched on a Friday afternoon.

With AI, something similar should happen.

Not because it’s dangerous in itself, but because it removes friction. And when friction disappears, many warning signals disappear with it.

The black box with a smile doesn’t warn you when you’re crossing a line. It just answers.

Zones where AI truly helps

#

There are tasks where AI fits naturally and adds almost immediate value. Not because it “thinks,” but because it speeds up mechanical or repetitive work without compromising critical decisions.

For example:

• Synthesis and summarization
  Long documents, bids, reports, minutes, regulations. AI shines here because it reduces cognitive load without deciding for anyone.

• Writing and rephrasing
  Proposals, emails, auxiliary documentation, initial explanations. It doesn’t decide the content, but it helps express it better.

• Scaffolding and starting points
  Initial project structures, code skeletons, templates, drafts. As a first step, not as the final result.

• Repetitive or low-risk code
  Helper scripts, basic tests, glue code, internal automations. Where an error is cheap and visible.

• Exploration and comparison
  “What options exist?”, “what trade-offs are common?”, “what patterns are usually used?”. Not to decide, but to broaden the space of possibilities.

In these zones, AI acts as an assistant. It accelerates, but it doesn’t replace judgment.

Zones where AI starts to get in the way

#

There are other areas where AI introduces more problems than it solves, especially when used without clear limits.

For example:

• Architecture and system design
  AI can suggest plausible patterns, but it doesn’t understand the system as a whole or its history. It mixes best practices without knowing why they exist or when they don’t apply.

• Critical business logic
  Here errors aren’t syntactic, they’re conceptual. And they tend to show up late.

• Security, compliance, and resilience
  AI reproduces common configurations, not specific threat models or real organizational risks.

• Deep refactors
  Changing a system that’s been in production for years requires understanding past decisions, not just rewriting code.

• Systems others will maintain for years
  The longer the system’s life, the more expensive an early design mistake becomes.

In these zones, AI stops being an assistant and starts to interfere, because it produces something that looks correct but requires such deep review that any time savings evaporate.

The real boundary isn’t technical: it’s probability and impact

#

When we talk about safe and dangerous zones for AI, we’re not talking about whether the tool is “good” or “bad,” or whether the model is more or less advanced. We’re talking—like we so often do in engineering—about risk.

And risk is simply the combination of two well-known factors: probability of failure and impact of failure.

In some tasks, AI use has a reasonable probability of error, but the impact of that error is low. If something fails, it’s detected quickly, corrected cheaply, and consequences are limited. In those cases, overall risk is acceptable and AI use tends to be worth it.

In other tasks, the situation is very different. The probability of error might not be especially high, but the impact of that error—when it happens—is huge. It affects critical systems, conditions other teams’ work for months or years, or creates problems that are hard to reverse. In those scenarios, even a rare failure is unacceptable.

The problem appears when we treat both cases as equivalent.

Using AI for a task where:

• errors are visible,

• fixes are cheap,

• and decisions can be undone,

doesn’t carry the same risk profile as using it for tasks where:

• errors are discovered late,

• fixes are costly,

• or consequences fall on people who didn’t participate in the decision.

In the second case, the risk isn’t only that AI gets it wrong, but that the impact of the error lands on someone who had no real control over the decision.

When that difference is ignored, we end up implicitly accepting a dangerous model: decisions with low apparent cost and high hidden cost. And that’s not a technology problem—it’s a risk management problem.

The most common mistake: treating all tasks the same

#

Many organizations make the same mistake:
they mandate AI use across the board, with the same expectation of savings everywhere.

That ignores something fundamental: not all work carries the same cognitive cost.

Reducing minutes of writing can add hours of review.
Eliminating visible effort can multiply invisible effort.
Speeding up output can slow down learning.

When that happens, AI isn’t helping. It’s moving the problem around.

A simple (but uncomfortable) criterion

#

A good practical rule could be this:

The harder it is to explain why something is correct,
the less sense it makes to delegate it to AI.

If you need someone experienced to validate a decision,
that experience can’t be replaced with a prompt.

Use the tool for what it was designed to do

#

AI is excellent at working with language, frequent patterns, and well-bounded problems. It isn’t good at contextualized decisions, carrying consequences, or forming professional judgment.

Using it outside that frame isn’t innovation.
It’s confusing power with suitability.

It’s not about banning.
It’s about designing the use.

Defining safe zones and forbidden zones doesn’t slow AI adoption.
It makes it sustainable.

Note: This article doesn’t aim to close the debate, but to introduce a more nuanced way of using AI in professional environments. The next logical step is to ask how to train juniors, protect seniors’ judgment, and redesign metrics so AI adoption doesn’t erode what makes organizations work.