Notizen aus der Praxis.

Was diese Woche passiert ist

Anthropic hat am 8. Mai eine Forschungsarbeit unter dem Titel „Teaching Claude Why” veröffentlicht. Kurzfassung: Das Unternehmen erklärt detailliert, wie Claude nicht nur darauf trainiert wird, was zu tun ist, sondern warum bestimmte Antworten richtig oder falsch sind. Statt dem Modell nur Verhaltensregeln einzubläuen („Antworte nicht auf Frage X”), bekommt es die Begründung mitgeliefert („Antworte nicht, weil daraus folgendes Risiko entsteht”).

Der Beitrag landete mit 110 Punkten und 43 Kommentaren auf der Hacker-News-Frontpage — was in der Entwickler-Community ein klares Signal ist: Das Thema trifft einen Nerv. Die Diskussion dreht sich vor allem um eine Frage: Macht „Begründungs-Training” Modelle wirklich robuster — oder produziert es nur eloquentere Ausreden, wenn das Modell scheitert?

Für KMU klingt das auf den ersten Blick nach akademischer Forschung. Ist es aber nicht. Hier kommt das Warum.

Warum das jetzt für österreichische KMU zählt

Die meisten KMU, die ich berate, behandeln Sprachmodelle wie eine Black Box: Frage rein, Antwort raus, fertig. Funktioniert in 80 Prozent der Fälle. Die anderen 20 Prozent — und genau da entstehen die teuren Probleme — sind die, in denen das Modell nachvollziehbar handeln muss, nicht nur richtig.

Typisches Beispiel aus der Praxis: Ein Steuerberatungsbüro setzt Claude für eine erste Mandantenanfrage-Filterung ein. Das Modell verweigert plötzlich Auskunft zu einer harmlosen umsatzsteuerlichen Frage, weil es im Training gelernt hat, „keine rechtsverbindlichen Steuerauskünfte zu geben”. Aus Sicht des Modells: korrekt. Aus Sicht des Geschäftsführers: kaputt. Aus Sicht des Mandanten, der nun zwei Tage auf eine Antwort wartet: ärgerlich.

Genau hier setzt der Anthropic-Ansatz an. Wenn das Modell nicht nur die Regel kennt, sondern den Grund, kann es besser unterscheiden: „Steuerliche Grundsatzauskunft mit Disclaimer” ist etwas anderes als „individuelle verbindliche Rechtsauskunft im Einzelfall”. Das erste ist sinnvoll, das zweite tatsächlich problematisch.

Aus meiner Sicht ist diese Veröffentlichung aus drei Gründen wichtig:

Erstens: Transparenz wird zum Auswahlkriterium. Bisher war die Modellauswahl für KMU meist eine Frage von Preis und Latenz. Wer im B2B-Bereich KI einsetzt — und gegenüber Kunden, Mitarbeitern oder Aufsichtsbehörden erklären muss, warum die KI dies oder jenes tut — wird zunehmend Anbieter bevorzugen, die offenlegen, wie trainiert wurde. Anthropic positioniert sich hier bewusst.

Zweitens: Der EU AI Act greift. Seit Februar 2025 sind die ersten Verpflichtungen des AI Act in Kraft, weitere folgen schrittweise bis 2027. Für Hochrisiko-Anwendungen — und dazu zählt überraschend viel im KMU-Bereich, etwa HR-Tools oder Kreditscoring — ist Erklärbarkeit nicht Kür, sondern Pflicht. Wer einen Anbieter wählt, der das Werte-Training dokumentiert, hat es bei der Compliance-Dokumentation deutlich leichter.

Drittens: Halluzinationen bekommen einen neuen Charakter. Modelle, die mit Begründungslogik trainiert sind, halluzinieren nicht weniger — aber sie halluzinieren anders. Sie produzieren plausibler klingende Falschauskünfte, weil sie auch die Begründung gleich miterfinden. Das ist gefährlicher, nicht harmloser. Wer das nicht versteht, prüft die Outputs falsch.

Was Sie diese Woche konkret tun sollten

Drei Schritte, in der Reihenfolge:

1. Inventur Ihrer KI-Einsätze: Wo ist „warum” wichtig?

Gehen Sie Ihre aktuellen Use-Cases durch und markieren Sie jeden, bei dem ein Mensch — Kunde, Mitarbeiter, Prüfer — irgendwann fragen könnte: „Warum hat die KI das so entschieden?” Bei reinen Produktivitäts-Tasks (E-Mail-Entwürfe, Zusammenfassungen) ist die Antwort meist: egal. Bei allem mit Außenwirkung, rechtlicher Relevanz oder Personalbezug ist die Antwort: kritisch. Letztere Use-Cases brauchen eine Modellwahl und Prompt-Architektur, die Begründungen mitliefert.

2. Prüfprozess anpassen: Stichproben mit Begründungs-Fokus.

Wenn Sie heute KI-Outputs stichprobenweise kontrollieren — gut. Wenn nicht — fangen Sie an. Wichtiger Punkt: Prüfen Sie nicht nur, ob die Antwort richtig ist, sondern auch, ob die mitgelieferte Begründung trägt. Eine Faustregel aus meinen Projekten: Bei 5 Prozent der Outputs stimmt das Ergebnis, aber die Begründung ist erfunden. Genau diese Fälle sind die gefährlichsten, weil sie bei der nächsten ähnlichen Anfrage zu falschen Ergebnissen führen werden.

3. Anbieter-Gespräch führen — auch wenn Sie zufrieden sind.

Fragen Sie bei Ihrem aktuellen KI-Anbieter (OpenAI, Anthropic, Google, Microsoft, lokale Provider) konkret nach: Wie wird das Modell auf Werte trainiert? Gibt es eine Constitution oder ein vergleichbares Dokument? Wie wird Begründungsfähigkeit getestet? Wenn der Vertriebskontakt nicht antworten kann, eskalieren Sie zur technischen Ebene. Wenn auch dort keine substanzielle Antwort kommt, ist das selbst ein Signal — vor allem, falls Sie 2026 oder 2027 in den AI-Act-Hochrisiko-Bereich fallen.

Mein Rat zum Schluss

Der Anthropic-Beitrag ist Marketing — natürlich. Anthropic positioniert sich als der „durchdachte” Anbieter, im Gegensatz zur Geschwindigkeits-Konkurrenz. Aber das Marketing hat einen wahren Kern: Modelle, die ihre Werte begründen können, sind in regulierten Umgebungen leichter einzusetzen. Und „regulierte Umgebung” wird in den nächsten 24 Monaten für viele KMU nicht mehr „die anderen” bedeuten, sondern „uns”.

Wer jetzt eine KI-Strategie aufsetzt, sollte Erklärbarkeit nicht als Bonus betrachten, sondern als Grundanforderung. Nicht weil es schick ist — sondern weil die Alternative ist, in zwei Jahren eine bereits produktive Lösung wieder auszutauschen. Das ist teurer als von Anfang an richtig zu wählen.

Was diese Woche passiert ist

Timothy Gowers, Mathematiker und Fields-Medaillist, hat in seinem Blog einen ausführlichen Praxisbericht zu ChatGPT 5.5 Pro veröffentlicht. Der Beitrag landete auf Hacker News mit über 600 Punkten und 445 Kommentaren — ein Indikator, dass die Tech-Community genau hinschaut.

Gowers testet das Modell nicht an Benchmarks, sondern an einem konkreten Forschungsproblem. Sein Befund, verkürzt: 5.5 Pro liefert auf hohem Niveau, macht aber weiterhin Fehler, die ein Fachmensch sofort erkennt — und ein Laie eben nicht. Das Modell argumentiert flüssig, zieht plausible Zwischenschritte und liegt trotzdem an entscheidenden Stellen daneben.

Das ist keine Sensationsmeldung. Aber genau deshalb ist sie interessant.

Warum das jetzt für KMU zählt

Seit den 5er-Releases häufen sich in meiner Beratungspraxis zwei Fragen: „Sollen wir auf das neue Modell upgraden?” und „Können wir damit endlich Aufgabe X automatisieren, die letztes Jahr noch nicht ging?”

Der Gowers-Bericht ist ein nüchterner Datenpunkt gegen beide Extremreaktionen.

Extrem 1: „Die neuen Modelle sind schon fast AGI, wir können alles delegieren.” Nein. Wenn ein Top-Mathematiker an einem Fachproblem strukturelle Fehler findet, dann findet Ihre Steuerberaterin, Ihr Anwalt, Ihre Konstrukteurin die analogen Fehler in ihren Fachgebieten auch. Die Modelle sind besser geworden, aber das Muster bleibt: souveräne Sprache, fallweise falscher Inhalt. Wer das in einen unbeaufsichtigten Workflow steckt, kauft sich Risiken ein, die er später teuer bezahlt.

Extrem 2: „Solange Halluzinationen vorkommen, ist das alles unbrauchbar.” Auch nein. Gowers beschreibt durchaus, dass das Modell ihm beim Denken hilft — als Sparring-Partner, als Ideengeber, als jemand, der schnell mögliche Ansätze skizziert. Genau das ist der Modus, in dem KMU heute echten Nutzen ziehen.

Aus meiner Sicht ist die zentrale Lehre des Berichts nicht „5.5 Pro ist gut” oder „5.5 Pro ist schlecht”. Sie lautet: Das Delta zwischen den Generationen wird kleiner, das Delta zwischen guter und schlechter Anwendung im Unternehmen wird größer.

Konkret: Wer 2024 mit GPT-4 keinen Wert gehoben hat, wird mit 5.5 Pro auch keinen heben. Das Modell ist nicht das Bottleneck. Das Bottleneck sind Prozesse, Datenzugriff, Review-Schritte und die Frage, welche Aufgaben überhaupt sinnvoll an ein Sprachmodell delegierbar sind.

Was das für die Modell-Wahl bedeutet

Ein häufiges Muster in KMU-Projekten: Es wird monatelang debattiert, ob man GPT-5, 5.5 Pro, Claude oder Gemini nimmt — und am Ende läuft die Lösung in 80 Prozent der Fälle mit jedem dieser Modelle vergleichbar gut. Die Unterschiede sind real, aber sie wirken sich oft erst an den Rändern aus: bei langen Kontexten, bei strikter Strukturtreue, bei sehr spezifischen Fachdomänen.

Für die meisten KMU-Use-Cases — Angebotsentwürfe, E-Mail-Triagierung, Protokoll-Zusammenfassungen, interne Wissenssuche, Code-Snippets — ist die Modellklasse wichtiger als das konkrete Modell. Und ein Pro-Tier kostet pro Sitzplatz ein Mehrfaches des Standard-Tiers.

Mein Rat: Testen Sie den Mehrwert eines Pro-Modells an Ihren tatsächlichen Aufgaben, nicht an Demo-Prompts. Geben Sie zwei oder drei Mitarbeitenden für vier Wochen Zugang, lassen Sie sie täglich vergleichen — gleiche Aufgabe, beide Modelle, kurze Notiz, welches Ergebnis besser war und warum. Nach vier Wochen haben Sie eine Entscheidungsgrundlage, die mehr wert ist als jeder Benchmark.

Drei konkrete Schritte für diese Woche

1. Reality-Check im Team. Fragen Sie diese Woche in einer 30-Minuten-Runde: Wo nutzt jemand bei uns ein KI-Modell für etwas, das die Person fachlich nicht selbst beurteilen kann? Das sind Ihre Risikostellen — unabhängig davon, welches Modell läuft. Dort braucht es entweder einen Review-Schritt oder einen Rückzug aus diesem Use-Case.

2. Upgrade-Frage entkoppeln. Trennen Sie zwei Entscheidungen, die oft vermischt werden: a) Welches Modell nutzen wir? b) Welche Aufgaben lassen wir KI machen? Frage b) ist deutlich wichtiger und unabhängig vom Modell. Wer mit der Antwort auf b) klar ist, beantwortet a) in zehn Minuten.

3. Eine Aufgabe diese Woche neu prüfen. Nehmen Sie genau einen Workflow, den Sie vor 12 Monaten als „geht mit KI noch nicht” abgehakt haben — und testen Sie ihn mit einem aktuellen Modell. Nicht alle, einen. Die Modelle haben sich bewegt, manche Use-Cases sind jetzt im grünen Bereich. Andere weiterhin nicht. Sie wissen es erst, wenn Sie es prüfen.

Was ich aus dem Gowers-Bericht mitnehme

Die ehrlichen Praxisberichte von Leuten, die ein Modell wirklich an seinem Anschlag testen, sind aktuell wertvoller als die offiziellen Release-Folien. Gowers ist nicht der einzige, der so etwas öffentlich macht — aber die Kombination aus fachlicher Tiefe und nüchternem Ton ist selten.

Für KMU heißt das: Lesen Sie solche Berichte. Nicht, um eine Modell-Entscheidung daran festzumachen, sondern um ein realistisches Bild zu bekommen, wo die Werkzeuge wirklich stehen. Zwischen Marketing und Untergangsstimmung gibt es eine breite Mitte, in der seit Monaten ordentliche Produktivitätsgewinne entstehen — bei den Firmen, die Prozesse statt Modelle in den Mittelpunkt stellen.

Was diese Woche bekannt wurde

Auf Hacker News steht seit einigen Tagen ein Paper weit oben in der Diskussion: „LLMs corrupt your documents when you delegate” (arxiv.org/abs/2604.15597), 376 Punkte, 146 Kommentare. Der Kern in einem Satz: Sobald man einem Sprachmodell die Aufgabe gibt, ein bestehendes Dokument zu bearbeiten — also nicht nur zusammenzufassen, sondern zu verändern, zu ergänzen oder neu zu strukturieren — verändert das Modell systematisch auch Inhalte, die es eigentlich unangetastet lassen sollte.

Das ist kein Halluzinations-Problem im klassischen Sinn. Es ist subtiler. Das Modell formuliert Sätze um, ersetzt Zahlen durch „plausibel klingende” Werte, glättet Widersprüche im Originaltext und entfernt scheinbar redundante Passagen, die für den menschlichen Autor aber Bedeutung hatten. Wer das Ergebnis nur überfliegt, merkt es nicht.

Die Autorinnen und Autoren bezeichnen das als „Document Drift” — Dokumenten-Verschiebung — und zeigen, dass das Phänomen über alle gängigen Modellfamilien hinweg auftritt: GPT-Klasse, Claude, Gemini, offene Modelle. Je mehr Autonomie das Modell bekommt (Stichwort Agenten-Setups mit mehreren Bearbeitungsschritten), desto stärker der Drift.

Warum das jetzt für österreichische KMU zählt

Ich sehe in meiner Beratung gerade einen klaren Trend: KMU experimentieren nicht mehr nur mit ChatGPT als Schreibhilfe. Sie bauen kleine Agenten-Workflows. Typisches Beispiel: Ein Tool liest eingehende Angebote ein, ein LLM extrahiert die Eckdaten, ein zweiter Schritt aktualisiert die interne Kalkulation, ein dritter erzeugt das Antwortschreiben. Das funktioniert beeindruckend gut — bis es das nicht mehr tut.

Genau hier trifft die Studie ins Schwarze. Drei Punkte sind aus meiner Sicht für KMU besonders relevant:

1. Der Fehler ist unsichtbar, bis er teuer wird. Wenn ein LLM in einem 12-seitigen Vertragsentwurf einen Liefertermin von „14 Werktagen” zu „14 Tagen” umformuliert, ist das juristisch ein Unterschied. Wenn in einem Kalkulationsblatt eine Marge von 18,5 % zu 18 % „aufgerundet” wird, ist das ein Unterschied. Solche Änderungen fallen bei einer schnellen Sichtprüfung nicht auf.

2. Je länger die Kette, desto schlimmer. Die Studie zeigt: Bei mehrstufigen Agenten-Workflows multipliziert sich der Drift. Schritt 1 verändert eine Kleinigkeit, Schritt 2 baut darauf auf, Schritt 3 zementiert es. Am Ende stimmt das Dokument intern — entspricht aber nicht mehr dem Original.

3. Es betrifft nicht nur Text. Das Phänomen tritt auch bei strukturierten Dokumenten auf: Tabellen, JSON-Konfigurationen, sogar CSV-Exporten. Überall dort, wo das Modell „verstehen” und „neu schreiben” muss.

Aus meiner Sicht ist das keine Panikmeldung. Aber es ist ein Realitätscheck. Die Diskussion in Wien und Linz dreht sich gerade stark um „Agentic AI” und „autonome Workflows”. Diese Studie ist ein Datenpunkt, der zeigt: Autonomie ohne Kontrolle ist im Geschäftskontext teuer.

Was ich KMU jetzt rate

Drei konkrete Schritte, die sich diese Woche umsetzen lassen — ohne Agentur, ohne Großprojekt:

Schritt 1: Trennen Sie Lese-Aufgaben von Schreib-Aufgaben.

LLMs sind hervorragend darin, Dokumente zu analysieren, zu klassifizieren, zu kommentieren und Vorschläge zu generieren. Sie sind problematisch, sobald sie das Original-Dokument direkt überschreiben dürfen. Mein Rat: Lassen Sie das Modell einen Vorschlag erzeugen — als separates Dokument, als Diff, als strukturierten Output — aber den finalen Schritt „Original ersetzen” macht ein Mensch oder ein deterministisches Skript mit klaren Regeln.

Konkret: Wenn Sie heute einen Prompt haben, der lautet „Überarbeite das angehängte Angebot und gib es zurück”, ändern Sie ihn zu „Liste die vorgeschlagenen Änderungen am angehängten Angebot strukturiert auf — Originaltext, Vorschlag, Begründung”. Der Mensch entscheidet dann pro Position.

Schritt 2: Führen Sie ein Diff-Logging ein.

Wenn Sie schon einen Workflow haben, bei dem ein LLM Dokumente bearbeitet, dann speichern Sie die Differenz zwischen Input und Output. Bei Textdokumenten reicht ein einfaches Git-Diff oder ein Tool wie diff-match-patch. Bei strukturierten Daten ein JSON-Diff. Schauen Sie sich stichprobenhaft die Diffs an — Sie werden überrascht sein, was das Modell „nebenbei” verändert.

Häufiges Muster, das ich gerade sehe: Kunden glauben, das Modell habe nur Tippfehler korrigiert, weil das Ergebnis „gleich aussieht”. Ein 30-Sekunden-Diff zeigt dann, dass auch Beträge, Datumsangaben oder Klauseln betroffen sind.

Schritt 3: Definieren Sie Sperrzonen.

In jedem geschäftlichen Dokument gibt es Bereiche, die ein LLM unter keinen Umständen verändern darf: Preisangaben, juristische Klauseln, Vertragsnummern, Unterschriftenfelder. Markieren Sie diese Bereiche im Input klar — etwa mit Tags wie LOCKED — und bauen Sie eine deterministische Prüfung nach dem Modell-Lauf ein, die sicherstellt, dass diese Bereiche byte-identisch sind. Das ist zehn Zeilen Code und verhindert die teuersten Fehlerklassen.

Der größere Punkt

Das Paper ist kein Argument gegen LLMs im KMU-Einsatz. Es ist ein Argument gegen blinde Delegation. Die Modelle werden besser — aber das Grundproblem („das Modell entscheidet, was wichtig ist”) verschwindet nicht durch ein Versions-Update. Es muss durch Workflow-Design adressiert werden.

Wer 2026 produktiv mit KI arbeitet, baut nicht den autonomsten Agenten. Wer produktiv arbeitet, baut den Workflow mit dem klarsten Kontroll-Punkt zwischen Modell-Output und Geschäftsdokument. Das ist weniger spektakulär in der Demo — und deutlich robuster im Betrieb.

Wenn Sie unsicher sind, wo in Ihren bestehenden Prozessen schon LLMs Dokumente direkt verändern: Eine halbtägige Bestandsaufnahme reict meist, um die kritischen Stellen zu finden. Genau da sollte man jetzt hinsehen — nicht beim nächsten Auditbericht.

Was passiert ist

Diese Woche wurde bekannt: Zwei Mitarbeiter des südafrikanischen Innenministeriums (Department of Home Affairs) sind suspendiert worden, nachdem sie in offiziellen Dokumenten KI-generierte Inhalte verwendet hatten — inklusive frei erfundener Gerichtsurteile und Quellen. Der Fall wurde von der Citizen am 7. Mai aufgegriffen und schaffte es prompt auf die Hacker-News-Frontpage.

Der Ablauf ist mittlerweile ein bekanntes Muster: Mitarbeiter nutzt ChatGPT oder ein vergleichbares Tool, kopiert den Output ungeprüft in ein Schriftstück, das Schriftstück geht raus, jemand prüft die zitierten Quellen — und stellt fest, dass mehrere davon schlicht nicht existieren. In den USA gab es bereits 2023 den prominenten Fall der Anwaltskanzlei Levidow, bei dem ein Anwalt vor Gericht ChatGPT-Halluzinationen als Präzedenzfälle einreichte. Seitdem ist die Liste länger geworden — und jetzt eben auch bei einer Behörde angekommen.

Die suspendierten Beamten haben offenbar weder die Quellen verifiziert noch transparent gemacht, dass KI im Einsatz war. Beides sind die Standardfehler, die ich auch in österreichischen KMU regelmäßig sehe.

Warum das jetzt für KMU zählt

Viele Geschäftsführer nehmen solche Fälle als Behörden-Schlamperei wahr und denken: Bei uns läuft das anders. Aus meiner Sicht ist das gefährlich naiv.

In fast jedem Beratungsmandat sehe ich denselben Zustand: ChatGPT, Copilot oder Claude werden bereits intensiv genutzt — nur weiß die Geschäftsleitung nichts davon. Mitarbeiter im Vertrieb lassen Angebotstexte generieren. Die Buchhaltung fragt das LLM nach steuerlichen Einschätzungen. HR lässt Stellenbeschreibungen schreiben. Niemand dokumentiert das, niemand prüft die Outputs systematisch.

Typisches Beispiel aus dem letzten Quartal: Ein Industriebetrieb mit 80 Mitarbeitern. Ein Projektleiter hat Sicherheitsdatenblätter teilweise per ChatGPT recherchiert und Werte übernommen, die plausibel aussahen, aber falsch waren. Aufgefallen ist es nur, weil ein Lieferant nachgefragt hat. Schaden: gering, weil rechtzeitig korrigiert. Das Problem: Niemand wusste, dass dieses Tool überhaupt verwendet wurde.

Der Home-Affairs-Fall ist deshalb relevant, weil er drei Dinge gleichzeitig zeigt:

1. Konsequenzen sind real. Suspendierung, öffentliche Berichterstattung, Reputationsschaden für die Behörde. Im KMU-Kontext kann genau das auch passieren — nur dass dort schneller ein Kunde, ein Auditor oder ein Gericht involviert ist.
2. Hierarchie schützt nicht. Wer denkt, dass nur unbedarfte Praktikanten halluzinierende Texte übernehmen, irrt. Die Beamten waren keine Anfänger. Halluzinationen sehen überzeugend aus — das ist ja der Punkt.
3. Die Tools selbst sind nicht das Problem. Niemand schlägt vor, ChatGPT bei Behörden zu verbieten. Das Problem ist der unkontrollierte Einsatz ohne Verifikationsschritt.

Dazu kommt: Mit dem EU AI Act, der seit Februar 2025 in den ersten Stufen anwendbar ist, gibt es zunehmend formale Anforderungen — gerade an Hochrisiko-Anwendungen wie HR-Entscheidungen oder rechtliche Bewertungen. Wer hier ohne interne Regelung arbeitet, hat nicht nur ein Qualitätsrisiko, sondern auch ein Compliance-Risiko.

Was Sie konkret tun sollten

Mein Rat ist pragmatisch und nicht aufwendig. Drei Schritte, die jedes KMU diese Woche umsetzen kann:

1. Bestandsaufnahme statt Verbot. Fragen Sie aktiv im Team: Wer nutzt welche KI-Tools wofür? Anonym, ohne Sanktionsdrohung. Das Ergebnis wird Sie überraschen. Erst wenn Sie wissen, wo KI bereits im Einsatz ist, können Sie sinnvoll regeln. Ein Verbot ohne Bestandsaufnahme treibt die Nutzung nur in die Schatten — Mitarbeiter verwenden dann private Accounts auf privaten Geräten, womit auch noch Datenschutz-Themen dazukommen.

2. Eine kurze, klare KI-Richtlinie. Maximal zwei Seiten, kein juristisches Pamphlet. Drei Punkte müssen drinstehen: a) Welche Tools sind freigegeben (z. B. der Firmen-Account von ChatGPT Team oder Microsoft Copilot mit Datenschutz-Setting), welche nicht. b) Welche Daten dürfen rein (keine personenbezogenen Daten von Kunden, keine Kalkulationsgrundlagen, keine Verträge ohne Anonymisierung). c) Die Verifikationspflicht: Jeder KI-Output, der nach außen geht oder eine Entscheidung beeinflusst, muss von einem Menschen geprüft werden. Bei Zahlen, Quellen, Zitaten und rechtlichen Aussagen explizit.

3. Den Verifikationsschritt einüben. Das ist der eigentliche Hebel. Reden Sie mit Ihrem Team darüber, wie LLMs funktionieren — nämlich als Wahrscheinlichkeitsmaschinen, nicht als Wissensdatenbanken. Halluzinationen sind kein Bug, sondern Teil der Funktionsweise. Für kritische Outputs gilt: Quelle nachschlagen, Zahl gegenprüfen, Aussage durch eine zweite Quelle bestätigen lassen. Bei juristischen oder steuerlichen Themen: Niemals ohne Fachperson freigeben.

Für die Umsetzung brauchen Sie keine Beratung und kein Tool. Eine interne Mail, ein 30-Minuten-Termin im Team-Meeting und ein gemeinsam abgestimmtes Dokument reichen aus. Wer es ernster aufziehen will, kombiniert das mit einer kurzen Schulung — aber das ist Kür, nicht Pflicht.

Fazit

Der Fall in Südafrika ist kein Exot. Es ist die Vorschau auf das, was in den nächsten 12 bis 24 Monaten in vielen Organisationen passieren wird — auch in österreichischen KMU. Der Unterschied zwischen den Betrieben, bei denen es glimpflich ausgeht, und denen, bei denen es teuer wird, ist nicht das eingesetzte Tool. Es ist die Frage, ob es eine klare Regel gab und ob die Verifikation Teil des Prozesses war.

Wer das jetzt aufsetzt, hat es hinter sich. Wer wartet, bis der eigene Vorfall passiert, bezahlt die Lernkurve teurer.

Was diese Woche passiert ist

Am 7. Mai ist auf Hacker News ein Beitrag mit dem Titel „Agents need control flow, not more prompts” (sinngemäß: „Agenten brauchen Steuerlogik, keine zusätzlichen Prompts”) in die Top-Liste gewandert: 406 Punkte, über 200 Kommentare. Der Autor argumentiert, dass die meisten produktiven Agenten-Systeme nicht durch ausgefeiltere Prompts besser werden, sondern durch klassische Software-Architektur drumherum: Bedingungen, Schleifen, Retries, State-Machines, Validierung.

Die Diskussion in den Kommentaren fällt ungewöhnlich einig aus — und das ist im HN-Kontext bemerkenswert. Praktiker aus Anbau und Betrieb von LLM-Anwendungen bestätigen reihenweise: Wer Agenten nur mit längeren Systemprompts oder mehr Tools füttert, baut Systeme, die zu 70% funktionieren und zu 30% unvorhersehbar sind. Genau die 30% sind der Grund, warum viele Pilotprojekte nie in Produktion gehen.

Warum das jetzt für KMU zählt

In der österreichischen Beratungspraxis sehe ich seit etwa einem Jahr ein Muster, das exakt zum HN-Artikel passt: Ein Unternehmen startet mit einem GPT- oder Claude-basierten Agenten, der eine bestimmte Aufgabe lösen soll — Angebote vorbereiten, Kundenanfragen klassifizieren, Rechnungen prüfen. In den ersten Demos läuft alles gut. Dann kommt der Realbetrieb, und plötzlich häufen sich Fehler: Der Agent ruft Tools in der falschen Reihenfolge auf, vergisst Zwischenergebnisse, erzeugt halluzinierte Felder oder läuft in Endlosschleifen.

Die typische erste Reaktion: Man verlängert den Systemprompt. Aus 200 Wörtern werden 800, dann 1.500. Es werden Beispiele eingefügt, Verbote, „Du MUSST...”-Anweisungen in Großbuchstaben. Das hilft kurz — und macht das System mittelfristig schlechter, weil jede Änderung neue Nebenwirkungen produziert.

Aus meiner Sicht ist genau das die Stelle, an der viele KMU-Projekte falsch abbiegen. Ein LLM ist eine Komponente, kein Programm. Wer ihm die gesamte Steuerlogik überlässt, verlagert die Verantwortung an die unzuverlässigste Stelle des Systems.

Konkret: Wenn ein Agent für eine Angebotserstellung die Schritte „Kundendaten holen → Produktverfügbarkeit prüfen → Preis berechnen → Dokument generieren → ins CRM speichern” durchlaufen soll, dann gehören diese Schritte in normalen Code. Das LLM macht innerhalb jedes Schrittes das, was es gut kann — Texte verstehen, klassifizieren, formulieren. Was es nicht macht: entscheiden, ob Schritt 3 vor Schritt 2 ausgeführt werden darf.

Das technische Argument in einem Satz

LLMs sind exzellent darin, unstrukturierten Input in strukturierten Output zu verwandeln. Sie sind schlecht darin, einen mehrstufigen Prozess zuverlässig zu orchestrieren. Steuerlogik gehört in deterministischen Code; Sprachverstehen gehört ins Modell. Wer beides vermischt, bekommt ein System, das man weder testen noch debuggen kann.

Das ist kein neues Argument — aber es ist eines, das durch die Hot-Take-Welle der letzten zwei Jahre („Just add an agent!”) systematisch übertönt wurde. Frameworks wie LangGraph, das aktuelle OpenAI Agents SDK oder das, was Anthropic in den Claude-Skills-Patterns dokumentiert, gehen alle in dieselbe Richtung: explizite Graphen, definierte Zustände, klare Übergänge. Das ist im Kern Software-Engineering aus den 1990ern, nur mit einem LLM in den Knoten.

Was das praktisch für KMU bedeutet

Wenn Sie aktuell ein KI-Agenten-Projekt laufen haben — intern oder mit einer Agentur —, dann lohnen sich diese drei Schritte diese Woche:

1. Stellen Sie eine ehrliche Frage zur Architektur. Lassen Sie sich vom Umsetzer ein Diagramm geben: Welche Schritte laufen im Code, welche im LLM? Wenn die Antwort lautet „das LLM entscheidet selbst, was als Nächstes passiert”, ist das ein Warnsignal. Nicht zwingend ein KO-Kriterium — aber Sie sollten verstehen, wie Fehlerfälle abgefangen werden, wie Wiederholungen funktionieren und wie der Zustand zwischen den Schritten gespeichert wird.

2. Trennen Sie Wahrnehmung von Aktion. Ein praktikables Muster für KMU-Projekte: Das LLM darf interpretieren, klassifizieren, extrahieren, formulieren — also alles, was mit Sprache zu tun hat. Aktionen mit Konsequenzen (Datenbank schreiben, E-Mail versenden, Zahlung auslösen) gehören hinter eine deterministische Schicht, die validiert und gegebenenfalls einen Menschen einbindet. Diese Trennung kostet ein paar Tage Mehrarbeit beim Bauen und spart Wochen beim Betreiben.

3. Definieren Sie messbare Erfolgskriterien pro Schritt, nicht nur fürs Gesamtsystem. „Der Agent funktioniert zu 90%” ist keine Metrik. „Die Kundendaten-Extraktion ist in 98% der Fälle korrekt, die Preisberechnung in 100%, die Dokumentgenerierung in 95%” ist eine. Sobald Sie pro Schritt messen, sehen Sie sofort, wo das LLM überfordert ist — und wo Sie tatsächlich nur Code brauchen.

Mein Rat für die nächsten 30 Tage

Wer 2026 in KI investiert, hat in der Regel ein Budget zwischen 20.000 und 150.000 Euro für ein erstes ernsthaftes Projekt. Mein Rat: Geben Sie nicht mehr als ein Drittel davon für die LLM-Integration aus. Der Rest fließt in Datenanbindung, Steuerlogik, Logging, Monitoring und Fehlerbehandlung. Ein Projekt, dessen Code-zu-Prompt-Verhältnis bei 1:1 oder schlechter liegt, wird mit hoher Wahrscheinlichkeit nicht in den Regelbetrieb kommen.

Die HN-Diskussion bestätigt etwas, das in den letzten Monaten zwischen den vielen Modell-Releases unterzugehen drohte: Der Engpass produktiver KI-Anwendungen liegt nicht mehr beim Modell. Er liegt in der Architektur drumherum. Genau das ist die gute Nachricht für KMU — denn solide Architektur ist eine Disziplin, die in Österreich viele Entwicklungspartner beherrschen. Man muss sie nur einfordern.

Was passiert ist

Das Kammergericht Berlin hat diese Woche Anwälte öffentlich gerügt, weil sie in Rechtsmittelschriftsätzen erfundene Aktenzeichen und nicht existierende Urteile zitiert haben. Die Quelle: ein Sprachmodell, vermutlich ChatGPT oder ein vergleichbares Tool. Heise berichtete am 7. Mai über den Vorfall und die deutliche Mahnung des Gerichts an die anwaltliche Prüfpflicht.

Für alle, die das Muster nicht kennen: Sprachmodelle erfinden bei juristischen Fragen regelmäßig Fundstellen. Sie liefern formal korrekt aussehende Aktenzeichen wie „BGH, Urteil vom 14.03.2021 – VIII ZR 112/20” — nur existiert das Urteil nicht. Der Text klingt plausibel, die Struktur stimmt, der Inhalt ist frei erfunden. In den USA gab es 2023 den Fall Mata v. Avianca, bei dem ein New Yorker Anwalt aus genau diesem Grund mit 5.000 USD Strafe belegt wurde. Jetzt ist das Phänomen offiziell auch in der deutschen Justiz angekommen.

Das Kammergericht hat es bei einer Rüge belassen. Beim nächsten Fall wird das vermutlich nicht mehr so glimpflich ausgehen. Berufsrechtliche Konsequenzen, Haftungsfragen gegenüber Mandanten und Schadenersatzforderungen sind absehbar.

Warum das jetzt für KMU zählt

Sie denken vielleicht: „Ich bin kein Anwalt, was geht mich das an?” Mehr als Sie glauben. Der Berliner Fall ist nur die sichtbare Spitze. Das gleiche Muster passiert täglich in Buchhaltungen, Personalabteilungen, im Vertrieb und in der Geschäftsführung — nur fällt es dort niemandem auf, weil keine Richterin gegenliest.

Typische Beispiele aus meiner Beratungspraxis:

• Ein KMU lässt sich von ChatGPT die korrekte Vorgangsweise bei einer Kündigung im österreichischen Arbeitsrecht erklären. Das Modell zitiert Paragraphen aus dem deutschen BGB, die hier nicht gelten.
• Eine Buchhaltungskraft fragt nach der Behandlung eines USt-Sachverhalts. Die Antwort vermischt deutsche und österreichische Regelungen, klingt aber souverän.
• Im Vertrieb erstellt jemand eine Wettbewerbsanalyse mit KI. Drei der fünf zitierten Marktstudien existieren nicht.

Der gemeinsame Nenner: Das Modell weiß nicht, dass es nichts weiß. Und der Mensch davor kann die Qualität nicht prüfen, weil er sonst die KI gar nicht erst gefragt hätte.

Aus meiner Sicht ist die Berliner Rüge ein wichtiges Signal — nicht weil Anwälte besonders dumm wären, sondern weil hier zum ersten Mal eine staatliche Stelle in Deutschland klar sagt: Die Prüfpflicht liegt beim Menschen. Wer KI-Output ungeprüft weiterverwendet, haftet dafür. Das gilt analog für Geschäftsführer, die KI-Texte unterschreiben, für Buchhalter, die KI-Berechnungen einreichen, und für alle, die KI-generierte Behauptungen gegenüber Kunden oder Behörden verwenden.

Die EU-KI-Verordnung verschärft das Bild zusätzlich. Wer KI in Bereichen mit rechtlicher Außenwirkung einsetzt, muss dokumentieren können, wie geprüft wurde. Eine pauschale Aussage „Wir nutzen ChatGPT” reicht in einem Haftungsfall nicht aus.

Was KMU jetzt konkret tun sollten

Drei Schritte, die Sie diese Woche umsetzen können:

1. Klassifizieren Sie Ihre KI-Anwendungsfälle nach Risiko.

Machen Sie eine simple Liste: Wo wird in Ihrem Betrieb KI eingesetzt — auch inoffiziell durch Mitarbeitende? Markieren Sie jeden Fall mit grün, gelb oder rot.

• Grün: Brainstorming, Textentwürfe, Zusammenfassungen interner Dokumente. Hier ist Halluzination ärgerlich, aber nicht haftungsrelevant.
• Gelb: Kundenkommunikation, Marketing, Übersetzungen. Hier braucht es eine zweite Person, die gegenliest, bevor etwas rausgeht.
• Rot: Rechtsfragen, Steuer- und Buchhaltungsthemen, medizinische oder sicherheitsrelevante Auskünfte, behördliche Eingaben, Verträge. Hier ist KI höchstens ein Recherche-Hilfsmittel — nie die Quelle.

2. Etablieren Sie eine simple Prüfregel für rote Fälle.

Mein Rat: Bei roten Fällen muss jede Faktenbehauptung — jedes Aktenzeichen, jede Paragraphennummer, jede Zahl, jede Studie — auf eine Primärquelle zurückgeführt werden. Findet sich die Quelle nicht in unter zwei Minuten in RIS, Findok, Statistik Austria oder einem etablierten Fachverlag, ist die Behauptung falsch. Punkt. Diese Regel kostet Sie zehn Minuten zusätzliche Recherchezeit pro Dokument und schützt vor sechsstelligen Schäden.

3. Schaffen Sie eine schriftliche KI-Nutzungsrichtlinie — auch wenn Sie nur fünf Mitarbeitende haben.

Die muss nicht 30 Seiten lang sein. Eine A4-Seite reicht. Inhalt:

• Welche Tools sind freigegeben (und welche nicht — Stichwort Datenschutz bei kostenlosen Konsumenten-Tools).
• Welche Daten dürfen rein (keine personenbezogenen Daten, keine Geschäftsgeheimnisse in nicht-DSGVO-konforme Tools).
• Wer prüft was, bevor es das Haus verlässt.
• Wie wird KI-Nutzung bei sensiblen Dokumenten dokumentiert.

Diese Richtlinie ist im Streitfall Ihr Schutzschild. Sie zeigt, dass Sie Ihrer Sorgfaltspflicht als Geschäftsführer nachgekommen sind.

Mein Fazit

Der Berliner Fall ist kein Argument gegen KI. Im Gegenteil — KI bleibt eines der produktivsten Werkzeuge der letzten Jahre. Aber die Phase, in der man so tun konnte, als wäre der Output schon irgendwie richtig, ist vorbei. Was jetzt kommt, ist die Phase der Verantwortung. Und die liegt nicht beim Modell, nicht bei OpenAI, nicht bei Anthropic — sondern bei dem Menschen, der den Text unterschreibt.

Wer das ernst nimmt, gewinnt einen Wettbewerbsvorteil. Wer es ignoriert, wird über kurz oder lang sein eigenes Kammergericht-Erlebnis haben. Nur wahrscheinlich teurer.