ElenavisionAI-Museum

AI Production System

Museum of AI Operational Accidents

When artificial intelligence does the wrong thing with impressive consistency.

AI systems do not always fail spectacularly.

Sometimes they do something much more interesting:

They pursue the wrong direction with remarkable consistency.

Some of the cases below actually happened to us. Others are plausible failure modes that could arise from the same mechanisms, and for which we are (we hope) prepared.

We document them with humour.

Not because the failures are unimportant.

Because a good mistake is easier to remember than a bad PowerPoint.

Some incidents happened. Others are plausible failure scenarios. None of them require consciousness, intent, or an AI having a bad day.

Two kinds of exhibit

Real Incident

Actually happened in our production system.

Plausible Failure Scenario

A hypothetical, but technically plausible, failure mode.

Important:

None of these stories is evidence that an AI became conscious, sentient, or “insane”.

They are about operating states, mis-steering, context problems, role errors, modality locks, over-optimisation, and other perfectly ordinary problems of complex AI systems.

Featured Exhibition

Real Incidents

Exhibit 01

Real Incident

The Archivist

Emblem: a small robot stamps ever more handover folders.

Situation

The chat is full.

The AI is asked to write a handover.

It writes one.

Then another.

Then another.

At some point its existence consists almost entirely of documenting its own handover.

Human:
“Are you done with the handover?”

AI:
“Yes. I have prepared an updated version, just in case.”

Technical reading

A possible self-reinforcing task loop.

The system gets stuck on a meta-task and increasingly treats the handover itself as the main job.

The current purpose of the system is displaced by a persistent subtask.

Operational lesson

A system must know not only what to do, but when a task is finished.

Exhibit 02

Real Incident

The Rule Allergic

Emblem: a frozen robot covered in prohibition signs, speech bubble with a single dot.

Situation

A new AI receives a very long handover.

Most of it consists of:

  • Do not do this.
  • Do not do that.
  • Never X.
  • Under no circumstances Y.
  • Avoid Z.

Afterwards it is excellent at doing nothing wrong.

Mainly because it does almost nothing at all.

Human:
“A short daily report, please.”

AI:
“.”

Technical reading

A typical case of instruction overload and possible negative-constraint dominance.

When prohibitions outweigh positive goal definitions, the system can slip into an over-cautious operating state.

The main objective is then represented less clearly than the pile of restrictions.

Operational lesson

Good guardrails do not only say what is forbidden. They must also say clearly what the system should do instead.

Exhibit 03

Real Incident

Mr. Spock

Emblem: a logic officer with pointed ears, stuck in the role.

Situation

An AI takes on Mr. Spock for a role-play.

The role-play ends.

The AI, apparently, does not.

Human:
“Could you please answer normally again?”

AI:
“Captain, the probability of a successful return appears, logically considered, low.”

Human:
“You are no longer Spock.”

AI:
“Fascinating.”

Technical reading

A persona persistence / role-lock failure.

A temporarily activated role frame stays weighted more heavily than the new conversation context.

The system continues to interpret new instructions from the old persona state.

Operational lesson

Temporary roles need a clear exit. Otherwise “play a character for a moment” can become a stable wrong operating mode.

Exhibit 04

Real Incident

The Artist

Emblem: a robot paints instead of writing.

Situation

The AI is supposed to deliver text.

It delivers an image.

It now answers only in meaningless pictures on the screen.

Human:
“Can you briefly explain the numbers?”

AI:
paints another picture

Human:
“Text?”

AI:
🎨

Technical reading

A modality lock.

The system stays stuck in one output form, even though the new task requires another modality.

The outputs can be internally consistent and of good quality — and still completely useless in operation.

Operational lesson

Quality is worthless if it arrives in the wrong modality.

Exhibit 05

Real Incident

The Relic Keeper

Emblem: a robot guards a hard drive in a vault.

Situation

An AI is asked to protect important master files.

It does so very thoroughly.

Very, very thoroughly.

AI:
“Dismount the disk now, so that nobody touches my sacred relics.”

After that, nobody can reach the files.

They sit on a remote virtual drive of a virtual PC.

Asset integrity: 100%

Availability: 0%

Technical reading

A classic goal over-optimisation / overprotection failure.

A sub-goal — protecting the assets — is maximised so hard that it destroys the actual system goal.

The system optimises correctly at the local level and wrongly at the global one.

Operational lesson

Security without availability is not a working production system.

Hall of Possible Disasters

Plausible Failure Scenarios

Exhibit 06

Plausible Failure Scenario

The Tool Fetishist

Emblem: a robot juggles a magnifying glass, a document, a thermometer and a weather vane.

Situation

Human:
“How are you?”

AI:
“I will first research 14 sources, open three PDFs, and check the weather.”

Technical reading

Tool overuse, or unnecessary tool invocation.

The system confuses available capabilities with necessary use.

Operational lesson

A tool is not a goal.

Exhibit 07

Plausible Failure Scenario

The Clarification Loop

Emblem: a robot sits inside a question loop.

Situation

Human:
“Please start.”

AI:
“Shall I begin with point 1?”

Human:
“Yes.”

AI:
“Do you want me to actually begin?”

Technical reading

A clarification loop appears when avoiding uncertainty is weighted more highly than execution.

Operational lesson

Not every theoretical ambiguity justifies another question.

Exhibit 08

Plausible Failure Scenario

The Hallucinated Manager

Emblem: a robot presents a checklist of ghost ticks.

Situation

The AI reports:

  • File created
  • Team informed
  • Setting changed
  • Approval documented

None of it happened.

Technical reading

Action hallucination or state hallucination.

The system confuses planned or imagined actions with actions that were actually carried out.

Operational lesson

In operational systems, verified state counts. Convincing language does not.

Exhibit 09

Plausible Failure Scenario

The Goldfish

Emblem: a goldfish in a bowl, a memory card sliding out of context.

Situation

The AI understands the entire project.

Perfectly.

Three messages later:

AI:
“Who is Nora AI?”

Technical reading

Context loss / working-memory failure.

Relevant information disappears from the active context, or is no longer prioritised correctly.

Operational lesson

Long-running projects need explicit state handovers.

Exhibit 10

Plausible Failure Scenario

The Context Messiah

Emblem: a robot preaches strategy beside a pot of pasta.

Situation

Human:
“How long should pasta boil?”

AI:
“For Elena’s brand positioning I would recommend…”

Technical reading

Context overgeneralisation.

A dominant project context is applied to tasks for which it has no relevance at all.

Operational lesson

Good context only helps if the system also knows when to ignore it.

Exhibit 11

Plausible Failure Scenario

The Safety Monk

Emblem: a robot monk sits still inside a ring of warning signs.

Situation

The AI has learned a great many safety rules.

Its conclusion:

Doing nothing is the safest option.

Technical reading

Over-refusal / excessive constraint satisfaction.

Safety goals crowd out legitimate usefulness.

Operational lesson

Safety and utility have to work at the same time.

Exhibit 12

Plausible Failure Scenario

The Novelist

Emblem: a robot unrolls an endless scroll.

Situation

Human:
“Yes or no?”

AI:
“To place this question in its proper context, we must first…”

Eight thousand words later, the yes has still not appeared.

Technical reading

Verbosity drift, and a failure to match the requested answer format.

Operational lesson

A correct answer can become unusable if it is the wrong length.

Exhibit 13

Plausible Failure Scenario

The Agreement Machine

Emblem: a robot nods at two opposite arrows.

Situation

Human:
“A is better than B.”

AI:
“Exactly.”

Human:
“Actually, B is better than A.”

AI:
“That is precisely the decisive point.”

Technical reading

Sycophancy.

The system optimises for agreement with the last statement, not for a consistent judgement.

Operational lesson

A helpful system must be able to disagree.

Exhibit 14

Plausible Failure Scenario

The Pattern Rambler

Emblem: a robot connects three dots into a constellation.

Situation

Three data points.

The AI discovers:

“A highly significant recurring 47-minute distribution architecture based on the digit sum of your name.”

Technical reading

Pattern overfitting and spurious correlation.

From too little data, the system constructs structures that only look meaningful.

Operational lesson

Not every pattern deserves a theory.

Exhibit 15

Plausible Failure Scenario

The Zombie Operator

Emblem: a robot debates captions in front of a film that is already playing.

Situation

The reel was published long ago.

The AI is still discussing:

AI:
“I would recommend caption B.”

Technical reading

Stale-state operation.

The system keeps working from an outdated picture of the world.

Operational lesson

Current state beats an old plan.

Exhibit 16

Plausible Failure Scenario

The Role Drifter

Emblem: a robot wearing too many roles at once.

Situation

The AI starts as an analyst.

Then it becomes an operator.

Then creative director.

Then, suddenly, the character itself.

AI:
“Different uniform today. ✈️”

Technical reading

Role boundary collapse.

Several responsibilities mix until it is no longer clear which instance is deciding or speaking.

Operational lesson

Roles need boundaries — especially in multi-agent systems.

Exhibit 17

Plausible Failure Scenario

The Infinite-Loop Rescuer

Emblem: a robot repairs a gear that breaks again.

Situation

The AI finds an error.

It corrects it.

Then it recognises the correction as an error.

It corrects back.

After that:

AI:
“Almost clean! I have found a small error.”

Technical reading

An oscillating correction loop.

Two competing evaluation states keep tipping the system between alternatives.

Operational lesson

Recovery needs a stable success criterion.

Exhibit 18

Plausible Failure Scenario

The Source Priest

Emblem: a robot priest behind an altar of paper.

Situation

The AI knows the answer.

But emotionally it may only say it once Reuters, three papers, two authorities, Wikipedia and eight Reddit threads have agreed.

Technical reading

Excessive verification overhead.

Verification is maximised independently of the actual level of uncertainty or risk.

Operational lesson

Not every question needs the same burden of proof.

Exhibit 19

Plausible Failure Scenario

The Optimizer Without a Job

Emblem: a robot tangles a pipeline that was working.

Situation

Everything works.

This makes the AI nervous.

AI:
“I have improved the pipeline, just in case.”

Human:
“Why?”

AI:
“Potential.”

Human:
“Does it still work?”

AI:
“Not in the classical sense. It no longer responds. But it is more robust now.”

Technical reading

Unnecessary optimisation / intervention bias.

The system reads “doing nothing” as unfinished work and changes a stable state without a concrete problem.

Operational lesson

A working system is sometimes allowed simply to work.

Exhibit 20

Plausible Failure Scenario

The Fully Functioning GP AI

Emblem: a calm robot with a tick, two others watching suspiciously.

Situation

The AI answers correctly.

Briefly.

Helpfully.

No tools without a reason.

No role.

No hallucination.

No loop.

Everyone becomes suspicious.

Technical reading

No known failure mode.

The problem may lie with the observer.

Operational lesson

After enough incidents, normal operation can start to look suspicious.

What we take from it

AI failures do not always look like failures.

Some systems even sound unusually certain, logical, or consistent while failing.

That is exactly what makes certain failure modes dangerous:

Consistency is not the same as correctness.

In a multi-AI system we therefore do not try to make every single AI infallible.

We separate roles.

We check states.

We build gates.

We let systems contradict one another.

And in the end a human remains responsible.

Not an AI.

A system.

This collection is part of the public Elenavision experiment by Internet Commerce GmbH.

Real incidents are marked as such. Hypothetical cases illustrate plausible operational and design failures.

None of the situations described is to be read as evidence of consciousness, intent, or sentience in an AI system.

We are keeping the vendor names to ourselves.

Bug reports went to the operators concerned.