
KI-Agent
Wir gestalten KI innerhalb bestehender Berechtigungen, aufgabenspezifischer Datengrenzen und kontrollierter Anwendungsprozesse.
Ein KI-Agent darf kein direkter Weg zur Datenbank oder zu administrativen Rechten sein. Er arbeitet innerhalb der Grenzen von Anwendung und konkretem Prozess. Bevor Daten in eine KI-Aufgabe gelangen, prüfen vertrauenswürdige Anwendungskomponenten Benutzer, Zugriff und Zweck.
| Frage | Verantwortung der Anwendung | |---|---| | Wer ist der Benutzer? | Authentifizierung | | Was darf er lesen oder tun? | Autorisierung und Rollen | | Welche Daten darf er sehen? | Organisation, Kunde, Mandant oder Dokument | | Welche Aktion darf er ausführen? | Aktionsvalidierung und Freigaberecht |
Leserecht erlaubt nicht automatisch Änderung, Zahlungserstattung oder Änderung fremder Zugänge. Menschliche Freigabe kann nötig sein, ersetzt aber keine technischen Kontrollen.
Bei einem hypothetischen Supportfall kann KI Nachricht, Produkt und aktuellen Status für eine Zusammenfassung erhalten. Passwort, Sitzungstoken, fremde Rechnungen oder Daten anderer Kunden braucht sie nicht. Datenminimierung begrenzt Eingaben, ersetzt aber nicht die Zugriffsprüfung vor der Auswahl.
Benutzer → [Anwendung: Identität, Recht, Datenumfang]
│
▼
ausgewählte Aufgabendaten
│
▼
KI-Anbieter
│
▼
nicht vertrauenswürdiges Ergebnis → Validierung → erlaubte AktionEin Wissensassistent durchsucht zuerst nur Dokumente der aktuellen Berechtigung. Bei Rechnungen kann KI Werte vorschlagen; Anwendung prüft Format und Regeln, eine berechtigte Person verifiziert vor der bestehenden Freigabe. Dies sind illustrative Beispiele, keine GiSoft-Kundenprojekte.
Prompt Injection versucht, in Kundennachrichten oder Dokumenten Anweisungen zu platzieren, die KI von ihren Regeln abbringen sollen. Solche Inhalte sind nicht vertrauenswürdige Daten, keine Anwendungsanweisung. Begrenzter Kontext, Trennung von Instruktionen und Inhalt, Ergebnisvalidierung und eingeschränkte Werkzeuge helfen; keine einzelne Maßnahme beseitigt das Risiko vollständig.
Strukturiertes JSON oder hoher Confidence Score garantiert keine korrekten Kategorien, Zusammenfassungen, Rechnungswerte oder Aktionen. Secrets gehören nicht in Prompts, Kontext oder Antworten; eine getrennte Integrationsschicht garantiert Vertraulichkeit nicht selbst.
Sinnvolle Betriebsnachweise können Fall-ID, Benutzer, Quellen, Prozessversion, Validierung und freigegebene Aktion enthalten, ohne vollständige Prompts oder Dokumente aufzubewahren. Bei verzögerten Ergebnissen werden relevante Rechte erneut geprüft.
Timeout, ungültige Ausgabe, entzogener Zugriff, fehlende Quelle oder Abbruch brauchen sichtbaren Status und prozessspezifisches Verhalten. Manueller Fallback ist nur nützlich, wenn er gestaltet und geprüft wurde. Maßgebliche Daten, Entscheidungen und Aktionen bleiben bei Anwendung und berechtigten Personen.