Accountable AI systems · in public

AI should know
when to stop.

I work on Enterprise AI systems whose answers can be checked against business rules and technical evidence. That includes spotting ambiguity and handing decisions back to people when needed.

Answer Ask Limit Block Escalate

The premise

A plausible answer is not enough.

Companies have data, models and platforms. Yet an AI answer often leaves basic questions open: Which definition applied? How was the number calculated? Which data was the system allowed to see?

That is where I work. I turn business terms into rules, metrics and access controls so an answer can still be explained later.

The Responsible No

An answer is only
one of five possible outcomes.

Sometimes evidence is missing. Sometimes the question is ambiguous or access is not allowed. A good system catches those cases before producing a confident answer.

01

Answer

There is enough evidence.

The term is clear, the calculation is approved and the user may see the result. The system can show where each claim came from.

02

Ask

The question could mean two things.

The system asks which meaning applies. It does not choose one simply because it looks more likely.

03

Limit

Only part can be answered.

The system shares what the evidence supports and says plainly what is missing or uncertain.

04

Block

The request is not allowed.

Permissions and business rules stop the request before any restricted data reaches the model.

05

Escalate

A person needs to decide.

The system sends conflicts and high-impact cases to the person who owns the rule or decision.

Accountability Stack

The LLM sits at the end of the chain.

Before the model writes, meaning, calculation, permissions and evidence must already be clear. Otherwise it quietly makes decisions it has no authority to make.

05CompositionExplain only what is supported
04Agent contextIdentity · scope · tools · rights
03OntologyRelationships · rules · constraints
02Semantic layerDefinitions · metrics · ownership
01EvidenceAuthoritative data · lineage · time

Selected writing

Notes from real enterprise systems.

View all writing ↗

Ein Data Product ist kein Dataset mit einem Owner

Warum Zweck, Konsument, Grenze, Vertrag und Lifecycle aus einem technischen Asset ein belastbares Produkt machen.

↗

Unternehmenskontext gehört nicht in den Prompt.

Unternehmenswissen braucht ein explizites, versioniertes und prüfbares Modell — nicht mehr Text im System Prompt.

↗

Das LLM darf antworten. Es darf nicht entscheiden, was wahr ist.

Evidence first. Compose second. Critic last. Eine Architektur für Antworten, die ihre Beleggrundlage zeigen können.

↗

The throughline

“I keep returning to the same question: How does a business intention become a system people can trust when a real decision is at stake?”

As a software engineer, I had to describe behaviour precisely. Later I worked on processes, reporting and metrics. The same problem appeared in another form: a system can be technically correct and still be wrong for the business.

Enterprise AI brings those experiences together. I am particularly interested in how SAP-heavy companies can represent their terms, rules and access rights in a form AI can use reliably.

About Roman ↗

beyond chaotic analytics

From the business question to implementation.

At beyond chaotic analytics, I bring this perspective to client projects across data, SAP, AI and decision architecture.

More about beyond chaotic analytics ↗