Eine KI-Antwort kann präzise wirken und dennoch ungeeignet sein, um Operationen in einem System auszuführen. Dass sie eine Anfrage als dringend einstuft, das Ausfüllen eines Feldes vorschlägt oder empfiehlt, einen Workflow zu starten, bedeutet nicht, dass sie dazu berechtigt ist, über ausreichenden Kontext verfügt oder die Geschäftsregeln erfüllt. Das Risiko entsteht, wenn ein textueller oder strukturierter Vorschlag ohne unabhängige Barrieren in einen ausführbaren Befehl umgewandelt wird.
Um strukturierte KI-Ausgaben in PHP zu validieren, sollte das Modell als Komponente behandelt werden, die Vorschläge vorbereitet, nicht als Instanz, die Datensätze ändert, Zuständige zuweist, Kommunikation versendet oder Prozesse startet. Die Anwendung behält die Entscheidung, wendet ihre eigenen Regeln an und protokolliert, warum ein Vorschlag akzeptiert, korrigiert oder abgelehnt wurde.
Eine plausible Ausgabe ist keine gültige Anweisung
Modelle können syntaktisch korrektes JSON zurückgeben und dennoch eine nicht vorhandene Priorität, eine Kennung, die nicht zum Kunden gehört, ein unmögliches Datum oder eine Aktion enthalten, die der Benutzer nicht anfordern darf. Sie können auch Daten ergänzen, die in der Eingabe nicht vorhanden sind, eine Mehrdeutigkeit falsch interpretieren oder nach einer Vertragsänderung einem alten Format folgen.
Die operative Grenze muss explizit sein: Die KI darf eine Aktion vorschlagen und die verwendeten Daten erläutern; das System entscheidet, ob dieser Vorschlag zu einem Entwurf wird, eine Prüfung erfordert oder unter sehr eng begrenzten Bedingungen ausgeführt werden kann. Diese Trennung schützt sowohl die Datenintegrität als auch die Verantwortung für die Entscheidung.
Ein guter Ausgangspunkt ist, jede Aktion nach ihrer Auswirkung zu klassifizieren:
- Geringe Auswirkung: einen Entwurf kennzeichnen, eine Kategorie vorschlagen oder nicht kritische Felder extrahieren.
- Mittlere Auswirkung: eine ausstehende Aufgabe erstellen, eine zuständige Person vorschlagen oder eine Antwort zur Prüfung vorbereiten.
- Hohe Auswirkung: Vertragsstatus ändern, irreversible Arbeit zuweisen, Beträge ändern, Daten löschen, extern kommunizieren oder sensible Prozesse aktivieren.
Die zulässige Autonomie hängt nicht davon ab, dass die KI eine hohe erklärte Konfidenz aufweist. Sie hängt von der Reversibilität, den Kosten eines Fehlers, der überprüfbaren Qualität der Daten und dem Vorhandensein von Kontrollen außerhalb des Modells ab.
Einen Vorschlagsvertrag definieren, bevor das Modell integriert wird
Der Ausgabe-Vertrag definiert, was die KI-Komponente vorschlagen darf und was außerhalb ihres Zuständigkeitsbereichs liegt. Er muss klein, typisiert und versioniert sein. Statt „entscheide, was mit dieser Anfrage zu tun ist“ zu verlangen, geben Sie eine geschlossene Liste von Aktionen und die für jede Aktion notwendigen Felder an.
{
"version": "1",
"action": "create_task_draft",
"category": "billing",
"priority": "normal",
"summary": "Abweichung in Rechnung prüfen",
"sourceReferences": ["message:123"],
"confidence": 0.82
}Die Aktionsliste muss kontrollierte Werte verwenden, beispielsweise create_task_draft, request_more_information oder no_action. Methodennamen, Abfragen, Codefragmente, freie Empfänger oder Anweisungen wie „aktualisiere die Bestellung“ sollten nicht akzeptiert werden. Die Anwendung übersetzt eine erlaubte Aktion in eine konkrete interne Operation.
Felder, Zustände und Nachweise
Neben Typen und erlaubten Werten muss der Vertrag angeben, welche Felder obligatorisch sind, welche Kombinationen inkompatibel sind und welche Nachweise der Vorschlag liefern muss. Eine Kategorie kann gültig sein, aber mindestens eine Referenz auf die Ursprungsnachricht oder das Ursprungsdokument erfordern. Die Konfidenz ist, falls sie erfasst wird, ein Hilfswert zur Priorisierung von Prüfungen; sie ersetzt keine Validierung.
Die Versionierung des Schemas ermöglicht es, Ausgaben aus zurückgezogenen Verträgen sicher abzulehnen. Wenn eine Änderung ein Pflichtfeld hinzufügt oder eine Aktion entfernt, muss der Adapter die Version erkennen und implizite Interpretationen vermeiden.
Vier Barrieren vor jeder Auswirkung anwenden
Die Validierung muss in getrennten Schichten erfolgen. Ein Fehler in einer Schicht wird nicht durch eine in einer anderen scheinbar vernünftige Antwort ausgeglichen.
- Format: prüfen, ob die Antwort dekodiert werden kann, ob sie dem erwarteten Schema entspricht, keine unerwarteten kritischen Felder enthält und jeder Wert den richtigen Typ hat. Ungültiges JSON, eine unbekannte Enumeration oder ein fehlendes Pflichtfeld werden abgelehnt.
- Domäne: anwendungseigene Regeln überprüfen. Beispielsweise, ob die Kategorie existiert, die Priorität auf den Anfragetyp anwendbar ist, das referenzierte Konto aktiv ist und die Ursprungsreferenz zum verarbeiteten Kontext gehört.
- Autorisierung: prüfen, was der Akteur, der den Workflow gestartet hat, tun darf und welche Berechtigungen die Operation erfordert. Die KI erbt weder unbegrenzte Privilegien noch entscheidet sie über den Zugriffsbereich. Der Server wendet die Identität, den Tenant und die geltenden Richtlinien an.
- Operative Bedingungen: Nebenläufigkeit, aktuelle Zustände, Limits, Abhängigkeiten und Idempotenz prüfen. Ein gültiger Vorschlag kann möglicherweise nicht ausgeführt werden, wenn der Fall bereits geschlossen wurde, ein anderer Prozess den Datensatz geändert hat oder ein Lastschwellenwert überschritten wurde.
Die semantische Validierung muss interne Quellen der Wahrheit abfragen. Es reicht nicht aus, dass das Modell eine wohlgeformte Kennung zurückgibt: Das Repository oder der Domänendienst muss ihre Existenz, Zugehörigkeit und ihren Status überprüfen. Vermeiden Sie, dass die Modellantwort Autorisierungsdaten mitführt, die die Anwendung selbst auflösen kann.
PHP-Architektur: Vorschlag, Entscheidung und Ausführung getrennt
Eine wartbare Architektur trennt Verantwortlichkeiten. Der KI-Adapter bereitet die Anfrage vor, wendet Größenlimits an und erhält eine Ausgabe; er schreibt nicht in die Geschäftsdatendatenbank. Ein DTO repräsentiert den bereits geparsten Vorschlag. Der Domänenvalidator wandelt diesen Vorschlag in eine Entscheidung mit expliziten Fehlern um. Schließlich wendet ein autorisierter Executor nur genehmigte Entscheidungen an.
final class ActionProposal {
public function __construct(
public string $action,
public string $category,
public string $priority,
public array $sourceReferences,
) {}
}
$proposal = $aiAdapter->propose($input);
$validation = $domainValidator->validate($proposal, $context);
if (!$validation->isApproved()) {
$auditLog->recordRejected($proposal, $validation->reasons());
return $validation;
}
return $decisionService->route($validation->approvedProposal(), $context);Der Entscheidungsdienst kann einen Entwurf erstellen, ihn in eine Prüfwarteschlange stellen oder eine menschliche Genehmigung anfordern. Der finale Executor muss ein internes Entscheidungsobjekt erhalten, nicht die Rohausgabe oder das JSON der KI. So wird verhindert, dass eine versehentliche Erweiterung des Vertrags zu einer neuen operativen Fähigkeit wird.
Verwenden Sie Transaktionen für zusammenhängende Änderungen, Idempotenzschlüssel für Wiederholungsversuche und Nebenläufigkeitskontrollen, wenn mehrere Personen oder Prozesse auf denselben Fall einwirken können. Unterscheiden Sie außerdem zwischen Bereitstellung und Aktivierung: Der Code kann bereitgestellt sein, ohne den Workflow echten Benutzern zugänglich zu machen. Eine schrittweise Aktivierung ermöglicht es, Ablehnungen, Zeiten und Korrekturen zu beobachten, bevor der Umfang erweitert wird.
Menschliche Prüfung, begrenzte Automatisierung oder Ablehnung wählen
Eine menschliche Prüfung ist angemessen, wenn wesentliche Mehrdeutigkeit, sensible Daten, externe Folgen, Richtlinienausnahmen oder hohe Korrekturkosten vorliegen. Die Prüfoberfläche sollte den Vorschlag, die zulässigen Herkunftsnachweise, die erfüllten Regeln und die Warnhinweise anzeigen, ohne die Empfehlung als Tatsache darzustellen.
Begrenzte Automatisierung kann für reversible und abgegrenzte Vorgänge angemessen sein: einen nicht zugewiesenen Entwurf erstellen, ein vorläufiges Label anwenden oder eine Anfrage an eine allgemeine Warteschlange weiterleiten. Sie muss Frequenzlimits, eine Möglichkeit zum Rückgängigmachen und nachträgliche Überwachung haben. Wenn Daten fehlen, ein Konflikt zwischen Regeln besteht oder die Aktion außerhalb der erlaubten Liste liegt, ist das sichere Verhalten, abzulehnen oder zu eskalieren, nicht zu improvisieren.
Bevor Sie KI einsetzen, bewerten Sie eine deterministische Alternative. Wenn die Eingaben stabilen Mustern folgen, können Regeln, geführte Formulare, Auswahllisten oder ein herkömmlicher Klassifikator günstiger, auditierbarer und vorhersehbarer sein. Wenn KI eingesetzt wird, definieren Sie den Anwendungsfall, einen repräsentativen Evaluierungssatz, operative Schwellenwerte, Kosten pro Volumen und einen Degradationsmodus für den Fall, dass der Anbieter ausfällt oder die erwartete Zeit überschreitet.
Beispiel: Eine Anfrage in einen Aufgabenentwurf umwandeln
Nehmen Sie eine eingehende Anfrage an, die eine Abweichung in einer Rechnung erwähnt. Die KI kann die Kategorie billing, normale Priorität und die Zusammenfassung einer Aufgabe vorschlagen. Der Validator prüft, ob die Nachricht zum aktuellen Tenant gehört, die Kategorie aktiviert ist und noch kein offener Fall mit derselben Referenz existiert. Wenn alles korrekt ist, erstellt das System einen Entwurf, ohne eine zuständige Person zuzuweisen oder den Status der Rechnung zu ändern.
Ein Bearbeiter prüft den Entwurf, bestätigt oder korrigiert die Kategorie und entscheidet die Zuweisung entsprechend der aktuellen Auslastung und Berechtigungen. Diese Unterscheidung verhindert, dass eine plausible Schlussfolgerung über eine zuständige Person oder einen Betrag zu einer fehlerhaften Änderung wird. Wenn der Vertrag eine Rechnungsnummer erfordert und diese nicht in der Nachricht erscheint, muss der Vorschlag zusätzliche Informationen anfordern, statt sie zu erfinden.
Nachvollziehbarkeit, Datenschutz und Tests vor der Erweiterung des Workflows
Protokollieren Sie eine Korrelationskennung, die Vertragsversion, einen Fingerabdruck oder eine Referenz der minimierten Eingabe, den normalisierten Vorschlag, die Ergebnisse jeder Validierung, die endgültige Entscheidung, gegebenenfalls den genehmigenden Akteur und den Ablehnungsgrund. Das Protokoll muss zur Untersuchung von Vorfällen nützlich sein, ohne unnötig personenbezogene Daten oder sensible Inhalte zu duplizieren. Wenden Sie Aufbewahrung, eingeschränkten Zugriff und dem Prozessrisiko entsprechende Minimierungstechniken an.
Testen Sie den Workflow mit repräsentativen und adversarialen Fällen: unvollständige Eingaben, widersprüchliche Anweisungen, erfundene Werte, Referenzen eines anderen Tenants, gleichzeitige Zustandsänderungen, Antworten im alten Format, Latenz und Ausfall des KI-Dienstes. Die Akzeptanzkriterien müssen messen, ob nicht autorisierte Operationen blockiert werden, ob Entwürfe wiederherstellbar sind, ob Ablehnungen verständlich sind und ob das System bei Fehlern eine funktionsfähige Alternative beibehält.
Sicherer Betrieb besteht nicht darin, zu erreichen, dass das Modell immer antwortet. Er besteht darin sicherzustellen, dass die PHP-Anwendung die Kontrolle behält und keine Wirkungen erzeugt, die sie nicht rechtfertigen kann, wenn es falsch antwortet, zu lange braucht oder nicht antwortet.
