Eine Störungsmeldung, vom Posteingang bis zur freigegebenen Aktion
Der Agent läuft bereits. Sehen Sie zu, wie er die Anfrage interpretiert, Geräte-, Vertrags- und Lagerdaten abruft, eine Ursache vorschlägt — und vor dem Technikereinsatz stehen bleibt, weil diese Entscheidung einem Menschen gehört. Jeder Schritt ist anklickbar.
Die Schicht zwischen KI-Modell und verlässlicher Ausführung
Das Modell liefert Interpretation und Empfehlungen. Alles, was das Ergebnis verlässlich macht — Zustandsverwaltung, Werkzeuge, Richtlinien, Freigaben, Recovery, Audit — ist gewöhnliche, testbare Software. Genau diese Zwischenschicht baut Conpeak.
Eingangsschicht
Wie Anfragen eintreffenKI-Interpretationsschicht
Was das Modell beiträgtAgent-Harness
Die eigentliche Kontrollschicht — deterministisch, testbar, auditierbarGeschäftssysteme (simuliert)
Zugeschnittene Konnektoren statt offenem ZugriffOperations-Schicht
Wo Menschen die Kontrolle behaltenSpezialisierte Werkzeuge statt einer Alleskönner-Schnittstelle
| Tool | System | Zugriff | Zweck |
|---|---|---|---|
| find_customer | Kundendatenbank | nur lesend | Kunden in der Kundendatenbank per ID, E-Mail oder Firmennamen nachschlagen. |
| find_machine | Geräteregister | nur lesend | Maschinen im Geräteregister per ID, Seriennummer oder unscharfen Merkmalen finden. |
| get_machine_telemetry | Telemetrie-Plattform | nur lesend | Aktuelle Betriebsdaten einer Maschine auslesen. |
| get_service_history | Service-Management | nur lesend | Frühere Servicefälle einer Maschine abrufen. |
| get_service_contract | Vertragssystem | nur lesend | Aktiven Servicevertrag eines Kunden abrufen. |
| search_technical_manual | Wissensdatenbank | nur lesend | Handbücher, Fehlercode-Tabellen, Bulletins und Fehlersuche-Anleitungen durchsuchen. |
| check_part_inventory | Ersatzteillager | nur lesend | Bestand und Nachschub für ein Ersatzteil prüfen. |
| calculate_service_priority | Richtlinien-Engine | nur lesend | Deterministische Geschäftsregel: leitet die Dringlichkeit aus Maschinen- und Vertragsdaten ab. |
| create_service_ticket_draft | Service-Management | schreibend | Ticket-Entwurf im Service-Management-System anlegen (idempotenter Schreibzugriff). |
| dispatch_technician | Service-Management | schreibend | Technikereinsatz im Service-Management-System einplanen (kritischer Schreibzugriff). |
| send_customer_reply | Mail-Gateway (simuliert) | schreibend | Entworfene Antwort an den Kundenkontakt senden (kritischer Schreibzugriff, simulierter Postausgang). |
Schutzmechanismen, die Sie selbst auslösen können
Wählen Sie im Tab Demo unter „Und wenn es nicht glatt läuft?“ den Fall mit der versteckten Anweisung im Anhang, um den Umgang mit nicht vertrauenswürdigen Eingaben live zu sehen — oder versuchen Sie, als Service-Agent einen Einsatz freizugeben: Der abgelehnte Versuch landet im Audit-Protokoll.
Umgang mit nicht vertrauenswürdigen Eingaben
Anhangstexte und Nachrichteninhalte sind Daten, niemals Anweisungen. Ein Muster-Scanner markiert Injection-Versuche; markierte Inhalte werden als Beleg zitiert und von Entscheidungen ausgeschlossen.
Trennung von Lese- und Schreib-Tools
Lesende Abfragen laufen automatisch. Schreibende Tools (Einsatzplanung, Antwortversand) laufen nur mit erteilter Freigabe und verlangen einen Idempotenzschlüssel.
Rollenbasierte Berechtigungen
Service-Agenten bestätigen Maschinen und geben risikoarme Kommunikation frei; nur die Serviceleitung gibt Einsätze frei, löst Identitätskonflikte auf und entscheidet Vertragsausnahmen. Abgelehnte Versuche werden protokolliert.
Freigabe vor Ausführung
Jeder Schreibzugriff auf die (simulierten) Servicesysteme durchläuft ein Freigabe-Gate, das geplante Aktionen, Belege, Regelprüfungen, betroffene Systeme und das Risiko zeigt.
Vollständiges Audit-Protokoll
Szenario-Start, Dokumenten-Parsing, jeder Tool-Aufruf, jeder Wiederholungsversuch, jede Richtlinien-Entscheidung, Freigabe und jeder Schreibzugriff landen in einem persistenten Audit-Protokoll mit Korrelations-IDs.
Sicher schon durch die Konstruktion der Demo
Ausschließlich synthetische Daten, keine Secrets im Browser, strenge Upload-Beschränkungen (Typ und Größe validiert, Dateien nicht gespeichert), kein Abruf beliebiger URLs und Rate-Limits auf offenen Endpunkten.
KI im Produktivbetrieb braucht systematisches Testen
Eine synthetische Suite mit 33 Fällen prüft Geräteidentifikation, Fehlercode-Interpretation, Deckungsklassifikation, fehlende und widersprüchliche Angaben, bösartige Dokumente, Tool-Ausfälle, Berechtigungsverletzungen, nicht unterstützte Anfragen, Fälle mit niedriger Konfidenz und doppelte Meldungen.
Alle Werte sind interne Demo-Messungen auf synthetischen Daten. Die Spalte „Einfache KI“ führt eine bewusst naive Baseline aus (Regex-Extraktion, blindes Vertrauen in Dokumente, keine Wiederholungsversuche, keine Berechtigungen, keine Idempotenz); die Spalte „Produktions-Harness“ führt dieselben Code-Pfade aus, die diese Demo nutzt. Es werden keine externen Benchmarks behauptet.