KI-Governance: Selbstreflexion & Genehmigungen

Business-object Introspektion (Bereich introspection:read)

Drei Analysetools ermöglichen es einem KI-Client, die Struktur des Unternehmens zu erfassen, bevor er es berührt: welche Objekte existieren (einschließlich der benutzerdefinierten Felder und Objekte des Arbeitsbereichs), was jedes Attribut bedeutet, wie Objekte miteinander in Beziehung stehen und welche Aktionen ausführbar sind – mit ihren Vorbedingungen und dem aktuellen Status. Ein korrekt konfigurierter Agent ruft diese Informationen zuerst ab und schlägt nur Aktionen vor, die der Status tatsächlich zulässt.

Schreiben Sie Werkzeuge unter eine Rezension: ausstehend/abgelehnt

Wenn ein MCP-Schreibwerkzeug eine Aktion mit dem Gear review anvisiert, führt der Aufruf not den Seiteneffekt nicht aus. Er gibt ein strukturiertes Ergebnis zurück: Entweder wurde der Vorschlag zur menschlichen Genehmigung in die Warteschlange gestellt (pending) oder er wurde direkt abgelehnt (refused) mit einem maschinenlesbaren reason_code und einem suggested_action.

// proposed — waiting for a human
{
  "status": "pending",
  "proposal_id": "prop_9f2c…",
  "action": "issue_coupon",
  "expires_at": "2026-07-10T00:00:00Z",  // 7 days
  "message": "Queued for human approval in
              AI Activity & Approvals."
}

// refused — with a reason and a next step
{
  "status": "refused",
  "action": "issue_coupon",
  "reason_code": "recently_rejected",
  "suggested_action": "A human rejected this
    proposal recently. Do not re-propose;
    consider a different action or ask the
    operator."
}

Jede Ablehnung trägt ein reason_code in dieser Form plus ein suggested_action – behandeln Sie die oben genannten Codes als diejenigen, auf die verzweigt werden soll, und das Feld als erweiterbar. Eine Ablehnung ist für Sie eine schwierige Grenzüberschreitung und kein Fehler, den Sie noch einmal umgehen müssen: Formulieren Sie einen Vorschlag niemals um, um an einer Ablehnung vorbeizukommen.

Transparenz-Primitive & das Glass-Box-Modell für die Bestandsverwaltung

Die gleiche Transparenz – jede automatisierte Entscheidung protokolliert und nachvollziehbar, personenbezogene Daten aus dem Modellkontext ferngehalten – erstreckt sich über die geregelten Aktionen hinaus: auf die Optimierung des Datenverkehrs, auf ausgehende LLM-Aufforderungen und auf das klassische ML-Modellinventar, das Ranking, Vorhersage und Erkennung im gesamten Produkt ermöglicht.

A/B-Verkehrsoptimierung: das Entscheidungsprotokoll

Wiederkehrende Kampagnen (Automatisierungen und Customer Journeys) können sich dafür anmelden Automatische Optimierung des Datenverkehrs im Laufe der Zeit, wodurch die Auslieferungsgewichte auf die verschiedenen Experimentvarianten basierend auf der beobachteten Klickleistung neu verteilt werden. Jede Neuverteilung ist nachvollziehbar:

• Entscheidungsprotokoll (nur Anhängen). Bei jeder stündlichen Neuberechnung wird ein Datensatz mit den angewendeten Gewichtungen und einer lesbaren Begründung erstellt. Datensätze werden niemals überschrieben – das Protokoll dokumentiert die vollständige Historie des Datenverkehrs.
• Die konfigurierte Aufteilung wird nicht verändert. Die konfigurierte Aufteilung Ihres Experiments bleibt als Basiswert unverändert; optimierte Gewichtungen werden berechnet und parallel protokolliert.
• Explorationsschwelle: 10 %. Die Gewichtung keiner Variante fällt jemals unter 10 %, sodass jede Variante weiterhin Traffic generiert und eine Trendwende erkennbar bleibt.
• Gleichmäßige Aufteilung bis ≥100 Auslieferungen pro Variante. Die Gewichtung bleibt so lange auf der konfigurierten Aufteilung, bis jede Variante mindestens ~100 Auslieferungen erreicht hat – keine Neuverteilung bei geringen Datenmengen und kein statistischer „Gewinner“ wird durch diesen Mechanismus ermittelt.

LLM PII-Maskierung an der Provider-Naht

Bevor eine Anfrage Flash an einen externen LLM-Anbieter weitergeleitet wird, werden die persönlichen Identifikationsdaten der Mitglieder maskiert – und zwar direkt an der Schnittstelle zum Anbieter, sodass jede KI-Funktion diesen Prozess durchläuft:

• Deterministische Pseudonyme. E-Mail-Adressen, Telefonnummern und kartenähnliche Ziffernfolgen werden durch stabile Platzhalter ersetzt. Derselbe Bezeichner wird immer demselben Pseudonym zugeordnet, sodass die Argumentation des Modells über eine Eingabeaufforderung hinweg konsistent bleibt.
• Die Maskierung gilt für jede ausgehende Eingabeaufforderung jeder KI-Funktion – es gibt nichts zu aktivieren, und sie kann nicht im Produkt deaktiviert werden.
• Nur maskiert, niemals demaskiert. Die Zuordnung ist an der Ausgabegrenze unidirektional: Die Modellausgabe wird niemals umgeschrieben, um echte Kennungen wiederherzustellen, sodass rohe personenbezogene Daten nicht durch eine LLM-Antwort übertragen werden können.

Inventar des Glaskastenmodells

Jede Vorhersage- oder Statistikfunktion im Produkt ist ein klassisches, deterministisches Modell – keine Black-Box-Bewertung, keine Stichprobenentnahme, sodass dieselben Daten immer dasselbe Modell erzeugen. Jedes trägt ein explizites Ehrlichkeitstor: Unterhalb des Tors gibt es nichts statt einer Vermutung aus, und jede Punktzahl wird mit den Zahlen geliefert, die zur Neuberechnung erforderlich sind. Der aktuelle Bestand:

Keines dieser Modelle agiert jemals eigenständig: Sie bewerten, werten aus und kennzeichnen Transaktionen, und alles, was Geld bewegt oder ein Mitglied kontaktiert, durchläuft die oben genannten, festgelegten Mechanismen.

Für alle technischen Details zu den einzelnen Modellen – Methoden, Eingaben, Ausgabespalten, Integritätsprüfungen und Nutzungsflächen – siehe die Referenz für Vorhersagemodelle.