Ein Assistent, der Wissen findet, ist die halbe Miete. Ein Agent legt das Ticket an, startet den Workflow und trägt das Ergebnis ins System ein - mit klaren Grenzen, Protokoll und Freigaben, wo es darauf ankommt.
Tickets, Terminbuchung, Datenabfragen, Workflow-Starts - der Agent nutzt Ihre bestehenden APIs und Systeme (Zammad, n8n, ERP, CRM).
Erlaubte Aktionen sind explizit definiert, kritische Schritte brauchen menschliche Freigabe, und jede Aktion wird protokolliert - nachvollziehbar per Trace.
Gebaut auf dem offenen Stack (LiteLLM, Langfuse, Ihre APIs), betrieben bei uns, in der EU-Cloud oder auf Ihrer Hardware. Der Agent gehört Ihnen.
Gemeinsames Muster: Anfragen kommen unstrukturiert an, ein Mensch sortiert sie, und der eigentliche Vorgang ist ein immer gleicher Handgriff in einem anderen System.
Auslöser: Eine E-Mail beschreibt ein Problem in eigenen Worten.
Agent: Der Agent klassifiziert, legt das Ticket in Zammad mit passender Kategorie und Priorität an, hängt bekannte Lösungsartikel an und bestätigt den Eingang.
Auslöser: Eine Anfrage nennt Anforderungen quer über mehrere Leistungen.
Agent: Der Agent zieht die passenden Bausteine aus Ihrem Katalog, erzeugt einen Entwurf und legt ihn zur Freigabe vor - versendet wird nie ohne Mensch.
Auslöser: Ein neuer Mitarbeiter oder Kunde soll Zugänge bekommen.
Agent: Der Agent stößt die Provisionierung über bestehende Automatisierung an (n8n, Ansible, API), prüft den Status und meldet Abweichungen statt sie zu übergehen.
Auslöser: Informationen stehen in einem System und fehlen im anderen.
Agent: Der Agent gleicht ab, ergänzt fehlende Felder nach definierten Regeln und markiert Konflikte zur Klärung, statt blind zu überschreiben.
Auslöser: Jemand will ein Gespräch, nennt aber nur grobe Zeitfenster.
Agent: Der Agent gleicht Kalender ab, schlägt Termine vor und bucht nach Bestätigung - inklusive Kontext, worum es geht.
Auslöser: Jede Woche dieselbe Frage an dieselben Daten.
Agent: Der Agent holt die Zahlen über die API, prüft Plausibilität und legt die Auswertung ab - mit Hinweis, wenn Werte aus dem Rahmen fallen.
Kein Modell, das frei im System herumräumt - sondern eine kontrollierte Kette mit definierten Werkzeugen.
Der Agent liest die Anfrage und ordnet sie einer bekannten Aufgabe zu. Passt nichts, fragt er nach oder übergibt an einen Menschen - er improvisiert nicht.
Über RAG oder direkte Abfragen zieht er, was er für die Entscheidung braucht: Kundendaten, Historie, Regelwerk. Berechtigungen gelten wie beim internen Assistenten.
Aus einer festen Liste erlaubter Aktionen wählt er die passende und füllt die Parameter. Was nicht in der Liste steht, existiert für den Agenten nicht.
Bei kritischen Schritten - Geld, Außenwirkung, Löschungen - stoppt der Agent und legt den Vorschlag einem Menschen vor. Die Schwelle definieren Sie.
Die Aktion läuft über Ihre API. Anfrage, Kontext, gewähltes Werkzeug, Parameter und Ergebnis landen mit Trace-ID im Protokoll.
Der Agent meldet das Ergebnis - auch einen Fehlschlag. Stille Fehler sind der teuerste Fehlermodus, deshalb schlagen sie durch.
Die Sorge vor Agenten ist berechtigt. Sie lässt sich mit Architektur beantworten, nicht mit Zuversicht.
| Risiko | Gegenmaßnahme |
|---|---|
| Der Agent führt eine Aktion aus, die niemand wollte | Er kennt nur explizit definierte Werkzeuge. Was nicht implementiert ist, kann er nicht aufrufen - es gibt keinen generischen Systemzugriff. |
| Falsche Parameter, richtige Aktion | Parameter werden gegen ein Schema validiert, bevor die API sie sieht. Ungültige Werte führen zur Rückfrage, nicht zum Versuch. |
| Zu weitreichende Rechte | Der Agent bekommt einen eigenen technischen Account mit minimalen Rechten - nicht die Rechte des Nutzers und keine Administratorrechte. |
| Niemand merkt, was passiert ist | Jede Aktion wird mit Trace-ID, Zeitstempel, Auslöser und Ergebnis protokolliert. Das Protokoll liegt in Ihrem System und ist Teil der Übergabe. |
| Ein Fehler wiederholt sich endlos | Wiederholungen sind begrenzt, Schleifen brechen ab, und der Vorgang landet bei einem Menschen statt in einer Endlosschleife. |
| Prompt Injection über eingehende Inhalte | Inhalte aus E-Mails oder Dokumenten werden als Daten behandelt, nicht als Anweisungen. Werkzeugauswahl und Freigabelogik hängen nicht am Text des Absenders. |
Alles mit API. Diese Systeme binden wir in Projekten an oder betreiben sie selbst:
Zammad, Chatwoot, Mail-Postfächer
n8n, Node-RED, Webhooks, eigene Skripte
ERP und CRM über REST, ERPNext, Odoo
PostgreSQL, APIs, Dateiablagen, Nextcloud
CalDAV, Cal.eu, Mattermost, SMTP
Proxmox, Ansible, Monitoring-APIs
Die drei werden im Marketing durcheinandergeworfen. Der Unterschied ist nicht die Technik, sondern wer den Weg bestimmt - und was passiert, wenn etwas schiefgeht.
| Was es tut | Wer bestimmt den Weg | Was ein Fehler kostet | |
|---|---|---|---|
| Chatbot | Antwortet aus vorhandenen Inhalten. Verändert nichts. | Niemand - es gibt keinen Weg, nur eine Antwort. | Eine falsche Auskunft. Ärgerlich, aber umkehrbar. |
| Workflow | Führt eine Kette von Schritten aus: Ticket anlegen, Mail senden, Datensatz schreiben. | Sie, vorher. Der Ablauf ist fest verdrahtet, das Modell füllt höchstens Felder. | Der Ablauf bricht ab oder läuft mit falschen Werten durch. Reproduzierbar und damit reparierbar. |
| Agent | Entscheidet innerhalb gesetzter Grenzen selbst, welche Werkzeuge er in welcher Reihenfolge benutzt. | Das Modell, zur Laufzeit. Sie setzen die Grenzen, nicht die Route. | Eine falsche Aktion im Zielsystem - und die war nicht vorhergesagt. Deshalb steht hier die Freigabe. |
Die meisten Vorhaben, die als Agent angefragt werden, sind Workflows. Das ist keine schlechte Nachricht: Ein Workflow ist billiger, schneller fertig und leichter zu prüfen. Wir sagen es Ihnen im Erstgespräch, statt den teureren Bau zu verkaufen.
Das ist die Frage, die in Ausschreibungen fehlt und im Betrieb zuerst weh tut. Ein Agent, der handelt, braucht eine Identität im Zielsystem - und davon hängt ab, was ein einzelner Nutzer über ihn auslösen kann.
Der einfache Weg: Der Agent bekommt ein technisches Konto mit allen Rechten, die er je brauchen könnte. Das Problem ist die Vereinigungsmenge - jeder Nutzer kann über den Agenten mittelbar alles auslösen, wozu das Dienstkonto berechtigt ist, auch das, wozu er selbst nicht berechtigt wäre.
Nur vertretbar, wenn der Agent ausschließlich Dinge tut, die ohnehin jeder auslösen darf.
Der Agent handelt im Namen des Benutzers, der ihn angestoßen hat, und erbt dessen Rechte im Zielsystem. Wer selbst kein Ticket in dieser Queue anlegen darf, kann es auch über den Agenten nicht. Das ist aufwendiger, weil das Zielsystem delegierte Identitäten unterstützen muss - und es ist der Normalfall, den wir bauen.
Der Regelfall. Rechte bleiben dort, wo sie gepflegt werden.
Für Aktionen, die niemand persönlich auslösen soll - nächtliche Läufe, Systemwartung - bekommt der Agent ein eigenes, eng geschnittenes Konto pro Aufgabe statt eines allmächtigen.
Für unbeaufsichtigte Läufe. Ein Konto pro Aufgabe, nicht eines für alle.
Protokolliert wird in jedem Fall beides: wer die Aktion ausgelöst hat und unter welcher Identität sie ausgeführt wurde. Ohne diese zwei Angaben ist im Nachhinein nicht zu klären, wer etwas zu verantworten hat.
Als Einordnung, nicht als Rechtsberatung - und mit dem Stand nach dem Digital Omnibus, der seit dem 27. Juli 2026 in Kraft ist.
Seit dem 2. August 2026 gelten die Transparenzpflichten: Wer mit einem KI-System interagiert, muss das erkennen können. Für einen Agenten heißt das nicht nur ein Hinweis im Chat, sondern auch, dass eine von ihm ausgelöste Aktion als solche erkennbar bleibt - eine Mail, die aussieht, als hätte ein Mensch sie geschrieben, ist der Fehler.
Der Digital Omnibus hat die Hochrisiko-Pflichten aus Anhang III auf den 2. Dezember 2027 und die aus Anhang I auf den 2. August 2028 verschoben. Wer einen Agenten in Personalwesen, Kreditvergabe oder ähnlich eingestuften Bereichen plant, gewinnt Zeit - keine Entwarnung.
Aufsicht lässt sich nicht nachrüsten. Sie entsteht daraus, dass kritische Schritte eine Freigabe brauchen und dass jemand benannt ist, der sie erteilt. Das gehört in die Architektur, nicht in eine Richtlinie.
Was nicht mitgeschrieben wurde, lässt sich später nicht nachweisen. Wir protokollieren jede Aktion mit Auslöser, Identität, Werkzeug und Ergebnis - auf Ihrer Infrastruktur, nicht bei einem Anbieter, der die Daten für sich auswertet.
Die meisten Unternehmensagenten fallen nicht unter Hochrisiko, sondern unter Transparenz und Dokumentation. Welche Klasse für Ihren Fall gilt, klären Sie mit Ihrer Rechtsberatung - wir liefern die technische Beschreibung, auf der diese Einschätzung aufsetzt.
Ein Agent ohne Werkzeuge ist ein Chatbot. Die Frage ist, wie die Werkzeuge angebunden werden - und ob Sie diese Anbindung behalten, wenn Sie das Modell wechseln.
MCP ist ein offener Standard, über den ein Modell Werkzeuge und Datenquellen einheitlich anspricht. Der Nutzen für Sie ist nicht die Technik, sondern die Entkopplung: Ein einmal gebauter MCP-Server für Ihr Ticketsystem funktioniert weiter, wenn Sie das Modell darunter austauschen - solange die neue Umgebung MCP spricht, was die gängigen Assistenten und Editoren inzwischen tun.
Wo es schon eine Schnittstelle gibt - Zammad, n8n, ERP, CRM -, nutzen wir sie. Wir bauen keine Parallelwelt und verlangen keinen Umbau Ihrer Systeme, damit ein Agent damit reden kann.
Der Agent bekommt eine benannte Liste erlaubter Werkzeuge mit definierten Parametern - nicht einen Datenbankzugang und die Hoffnung, dass er sich benimmt. Was nicht im Katalog steht, existiert für ihn nicht.
Jeder Lauf wird als Trace aufgezeichnet: welche Werkzeuge in welcher Reihenfolge, mit welchen Parametern, mit welchem Ergebnis. Das ist die Grundlage, um einen Fehlerfall zu rekonstruieren, statt ihn zu vermuten.
Wir bauen lieber ein kleineres System, das trägt, als ein großes, das niemand einschaltet.
Dann ist ein klassischer Workflow (n8n, Skript) billiger, schneller und leichter zu debuggen. Ein Agent lohnt erst, wenn der Eingang unstrukturiert ist.
Wo nur eine Oberfläche existiert, wird jede Automatisierung fragil. Dann ist die ehrliche Reihenfolge: erst Schnittstelle, dann Agent.
Zehn Fälle im Jahr rechtfertigen keine Automatisierung mit Wartungsaufwand - da gewinnt der Mensch.
Wenn niemand sagen kann, welches System die Wahrheit hält, automatisiert ein Agent nur die Verwirrung. Erst aufräumen, dann automatisieren.
Ehrlich vorweg: Nicht jeder Prozess braucht einen Agenten. Wenn ein Formular oder ein fester Workflow reicht, sagen wir das - ein Agent lohnt sich dort, wo Anfragen unstrukturiert ankommen und heute ein Mensch sie einsortiert.
Weitere Anwendungsfälle auf demselben Stack sind deutlich günstiger als der erste - Werkzeuge, Rechte und Protokollierung stehen dann bereits.
Läuft, wo Sie wollen
Antworten auf die wichtigsten Fragen
Ein Chatbot beantwortet Fragen. Ein Agent führt Aktionen aus: Er legt das Ticket an, bucht den Termin, fragt die Datenbank ab oder startet den n8n-Workflow - und meldet das Ergebnis zurück. Die Grenze ziehen definierte Werkzeuge, nicht das Modell.
Durch Architektur statt Hoffnung: Der Agent kann nur explizit freigegebene Aktionen mit validierten Parametern ausführen, kritische Schritte erfordern menschliche Bestätigung, und jede Aktion wird mit Trace-ID protokolliert. Was nicht definiert ist, kann er nicht tun.
Alles mit API: Ticketsysteme wie Zammad, Workflows über n8n, ERP- und CRM-Systeme, Datenbanken, E-Mail und Kalender. Die Anbindung läuft über definierte Werkzeuge mit klaren Berechtigungen je Agent.
Eingehende Inhalte werden als Daten behandelt, nicht als Anweisungen. Der Agent wählt Werkzeuge anhand der definierten Aufgabe, nicht anhand von Text im Dokument - und kritische Aktionen brauchen ohnehin eine Freigabe. Zusätzlich fällt ein solcher Versuch im Protokoll auf.
Ja. Der Stack läuft auf europäischer Infrastruktur oder Ihrer Hardware, mit einem europäischen Modell (Mistral) oder lokalen Modellen. Die Aktionsprotokolle bleiben in Ihrem System und sind Teil der Übergabe.
Wir nennen den Preis nach dem Erstgespräch, weil Aufwand und Umfang stark vom Anwendungsfall abhängen. Sie bekommen eine schriftliche Aufwandsschätzung, bevor Sie sich festlegen. Weitere Anwendungsfälle auf demselben Stack sind deutlich günstiger, weil Werkzeuge, Rechtekonzept und Protokollierung bereits stehen.
Ja, das ist der empfohlene Weg. Interner Assistent und Agent teilen sich denselben Stack (LiteLLM, Langfuse, Wissensbasis) - Werkzeuge und Freigaben kommen als Schicht dazu, ohne Neubau.
Nach der Analyse typisch drei bis sechs Wochen bis zum ersten produktiven Anwendungsfall - abhängig davon, wie zugänglich die Zielsysteme sind. Der Engpass ist fast nie das Modell, sondern die Schnittstelle.
Kein Risiko: Im schlechtesten Fall gehen Sie mit mehr Klarheit über Ihr Projekt heraus als vorher.


„Die Beratung von WZ-IT zu unserer Azure-Migration war schon im Erstgespräch fachlich sehr fundiert und völlig unverbindlich - wir haben eine Menge mitgenommen.“
ml&s spricht über die Integration einer lokalen KI-Lösung. Die übrigen Stimmen betreffen Architektur, Datenhoheit und Betrieb - genau die Reife, ohne die ein KI-Projekt nicht produktiv wird.
Ob konkrete IT-Herausforderung oder einfach eine Idee - wir freuen uns auf den Austausch. In einem kurzen Gespräch prüfen wir gemeinsam, ob und wie Ihr Projekt zu WZ-IT passt.
Timo Wevelsiep & Robin Zins
Geschäftsführer
