KI, die euch gehört.
Nicht dem Anbieter.
Zum vierten Mal ordnet sich die Büroarbeit neu.
Der Wandel ist nicht Zukunftsmusik. Er läuft bereits, in jedem Unternehmen.
Apps sind teuer. Menschen sind das Nadelöhr. Jede Aufgabe wird zur eigenen App, teuer gebaut, teuer gewartet. Mitarbeitende warten auf IT, weil jede Ausnahme ein Ticket braucht. Und mit jeder Kündigung verlässt Wissen die Firma, unwiderruflich.
Mehr Fähigkeit hat bisher immer mehr Daten gekostet
Ein Fenster, in das jemand Text tippt. Nützlich, aber ohne Zugriff auf eure Systeme, und jede Anfrage fängt wieder bei null an.
Sitzt in den Office-Werkzeugen und sieht, woran gerade gearbeitet wird. Genau das sieht der Anbieter mit.
Agenten, die wirklich arbeiten, betrieben beim Anbieter. Er bestimmt Modell, Datenfluss und Preis, und er sieht nahezu alles, was durchläuft.
Dieselben Agenten, dieselbe Fähigkeit, nur bei euch im Haus betrieben. PrivacyGuard nimmt vor jedem Modellaufruf die persönlichen Daten heraus und setzt sie danach wieder ein.
Bisher galt: wer mehr Fähigkeit wollte, musste dem Modell-Anbieter einen grösseren Teil der eigenen Daten überlassen. agentctl löst diese Kopplung auf, statt sie zu verwalten.
Dass die Daten im Haus bleiben, ist nicht nur Schutz. Über fünf Jahre wird daraus der Unterschied zwischen gemieteter und eigener KI.
Die Nutzung wächst
Mitarbeitende verlagern Monat für Monat mehr Arbeit auf ihre Agenten, weil das, was einmal funktioniert hat, danach immer funktioniert.
Die Daten wachsen mit
Dabei entsteht eine Aufzeichnung davon, wie euer Betrieb tatsächlich arbeitet: Abläufe, Entscheide, Begründungen, Ausnahmen.
Diese Daten gehören euch
Sie liegen auf eurer Infrastruktur, unter eurer Kontrolle, in eurem Besitz.
Ohne agentctl: laufend zum Anbieter gestreamt.Daraus wird eine KI, die euch gehört
Ein System, das euren Betrieb kennt, weil es ihn jahrelang mitgeschrieben hat. Das kann euch kein Anbieter verkaufen.
Ein Abo endet, wenn ihr kündigt. Eine Datenbasis über die eigene Arbeit bleibt, mitsamt den Abläufen, die darauf aufbauen.
Echter Systemzugriff, und acht Prinzipien, die ihn beherrschbar machen
agentctl läuft dort, wo ihr entscheidet: eigene Cloud, eigenes Rechenzentrum, on-prem. Was darin passiert, regeln diese acht Punkte.
PrivacyGuard
Vor jedem Modellaufruf läuft der Prompt durch eine Filterstufe: Namen, Vertragsnummern und Kundendaten werden ersetzt. Das externe Modell sieht die Aufgabe, nicht die Person; im Haus wird die Antwort wieder zusammengesetzt.
Config-Audit
Jede Änderung an einer Agenten-Konfiguration ist protokolliert: wer, wann, und was vorher galt. Im Review lässt sich der Stand von letztem Dienstag belegen, statt ihn zu rekonstruieren.
Cost Control
Verbrauch und Budget sind pro Agent und pro Person jederzeit sichtbar, mit Limiten, die greifen, bevor eine Rechnung überrascht. Kein Posten, der erst im Monatsabschluss auffällt.
Governed Skills
Agenten arbeiten mit einer geprüften Bibliothek von Werkzeugen und Abläufen, zentral verwaltet. Niemand hängt im Alleingang ein Tool an, das IT & Security nie gesehen hat.
One Owner
Jeder Agent gehört genau einer Person und läuft mit deren Rechten aus dem bestehenden Konto. Keine Sammelidentität, also auch keine Aktion ohne zurechenbaren Verursacher.
Model Choice
GPT, Claude, Gemini oder ein Modell in der eigenen Infrastruktur, jederzeit wechselbar, ohne den Agenten neu zu bauen. Der Anbieter ist eine Einstellung und keine Abhängigkeit.
Human in the Loop
Ein Entscheidungsmodell hält Aktionen an, die unsicher oder folgenschwer sind, und legt sie einer Person vor. Routine läuft durch, der Grenzfall wartet auf eine Freigabe.
Secret Store
Zugangsdaten liegen verschlüsselt im eigenen Haus und werden erst zur Laufzeit geholt. Sie landen in keinem Prompt, in keinem Log und bei keinem Modell-Anbieter.
Alles, was ein Agent tun kann, läuft über einen Kontrollpunkt
Die Agenten hängen nicht einzeln an euren Systemen. Sie hängen an agentctl, und agentctl hängt an den Systemen, die ihr schon habt.
- Standard-Konnektoren und APIs
- Zugriffe, die ihr ohnehin vergebt
- Auf Servern, die euch gehören
- Nichts wird ersetzt
- Nichts wird migriert
- Die Systeme bleiben, wie sie sind
Ein Agent pro Person, alle über denselben Kontrollpunkt: dort hängen Rechte, Protokoll, Budget und Modellwahl. Deshalb kostet der elfte Agent keine neue Integration.
Was konkret passiert, wenn ein Auftrag reinkommt
Nicht die Bauteile: der tatsächliche Ablauf, Schritt für Schritt.
Auftrag entsteht
Per E-Mail, Ticket, Zeitplan oder Ereignis im System, genau wie bei einem Mitarbeitenden.
Rechte werden geprüft
Mit der geerbten Identität, keine Sonderrolle, kein separates Konto.
Agent handelt im System
Klickt, tippt, navigiert wie ein Mitarbeitender, nicht nur eine Antwort im Chat.
Jede Aktion protokolliert
Zeitstempel, Auftrag, Ergebnis, nachvollziehbar für Audit.
Als echte, Schritt-für-Schritt-Animation
Vom Posteingang bis zum Audit-Vault, inklusive des Moments, in dem PrivacyGuard die persönlichen Daten herausnimmt, bevor etwas das Haus verlässt.
Heute verbindet der Mensch die Systeme. Künftig tut es sein Agent.
Kein Chatbot, keine RPA, kein Custom-Build
Drei bekannte Wege, ein Problem zu lösen, und wo agentctl sich strukturell unterscheidet.
| Kriterium | Chatbot-Tools | RPA | Custom-Build | agentctl |
|---|---|---|---|---|
| Zugriff auf echte Systeme | Nur Text-Antworten | Ja, aber starr verdrahtet | Ja, wie gebaut | Ja, wie ein Mitarbeitender |
| Rechte & Identität | Keine | Eigener Service-Account | Individuell gebaut | Geerbt von der echten Identität |
| Reagiert auf Ausnahmen | Nein | Nein, bricht ab | Nur was vorgesehen wurde | Ja, wie ein Mensch würde |
| Wartung bei UI-Änderungen | — | Hoch: Skripte brechen | Hoch: eigenes Team nötig | Gering: LLM interpretiert neu |
| LLM-Wahl | Meist fix vorgegeben | — | Frei, aber selbst integriert | Frei, jederzeit austauschbar |
| Time-to-Value | Sofort, aber limitiert | Wochen pro Prozess | Monate | Tage bis Wochen |
nicht im Pilotprojekt auf Papier.
Rund 100 Nutzende bei einem IT- und Digitalisierungspartner Schweizer Banken und Versicherer
Die Agenten laufen dort über mehrere Fachbereiche, auf der bestehenden Identität der Mitarbeitenden und in der Infrastruktur des Hauses.
Entstanden in einem FINMA-regulierten Fondshaus in Zürich
Dort wurde agentctl gebaut, weil es nichts Vergleichbares gab, das die Compliance-Anforderungen erfüllt. Es läuft dort bis heute jeden Tag produktiv.
So sieht das im Betrieb aus
Drei Oberflächen aus dem Cockpit: der Posteingang eines Agenten, der Stand aller Agenten einer Firma, und ein Lauf, der auf eine Freigabe wartet.
Und jede dieser Aktionen landet im Protokoll: mit Zeitstempel, Auftrag und Ergebnis, in derselben Form wie bei einem Menschen.
Typische Aufgaben, ob KMU oder regulierte Branche
Illustrativ: die konkrete Umsetzung hängt immer an euren echten Systemen und Prozessen.
Was Sicherheits- und IT-Verantwortliche als Erstes fragen
Was Sicherheits- und IT-Verantwortliche brauchen, um Ja zu sagen
Die FAQ oben beantwortet die ersten Fragen kurz. Hier die Vertiefung, ohne Marketing-Umweg.
Datenresidenz
agentctl läuft dort, wo ihr entscheidet: eigene Cloud, eigenes Rechenzentrum, on-prem. Es gibt keine Pflicht, Daten zu agentctl zu senden. Die Architektur ist self-hosted by default. Die einzige Ausnahme ist bewusst gewählt: wenn ihr ein extern gehostetes Sprachmodell einsetzt (z. B. ein API-basiertes Modell statt eines lokal gehosteten), verlassen die Prompts & Antworten dieses spezifischen Aufrufs die eigene Infrastruktur in Richtung des Modell-Anbieters, dessen Datenschutzbedingungen dann zusätzlich zu unseren gelten.
Eine Anfrage, Schritt für Schritt
Statt das nur zu behaupten: ein echter Ablauf, Schritt für Schritt: eine Anfrage kommt per E-Mail rein, der Agent schlägt Kundendaten nach, nutzt eine bereits gelernte Skill. Bevor etwas das Haus verlässt, nimmt PrivacyGuard alle persönlichen Daten heraus; erst die geschwärzte Anfrage geht an das externe Sprachmodell, die Antwort kommt verschlüsselt zurück und PrivacyGuard setzt die Daten wieder ein. Jeder Schritt landet unveränderbar im Audit-Vault, nachvollziehbar für IT & Security.
PrivacyGuard ist der Name dieser Stufe im Produkt, nicht eine Konfiguration, die jemand vergessen kann: ohne sie kommt kein Aufruf an ein extern gehostetes Modell zustande.
Identität & Zugriff
Ein Agent bekommt keine eigene, neue Rolle. Er erbt die Rechte der echten Mitarbeiter-Identität, in deren Auftrag er läuft, dieselbe Berechtigungsprüfung wie bei einem Menschen, kein zusätzliches Berechtigungsmodell, das separat gepflegt werden müsste.
Audit & Nachvollziehbarkeit
Jede Aktion eines Agenten wird mit Zeitstempel, Auftrag und Ergebnis protokolliert. Weil der Agent exakt die Rechte der echten Identität nutzt, taucht er in euren bestehenden Audit-Trails genauso auf wie ein menschlicher Mitarbeitender. Kein zusätzliches, separates Logging-System nötig, das erst noch an eure bestehende Audit-Pipeline angebunden werden müsste.
Für ein Sicherheits-Review bedeutet das konkret: die Frage „wer hat das getan“ hat für einen Agenten dieselbe Antwortform wie für einen Menschen: ein Konto, ein Zeitstempel, eine Handlung.
Modellwahl
agentctl bindet euch nicht an einen einzelnen LLM-Anbieter. Einsetzbar ist jedes Modell: GPT, Claude, Gemini, oder ein lokal in eurer eigenen Infrastruktur gehostetes Open-Weight-Modell. Der Wechsel zwischen Modellen ändert nur, welches Modell die Sprachverarbeitung übernimmt, nicht wie der Agent gebaut ist.
Das ist auch eine Sicherheitsentscheidung: Für besonders sensible Anwendungsfälle lässt sich ein Modell wählen, das komplett innerhalb der eigenen Infrastruktur läuft, ohne dass eine einzige Anfrage sie verlässt.
Betriebsverantwortung
Weil die Standardarchitektur self-hosted ist, betreibt in den meisten Fällen euer eigenes Team die Infrastruktur und wählt/betreibt das Sprachmodell. agentctl verbindet beides zu einem Mitarbeitenden, inklusive Betriebsunterstützung, aber ohne dass eure Daten zwingend durch agentctl-Infrastruktur laufen müssen.
Bereit für den ersten Anwendungsfall?
Wir zeigen es gerne live, am eigenen System, mit den eigenen Daten.