Jede Automatisierung und jeder KI-gestützte Prozess beginnt mit einer grundlegenden Annahme: Die übergebenen Daten sind vollständig, korrekt und für den vorgesehenen Zweck zulässig.
In vielen Implementierungen bleibt genau diese Annahme ungeprüft.
Das System prüft vielleicht, ob ein Feld vorhanden ist oder ob eine Datei syntaktisch verarbeitet werden kann. Ob die Eingabe zum richtigen Kunden, zur richtigen Umgebung und zum aktuellen Systemzustand gehört, wird dagegen häufig erst während der Ausführung oder gar nicht festgestellt.
Dann ist aus einem Datenfehler bereits eine technische Änderung geworden.
Automatisierung kennt nur die übergebenen Daten
Eine Automatisierung kann eine Anweisung exakt und reproduzierbar ausführen. Sie kann jedoch nicht von selbst erkennen, ob die zugrunde liegende Anweisung fachlich sinnvoll ist.
Ein gültiger Hostname kann das falsche System bezeichnen. Ein korrekt formatiertes Netzwerk kann sich mit einem bestehenden Adressbereich überschneiden. Eine Benutzerkennung kann existieren, aber zu einem anderen Mandanten gehören. Eine Cloud-Region kann technisch verfügbar, für die betroffene Datenklasse jedoch unzulässig sein.
Auch KI löst dieses Problem nicht automatisch. Im Gegenteil: Ein Modell ist häufig in der Lage, unvollständige oder widersprüchliche Eingaben plausibel zu ergänzen. Was bei einem unverbindlichen Text hilfreich sein kann, ist bei Berechtigungen, Infrastrukturänderungen oder administrativen Aktionen ein Risiko.
Eine fehlende Information darf in einem ausführenden Prozess nicht durch eine glaubwürdige Vermutung ersetzt werden.
Formal gültig reicht nicht aus
Input-Validierung wird häufig auf Datentypen, Pflichtfelder und zulässige Zeichen beschränkt. Diese Prüfungen sind notwendig, bestätigen aber nur die formale Verarbeitbarkeit.
Eine IP-Adresse kann syntaktisch korrekt und trotzdem am vorgesehenen Ort falsch sein. Eine Rolle kann in einem IAM-System existieren und dennoch mehr Berechtigungen enthalten, als für den Anwendungsfall zulässig sind. Ein Änderungsauftrag kann vollständig ausgefüllt sein, aber auf einem veralteten Systemzustand beruhen.
Deshalb müssen mehrere Arten von Gültigkeit unterschieden werden:
- Strukturelle Gültigkeit: Sind Format, Datentypen und Pflichtfelder korrekt?
- Fachliche Gültigkeit: Entsprechen die Werte den Geschäftsregeln und technischen Standards?
- Kontextuelle Gültigkeit: Passen die Angaben zum Kunden, Mandanten, Standort und Zielsystem?
- Zeitliche Gültigkeit: Sind Daten, Freigaben und Referenzen noch aktuell?
- Berechtigungsbezogene Gültigkeit: Darf der Absender die angeforderte Änderung für diesen Umfang veranlassen?
- Sicherheitstechnische Gültigkeit: Bleibt die Eingabe innerhalb der definierten Sicherheits- und Auswirkungsgrenzen?
Erst wenn diese Ebenen erfüllt sind, darf eine Eingabe als Grundlage für eine automatisierte Aktion dienen.
Was vor der Ausführung geprüft werden muss
Die konkrete Validierung hängt natürlich vom Prozess ab. Die grundlegenden Fragen bleiben jedoch weitgehend gleich:
- Sind alle zwingend benötigten Angaben vorhanden?
- Liegen Werte innerhalb der zulässigen Bereiche?
- Sind voneinander abhängige Angaben widerspruchsfrei?
- Existieren referenzierte Objekte eindeutig und im richtigen Kontext?
- Gehören Ziel und Quelldaten zum gleichen Kunden oder Mandanten?
- Entspricht die Eingabe dem aktuellen Zustand des Zielsystems?
- Ist die anfordernde Identität für diese Aktion und diesen Umfang berechtigt?
- Überschreitet die geplante Auswirkung festgelegte Grenzwerte?
- Stammt die Eingabe aus einer zugelassenen und nachvollziehbaren Quelle?
- Ist die verwendete Version des Datenmodells weiterhin unterstützt?
Diese Prüfungen müssen erfolgen, bevor eine Änderung vorbereitet, ein KI-Modell mit operativen Entscheidungen beauftragt oder eine externe Schnittstelle mit schreibenden Parametern aufgerufen wird.
Die Validierung selbst darf automatisiert sein. Sie ist jedoch eine vorgeschaltete Kontrollinstanz und nicht Teil der eigentlichen Änderungsausführung.
Bei KI umfasst die Eingabe mehr als den Prompt
In einem KI-gestützten Prozess besteht der Input nicht nur aus der sichtbaren Benutzeranfrage. Zum tatsächlichen Eingabekontext gehören möglicherweise:
- Systemanweisungen und hinterlegte Richtlinien,
- aus Wissensdatenbanken geladene Dokumente,
- frühere Konversationen oder gespeicherte Zustände,
- automatisch ermittelte Kunden- und Systemdaten,
- Parameter für aufrufbare Werkzeuge,
- sowie Berechtigungen und Grenzen des ausführenden Kontos.
Jeder dieser Bestandteile kann falsch, veraltet, unvollständig oder einem falschen Kontext zugeordnet sein.
Besonders kritisch ist die automatisierte Bereitstellung zusätzlicher Informationen. Wenn ein Retrieval-System ein inhaltlich passendes Dokument findet, bedeutet das noch nicht, dass dieses Dokument aktuell ist oder im betreffenden Mandanten verwendet werden darf. Semantische Ähnlichkeit ersetzt weder Berechtigungsprüfung noch Herkunftsnachweis.
Vor dem Aufruf eines Modells müssen deshalb zumindest Quelle, Mandantenzuordnung, Zugriffserlaubnis, Aktualität und zulässiger Verwendungszweck des bereitgestellten Kontextes geprüft werden.
Ein KI-Modell darf diese Grenzen nicht selbst definieren. Sie müssen außerhalb des Modells deterministisch durchgesetzt werden.
Fehlende Angaben dürfen nicht stillschweigend ersetzt werden
Viele Automatisierungen versuchen, unvollständige Eingaben durch Standardwerte zu vervollständigen. Das kann bei unkritischen Komfortfunktionen sinnvoll sein. Bei operativen Änderungen kann es jedoch einen Eingabefehler verdecken.
Fehlt beispielsweise die Zielumgebung, darf nicht automatisch Produktion ausgewählt werden. Ist ein Mandant nicht eindeutig, darf nicht der zuletzt verwendete Mandant eingesetzt werden. Ist der gewünschte Berechtigungsumfang unklar, darf nicht die technisch naheliegende Rolle vergeben werden.
Für sicherheits- oder betriebsrelevante Werte muss der Grundsatz gelten:
Unklarheit stoppt die Ausführung.
Ein Validierungsfehler muss konkret benennen:
- welcher Wert fehlt oder unzulässig ist,
- gegen welche Regel er verstößt,
- welcher Kontext erwartet wurde,
- und was für eine erneute Verarbeitung korrigiert werden muss.
Nur so wird aus Validierung ein nutzbarer Bestandteil des Prozesses und keine schwer verständliche technische Hürde.
Input-Validierung ist ein verbindlicher Schnittstellenvertrag
Eine robuste Eingabevalidierung entsteht nicht aus einzelnen Prüfungen, die nach Bedarf in Skripte eingebaut werden. Sie benötigt einen klaren Vertrag zwischen dem System, das Daten erzeugt, und dem System, das sie verarbeitet.
Dieser Vertrag sollte festlegen:
- welche Angaben verpflichtend sind,
- welche Werte und Kombinationen zulässig sind,
- wie Identitäten und Mandanten zugeordnet werden,
- welche Zustandsinformationen vorausgesetzt werden,
- welche Auswirkungen maximal erlaubt sind,
- und wie mit ungültigen oder veralteten Eingaben umzugehen ist.
Schemas, Regeln und Datenmodelle gehören versioniert und gemeinsam mit der Automatisierung getestet. Dabei sind nicht nur gültige Beispiele zu prüfen. Gerade negative Testfälle zeigen, ob eine Automatisierung falsche, mehrdeutige oder unzulässige Eingaben tatsächlich ablehnt.
Fazit
Der sicherste Zeitpunkt, einen Fehler zu stoppen, liegt vor seiner Ausführung.
Automatisierung und KI können Daten schneller verarbeiten, Entscheidungen vorbereiten und Änderungen in großem Umfang umsetzen. Sie können aber nicht zuverlässig kompensieren, dass ihre Eingaben falsch, veraltet oder einem unzulässigen Kontext zugeordnet sind.
Input-Validierung ist deshalb keine vorgelagerte Formalität. Sie ist die erste verbindliche Sicherheits- und Qualitätsgrenze eines automatisierten Prozesses.