KI-Agenten entwickeln

Aus dem Design wird Software. In zwei bis drei Wochen entsteht ein funktionsfähiger Prototyp mit echten Daten und einer kleinen Pilot-Nutzergruppe. Kein Power-Point-Mockup, kein „das könnten wir bauen“.

Was im Prototyp steckt:

• Modell und API-Anbindung (Anthropic-API, OpenAI-API oder lokale Ollama-Instanz)
• System-Prompt mit den definierten Regeln und Tonfall
• Erste Tool-Anbindungen (1–3 Tools, die für den Hauptfluss kritisch sind)
• Bei Bedarf RAG-Index über die wichtigsten Dokumente
• Ein einfaches Frontend — eigene Web-App, Slack/Teams-Integration oder Open WebUI
• Logging jeder Interaktion für spätere Auswertung

Der Prototyp läuft auf Ihrer Infrastruktur (oder einer übergangsweise von uns gestellten), mit echten anonymisierten Daten — nicht mit Beispiel-Daten aus dem Tutorial. Erst dann zeigt sich, wo die echten Probleme liegen.

Ein KI-Agent, der bei den ersten zehn Anfragen funktioniert, ist noch nicht produktionsreif. Es geht um die Anfrage Nummer 387, bei der etwas Ungewöhnliches passiert — und um die Frage, ob er sich dann sauber verhält.

Was wir systematisch testen:

• Goldener Pfad — typische Anfragen, die täglich vorkommen. Müssen 100% sitzen
• Edge Cases — ungewöhnliche, aber legitime Anfragen. Lernen wir aus Pilot-Logs
• Halluzinationen — wo erfindet der Agent etwas, statt „weiß ich nicht“ zu sagen? Mit RAG-Quellen-Verifikation und niedriger Temperatur reduzieren
• Prompt Injection — kann jemand den Agenten dazu bringen, Anweisungen zu ignorieren oder vertrauliche Daten preiszugeben? Vor allem bei externen Nutzergruppen wichtig
• Akzeptanz im Team — wird der Agent genutzt? Verstehen die Nutzer, wann sie eskalieren sollen? Vertrauen sie den Antworten?
• Performance & Kosten — wie viele Tokens pro Anfrage? Bleibt das im Budget, wenn die Nutzung skaliert?

Aus den Tests entstehen iterative Anpassungen — am Prompt, an den Tool-Berechtigungen, an der Modellwahl, am Eskalationsmechanismus. Erst wenn alle drei Stakeholder-Gruppen (Nutzer, Fachbereich, IT) grünes Licht geben, geht es weiter.

Aus dem Prototyp wird produktive Software. Hier kommt das Setup zum Tragen, das zwischen einem Bastler-Bot und einem unternehmenstauglichen Agenten unterscheidet — besonders bei mehreren Nutzern oder regulierten Branchen.

Multi-User-Frontend (wenn mehrere Mitarbeiter den Agenten nutzen):

• Open WebUI als Frontend — Multi-User-Login, kein Pro-Sitz-Pricing wie bei kommerziellen Chat-Tools
• RBAC — wer welche Agenten/Modelle nutzen darf, ergibt sich aus der Rolle (Vertrieb, Buchhaltung, Geschäftsführung)
• Geteilte Prompt-Templates — Vertriebs-Team kann auf vorgefertigte System-Prompts zugreifen, ohne sie selbst zu pflegen
• Audit-Logs — wer hat wann welchen Prompt geschickt, welche Tools wurden aufgerufen, welche Daten wurden abgerufen? Pflicht für Compliance

Deployment-Optionen:

• Cloud — wenn keine Compliance-Hürden bestehen, schnellster Weg zur Produktion
• Self-Hosted auf eigenem Server — für Compliance-Branchen (Kanzleien, Praxen, Behörden, Banken). Komplett innerhalb der eigenen Infrastruktur
• Hybrid — Frontier-Modell extern für unkritische Aufgaben, lokales Modell intern für sensible Routinen. In der Praxis oft die beste Lösung

Was zum Betrieb dazugehört:

• Monitoring der Antwortqualität — automatische Stichproben mit menschlicher Bewertung
• Kosten-Dashboard — Token-Verbrauch pro Rolle, pro Use Case, pro Monat
• Update-Pfad bei neuen Modell-Versionen — kontrolliert, nicht automatisch
• Eskalations-Workflow — wenn der Agent unsicher ist, übergibt er an einen Menschen mit voller Konversations-Historie
• Schulung der Nutzer — was kann der Agent gut, was nicht, wann sollte man ihm widersprechen?