# August 2026: Worüber ich geschrieben habe – und warum

> Eine vergessene Hotelbewertung, KI-Entscheidungen im Unternehmen, ältere Systeme und die Pflege des Archivs: meine August-Artikel darüber, was noch zu erledigen ist und was nützlich bleiben soll.

Im August veröffentlichte ich eine Reihe von Artikeln über KI-Projekte in Unternehmen. Dabei ging es jeweils um eine andere Entscheidung: welches Modell wir wählen, welche Daten wir brauchen, was das System tun darf und woran wir seinen Nutzen erkennen. Im selben Monat kam ich auf Systeme zurück, die ich früher gebaut hatte, und auf ältere Artikel meiner eigenen Website.

Einer dieser Artikel handelte von einer Hotelbewertung, die ich nach dem Urlaub vergessen hatte zu schreiben. Neben KI im Unternehmen erscheint das wie eine Kleinigkeit. Doch auch hier ging es darum, dass eine Zusage noch keine erledigte Arbeit ist. Der Aufenthalt hatte mir gefallen, und ich war bereit, eine Bewertung zu schreiben. Dass ich das im ersten Gespräch zugesagt hatte, brachte die Bewertung noch nicht zustande.

## Die vergessene Bewertung eines zufriedenen Gastes

Als wir am 7. August das Hotel verließen, sagten wir den Mitarbeitern, dass uns der Aufenthalt gefallen hatte. Sie gaben uns Karten mit QR-Codes, damit wir auf TripAdvisor eine Bewertung schreiben konnten. „Natürlich, das machen wir“, sagten wir. Wir fuhren nach Hause, packten aus, gingen wieder arbeiten und wurden krank. Fünfzehn Tage später hatten wir die Bewertung vergessen.

Im Hotel war nichts Schlechtes passiert. Niemand war unhöflich gewesen. Wir wollten eine Bewertung schreiben, taten es aber nicht. Diese kleine Lücke war der Ausgangspunkt für meinen August-Artikel über Kundenerlebnisse.

In [meinem Artikel darüber, wie man einem zufriedenen Kunden das Bewerten erleichtern kann](/de/zufriedene-kunden-zu-haben-reicht-nicht-sie-muessen-nachfassen) schrieb ich aus Kundensicht. Durch meine Arbeit wusste ich seit Jahren, wie wichtig es ist, zufriedene Kunden um Bewertungen zu bitten. Nun hatte ich selbst eine Bewertung zugesagt und sie trotzdem nicht geschrieben.

Im Artikel schlug ich eine höfliche Erinnerung ein paar Tage später vor. Sie hätte vielleicht geholfen. Ob sie mich tatsächlich zum Schreiben gebracht hätte, weiß ich nicht; ich hätte es trotzdem vergessen können.

KI könnte dabei in begrenztem Umfang helfen, ein kleines Programm zu bauen, das dem Team für Gästebetreuung zeigt, bei welchen Gästen es nachfassen könnte. Wer die Arbeit kennt, sollte entscheiden, wen das Team wann und unter welchen Bedingungen kontaktiert. Das System muss auch berücksichtigen, dass ein Kunde bereits eine Bewertung geschrieben hat, keinen Kontakt wünscht oder noch ein ungelöstes Problem hat.

Beim Schreiben des Artikels erledigte ich schließlich die vergessene Aufgabe. Ich ging auf TripAdvisor und veröffentlichte meine Bewertung.

## Die Entscheidungen vor der Modellwahl

Die Artikel über KI im Unternehmen begannen mit einer verwandten Frage: Welche Arbeit soll das System erledigen? In [meinem Artikel darüber, warum ein KI-Projekt nicht mit der Modellwahl beginnen sollte](/de/mit-dem-geschaeftsproblem-beginnen-nicht-mit-dem-ki-modell) unterschied ich zwischen einer guten Modellantwort und der Fähigkeit eines Unternehmens, eine Aufgabe zuverlässig zu erledigen. Einem Kunden die Bedingungen für eine Erstattung zu erklären und eine Erstattung auszulösen erfordern unterschiedliche Verantwortlichkeiten.

Diese Ausgangsfrage vertiefte ich in einzelnen Artikeln. Ich fragte, welcher Teil des Prozesses festen Regeln folgen kann und wo unstrukturierter Text verstanden werden muss. Dazu kamen der Speicherort und die nötige Aktualität der Informationen sowie die Frage, ob das Modell überhaupt den nächsten Schritt wählen muss.

Anhand von Vanity, REDAR und der Bankanbindung erklärte ich [die Rolle von KI in der Prozessautomatisierung](/de/wann-braucht-prozessautomatisierung-tatsaechlich-ki). Die Regeln für die Zuweisung von Leads waren komplex, aber bekannt. REDAR brauchte ein Modell, um unstrukturierten Text zu verarbeiten. Bei Banktransaktionen lag der Nutzen eines Dienstes in der Pflege der Bankverbindungen. Dieselbe technische Lösung konnte nicht alle drei Fälle abdecken.

In den Artikeln über Fine-Tuning und RAG trennte ich zwei Aufgaben: dem Modell aktuelle Informationen zu geben und sein Verhalten anhand von Beispielen anzupassen. Einen aktuellen Bestelldatensatz zu lesen und unter Tausenden von Dokumenten die passende Passage zu finden sind unterschiedliche Anforderungen. Deshalb schrieb ich auch gesondert darüber, [ob die Daten für eine bestimmte Entscheidung ausreichen](/de/ist-ihre-datenbasis-bereit-fuer-ki). Eine Tabelle kann für einen Monatsbericht genügen, ohne für ein verbindliches Kundenangebot auszureichen.

[Den Unterschied zwischen einem festgelegten Ablauf und einem Agenten](/de/wann-brauchen-sie-tatsaechlich-einen-ki-agenten) erklärte ich anhand der Frage, wer den nächsten Schritt auswählt. Wenn die Schritte bekannt sind, muss das Modell nicht jedes Mal einen Weg wählen. Wenn neue Informationen den Weg verändern, kann es helfen, das Modell freier über den nächsten Schritt entscheiden zu lassen. Dadurch entstehen auch mehr mögliche Wege, die geprüft werden müssen.

Deshalb behandelte ich gesondert, [welche Befugnisse ein KI-System erhalten sollte](/de/wie-viel-befugnis-sollte-ein-ki-system-haben). Auch wenn das Modell den richtigen Erstattungsbetrag vorbereitet, muss die Berechtigung zur Rücküberweisung trotzdem gesondert geprüft und durchgesetzt werden. Die Freigabe durch einen Menschen bietet nur dann Kontrolle, wenn er die nötigen Informationen sehen und die Entscheidung vor der Ausführung ändern kann.

Einige der Beispiele zu Kundenservice, Angeboten und Erstattungen in diesen Artikeln sind hypothetisch. Ich stelle sie nicht als Kundenprojekte dar, die ich umgesetzt habe. Sie zeigen, welche Informationen und Verantwortlichkeiten unterschiedliche Entscheidungen erfordern.

## Der Blick auf ältere Systeme

Auch meine Arbeit vor KI war von solchen Fragen geprägt. Im August schrieb ich über [das Mystery-Shopping-System, das ich bei PlusValue gebaut hatte](/de/tuerkeis-erste-echtzeit-mystery-shopping-berichtsplattform). Die Geschichte begann 2005; ich war bis 2008 daran beteiligt. Der Bericht meines früheren Partners Galip über die Anfänge brachte mich dazu, einen kurzen Satz auf meiner Über-mich-Seite ausführlicher zu erzählen.

Das System verband Bewerber, Aufträge, Besuche vor Ort, Formulardaten und Berichte. Ein Formular auf dem Bildschirm allein hätte dafür nicht gereicht. Kunden mussten die erfassten Informationen schon sehen können, während die Arbeit vor Ort noch lief. Was heute selbstverständlich erscheint, versuchten wir mit den damaligen Werkzeugen zu ermöglichen.

Ich wollte diese Geschichte nicht ausschmücken. Ich schrieb auch, dass wir mit den personenbezogenen Daten der Bewerber nicht so umsichtig umgegangen waren, wie ich es heute erwarten würde. Die Aussage „Soweit ich weiß, sind keine Daten an Außenstehende verloren gegangen“ belegte nicht, dass wir die personenbezogenen Daten der Bewerber angemessen geschützt hatten.

[Der Artikel über die Anbindung von Banktransaktionen](/de/bankkonto-api-integration-warum-skalierung-teuer-wird) betrachtete dieselbe Frage der Verantwortung anhand einer neueren Erfahrung. Wir hatten die Verbindungen über einen Anbieter eingerichtet. Wir nutzten seinen API-Zugang und übertrugen ihm einen erheblichen Teil der Verantwortung für die Pflege der Verbindungen zu verschiedenen Banken. Damit mussten wir auch diesem Anbieter vertrauen. Im August-Artikel untersuchte ich, welche Folgen diese frühere Entscheidung für Wartung und Vertrauen hatte.

## Die Arbeit hinter schnell erzeugtem Code

[Mein Artikel über den Aufwand für die Prüfung von Software](/de/ki-hat-code-billig-gemacht-pruefung-ist-weiterhin-teuer) beginnt damit, dass mir ein Entwickler eine kleine, mit KI gebaute Anwendung für die letzte Prüfung vor der Freigabe vorlegt. Der Code war geschrieben und bereits einmal geprüft worden. Um die Anwendung freizugeben, musste ich trotzdem verstehen, welches Problem sie lösen sollte, welche Annahmen sie enthielt und wie sie sich bei Fehlern verhielt.

Wenn der Autor Entscheidungen im Code nicht erklären kann, muss der Prüfer sie rekonstruieren. Wird schneller produziert, kann diese Arbeit unbemerkt auf dem Schreibtisch eines anderen landen. Im Artikel sagte ich auch, dass ich selbst von der Geschwindigkeit der KI profitiere. Ich wollte erklären, welche Arbeit Menschen bis zur Freigabe weiterhin leisten müssen, und zugleich den Geschwindigkeitsgewinn anerkennen.

Auch die Prinzipien meiner REST-Reihe von 2021 brauchten eine neue Verwendung. Statt die Reihe unverändert zu erhalten, überführte ich sie in [Prüfkriterien für die API-Entwicklung mit KI](/de/rest-api-qualitaet-in-ki-gestuetzter-entwicklung-sichern). Entscheidungen über das Löschen, die Zuordnung eines Datensatzes zu einem Nutzer, Berechtigungen und wiederholte Anfragen sollten nicht als unausgesprochene Annahmen in den Code gelangen. Nützliches Wissen zu bewahren kann bedeuten, seine Veröffentlichungsform zu ändern.

## Was im Archiv bleiben sollte

Im August prüfte ich ältere Artikel meiner Website und entfernte einige davon. In [der Fallstudie zum Content Pruning](/de/content-pruning-eine-fallstudie-aus-der-praxis) erklärte ich, warum sich diese Entscheidung nicht allein aus den Besucherzahlen ableiten ließ. Eine Installationsanleitung, die weiterhin gelesen wurde, wollte ich vielleicht nicht mehr aktualisieren. Ein Artikel ohne Traffic konnte eine reale Erfahrung enthalten, die nirgendwo sonst dokumentiert war.

Bei einigen Artikeln entschied ich mich für die Entfernung, bei anderen für die Zusammenführung. Anleitungen nahm ich offline, wenn ich sie nicht zuverlässig aktuell halten konnte und keinen Ersatzartikel hatte. Die nützlichen Prinzipien der REST-Reihe bewahrte ich im neuen Artikel und leitete die alten URLs dorthin um. Ich versuchte zu entscheiden, welches Wissen heute in welcher Form nützlich war, statt meine technische Vergangenheit auszulöschen.

Ich behauptete noch nicht, dass diese Entscheidung gute SEO-Ergebnisse gebracht hatte. Ich musste noch beobachten, ob die entfernten Seiten aus dem Index verschwinden würden. Ebenso offen war, ob die verbleibenden Artikel ein zusammenhängenderes Gesamtwerk ergäben und ob mir mehr Zeit für die Themen bliebe, die ich pflegen wollte.

In [meinem Artikel über Werkzeuge zur Messung von KI-Sichtbarkeit](/de/funktionieren-ki-sichtbarkeits-tools-wirklich) beschäftigte ich mich ebenfalls mit den Grenzen der Messung. Dass eine Marke in ausgewählten Prompts erscheint, ist etwas anderes, als wenn ein tatsächlicher Kunde sie sieht. Auch deshalb unterschied ich [bei der Erfolgsmessung in der Reihe über KI im Unternehmen](/de/erzielt-ihr-ki-system-tatsaechlich-geschaeftsergebnisse) zwischen einer Antwort, einer erledigten Aufgabe und einer geschäftlichen Wirkung.

Nach dem Ausdünnen des Archivs bleiben weniger Artikel übrig. Durch schnellere Codeproduktion liegt mehr Code vor uns. In beiden Fällen ist das Zählen einfach. Ob Artikel und Code weiterhin richtig, nützlich und die Pflege wert sind, lässt sich erst bei einer genauen Prüfung beurteilen.

---

Language: German
License: CC BY 4.0
License URL: https://creativecommons.org/licenses/by/4.0/
Scope: Evren Bal-authored text, unless this article expressly states otherwise.
Excluded: Third-party material, quoted excerpts, logos, and separately marked images retain their own rights.
Attribution: Credit Evren Bal, link to the canonical source and license, and indicate changes.
Source: https://evrenbal.com/de/august-2026-worueber-ich-geschrieben-habe