Wenn wir bei einem Mittelständler am Besprechungstisch sitzen, fällt die Frage nach den Zugangsdaten fast immer in den ersten zwanzig Minuten. Über den ersten Anwendungsfall haben wir da noch nicht gesprochen. Der Inhaber will zuerst etwas anderes wissen: Wer schaut künftig in seine Systeme, wer bekommt seine Prozesse zu sehen und was passiert damit, wenn die Zusammenarbeit eines Tages endet.
Diese Frage stellt der Unternehmer meist selbst, bevor sein IT-Leiter überhaupt dazukommt. Zu Recht. Ein Agent, der Rechnungen prüft, braucht Zugriff auf Postfach, Dateiablage und ERP. Wer diesen Zugriff einrichtet, vergibt einen Generalschlüssel.
Bei herkömmlichen Automatisierungswerkzeugen werden die Zugangsdaten direkt in der Umgebung hinterlegt, in der auch die Workflows liegen. Wer diese Umgebung öffnet, erreicht jedes angebundene System. Betreut ein externer Dienstleister die Umgebung, hält er damit technisch die Schlüssel zum Unternehmen, unabhängig von der vertraglichen Regelung.
Architektur und Zugriffsverwaltung
Wir haben unsere Plattform so aufgebaut, dass Workflow-Logik und Zugangsverwaltung strikt getrennt sind.
Zentrale Schlüsselverwaltung: Die Workflow-Engine kennt keine Passwörter. Sie sendet Befehle wie „Postfach auslesen" an die Plattform, die den Zugriff ausführt und ausschließlich das Ergebnis zurückliefert. Wer die Engine öffnet, findet die Logik eines Agenten, aber keinen Schlüssel.
Zentrales Logging: Jeder Systemzugriff wird auf Plattformebene protokolliert. Dateizugriffe lassen sich auch Monate später an einer zentralen Stelle nachvollziehen, statt sie aus mehreren Automatisierungen zusammenzusuchen.
Zentrale Modellfreigabe: Wir legen fest, welche KI-Modelle einem Kunden zur Verfügung stehen, nicht die Person, die den Agenten baut. Das reduziert Schatten-KI, also den Abfluss von Kundendaten in private, unregulierte Werkzeuge.
Nahtloser Produktivbetrieb: Demos und Tests laufen auf derselben Infrastruktur wie der spätere Betrieb. Die Systeme eines Kunden binden wir genau einmal an. Steht diese Anbindung, ist der Weg von der Demo in den Testbetrieb eine Sache von Tagen, nicht von Wochen.
Modellwechsel im laufenden Betrieb
Für einen Zulieferer aus Österreich klassifiziert ein Agent eingehende Serviceanfragen und liest die Anhänge aus. Aufgesetzt war er zunächst auf einem US-amerikanischen Modell. Der Kunde äußerte den Wunsch, auf ein europäisches Modell zu wechseln.
Da die Modellauswahl in der Plattform gesteuert wird und nicht im Workflow, war das eine Einstellungsänderung und kein Umbau. Am Agenten selbst haben wir nichts angepasst. Noch bevor die ersten echten Kundendaten durch ihn liefen, arbeitete er auf Mistral. Digitale Souveränität wird so zu einem Schalter, den man umlegen kann, solange die Entscheidung noch nichts kostet.
Unterstützte Systeme und Validierung
Über diese Architektur laufen aktuell fünf unserer Kundeninstanzen mit gut 20.000 automatisierten Durchläufen pro Woche. Das ist nur ein Ausschnitt. Jeder Kunde arbeitet in einer eigenen Instanz.
Schnittstellen: Anbindung von Outlook und SharePoint, klassischen IMAP-Postfächern und einem SFTP-Server, den ein Kunde seit fünfzehn Jahren betreibt.
Dokumentenverarbeitung: PDF-Erstellung, direkte Kommentierung in Word-Originaldokumenten statt Neuerstellung, Texterkennung für gescannte Belege ohne Textebene.
Telefonie: Agenten können Anrufe tätigen oder entgegennehmen. Das Transkript läuft anschließend durch denselben Workflow wie eine E-Mail.
Schattenbetrieb: Vor dem Live-Gang laufen die Agenten im Lesemodus und verändern nichts im Quellsystem. Ergebnisse landen in einem Testordner, parallel entsteht eine Tabelle, in der der Kunde seine eigene Entscheidung gegen die des Agenten stellt. Erst bei belegter Zuverlässigkeit über eine ausreichende Zahl von Vorgängen erfolgt die Freigabe für das Zielsystem.
Fehler gehören zu einem System, das täglich echte Vorgänge anfasst: Modelle, die Anhänge verweigern, Ordnernamen, an denen ein Konnektor scheitert, Ausfälle mit nachzuholendem Rückstand. Wir messen das laufend und arbeiten es gemeinsam mit den Kunden ab.
Weiterentwicklung: Self-Service für Kunden
Heute bauen wir jeden Agenten selbst. Das ist unsere Wachstumsgrenze und der Grund, warum wir die Plattform so aufgesetzt haben. Ziel ist, dass Kunden künftig eigene Agenten per Chat-Eingabe erstellen und im Dialog anpassen, ohne Programmieraufwand und ohne Ticket. Wir rechnen dabei eher in Monaten als in Jahren. Dafür schaffen wir drei Voraussetzungen:
Transparenz je Vorgang: Je Vorgang muss sichtbar sein, welches Modell gearbeitet hat, was es gelesen hat und wie es entschieden hat. Erst dann kann man einem Agenten begründet vertrauen oder ihn begründet stoppen.
Übergreifende Datenstruktur: Wissen und Vorgänge liegen auf einer gemeinsamen Struktur, auf der neue Anwendungsfälle direkt aufbauen, statt wieder bei null zu beginnen.
Bauen ohne Zugangsdaten: Der Kunde baut selbst, ohne unsere Bauzeit und ohne je mit Zugangsdaten zu hantieren. Nur wenn die Schlüssel gar nicht erst in seine Reichweite gelangen, bleibt der Baukasten eine Kontrollebene und wird nicht zum größten Sicherheitsrisiko im Unternehmen.
Wenn Sie sich ein KI-Werkzeug vorführen lassen, prüfen Sie früh drei Punkte: Wo liegen die Zugangsdaten, wer kann sie einsehen und was steht im Protokoll, wenn Sie in einem Jahr nachvollziehen wollen, wer worauf zugegriffen hat. Die Antwort darauf sagt mehr über einen Anbieter aus als jede Demo.
Sie wollen sehen, wie das in Ihrem Betrieb aussehen würde? 45 Minuten Erstgespräch, ehrlich und unverbindlich.