KI liefert eine Lösung. Woran erkennen Sie, ob sie passt?

Jeder bekommt heute eine Antwort. Sie tippen Ihr Problem in ein Sprachmodell und erhalten binnen Sekunden einen Vorschlag, der ordentlich gegliedert ist, vernünftig klingt und sich wie eine Lösung liest.

Der Vorschlag ist meistens auch richtig. Nur eben für jemand anderen.

Was knapp geworden ist, ist die Fähigkeit zu erkennen, welcher von dreißig vernünftigen Wegen für Ihren Betrieb der richtige ist. Dafür gibt es handfeste Prüfungen, und es gibt eine Normanforderung, die genau an dieser Stelle greift.

Warum der Vorschlag plausibel ist und trotzdem nicht passt

Ein Sprachmodell erzeugt die Antwort, die angesichts von allem, was es gelesen hat, am wahrscheinlichsten ist. Bei einer Frage, die vor Ihnen schon zehntausend Betriebe gestellt haben, ist das die mittlere Antwort. Sie ist korrekt für den mittleren Betrieb.

Ihren Betrieb gibt es in dieser Mitte nicht. Was Ihre Entscheidung wirklich bestimmt, ist fast immer eine einzelne bindende Randbedingung: die 1998er Maschine ohne Schnittstelle. Der Kunde, der vierzig Prozent des Umsatzes trägt und keine Cloud akzeptiert. Die Kollegin, die als einzige den Freigabeprozess im Kopf hat und in zwei Jahren in Rente geht.

Keine dieser Bedingungen steht im Modell. Sie stehen nicht einmal bei Ihnen irgendwo geschrieben. Und weil Sie sie nicht genannt haben, rechnet der Vorschlag ohne sie.

Der nächstliegende Einwand lautet: Dann nenne ich sie eben. Das scheitert daran, dass kaum jemand vorher weiß, welche seiner Besonderheiten die bindende ist. Jeder Betrieb hat dreißig Eigenheiten, und neunundzwanzig davon sind für diese eine Entscheidung belanglos. Welche die dreißigste ist, merkt man meistens erst, wenn der Vorschlag daran zerbricht. Genau darin liegt der Unterschied zwischen jemandem, der das Feld kennt, und jemandem, der eine Antwort hat: Der eine fragt vorher die drei Fragen, die die bindende Bedingung hervorholen.

Das ist der Grund, warum sich so viele KI-Projekte gut anfühlen und nach vier Monaten stehenbleiben. Nicht weil die Technik versagt hat, sondern weil der entscheidende Satz nie aufgeschrieben wurde.

Fünf Prüfungen, die einen Vorschlag zerlegen

Diese fünf Fragen stelle ich jedem Vorschlag, egal ob er von einem Modell, einem Dienstleister oder aus dem eigenen Haus kommt. Sie kosten zusammen zwanzig Minuten.

• Unter welcher Bedingung scheitert dieser Weg? Ein Vorschlag, der seine eigene Scheiterbedingung nicht nennt, ist Werbung. Fragen Sie nach, bis eine kommt.
• Was kostet es, das wieder rückgängig zu machen? Nicht der Aufbau entscheidet über das Risiko, sondern der Rückbau. Zwei Tage Rückbau sind ein Versuch wert. Sechs Monate nicht.
• Wer muss dafür sein Verhalten ändern, und hat diese Person mitgeredet? Jeder Vorschlag, der das Verhalten von Menschen voraussetzt, die nicht am Tisch saßen, ist eine Wette.
• Was kostet der Fehlerfall, nicht der Normalfall? Rechnen Sie den Tag durch, an dem es falsch läuft und niemand es merkt. Diese Zahl entscheidet, nicht die Einsparung im Gutfall.
• Hält der Weg Ihrem schlechtesten Tag stand? Jahresabschluss, zwei Krankmeldungen, der große Kunde ruft an. Ein Verfahren, das nur dienstags funktioniert, ist keins.

Die vierte Frage lohnt eine kleine Rechnung, weil sie fast immer anders ausgeht als gedacht. Ein Vorgang spart zehn Minuten, läuft dreißigmal am Tag, das sind rund hundert Stunden im Jahr. Jetzt die Gegenseite: Der Vorgang läuft in zwei von hundert Fällen falsch, fällt im Schnitt nach sechs Wochen auf und kostet dann einen halben Tag Nacharbeit plus ein unangenehmes Telefonat. Bei dreißig Vorgängen täglich sind zwei Prozent rund zwölf Fälle im Monat. Die Rechnung kippt, und zwar nicht knapp.

Die zweite Frage ist die unterschätzte. In der Praxis wird fast nie über Rückbaukosten gesprochen, und genau dort entsteht die Abhängigkeit, die später teuer wird.

Ein Fall, in dem die dreißigste Eigenheit entschieden hat

Ein Zulieferer, rund 90 Mitarbeitende, wollte die Angebotserstellung beschleunigen. Die Aufgabe war sauber beschrieben: Anfrage kommt per Mail, Positionen werden erfasst, Preise aus der Kalkulation gezogen, Angebot geht raus. Vier Anbieter, vier plausible Wege, dazu mehrere Vorschläge aus einem Sprachmodell. Alle liefen auf dasselbe hinaus: Texterkennung auf die Anfrage, Abgleich gegen den Artikelstamm, Vorbelegung des Angebots.

Keiner der Wege hat getragen. Der Grund stand in keinem Konzept: Rund ein Drittel der Anfragen kam als abfotografierte Handskizze vom Bau, teils mit Maßen am Rand. Text war daran nichts. Die Positionen standen nirgends in einer Form, die sich abgleichen ließ. Die Sachbearbeiterin hat sie seit Jahren gelesen, weil sie die Kunden kennt.

Als diese eine Bedingung auf dem Tisch lag, sortierte sich die Sache in zwanzig Minuten. Zwei Wege fielen sofort aus. Ein Weg wurde auf die zwei Drittel sauberer Anfragen begrenzt, mit einem bewussten Schnitt davor. Der Rest blieb bei der Sachbearbeiterin, und ihr Wissen wurde dokumentiert, statt es automatisieren zu wollen.

Die Information war im Haus die ganze Zeit vorhanden. Gefragt hatte nur niemand danach, weil in der Aufgabenbeschreibung stand, wie es sein sollte, und nicht, wie es ist.

Die Frage, die vor dem Vorschlag kommt

Alle fünf Prüfungen setzen etwas voraus, das in den meisten Betrieben fehlt: eine Vorstellung davon, was eine gute Lösung überhaupt leisten muss. Ohne diesen Maßstab vergleichen Sie dreißig Vorschläge gegen Ihr Bauchgefühl, und dann gewinnt der am besten formulierte.

ISO/IEC 42001 hat dafür eine eigene Maßnahme, und sie steht bewusst am Anfang des Lebenszyklus. A.6.2.2 verlangt, die Anforderungen für ein neues KI-System zu spezifizieren und zu dokumentieren. Der Zweck ist ausdrücklich, dass Ziele und Rahmenbedingungen vor der Entwicklung feststehen und überprüfbar sind.

Zum erwarteten Nachweis gehören Begründung des Vorhabens, Ziele, funktionale und nichtfunktionale Anforderungen, Datenanforderungen, Anforderungen für alle Lebenszyklusphasen und, das ist der entscheidende Punkt, Abnahmekriterien. Freigegeben wird das Dokument vom Auftraggeber, nicht von der Entwicklung.

Wer das hat, kann dreißig Vorschläge in einer Stunde sortieren. Wer es nicht hat, diskutiert Vorschläge.

Ein Detail aus dieser Maßnahme wird regelmäßig überlesen und ist in der Praxis das wichtigste: Freigegeben wird die Spezifikation vom Auftraggeber. Nicht von der IT, nicht vom Dienstleister, nicht von der Person, die das System später baut. Wer baut, schreibt sich die Anforderungen sonst so, dass sie zu seiner Lösung passen. Das ist kein böser Wille, es ist der Normalfall. Die Trennung von Anforderung und Lösung ist der halbe Nutzen der ganzen Maßnahme.

Dasselbe gilt für den Vergleich mehrerer Anbieter. Liegt die Spezifikation vor, bekommen alle dieselbe Unterlage und antworten auf dieselben Punkte. Ohne sie beschreibt jeder Anbieter die Aufgabe so, wie sein Produkt sie am besten löst, und Sie vergleichen am Ende drei verschiedene Aufgaben miteinander. Das ist der häufigste Grund, warum Angebotsvergleiche im KI-Umfeld so mühsam sind und warum der Preis dann als einziges verbleibendes Unterscheidungsmerkmal entscheidet.

Sie können einen Vorschlag erst beurteilen, wenn Sie vorher aufgeschrieben haben, was er können muss. Vorher vergleichen Sie Formulierungen.

Was ich im Audit an dieser Stelle sehe

Drei Fragen aus A.6.2.2 bringen in jedem Audit Bewegung in den Raum:

• Zeigen Sie mir die Anforderungsspezifikation für dieses System. Warum wurde es gebaut, und woraus ergibt sich das?
• Decken die Anforderungen den gesamten Lebenszyklus ab, einschließlich Betrieb, Wartung und Stilllegung?
• Wann und unter welchen Umständen überprüfen Sie die Anforderungen erneut?

Die typische Abweichung sieht fast immer gleich aus. Es liegt eine funktionale Beschreibung vor, oft sogar eine gute. Anforderungen für Betrieb, Wartung und Stilllegung fehlen. Die Folge zeigt sich erst später: Die Maßnahmen zur Bereitstellung und zum Betrieb können auf keine spezifizierten Kriterien zurückgreifen, weil es keine gibt.

Im Klartext: Niemand kann sagen, wann das System gut genug ist, wann es gewartet werden muss und wann es abgeschaltet gehört. Es läuft einfach weiter, bis jemand merkt, dass es seit Monaten Unsinn produziert.

Die Frage nach der Stilllegung ist dabei die unbequemste und die nützlichste. Fast niemand hat sie beantwortet. Wer sie beantwortet, hat automatisch auch die Frage beantwortet, woran man erkennt, dass sich das System nicht mehr lohnt.

Was Sie am Montag tun können

Nehmen Sie das KI-Vorhaben, das bei Ihnen gerade am weitesten vorne steht. Eine Seite reicht, handschriftlich geht auch.

• Warum machen wir das? Ein Satz, der eine Zahl enthält. Ohne Zahl ist es ein Wunsch.
• Woran erkennen wir, dass es funktioniert? Das sind Ihre Abnahmekriterien. Mindestens eine Größe, die sich messen lässt.
• Was darf es nicht? Die bindenden Randbedingungen, die oben niemand kennt. Hier gehören die alte Maschine, der Kunde ohne Cloud und die Kollegin mit dem Wissen im Kopf hinein.
• Wer gibt das frei? Ein Name, keine Abteilung.
• Wann schalten wir es ab? Die Bedingung, unter der das Vorhaben beendet wird.

Mit dieser Seite gehen Sie in das nächste Gespräch, egal ob mit einem Anbieter, einem Berater oder einem Sprachmodell. Sie werden erleben, dass die Hälfte der Vorschläge an Punkt drei stirbt, und zwar in zwei Minuten statt in vier Monaten.

Und wenn Ihnen zu Punkt zwei nichts einfällt, haben Sie das wichtigste Ergebnis schon in der Hand. Finden Sie keine Größe, an der sich Erfolg zeigen würde, ist das Vorhaben noch nicht entscheidungsreif. Dann steht nicht die Technik an, sondern eine Messung über zwei, drei Wochen. Das fühlt sich nach Verzögerung an und ist die Abkürzung.

Und Sie werden merken, woran Sie einen guten Gesprächspartner erkennen: Er fragt nach Punkt drei und fünf, bevor er etwas vorschlägt. Wer sofort eine Lösung anbietet, hat die mittlere Antwort im Angebot. Das ist kein Grund, ihn auszuladen. Es ist ein Grund, die Seite auf den Tisch zu legen, bevor er anfängt.