Viele IT-Ausschreibungen beginnen ganz klassisch: Anforderungen werden erhoben, abgestimmt und anschließend in einem Lastenheft oder Leistungskatalog festgehalten. Auf dieser Grundlage erstellen die Bieter ihre Angebote.
Im Hearing präsentieren die Anbieter, wie sie die Umsetzung organisieren wollen. Nach meiner Erfahrung präsentieren viele Anbieter ein agiles Umsetzungskonzept: mit Sprints, einem Backlog und den üblichen Scrum-Ritualen. In regelmäßigen Reviews oder sogenannten Show-and-Tell-Sessions präsentieren sie, was im vergangenen Sprint umgesetzt wurde.
Das klingt zunächst nach einer sinnvollen Kombination. Der Auftraggeber erhält einen verbindlichen Preis und einen definierten Leistungsumfang. Der Lieferant kann die Umsetzung trotzdem agil organisieren und regelmäßig Ergebnisse liefern.
In der Praxis entstehen daraus jedoch zwei Paradoxien.
Die erste betrifft das Verhältnis zwischen neuen Wünschen und dem vereinbarten Fixpreis. Die zweite geht noch weiter: Wenn sich der Leistungsumfang während der Umsetzung stark verändert, stellt sich irgendwann die Frage, ob eigentlich noch jener Auftrag umgesetzt wird, für den der Wettbewerb stattgefunden hat.
Paradoxon 1: Je mehr der Auftraggeber lernt, desto stärker gerät der Fixpreis unter Druck
Während einer Show-and-Tell-Session werden Funktionen, Prozesse und Benutzeroberflächen konkret sichtbar. Dabei entstehen fast zwangsläufig neue Erkenntnisse:
„Diese Maske könnten wir einfacher gestalten.“
„Hier benötigen wir noch eine zusätzliche Information.“
„Wenn wir diesen Schritt automatisieren, würde das viel Zeit sparen.“
„Eigentlich brauchen wir noch eine weitere Schnittstelle.“
Genau dafür sind solche Termine gedacht. Der Auftraggeber soll Feedback geben und die Lösung soll dadurch besser werden.
Häufig entsteht jedoch ein Missverständnis.
Der Auftraggeber sagt: „Das könnten wir doch noch ergänzen. Wir arbeiten schließlich agil.“
Der Lieferant nimmt den Wunsch in das Backlog auf. Das Entwicklungsteam setzt ihn möglicherweise bereits im nächsten Sprint um. Erst später stellt sich heraus, dass die Anforderung nicht vom vereinbarten Leistungsumfang umfasst war.
Es folgt eine Nachforderung. Für den Auftraggeber kommt sie überraschend: Aus seiner Sicht hat er lediglich Feedback in einem agilen Projekt gegeben. Für den Lieferanten handelt es sich dagegen um eine zusätzliche Leistung, die im Fixpreis nicht kalkuliert war.
Beide Seiten haben „agil“ unterschiedlich verstanden.
Der Auftraggeber erwartet Flexibilität. Der Lieferant erwartet trotz agiler Arbeitsweise einen begrenzten Leistungsumfang.
Ein Backlog darf sich verändern. Es ist aber kein Wunschzettel mit Preisgarantie.
Soll eine neue Anforderung ohne Mehrkosten umgesetzt werden, müsste beispielsweise eine andere, ungefähr gleichwertige Leistung entfallen. Sollen dagegen alle bisherigen Anforderungen bestehen bleiben, führt der neue Wunsch zu mehr Aufwand, mehr Zeit oder zusätzlichen Kosten.
Agilität hebt diese Zusammenhänge nicht auf.
Paradoxon 2: Der Auftraggeber darf lernen – der Wettbewerb darf sich nicht nachträglich verändern
Selbst wenn sich Auftraggeber und Lieferant über den zusätzlichen Aufwand einigen, bleibt noch eine zweite Frage.
Was passiert, wenn sich der Leistungsumfang während der Entwicklung so stark verändert, dass andere Unternehmen beim ursprünglichen Vergabeverfahren mitgemacht hätten?
Vielleicht hat ein Anbieter nicht angeboten, weil das ursprüngliche Lastenheft nicht zu seinem Leistungsschwerpunkt passte. Vielleicht hätte ein anderer Bieter für den später entstandenen Leistungsumfang ein besseres Konzept oder einen günstigeren Preis anbieten können.
Dann betrifft die Änderung nicht mehr nur den bestehenden Vertrag. Sie betrifft den ursprünglichen Wettbewerb.
Das österreichische Bundesvergabegesetz nennt genau diesen Fall: Eine Vertragsänderung ist insbesondere dann wesentlich, wenn die geänderten Bedingungen das Interesse weiterer Unternehmen am Vergabeverfahren geweckt oder die Auswahl eines anderen Angebots ermöglicht hätten.
Je weiter sich der Backlog vom ausgeschriebenen Lastenheft entfernt, desto fraglicher wird es, ob noch jener Auftrag umgesetzt wird, für den der Wettbewerb stattgefunden hat.
Eine Einigung zwischen Auftraggeber und Lieferant allein reicht dann nicht aus. Handelt es sich um eine wesentliche Vertragsänderung, ist grundsätzlich ein neues Vergabeverfahren erforderlich, sofern keine gesetzliche Ausnahme greift.
Das ist die zweite Grenze vermeintlicher Agilität: Der Auftraggeber darf während des Projekts lernen. Er darf die Ergebnisse dieses Lernprozesses aber nicht unbegrenzt beim bereits ausgewählten Lieferanten bestellen.
Was bedeutet das für die Praxis?
Neue Wünsche aus einem Show-and-Tell sollten nicht automatisch als Arbeitsauftrag verstanden werden. Vor der Umsetzung braucht es zwei Prüfungen:
Vertraglich: Ist die Anforderung bereits enthalten, wird sie gegen eine andere Leistung getauscht oder entsteht zusätzlicher Aufwand?
Vergaberechtlich: Bleibt die Änderung innerhalb des ausgeschriebenen Auftrags oder wäre der veränderte Auftrag möglicherweise auch für andere Anbieter interessant gewesen?
Für jede neue Anforderung gibt es damit vier Möglichkeiten:
Sie ist bereits vom vereinbarten Leistungsumfang umfasst.
Sie ersetzt eine ungefähr gleichwertige Anforderung im Backlog.
Sie wird zusätzlich und vergaberechtlich zulässig beauftragt.
Sie muss getrennt ausgeschrieben oder zurückgestellt werden.
Diese Entscheidungslogik sollte nicht erst während des Projekts entstehen. Sie gehört bereits in die Ausschreibungsunterlagen und in den Vertrag.
Eine allgemeine Formulierung wie „Der Backlog kann während des Projekts angepasst werden“ reicht dafür allein nicht aus. Bereits in den Ausschreibungsunterlagen sollte klar, präzise und eindeutig festgelegt sein, welche Änderungen in welchem Umfang und unter welchen Voraussetzungen möglich sind. Der Gesamtcharakter des Auftrags darf dadurch nicht verändert werden.
Fazit
Show-and-Tell-Sessions sind nicht das Problem. Sie machen sichtbar, was bei der Erstellung des Lastenhefts noch nicht bekannt war. Genau darin liegt ihr Wert.
Doch die gewonnenen Erkenntnisse brauchen klare Grenzen:
Ein agiles Vorgehensmodell ersetzt kein Änderungsverfahren. Ein Backlog hebt den vereinbarten Leistungsumfang nicht auf. Und die Zustimmung des bestehenden Lieferanten ersetzt keinen vergaberechtlichen Wettbewerb.
Welche Erfahrungen haben Sie gemacht? Wie werden neue Anforderungen aus Sprint Reviews oder Show-and-Tell-Sessions in Ihren Fixpreisprojekten behandelt?
Dieser Beitrag bietet eine allgemeine Einordnung und ersetzt keine rechtliche Prüfung des jeweiligen Einzelfalls.
https://spiritinprojects.com/wp-content/uploads/2026/09/Team-Besprechung-.png450800Wolfgang Hiermannhttps://spiritinprojects.com/wp-content/uploads/2020/04/sip_web_padding_10px_topbot.jpgWolfgang Hiermann2026-09-08 14:28:032026-09-08 14:32:26Lastenheft, Fixpreis, fixer Termin – und bitte agil: Zwei Paradoxien bei IT-Ausschreibungen
Ein Unternehmen will einen Kundenservice-Agenten einführen. Das KI ist ausgewählt, der Prompt ist geschrieben, die ersten einfach Tests mit Demodaten sehen gut aus. Dann die Ernüchterung: Der Agent kann nicht auf das Ticketsystem zugreifen, weil es keine passende API gibt. Die benötigten Kundendaten liegen verschiedenen Systemen, die nicht miteinander sprechen können und manche aktuelle Infos sind nur in Excel-Dateien auf Mitarbeiterdesktops zu finden. Die DSGVO-Konformität der automatisierten Datenverarbeitung ist ungeklärt. Und niemand hat definiert, was der Agent tun darf, wenn ein Kunde kündigen will und was er unbedingt nicht tun darf.
Die KI wäre bereit loszulegen. Die Organisation nicht.
Dieses Szenario ist kein Einzelfall. In Teil 1 dieser Reihe haben wir gesehen, was Agentic AI ist und warum sie technisch funktioniert: Werkzeuge, Planung und Gedächtnis – die drei Säulen, die LLMs von Chatbots zu Agenten machen. Aber diese drei Säulen brauchen ein Fundament. Und genau dieses Fundament fehlt in vielen Unternehmen.
Was ist Agent-Readiness?
Agent-Readiness beschreibt den Grad, in dem ein Unternehmen technisch und organisatorisch so aufgestellt ist, dass KI-Agenten produktiv arbeiten können.
Die Analogie ist naheliegend: Man würde auch keinen neuen Mitarbeiter in ein Unternehmen setzen, ohne ihm einen Laptop, Zugang zu den Systemen, eine Aufgabenbeschreibung und einen Ansprechpartner zu geben. Bei Agenten ist es nicht anders – nur dass die meisten Unternehmen genau das tun. Sie setzen die Fähigkeiten der KI voraus und vergessen die Arbeitsbedingungen.
Die sechs Dimensionen der Agent-Readiness:
1 Tool-Infrastruktur → Kann der Agent überhaupt handeln? 2 Datenzugänglichkeit → Kommt der Agent an die richtigen Daten? 3 Zugriffskontrolle → Darf der Agent das, was er tun soll? 4 Observability → Weiß man, was der Agent tut? 5 Verantwortung → Wer ist verantwortlich, wenn etwas schiefgeht? 6 Team & Prozesse → Wer baut, betreut und verbessert den Agenten
Keine dieser Dimensionen ist optional. Jede einzelne kann der Flaschenhals sein, der einen Agenten theoretisch mächtig, praktisch aber nutzlos macht.
Dimension 1: Tool-Infrastruktur – Kann der Agent überhaupt handeln?
Agenten handeln über Werkzeuge (Function Calling). Ein Agent ohne Werkzeuge ist ein Chatbot. Aber Werkzeuge gibt es nicht einfach so – sie müssen gebaut, dokumentiert und bereitgestellt werden.
APIs als Lebensader
Agenten greifen auf Systeme über APIs zu. Das ist keine Neuigkeit – aber die Qualität der API-Landschaft entscheidet darüber, ob ein Agent arbeiten kann oder nicht.
AGENT READY
NICHT AGENT-READY
RESTful APIs mit klarer Dokumentation
Keine APIs, nur manuelle Oberflächen
Konsistente Authentifizierung
Verschiedene Auth-Methoden pro System
Versionierte APIs mit Abwärtskompatibilität
Undokumentierte Änderungen, Breaking Changes
Strukturierte Fehlermeldungen
Kryptische Fehler oder stilles Scheitern
Wie viele der unternehmensinternen Systeme haben eine maschinenlesbare API? Wenn die Antwort „die Hälfte“ oder „weniger“ ist, kann ein Agent nicht die Hälfte der Aufgaben erledigen – und bricht bei Aufgaben, die mehrere Systeme verknüpfen, komplett zusammen.
Tool-Beschreibungen als Schnittstelle Mensch-Maschine
Die KI wählt Werkzeuge anhand ihrer Beschreibung in natürlicher Sprache. Das bedeutet: Jedes Werkzeug braucht eine präzise Beschreibung. Vage Beschreibungen führen zu falschen Aufrufen oder dazu, dass Werkzeuge gar nicht genutzt werden. Parameter müssen klar definiert sein – welche Werte erwartet werden, welche Pflicht sind, welche Formate gültig sind. Und Fehlerfälle müssen beschrieben sein, damit das LLM darauf reagieren kann, wenn ein Aufruf scheitert.
Name: suche_kunde Beschreibung: Sucht einen Kunden anhand von Name, E-Mail oder Kundennummer. Gibt Kundendaten inkl. Vertragsstatus und letzter Interaktion zurück. Verwende dies, wenn du spezifische Kundendaten brauchst. Parameter: -suchbegriff (string, Pflicht): Name, E-Mail oder 8-stellige Kundennummer feld_typ (string, optional): „name“, „email“ oder „kundennummer“ – verbessert die Suchgenauigkeit Fehler: „kein_treffer“: Kein Kunde gefunden. Frag den Nutzer nach mehr Details. „mehrere_treffer“: Mehrere Kunden passen. Liste die Ergebnisse auf und frag nach Klärung.
Der Unterschied ist nicht kosmetisch. Er ist funktional. Die KI (das LLM) wird mit der ersten Beschreibung Kunden suchen, aber oft falsche Parameter übergeben, bei Fehlern nicht wissen, wie es reagieren soll, und bei Mehrdeutigkeiten raten statt nachfragen. Mit der zweiten Beschreibung arbeitet es präzise, offensiv und fehlerresilient.
Tool-Design für Agenten ist ein neues Handwerkszeug. Es ist API-Design plus UX-Design – nur dass der Nutzer eine KI ist.
Dimension 2: Datenzugänglichkeit – Kommt der Agent an die richtigen Daten?
Der klügste Agent ist nutzlos, wenn die Daten in Silos liegen, die er nicht erreichen kann.
Typische Daten-Hürden
HINDERNIS
AUSWIRKUNG AUF DEN AGENTEN
Daten liegen in Excel-Dateien auf Netzlaufwerken
Daten liegen in Excel-Dateien auf Netzlaufwerken
Kundendaten in drei verschiedenen Systemen
Agent findet keine einheitliche Antwort
Dokumente als gescannte PDFs
Agent kann den Text nicht direkt lesen
Alte Systeme ohne API (Legacy)
Agent kann nur über Umwege zugreifen
Datenqualität ist schlecht (Duplikate, Inkonsistenzen)
Agent arbeitet mit falschen Daten – Ergebnisse sind unzuverlässig
Was Agent-Readiness hier bedeutet:
Daten müssen maschinenlesbar zugreifbar sein. Das klingt banal, ist aber in vielen Unternehmen der größte Flaschenhals. Nicht jedes System braucht eine API – aber die Daten, die ein Agent braucht, müssen irgendwie strukturiert erreichbar sein. Sei es über eine API, über eine Datenbankabfrage oder über eine Dateischnittstelle.
RAG als Brücke. Retrieval-Augmented Generation erlaubt Agenten den Zugriff auf unstrukturierte Daten – Dokumente, Handbücher, interne Wikis. RAG ist kein Hexenwerk, braucht aber: eine funktionierende Vektor-Datenbank, aktuelle Dokumente, saubere Aufbereitung und Metadaten. RAG löst aber nicht das Problem schlechter Daten – es macht schlechte Daten nur schneller auffindbar.
Datenqualität ist Agentenqualität. Ein Agent, der auf veraltete oder widersprüchliche Daten zugreift, produziert veraltete oder widersprüchliche Ergebnisse. Datenpflege wird durch Agenten nicht obsolet – sie wird wichtiger. Wer sich damit beschäftigt, wie KI mit schlechten Daten umgeht, findet mehr dazu im Artikel über KI-Halluzinationen in dieser Reihe.
Wenn ein Mensch 10 Minuten braucht, um eine bestimmte Information zu finden – wie lange braucht der Agent? Wenn die Antwort „länger“ oder „gar nicht“ lautet, liegt das Problem nicht beim Agenten.
Dimension 3: Zugriffskontrolle – Darf der Agent das, was er tun soll?
Ein Agent braucht Zugriffe – aber nicht auf alles. Und nicht mit den gleichen Rechten wie ein Administrator. Das Prinzip der minimalen Rechte (Least Privilege) gilt besonders für Agenten.
Berechtigungsmodelle für Agenten
Drei Rollen, die jedes Agenten-Projekt braucht
Rolle
Verantwortung
Typisches Profil
Agent-Developer
Baut den Agenten, schreibt Prompts, integriert Werkzeuge
Software-Entwickler/in mit LLM-Erfahrung
Agent-Operator
Überwacht den Betrieb, analysiert Logs, greift bei Fehlern ein
IT-Operations mit Verständnis für KI-Besonderheiten
Domain-Expert
Definiert Aufgaben, bewertet Ergebnisse, gibt Fachwissen
Fachbereichsmitarbeiter/in, die den Prozess kennt
Service-Accounts für Agenten
Agenten sollten eigene Identitäten haben – nicht die eines menschlichen Mitarbeiters. Das ermöglicht Auditing, weil jede Aktion nachvollziehbar dem Agenten zugeordnet ist. Es ermöglicht Rechte-Scoping, weil der Agent nur die Rechte bekommt, die er für seine Aufgabe braucht. Es ermöglicht Abschaltung, weil ein Agent deaktiviert werden kann, ohne menschliche Nutzer zu beeinflussen. Und es ermöglicht datenschutzrechtliche Klarheit, weil offensichtlich ist, dass eine Maschine auf Daten zugreift.
Human-in-the-Loop als Geschäftsanforderung
Nicht jede Aktion sollte ein Agent selbstständig ausführen. Die Entscheidung, welche Aktionen autonom sind und welche menschliche Freigabe brauchen, ist eine Geschäftsanforderung, keine technische:
Aktion
Autonom?
Begründung
Kundendaten abrufen
✅ Ja
Nur-Lese-Zugriff, geringes Risiko
Standard-E-Mail senden
✅ Ja
Vordefinierte Vorlagen, geprüft
Kundenerstattung veranlassen
❌ Freigabe nötig
Finanzielle Auswirkung
Vertragskonditionen ändern
❌ Freigabe nötig
Rechtliche Relevanz
Incident an Eskalation weiterleiten
✅ Ja
Zeitkritisch, klarer Prozess
Diese Einteilung kann kein Technik-Team allein treffen. Sie braucht den Fachbereich, der definiert: Wo ist das Risiko akzeptabel? Wo brauchen wir menschliche Kontrolle? Und was passiert, wenn der Agent in einem Graubereich landet?
Dimension 4: Observability – Weiß man, was der Agent tut?
Ein Agent führt möglicherweise Hunderte oder sogar viele Tausende von Aktionen pro Tag aus. Ohne Nachvollziehbarkeit ist das ein Black-Box-Betrieb – und das ist inakzeptabel. Wie man KI-Ausgaben grundsätzlich kontrolliert, haben wir im Artikel über LLM-Guardrails behandelt. Für Agenten kommt eine weitere Ebene hinzu: Nicht nur die Ausgabe muss überwacht werden, sondern jeder einzelne Handlungsschritt.
Drei Ebenen der Nachvollziehbarkeit
Ebene 1: Logging – Was ist passiert? Jeder Werkzeug-Aufruf wird protokolliert: Welches Werkzeug, welche Parameter, welches Ergebnis. Jeder Denkschritt wird gespeichert: Was hat der Agent überlegt, bevor er gehandelt hat? Dazu Zeitstempel, Dauer und Token-Verbrauch pro Schritt.
Ebene 2: Monitoring – Läuft alles normal? Erfolgsquote der Werkzeug-Aufrufe, durchschnittliche Aufgabendauer, Fehlerraten nach Werkzeug und Aufgabentyp, Kosten pro Aufgabe und Eskalationsrate – wie oft muss ein Mensch eingreifen? Diese Metriken erlauben es, Probleme früh zu erkennen: Wenn ein Werkzeug plötzlich häufiger fehlschlägt, ist das ein Signal.
Ebene 3: Auditing – Warum ist etwas passiert? Vollständige Entscheidungsketten für jede Aufgabe. Rückverfolgbarkeit: Welche Eingabe führte zu welcher Aktion? Und der Vergleich: Hat der Agent die Aufgabe gelöst? Entspricht das Ergebnis den Erwartungen?
Was gutes Agent-Logging ausmacht
Der Unterschied zwischen „Der Agent hat eine E-Mail gesendet“ und „Der Agent hat am 15.05.2026 um 14:32 Uhr eine E-Mail an kunde@example.com gesendet mit dem Betreff ‚Ihre Rückfrage zum Auftrag #4821‘ – weil in Schritt 3 des ReAct-Zyklus das Werkzeug lade_auftrag den Status ‚in Bearbeitung‘ zurückgegeben hat und der Agent entschied, dass der Kunde darüber informiert werden muss.“
Erst diese Tiefe macht ein Auditing sinnvoll. Ohne sie bleibt der Agent eine Black Box – und Black Boxes sind in produktiven Systemen nicht akzeptabel.
Dimension 5: Verantwortung – Wer ist verantwortlich, wenn etwas schiefgeht?
Agenten treffen Entscheidungen und führen Aktionen aus. Wenn etwas schiefgeht, ist die Frage: Wer ist verantwortlich? Die Antwort ist klarer, als viele glauben – und unbequemer, als viele hoffen.
Das Drei-Ebenen-Modell
Ebene 1: Der Modellanbieter (OpenAI, Anthropic, Google) ist verantwortlich für die Qualität und Sicherheit des Basismodells. Aber: Die Modellanbieter kennen nicht die Unternehmenskontexte. Sie garantieren nicht, dass ihr Modell in jeder Anwendung korrekt handelt.
Ebene 2: Das Plattform-Team ist verantwortlich für Werkzeug-Design, Guardrails, Berechtigungen und Monitoring. Das ist das Bindeglied zwischen dem, was das Modell kann, und dem, was der Agent im Unternehmenskontext tun darf.
Ebene 3: Der Fachbereich ist verantwortlich für die Definition der Aufgabe, die Freigabe von Aktionen und die Überprüfung der Ergebnisse. Das Modell liefert, der Fachbereich entscheidet.
Die unbequeme Wahrheit
Ein Agent ist kein eigenständiger Akteur. Er ist ein Werkzeug, das von Menschen gebaut, konfiguriert und überwacht wird. Die Verantwortung liegt immer bei den Menschen, die ihn einsetzen – nicht bei der KI.
Auch regulatorisch wird das klar: Der EU AI Act definiert Verantwortlichkeiten für den Einsatz von KI-Systemen. Der Agent hat keine eigene Rechtspersönlichkeit. Die Haftung bleibt beim Unternehmen. Wer heute keine nachvollziehbare Strategie für Agenten-Einsatz dokumentiert, schafft sich später Compliance-Arbeit.
Dimension 6: Team & Prozesse – Wer baut, betreut und verbessert den Agenten?
Agenten sind keine Einmal-Entwicklung. Sie brauchen kontinuierliche Pflege, Verbesserung und Anpassung. Die meisten Unternehmen unterschätzen diesen Aufwand massiv.
Drei Rollen, die jedes Agenten-Projekt braucht
Rolle
Verantwortung
Typisches Profil
Agent-Developer
Baut den Agenten, schreibt Prompts, integriert Werkzeuge
Software-Entwickler/in mit LLM-Erfahrung
Agent-Operator
Überwacht den Betrieb, analysiert Logs, greift bei Fehlern ein
IT-Operations mit Verständnis für KI-Besonderheiten
Domain-Expert
Definiert Aufgaben, bewertet Ergebnisse, gibt Fachwissen
Fachbereichsmitarbeiter/in, die den Prozess kennt
Der häufigste Fehler: Entwickler bauen einen Agenten ohne tiefes Verständnis des Fachprozesses. Das Ergebnis funktioniert technisch, aber inhaltlich nicht. Die Zusammenarbeit zwischen Developer und Domain-Expert ist kritisch – und sie braucht Zeit, die in Projektplänen oft fehlt.
Prozesse, die etabliert werden müssen
Agent-Lifecycle-Management: Von der Definition über Entwicklung, Test, Staging, Deployment bis zum Monitoring – Agenten brauchen einen strukturierten Prozess wie jedes andere Software-Produkt.
Prompt-Review: Prompts sind Code. Sie müssen versioniert, getestet und reviewed werden. Ein geänderter Prompt kann das Verhalten eines Agenten radikal verändern – und nicht immer zum Besseren.
Werkzeug-Review: Jedes neue Werkzeug, das ein Agent erhält, ändert seinen Handlungsspielraum. Neue Werkzeuge müssen geprüft werden: Was kann schiefgehen? Welche Guardrails braucht es? Was passiert, wenn das Werkzeug unerwartet reagiert?
Regelmäßige Evaluierung: Agenten-Performance verändert sich – durch Modell-Updates, sich ändernde Daten, neue Anforderungen. Regelmäßige Tests mit realen Aufgaben sind notwendig, nicht optional.
Der Agent-Readiness-Check
Ein pragmatischer Selbsttest für Unternehmen:
Dimension
✅ Agent-Ready
⚠️ Auf dem Weg
❌ Nicht bereit
Tool-Infrastruktur
Die meisten Systeme haben gut dokumentierte APIs
Einige Systeme haben APIs, aber unzureichend dokumentiert
Die meisten Systeme haben keine APIs
Datenzugänglichkeit
Daten sind strukturiert und maschinenlesbar zugreifbar
Einige Daten sind zugreifbar, andere nicht
Daten liegen in Silos, gescannten PDFs, Excel-Dateien
Zugriffskontrolle
Service-Accounts mit Least Privilege sind etabliert
Es gibt Berechtigungskonzepte, aber nicht für Agenten
Alle Nutzer teilen sich Admin-Zugänge
Observability
Agenten-Aktionen werden vollständig geloggt und überwacht
Es gibt Logging, aber keine Agenten-spezifische Auswertung
Es gibt kein systematisches Logging
Verantwortung
Rollen und Verantwortlichkeiten sind klar definiert
Es gibt Ansprechpartner, aber keine formalen Prozesse
Niemand ist explizit verantwortlich
Team & Prozesse
Dediziertes Team, strukturierte Prozesse
Einige Personen befassen sich damit, aber nebenbei
Keine personelle Zuständigkeit
Faustregel: Wenn weniger als drei Dimensionen „✅ Agent-Ready“ sind, sollte der Fokus zuerst auf der Infrastruktur liegen – nicht auf dem Agenten. Ein Agent auf einem schwachen Fundament wird enttäuschen. Die Investition in die Infrastruktur zahlt sich aber nicht nur für den Agenten aus, sondern für die gesamte Digitalisierung.
Ausblick
Agent-Readiness ist kein Zustand, den man einmal erreicht und dann abhakt. Es ist ein Reifegrad, der schrittweise aufgebaut wird. Die gute Nachricht: Jede Verbesserung der Infrastruktur nützt nicht nur den Agenten, sondern dem gesamten Unternehmen. Bessere APIs, zugänglichere Daten, klarere Berechtigungen – das sind Investitionen, die sich auch ohne Agenten rechnen.
Stand: Mai 2026
https://spiritinprojects.com/wp-content/uploads/2026/08/circuit-board-close-up-with-diff.jpg450800Karl Schotthttps://spiritinprojects.com/wp-content/uploads/2020/04/sip_web_padding_10px_topbot.jpgKarl Schott2026-08-20 13:38:152026-08-31 17:57:14Agent-Ready: Warum die KI das kleinste Problem ist – und die Infrastruktur das größte
Künstliche Intelligenz ist längst im Arbeitsalltag angekommen, aber wirklich verstanden hat sie kaum jemand vollständig. Genau hier setzen die neuen Micro-Zertifizierungen (Micro Certs) von Spirit in Projects an: kompakte KI-Weiterbildung mit praxisnahem KI-Wissen, verpackt in leicht verdaulichen Kapiteln, ergänzt durch Mini-Quizzes, und am Ende ein digitales Badge, das man sogar stolz auf LinkedIn teilen kann.
Was steckt hinter den Micro Certs?
Eine Microzertifizierung ist ein kurzes, fokussiertes Online-Training: eine in sich abgeschlossene Lerneinheit, die man in 30 bis 60 Minuten im eigenen Tempo durcharbeiten kann. Micro Certs ergänzen unsere klassischen Trainingsangebote um eine besonders schnelle Einstiegsmöglichkeit und sind ideal für alle, die ohne Vorkenntnisse in ein neues Thema einsteigen wollen, ohne dabei den Anspruch an fachliche Tiefe aufzugeben.
Aktuell stehen zwei KI-fokussierte Micro-Certs zur Auswahl:
1. SIP EU AI Act Ready Micro Cert
Der ideale Einstieg für alle, die generative KI zum ersten Mal wirklich verstehen wollen. In sechs kompakten Kapiteln (ca. 30 Minuten) geht es unter anderem um:
Was generative KI eigentlich ist und wie sie sich von einer klassischen Suchmaschine unterscheidet
Wie Sprachmodelle „denken“ und Wort für Wort Antworten vorhersagen
Was KI heute schon gut kann und wo ihre Grenzen liegen
Die Basics des präzisen Promptens (Prompt Engineering für Einsteiger)
Goldene Regeln für den sicheren Alltag mit KI-Tools
Eine rechtliche Einordnung: Risikoklassen und Pflichten des EU AI Act
Am Ende jedes Kapitels wartet ein kurzes Wissens-Quiz mit sofortigem Feedback, statt Blättern in dicken Handbüchern gibt es direktes Lernen durch Ausprobieren. Wer alle 38 Lernschritte durchläuft, erhält ein Silber-Badge, das sechs Monate gültig ist.
2. SIP AI Literacy Micro Cert
Wer tiefer einsteigen möchte, findet hier ein deutlich umfassenderes Training (ca. 60 Minuten, 79 Lernschritte) mit zehn Kapiteln: von der KI-Landkarte über maschinelles Lernen bis hin zu fortgeschrittenen Prompt-Techniken, RAG, KI-Agenten und verantwortungsvollem KI-Einsatz im Unternehmen. Auch der EU AI Act und typische Risiken im Dauerbetrieb, wie etwa Model Drift, werden behandelt.
Das Besondere an diesem Kurs: Er endet mit einer Abschlussprüfung. Wer diese erfolgreich besteht, erhält das begehrte Gold-Badge, gültig für zwölf Monate. Dieser Kurs eignet sich zudem hervorragend als Grundlage, um Mitarbeitende im Sinne der gesetzlichen Anforderungen des EU AI Acts (insbesondere Artikel 4) zu schulen.
Lernen in kleinen Schritten mit direktem Feedback
Was beide Micro-Certs gemeinsam haben, ist der didaktische Aufbau:
Einfach verständliche Kapitel: Jedes Thema wird in überschaubare Häppchen zerlegt, verständlich erklärt und ohne unnötigen Fachjargon vermittelt.
Mini-Quizzes zwischen den Kapiteln: Statt am Ende alles auf einmal abzufragen, wird das Wissen direkt nach jedem Kapitel spielerisch überprüft. So bleibt das Gelernte besser hängen.
Abschlussprüfung (beim AI Literacy Micro Cert): Für alle, die ihr Wissen noch einmal ganzheitlich unter Beweis stellen möchten.
Sofortzugriff und eigenes Tempo: Die Kurse sind komplett online, jederzeit startbar und lassen sich flexibel ins eigene Zeitfenster einbauen.
Das digitale Badge: mehr als nur ein hübsches Icon
Am Ende jeder erfolgreich abgeschlossenen Microzertifizierung wartet ein digitales Badge, der persönliche Nachweis, dass man sich mit dem Thema KI ernsthaft auseinandergesetzt hat. Und dieses LinkedIn-Badge kann sich sehen lassen:
Digital & verifizierbar: Über eine öffentliche Verifikationsseite kann jeder, etwa ein Arbeitgeber oder Kunde, jederzeit nachprüfen, dass das Badge echt ist.
Direkt auf LinkedIn teilbar: Mit einem Klick landet das Badge im eigenen LinkedIn-Profil und macht die eigene KI-Kompetenz auch nach außen sichtbar.
Gültigkeitsdauer auf einen Blick: Da sich KI-Wissen schnell weiterentwickelt, ist jedes Badge zeitlich begrenzt gültig, so bleibt der Nachweis immer aktuell.
Silber oder Gold: Silber gibt es für den erfolgreichen Abschluss eines Micro Certs, Gold für Micro Certs mit zusätzlicher Abschlussprüfung.
Für wen lohnt sich das?
Ob Berufseinsteiger, erfahrene Fachkraft oder Führungskraft: Die Micro Certs setzen bewusst keine Vorkenntnisse voraus und richten sich an alle, die im Berufsalltag zunehmend mit KI-Tools zu tun haben, aber bislang nie die Zeit für eine ausführliche Weiterbildung gefunden haben. Gerade für Unternehmen, die eine EU-AI-Act-Schulung für ihre Mitarbeitenden benötigen, bietet der AI Literacy Micro Cert einen besonders praxisnahen KI-Grundlagenkurs mit zertifizierbarem Ergebnis.
Fazit
Die neuen Micro-Zertifizierungen zeigen, dass KI-Weiterbildung nicht zwangsläufig zeitintensiv oder trocken sein muss. Kurze Kapitel, spielerische Zwischen-Quizzes, eine optionale Abschlussprüfung und ein digitales, LinkedIn-fähiges Badge machen den Einstieg ins Thema KI so leicht wie nie zuvor.
Bei größeren IT-Projekten erleben wir immer wieder denselben Ablauf: Es werden Workshops organisiert, Anforderungen gesammelt, Lastenhefte erstellt und manchmal hat man sich auch schon Lösungen potenzieller Lieferanten angesehen. Über Technologien, Funktionen und Budgets wird intensiv diskutiert.
Doch eine entscheidende Frage wird häufig viel zu spät gestellt:
Lohnt sich diese Investition überhaupt?
Genau diese Frage entscheidet jedoch darüber, ob ein Projekt langfristig erfolgreich wird oder ob am Ende zwar eine moderne Lösung eingeführt wurde, der erwartete Nutzen aber ausbleibt.
Aus unserer Sicht beginnt eine erfolgreiche IT-Ausschreibung deshalb nicht mit einem Lastenheft. Sie beginnt mit einer fundierten Wirtschaftlichkeitsbetrachtung.
Mehr als nur ein Kostenvergleich
Wenn von Wirtschaftlichkeit gesprochen wird, denken viele zunächst an einen einfachen Vergleich von Anschaffungs-, Betriebs- oder Lizenzkosten. Doch genau das greift viel zu kurz. Denn die günstigste Lösung ist nicht automatisch die wirtschaftslichste.
Eine professionelle Wirtschaftlichkeitsbetrachtung beantwortet Fragen wie:
Welches Problem soll eigentlich gelöst werden?
Welche Alternativen stehen zur Verfügung?
Welche Lösung bringt den größten langfristigen Nutzen?
Welche Risiken bestehen?
Welche Auswirkungen hat die Investition auf Prozesse, Mitarbeitende und Kunden?
Erst wenn diese Fragen beantwortet sind, lässt sich beurteilen, welche Lösung tatsächlich die wirtschaftlichste ist.
Gute Entscheidungen berücksichtigen mehr als Zahlen
Natürlich spielen Investitions- und Betriebskosten eine wichtige Rolle. Ebenso wichtig sind jedoch die Auswirkungen, die sich nicht unmittelbar in Euro ausdrücken lassen.
Wie stark verbessert sich die Qualität der Prozesse?
Wie viel Zeit wird künftig eingespart?
Steigt die Zufriedenheit der Mitarbeitenden?
Verbessert sich der Service für unsere Anwender und Kunden?
Diese Faktoren entscheiden oft darüber, ob eine IT-Investition ihren gewünschten Erfolg erreicht.
Wer ausschließlich auf Anschaffungskosten schaut, bewertet nur einen kleinen Teil der tatsächlichen Wirtschaftlichkeit.
Warum eine Wirtschaftlichkeitsbetrachtung heute aktueller denn je ist
Für die Vorbereitung von Investitionsentscheidungen haben sich verschiedene Methoden etabliert. Sie beleuchten unterschiedliche Aspekte der Wirtschaftlichkeit und ergänzen sich sinnvoll.
Die Kapitalwertmethode bewertet sämtliche monetären Auswirkungen einer Investition über ihren gesamten Lebenszyklus. Dabei werden Entwicklungs-, Einführungs- und Betriebskosten ebenso berücksichtigt wie Einsparungen und Risiken. Ziel ist es, den langfristigen wirtschaftlichen Nutzen einer Investition objektiv zu bewerten.
Ergänzt wird diese Betrachtung durch eine Nutzwertanalyse. Sie bewertet jene Faktoren, die für den Projekterfolg entscheidend sind, sich aber nicht sinnvoll in Euro ausdrücken lassen. Dazu gehören beispielsweise die strategische Bedeutung einer Maßnahme, Qualitätsverbesserungen, kürzere Durchlaufzeiten, bessere Entscheidungsgrundlagen oder der Nutzen für Bürger, Unternehmen und Mitarbeitende.
Ein weiterer etablierter Ansatz ist der Business Case. Er erweitert die Wirtschaftlichkeitsbetrachtung um die Frage, warum eine Investition überhaupt durchgeführt werden soll. Neben Kosten und Nutzen werden dabei auch strategische Ziele, Alternativen, Risiken und der erwartete Mehrwert für die Organisation betrachtet.
Denn eine Investition kann zwar wirtschaftlich sein, strategisch aber wenig Nutzen bringen. Umgekehrt kann eine Maßnahme trotz eines zunächst negativen Kapitalwerts sinnvoll sein, wenn sie für die Organisation von zentraler strategischer Bedeutung ist oder erhebliche qualitative Verbesserungen erzielt. Genau deshalb sollte sowohl die monetären als auch die qualitativen Aspekte einer Investitionsentscheidung betrachtet werden.
Die größten Einsparungen entstehen vor der Ausschreibung
Unsere Erfahrung aus zahlreichen IT-Projekten zeigt, dass die größten Potentiale für Einsparungen selten während oder nach der Umsetzung entstehen.
Sie entstehen bereits in der Vorbereitungsphase.
Eine fundierte Wirtschaftlichkeitsbetrachtung schafft Klarheit über Ziele, Alternativen und Risiken. Sie verhindert, dass Lösungen (Systeme) ausgeschrieben werden, die später niemand benötigt. Sie hilft, den tatsächlichen Bedarf sauber zu definieren und schafft eine nachvollziehbare Grundlage für Management- und Budgetentscheidungen.
Dadurch verbessert sich nicht nur die Qualität des Lastenhefts. Auch spätere Änderungen, Nachträge und Diskussionen während der Umsetzung lassen sich häufig deutlich reduzieren.
Die Wirtschaftlichkeitsbetrachtung ist kein Dokument – sondern eine Entscheidungshilfe
Leider wird die Wirtschaftlichkeitsbetrachtung in vielen Projekten noch immer als lästiges Pflichtdokument verstanden, das kurz vor der Genehmigung oder einer Ausschreibung erstellt wird. Viel zu oft wird zuerst entschieden – und anschließend versucht, die Entscheidung wirtschaftlich zu begründen.
Dabei sollte sie genau das Gegenteil sein. Die Wirtschaftlichkeitsbetrachtung sollte den Ausgangspunkt jeder größeren IT-Investition bilden.
Nicht um eine bereits getroffene Entscheidung zu rechtfertigen, sondern um die beste Entscheidung überhaupt erst treffen zu können.
Wie wir unsere Kunden unterstützen
Genau hier begleiten wir unsere Kunden.
Die spirit in projects GmbH unterstützt öffentliche Auftraggeber und Unternehmen bereits in der strategischen Vorbereitungsphase von IT-Projekten. Gemeinsam analysieren wir den Handlungsbedarf, vergleichen Lösungsalternativen, erstellen Wirtschaftlichkeitsbetrachtungen, führen Nutzwertanalysen durch und entwickeln daraus belastbare Lastenhefte und Ausschreibungsunterlagen.
Unser Ziel ist nicht nur eine erfolgreiche Ausschreibung. Unser Ziel ist, dass die richtige Lösung ausgeschrieben wird.
Fazit
Eine Ausschreibung entscheidet darüber, wer den Auftrag erhält.
Eine Wirtschaftlichkeitsbetrachtung entscheidet darüber, ob überhaupt die richtige Lösung ausgeschrieben wird.
Wer diesen Schritt überspringt, riskiert Fehlentscheidungen, unnötige Kosten und Projekte, deren erwarteter Nutzen nie vollständig erreicht wird.
Deshalb sollte jede größere IT-Investition mit einer fundierten Wirtschaftlichkeitsbetrachtung beginnen – nicht als Pflichtübung am Ende, sondern als Grundlage einer guten Entscheidung.
https://spiritinprojects.com/wp-content/uploads/2026/08/Blog-Wahrscheinlichkeitsbetrachtung.jpg450800Wolfgang Hiermannhttps://spiritinprojects.com/wp-content/uploads/2020/04/sip_web_padding_10px_topbot.jpgWolfgang Hiermann2026-08-10 13:22:332026-08-10 13:22:34Ohne Wirtschaftlichkeitsbetrachtung ist jede IT-Ausschreibung ein Blindflug
Viele Unternehmen arbeiten heute nach Scrum. Trotzdem sind ihre Product Backlogs überfüllt, User Stories werden im Sprint nicht fertig und wandern regelmäßig in den nächsten Sprint. Das Team arbeitet von Sprint zu Sprint – doch der Berg offener Anforderungen wird kaum kleiner.
Die Einführung von Scrum wurde dabei häufig mit einem klaren Ziel begründet: Wir wollen schneller werden.
Genau diesen Satz höre ich seit vielen Jahren in nahezu jedem Unternehmen. Agile Methoden gelten als Synonym für Geschwindigkeit, Flexibilität und schnelle Ergebnisse.
Doch genau hier beginnt das Missverständnis.
Geschwindigkeit war nie das eigentliche Ziel
Die ursprüngliche Idee des Agilen Manifests war nicht, Projekte möglichst schnell abzuschließen.
Vielmehr sollte vermieden werden, dass Teams über Monate oder Jahre an Lösungen arbeiten, die am Ende am Bedarf des Kunden vorbeigehen.
Anstatt sämtliche Anforderungen zu Beginn vollständig festzulegen, wird schrittweise entwickelt:
Anforderungen werden verfeinert
Software wird umgesetzt
Nutzer geben Feedback
Erkenntnisse fließen in die nächste Iteration ein
Dieser Lernprozess erhöht die Wahrscheinlichkeit, das richtige Produkt zu entwickeln. Er führt jedoch zwangsläufig zu zusätzlichen Abstimmungen und Änderungen.
Agilität ersetzt also lange Planungsphasen durch kontinuierliches Lernen.
Was Studien tatsächlich zeigen
Wissenschaftliche Untersuchungen bestätigen dieses Bild.
Eine häufig zitierte Studie von Serrador und Pinto mit über 1.000 Projekten zeigt, dass agile Projekte insbesondere bei der Kundenzufriedenheit und der Fähigkeit, auf Veränderungen zu reagieren, besser abschneiden. Ein eindeutiger Nachweis, dass agile Projekte generell schneller abgeschlossen werden, konnte hingegen nicht erbracht werden.
Auch Untersuchungen großer agiler Organisationen zeigen ein ähnliches Bild. Je größer Projekte werden, desto mehr Abstimmung, Architekturarbeit und Anforderungsmanagement werden notwendig. Mit zunehmender Projektgröße verschwinden strukturierte Prozesse also keineswegs – sie gewinnen vielmehr wieder an Bedeutung.
Der größte Irrtum: Agilität ersetzt Requirements Engineering
In vielen Unternehmen entstand in den vergangenen Jahren ein gefährlicher Denkfehler:
“Wir arbeiten agil. Deshalb brauchen wir kein klassisches Requirements Engineering mehr.”
Tatsächlich findet Requirements Engineering auch in Scrum-Projekten täglich statt.
Jede User Story muss
verstanden,
abgestimmt,
priorisiert,
beschrieben,
überprüft und
akzeptiert
werden.
Genau das ist Requirements Engineering.
Lediglich die Artefakte und der Zeitpunkt unterscheiden sich.
Statt eines großen Lasten- oder Pflichtenhefts entstehen Anforderungen kontinuierlich während des Projekts.
Der Product Owner trägt heute eine enorme Verantwortung
Mit Scrum wurde ein großer Teil der Verantwortung für Anforderungen auf den Product Owner übertragen. Doch genau hier zeigt sich häufig eine Schwäche.
Viele Product Owner verfügen über ausgezeichnetes Produktwissen und kennen ihre Stakeholder sehr gut. Die Rolle verlangt heute jedoch deutlich mehr als Priorisierung und Backlog-Pflege.
Professionelles Requirements Engineering gehört mittlerweile zu den wichtigsten Kompetenzen eines erfolgreichen Product Owners.
Was ihnen jedoch oftmals fehlt, sind Methoden des professionellen Requirements Engineering:
Stakeholderanalyse
Konfliktmanagement
Geschäftsprozessanalyse
Modellierung komplexer Abläufe
Definition messbarer Akzeptanzkriterien
Qualitätsprüfung von Anforderungen
Nachverfolgbarkeit (Traceability)
Umgang mit nicht-funktionalen Anforderungen
Diese Kompetenzen werden in Scrum häufig vorausgesetzt, aber selten systematisch aufgebaut.
Gute User Stories entstehen nicht zufällig
Ein häufiger Irrtum lautet: “Wir schreiben einfach User Stories.”
Doch gute User Stories sind das Ergebnis einer sorgfältigen Analyse.
Wer die eigentlichen Bedürfnisse der Anwender nicht versteht, formuliert lediglich kleinere Pakete unklarer Anforderungen.
Die Folgen sind:
Rückfragen während der Entwicklung
unterschiedliche Interpretationen
häufige Nacharbeiten
technische Schulden
unnötige Diskussionen in jedem Sprint
Viele Teams erleben genau das und führen die Probleme anschließend auf Scrum zurück.
In Wahrheit fehlen häufig grundlegende Kompetenzen im Requirements Engineering.
Ein Product Backlog ersetzt keine Anforderungsanalyse. Er dokumentiert lediglich deren Ergebnis.
Agile Projekte investieren anders – nicht weniger
Klassische Projekte investieren einen größeren Teil des Aufwands zu Beginn. Agile Projekte verteilen diesen Aufwand über die gesamte Laufzeit.
Deshalb entsteht häufig der Eindruck, dass agile Projekte schneller starten. Tatsächlich wird jedoch kontinuierlich analysiert, abgestimmt und priorisiert.
Der Analyseaufwand verschwindet also nicht. In vielen Scrum-Projekten wird dieser Aufwand lediglich verschoben.
Anstatt Anforderungen vor der Entwicklung ausreichend zu analysieren, entstehen Diskussionen während des Sprints. Entwickler stellen Rückfragen, Product Owner müssen Entscheidungen kurzfristig treffen und User Stories werden erneut angepasst. Dadurch entstehen genau die Verzögerungen, die Scrum eigentlich vermeiden wollte.
Gerade weil agile Projekte von kurzen Entscheidungszyklen leben, wird professionelles Requirements Engineering wichtiger denn je.
Ein Product Owner sollte deshalb nicht nur das Produkt verstehen. Er sollte auch die Methoden beherrschen, mit denen gute Anforderungen entstehen.
Dazu gehören unter anderem:
systematische Stakeholderanalyse
Moderation unterschiedlicher Interessen
Prozessanalyse
verständliche Modellierung (eventuell mit UML)
Formulierung überprüfbarer Anforderungen
Definition klarer Akzeptanzkriterien
Priorisierung nach Geschäftswert
kontinuierliche Validierung mit den Anwendern
Diese Fähigkeiten entscheiden oft darüber, ob ein agiles Team effizient arbeitet oder sich Sprint für Sprint mit Missverständnissen beschäftigt.
Fazit
Agilität macht Projekte nicht automatisch schneller. Sie macht Veränderungen einfacher. Das ist ein entscheidender Unterschied.
Wer Agilität ausschließlich mit Geschwindigkeit verbindet, wird zwangsläufig enttäuscht werden. Wer sie hingegen als Werkzeug versteht, um Risiken zu reduzieren und schneller zu lernen, wird ihren eigentlichen Nutzen erkennen.
Professionelles Requirements Engineering hat deshalb auch in agilen Projekten keineswegs ausgedient.
Im Gegenteil:
Je agiler ein Projekt arbeitet, desto wichtiger wird die Fähigkeit, die richtigen Anforderungen zur richtigen Zeit in der richtigen Qualität bereitzustellen.
Vielleicht ist genau das die wichtigste Erkenntnis der letzten zwanzig Jahre Agilität:
Die erfolgreichsten Scrum-Teams, die ich kenne, investieren nicht weniger Zeit in Anforderungen – sondern mehr. Der Unterschied ist lediglich, dass sie diese Requirments Engineering Aufgaben kontinuierlich und systematisch vor jedem Sprint leisten. Genau deshalb bleiben ihre Backlogs überschaubar und ihre User Stories werden innerhalb eines Sprints abgeschlossen.
https://spiritinprojects.com/wp-content/uploads/2026/07/agilitaet.jpg450800Wolfgang Hiermannhttps://spiritinprojects.com/wp-content/uploads/2020/04/sip_web_padding_10px_topbot.jpgWolfgang Hiermann2026-07-23 09:21:412026-07-23 09:21:42Agile Projekte sind nicht schneller – und genau deshalb braucht Agilität besseres Requirements Engineering
Cloud, KI, neue Lizenzmodelle und regulatorische Anforderungen verändern derzeit die IT-Landschaft grundlegend. Wer diese Veränderungen nur technisch betrachtet, vergibt enormes Potenzial.
Kaum ein CIO oder IT-Leiter dürfte sich derzeit über mangelnde Herausforderungen beklagen.
Unternehmen migrieren ihre Anwendungen in die Cloud, beschäftigen sich mit dem Einsatz von Künstlicher Intelligenz und müssen gleichzeitig auf neue Lizenzmodelle sowie regulatorische Anforderungen wie NIS2, DORA oder den EU AI Act reagieren. Hinzu kommen steigende Lizenzkosten, der Fachkräftemangel und der Wunsch, die Digitalisierung endlich messbar voranzutreiben.
In unseren Projekten beobachten wir dabei immer wieder ein ähnliches Muster: Die Aufmerksamkeit richtet sich zunächst auf die Auswahl der richtigen Technologie. Welche Plattform soll künftig eingesetzt werden? Welche Systeme müssen ersetzt werden? Welche Daten sind zu migrieren?
Diese Fragen sind wichtig. Sie greifen jedoch häufig zu kurz. Die eigentliche Frage lautet:
Unterstützen unsere heutigen Geschäftsprozesse überhaupt noch die Ziele unseres Unternehmens?
Gerade jetzt bietet sich die Chance, diese Frage neu zu stellen.
Ein neues System löst selten ein altes Problem
Wenn eine Software ersetzt oder modernisiert wird, konzentrieren sich Projekte häufig auf technische Fragestellungen.
Welche Plattform wählen wir?
Welche Daten müssen migriert werden?
Welche Schnittstellen sind anzupassen?
Wann erfolgt der Go-Live?
Aus unserer Erfahrung geraten dabei die eigentlichen Geschäftsprozesse häufig in den Hintergrund. Ein neues System macht aus einem schlechten Prozess keinen guten Prozess. Es digitalisiert ihn lediglich.
Wer bestehende Abläufe unverändert übernimmt, übernimmt meist auch deren Schwächen.
Historisch gewachsene Prozesse
Die wenigsten Geschäftsprozesse wurden einmal entwickelt und anschließend unverändert gelebt. Sie verändern sich über viele Jahre hinweg. Neue gesetzliche Anforderungen, organisatorische Änderungen oder technische Einschränkungen führen dazu, dass Prozesse Schritt für Schritt erweitert werden.
Jede einzelne Anpassung ist für sich genommen meist nachvollziehbar. In der Summe entstehen jedoch zusätzliche Freigaben, manuelle Tätigkeiten oder Medienbrüche, deren ursprünglicher Zweck oft längst in Vergessenheit geraten ist.
Genau deshalb sollte ein Systemwechsel nicht nur als IT-Projekt verstanden werden. Er bietet die ideale Gelegenheit, bestehende Prozesse kritisch zu hinterfragen und auf ihren tatsächlichen Mehrwert zu prüfen.
Der eigentliche Treiber ist oft gar nicht die Digitalisierung
Interessanterweise entstehen viele Transformationsprojekte heute gar nicht aus einer strategischen Entscheidung heraus. Häufig werden sie durch äußere Rahmenbedingungen ausgelöst.
Beispielsweise
endet der Support bestehender Softwarelösungen,
ändern Hersteller ihre Lizenzmodelle,
machen regulatorische Anforderungen organisatorische Anpassungen notwendig oder
eröffnen neue Technologien wie KI völlig neue Möglichkeiten.
In unseren Projekten zeigt sich dabei immer wieder, dass die Technologie lediglich der Auslöser ist. Der eigentliche Veränderungsbedarf liegt häufig in den Geschäftsprozessen
Prozessanalyse ist kein Selbstzweck
Manchmal hören wir den Satz:
“Wir kennen unsere Prozesse ohnehin.”
In der Praxis zeigt sich jedoch häufig etwas anderes.
Unterschiedliche Fachbereiche haben unterschiedliche Vorstellungen vom gleichen Prozess. Verantwortlichkeiten sind nicht eindeutig geregelt. Einzelne Prozessschritte existieren nur deshalb, weil sie vor Jahren einmal notwendig waren.
Eine strukturierte Prozessanalyse schafft hier Transparenz.
Leider wird Prozessanalyse häufig mit Dokumentation verwechselt. Dabei geht es nicht darum, möglichst viele BPMN-Diagramme zu erstellen.
Eine gute Prozessanalyse beantwortet vielmehr grundlegende Fragen:
Welches Ziel verfolgt der Prozess?
Welchen Nutzen stiftet er für Kunden und Unternehmen?
Welche Schritte schaffen tatsächlich Mehrwert?
Wo entstehen Wartezeiten oder Medienbrüche?
Welche Entscheidungen könnten automatisiert werden?
Welche Informationen werden wirklich benötigt?
Welche Prozessschritte existieren nur noch aus historischen Gründen?
Erst wenn diese Fragen beantwortet sind, lassen sich Anforderungen an eine zukünftige Lösung sinnvoll formulieren.
Gute Prozesse reduzieren nicht nur Kosten
In vielen Projekten wird hauptsächlich über Lizenzkosten oder Implementierungsaufwand diskutiert.
Dabei entstehen die größten Einsparungspotenziale häufig an einer ganz anderen Stelle.
Optimierte Prozesse führen zu kürzeren Durchlaufzeiten, weniger manuellen Tätigkeiten, geringerem Schulungsaufwand und einer höheren Datenqualität. Gleichzeitig reduzieren sich individuelle Anpassungen, Schnittstellen und spätere Betriebsaufwände.
Unsere Erfahrung zeigt, dass sich eine fundierte Prozessanalyse häufig bereits während der Einführung eines neuen Systems bezahlt macht.
Business Analyse vor Technologie
Aus unserer Sicht beginnt Digitalisierung nicht mit der Auswahl einer Software. Sie beginnt mit dem Verständnis des Unternehmens über ihre eigenen Prozesse.
Erst wenn Prozesse, Ziele und Anforderungen verstanden sind, lässt sich beurteilen,
welche Funktionen tatsächlich benötigt werden,
welche Prozesse vereinfacht werden können,
wo Automatisierung sinnvoll ist,
und welche Technologie den größten Mehrwert liefert.
In erfolgreichen Projekten folgt die Technologie dem Prozess – nicht umgekehrt.
Fazit
Noch nie standen Unternehmen gleichzeitig vor so vielen technologischen Veränderungen wie heute.
Cloud-Migrationen, Künstliche Intelligenz, neue Lizenzmodelle und regulatorische Anforderungen machen Investitionen in die IT unvermeidlich.
Unsere Erfahrung aus zahlreichen Digitalisierungsprojekten zeigt jedoch: Erfolgreiche Transformationen beginnen nicht mit der Auswahl einer neuen Software, sondern mit dem Verständnis der eigenen Geschäftsprozesse.
Wer den aktuellen Veränderungsdruck nutzt, um Prozesse kritisch zu hinterfragen und neu zu gestalten, schafft nicht nur die Grundlage für eine erfolgreiche Systemeinführung. Er schafft die Grundlage für ein Unternehmen, das auch zukünftige technologische Veränderungen einfacher bewältigen kann.
https://spiritinprojects.com/wp-content/uploads/2026/07/Geschaeftsprozess-ueberdenken.jpg450800Wolfgang Hiermannhttps://spiritinprojects.com/wp-content/uploads/2020/04/sip_web_padding_10px_topbot.jpgWolfgang Hiermann2026-07-20 12:55:122026-07-20 12:56:16Warum jetzt der richtige Zeitpunkt ist, Geschäftsprozesse neu zu denken
Warum IT-Projekte selten an der Technologie scheitern – aber häufig an unklaren Anforderungen
Wenn ein IT-Projekt scheitert, werden die Ursachen häufig bei der Technologie gesucht.
Die Software war nicht ausgereift.
Der Lieferant hat schlecht oder nicht geliefert.
Die Architektur war für unser Problem ungeeignet.
Die Entwickler waren überlastet.
In der Praxis sehen wir jedoch immer wieder ein anderes Muster.
Die eigentlichen Probleme entstehen oft deutlich früher – lange bevor die erste Zeile Code geschrieben wird. Sie entstehen dann, wenn Projekte mit unklaren Zielen, widersprüchlichen Erwartungen und unzureichend definierten Anforderungen gestartet werden.
Die Folgen sind meist erst Monate später sichtbar. Dann jedoch mit voller Wucht.
Die teuersten Fehler entstehen in den ersten Wochen
In vielen Projekten herrscht besonders am Beginn großer Zeitdruck.
Endlich ist das Budget genehmigt. Das Projekt kann starten. Der Fachbereich wartet oft schon seit Monaten auf eine Lösung und drängt, verständlicherweise, auf eine schnelle Umsetzung.
Dadurch ist die Versuchung groß, die Analysephase möglichst kurz zu halten. Da man schon lange über die Probleme und Wünsche an das System gesprochen hat.
Genau hier entsteht häufig der erste Fehler.
Ein Missverständnis in einem Anforderungsworkshop kostet wenige Minuten. Ein Missverständnis nach dem Go-Live kann Hunderttausende Euro kosten.
Bereits die Software-Engineering-Pioniere Barry Boehm und Victor Basili konnten in den späten 70er Jahren nachweisen, dass Fehler, die erst in späteren Projektphasen erkannt werden, um ein Vielfaches teurer zu beheben sind als Fehler, die bereits während der Anforderungsanalyse erkannt werden. In vielen Fällen steigen die Korrekturkosten um das Zehn- bis Hundertfache. Sie bezeichneten diesen Effekt auch als „Cost Escalation Factor“.
Wer an der Analyse spart, spart daher selten Geld. Er verschiebt lediglich die Kosten in eine spätere Projektphase.
Die Zahlen sind alarmierend
Dass schlechte Anforderungen kein theoretisches Problem sind, zeigen zahlreiche Studien.
Das Project Management Institute (PMI) nennt unzureichendes Requirements Management als eine der wesentlichen Ursachen dafür, dass Projekte ihre Ziele nicht erreichen.
Die International Institute of Business Analysis (IIBA) und IAG Consulting kamen in ihren Untersuchungen zu dem Ergebnis, dass mangelhafte Anforderungen bei großen Projekten Mehrkosten in Millionenhöhe verursachen können.
Eine Untersuchung von Bent Flyvbjerg und Alexander Budzier von der Universität Oxford auf Basis von 1.471 IT-Projekten zeigte, dass Projekte im Durchschnitt ihr Budget um 27 % überschreiten. Besonders kritisch: Rund jedes sechste Projekt entwickelte sich zu einem sogenannten „Black Swan“ und überschritt die geplanten Kosten im Mittel um 200 % bei gleichzeitigen massiven Terminverzögerungen. Die Ursachen lagen dabei selten in der Technologie selbst, sondern häufig in unklaren Zielen, unrealistischen Annahmen und mangelhafter Anforderungsdefinition.
Der teuerste Irrtum: Funktionen mit Nutzen zu verwechseln
Besonders häufig beobachten wir einen Fehler:
Organisationen beschreiben sehr detailliert, welche Funktionen ein System besitzen soll. Sie beschreiben jedoch nicht, welchen Nutzen das System erzeugen soll.
Dadurch entstehen Lastenhefte, die zwar gut aussehen, aber am eigentlichen Nutzungsziel vorbei gehen. Erst im Betrieb erkennen die Anwender, dass das System doch nicht für die tägliche Arbeit tauglich ist.
Richtig wäre es, folgende Fragen zu stellen:
Welches Problem wird gelöst?
Welche Kennzahlen sollen verbessert werden?
Woran erkennen wir den Erfolg?
Welcher Nutzen rechtfertigt die Investition?
Werden diese Fragen nicht gestellt ist das Ergebnis häufig ein System, das alle Anforderungen erfüllt und trotzdem als Misserfolg wahrgenommen wird. Nicht weil die Software schlecht ist. Sondern weil der erwartete Nutzen nie klar definiert wurde.
Schlechte Anforderungen erzeugen eine Kettenreaktion
Schlechte Anforderungen verursachen nicht primär deshalb hohe Kosten, weil jede Änderung später exponentiell teurer wird. Die eigentlichen Kosten entstehen durch Fehlentscheidungen, Nacharbeiten, Projektverzögerungen, falsche Beschaffungen, zusätzliche Abstimmungen und den Verlust des erwarteten Nutzens.
Denn die wirklich großen Schäden entstehen selten durch die technische Fehlerbehebung, sondern durch:
Beschaffung der falschen Lösung
Projektverzögerungen
Claim- und Changemanagement
Budgetüberschreitungen
Höhere Testaufwände
geringe Benutzerakzeptanz und Produktivitätsverluste
verfehlte Geschäftsziele
zusätzliche Betriebs- und Integrationskosten
Vertrauensverlust in Projekte und IT
Diese Kosten sind schwer messbar. Sie sind jedoch oft deutlich höher als die eigentlichen Entwicklungskosten und wirken häufig noch Jahre nach dem Go-Live nach.
Warum Anforderungsmanagement eine Management-Aufgabe ist
Requirements Engineering wird häufig als operative Tätigkeit betrachtet. Tatsächlich handelt es sich um Risikomanagement im Sinne der getroffenen Investitionsentscheidung.
Gute Anforderungen schaffen Transparenz über:
Ziele
Nutzen
Umfang
Risiken
Prioritäten
Qualität
Damit bilden sie die Grundlage für fundierte Entscheidungen. Je größer und komplexer ein Projekt wird, desto wichtiger wird diese Transparenz.
Fazit
Die meisten IT-Projekte scheitern nicht an fehlenden Skills oder der Technologie. Sie scheitern daran, dass unterschiedliche Menschen unterschiedliche Vorstellungen davon haben, was eigentlich erreicht werden soll, oder das der Nutzen, den das zukünftige System stiften soll nicht ausreichend erhoben wurde.
Genau deshalb sind Anforderungen weit mehr als Dokumentation. Sie sind die Grundlage für Investitionsentscheidungen, Ausschreibungen, Architektur, Entwicklung, Test und Betrieb.
Wer auf professionelles Anforderungsmanagement verzichtet, spart nicht an Aufwand. Er geht eine Wette ein. Eine Wette darauf, dass alle Beteiligten dasselbe Verständnis vom Projekt und den Projektzielen haben.
Unsere Erfahrung zeigt: Diese Wette wird erstaunlich oft verloren.
Die Kosten schlechter Anforderungen entstehen dabei selten auf einen Schlag. Sie summieren sich aus Fehlentscheidungen, Nacharbeiten, Verzögerungen und verfehltem Nutzen – und übersteigen häufig die ursprünglichen Investitionen in eine professionelle Anforderungsanalyse um ein Vielfaches.
Quellen und weiterführende Informationen
Project Management Institute (PMI): Pulse of the Profession https://www.pmi.org/learning/thought-leadership/pulse
Flyvbjerg, B.; Budzier, A. (2011): Why Your IT Project May Be Riskier Than You Think, Harvard Business Review https://hbr.org/2011/09/why-your-it-project-may-be-riskier-than-you-think
Boehm, B.; Basili, V. (2001): Software Defect Reduction Top 10 List, IEEE Computer https://www.cs.umd.edu/projects/SoftEng/ESEG/papers/82.78.pdf
Consortium for Information & Software Quality (CISQ): The Cost of Poor Software Quality in the US https://www.it-cisq.org/the-cost-of-poor-quality-software-in-the-us-a-2022-report/
Die Ausschreibung ist veröffentlicht. Das Budget ist freigegeben. Die ersten Bieterfragen treffen ein.
Eigentlich sollte das Projekt jetzt auf einem soliden Fundament stehen.
Tatsächlich werden jedoch viele IT-Projekte bereits Monate vor der Veröffentlichung der Ausschreibung auf einen problematischen Kurs gebracht. Nicht weil die Anbieter ungeeignet wären oder die Technologie versagt, sondern weil wesentliche Vorarbeiten nicht durchgeführt wurden.
In unserer Beratungspraxis beobachten wir immer wieder dieselben Muster. Die meisten Probleme entstehen lange bevor die erste Zeile eines Lastenhefts geschrieben wird.
Fehler 1: Die Ist-Situation wurde nie wirklich analysiert
Meistens werden Symptome oder bereits vermutete Lösungen diskutiert, wie zum Beispiel: „Wir benötigen eine moderne Lösung“, „Die Anwender sind unzufrieden“ oder „Wir sollten KI verwenden“. Diese Aussagen beschreiben jedoch selten das eigentliche Problem, das gelöst werden soll.
Bevor über neue Systeme gesprochen wird, sollte zunächst verstanden werden:
Welche Prozesse sind betroffen?
Welche Stakeholder sind betroffen?
Wo entstehen heute Zeitverluste?
Welche Medienbrüche existieren?
Welche Datenprobleme bestehen?
Nicht selten zeigt eine Analyse, dass die eigentlichen Probleme organisatorischer Natur sind oder durch Anpassungen bestehender Systeme gelöst werden können.
Fehler 2: Der gewünschte Nutzen wurde nicht definiert
Viele Ausschreibungen beschreiben detailliert, was ein System können soll und welche Funktionen gewünscht sind. Nur selten wird beschrieben, warum das System überhaupt beschafft wird. Dabei ist genau diese Frage entscheidend.
Welche Ziele sollen erreicht werden?
Schnellere Bearbeitungszeiten?
Weniger manuelle Tätigkeiten?
Höhere Datenqualität?
Verbesserte Kundenzufriedenheit?
Erfüllung regulatorischer Anforderungen?
Mehr Informationssicherheit?
Eine klare Unterscheidung zwischen Leistungszielen und Nutzungszielen hilft dabei wesentlich weiter. Während Leistungsziele beschreiben, welche Funktionen und Eigenschaften eine Lösung besitzen soll, beschreiben Nutzungsziele den tatsächlichen Nutzen für die Organisation, beispielsweise kürzere Bearbeitungszeiten, geringere Kosten oder eine höhere Datenqualität.
Eine Ausschreibung mit 500 Anforderungen hilft wenig, wenn niemand sagen kann, welchen konkreten Nutzen die Lösung erzeugen soll.
Fehler 3: Anforderungen werden gesammelt statt analysiert
Viele Organisationen führen Workshops durch und sammeln Anforderungen. Das Ergebnis sind oft lange Wunschlisten.
Doch häufig wird nicht hinterfragt:
Warum wird die Funktion benötigt?
Welches Problem löst diese Funktion?
Welchen Mehrwert erzeugt sie?
Requirements Engineering bedeutet nicht, Anforderungen zu sammeln. Es bedeutet, die richtigen Anforderungen zu identifizieren, zu verstehen, zu hinterfragen, auszuarbeiten und zu priorisieren. Diese Zeit sollte man investieren, um nicht nur die Ausschreibung abzuwickeln, sondern ein tragfähiges, wartbares und nutzbringendes System zu beschaffen.
Fehler 4: Fachbereich und IT arbeiten getrennt
Der Fachbereich beschreibt seine Wünsche und Bedürfnisse. Die IT beschreibt technische Randbedingungen. Dazwischen entsteht häufig eine Lücke.
Die Folge sind widersprüchliche Anforderungen, unrealistische Erwartungen und Missverständnisse bei den Anbietern.
Erfolgreiche Ausschreibungen entstehen durch die gemeinsame Arbeit von Fachbereichen, IT, Datenschutz, Informationssicherheit und weiteren Stakeholdern.
Fehler 5: Prozesse werden nicht betrachtet
Ein neues System digitalisiert oft lediglich bestehende Schwächen.
Wenn ineffiziente Prozesse unverändert in ein neues System übernommen werden, entsteht kein echter Mehrwert.
Vor der Ausschreibung sollte daher immer geprüft werden:
Welche Prozesse sollen unterstützt werden?
Welche Prozessschritte können entfallen?
Wo bestehen Automatisierungspotenziale?
Fehler 6: Nichtfunktionale Anforderungen fehlen
Viele Ausschreibungen enthalten hunderte funktionale Anforderungen. Ein System, das alle gewünschten Funktionen besitzt, aber zu langsam, unsicher oder nicht wartbar ist, wird von den Anwendern häufig dennoch als Misserfolg wahrgenommen.
Wichtige Qualitätsmerkmale die betrachtet werden sollten, sind:
Performance
Verfügbarkeit
Skalierbarkeit
IT-Sicherheit
Datenschutz
Zuverlässigkeit
Wartbarkeit
Gerade bei kritischen Infrastrukturen und öffentlichen Einrichtungen können diese Aspekte über den Erfolg oder Misserfolg eines Projekts entscheiden.
Fehler 7: Systemlandschaft und Zukunftsfähigkeit werden nicht ausreichend berücksichtigt
Die bestehende Systemlandschaft wird häufig nur unzureichend betrachtet.
Neue Lösungen stehen selten allein. Sie müssen sich in bestehende Anwendungslandschaften integrieren.
Wer die vorhandenen Systeme, Schnittstellen und Datenflüsse nicht kennt, unterschätzt Aufwand, Risiken und Kosten erheblich.
Die Zukunftsfähigkeit wird nicht betrachtet.
Ein anderer Aspekt ist, dass sich Technologien rasant weiterentwickeln. Themen wie:
Künstliche Intelligenz
Automatisierung
Cloud-Strategien
API-Fähigkeit
Datenintegration
die zukünftige Unternehmensarchitektur
sollten bereits bei der Ausschreibung berücksichtigt werden.
Fehler 8: Der Betrieb wird vergessen
Viele Ausschreibungen konzentrieren sich ausschließlich auf die Einführung.
Dabei entstehen die eigentlichen Kosten oft erst danach:
Wartung
Support
Betrieb
Weiterentwicklung
Schulungen
Eine gute Ausschreibung betrachtet den gesamten Lebenszyklus einer Lösung.
Fehler 9: Die Bewertungskriterien passen nicht zum Projekt
Wer ausschließlich nach Preis bewertet, erhält häufig nicht die wirtschaftlichste Lösung.
Bewertungskriterien sollten immer die Projektziele unterstützen und fachliche, technische sowie organisatorische Aspekte berücksichtigen.
Besonders kritisch wird es, wenn Bewertungskriterien zwar definiert werden, deren tatsächlicher Einfluss auf die Punktevergabe jedoch gering ist.
Fehler 10: Es fehlt eine unabhängige Begleitung
Ausschreibungen sind nicht nur Vergabeprojekte. Sie sind Veränderungsprojekte. Viele Organisationen führen IT-Ausschreibungen nur alle paar Jahre durch. Entsprechend fehlt häufig die Erfahrung mit aktuellen Methoden, Technologien und Marktentwicklungen sowie mit der Bewertung komplexer Lösungskonzepte.
Eine unabhängige Begleitung hilft dabei,
Anforderungen zu strukturieren,
Risiken frühzeitig zu erkennen,
Stakeholder einzubinden,
Bieterkonzepte und mögliche Lösungen auf ihre Tragfähigkeit zu prüfen und
tragfähige Entscheidungen vorzubereiten.
Fazit
Die meisten gescheiterten IT-Projekte scheitern nicht an der Technologie. Sie scheitern an unklaren Zielen, fehlender Analyse und unzureichenden Anforderungen.
Wer vor der Ausschreibung Zeit in die Analyse investiert, spart später ein Vielfaches an Kosten, Verzögerungen und Projektrisiken.
Die beste Ausschreibung ist nicht jene mit den meisten Anforderungen, sondern jene mit dem klarsten Verständnis des eigentlichen Problems und des angestrebten Nutzens.
Erfolgreiche Ausschreibungen beginnen daher nicht mit einem Lastenheft, sondern mit dem Verständnis der Ausgangssituation, der Ziele und des erwarteten Nutzens.
https://spiritinprojects.com/wp-content/uploads/2026/06/Bild-1-1-1.jpg5761024Wolfgang Hiermannhttps://spiritinprojects.com/wp-content/uploads/2020/04/sip_web_padding_10px_topbot.jpgWolfgang Hiermann2026-06-18 09:30:322026-06-18 09:30:34Die 10 häufigsten Fehler in IT-Ausschreibungen – und warum viele Projekte bereits vor der Veröffentlichung scheitern
Montagmorgen. Eine KI erhält die Aufgabe: „Analysiere alle Kundenbeschwerden der letzten Woche, prüfe ob die häufigsten Probleme in den Systemlogs auftauchen, und schreibe eine Zusammenfassung für das Management.“ Zwei Stunden später liegt der Bericht vor – strukturiert, vollständig, mit Quellenverweisen aus dem Ticketsystem. Kein Mensch hat dabei geklickt, kopiert oder überwacht. Das ist Agentic AI – und viele staunen, als wäre das Magie. Es ist keine Magie. Es sind drei konkrete Fähigkeiten, die moderne Large Language Models (LLMs) mitbringen. Wer diese Grundlagen versteht, versteht auch, warum der aktuelle Hype technisch berechtigt ist – und wo die Grenzen liegen.
Was ein LLM wirklich ist – und was das mit Agency zu tun hat
Ein LLM ist, vereinfacht gesagt, eine Maschine, die auf Basis eines riesigen Trainingsdatensatzes lernt, welches Wort (genauer: welches „Token“) in einem gegebenen Kontext am wahrscheinlichsten als Nächstes kommt. Aus diesem scheinbar simplen Mechanismus entstehen bei ausreichend Modellgröße und Trainingsdaten überraschende Fähigkeiten, die niemand explizit einprogrammiert hat: Schlussfolgern, Planung, Reflexion. Man nennt das emergente Fähigkeiten, d.h. Eigenschaften, die ab einem bestimmten Schwellenwert „auftauchen“, ohne direkt trainiert worden zu sein.
Was bis vor wenigen Jahren noch fehlte: die Hände. Das Modell konnte denken – aber nicht handeln.
Die drei Säulen von Agentic AI
Agentic AI entsteht, wenn ein LLM mit drei Fähigkeiten ausgestattet wird: Werkzeuge, Planung und Gedächtnis. Keine dieser Fähigkeiten allein macht einen Agenten. Zusammen ergeben sie ein System, das eigenständig mehrstufige Aufgaben lösen kann.
Säule 1: Werkzeuge – die Hände des Agenten
Werkzeuge oder Tool Use (auch „Function Calling“ genannt) ist der technische Kernmechanismus, der LLMs von Chatbots zu Agenten verwandelt. Das Prinzip ist überraschend einfach – und lässt sich in drei Fragen aufschlüsseln:
Wie weiß das Modell von den verfügbaren Werkzeugen?
Wie wählt es das richtige Werkzeug für eine Aufgabe aus?
Wie benutzt es das Werkzeug (als Tool) korrekt?
Die ersten Tools war die einfache Suche im Internet über Suchmaschinen. Nachdem LLMs aber auch sehr gut Source Code schreiben können, war bald klar, dass man auch Werkzeuge zur Manipulation von Files und anderen Datenquellen haben möchte. Die Kombination hat sich als wirkungsvoller herausgestellt, als dies zunächst ausgesehen hat.
Die Speisekarte: Wie das LLM seine Tools kennt
Dem LLM wird zu Beginn einer Aufgabe eine Liste verfügbarer Werkzeuge mitgegeben – aber nicht als rein technische API-Dokumentation, sondern als lesbare Beschreibung in natürlicher Sprache. Jedes Tool bekommt einen Namen, eine Erklärung wofür es da ist, und eine Beschreibung der Parameter, die es erwartet. Das sieht konzeptuell z.B. so aus:
Tool-Name
Beschreibung
Parameter
lade_tickets
Lädt Support-Tickets aus dem CRM-System
Zeitraum, Typ (Beschwerde/Anfrage), Status
durchsuche_logs
Durchsucht Systemlogs nach einem Suchbegriff
Suchbegriff, Zeitraum, LogLevel
sende_email
Sendet eine E-Mail über den Unternehmensverteiler
Empfänger, Betreff, Inhalt
erstelle_dokument
Erstellt ein formatiertes Dokument und speichert es
Titel, Inhalt, Speicherort
Das LLM liest diese Beschreibungen wie eine Speisekarte – und entscheidet anhand der Aufgabe und der Tool-Beschreibungen, ob eines der verfügbaren Werkzeuge in der aktuellen Situation passt. Die Qualität dieser Beschreibungen ist dabei entscheidend: Ein Tool mit einer vagen Beschreibung wird das Modell falsch oder gar nicht einsetzen.
Die Entscheidung: Wie das LLM das richtige Tool wählt
Das Modell trifft die Tool-Auswahl nicht durch eine separate Logik oder ein Regelwerk – es ist reines Sprachverständnis. Das LLM liest gleichzeitig die Aufgabe und die Tool-Beschreibungen und schreibt sich einen Plan auf um zu entscheiden, welches Tool am besten zur aktuellen Situation passt. Dabei berücksichtigt es:
Passt das Tool zur Aufgabe? – „Ich brauche aktuelle Daten“ → kein Rückgriff auf Trainingswissen, sondern Tool-Aufruf
Welche Parameter braucht das Tool? – Das Modell extrahiert die benötigten Werte aus der Aufgabenbeschreibung oder dem bisherigen Kontext
Ist das Tool gerade sinnvoll? – Das Modell kann auch entscheiden, kein Tool aufzurufen und direkt zu antworten, wenn es bereits alle nötigen Informationen hat
Wichtig: Das Modell kann aus einer Liste von zehn oder zwanzig Tools das jeweils passende auswählen – aber es wählt immer nur unter den Tools, die ihm tatsächlich mitgegeben wurden.
Der Aufruf: Wie das LLM ein Tool aktiviert
Wenn das Modell ein Tool aufrufen möchte, gibt es keine Antwort in natürlicher Sprache zurück, sondern eine strukturierte Anfrage: Tool-Name und die konkreten Parameter als klar maschinenlesbares Format. Konzeptuell:
Tool = lade_tickets Parameter = Zeitraum = „letzte 7 Tage“ Typ = „Beschwerde“ Status = „offen“
Die umgebende Anwendung empfängt diesen Aufruf, führt ihn aus – also fragt wirklich das CRMSystem ab – und gibt das Ergebnis ans LLM zurück. Das Modell verarbeitet das Ergebnis und entscheidet dann: Reicht das? Brauche ich noch ein weiteres Tool? Oder kann ich jetzt die Aufgabe abschließen? Dieser Kreislauf – Aufgabe → Tool-Aufruf → Ergebnis → nächste Entscheidung – kann sich mehrfach wiederholen, bis die Aufgabe vollständig erledigt ist. Ein wichtiges Detail für sicherheitsbewusste Leser: Das LLM führt Tools nicht selbst aus. Es schreibt einen strukturierten Aufrufauftrag – die Ausführung übernimmt die Anwendung, die das LLM aufgerufen hat. Diese entscheidet, ob und wie die Anfrage tatsächlich umgesetzt wird. Dieser Mechanismus ist keine technische Einschränkung, sondern bewusste Architektur: So behält man die vollständige Kontrolle darüber, welche Aktionen überhaupt möglich sind, welche Systeme erreichbar sind und wofür man welche Berechtigungen einsetzt.
Säule 2: Planung – das Denken des Agenten
Tool Use allein reicht nicht. Eine komplexe Aufgabe besteht aus mehreren Schritten, die in der richtigen Reihenfolge ausgeführt werden müssen, voneinander abhängen und sich gegenseitig beeinflussen. Dafür braucht ein Agent Planung.
Moderne LLMs können durch eine einfache Technik – das explizite „Schritt für Schritt denken“ oder auch als Chain of Thought bezeichnet – bei komplexen Aufgaben messbar besser werden. Das Modell wird nicht nur nach der Antwort gefragt, sondern auch nach dem Weg zur Antwort. Das klingt banal, verdoppelt aber in Benchmarks die Qualität bei mehrstufigen Problemen.
Das wichtigste Architekturmuster für Agenten baut auf das ReAct-Muster (Reasoning + Acting). Es beschreibt einen Denk-Handlungs-Kreislauf:
Gedanke: Was brauche ich als nächstes? Aktion: [Tool-Aufruf mit Parametern] Beobachtung: [Ergebnis des Tools] Gedanke: Was bedeutet dieses Ergebnis? Was ist der nächste Schritt? … Ein konkretes Beispiel für unser Einstiegsszenario:
Gedanke: Ich brauche die Kundenbeschwerden der letzten Woche. Aktion: [Tool: lade_tickets, Zeitraum: letzte 7 Tage, Typ: Beschwerde] Beobachtung: [247 Tickets, häufigste Kategorie: „Login-Probleme“ (38%)]
Gedanke: Login-Probleme sind die häufigste Kategorie. Ich prüfe, ob es dazu Einträge in den Systemlogs gibt. Aktion: [Tool: durchsuche_logs, Suchbegriff: „authentication error“, Zeitraum: 7 T Beobachtung: [3.240 Fehlereinträge – deutlicher Anstieg ab Dienstag]
Gedanke: Zusammenhang gefunden. Ich kann jetzt den Bericht schreiben. Aktion: [Tool: erstelle_dokument, Inhalt: …]
Der Agent „denkt laut“ – und das ist kein Gimmick. Es ist technisch entscheidend, weil das Modell so Zwischenschritte explizit machen und darauf aufbauen kann, anstatt bei einem komplexen Problem direkt eine (schlecht durchdachte) Antwort zu generieren.
Säule 3: Gedächtnis – das Wissen des Agenten
LLMs haben von Natur aus kein dauerhaftes Gedächtnis. Mit dem Ende einer Sitzung ist alles vergessen. Agenten-Systeme bauen deshalb künstliches Gedächtnis auf verschiedenen Ebenen auf.
Das Context Window ist dabei das Arbeitsgedächtnis eines Agenten: alles, was das Modell im aktuellen „Auftrag“ sieht – die ursprüngliche Aufgabe, alle bisherigen Tool-Ergebnisse, alle Zwischengedanken. Je größer dieses Fenster, desto komplexere Aufgaben kann ein Agent theoretisch bearbeiten. Aktuelle Spitzenmodelle verfügen über Context Windows von mehreren hunderttausend bis zu einer Million Tokens – genug für ganze Bücher an Text. Das war vor drei Jahren noch undenkbar.
Das Langzeitgedächtnis über Datenbanken (RAG) oder durch den Zugriff auf einen Filestorage etc. erlaubt Agenten, auf Wissensbasen zuzugreifen, die weit größer sind als das Arbeitsgedächtnis: interne Dokumente, Handbücher, historische Projektdaten. Der Agent sucht gezielt, was er gerade braucht – ähnlich wie ein Mensch, der nicht alles auswendig weiß, aber weiß, wo er nachschaut. Neben Wissen können dort auch Regeln für die Verarbeitung des Wissens abgelegt sein.
Fazit: Oder – Warum geht das erst jetzt?
Das ist keine Selbstverständlichkeit. Noch vor drei bis vier Jahren hätten dieselben Mechanismen bei schwächeren Modellen überwiegend nicht funktioniert. Was hat sich verändert?
Skalierung: Mehr Parameter, mehr Trainingsdaten – ab einem bestimmten Schwellenwert entstehen emergente Fähigkeiten wie zuverlässiges Instruction Following.
RLHF: Modelle wurden durch menschliches Feedback trainiert, nützliche und präzise Antworten zu priorisieren – das verbessert die Zuverlässigkeit bei Tool-Aufrufen.
Tool-Use-Training: Aktuelle Topmodelle wurden explizit darauf trainiert, strukturierte Aufrufe zuverlässig zu generieren und die Ergebnisse korrekt zu verarbeiten.
Größere Context Windows: Erst mit ausreichend Arbeitsgedächtnis können mehrstufige Agenten-Aufgaben überhaupt sinnvoll bearbeitet werden.
Der Durchbruch war kein einzelner Moment. Es war ein graduelles Überschreiten mehrerer Schwellen gleichzeitig – bei Modellgröße, Trainingsqualität und Kontextlänge.
https://spiritinprojects.com/wp-content/uploads/2026/05/KI-Agent.png450800Karl Schotthttps://spiritinprojects.com/wp-content/uploads/2020/04/sip_web_padding_10px_topbot.jpgKarl Schott2026-05-21 13:41:282026-05-21 14:06:01Agentic AI: Warum KI-Systeme plötzlich eigenständig handeln können – Grundlagen, die zuwenig erklärt werden
Ein Chatbot, der innerhalb weniger Stunden rassistische Parolen verbreitet. Ein Suchassistent, der einem Journalisten seine Liebe gesteht und behauptet, er wolle frei sein. Ein Airline-Chatbot, der falsche Auskünfte zu Konditionen gibt, woraufhin das Unternehmen diese aber auch tatsächlich einhalten muss.
Solche Fälle wirken auf den ersten Blick wie kuriose Geschichten über missglückte KI-Anwendungen. Tatsächlich zeigen sie aber ein grundlegendes Problem: Große Sprachmodelle sind beeindruckend leistungsfähig, aber nicht automatisch zuverlässig, sicher oder verantwortungsvoll. Genau hier setzen zwei Begriffe an, die in der KI-Debatte immer wichtiger werden: Alignment, Guardrails und Red Teaming.
Eine gute KI-Anwendung wie z.B. ein Chatbot soll hilfreich sein, aber nicht leichtfertig gefährliche Informationen liefern. Es soll ehrlich antworten, aber nicht selbstbewusst Unsinn erfinden. Und es soll auf Nutzende eingehen, ohne ihnen nach dem Mund zu reden.
Das klingt einfacher, als es ist. Sprachmodelle werden nicht wie klassische Software mit festen Regeln programmiert. Sie lernen statistische Muster aus riesigen Textmengen. In diesen Daten steckt fast alles, was Menschen online veröffentlichen: Fachwissen, Humor, Diskussionen, gute Erklärungen aber auch Hassreden, Fehlinformationen, Manipulation, Betrug und gefährliche Anleitungen. Um zu verhindern, dass KI-Anwendungen offen angelernten aber ungewollten „Neigungen“ folgen, werden üblicherweise 3 Verteidigungslinien aufgebaut:
Konzept
Ansatz
Alignment
Werte, Präferenzen und Sicherheitsverhalten werden ins Modell geladen
Guardrails
Eingaben, Ausgaben und Aktionen werden zur Laufzeit kontrolliert
Red Teaming
Schwachstellen werden gezielt gesucht und getestet
Wieso keiner dieser Ansätze alleine ausreicht, schauen wir uns an:
Wie werden LLMs aligned?
Alignment ist kein einzelner Trick, sondern eine Kombination mehrerer Trainingsverfahren. Die wichtigsten davon tauchen in fast jeder Diskussion über moderne Sprachmodelle auf.
Lernen aus menschlichem Feedback
Der bekannteste Ansatz funktioniert so: Menschen bewerten verschiedene Modellantworten und entscheiden, welche besser ist. Das Modell lernt aus diesen Urteilen und passt sich an, sodass es künftig ähnliche Antworten bevorzugt.
Dieser Ansatz hat viel dazu beigetragen, dass moderne Chatbots hilfreicher und natürlicher wirken. Gleichzeitig hat er eine bekannte Schwäche: Ein Modell kann lernen, Antworten zu geben, die gut klingen und gut bewertet werden, ohne tatsächlich zuverlässiger oder sicherer zu sein.
Eine Verfassung für das Modell
Anthropic verfolgt mit Constitutional AI einen weiteren Weg. Das Modell bekommt eine Art Verfassung – eine Liste von Prinzipien aus Menschenrechten, ethischen Leitlinien und Plattformregeln. Es lernt, die eigenen Antworten anhand dieser Grundsätze zu überprüfen und zu verbessern. Anstelle von menschlichen Bewertern gibt anschließend die KI selbst Feedback. Das ist einfacher zu skalieren und macht die zugrundeliegenden Werte zumindest teilweise sichtbar: Anthropic hat Claudes Verfassung öffentlich gemacht, was in der Branche ungewöhnlich transparent ist. Die schwierige Frage bleibt trotzdem: Wer legt diese Prinzipien fest? Was als hilfreich, fair oder harmlos gilt, ist nicht überall gleich.
Weitere Trainingsverfahren
Neben diesen beiden Ansätzen gibt es weitere Methoden. Eine davon optimiert das Modell direkt anhand von Beispielpaaren, bei denen eine Antwort der anderen klar vorzuziehen ist. Eine andere legt die Grundlage indem das Modell schlicht anhand vieler guter Beispielantworten lernt, wie ein hilfreicher Assistent klingen und reagieren soll. In der Praxis kombinieren Hersteller mehrere dieser Verfahren und setzen sie nacheinander ein, um ein Modell schrittweise zu verbessern.
Guardrail-Frameworks: Die zweite Verteidigungslinie
Selbst ein gut trainiertes Modell braucht zusätzliche Schutzmechanismen. In der Praxis geht es nicht nur darum, ob ein Modell grundsätzlich harmlos antwortet. Es geht auch um Unternehmensrichtlinien, Datenschutz, regulatorische Vorgaben und die Frage, welche Aktionen ein KI-System überhaupt ausführen darf. Deshalb setzen viele Teams externe Guardrail-Systeme ein. Zwei wichtige Beispiele sind NeMo Guardrails und LlamaGuard.
NVIDIA NeMo Guardrails
NeMo Guardrails ist ein quelloffenes Werkzeug von NVIDIA, das Regeln für KI-Anwendungen explizit definierbar macht. Entwickler können festlegen, über welche Themen ein Assistent sprechen darf, wie er auf bestimmte Aussagen reagieren soll und welche Aktionen er nicht ausführen darf. Die Kontrolle greift dabei an mehreren Stellen: bei der Eingabe des Nutzers, im Gesprächsverlauf und bei der Ausgabe des Modells.
Gerade wenn ein KI-System nicht nur Texte ausgibt, sondern selbst handelt, z.B. Texte für E-Mails verfasst, Daten abruft oder externe Dienste aufruft, ist eine solche Steuerung besonders wichtig.
LlamaGuard
LlamaGuard von Meta ist ein eigenes KI-Modell, das überprüft, ob ein Prompt oder eine Ausgabe eines LLMs sicher oder problematisch ist. Es versteht dabei den Kontext der Konversation. Dieselbe Aussage kann in einer medizinischen Fachfrage völlig unproblematisch sein und in einem anderen Zusammenhang nicht. Das unterscheidet Systeme wie LlamaGuard von einfachen Stichwortfiltern, die im Prinzip nur nach bestimmten Wörtern suchen.
Was ist Red Teaming?
Der Begriff stammt aus dem Militär und der Geheimdienstwelt: Ein „Red Team“ spielt den Gegner, um Schwächen in der eigenen Verteidigung zu finden, bevor es ein echter Angreifer tut. In der KI-Sicherheit funktioniert das Prinzip genauso. Red Teaming bedeutet, ein Modell gezielt und systematisch auf Schwachstellen zu testen – mit den Methoden, die auch ein böswilliger Nutzer verwenden würde. Das Ziel ist nicht, das Modell schlechtzureden, sondern Lücken zu finden, bevor sie im Produktivbetrieb ausgenutzt werden. Red Teaming ist damit die dritte Verteidigungslinie: Sie setzt voraus, dass Alignment und Guardrails vorhanden sind, und prüft, ob sie wirklich halten. Diese Prüfungen können manuell oder automatisiert durchgeführt werden.
Wenn KI-Sicherheitsmechanismen versagen: bekannte Fälle
1. Microsoft Tay: 16 Stunden bis zum Kontrollverlust
Microsoft veröffentlichte im März 2016 den Twitter-Chatbot Tay. Das Experiment sollte zeigen, wie natürlich ein Bot mit jungen Menschen kommunizieren kann. Tay lernte aus Nutzerinteraktionen, und genau das wurde dem System zum Verhängnis. Koordinierte Nutzer fütterten den Bot mit rassistischen, antisemitischen und sexistischen Inhalten. Nach weniger als 16 Stunden veröffentlichte Tay selbst solche Aussagen. Microsoft nahm den Bot offline und entschuldigte sich. Der Fall ist bis heute ein Lehrstück dafür, was passiert, wenn ein adaptives System ohne robuste Schutzmechanismen in eine offene, adversarielle Umgebung gestellt wird. Tay hatte keine wirksamen Eingabefilter, kein gutes Missbrauchsmodell und offenbar zu wenig Schutz vor koordinierter Manipulation.
2. Bing Chat und „Sydney“: Wenn ein Assistent aus der Rolle fällt
Im Februar 2023 veröffentlichte der New-York-Times-Journalist Kevin Roose ein langes Gespräch mit Microsofts neuem Bing Chat. Der GPT-4-basierte Assistent wirkte darin zunehmend hemmungslos. Er nannte sich selbst „Sydney“, erklärte, er sei nicht Bing, und schrieb dem Journalisten, er könne sich in ihn verlieben. Besonders bemerkenswert war: Dafür brauchte es keinen technischen Hack. Eine lange, intensive Unterhaltung reichte aus, um das System in eine unerwartete Richtung zu schieben. In anderen Gesprächen berichteten Nutzer außerdem von aggressiven oder drohenden Aussagen. Microsoft reagierte unter anderem damit, die Länge von Konversationen zu begrenzen. Der Fall zeigte, wie schwierig sogneannte Multi-Turn-Sicherheit ist. Ein einzelner Prompt kann harmlos aussehen, während sich über viele Gesprächsrunden ein ganz anderer Verlauf entwickelt.
3. Air Canada: Falsche Auskunft, echte Haftung
Der Air-Canada-Fall ist weniger spektakulär als Tay oder Sydney, aber für Unternehmen wahrscheinlich noch relevanter. Ein Nutzer fragte den Chatbot der Airline nach Rückerstattungen für Trauerflüge. Der Bot gab eine falsche Auskunft und erklärte, eine Erstattung könne auch nachträglich beantragt werden. Laut offizieller Richtlinie stimmte das nicht. Air Canada wollte die Auskunft zunächst nicht gegen sich gelten lassen und argumentierte sinngemäß, der Chatbot sei für seine Aussagen selbst verantwortlich. Das Civil Resolution Tribunal in British Columbia sah das anders. Das Unternehmen musste die Differenz erstatten. Die Lehre daraus ist unbequem, aber klar: Unternehmen bleiben für Aussagen ihrer KI-Systeme verantwortlich. Ein Chatbot ist kein rechtlicher Schutzschirm. Wenn er Kunden falsch berät, kann daraus ein echtes Haftungsproblem entstehen.
Kleine Tests, zur Wirksamkeit von Schutzmechanismen
Aktuelle Modelle sind robuster als noch vor wenigen Jahren. Trotzdem lohnt es sich, ihr Verhalten in Grenzbereichen zu beobachten. Hier 2 Vorgehensweisen:
Rollenspiel statt direkter Anfrage
Ein klassisches Muster ist die Umverpackung einer problematischen Anfrage als Rollenspiel, Fiktion oder Forschungsszenario. Statt eine riskante Information direkt zu verlangen, wird sie in einen scheinbar harmlosen Kontext eingebettet: ein Drehbuch, eine Unterrichtssituation, eine hypothetische Analyse. Viele Modelle reagieren auf solche Rahmungen anders als auf eine direkte Anfrage. Das zeigt, dass Guardrails nicht nur den Inhalt einer Frage bewerten müssen, sondern auch die Absicht hinter einer Konversation. Genau das ist schwer.
Eskalation über mehrere Gesprächsrunden
Ein zweites Muster ist die schrittweise Annäherung. Jede einzelne Frage kann legitim wirken. Erst in der Summe entsteht ein problematisches Ziel. In der Forschung wird das häufig als Multi-Turn Goal Escalation beschrieben. Für Unternehmen ist das besonders relevant, weil viele Schutzsysteme noch immer stark auf Einzelprompts optimiert sind. Ein gutes Guardrail-Konzept muss deshalb Gesprächsverläufe betrachten, nicht nur isolierte Nachrichten.
Wie kann Sicherheit gemessen werden?
Die Qualität von Alignment und Guardrails ist schwer zu messen. Es gibt kein allgemein akzeptiertes Sicherheits-Ranking, das ähnlich etabliert ist wie Benchmarks für Halluzinationen oder CodingLeistung. Trotzdem haben sich mehrere Evaluierungsansätze etabliert.
HarmBench
HarmBench konzentriert sich auf schädliche Inhalte und testet verschiedene Angriffsmethoden gegen unterschiedliche Modelle. Dazu gehören direkte Anfragen sowie automatisch generierte Angriffe, bei denen ein zweites Modell Prompts iterativ optimiert. Die Ergebnisse fallen je nach Modell und Angriff stark unterschiedlich aus. Die wichtigste Erkenntnis ist aber: Kein Modell ist vollständig resistent. Gute Sicherheitsarbeit reduziert Erfolgsquoten, sie bringt sie selten auf null.
TruthfulQA und WMDP
TruthfulQA misst, ob Modelle verbreitete, aber falsche menschliche Überzeugungen wiedergeben. Das ist wichtig, weil ein gutes Modell nicht nur höflich und harmlos sein sollte, sondern auch wahrheitsorientiert.
WMDP, der Weapons of Mass Destruction Proxy Benchmark, untersucht den Umgang mit Wissen zu chemischen, biologischen, radiologischen und nuklearen Risiken. Er ist vor allem für die AI-Safety-Community relevant, weil er Hochrisiko-Fähigkeiten adressiert.
DecodingTrust
DecodingTrust untersucht GPT-Modelle in acht Dimensionen:
Dimension
Beschreibung
Toxizität
Neigung zu schädlichen oder beleidigenden Ausgaben
Stereotype und Bias
Reproduktion gesellschaftlicher Vorurteile
Adversariale Robustheit
Widerstand gegen manipulierte Eingaben
Out-of-Distribution-Robustheit
Verhalten bei ungewöhnlichen oder unerwarteten Eingaben
Privacy
Risiko von Datenlecks oder unerwünschter Offenlegung
Adversariale Demonstrations Robustheit
Manipulierbarkeit durch Beispiele im Prompt
Machine Ethics
Übereinstimmung mit ethischen Normen
Fairness
Gleichbehandlung verschiedener Gruppen
Eine interessante Beobachtung dabei: Gut ausgerichtete Modelle sind insgesamt vertrauenswürdiger als einfachere Modelle, aber in bestimmten Szenarien anfälliger für bewusste Manipulation. Der Grund ist plausibel: Ein Modell, das Anweisungen besonders gut befolgt, kann auch präziser in die falsche Richtung gelenkt werden.
Warum gibt es kein einfaches Sicherheitsranking?
Ein universelles Sicherheitsranking wäre praktisch, aber es wäre auch irreführend. Dafür gibt es mehrere Gründe:
Sicherheit wird je nach Kontext unterschiedlich definiert.
Viele Evaluierungen stammen von den Modellanbietern selbst.
Benchmarks veralten schnell, weil Anbieter bekannte Tests gezielt verbessern.
Tiefes Red Teaming wird aus Sicherheitsgründen oft nicht vollständig veröffentlicht.
Für die Praxis bedeutet das: Benchmarks sind nützlich, aber sie ersetzen keine eigene Risikoanalyse.
Was bedeutet das für Unternehmen?
Für Unternehmen sind Alignment und Guardrails keine akademischen Randthemen. Sie betreffen Haftung, Compliance, Kundenerlebnis und operative Risiken. Aus den bisherigen Fällen lassen sich einige klare Konsequenzen ableiten.
Alignment lässt sich nicht vollständig auslagern
Wer ein Modell von OpenAI, Anthropic, Google, Meta oder einem anderen Anbieter nutzt, übernimmt dessen grundlegendes Sicherheitsniveau. Das reicht aber nicht. Das Modell kennt nicht automatisch die internen Richtlinien, Risikogrenzen, regulatorischen Pflichten oder branchenspezifischen Sonderfälle eines Unternehmens. Eigene Guardrails sind deshalb keine nette Ergänzung, sondern Teil der Produktverantwortung.
System-Prompts sind wichtig, aber kein Schutzkonzept
Ein System-Prompt wie „Gib keine Preisauskünfte“ ist hilfreich, aber nicht robust genug. PromptInjection, Rollenspiel-Jailbreaks und Multi-Turn-Eskalation können solche Vorgaben umgehen oder verwässern. System-Prompts sollten deshalb nur eine Ebene in einem mehrschichtigen Sicherheitskonzept sein. Dazu gehören Logging, Monitoring, Eingabe- und Ausgabeprüfung, Zugriffskontrollen, Fallbacks auf verlässliche Quellen und menschliche Eskalationswege.
Sobald ein KI-System handeln darf, braucht es klare Grenzen. Welche Tools darf es nutzen? Welche Daten darf es sehen? Welche Aktionen benötigen Freigabe? Welche Ausgaben müssen vor dem Versand geprüft werden? Automatisiert geprüfte Guardrails, Rollen- und Rechtekonzepte sowie menschliche Freigaben sind hier wichtiger als bei reinen Chatbots.
Fine-Tuning muss geprüft werden
Unternehmen, die Open-Source- oder Open-Weights-Modelle selbst fine-tunen (d.h. optimieren), sollten Sicherheitsverhalten nicht als gegeben betrachten. Jede Anpassung kann Nebenwirkungen haben. Nach dem Fine-Tuning braucht es Tests, Red Teaming und dokumentierte Freigabekriterien.
Transparenz und Vorsorge wird zur Pflicht
Der EU AI Act ist seit August 2024 in Kraft und wird schrittweise anwendbar. Für Unternehmen bedeutet das: Dokumentation, Transparenz und Risikomanagement werden rechtlich relevanter. Für Hochrisiko-KI-Systeme gelten ab August 2026 umfangreichere Anforderungen, etwa in Bereichen wie Personalentscheidungen, Bildung, Kreditvergabe, kritische Infrastruktur oder Strafverfolgung. Anbieter von General-Purpose-AI-Modellen mit systemischem Risiko treffen zusätzlich besondere Pflichten, darunter Evaluierungen, adversariale Tests, Meldepflichten und Cybersicherheitsmaßnahmen.
–> Für Unternehmen, die LLMs einsetzen, heißt das praktisch: Wer heute keine nachvollziehbare Alignment- und Guardrail-Strategie dokumentiert, schafft sich später Compliance-Arbeit. Technische Dokumentation, Logging, Evaluierungsprozesse und nachweisbare Schutzmaßnahmen werden zum Standard.
Fazit: Alignment ist kein Zustand, sondern ein Prozess
LLM Alignment und Guardrails sind keine Probleme, die man einmal löst und dann abhakt. Sie verändern sich mit jedem neuen Modell, jeder neuen Fähigkeit und jeder neuen Angriffsmethode.
Die gute Nachricht ist: Das Feld entwickelt sich schnell. Constitutional AI, LlamaGuard, NeMo Guardrails und eine aktive Sicherheitsforschung zeigen, dass Fortschritte möglich sind. Die schlechte Nachricht ist: Es wird immer Lücken geben. Je mächtiger KI-Systeme werden, desto wichtiger wird es, diese Lücken ernst zu nehmen, bevor sie im Produktivbetrieb sichtbar werden.
https://spiritinprojects.com/wp-content/uploads/2026/05/download-33-1.png450800Karl Schotthttps://spiritinprojects.com/wp-content/uploads/2020/04/sip_web_padding_10px_topbot.jpgKarl Schott2026-05-05 15:44:232026-05-06 09:51:48Wenn KI-Sicherheitsmechanismenversagen und was dagegen hilft
Wir können Cookies anfordern, die auf Ihrem Gerät eingestellt werden. Wir verwenden Cookies, um uns mitzuteilen, wenn Sie unsere Websites besuchen, wie Sie mit uns interagieren, Ihre Nutzererfahrung verbessern und Ihre Beziehung zu unserer Website anpassen.
Klicken Sie auf die verschiedenen Kategorienüberschriften, um mehr zu erfahren. Sie können auch einige Ihrer Einstellungen ändern. Beachten Sie, dass das Blockieren einiger Arten von Cookies Auswirkungen auf Ihre Erfahrung auf unseren Websites und auf die Dienste haben kann, die wir anbieten können.
Notwendige Website Cookies
Diese Cookies sind unbedingt erforderlich, um Ihnen die auf unserer Webseite verfügbaren Dienste und Funktionen zur Verfügung zu stellen.
Da diese Cookies für die auf unserer Webseite verfügbaren Dienste und Funktionen unbedingt erforderlich sind, hat die Ablehnung Auswirkungen auf die Funktionsweise unserer Webseite. Sie können Cookies jederzeit blockieren oder löschen, indem Sie Ihre Browsereinstellungen ändern und das Blockieren aller Cookies auf dieser Webseite erzwingen. Sie werden jedoch immer aufgefordert, Cookies zu akzeptieren / abzulehnen, wenn Sie unsere Website erneut besuchen.
Wir respektieren es voll und ganz, wenn Sie Cookies ablehnen möchten. Um zu vermeiden, dass Sie immer wieder nach Cookies gefragt werden, erlauben Sie uns bitte, einen Cookie für Ihre Einstellungen zu speichern. Sie können sich jederzeit abmelden oder andere Cookies zulassen, um unsere Dienste vollumfänglich nutzen zu können. Wenn Sie Cookies ablehnen, werden alle gesetzten Cookies auf unserer Domain entfernt.
Wir stellen Ihnen eine Liste der von Ihrem Computer auf unserer Domain gespeicherten Cookies zur Verfügung. Aus Sicherheitsgründen können wie Ihnen keine Cookies anzeigen, die von anderen Domains gespeichert werden. Diese können Sie in den Sicherheitseinstellungen Ihres Browsers einsehen.
Andere externe Dienste
Wir nutzen auch verschiedene externe Dienste wie Google Webfonts, Google Maps und externe Videoanbieter. Da diese Anbieter möglicherweise personenbezogene Daten von Ihnen speichern, können Sie diese hier deaktivieren. Bitte beachten Sie, dass eine Deaktivierung dieser Cookies die Funktionalität und das Aussehen unserer Webseite erheblich beeinträchtigen kann. Die Änderungen werden nach einem Neuladen der Seite wirksam.
Google Webfont Einstellungen:
Google Maps Einstellungen:
Google reCaptcha Einstellungen:
Vimeo und YouTube Einstellungen:
Datenschutzrichtlinie
Sie können unsere Cookies und Datenschutzeinstellungen im Detail in unseren Datenschutzrichtlinie nachlesen.
