Agentic AI & LLM-Einführung für regulierte Organisationen
Agentic AI bezeichnet KI-Systeme, die auf Basis eines großen Sprachmodells (LLM) ein Ziel in Teilschritte zerlegen, selbstständig Werkzeuge wie Suche, Datenbanken oder Fachanwendungen aufrufen und Zwischenergebnisse prüfen, bis die Aufgabe erledigt ist. SIFAMO, eine KI-Beratung aus Deutschland, führt LLMs und KI-Agenten in Versicherungen, Banken, öffentlicher Verwaltung und Gesundheitswesen ein — mit RAG auf eigenen Daten, Evaluation, Leitplanken, menschlicher Freigabe und einem Audit-Trail für jeden Werkzeugaufruf.
Wir verstehen uns als KI-Architekt für regulierte Branchen — vom AI-Act-Paragrafen zum produktiven System. Wir bauen die Agenten und die Kontrollen, nicht nur das Konzept. Die Strategie dahinter beschreibt unsere KI-Beratung, die regulatorische Tiefe unsere EU AI Act Beratung.
Agentic AI, Chatbot oder RPA: worin der Unterschied liegt
Die drei Begriffe werden oft vermischt. Für Architektur, Risiko und Governance ist die Unterscheidung entscheidend: Ein RPA-Bot klickt nach Regeln, ein Chatbot antwortet, ein KI-Agent handelt nach einem Ziel.
Mit dem Schritt vom Chatbot zum Agenten verschiebt sich das Risiko: von der falschen Antwort zur falschen Handlung. Die entscheidende Frage ist deshalb nicht das Etikett, sondern: Was darf das System in welchen Systemen verändern, ohne dass ein Mensch zustimmt? Daran bemessen wir Architektur, Freigaben und Protokollierung.
In der Praxis kombinieren sich die drei Ansätze. Ein Agent kann einen bestehenden RPA-Bot als Werkzeug nutzen, ein Chat-Interface kann die Oberfläche eines Agenten sein.
RPA (Robotic Process Automation)
RPA folgt fest programmierten Regeln und Klickpfaden in bestehenden Oberflächen. Das ist deterministisch und gut prüfbar, scheitert aber an unstrukturierten Eingaben und bricht, sobald sich eine Maske ändert.
Chatbot und KI-Assistent
Ein Chatbot — klassisch oder LLM-basiert — beantwortet Fragen im Dialog. Mit RAG greift er auf Ihr Unternehmenswissen zu, verändert aber nichts in Ihren Systemen. Das Risiko liegt in falschen oder unbelegten Antworten.
KI-Agent
Ein KI-Agent erhält ein Ziel statt einer Frage. Er plant Schritte, ruft Werkzeuge auf, liest die Ergebnisse, korrigiert sich und kann — wenn man ihn lässt — in Fachanwendungen schreiben.
- RPA passt, wenn Regeln stabil sind und sich Oberflächen selten ändern.
- Ein Assistent mit RAG passt, wenn Mitarbeitende oder Kunden belegte Antworten aus Wissen brauchen, aber nichts verändert werden soll.
- Ein KI-Agent passt, wenn unstrukturierte Informationen, wechselnde Wege und mehrere Systeme zusammenkommen — etwa bei Posteingängen, Recherchen, Fallvorbereitung oder Softwareentwicklung — und die Freigaben sauber definiert sind.
LLM-Einführung Schritt für Schritt: vom Use Case bis zum Betrieb
Eine LLM-Einführung scheitert selten am Modell, sondern an Daten, fehlender Messbarkeit und unklaren Zuständigkeiten. Unser Vorgehen hat deshalb acht Schritte, die aufeinander aufbauen.
Use Cases auswählen
Wir bewerten Kandidaten nach Fallvolumen, Datenlage, messbarem Nutzen, Fehlertoleranz und regulatorischer Einordnung. Am Anfang stehen meist interne, gut prüfbare Aufgaben — Recherche, Entwürfe, Klassifikation von Eingängen —, bevor ein Agent mit Außenwirkung entsteht. Die übergreifende Priorisierung im Portfolio gehört in die KI-Strategie.
Daten aufbereiten und RAG aufbauen
Retrieval-Augmented Generation (RAG) lässt das Modell aus Ihren freigegebenen Dokumenten antworten, mit Quellenangabe. Entscheidend sind saubere Quellen, sinnvolle Zerlegung, Metadaten, Aktualität und eine Berechtigungsprüfung vor dem Retrieval: Wer ein Dokument nicht sehen darf, bekommt auch keine Antwort daraus. Wie das produktiv aussieht, zeigt unsere RAG-basierte Wissensplattform.
Modell und Hosting wählen
Ob Modell per API mit EU-Datenresidenz, EU-gehostetes Modell oder Open-Weight-Modell im eigenen Rechenzentrum: Die Wahl folgt der Datenklassifizierung, nicht der Benchmark-Tabelle. Wir bauen modellagnostisch, damit ein Modellwechsel eine Konfigurationsfrage bleibt und kein Neubau wird.
Evaluation-Harness aufsetzen
Vor dem ersten Pilotnutzer steht ein Testsatz aus realen, anonymisierten Fällen mit erwarteten Ergebnissen. Gemessen werden Faktentreue, Quellenabdeckung, Formatfehler und korrekte Ablehnungen. Jede Änderung an Prompt, Modell oder Datenbasis läuft gegen diesen Satz — wie ein Regressionstest in der Softwareentwicklung. Eine automatische Bewertung durch ein zweites Modell setzen wir nur ein, wenn sie gegen menschliche Bewertungen kalibriert ist.
Leitplanken einziehen
Guardrails prüfen Eingaben und Ausgaben: Maskierung personenbezogener Daten, Abwehr von Prompt Injection — auch indirekt über Dokumente und E-Mails —, Schema-Validierung strukturierter Ausgaben und klare Themengrenzen. Leitplanken sind Code außerhalb des Modells; eine Anweisung im Prompt ist keine Sicherheitsgrenze.
Human-in-the-Loop gestalten
Wir legen fest, welche Schritte eine menschliche Freigabe brauchen, und gestalten die Prüfung so, dass sie tatsächlich prüft: mit Quellen, Begründung und einer Gegenüberstellung der vorgeschlagenen Änderung. Sonst wird die Freigabe zum Durchwinken — ein Effekt, den der AI Act in Art. 14 als „Automatisierungsbias“ benennt.
Rollout und Change begleiten
Wir starten mit einer Pilotgruppe, messen Nutzung und Qualität und erweitern schrittweise. Mitarbeitende lernen, was das System kann und wo seine Grenzen liegen. Das ist auch eine rechtliche Anforderung: Nach Art. 4 AI Act in der seit 27. Juli 2026 geltenden Fassung ergreifen Anbieter und Betreiber Maßnahmen zur Förderung der KI-Kompetenz ihres Personals.
Betrieb, Monitoring und Kosten steuern
Im Betrieb protokollieren wir jeden Modell- und Werkzeugaufruf mit Prompt- und Modellversion, prüfen die Qualität laufend an Stichproben und weisen Kosten pro Vorgang aus statt pro Monat. Budgets je Use Case, Caching und das Routing einfacher Schritte auf kleinere Modelle halten die Kosten planbar. Ändert ein Anbieter sein Modell, läuft zuerst die Evaluation.
Generative KI im Unternehmen: API, EU-Hosting oder Open-Weight?
Datensouveränität ist keine Ja-Nein-Frage, sondern eine Abwägung pro Datenklasse. Drei Betriebsmodelle stehen zur Wahl, und viele Organisationen kombinieren sie.
Vorweg die häufigste Frage: Ein eigenes Basismodell zu trainieren, ist für fast keine Organisation wirtschaftlich. Der Hebel liegt in RAG, guten Prompts und Evaluation. Fine-Tuning lohnt sich gezielt, wenn Format, Fachsprache oder Klassifikationsaufgaben dauerhaft konsistent sein müssen. Wir bauen die Architektur so, dass Sie pro Use Case das passende Modell nutzen und später wechseln können.
Proprietäre Modelle per API mit EU-Datenresidenz
Leistungsstarke Modelle, schnell verfügbar, kein eigener GPU-Betrieb. Zu prüfen sind Verarbeitungsort, Auftragsverarbeitung, der Ausschluss der Trainingsnutzung Ihrer Daten und der Umgang des Anbieters mit Modellwechseln. Geeignet für Daten, deren Klassifizierung eine externe Verarbeitung zulässt.
EU-gehostete Modelle bei europäischen Anbietern
Modelle bei Cloud- oder Hosting-Anbietern mit Sitz und Rechenzentren in der EU. Das vereinfacht Datenschutz- und Souveränitätsfragen, verlagert die Abhängigkeit aber, statt sie aufzulösen. Für Finanzunternehmen bleibt auch dieser Anbieter ein IKT-Drittdienstleister im Sinne von DORA.
Open-Weight-Modelle on-premises oder in der Private Cloud
Volle Kontrolle über Daten, Versionen und Updates; kein Anbieter ändert das Modell ungefragt. Dafür liegen GPU-Kapazität, Sicherheit, Patching und Evaluation in Ihrer Verantwortung. Sinnvoll für besonders schutzbedürftige Daten — etwa Sozial- und Gesundheitsdaten — und für planbare Last.
Governance für KI-Agenten: sieben Kontrollen, die im Code stecken
Ein Agent ist so sicher wie die Rechte, die er hat. Governance für Agentic AI ist deshalb vor allem Architektur — eine Richtlinie allein hält keinen Werkzeugaufruf auf.
Die folgenden Kontrollen decken sich mit dem, was der AI Act von Hochrisiko-Systemen verlangt: automatische Protokollierung von Ereignissen über die gesamte Lebensdauer (Art. 12), wirksame menschliche Aufsicht einschließlich der Möglichkeit, Ergebnisse zu übersteuern und das System über ein „Stopp“-Verfahren anzuhalten (Art. 14), sowie Robustheit gegen KI-spezifische Angriffe wie Data Poisoning oder manipulierte Eingaben (Art. 15). Wer sie von Anfang an einbaut, muss bei einer späteren Hochrisiko-Einstufung deutlich weniger nachrüsten.
- Least Privilege: Jeder Agent erhält eine eigene technische Identität mit genau den Rechten, die sein Use Case braucht. Lesend vor schreibend, kein geteiltes Servicekonto mit Administratorrechten.
- Tool-Allowlist: Der Agent ruft nur ausdrücklich freigegebene Werkzeuge mit definierten Parametern auf. Jede neue Fähigkeit ist eine Änderung mit Review, kein Prompt-Update.
- Budgets und Rate Limits: Obergrenzen für Schritte, Token, Kosten und Aufrufe pro Zeiteinheit beenden Endlosschleifen und begrenzen den Schaden fehlerhafter Läufe.
- Freigabe-Gates: Irreversible Aktionen und Aktionen mit Außenwirkung — Zahlungen, Bescheide, Kundenkommunikation, Löschungen — führt der Agent erst nach menschlicher Freigabe aus.
- Audit-Trail: Jeder Werkzeugaufruf wird mit Eingabe, Ergebnis, Modell- und Prompt-Version, Zeitstempel und auslösendem Vorgang protokolliert. Das ist die Grundlage für Revision, Fehleranalyse und Nachweise gegenüber der Aufsicht.
- Kill Switch: Ein Agent lässt sich zentral und sofort stoppen, einzelne Werkzeuge lassen sich gezielt sperren. Für jeden Agenten ist festgelegt, wie der Prozess dann manuell weiterläuft.
- Red Teaming: Vor dem Go-live und nach wesentlichen Änderungen greifen wir den Agenten gezielt an — mit Prompt Injection über Dokumente, Versuchen des Datenabflusses, Rechteausweitung und dem Missbrauch von Werkzeugen.
KI-Agenten und der EU AI Act (Stand: Oktober 2026)
Der AI Act kennt keine eigene Kategorie für KI-Agenten. Welche Pflichten gelten, hängt davon ab, was der Agent tut und welche Rolle Sie dabei haben.
Der AI Act Service Desk der Europäischen Kommission stellt klar: KI-Agenten sind keine eigene Kategorie. Die Definitionen des KI-Systems (Art. 3 Nr. 1) und des KI-Modells mit allgemeinem Verwendungszweck (Art. 3 Nr. 63) reichen aus, die Regeln für KI-Systeme und GPAI-Modelle gelten auch für Agenten. Ein Agent enthält typischerweise ein GPAI-Modell und ist selbst ein KI-System. Eigene Leitlinien der Kommission oder des AI Office zu Agenten gibt es nach aktuellem Stand nicht; die Kommission bezeichnet ihre Einschätzung als vorläufig.
Die Einstufung folgt dem Einsatzzweck. Ein Agent, der interne Richtlinien durchsucht, ist in der Regel kein Hochrisiko-System. Derselbe Agent wird es, wenn er Bewerbungen filtert (Anhang III Nr. 4a), für eine Behörde den Anspruch auf grundlegende öffentliche Unterstützungsleistungen prüft (Nr. 5a) oder die Risikobewertung und Preisgestaltung für natürliche Personen in der Lebens- und Krankenversicherung übernimmt (Nr. 5c). Die Hochrisiko-Pflichten gelten nach der Verordnung (EU) 2026/1744 für Anhang-III-Systeme ab dem 2. Dezember 2027, für Anhang-I-Produkte ab dem 2. August 2028. Finale Leitlinien der Kommission zur Hochrisiko-Klassifizierung liegen noch nicht vor, ein Entwurf wurde am 19. Mai 2026 veröffentlicht. Wir empfehlen, ein Agentensystem als Ganzes zu bewerten — mit allen Werkzeugen, auf die es zugreifen kann.
Welche Rolle Sie einnehmen — Anbieter oder Betreiber —, bestimmt Ihre Pflichten; das klären wir pro System. Den Verordnungstext finden Sie bei EUR-Lex, Risikoklassifizierung, Dokumentation und Aufsicht im Detail in unserer EU AI Act Beratung. SIFAMO übernimmt die technisch-organisatorische Umsetzung und arbeitet, wo nötig, mit Ihrer Rechtsberatung zusammen. Für Agenten sind vor allem diese Punkte relevant:
- GPAI-Pflichten: Die Pflichten für Anbieter von KI-Modellen mit allgemeinem Verwendungszweck gelten seit dem 2. August 2025 und liegen beim Modellanbieter. Wer einen Agenten auf einem solchen Modell betreibt, hat eigene Pflichten.
- KI-Kompetenz (Art. 4): Anbieter und Betreiber ergreifen Maßnahmen zur Förderung der KI-Kompetenz ihres Personals — in der seit 27. Juli 2026 geltenden Fassung, in ursprünglicher Form bereits seit 2. Februar 2025.
- Verbote (Art. 5): Für Agenten sind laut Service Desk besonders die Verbote manipulativer Techniken und der Ausnutzung von Schwächen relevant (Art. 5 Abs. 1 lit. a und b). Sie gelten seit dem 2. Februar 2025.
- Transparenz (Art. 50): Seit dem 2. August 2026 müssen KI-Systeme, die mit Menschen interagieren, so gestaltet sein, dass Menschen erfahren, dass sie es mit einer KI zu tun haben — sofern das nicht offensichtlich ist, spätestens bei der ersten Interaktion. Generierte Inhalte sind maschinenlesbar zu kennzeichnen; für Systeme, die vor dem 2. August 2026 auf dem Markt waren, gilt dafür eine Frist bis 2. Dezember 2026.
- Veröffentlichte Texte (Art. 50 Abs. 4): Wer KI-generierte Texte veröffentlicht, um die Öffentlichkeit über Angelegenheiten von öffentlichem Interesse zu informieren, muss das offenlegen — es sei denn, die Texte wurden von Menschen geprüft und eine Person oder Stelle trägt die inhaltliche Verantwortung. Das ist gerade für die öffentliche Verwaltung relevant.
- Betreiberpflichten bei Hochrisiko (Art. 26): ab 2. Dezember 2027 unter anderem menschliche Aufsicht durch Personen mit der nötigen Kompetenz, Schulung und Befugnis, Überwachung des Betriebs und Aufbewahrung der Protokolle für mindestens sechs Monate.
- Zuständigkeit in Deutschland: Seit Inkrafttreten des KI-MIG am 29. Juli 2026 ist grundsätzlich die Bundesnetzagentur Marktüberwachungsbehörde, für KI-Systeme in direktem Zusammenhang mit einer regulierten Finanztätigkeit die BaFin.
LLM-Einführung bei Versicherern und Banken: DORA mitdenken
Für Versicherer, Banken und andere Finanzunternehmen gilt neben dem AI Act die DORA-Verordnung (EU) 2022/2554. Beide greifen parallel: Der AI Act regelt das KI-System, DORA die digitale operationale Resilienz des Unternehmens.
DORA gilt seit dem 17. Januar 2025; die VAIT hat die BaFin mit Ablauf des 16. Januar 2025 aufgehoben. Die BaFin-Orientierungshilfe zu IKT-Risiken beim Einsatz von KI in Finanzunternehmen vom 18. Dezember 2025 ist ausdrücklich unverbindlich, gibt aber eine klare Orientierung: KI-Systeme werden wie andere IKT-Systeme bewertet, und KI in kritischen oder wichtigen Funktionen braucht weitergehende Kontrollen. Ein Anhang behandelt eigens den Betrieb eines LLM-basierten KI-Assistenten.
Anbieter von LLMs, Modell-APIs und Cloud-Infrastruktur sind nach DORA IKT-Drittdienstleister. Architektonisch beantworten wir das mit einer Abstraktionsschicht zwischen Anwendung und Modell, fest versionierten Modellen, einer eigenen Evaluation für jeden Anbieterwechsel und Protokollen, die IKT-Risikomanagement und AI-Act-Nachweise gleichermaßen bedienen. So bleibt der Exit kein Papierplan. Die wichtigsten DORA-Anforderungen beim Einsatz eines LLM-Anbieters:
- Risikobewertung vor Vertragsschluss (Art. 28 Abs. 4 DORA), die laut BaFin-Orientierungshilfe auch Nachtrainings und Modelländerungen durch den Anbieter einbeziehen sollte.
- Exit-Strategie und Portabilität von Modellen, Trainingsdaten und Code, wenn die KI kritische oder wichtige Funktionen unterstützt (Art. 28 Abs. 7 und 8).
- Einbindung des KI-Anbieters in das Business-Continuity-Management (Art. 11 Abs. 4 und Art. 28).
- Eintrag im Informationsregister (Art. 28 Abs. 3) und vertragliche Mindestinhalte (Art. 30).
- Meldung schwerwiegender IKT-bezogener Vorfälle nach Art. 19 DORA — dazu können laut BaFin auch Vorfälle in KI-Systemen gehören.
Agentic AI und LLMs in der Praxis: wo SIFAMO das umgesetzt hat
Die meisten unserer Referenzen sind anonymisiert. Sie zeigen Systeme im Einsatz, keine Folienstände.
LLM-Einführung bei einer großen gesetzlichen Krankenkasse
Einführung großer Sprachmodelle in einer Organisation, in der Sozial- und Gesundheitsdaten besonders hohe Anforderungen an Hosting, Zugriffskontrolle und Nachvollziehbarkeit stellen.
RAG-System für interne Dokumente bei emeis
Für emeis, ein Unternehmen aus der Pflege, hat SIFAMO ein RAG-System über die internen Dokumente eingeführt. Mitarbeitende finden Dokumente und die Antworten darin schneller, statt Ablagen manuell zu durchsuchen. Das System ist im Einsatz.
RAG-basierte Wissensplattform
Historische Dokumente und Prozessdaten wurden zu einer abfragbaren Wissensbasis für interne KI-Assistenten. Die Berechtigungsprüfung steht vor dem Retrieval, Antworten entstehen nur aus freigegebenen Quellen, Governance liegt über Quellen und Antworten. Zur Case Study
Agentic AI für skalierbare Investment-Plattformen
Auf einer hochverfügbaren Depot- und Trading-Plattform geben Agenten personalisierte Empfehlungen — autonom, aber nur innerhalb fest definierter Leitplanken. Jede Empfehlung durchläuft Compliance und Freigabe und ist auditierbar; abgelehnte Vorschläge fließen in das kontinuierliche Fine-Tuning zurück. Zur Case Study
Multi-Agent-KI für die Softwareentwicklung im Versicherungsumfeld
Aktuell im Einsatz: ein Multi-Agent-System, in dem spezialisierte KI-Agenten in der Softwareentwicklung eines Versicherungsumfelds zusammenarbeiten. Softwareentwicklung ist ein naheliegendes Feld für Agenten, weil Review, Tests und Freigaben dort bereits etablierte Kontrollpunkte sind.
LLM-Beratung mit SIFAMO: so arbeiten wir zusammen
Wir begleiten eine LLM-Einführung von der ersten Bewertung bis zum Betrieb — oder steigen dort ein, wo Ihr Projekt gerade steht.
SIFAMO ist eine KI-Beratung mit Sitz in Berlin, Büro in Frankfurt am Main und Präsenz in den Vereinigten Arabischen Emiraten und Katar. Gründer und CEO ist Umair Zaffar, KI-Experte und IT-Produktarchitekt mit mehr als 15 Jahren IT-Erfahrung, überwiegend für die öffentliche Hand. Für Termine vor Ort im Rhein-Main-Gebiet siehe KI-Beratung Frankfurt.
Wir beraten nicht nur, wir bauen: Mit SKILLDEX entwickelt SIFAMO ein eigenes KI-Produkt, das Fähigkeiten aus Briefings extrahiert und passende Personen in Sekunden findet. Auch intern arbeitet SIFAMO mit eigenen KI-Systemen: KAITO gleicht Projektanfragen selbstständig mit den Beraterprofilen ab und schlägt Besetzungen vor, Slyvar ist das KI-gestützte ERP-System des Hauses. Für seine Forschung und Entwicklung trägt SIFAMO das BSFZ-Siegel. Weitere Projekte finden Sie unter Case Studies, darunter die KI-gestützte Schaden- und Antragsplattform aus der Versicherung.
Use-Case-Bewertung
Gemeinsam mit Fachbereich, IT und Compliance bewerten wir Kandidaten nach Nutzen, Machbarkeit, Datenlage und AI-Act-Einordnung. Ergebnis ist eine priorisierte Liste mit klarer Empfehlung: Agent, RAG-Assistent oder klassische Automatisierung.
Pilot mit Evaluation
Wir bauen den ersten Use Case gegen einen definierten Testsatz und mit echten Nutzerinnen und Nutzern. Am Ende steht eine messbare Entscheidung über den Rollout.
Umsetzung und Integration
RAG-Pipeline, Agenten-Orchestrierung, Guardrails, Freigabe-Workflows und Audit-Trail — integriert in Ihre Fachanwendungen sowie Ihre Identitäts- und Berechtigungssysteme.
Betrieb und Übergabe
Monitoring, Kostensteuerung, Runbooks und Befähigung Ihres Teams, damit Sie das System selbst weiterentwickeln können. Alle Leistungsbausteine finden Sie unter Leistungen.
Wer bei SIFAMO dahintersteht
Häufige Fragen
- Was ist der Unterschied zwischen Agentic AI und einem Chatbot?
- Ein Chatbot beantwortet Fragen im Dialog und verändert nichts in Ihren Systemen. Ein KI-Agent erhält ein Ziel, plant die Schritte selbst und ruft dafür Werkzeuge wie Datenbanken, Schnittstellen oder Fachanwendungen auf. Damit verschiebt sich das Risiko von der falschen Antwort zur falschen Handlung — deshalb brauchen Agenten begrenzte Rechte, Freigabe-Gates und einen lückenlosen Audit-Trail.
- Wie lange dauert eine LLM-Einführung?
- Für einen klar umrissenen Use Case planen wir einen belastbaren Pilot in der Regel mit rund 90 Tagen, einschließlich Datenaufbereitung und Evaluation. Der produktive Rollout mit Integration in Fachanwendungen, Freigabeprozessen und Betrieb braucht meist mehrere Monate. Die größten Zeittreiber sind selten das Modell, sondern Datenzugang, Berechtigungen und die Abstimmung mit Datenschutz, Informationssicherheit und Betriebsrat.
- Können wir LLMs datenschutzkonform in der EU betreiben?
- Ja, dafür gibt es drei Wege: proprietäre Modelle per API mit EU-Datenresidenz, Modelle bei EU-Hosting-Anbietern und Open-Weight-Modelle im eigenen Rechenzentrum. Welcher Weg passt, hängt von der Klassifizierung der Daten ab — für Sozial- oder Gesundheitsdaten fällt die Wahl oft anders aus als für interne Richtlinien. Entscheidend sind außerdem Verträge zur Auftragsverarbeitung, der Ausschluss der Trainingsnutzung Ihrer Daten und eine Architektur, die personenbezogene Daten vor dem Modellaufruf minimiert.
- Sind KI-Agenten nach dem AI Act Hochrisiko?
- Nicht automatisch. Nach Auskunft des AI Act Service Desks der EU-Kommission sind KI-Agenten keine eigene Kategorie; es gelten die Regeln für KI-Systeme und GPAI-Modelle. Ein Agent wird zum Hochrisiko-System, wenn sein Einsatzzweck unter Anhang III fällt — etwa das Filtern von Bewerbungen oder die Risikobewertung und Preisgestaltung in der Lebens- und Krankenversicherung. Die Hochrisiko-Pflichten für solche Systeme gelten ab dem 2. Dezember 2027.
- Brauchen wir eigene Modelle?
- In aller Regel nicht. Ein eigenes Basismodell zu trainieren, ist für fast keine Organisation wirtschaftlich; der größte Hebel liegt in RAG auf Ihren Daten, guten Prompts und einer sauberen Evaluation. Fine-Tuning lohnt sich gezielt, wenn Format, Fachsprache oder Klassifikation dauerhaft konsistent sein müssen. Open-Weight-Modelle im eigenen Betrieb sind eine Option, wenn Datensouveränität das verlangt.
- Wie verhindern wir, dass ein Agent Fehler macht?
- Ganz verhindern lässt sich das nicht, denn Sprachmodelle arbeiten probabilistisch. Man begrenzt deshalb, was ein Fehler anrichten kann: mit minimalen Rechten, einer Allowlist erlaubter Werkzeuge, Budgets, menschlicher Freigabe vor irreversiblen Aktionen und einem Kill Switch. Eine Evaluation mit realen Testfällen vor jeder Änderung und ein Audit-Trail jedes Werkzeugaufrufs machen Fehler früh sichtbar und nachvollziehbar.
- Ab wann gelten die Transparenzpflichten für KI-Agenten und Chatbots?
- Art. 50 AI Act gilt seit dem 2. August 2026 und wurde durch den Digital Omnibus nicht verschoben. Menschen, die mit einem KI-System interagieren, müssen darüber spätestens bei der ersten Interaktion informiert werden, sofern es nicht offensichtlich ist. Für die maschinenlesbare Kennzeichnung generierter Inhalte haben Systeme, die vor dem 2. August 2026 auf dem Markt waren, eine Übergangsfrist bis zum 2. Dezember 2026.
- Was kostet der laufende Betrieb von KI-Agenten?
- Die laufenden Kosten hängen vor allem vom Volumen, von der Zahl der Modellaufrufe pro Vorgang und vom gewählten Modell ab — ein Agent mit vielen Zwischenschritten verbraucht ein Vielfaches eines einfachen Chat-Aufrufs. Wir machen die Kosten pro Vorgang sichtbar und steuern sie über Budgets je Use Case, Caching und das Routing einfacher Schritte auf kleinere Modelle. So lässt sich vor dem Rollout belastbar abschätzen, was ein Use Case im Betrieb kostet.
Passende Themen
- EU AI Act BeratungRisikoklassifizierung, KI-Kompetenz, Logging und menschliche Aufsicht im Detail — abgestimmt mit BaFin und DORA.
- KI-Beratung & KI-StrategieUse-Case-Portfolio, Priorisierung und Roadmap, bevor der erste Agent gebaut wird.
- Case Study: RAG-basierte WissensplattformInterne KI-Assistenten auf historischem Unternehmenswissen — mit Berechtigungsprüfung vor dem Retrieval.
- SKILLDEXSIFAMOs eigenes KI-Produkt: extrahiert Fähigkeiten aus Briefings und findet passende Personen in Sekunden.
Ihr erster KI-Agent — mit Kontrollen ab Tag eins
Schildern Sie uns Ihren Use Case. Wir sagen Ihnen, ob ein Agent, ein RAG-Assistent oder eine klassische Automatisierung die bessere Lösung ist — und welche Kontrollen der Betrieb unter dem AI Act und, für Finanzunternehmen, unter DORA braucht.
SIFAMO GmbH — Frankfurt am Main · Berlin

