KI-Pilotprojekte in bestehenden Systemen

Ein begrenztes KI-Pilotprojekt ist der kontrollierte Weg, eine KI-Fähigkeit in ein bereits bestehendes System einzuführen und zu bewerten. Das Pilotprojekt wird vor der Technologie definiert: ein enges operatives Problem, eine explizite Systemgrenze, eine begrenzte KI-Rolle, erlaubte Eingaben und Ausgaben, ein Berechtigungsumfang, der dort endet, wo die Folgen es verlangen, beobachtbare Bewertungskriterien und umkehrbare Ergebnisse. Es läuft über einen definierten Zeitraum, wird an den vorab festgelegten Kriterien gemessen und endet mit einer von fünf Entscheidungen: ausweiten, begrenzt halten, neu gestalten, verschieben oder die KI-Fähigkeit vollständig entfernen. Die erfolgreiche Übernahme ist ein mögliches Ergebnis, nicht das geforderte – das Pilotprojekt dient dazu, Belege für die nächste Systementscheidung zu gewinnen.

Definieren Sie das operative Problem, bevor irgendeine KI-Fähigkeit, ein Modell oder ein Werkzeug in Betracht gezogen wird. Das Problem wird in der Sprache des Betriebs formuliert: eine Aufgabe, die langsam, inkonsistent oder schwer zu besetzen ist, ein Schritt, bei dem Sprach- oder Musterarbeit über das hinausgeht, was Regeln leisten, oder ein Ergebnis, das Menschen heute von Hand erzeugen. Die Problemstellung benennt die Aufgabe, die Daten, die sie berührt, die beteiligten Personen und das, was als Verbesserung gelten würde. Wenn sich das Problem nicht formulieren lässt, ohne ein Modell oder ein Produkt zu nennen, ist es noch keine Problemstellung. Was ein kohärentes Business-System ist – und wie das Gastsystem des Pilotprojekts in dieses Bild passt – behandelt der Leitfaden zu Business-Systemen (/resources/was-geschaeftssysteme-umfassen); das Pilotprojekt beginnt bei der konkreten Aufgabe, nicht bei der Definition.

Das Pilotprojekt benennt, wo die KI-Fähigkeit innerhalb des bestehenden Systems lebt und was ausserhalb von ihr bleibt. Die Grenze listet die Systeme auf, aus denen die Fähigkeit lesen darf, den einen Ort, an dem ihr Ergebnis in den Betrieb einfliesst, und alles, was sie nicht berühren darf: andere Systeme, andere Daten, andere Prozesse und andere Entscheidungspunkte. Der Rest des bestehenden Systems arbeitet genau so weiter wie heute – das Pilotprojekt zeichnet das System nicht neu, ersetzt keinen Ablauf und verlangt von anderen Teams keine Änderung ihrer Arbeitsweise. Das ist bewusst enger als die Arbeit am kohärenten System, die im Leitfaden zu Business-Systemen beschrieben ist (/resources/was-geschaeftssysteme-umfassen): Dieser Leitfaden definiert das operative Ganze, während das Pilotprojekt nur eine begrenzte Ecke davon beansprucht.

Die KI-Fähigkeit in einem Pilotprojekt leistet genau eine enge Art von Arbeit: interpretieren, klassifizieren, generieren, extrahieren oder assistieren – nicht die ganze Aufgabe und nicht das ganze System. Die Rolle wird als Aufgabe beschrieben, nicht als Technologie: eingehende Anfragen lesen und die Falldaten extrahieren, statt einen Endpunkt oder einen Modellnamen zu nennen. Alles, was nicht in diese enge Rolle passt, bleibt im bestehenden System, bei den vorhandenen Werkzeugen und den vorhandenen Personen. Das Pilotprojekt darf die KI-Fähigkeit nicht implizit zum System machen: Sie ist eine begrenzte Komponente mit einer benannten Aufgabe, umgeben von einem System, das auch ohne sie bereits funktioniert.

Das Pilotprojekt läuft mit einer definierten Menge an Eingaben und mit nichts weiter. Benennen Sie die Quelle der Wahrheit für jede Eingabe – das System und den Datensatz, aus dem sie stammt – sowie den erlaubten Kontext, den die Fähigkeit sehen darf: welche Felder, welche Datensätze, welche Dokumente und was ausdrücklich ausgeschlossen ist. Wenn das Pilotprojekt Kontext abruft statt empfängt, gehört die Abrufgrenze zum Design: was durchsucht werden darf, was nicht und wie der ausgewählte Kontext begrenzt wird, bevor er das Modell erreicht. Deterministische Eingaben, die die Aufgabe bereits hat – Status, Kennungen, Referenzdaten – bleiben deterministisch und werden neben der KI-Arbeit übergeben, statt neu erzeugt zu werden.

Fähigkeit ist keine Berechtigung. Eine Fähigkeit, die eine Antwort erzeugen kann, darf sie deshalb noch nicht verbindlich machen, und eine Fähigkeit, die eine Handlung empfehlen kann, darf sie deshalb noch nicht ausführen. Das Pilotprojekt definiert, was die KI hervorbringen darf – Klassifikationen, Extraktionen, Entwürfe, Zusammenfassungen, Empfehlungen, strukturierte Ergebnisse – und was sie nicht darf: Datensätze schreiben, Abläufe auslösen, Kommunikation versenden oder eine Handlung ausführen, die den Betrieb verändert, sofern diese spezifische Berechtigung nicht für genau diese Aufgabe erteilt wurde. Wo das Ergebnis des Pilotprojekts eine Entscheidungsunterstützung ist, bleibt die Entscheidung bei der Person; wo das Ergebnis Material für einen Schritt ist, bleibt der Schritt selbst dort, wo er bereits liegt.

Das Pilotprojekt braucht genau einen begrenzten Integrationspunkt: einen definierten Vertrag, an dem sein strukturiertes Ergebnis in das bestehende System einfliesst, und einen definierten Fallback, wenn das Ergebnis nicht erzeugt werden kann. Der Vertrag ist minimal und explizit – das Ausgabeschema, die erwarteten Werte, das Format und das, was der empfangende Schritt mit dem Ergebnis tut. Der Fallback ist Teil desselben Vertrags: Wenn die Fähigkeit ausfällt, ein Zeitlimit überschreitet oder ein Ergebnis erzeugt, das die Validierung nicht besteht, läuft die Arbeit auf dem bestehenden Weg weiter, übernommen von der Person oder dem Prozess, der die Aufgabe vor dem Pilotprojekt erledigt hat. Dieser eine Integrationspunkt ist der einzige Anspruch des Pilotprojekts auf das bestehende System; alles andere bleibt unberührt.

Die menschliche Kontrolle in einem Pilotprojekt folgt der Folge jeder Handlung, die die Fähigkeit beeinflusst, und nicht einer universellen Regel, dass jedes Ergebnis freigegeben werden muss. Wo das Ergebnis des Pilotprojekts einen Schritt mit hohen oder irreversiblen Folgen speist – externe Kommunikation, Datenänderungen mit rechtlichem oder finanziellem Gewicht, Entscheidungen, die das Unternehmen binden – prüft eine Person oder führt sie aus. Wo das Ergebnis folgenarm und leicht korrigierbar ist – ein Entwurf, eine Klassifikation für die Triage, eine Zusammenfassung zur internen Prüfung – kann das Pilotprojekt direkt fliessen und bleibt trotzdem umkehrbar. Der Zweck des Pilotprojekts ist es, herauszufinden, wo die Konsequenzgrenze für diese Aufgabe tatsächlich liegt, und die Kontrollpunkte entsprechend zu setzen. Der vollständige Katalog der Kontrollkategorien für KI-Systeme ist Gegenstand der Notiz zu praktischen Schutzmechanismen (/resources/praktische-schutzmechanismen-fuer-ki-systeme); das Pilotprojekt wendet die Teilmenge an, die seine Folgen verlangen.

Das Pilotprojekt sollte genug Spur hinterlassen, dass eine spätere Prüfung rekonstruieren kann, was geschehen ist: die Eingaben, die jede Anfrage erhalten hat, der Kontext, der tatsächlich verwendet wurde, das erzeugte Ergebnis, die Validierungs- und Fallback-Entscheidungen, die einbezogenen menschlichen Prüfungen sowie die aufgetretenen Ausnahmen und Ausfälle. Beobachtbarkeit bedeutet nicht, alles zu protokollieren – sie bedeutet, die Bewertungskriterien beantwortbar zu machen. Wenn die Ergebnisse des Pilotprojekts später beurteilt werden, muss das Material für diese Beurteilung existieren. Was sichtbar sein muss, wird pro Signal entschieden: Eingaben und Ausgaben für die Nützlichkeit, Ausnahmen und Ausfälle für die Fehlermuster, Korrekturen für die menschliche Belastung und die vollständige Spur für die Prüfbarkeit.

Betriebskosten und Latenz sind im Pilotprojekt Anforderungen erster Klasse, keine Nebensache. Das Design setzt ein Token- oder Kontextbudget für die Aufgabe, eine Obergrenze für das, was jeder Lauf verbrauchen darf, und ein Latenzbudget für den Schritt, den die Fähigkeit bedient. Das sind operative Parameter, die das Team für seine eigene Aufgabe und Umgebung festlegt – es gibt keine universellen Zahlen, und es sollten keine von anderswo übernommen werden. Entscheidend ist, dass das Pilotprojekt seine Budgets im Voraus benennt und aufzeichnet, was es tatsächlich verbraucht hat, damit die Bewertung die Kosten und die Latenz der Fähigkeit gegen den bestehenden Weg abwägen kann, den sie ersetzen würde.

Das Pilotprojekt definiert, wie die Fähigkeit ausfällt, bevor sie ausfällt. Zeitüberschreitungen begrenzen, wie lange ein Lauf dauern darf, Wiederholungsgrenzen, wie oft er versucht werden darf, und Validierung fängt Ergebnisse ab, die strukturell nicht brauchbar sind. Der Fallback ist der bestehende Weg: Wenn die Fähigkeit innerhalb ihrer Grenzen kein akzeptables Ergebnis erzeugen kann, läuft die Aufgabe so weiter, wie sie vor dem Pilotprojekt lief. Für die meisten Pilotaufgaben führt eine Person den Schritt direkt aus; wo ein deterministischer Weg existiert, dient dieser als Fallback. Ein Pilotprojekt, das lautlos ausfällt, ist kein Pilotprojekt – jeder Ausfall ist sichtbar und lässt den Betrieb entweder unberührt oder besser informiert.

Eignung der Aufgabe: ob die im Pilotprojekt definierte enge Rolle tatsächlich zum operativen Problem passt oder ob das Problem falsch erkannt wurde.

Nützlichkeit der Ergebnisse: ob die Ergebnisse in der Praxis brauchbar sind, nicht nur in einer Testmenge.

Fehlermuster: die Muster darin, wo und wie die Fähigkeit ausfällt.

Korrekturaufwand durch Menschen: wie viel Prüfung und Korrektur die Ergebnisse tatsächlich erfordern.

Passung zum Ablauf: ob der Integrationspunkt und der Fallback zur tatsächlichen Arbeitsweise passen.

Zuverlässigkeit der Integration: ob sich der begrenzte Integrationsvertrag wie entworfen verhält.

Latenz: ob der Schritt innerhalb des Latenzbudgets abschliesst, das der Betrieb braucht.

Betriebskosten: was die Fähigkeit tatsächlich verbraucht, gegenüber dem im Voraus gesetzten Budget.

Fallback-Verhalten: ob Ausfälle sauber und sichtbar auf den bestehenden Weg führen.

Prüfbarkeit: ob die aufgezeichnete Spur ausreicht, um zu rekonstruieren, was geschehen ist.

Umkehrbarkeit: ob sich jedes Ergebnis des Pilotprojekts ohne Reste zurückrollen lässt.

Bereitschaft zur Ausweitung: was das Pilotprojekt darüber gezeigt hat, ob und wie eine breitere Fähigkeit in das System passen würde.

Die Pilotbewertung braucht keinen universellen Score und keine feste Bestehensgrenze. Sie braucht Belege gegen die Kriterien, die vor dem Start benannt wurden, gesammelt aus dem Betrieb selbst.

Ausweiten: Die Belege sprechen dafür, die Fähigkeit auf einen breiteren Umfang zu erweitern – einen grösseren Teil der Aufgabe, mehr Eingaben, mehr Autorität – als eigenen nächsten begrenzten Schritt.

Begrenzt halten: Die Fähigkeit ist genau dort nützlich, wo sie ist, im aktuellen Umfang, und dort zu bleiben ist ein legitimes Ergebnis.

Neu gestalten: Die Aufgabe oder die Grenze war falsch, und das Pilotprojekt sollte neu geformt werden, bevor etwas beurteilt wird.

Verschieben: Das Problem ist real, aber die Belege sagen, dass die Bedingungen – Daten, Zeitpunkt, Integration, Kosten – noch nicht stimmen.

KI vollständig entfernen: Die ehrliche Schlussfolgerung ist, dass der bestehende Weg besser ist und die KI-Fähigkeit herausgenommen werden sollte.

Das Pilotprojekt dient dazu, Belege für die nächste Systementscheidung zu gewinnen, nicht dazu, die KI-Übernahme zu rechtfertigen. Die Fähigkeit zu entfernen ist ein erfolgreiches Pilotprojekt, wenn das die Belege stützen.