KI-Agenten erstellen: Von ChatGPT bis Enterprise – der komplette Leitfaden
Ein KI-Agent ist ein System das eigenständig Aufgaben ausführt – nicht nur auf Fragen antwortet wie ein Chatbot, sondern aktiv plant, entscheidet und handelt. Ob ihr einen einfachen Agenten in ChatGPT baut oder ein produktionsreifes System das 24/7 in eurem Unternehmen läuft: Dieser Leitfaden zeigt beide Wege, mit konkreten Schritten, echten Beispielen und einer ehrlichen Einschätzung was funktioniert und was nicht.
Die kurze Version: Einen KI-Agenten in ChatGPT oder Copilot erstellen dauert 10 Minuten. Einen Agenten der zuverlässig im Unternehmensalltag arbeitet, dauert 4–6 Wochen. Der Unterschied liegt nicht im Modell, sondern in der Architektur drumherum.
📑 Inhaltsverzeichnis
Was sind KI-Agenten? Der Unterschied zu Chatbots
Ein Chatbot reagiert. Du stellst eine Frage, er gibt eine Antwort. Danach vergisst er alles.
Ein KI-Agent handelt. Er bekommt ein Ziel, zerlegt es in Schritte, führt diese Schritte aus, bewertet die Ergebnisse und passt seinen Ansatz an. Er greift auf Tools zu – Datenbanken, APIs, E-Mail-Systeme – und arbeitet auch dann weiter wenn niemand zuschaut.
Der entscheidende Unterschied: Ein Chatbot braucht ständig Input von euch. Ein Agent braucht ein Ziel und arbeitet selbstständig darauf hin.
Einfaches Beispiel
Ihr fragt ChatGPT "Schreib mir eine Zusammenfassung dieser E-Mail" – das ist ein Chatbot. Ein KI-Agent dagegen prüft selbstständig eingehende E-Mails, erkennt Support-Anfragen, kategorisiert sie nach Dringlichkeit, schreibt einen Antwort-Entwurf und leitet kritische Fälle an einen Mitarbeiter weiter. Ohne dass jemand einen Prompt eingibt.
KI-Agenten erstellen mit ChatGPT: Der schnelle Einstieg
Für den Anfang oder für persönliche Produktivität ist ein Custom GPT in ChatGPT ein guter erster Schritt. So funktioniert es:
Das Gleiche funktioniert mit Microsoft Copilot Studio für Agenten im Microsoft-Ökosystem.
Wo die Grenzen liegen
Ein ChatGPT-Agent ist ein Prototyp, kein Produktivsystem. Konkret:
Keine echte Autonomie
Der Agent wartet immer darauf dass ihr etwas eingebt. Er kann nicht selbstständig im Hintergrund laufen, auf Events reagieren oder Prozesse anstoßen.
Kein Zugriff auf eure Systeme
Er kann nicht in eure Datenbank schauen, keine E-Mails verschicken, keine CRM-Einträge erstellen. Er lebt in seiner ChatGPT-Sandbox.
Keine Zuverlässigkeit
Wenn ChatGPT ein Update bekommt, kann sich das Verhalten eures Agenten über Nacht ändern. Für interne Spielereien kein Problem – für Prozesse die jeden Tag funktionieren müssen, ein Dealbreaker.
Datenschutz
Jedes Dokument das ihr hochladet liegt auf OpenAI-Servern. Für Unternehmen mit sensiblen Daten ist das ein Problem. Mehr dazu in unserem Leitfaden zu KI und DSGVO.
ChatGPT-Agenten sind hervorragend um zu verstehen was möglich ist und um erste Use Cases zu testen. Aber sie sind die Modellwohnung, nicht das Haus in dem ihr wohnen wollt.
KI-Agenten für Unternehmen: Was es wirklich braucht
Wenn ein Agent zuverlässig im Unternehmensalltag arbeiten soll – ob in Finance, HR, Support oder Marketing – braucht er mehr als ein gutes LLM. Er braucht eine Architektur die drei Probleme löst:
Problem 1: Zuverlässigkeit
Der Agent muss auch dann weiterarbeiten wenn mitten im Prozess etwas schiefgeht. Ein API-Timeout, ein unerwartetes Datenformat, ein Netzwerkfehler. In ChatGPT bedeutet das: Prozess abgebrochen, von vorne anfangen. In einem Produktivsystem muss der Agent beim letzten erfolgreichen Schritt weitermachen.
Problem 2: Datenzugriff
Der Agent braucht Zugang zu euren echten Daten – Rechnungen, CRM-Einträge, Support-Tickets, Produktkataloge. Und zwar strukturiert, aktuell und sauber. Ohne saubere Daten macht der klügste Agent dumme Dinge.
Problem 3: Kontrolle
Ihr müsst nachvollziehen können was der Agent tut, warum er Entscheidungen trifft und wie ihr ihn stoppen könnt wenn etwas schiefgeht. "Human in the Loop" ist kein Nice-to-have, sondern Pflicht – besonders nach DSGVO und EU AI Act.
Unsere Architektur: Wie wir KI-Agenten bauen
Wir haben in der Praxis eine Drei-Schichten-Architektur entwickelt die diese Probleme löst. Jede Schicht hat eine klare Aufgabe.
⚙️ Schicht 1: Agent-Runtime – Go + Temporal
Die Agenten selbst sind in Go geschrieben und laufen auf Temporal als Orchestrierungsplattform. Warum Go? Es kompiliert zu einem einzigen Binary – keine node_modules, keine Runtime-Dependencies, keine Überraschungen. Was nicht kompiliert, läuft nicht. Für Software die 24/7 unbeaufsichtigt beim Kunden läuft, ist das entscheidend. Warum Temporal? Durable Execution. Wenn ein Agent mitten im Workflow crasht – API-Timeout, Server-Neustart, was auch immer – startet er beim letzten Checkpoint neu, nicht von vorne. Dazu eingebaute Retries mit exponential Backoff und eine Web-UI die als Monitoring-Dashboard dient.
🔄 Schicht 2: Statische Workflows – n8n
Nicht alles braucht einen intelligenten Agenten. Tägliche Report-Mails, Daten-Syncs zwischen Systemen, Kill-Switches zum Stoppen von Kampagnen – das sind feste Abläufe ohne Entscheidungslogik. Dafür nutzen wir n8n: visuell editierbar, der Kunde kann selbst kleine Anpassungen machen, kein LLM nötig. Die Faustregel: Wenn ein Workflow jeden Tag exakt gleich abläuft → n8n. Wenn ein Prozess denken, entscheiden oder adaptiv reagieren muss → Go + Temporal.
🗄️ Schicht 3: State Layer – PostgreSQL + pgvector
Alle Daten liegen in PostgreSQL mit der pgvector-Extension. Eine Datenbank, zwei Zwecke: PostgreSQL speichert operative Daten (Scraping-Ergebnisse, Agent-Outputs, Kampagnen-Metriken). pgvector speichert Dokumente als Embeddings für RAG – damit Agenten auf euer gesamtes Firmenwissen zugreifen können. Agenten kommunizieren nicht direkt miteinander. Ergebnisse werden in die Datenbank geschrieben, der nächste Agent liest sie dort. Sauber entkoppelt, nachvollziehbar und debuggbar.
🧠 Die LLM-Schicht: Gemma 4.0 + Claude API
Das Sprachmodell ist bewusst austauschbar. Unser Default ist Gemma 4.0 – läuft lokal oder auf EU-Servern, DSGVO-konform, keine Daten verlassen eure Umgebung. Für die Masse der Aufgaben (Analyse, Scoring, Zusammenfassungen, Content-Generierung) ist das mehr als ausreichend. Für komplexe Reasoning-Tasks – wo Gemma an seine Grenzen stößt – nutzen wir Claude API als Fallback. Mit einer harten Regel: Keine personenbezogenen Daten über die API, nie. Die Strategie: Gemma für die Masse, Claude für die Veredelung. So bleibt 90% der Verarbeitung lokal und DSGVO-konform.
Welche Beispiele gibt es für KI-Agenten im Unternehmensalltag?
KI-Agenten sind keine Zukunftsmusik – sie arbeiten heute schon in konkreten Unternehmensprozessen. Hier sind reale Einsatzfelder:
Rechnungsprüfung
Der Agent prüft eingehende Rechnungen automatisch: Stimmen die Beträge mit der Bestellung überein? Gibt es Abweichungen? Fehlen Positionen? Er gleicht Rechnungen gegen offene Bestellungen ab, markiert Unstimmigkeiten und erstellt einen täglichen Report. Erst wenn etwas auffällt, wird ein Mensch einbezogen.
RAG-basierter Support-Agent
Der Agent hat Zugriff auf eure gesamte Produktdokumentation, FAQs und bisherige Support-Tickets. Kommt eine Kundenanfrage rein, durchsucht er die Wissensbasis, generiert einen Antwort-Entwurf und ordnet das Ticket nach Segment und Dringlichkeit ein. Standardanfragen beantwortet er direkt, komplexe Fälle leitet er mit Kontext an den richtigen Mitarbeiter weiter.
A/B Testing Agent
Der Agent überwacht laufende Ad-Kampagnen, analysiert alle vier Stunden die Performance, schaltet underperformende Varianten ab und lässt nur die Gewinner weiterlaufen. A/B Testing autonom, rund um die Uhr – ohne dass jemand morgens ins Ads-Dashboard schauen muss.
Kandidaten-Scoring
Der Agent scrapt LinkedIn-Profile von Bewerbern, gleicht sie gegen vordefinierte KPIs ab, prüft Social-Media-Kanäle auf Cultural Fit und erstellt ein Ranking der vielversprechendsten Kandidaten. Inklusive personalisiertem Ansprache-Vorschlag.
Access Review Agent
Der Agent crawlt regelmäßig Logs und SSO-Daten, identifiziert verwaiste Accounts und überprivilegierte Zugriffsrechte, erstellt Reports mit Handlungsempfehlungen und alarmiert sofort bei Zugriffen von Ex-Mitarbeitern.
Der Build-Prozess: 4–6 Wochen pro Agent
Ein produktionsreifer Agent entsteht nicht über Nacht. So sieht der realistische Zeitplan aus:
Infrastruktur
Temporal aufsetzen, PostgreSQL-Schema definieren, Langfuse für LLM-Monitoring installieren, API-Keys einrichten.
Code + Tests
Die Go-Packages für den Agenten schreiben, Unit Tests laufen lassen, Basis-Logik implementieren.
Prompt-Iteration
Das ist der aufwändigste Teil. 20–30 Durchläufe: Prompt anpassen, Agent laufen lassen, Output bewerten, Prompt wieder anpassen. Hier entscheidet sich ob der Agent gute oder mittelmäßige Ergebnisse liefert.
Stabilisierung
Eine Woche ohne Eingriff laufen lassen. Edge Cases finden und fixen, Monitoring prüfen, Fehlerbehandlung härten.
Danach läuft der Agent. Aber: Wartung ist Pflicht. APIs ändern sich, Datenformate entwickeln sich weiter, LLMs bekommen Updates. Plant alle 2–4 Wochen einen Wartungszyklus ein.
Wie viel kostet ein KI-Agent?
Die Kosten teilen sich in drei Bereiche:
💰 Infrastruktur (monatlich, pro Kunde)
Self-Hosted auf einem VPS: ca. 50€/Monat für die gesamte Infrastruktur (Temporal, PostgreSQL, Langfuse, n8n). Bei Managed Services (Cloud-Varianten) ca. 220€/Monat. In beiden Fällen ein Bruchteil eines Mitarbeitergehalts.
📊 API-Kosten (variabel)
Gemma 4.0 läuft lokal – nur Compute-Kosten, die bereits in der Infrastruktur enthalten sind. Claude API als Fallback: ca. 20–50€/Monat je nach Nutzung. Dazu kommen eventuelle Kosten für Scraping-Tools, CRM-Integrationen oder spezialisierte Services je nach Use Case.
🛠️ Entwicklung (einmalig)
Die Entwicklung eines Agenten dauert 4–6 Wochen. Die Kosten hängen davon ab ob ihr intern baut, einen Freelancer beauftragt oder einen spezialisierten Dienstleister. Für Enterprise-Implementierungen mit Datenbereinigung, mehreren Agenten und Team-Schulung rechnet mit einem Projekt über 3+ Monate.
Sind KI-Agenten legal?
Ja – aber nicht ohne Regeln. Zwei Regelwerke sind relevant:
DSGVO
Wenn der Agent personenbezogene Daten verarbeitet (Kundendaten, Mitarbeiterdaten, E-Mail-Adressen), greifen alle DSGVO-Anforderungen: Rechtsgrundlage, Datenschutz-Folgenabschätzung, Informationspflichten, Verarbeitungsverzeichnis. Besonders wichtig: Wenn der Agent mit Kunden interagiert, müssen diese wissen dass sie mit einer KI sprechen.
EU AI Act
Je nach Einsatzbereich fällt der Agent in unterschiedliche Risikoklassen. KI im HR (Bewerberbewertung) oder in der Kreditvergabe gilt als Hochrisiko und unterliegt strengen Dokumentations- und Transparenzpflichten. Ein Marketing-Agent für A/B Testing fällt in eine niedrigere Kategorie.
Unser Ansatz: Wir setzen auf lokale LLMs (Gemma 4.0) als Default, damit keine personenbezogenen Daten an US-Server fließen. Jeder Agent wird mit einem Architektur-Review geprüft bevor er live geht. Und mit Langfuse ist jeder LLM-Call protokolliert – wer hat wann welche Daten verarbeitet.
Ausführlich behandeln wir das in unserem DSGVO-Leitfaden für KI.
Bevor der erste Agent läuft: Daten aufräumen
Das ist der Schritt den die meisten überspringen – und der Hauptgrund warum KI-Projekte scheitern. Die besten Agenten machen dumme Dinge wenn sie auf schlechten Daten arbeiten.
Unser Prozess in fünf Phasen:
Data Audit
Alle Systeme durchgehen. Wo liegen die Daten, wie fließen sie, wer hat Zugang? Schatten-KI identifizieren. Am Ende steht eine Datenfluss-Karte.
Konsolidierung
Quellsysteme verbinden und alles in eine zentrale Datenbank ziehen – mit Airbyte für laufende Syncs. HubSpot-Deals, Shopify-Orders, Meta-Kampagnen – alles an einem Ort.
Bereinigung
Rohdaten transformieren mit dbt: Deduplizierung, Normalisierung, Beziehungen herstellen. "Firma GmbH" und "Firma GmbH & Co. KG" werden zur selben Entity. SQL-Modelle die automatisch laufen, versioniert in Git.
Anreicherung
Kundendokumente (PDFs, Handbücher, FAQs) mit unstructured.io parsen und als Embeddings in pgvector speichern. Damit hat der RAG-Layer Zugriff auf euer gesamtes Firmenwissen.
Agenten
Erst jetzt werden Agenten gebaut. Sie haben saubere, strukturierte, vernetzte Daten. Der Support-Agent sucht in der echten Produktdatenbank. Der Finance-Agent kennt die echten Rechnungsdaten. Alles andere wäre ein teurer Chatbot der halluziniert.
Agent oder Workflow? Die Entscheidungsmatrix
Nicht jede Automatisierung braucht einen KI-Agenten. Ein häufiger Fehler ist es, intelligente Agenten für Aufgaben zu bauen die ein simpler Workflow besser löst. So unterscheidet ihr:
🤖 Das braucht einen Agenten
- Die Aufgabe erfordert LLM-Calls
- Es müssen Entscheidungen getroffen werden
- Der Prozess muss adaptiv auf Ergebnisse reagieren
- Es gibt Loops mit Abbruchbedingungen
Beispiele: Ad-Research mit Analyse, A/B Testing mit Performance-Optimierung, Support-Tickets beantworten, LinkedIn-Kommentare personalisiert schreiben.
⚡ Das reicht ein Workflow
- Der Ablauf ist jeden Tag identisch
- Kein LLM nötig
- Kein adaptives Verhalten
- Der Kunde soll es selbst anpassen können
Beispiele: Täglicher Report per Mail, Daten-Sync zwischen Systemen, Kill-Switch zum Stoppen einer Kampagne, Webhooks empfangen und weiterleiten.
Faustregel
Muss es denken? → Agent. Läuft es immer gleich? → Workflow. Ein Agent für eine Aufgabe die ein Workflow lösen kann ist Overengineering. Ein Workflow für eine Aufgabe die Intelligenz braucht ist Underengineering.
Häufige Fragen (FAQ)
Kann man mit ChatGPT einen KI-Agenten erstellen?
Was ist der Unterschied zwischen KI-Agent und Chatbot?
Welche KI-Agenten gibt es?
Wie viel kostet ein KI-Agent?
Kann ich KI-Agenten erstellen ohne Programmierkenntnisse?
Welche Beispiele gibt es für KI-Agenten im Mittelstand?
Nächster Schritt: Wo anfangen?
Der schnellste Weg ist nicht der beste Agent – sondern der richtige. In einem kostenlosen Erstgespräch identifizieren wir gemeinsam welcher Prozess in eurem Unternehmen den größten Hebel hat und wie die technische Umsetzung aussehen würde.
Dieser Artikel wird regelmäßig aktualisiert um neue Tools, Modelle und Best Practices zu berücksichtigen. Letztes Update: April 2026.