Einordnung
Eine überzeugende Demo beweist noch keinen Prozess
Eine Demo zeigt, dass ein System unter günstigen Bedingungen eine Aufgabe lösen kann. Im Alltag kommen unvollständige Eingaben, widersprüchliche Dokumente, Sonderfälle und wechselnde Zuständigkeiten hinzu. Ein produktives System muss deshalb nicht nur gute Antworten liefern, sondern auch erkennen, wann es keine belastbare Antwort geben kann und wer dann übernimmt.
Prüfpunkte
Den Pilot als Prozessvertrag beschreiben
Vor dem ersten Test sollte in einem kurzen Dokument stehen, was genau in den Pilot hinein und was bewusst nicht hinein gehört. Diese Beschreibung schafft eine gemeinsame Grundlage zwischen Fachbereich, IT und Umsetzungspartner.
- Auslöser und erlaubte Eingaben
- Erwartetes Ergebnis und zulässige Aktionen
- Ausnahmen, Eskalationen und Ausschlussfälle
- Verantwortliche Personen für Inhalt, Technik und Freigaben
- Messwerte, Testfälle und Entscheidung nach dem Pilot
Einordnung
Datenzugriff ist eine Fachentscheidung
Die technische Anbindung einer Quelle beantwortet nicht die Frage, ob sie genutzt werden darf oder ob sie fachlich verlässlich ist. Für jede Quelle sollte klar sein, wer sie verantwortet, wie aktuell sie ist und welche Rollen zugreifen dürfen. Besonders bei Wissensassistenten ist eine klare Quellenbasis wichtiger als möglichst viele Dokumente.
Einordnung mit Bezug auf NIST AI Risk Management Framework ↗.
Einordnung
Mit einem Testkatalog statt Einzelfeedback arbeiten
Einzelne gute oder schlechte Beispiele reichen nicht. Ein Testkatalog enthält typische Fälle, schwierige Varianten, fehlende Angaben und Fälle, die bewusst eskalieren müssen. Bei jeder Änderung an Prompt, Datenquelle oder Modell wird derselbe Katalog erneut geprüft. So wird sichtbar, ob eine Verbesserung an einer Stelle neue Schwächen erzeugt.
Für interne Wissensassistenten dokumentiert die Pilotvorlage gültige Quellen und erwartete Antworten.
Vergleich
Qualität nach Fehlerfolgen steuern
Nicht jeder Fehler ist gleich schwer. Ein unvollständiger Entwurf kann durch eine kurze Prüfung korrigiert werden. Eine falsche externe Auskunft, eine unberechtigte Datenfreigabe oder eine irreversible Aktion hat eine andere Konsequenz. Je höher die Fehlerfolge, desto enger müssen Berechtigungen, Freigaben und Abbruchregeln sein.
Kontrolle richtet sich nach der Wirkung eines Fehlers
| Aufgabe | Sinnvoller Start | Kontrollpunkt |
|---|---|---|
| Zusammenfassung interner Texte | Entwurf mit Quellen | Fachliche Prüfung bei wichtigen Entscheidungen |
| Klassifikation einer Anfrage | Vorschlag für Kategorie und Priorität | Regeln für sensible oder unklare Fälle |
| Externe Kommunikation | Antwortentwurf | Freigabe vor Versand |
| Aktion in einem System | Vorbereitete Aufgabe | Berechtigung und nachvollziehbarer Auslöser |
Einordnung
Menschliche Kontrolle bewusst platzieren
Menschliche Kontrolle ist nicht gleichbedeutend mit einem Klick nach jedem Schritt. Sie muss dort greifen, wo sie tatsächlich Wirkung entfaltet: bei der Freigabe externer Kommunikation, bei Ausnahmen, bei risikoreichen Entscheidungen und bei Änderungen am System. Routine ohne Folgen kann stärker automatisiert sein als eine seltene Entscheidung mit großer Wirkung.
Einordnung
Betrieb von Beginn an mitplanen
Ein System bleibt nur brauchbar, wenn sich jemand um Inhalte, Zugriffsrechte, Fehler und Veränderungen kümmert. Dazu gehören ein klarer Kontakt für Anwender, ein Prozess für neue Fragen und eine Entscheidung, wie das System bei Störung oder Unsicherheit reagiert. Diese Betriebslogik muss nicht groß sein, aber sie darf nicht fehlen.
Einordnung
Einführung in Stufen
Starten Sie mit einer begrenzten Nutzergruppe und beobachten Sie reale Nutzung. Erst nach dokumentierter Qualität folgt die Erweiterung. In jeder Stufe werden Rückmeldungen, Abweichungen und nicht genutzte Funktionen ausgewertet. So entstehen nicht nur technische Erkenntnisse, sondern auch ein realistisches Bild davon, welche Arbeit das Team tatsächlich abgeben möchte.
Nächste Entscheidung
Änderungen wie neue Releases behandeln
Modelle, Wissensquellen, Prozesse und Berechtigungen verändern sich. Deshalb sollten wesentliche Änderungen mit repräsentativen Testfällen geprüft und nachvollziehbar dokumentiert werden. Das entspricht dem Grundgedanken risikobasierter KI Steuerung, wie ihn auch NIST und der EU AI Act beschreiben. Die konkrete rechtliche Bewertung eines Einzelfalls gehört bei Bedarf in spezialisierte Beratung.
Einordnung mit Bezug auf EU AI Act, konsolidierte Fassung ↗.