Nachhaltigkeitsmanager

*„ChatGPT, was ist die Frage auf Antwort 42“* - *„Perplexity, wie kocht man Leaky, Leaky Soup“*  -*„Dall-E, generiere ein Bild im Stil von Monet, das eine Küstenlandschaft zeigt, in der Katzen auf Einhörnern die Dünen entlang reiten.“*

Jeder hat wahrscheinlich schon die plötzlich aufgetauchte, scheinbar unerschöpfliche Quelle des Wissens genutzt, um sie mit völlig irrelevanten, aber interessanten Fragen zu quälen. Die Rede ist natürlich von KI. 

Während wir mit den amüsanten Antworten herumalbern, springt irgendwo in Virginia ein Kohlekraftwerk aus der Reserve. Natürlich bietet KI ein gigantisches Potenzial in den unterschiedlichsten Bereichen: sei es in der Medizin, der Forschung, bei der Vorhersage von Stürmen, in der Archäologie oder ganz einfach bei der Optimierung von Geschäftsabläufen. KI revolutioniert die Art und Weise, wie wir arbeiten, leben oder forschen. Welche Dimension der Energiehunger von KI jedoch jetzt schon angenommen hat und wie man die Nutzung als User nachhaltiger gestaltet, erfahrt ihr in diesem Blogpost. 

### Training Training Training...

Damit wir solche fundamental wichtigen Fragestellungen an einen digitalen Gesprächspartner übergeben können, muss dieser jedoch erst einmal dafür trainiert werden. Das bedeutet, dass Algorithmen Milliarden von Datensätzen in sich aufsaugen und in gigantischen Rechenzentren wieder und wieder an Parametern geschraubt wird, bis das Modell schlussendlich dazu in der Lage ist, komplexe Sachverhalte zu verstehen und in geraden Sätzen auf unsere Fragen zu antworten. 

Für das Training von OpenAIs GPT-4 wurden laut externen Schätzungen rund 50 Gigawattstunden (GWh) an Energie benötigt – genug, um alle Büros der codecentric AG die nächsten 131 Jahre lang mit Strom zu versorgen. Diese Zahl bezieht sich allerdings ausschließlich auf den Energiebedarf des Trainingsprozesses selbst. Nicht berücksichtigt ist dabei der Bau der Rechenzentren, die Herstellung der spezialisierten Hardware wie GPUs und TPUs, oder die Umwelt- und Energiekosten für deren Rohstoffgewinnung, Transport usw.

Einblicke in die gesamten Emissionen liefert immerhin das Open-Source-Sprachmodell BLOOM, bei dem die Umweltbilanz detailliert offengelegt wurde. Daraus geht hervor, dass rund 22 % der gesamten CO₂-Emissionen eines KI-Modells nicht aus dem eigentlichen Training stammen, sondern aus vorgelagerten Prozessen wie dem Bau und der Herstellung der Infrastruktur. Dies umfasst zum Beispiel den Energieaufwand für die Produktion der hochspezialisierten Chips, deren Lieferketten oft über mehrere Kontinente reichen.

Abgesehen von den nicht unerheblichen Energie- und Rohstoffmengen sind Rechenzentren durstiger als jedes Oktoberfest. Millionen Liter Trinkwasser werden täglich für die Kühlung von KI-Rechenzentren genutzt, das dann größtenteils durch Verdunstung entweicht. In Anbetracht dessen, dass wir 2050 davon ausgehen müssen, dass etwa 5 Milliarden Menschen unter Wasserknappheit leiden werden, eine eher ungünstige Entwicklung. 

Betrachten wir dann die eigentliche Nutzung der Modelle, wird es nicht besser.

### Int.. Inf... Infer was? – Mit dem Modell reden

Sobald wir einen Prompt abschicken, beginnt die komplexe Rechenarbeit des Modells, die letztendlich in einer text-, bild- oder videobasierten Antwort endet. Dieser Ablauf wird als „Inferenz“ bezeichnet und ist die eigentliche Handlung des LLMs. Das Auswerten des Inputs, das Durchlaufen von Algorithmen und letztendlich die Formulierung eines Resultats. Wie energieintensiv dieser Vorgang ist, hängt von verschiedenen Faktoren ab:

**Art und Größe des Modells:** Je größer, komplexer und präziser ein Modell ist, desto größer ist auch der Energiebedarf, um eine Antwort zu generieren.

**Länge unseres Prompts:** Die KI zerlegt sämtliche Text-Ein- und Ausgaben in sogenannte „Tokens“. Dies ist die kleinste Einheit an Informationen, die von dem jeweiligen Modell zur Berechnung verwendet wird. Es kann ein einzelner Buchstabe oder eine Silbe, manchmal auch ein ganzes Wort sein. Je mehr solcher Tokens eine Anfrage enthält, desto größer wird der Energiebedarf für die Verarbeitung der Eingabe.

**Länge der Antwort:** Natürlich gilt dies auch für die Ausgabe. Hier ist der Effekt sogar noch drastischer. Je länger die Antwort des Modells ist, desto größer ist ihr Energieverbrauch. 

**Komplexität der Aufgabe:** Komplexe Aufgaben brauchen mehr Rechenleistung. Die Frage nach dem Geburtsdatum von Alan Turing (bevor ihr ChatGPT fragt, es ist der 23. Juni 1912) verbraucht viel weniger Energie als die Frage nach einem 4k-Werbespot für Spielzeug-Laserschwerter. 

**Infrastruktur:** Unabhängig von dem, was wir vom Modell verlangen, ist natürlich auch die verwendete Infrastruktur und die Anwendung von Optimierungstechniken relevant. Läuft das Modell auf einem zusammengeschusterten Server in einer amerikanischen Provinz, die ihre Stromversorgung hauptsächlich durch antiquierte Kohlekraftwerke sicherstellt, oder wird mit den modernsten Hightech-Prozessoren in der kühlen norwegischen Fjordlandschaft vor sich hin gerechnet?




**Doch wie hoch ist denn nun eigentlich der Energiebedarf für eine Anfrage?**

Gute Frage. Fakt ist, dass es aktuell niemand der großen Betreiber von KI-Modellen ernsthaft preisgeben will. Weder Google, noch Meta oder OpenAI sprechen offen über den Energiebedarf ihrer Modelle. Der Energiebedarf ist „Betriebsgeheimnis“. Sam Altman, der Gründer von OpenAI, hatte dieses Jahr immerhin bekannt gegeben, dass eine Anfrage an ChatGPT durchschnittlich 0,34 Wattstunden verbraucht, ohne näher zu erläutern, wie sich die Zahl zusammensetzt. 

0,34 Wattstunden - bei einem herkömmlichen 3-W-LED Leuchtmittel entspricht das immerhin einer Betriebsdauer von 6,8 Minuten. Mit 9 Anfragen am Tag könnte man also stattdessen auch sein Homeoffice für eine Stunde beleuchten. Klingt jetzt erstmal überschaubar. Für sich betrachtet ist das auch richtig, aber ratet mal welche Apps seit Monaten auf den ersten Plätzen der Download Charts stehen? Richtig, chatGPT, Perplexity und Co. sind beliebter als Instagram und TikTok. Allein chatGPT verzeichnet ca. **eine Milliarde Anfragen am Tag**. So werden aus 0,34 Wattstunden dann schnell mal 124 GWh pro Jahr. Damit könnte die codecentric AG die nächsten 327 Jahre alle Büro-Standorte betreiben. In Ländern ausgedrückt: Allein der Betrieb von ChatGPT macht etwa 30 Prozent des jährlichen Stromverbrauchs von Liechtenstein aus. Und das ist erst der Anfang.

Und natürlich ist eine einfache Anfrage nicht unbedingt die Regel. Komplexe mathematische Berechnungen, die Formulierung langer Texte oder das Analysieren und Zusammenfassen eben solcher kann schnell den Energieverbrauch um den Faktor 10 bis 100 oder sogar noch mehr ansteigen lassen. Interessanterweise liegt der Energieverbrauch zur Generierung von Bildern oftmals unterhalb dieser Werte. Modelle zur Textgenerierung arbeiten mit hunderten von Milliarden Parametern und verrichten zur Generierung ihrer Antwort häufig mehr Arbeit, als für die Erstellung eines Bildes in Standardqualität von 1024x1024 Pixel nötig ist. Schätzungen nach, liegen hier die Emissionen zwischen 0,6 und 1,2 Wh pro Bild, was meistens nicht an den Verbrauch einer komplexen Textaufgabe heranreicht.

### Ein Blick in die Kristallkugel

Sicher ist, dass unser jetziger KI-Fußabdruck der kleinste ist, den wir jemals haben werden. Alleine in den USA wollen Apple, OpenAI und Co. über eine Billion Dollar in KI und die dafür notwendige Infrastruktur stecken. Nochmal zur Verdeutlichung: 1.000.000.000.000$ Damit einher geht ein fast exponentielles Wachstum des Energie- und Ressourcenbedarfs. Aufgrund mangelnder Transparenz können die meisten Studien und Prognosen jedoch nur vage Vermutungen über die zukünftige Entwicklung abgeben. So wird geschätzt, dass bis 2027 die KI-Nachfrage nach Wasser in den USA auf 5,2 bis 6,6 Milliarden Kubikmeter ansteigen wird (das entspricht 13,2 Billionen Dosen Bier oder dem jährlichen Wasserbedarf Dänemarks). Was den Energiebedarf betrifft, können wir schon seit 2017 beobachten, dass der Stromverbrauch für IT-Infrastruktur vier mal so schnell ansteigt, wie der durchschnittliche Energiebedarf. Bis 2028 geht man davon aus, dass in den USA Rechenzentren für 12 % des gesamten Stromverbrauchs verantwortlich sein werden. Eine genaue Abschätzung ist jedoch schwer bis unmöglich, da nicht abzusehen ist, wie schnell und in welchen Bereichen AI Einzug in den Alltag finden wird. Ganz dem Titel dieses Blogposts nach, sehr wahrscheinlich „everywhere“. So klingt es nicht unwahrscheinlich, wenn andere Studien davon ausgehen, dass bis Ende des Jahrzehnts der Energiebedarf dem von ganz Japan entsprechen wird. 

Auch beim Thema Elektroschrott macht KI keine halben Sachen. Schätzungen zufolge werden zusätzliche 5 Millionen Tonnen Elektroschrott anfallen, die dann aufwändig recycelt werden müssen. Wen das Thema Elektroschrott interessiert, wird am ENde dieses Artikels fündig.

### Der eigene Fußabdruck

Zugeben: Das ist eine ganze Menge an negativen Superlativen, mit denen man die Entwicklung der KI betiteln kann. Milliarden Liter Wasser, Terawattstunden an Energie, Millionen Tonnen Müll... besser ist es, das Thema einmal für sich persönlich zu betrachten.

**Wie sieht der eigene KI-Fußabdruck aus? **

Nehmen wir mal an, wir schreiben werktags 10 „Standard“ Anfragen an ChatGPT, die die oben angesprochenen 0,34 Wattstunden an Energie und ca. 12ml Wasser verbrauchen. Zusätzlich schreiben wir 5 komplexe Anfragen mit dem 20-fachen Energie- und Wasserbedarf pro Tag. Bei 220 Arbeitstagen kommen wir auf 8,2 kWh und 290,4 Liter Wasser. Mit einem üblichen CO₂-Emissionsfaktor von 400g pro kWh summiert sich unser Fußabdruck grob auf ca. 3,28 kg CO₂ und 290,4 Liter Wasser pro Jahr. Das entspricht ungefähr dem CO₂-Ausstoß der Produktion eines einzelnen 240-g-Rumpsteaks. Hinsichtlich des Wasserverbrauchs reden wir dann nur noch von einer einzelnen Gabel Rumpsteak (19 g). 

Fazit: Wer sich umweltbewusst verhalten will, findet weitaus effizientere Hebel, als auf ein paar ChatGPT Anfragen zu verzichten, die einem dafür Stunden von Arbeit abnehmen würden. Man muss kein schlechtes Gewissen haben, wenn man mit KI seinen Arbeitsalltag effizienter gestaltet, da der eigene KI-Fußabdruck vergleichsweise gering ist. Viel Spannender ist es, die KI für etwas Positives einzusetzen. Überall findet KI bereits Einzug im Kampf gegen den Klimawandel, in der Forschung oder anderen Projekten.

Wer möchte, kann mit den nachfolgenden Tipps an seinem KI-Fußabdruck arbeiten, ohne sich großartig einschränken zu müssen.

### Tipps zum nachhaltigeren Umgang als Anwender
**Nutze sie dort, wo es sinnvoll ist:** Manche Dinge gehen einfach immer noch am schnellsten, wenn man sie selbst erledigt. Nutze KI-Helfer dort, wo sie dir einen echten Mehrwert bieten.

**Die Länge deines Prompts:** Jedes Wort einer Anfrage wird verarbeitet, weshalb ausführliche, ausschweifende Prompts den Energiebedarf unnötig erhöhen. Formuliere kurze, zielführende Anfragen, ohne groß herumzureden. 

**Die Länge der Antwort:** Eine Halbierung der Antwortlänge führt häufig ungefähr zu einer Halbierung der Emissionen. Formulierungen wie „Erläutere den Begriff in einem Satz“ oder „Fasse den Text in 3 Zeilen zusammen“ können somit Energie- und Ressourcenverbräuche drastisch senken.

**Das richtige Tool für deine Aufgabe:** Je komplexer das Modell, desto höher ist sein Energiebedarf auch für einfache Anfragen. Häufig können aber auch viel schlankere Modelle ein ähnlich gutes Ergebnis abliefern, wenn sie speziell für diese Aufgabe konstruiert wurden.  Für mathematische Aufgaben gibt es WolframAlpha, fürs Übersetzen Deepl.com und für gefühlt jede Aufgabe gibt es individuelle Tools, die sich auf diesen einen Zweck fokussieren. Durch die richtige Wahl kannst du teilweise bis zu 90 % der Emissionen im Vergleich zu einem der großen LLMs einsparen. 

### Tipps zum nachhaltigeren Umgang als Entwickler
**Das richtige Modell** - viele Modelle haben ihre Stärken und Schwächen und die richtige Wahl eines LLM oder SLM kann langfristig einen riesigen Einfluss auf die Emissionen haben. Eine Übersicht über die effizientesten Open-Source-Modelle gibt es hier. Für bestimmte Benchmarks zeigt sich ein teils drastischer Unterschied in den Emissionen bei nur geringer Abweichung in der Präzision. Es ist für spezifische Anwendungen also ratsam genau zu betrachten, ob es nicht vielleicht ein kompaktes, hocheffizientes Modell für den gewünschten Anwendungszweck gibt. 

**Mixture of Experts schlägt Lonely Talent** - Für vielseitige Anwendungsanforderungen kann der Einsatz einer MOE (Mixture of Experts) Struktur den Energie- und Rechenleistungsbedarf deutlich reduzieren. Hierbei wird eine Vielzahl spezialisierter Modelle durch einen Gating-Mechanismus integriert. Eingehende Anfragen können dann geclustert und dem jeweils darauf spezialisierten Modell zugewiesen werden. Demgegenüber werden bei einem einzelnen, komplexen LLM, dem „Lonely Talent“ auch bei einfachen Anfragen größere Ressourcenmengen aktiviert, die eventuell gar nicht nötig sind. 

**Quantisierung** - Durch sinnvolle Modellkompression lässt sich der Energiebedarf von LLMs senken, ohne die Präzision maßgeblich zu beeinflussen. Dabei werden Techniken wie Quantisierung, Pruning und Distillation eingesetzt, um die Modellgröße zu reduzieren, die Anzahl der Berechnungen zu verringern und somit den Rechenaufwand zu minimieren. Dies führt zu einer effizienteren Nutzung der Hardware und kann den Energieverbrauch um bis zu 44 % senken. 

### Weiterführende Informationen

Wen das Thema neugierig gemacht hat, findet hier eine Vielzahl weiterführender Quellen und nützliche Links:

[Doku: Wo landet eigentlich unser Elektroschrott? - Welcome to Sodom](https://www.amazon.de/Welcome-Sodom-Kwasi-Yefter/dp/B07RD5H4R8)

[Greenpeace Report über KI](https://www.oeko.de//fileadmin/oekodoc/Report_KI_DEU.pdf)

[BLOOM - das größte Open Source LLM mit transparenter Umweltbilanz](https://bigscience.huggingface.co/blog/bloom)

[Ganzheitliche Umweltbetrachtung von KI](https://arxiv.org/html/2503.05804v1)

[Initiative für gemeinnützigen Einsatz von KI](https://publicinterest.ai/)

[AI Energy Score Leaderboard](https://huggingface.co/spaces/AIEnergyScore/Leaderboard)

[AI Efficiency Leaderboard](https://huggingface.co/spaces/open-llm-leaderboard/open_llm_leaderboard#/)

[Ausführlicher MIT Artikel zum Thema
](https://www.technologyreview.com/2025/05/20/1116327/ai-energy-usage-climate-footprint-big-tech/)

[UN Bericht zum Energiebedarf von KI
](https://unesdoc.unesco.org/ark:/48223/pf0000394521)

**TL:DR** KI-Infrastruktur verschlingt gigantische Mengen an Energie, Wasser und Rohstoffen. Es werden in den nächsten Jahren über eine Billion Dollar in den weiteren Ausbau gesteckt. Prognosen erwarten, dass der Energiebedarf für KI den von ganz Japan überschreiten wird. Das Training von LLMs verbraucht zwar viel Energie, doch die Milliarden Anfragen pro Tag sind der wesentliche Energieverbraucher. Als normaler User ist dein KI-Fußabdruck aktuell ungefähr so groß wie der eines einzelnen Rumpsteaks. Du kannst die Emissionen drastisch reduzieren, indem du kurze präzise Anfragen ohne Füllwörter und Floskeln schreibst, die Antwortlänge beschränkst, das richtige Tool für deine Aufgabe wählst und natürlich KI nur dann einsetzt, wenn es auch sinnvoll ist. 

Ein kurzer Einblick in den Energiehunger moderner KI-Systeme und einfache Tipps, um ihn als Anwender oder Entwickler zu reduzieren.

AI Everywhere – Watt now?

Wissens-Hub | codecentric AG

codecentric Blog

IT Security Consultant

Der neblige November birgt Gefahren in Form von Schwachstellen.

**Was ist der Patch Tuesday?**

Der Begriff bezeichnet den zweiten Dienstag im Monat, an dem Microsoft wichtige Patches für seine Systeme veröffentlicht. Durch den festen Rhythmus wird die Arbeit von Systemadministratoren und Nutzern erleichtert, da somit ein klarer Planungszeitpunkt zum Einspielen von Updates gegeben ist.

Der Patch Tuesday bringt im November 2025 unter anderem wichtige Sicherheitsupdates von Microsoft und schließt damit mehrere Sicherheitslücken. Eine Zero-Day-Schwachstelle, [CVE-2025-62215](https://msrc.microsoft.com/update-guide/en-US/advisory/CVE-2025-62215) nutzt einen Flaw im Windows-Kernel aus.

Außerdem wurden generelle Patches für Windows 10 und Windows 11 herausgebracht sowie für die gängigen Server-Typen, siehe [hier](https://msrc.microsoft.com/update-guide/releaseNote/2025-Nov).

SAP hat diesen Monat eine kritische Schwachstelle veröffentlicht. Die Schwachstelle [CVE-2025-42890](https://www.cve.org/CVERecord?id=CVE-2025-42890) wurde mit einer 10/10 bewertet. Im SQL Anywhere Monitor gibt es eine Schwachstelle, die das **Insecure Key & Secret Management** betrifft. ****

Mehr Informationen über die veröffentlichten Schwachstellen sind [hier](https://support.sap.com/en/my-support/knowledge-base/security-notes-news/november-2025.html) zu finden.

Weitere Hersteller, die Sicherheitsupdates herausgebracht haben, sind nachfolgend aufgelistet:

[Adobe](https://helpx.adobe.com/de/security/security-bulletin.html): Sicherheitsupdates für mehrere Produkte.

[Cisco](https://sec.cloudapps.cisco.com/security/center/publicationListing.x): Sicherheitsupdates für mehrere Produkte.

[Ivanti](https://www.ivanti.com/blog/november-2025-security-update): Sicherheitsupdates für mehrere Produkte.

[Fortinet](https://fortiguard.fortinet.com/psirt/FG-IR-25-026): Sicherheitsupdates für FortiOS

Kurze Zusammenfassung der Sicherheitsupdates aus dem Patch Tuesday November 2025 inklusive Microsoft und SAP.

Patch Tuesday November 2025

IT Consultant & Developer

Wie Unternehmen mit gezieltem API Architecture Management bestehende Landschaften modernisieren, neue Ökosysteme aufbauen und Business & IT vereinen.

API Architecture Management: Brücke zwischen Business und IT

APIs richtig steuern: So verbinden Sie Business-Ziele mit technischer Exzellenz

IAM & IT Consultant, Software Engineer

In vielen Unternehmen und deren IT-Landschaften wird die zentrale Benutzerverwaltung durch ein Active Directory (AD) bestimmt. Es wird als die “Single Source of Truth” für alle Mitarbeitendendaten, Gruppen, Passwörter und Rollen genutzt, das als wichtiges Identitätsmangementtool gewissenhaft gepflegt wird.

Gleichzeitig benötigen moderne Anwendungen, insbesondere Webanwendungen, auch Unterstützung für Authentifizierungsprotokolle wie OAuth2 und OpenID Connect, um sich authentifizieren zu können. Diese modernen Protokolle unterstützt das AD von Haus aus nicht. 

Wie kann es jetzt klappen, dass die modernen Protokolle gemeinsam mit Active Directory genutzt werden können? Unbedingt vermieden werden sollte es die Benutzerdaten an verschiedenen Orten und mehrfach zu speichern und zu pflegen. Eine doppelte Ablage ist wartungsintensiv und fehleranfällig. Stattdessen müssen wir es schaffen, unsere bereits in AD gepflegten Stammdaten über die modernen Protokolle auszuspielen.

An dieser Stelle kommt Keycloak ins Spiel, das bei der Unterstützung eben dieser Protokolle, insbesondere OAuth, OpenID Connect und SAML glänzen kann. Und statt nun die Benutzer in Keycloak separat zu pflegen, kann Keycloak die bereits angelegten Benutzer aus dem AD synchronisieren und über die genannten Protokolle bereitstellen.

![image9.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmhm25y51kmth06ukpzpcbei6)

In diesem Beitrag zeige ich kurz und bündig, wie man ein Active Directory im Rahmen einer sogenannten User Federation an Keycloak anbindet. Ziel ist ein modernes Single-Sign-On-System ohne doppelten Pflegeaufwand für die Benutzerbasis.

## Active Directory einrichten und konfigurieren

Im ersten Schritt muss das Active Directory eingerichtet werden. Für die meisten Unternehmen sollte dies bereits geschehen sein. Dennoch zeige ich hier einmal sehr kurz die Basisinstallation. Dazu muss im ersten Schritt im Server Manager des Windows Servers die Rolle “Active Directory-Domänendienste” installiert werden.

![image3.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmhm27hqboylz07ugvthkkqcj)

Anschließend erscheint im Server Manager der “AD DS” Eintrag im linken Menü, der bei Auswahl mit einem gelben Banner darauf hinweist, dass noch Konfigurationen notwendig sind. Mit einem Klick auf das gelbe Ausrufezeichen am oberen Bildschirmrand erhalten wir den Hinweis, dass der Server noch zu einem Domänencontroller heraufgestuft werden sollte.  

![image1.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmhm28gczp05d07ug9obyufqv)

In den folgenden Schritten sollte eine neue Gesamtstruktur mit einem festzulegenden Namen (“ad.codecentric.test”), Passwort und NetBIOS Name (“AD”) unter den sonst vorgegebenen Standardeinstellungen installiert werden.

![image4.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmhm29s4pq2aw07ul5iid2jtu)

Nach einem Neustart erfolgt der Login entsprechend nicht mehr nur mit dem Benutzernamen, sondern mit voreingestelltem NetBIOS-Namen, also z.B. “AD\\Administrator” und dem zugehörigen Passwort.  

![image6.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmhm2aeq2p2uf07ugxg3cwfy1)

Anschließend können über das Tool “Active Directory-Benutzer und \-Computer”, welches über die Suche im Startmenü aufgerufen werden kann, Benutzer angelegt werden.

![image7.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmhm2b48zq4jm07ulszowvpqa)

Schaltet man via “Ansicht” die “Erweiterten Features” ein, kann man via Rechtsklick auf einen Benutzer \-\> “Eigenschaften” \-\> “Attribut-Editor” noch den “distinguishedName” des Users einsehen, den wir später für die Keycloak Konfiguration benötigen.

Hinweis: Um AD sicher nutzen zu können, muss noch der Active-Directory-Zertifikatsdienst installiert werden und dem Server ein gültiges Zertifikat zugewiesen werden. Ist dies ein Self-Signed Zertifikat muss das CA-Zertifikat noch mit Hilfe der KC\_TRUSTSTORE\_PATHS Environment-Variable dem Keycloak hinzugefügt werden. Dieses Tutorial soll jedoch nur einen kurzen Überblick über Keycloak und AD geben und klammert daher die komplexere Zertifikats-Konfiguration aus.

## Active Directory in Keycloak konfigurieren

Sobald ein lauffähiger und korrekt konfiguriertes Active Directory vorliegt, kann dieses in Keycloak konfiguriert werden. Im Seitenmenü “User Federation” kann ein neues LDAP angelegt werden. Wichtige Konfigurationen hierbei sind:
|||
| :---- | :---- |
| Vendor | Wenn Sie ein Active Directory von Microsoft verwenden, kann hier “Active Directory” verwendet werden. Für openldap wählen Sie “other”. Zudem stehen weitere Optionen für Novell eDirectory und Red Hat Directory Server zur Verfügung. In unserem Fall wählen wir “Active Directory”. |
| Connection URL | Hier kommt die Domain oder der Hostname des AD-Servers hin. Dies ist für SSL-gesicherte Verbindungen “ldaps://meinadserver:636”. Sollten Sie ohne SSL arbeiten, nutzen Sie “ldap://meinadserver:389”. SSL ist hier empfohlen. |
| Bind type | Wählen Sie “none” für eine anonyme Anmeldung am LDAP Server, während “simple” eine Administrative Anmeldung erfordert. Meistens ist letzteres sinnvoll und wird von uns ausgewählt. |
| Bind DN | Der distinguishedName des Administrators (oder besser eines berechtigen Users) im AD |
| Bind credentials | Das Passwort des im Bind DN ausgewählten Users im AD |
|||

![image8.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmhm2c01tp5m107ug10bq1wj6)

Über die Buttons “Test connection” und “Test authentication” kann die Verbindung zum AD getestet werden. Falls Fehler auftreten, sind die angezeigten Fehlermeldungen oft nicht besonders hilfreich. Hier lohnt sich ein Blick in den Keycloak Syslog, um das Problem zu erkennen und zu beheben.

Als letztes müssen noch Einstellungen im Block “LDAP searching and updating” vorgenommen werden. 

|||
| :---- | :---- |
| Edit mode | Wählen Sie hier “READ\_ONLY” aus, wenn Sie weiterhin alle Benutzerdaten via Active Directory pflegen wollen. Dies ist sinnvoll, wenn das AD die “Single Source of Truth” bleiben soll. |
| Users DN | Geben Sie hier den distinguishedName eines Benutzers ein, allerdings ohne den Teil des Benutzernamens. Über das Users DN steuern Sie, welche Benutzer importiert werden sollen. |
|||

![image2.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmhm2cd5ykxwn06uk30nkqc8v)

Nach einem Klick auf “Save” werden die Benutzer importiert. Sie werden im Menü “Users” sichtbar. Enthalten sind hier der lokale Keycloak-User “admin”, der Admin des AD mit dem Namen “administrator”, unsere beiden angelegten Benutzer Michael und Stefan, sowie die deaktivierten AD-Standardbenutzer “gast” und “krbtgt”.

![image5.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmhm2cpwakybg06ukpj3hxzm2)

Je nach Konfiguration sollte es jetzt möglich sein, sich mit den Benutzern in ihre Anwendungen einzuloggen. Möglicherweise müssen vorher allerdings noch Rollen und Berechtigungen vergeben werden. Auch ist es möglich, AD-Benutzern automatisch bestimmte Rollen zuzuweisen. In der Keycloak Standard-Konfiguration kann ein einfacher Login-Test in die Account Console vorgenommen werden. Dazu wechseln wir im Menü auf den Punkt “Clients” und klicken in der Zeile “account-console” auf dessen Home URL. Dort sollte nun ein Login mit den synchronisierten AD-Benutzern möglich sein.

Keycloak bindet Active Directory und LDAP via User Federation (LDAP) an. Keycloak synchronisiert Nutzer für OAuth2, OIDC und SAML für SSO ohne doppelte Pflege.

User Federation mit Keycloak und Active Directory

# Keycloak Organizations für Mandantenfähigkeit nutzen

Keycloak hat mit dem aktuellen Major-Release 26 die Organizations als Standard-Feature eingeführt \- was ist das und was kann diese Funktionalität? Die Entwickler selbst beschreiben das Feature als einen Schritt Richtung Mandantenfähigkeit. Vielmehr ist es aber ein Feature zur Strukturierung von Nutzergruppen. Die genaue Funktionalität, Einsatzszenarien und Unterschiede zu bisherigen Konzepten sollen in diesem Artikel sortiert werden. Zuvor aber eine Aufstellung darüber, was Organizations sind und was sie nicht sind \- denn alleine der Begriff “Mandantenfähigkeit” weckt Wünsche, die dieses Feature möglicherweise nicht vollständig erfüllen kann.

## Organizations **erlauben…**

* … in Keycloak Benutzer unterschiedlichen Unternehmen zuzuordnen und separat gelistet zu verwalten  
* … eine Unterstrukturierung eines Realms  
* … jeweils die Einbindung von Nutzern über eigene Identity Provider pro Organization  
* … eigene Schritte bzgl. Authentication zu definieren  
* … Organization-spezifische Claims im Token abzulegen

## Organizations **erlauben** es jedoch **nicht…**

* … Organization-spezifische Admins zu definieren, die die Benutzer verwalten können.  
* … eigene Themes, Clients, Auth-Flows, Rollen und Gruppen zu definieren  
* … Mandanten und deren Benutzer vollständig zu isolieren

Bevor Organizations genutzt werden können, muss das Feature in den Realm Settings aktiviert werden:  

![a.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmguxg2rz16zg07uosvi0ryru)

## Wozu Organizations?

Organizations sind also ein weiteres Element, das es erlaubt, einen Realm zu strukturieren und dienen als reine Verwaltungseinheit. Hierbei stellt sich insbesondere die Frage, wann dieses Element genutzt werden kann und wann die Strukturierung stattdessen über Gruppen oder Realms hergestellt werden sollte.

* **Realms** trennen alle ihre Inhalte hart von den Inhalten anderer Realms. Ein eigener Realm ist fast wie eine eigene kleine Keycloak Installation. Darin enthaltene Clients, Gruppen, Rollen, Organizations und alle Einstellungen sind unabhängig von anderen Realms.  
* **Gruppen** fassen Benutzer innerhalb eines Realms zusammen. Benutzer können in mehreren Gruppen sein. Benutzer einer Gruppe können definierte Rollen und Berechtigungen automatisch durch ihre Gruppenzugehörigkeit erhalten.  
* **Organizations** fokussieren die Konfiguration von eigenen Identity Providern, Auth- und Onboarding-Prozessen sowie zugehörige Token Claims.

**Kurz gesagt: Organizations erlauben die Anpassung des Login-Prozesses je Organization innerhalb desselben Realms.**

Das beinhaltet sowohl die Quelle der Benutzerdaten (Identity Provider) als auch den Prozess des Logins. Dies führt im Übrigen insbesondere auch dazu, dass durch Organizations der Identity-First Login aktiviert wird. Hierbei gibt der Benutzer zuerst seinen Benutzernamen ein. Anhand der Organization-Zugehörigkeit und der Mail-Adresse des Benutzers wird der passende Identity Provider bestimmt und der Benutzer auf dessen Login-Maske geworfen.

Ebenfalls können Attribute für die Organization festgelegt werden. Wird der organization-Scope aktiviert, kann die Organization-Zugehörigkeit und \-Attribute im Token angezeigt werden.

## Tutorial

Mit diesem kleinen Tutorial lernen Sie Organizations kennen und zu konfigurieren.

1) Organizations in den Realm Settings aktivieren. Screenshot s. oben.  
2) Organizations im linken Hauptmenü auswählen und eine neue Organization anlegen. Über die Domain kann gesteuert werden, dass Benutzer, deren Mail-Adresse dieser Domain entspricht, automatisch der Organization hinzugefügt werden können. ![b.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmguxggy513bf07ugvjlh8hnl)
3) In den Einstellungen der Organization im Tab “Identity Providers” können wir jetzt zuvor konfigurierte Provider dieser Organization hinzufügen. Wählt man hier die Option “Redirect when email domain matches” aus, so wird der Benutzer direkt auf die Loginseite des Identity Providers weitergeleitet, wenn seine Mail-Adresse der definierten Domain entspricht. ![c.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmguxgpn029v90drt0do16q3q)
4) Loggt sich der Benutzer nun ein, wird er automatisch anhand seiner Mail Adresse der Organization zugeordnet. Sein Membership Type ist “Managed”, da dieser Benutzer konkret über die Organization beigetreten ist und ohne diese nicht existieren kann. Fügen wir dem Realm stattdessen manuell Benutzer hinzu und ordnen diese danach einer Organization zu, sind diese Benutzer “Unmanaged”, da sie normal im Realm existieren und nicht von einer Organization abhängig sind. ![d.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmguxh199185n07uou9gyxg4u)
5) Wenn wir jetzt im Attributes Tab der Organization ein Attribut definieren, können wir dieses im Token aller Organization-User ausspielen lassen. Dazu definieren wir im ersten Schritt ein Attribut. Danach aktivieren wir die Option Client scopes \-\> organization \-\> Mappers \-\> organization \-\> Add organization attributes. Dann werden bei Anforderung des organization-Scopes sowohl die Organization-Zugehörigkeit, als auch die Attribute (in diesem Beispiel “information=wichtiges\_tag”) dem Token hinzugefügt. ![e.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmguxhc5k2agx0drt31l07cu4)

## Fazit

* Organizations helfen Benutzer nach Identity Providern oder manuell zu sortieren  
* Organizations erlauben die Token-Konfiguration und steuern individuelles Login-Verhalten  
* Es findet keine Separierung in dem Sinne statt, dass je Organisation ein Admin nur seine eigenen User verwalten kann (soll aber noch kommen: [https://github.com/keycloak/keycloak/issues/30180](https://github.com/keycloak/keycloak/issues/30180))   
* Mandantenfähigkeit wird daher insbesondere im SaaS-Kontext unterstützt, indem ein Kunde sich nicht selbst administriert

Keycloak Organizations strukturieren Nutzer in Realms. Sie ermöglichen eigene Identity Provider und Login-Prozesse, bieten aber keine Isolation oder Admins.

Keycloak Organizations für Mandantenfähigkeit nutzen

Software Developer

Dieser Artikel ist der zweite Teil meiner Erfahrungen mit Projekten bei denen wir LLMs in Umgebungen mit großen, chaotischen Daten eingesetzt haben. Den ersten Teil findet ihr [hier](https://www.codecentric.de/wissens-hub/blog/llms-im-data-engineering).

Viele Unternehmen sitzen auf einem enormen Datenschatz – und können ihn dennoch schwer heben. Über Jahre ist eine Plattform mit Tausenden Tabellen gewachsen, die nur für langjährige Experten wirklich sichtbar ist. Wir sollten ein Experiment durchführen: Kann ein LLM-Agent belastbare Analysen zu Produkten, ihren Eigenschaften und den dazugehörigen Marketingaktivitäten auf diesen Daten durchführen? Zum Beispiel Fragen wie: Welche Merkmale prägen erfolgreiche Produkte? Welche Maßnahmen greifen wo? Ein Teilexperiment, das wir durchgeführt haben, war ein selbstgebautes Multi-Agenten System.

### Der Agenten-Aufbau
Der Einstieg begann mit Ordnung. Statt die komplette Landschaft zu erfassen, haben wir mit Domain-Experten gezielt einen Kern an Tabellen identifiziert, die für Produkt- und Marketingfragen relevant sind. Zu diesen Tabellen und ihren wichtigsten Spalten entstanden kurze, präzise, durch den Menschen formulierte Beschreibungen: wofür sie stehen, wie sie zusammenhängen, welche typischen Stolperfallen es gibt. Ein LLM half uns, durch Daten-Sampling zusätzliche Strukturtexte zu erzeugen – Verteilungen, Wertebereiche, Join-Hinweise – sodass aus dünner Dokumentation ein kompakter Katalog wurde, der Menschen und Modellen gleichermaßen Orientierung bietet.

Darauf aufbauend entstand die Architektur des Multi-Agenten. Wir trennen Rollen und Verantwortlichkeiten: Ein Retrieval-Agent hat den Datenzugriff – ausschließlich auf Basis der Metadaten und Beschreibungen. Er entscheidet, welche Tabellen und Felder für eine konkrete Frage zu Produkten und Marketing herangezogen werden und formuliert die nötigen SQL-Queries. Die Ergebnisse werden zwischengespeichert, das LLM erhält nur Metadaten, die wichtig sind, um die Daten wiederzufinden. So vermeiden wir, dass das LLM bei großen Ergebnissen durch Halluzination diese verfälscht.

Ein Analyse-Agent erhält dann Zugriff auf die Datenbeschreibungen und den Speicherort, um so Analyseschritte durchzuführen und eine Interpretation der Zahlen zu ermöglichen.

Am Ende werden die Analysen durch einen Reporting-Agenten gesammelt und aufbereitet. 

### Stolpersteine und Erkenntnisse
Selbst die Menge der vorausgewählten Tabellen stellte sich als zu groß für zuverlässige LLM-Ergebnisse heraus. Zwar haben diese alle in das Kontextfenster gepasst (1 Million Token sind groß genug für mehrere Bücher), aber die Präzision lässt dort dennoch zu wünschen übrig. In der aktuellen Forschung wird hier von „Context Rot“ gesprochen. Die Faustregel ist, nur den wirklich relevanten Kontext zur Verfügung zu stellen. Wir nennen das Context Engineering. In einem mehrstufigen Prozess wurde die Anfrage des LLMs erst klassifiziert, damit danach die Gruppe der Tabellen eingeordnet werden konnte, die benötigt wird. Danach wurde ein weiteres LLM befragt, das die Gruppe genauer kannte und so die richtigen Tabellen vorausgewählt hat. Am Ende erhält der Retrieval-Agent nur die Metainformationen dieser ausgewählten Tabellen, um den Query zu formulieren.

Eine weitere Lehre war, dass Retrieval viel schwieriger ist, als es klingt. Selbst in einem Produkt- und Marketingkontext sind Synonyme, historische Bezeichnungen oder unterschiedliche Logiken für Produktzuordnungen tückisch. Die Suche nach Namen allein greift zu kurz; die relevanten Informationen liegen oft an mehreren Stellen, in verschiedenen Granularitäten. 

Darauf haben wir mit zwei Methoden reagiert. Handelt es sich um einen simplen Prozess, hat es gereicht Details hinzuzufügen, wie diese Informationen in der richtigen Reihenfolge durch Joins gefunden werden können. Komplexere aber wieder vorkommende Requests, wie die eindeutige Bestimmung aller Produkte einer Gattung, haben wir durch Code vorbereitet, sodass das LLM nur notwendige Stichwörter füllen oder aus Ergebnislisten auswählen musste. Damit haben wir es geschafft, starre aber wichtige Prozesse mit der Flexibilität und dem gewünschten alternativen Blickwinkel eines Agenten zu vereinbaren.

Das größte Hindernis für uns war am Ende aber die Flexibilität der Agenten. Die gleiche Frage wurde durch das LLM immer anders versucht zu lösen. Das war der stärkste Vorteil, den wir uns erhofft haben: einen neuen, dynamischen Blickwinkel. Aber bei der Implementierung wurde so das richtige Debugging nahezu unmöglich. Des Weiteren mussten nun alle Analysemethoden derart flexibel formuliert werden, dass sie auf jegliche zur Verfügung gestellten Daten passen können und auch mit ständig wechselnder Reihenfolge der Spalten umgehen konnten.  

Aufgrund der kurzen Zeit bleibt somit offen, wie wir die Komplexität weiter senken können, ohne an Präzision zu verlieren. 

Zusammengefasst haben wir aus diesem und dem [vorherigen Projekt](https://www.codecentric.de/wissens-hub/blog/llms-im-data-engineering) wertvolle Erkenntnisse gewinnen können.

**Was sich bewährt hat:**
- Reduktion vor Detailtiefe: Datenraum möglichst früh verkleinern um den Kontext gezielt zu füllen
- Annotationen der Daten, zusätzlich zu den maschinennotwendigen Namen und Typen sind unerlässlich. Mein Tipp ist hier: Wenn jemand neu eingestellt wird, und die Grundlage ist gut genug, damit diese Person alleine die Daten verstehen kann, dann befinden wir uns in einer guten Ausgangssituation. Ein LLM nutzt auch natürliche Sprache zum „Verständnis“ und kann diese nutzen.
- Struktur statt Freitext: Typisierte, validierte Ausgaben sind die Grundlage für belastbare Automatisierung.
- Transparenz als Standard: Quellen, Regeln und Zwischenergebnisse dokumentieren – und zwar so, dass sie maschinell und menschlich prüfbar sind.

**Was wir meiden:**
- „Alles-in-einem“-Prompts. Selbst wenn die Kontextlänge ausreicht, leidet die Präzision.

### Fazit
 LLMs sind im Data Engineering/Science kein Zauberstab, aber ein echter Hebel. Richtig eingesetzt helfen sie, komplexe Datenlandschaften in verlässliche, nachvollziehbare Ergebnisse zu überführen. Der Schlüssel liegt in der Kombination aus Reduktion der Komplexität, erzwungener Struktur und iterativen Workflows. So wird aus dem Datenchaos kein perfekter Garten – aber ein robustes System, das wächst, skaliert und Ergebnisse liefert, denen man vertrauen kann.


Können LLMs Fragen zu den Erfolgsfaktoren von Produkten beantworten? Unser Versuch: ein selbstgebautes Multi-Agenten System.

Data Science mit LLMs

Vom Datenschatz zum Erkenntnissystem: Ein Multi‑Agenten‑Ansatz mit LLMs

Der lange und steinige Weg zur Resilienz – Teil 6\nIm vorherigen Beitrag haben wir über das Plateau der Robustheit gesprochen, die zweite Zwischenstation auf dem Weg zur Resilienz, wozu es gut ist, wo seine Grenzen liegen und was es bedeutet, dort anzukommen.\nIn diesem Beitrag werden wir darüber sprechen, was es bedeutet, sich auch auf Überraschungen vorzubereiten, welche zusätzlichen Erkenntnisse wir brauchen, um zum nächsten Plateau zu gelangen – und wir werden auf das wahrscheinlich größte Hindernis auf unserem Weg stoßen.\nÜberraschung!\nDie meisten Menschen mögen keine Überraschungen – zumindest keine negativen. Unternehmen neigen dazu, Überraschungen zu hassen. Die meisten Manager neigen dazu, Überraschungen zu hassen, weil sie ihre sorgfältig ausgearbeiteten Pläne durcheinander- und unerwartete Risiken mit sich bringen. Mitarbeiter neigen dazu, Überraschungen zu hassen, weil sie in der Regel stressige Mehrarbeit bedeuten und manchmal sogar ihren Arbeitsplatz gefährden.\nDoch Überraschungen passieren, egal wie sehr wir versuchen, alles zu kontrollieren. Aber dann gibt es Leute, die behaupten, dass Überraschungen nur bedeuten, dass man nicht sorgfältig genug geplant hat …\n\n\nBetrachtet man jedoch den Quadranten „Bekanntes-Unbekanntes“, wird deutlich, dass selbst die beste Planung uns nicht vollständig vor Überraschungen schützen kann:\nBekanntes Bekanntes – die Dinge, die wir wissen und derer wir uns bewusst sind. Das explizite Wissen. Diese Dinge berücksichtigen wir in der Regel. Je sorgfältiger wir planen, desto vollständiger wird unsere Liste des bekannten Bekannten sein.\nUnbekanntes Bekanntes – die Dinge, die wir implizit wissen, uns derer aber nicht bewusst sind. Dies ist unser implizites Wissen. Wenn etwas schief geht, lenken sie oft unser „Bauchgefühl” in die richtige Richtung. Wir können diese Dinge in unserer Planung berücksichtigen. Da es jedoch nicht einfach ist, implizites Wissen explizit zu machen, ist die Wahrscheinlichkeit groß, dass wir einige davon übersehen.\nBekanntes Unbekanntes – die Dinge, die wir nicht wissen und uns bewusst sind, dass wir sie nicht wissen. Wenn wir uns intensiv damit beschäftigen, können wir möglicherweise einige davon identifizieren und in „bekanntes Bekanntes” umwandeln. Vielleicht können uns andere Menschen dabei helfen, (einige) der Lücken zu füllen. Die Wahrscheinlichkeit ist jedoch hoch, dass wir zumindest einige davon übersehen.\nUnbekanntes Unbekanntes – Dinge, die wir nicht wissen und wir uns nicht bewusst sind, dass wir sie nicht wissen. Egal, wie sehr wir uns auch bemühen, wir werden sie übersehen.\nWenn wir wirklich sehr hart arbeiten und viel Glück haben, können wir möglicherweise alle potenziellen unerwünschten Ereignisse und Situationen identifizieren, die sich in den ersten drei Quadranten verbergen. In der Regel gelingt uns das jedoch nicht. Selbst wenn wir sehr hart arbeiten, übersehen wir in der Regel einige davon. Versuche beispielsweise einmal, alle Gegenstände in deiner Küche aufzuzählen. Höchstwahrscheinlich wirst du einige Dinge übersehen. Und dabei handelt es sich um Dinge, die du definitiv kennst und wahrscheinlich schon oft gesehen hast. Unbekanntes Bekanntes oder bekanntes Unbekanntes zu identifizieren, ist viel schwieriger.\nAber selbst wenn wir Glück hätten und alle Arten von unerwünschten Ereignissen und Situationen identifizieren könnten, die zu den ersten drei Quadranten gehören, hätten wir Pech, wenn es um den letzten Quadranten geht. Die Definition von unbekannten Unbekannten ist, dass wir keine Ahnung haben, dass sie existieren. Wenn sie eintreten, überraschen sie uns. Das Einzige, was wir über sie wissen, ist, dass sie existieren und dass sie keine leere Menge sind. Mit anderen Worten: Es gibt immer unerwünschte Ereignisse und Situationen, die uns treffen können und von denen wir keine Ahnung haben, dass sie überhaupt existieren, bis wir sie sehen.\nDie vierte Erkenntnis\nDies führt uns unmittelbar zu unserer vierten Erkenntnis:\nÜberraschungen sind unvermeidlich.\nSobald wir dies akzeptieren, sind wir bereit, unsere Reise fortzusetzen.\nDie Grenzen technischer Systeme\nWenn wir akzeptieren, dass Überraschungen unvermeidlich sind, beginnen wir darüber nachzudenken, wie wir erfolgreich mit ihnen umgehen können. Wie können wir unsere IT-Systeme so aufbauen, dass sie Überraschungen erfolgreich bewältigen können?\nNun, das können wir nicht.\nEs ist nicht möglich, IT-Systeme (oder technische Systeme) so zu entwickeln, dass sie mit Überraschungen umgehen können (auch nicht mit den aktuellen KI-Möglichkeiten). Denk nur einmal kurz über die entsprechende Anforderung nach: „Schreibe Code, der mit einer widrigen Situation umgeht, von der niemand weiß, wie sie aussieht und wie sie sich manifestiert“. Viel Glück dabei!\nWir können technische Systeme so gestalten, dass sie mit erwarteten unerwünschten Ereignissen und Situationen umgehen können. Das ist es, was wir hauptsächlich auf der Ebene der Robustheit tun. Im besten Fall können wir versuchen, sicherzustellen, dass unser System in einen definierten sicheren Zustand zurückfällt, wenn etwas Unerwartetes passiert, mit dem es nicht umgehen kann (dies ist Teil von Safety-Design, einer Disziplin, in der normale Unternehmenssoftwareentwickler:innen ausgesprochen schlecht sind). Aber wir können keine Fähigkeit zum Umgang mit unerwarteten, d. h. noch unbekannten unerwünschten Ereignissen und Situationen in unsere technischen Systeme einbauen. 1\nAber wie können wir mit negativen Überraschungen erfolgreich umgehen, wenn wir sie nicht in unsere technischen Systeme integrieren können?\n\nWenn wir einen Moment über diese Frage nachdenken, erkennen wir, dass wir Menschen in den Prozess einbeziehen müssen, da derzeit nur Menschen in der Lage sind, erfolgreich mit Überraschungen umzugehen. Die gesamte Menschheitsgeschichte ist eine Geschichte voller unerfreulicher Überraschungen und der Fähigkeit der Menschen, diese erfolgreich zu überwinden. Andernfalls würden wir als Spezies nicht mehr existieren.\nDies bringt uns zum Konzept der sogenannten „soziotechnischen Systeme“. Dieser Begriff ist in letzter Zeit sehr in Mode gekommen. Er bedeutet jedoch nichts Neues. Er beschreibt lediglich ein technisches System einschließlich der es umgebenden sozialen Systeme. Bei IT-Systemen sind die umgebenden sozialen Systeme je nach Kontext die auftraggebende Organisation, die Entwicklungsorganisation, die Betriebsorganisation, die Fehlerbehebungsorganisation, die Nutzer des Systems einschließlich der Organisation, in die sie eingebettet sind, und manchmal sogar noch weitere Parteien.\nEin wesentlicher Aspekt eines soziotechnischen Systems ist, wie sich das technische und das soziale System gegenseitig beeinflussen, ergänzen und einschränken. Wenn beispielsweise von \nConways Gesetz\n die Rede ist, geht es um den Einfluss, den die Kommunikationswege in der Entwicklungsorganisation auf die Gestaltung des IT-Systems haben.\nWenn es darum geht, mit Überraschungen umzugehen, müssen wir unseren Blickwinkel erweitern und die relevante(n) übergeordnete(n) Organisation(en) und deren Prozesse in unsere Überlegungen einbeziehen, denn nur mit menschlicher Kreativität können wir auf widrige Ereignisse und Situationen reagieren, von denen wir nicht einmal wissen, dass sie existieren, bevor sie uns treffen.\nDie fünfte Erkenntnis\nDies führt uns zu unserer fünften Erkenntnis:\nÜberraschungen können nicht allein auf technischer Ebene bewältigt werden. Wir müssen das gesamte soziotechnische System nutzen.\nDiese Erkenntnis und die vorherige führen uns zu unserem nächsten Zwischenstopp, dem Hochplateau der grundlegenden Resilienz.\nEffizienzbesessenheit\nBevor wir jedoch bereit sind, uns auf das Hochplateau der grundlegenden Resilienz zu begeben, müssen wir zunächst den größten Gegenspieler der Resilienz diskutieren: die Effizienzbesessenheit.\nDas wahrscheinlich größte Hindernis auf unserem Weg zur Resilienz ist die Notwendigkeit, Resilienz und Effizienz in Einklang zu bringen. Letztendlich läuft es darauf hinaus, dass man ein wenig Effizienz opfern muss, um auch mit Überraschungen erfolgreich umgehen zu können. Allein dieser Gedanke bereitet den meisten Unternehmen und Entscheidungsträgern bestenfalls Kopfschmerzen. In der Regel lehnen sie diese Idee entschieden ab. Eine Verringerung der Effizienz kommt für sie nicht in Frage.\nIn meinem (englischen) Blogbeitrag „\nForget Efficiency\n“ habe ich erläutert, warum Unternehmen so effizienzbesessen sind. Kurz gesagt läuft es auf tief verwurzelte Gewohnheiten auf individueller wie auch auf Unternehmensebene hinaus, die aus einer Zeit mit anderen Marktbedingungen stammen: Während des größten Teils des letzten Jahrhunderts waren die meisten Märkte industrielle Märkte, die viel besser vorhersehbar sind als die mittlerweile dominierenden postindustriellen Märkte. Außerdem war zumindest in der westlichen Hemisphäre das allgemeine Umfeld viel besser vorhersehbar:\nRelativ klare politische Lage.\nDie prägenden westlichen Länder waren wirtschaftlich dominant und verzeichnen ein kontinuierliches Wachstum des BIP.\nDie ökologische Lage war noch recht stabil.\nUnd so weiter …\nNatürlich war nicht alles eitel Sonnenschein. Insgesamt bestand die größte Herausforderung für die meisten Unternehmen jedoch nicht darin, sich auf Überraschungen vorzubereiten, sondern die Produktion kosteneffizient zu steigern, um die Gewinne zu maximieren. Aus dieser Situation heraus entstand ein ganzes Wissensgebiet darüber, wie man in einem solchen Umfeld erfolgreich sein kann.\nDer wichtigste Faktor in diesem Optimierungsprozess war die Steigerung der Effizienz. Die zugrunde liegende implizite Annahme war, dass das Richtige produziert wurde und keine großen Überraschungen zu erwarten waren – was zum Zeitpunkt der Entstehung dieses Wissensgebiets für viele Unternehmen oft zutraf. Infolgedessen setzten sich die meisten Führungskräfte für Effizienz ein, da diese der Schlüssel zum Erfolg war (und weil man nicht entlassen wird, wenn man etwas vorantreibt, worüber sich alle einig sind).\nIm Laufe der Zeit wurde die Steigerung der Effizienz zum Selbstzweck. Sie wurde Teil der DNA und Kultur der Unternehmen: Hier ist eine neue Idee. Erste Frage: Steigert sie die Effizienz? Ja? Okay, dann machen wir das. Nein? Abgelehnt.\nEs ging sogar noch weiter. Effizienzsteigerung wurde zur einzigen Problemlösungsstrategie vieler Unternehmen. Sie vergaßen im Grunde genommen alle anderen Mittel, um Probleme und Herausforderungen anzugehen. Was auch immer geschah, die Antwort lautete immer: Effizienzsteigerung.\nNatürlich war nicht nur die Unternehmenskultur von Effizienzbesessenheit geprägt. Auch die Organisation und die Prozesse wurden auf Effizienzmaximierung ausgerichtet:\nMaximiere die Arbeitsteilung.\nFördere Spezialisierung.\nMaximiere die Auslastung.\nMinimiere Leerlaufzeiten.\nSetze die bedingungslose Einhaltung von Regeln durch.\nReduziere Abweichungen.\nMinimiere Ressourcen, bis jede weitere Reduzierung das System zum Stillstand bringen würde – auch ohne unerwartete Ereignisse.\n…\nAll diese Maßnahmen, die im Laufe der Jahrzehnte verfeinert wurden, führen zu hochgradig – manchmal übermäßig – optimierten Organisationen und Prozessen, in denen alles auf Effizienz ausgerichtet ist. Kurz gesagt: Die meisten Unternehmen sind effizienzbesessen. Alles dreht sich um die Steigerung der Effizienz. Alle Probleme werden durch den Versuch, die Effizienz zu steigern adressiert.\nEffizienz als Gegenspieler der Resilienz\nAuftritt: Resilienz.\nResilienz ist die Fähigkeit, auch mit unerwarteten widrigen Ereignissen und Situationen – mit Überraschungen – umzugehen. Überraschungen kümmern sich nicht um sorgfältig reduzierte Varianz, Ressourcenminimierung und all die anderen Maßnahmen zur Effizienzoptimierung, die nur funktionieren, solange nichts Unerwartetes passiert. Überraschungen sind das Unerwartete.\nDie Grundannahme von Menschen, die von Effizienz besessen sind, lautet, dass Überraschungen mit genügend harter Arbeit und Willenskraft ausgemerzt werden können.\nDas ist jedoch nicht möglich. Wie Fehler in technischen Systemen sind Überraschungen unvermeidlich.\nAber was braucht es, um mit Überraschungen umzugehen?Dazu braucht es beispielsweise:\nFreie (überschüssige) Ressourcen\nSpielraum im System, insbesondere etwas Handlungsspielraum für die beteiligten Personen\nKreativität\nUnkonventionelles Denken\nSpontane Zusammenarbeit\n…\nWenn du diese Liste Effizienzbefürwortern zeigst, werden sie sich vor Schmerzen krümmen. Genau das ist es, was sie als schlecht empfinden. Wenn du versuchst, die Effizienz zu maximieren, musst du all diese Dinge unterdrücken und ausmerzen. Das bedeutet:\nEffizienzbesessenheit und Resilienz sind Antagonisten.\nWenn du Effizienz über einige leicht zu erreichende Ziele hinaus steigerst, beeinträchtigst du Resilienz. Umgekehrt gilt: Wenn du resilient sein willst, kannst du Effizienz nicht beliebig steigern.\nBeachte, dass dies keine binäre Entweder-oder-Entscheidung ist. Es bedeutet, dass eine ausschließliche Fokussierung auf Effizienzsteigerung die Resilienz beeinträchtigt. Es bedeutet nicht, dass Effizienz vollständig aufgegeben werden muss, um resilient zu werden. Es bedeutet, dass es einen Sweet Spot gibt, an dem man ziemlich effizient ist, aber dennoch über die erforderlichen Voraussetzungen verfügt, um mit unerwünschten Überraschungen erfolgreich umzugehen.\nDie Verfechter der Effizienz werden jedoch weiterhin zusammenzucken. Schließlich wurden sie über viele Jahre hinweg darauf konditioniert, dass nichts so wichtig ist wie die Steigerung der Effizienz. Daher kommen sie manchmal auf eine scheinbar kluge Idee:\n„Lasst uns ein bimodales Modell einführen. Solange alles wie erwartet funktioniert, läuft alles im Hocheffizienzmodus. Wir wechseln nur dann in den Resilienzmodus, wenn etwas Unerwartetes und Ungünstiges passiert. Auf diese Weise müssen wir keine Kompromisse bei der Effizienz eingehen.“\nObwohl dies ein scheinbar sinnvoller Gedanke ist, funktioniert er in der Praxis nicht. Hocheffiziente Organisationen sind extrem starr und träge. Sie sind großartig darin, das zu tun, wofür sie konzipiert wurden. Aber sie sind extrem resistent gegenüber jeder Abweichung von der Norm. Und sie haben keine Ahnung, wie sie auf Situationen reagieren sollen, für die sie nicht konzipiert wurden.\nDie Reaktion auf eine Überraschung erfordert jedoch genau diese Fähigkeit. Sie erfordert, dass die Organisation sehr schnell und flexibel auf eine unerwartete und unbekannte Situation reagiert. Eine Organisation, die über viele Jahre hinweg auf maximale Effizienz optimiert wurde, hat diese Fähigkeit verloren.\nDarüber hinaus sind die Mitarbeiter in hocheffizienten Organisationen darauf konditioniert, nicht so zu denken und zu handeln, wie es erforderlich wäre, um auf Überraschungen zu reagieren. Fähigkeiten wie Kreativität, unkonventionelles Denken oder spontane Zusammenarbeit werden nicht gefördert. Ganz im Gegenteil: Solche Eigenschaften werden aktiv bestraft, und entweder man lernt, sich anzupassen und diese Eigenschaften abzulegen, oder man verlässt das Unternehmen besser.\nDaher wird ein solches bimodales Modell nicht funktionieren. Man kann nicht einfach bei Bedarf vom hocheffizienten Modus in den resilienten Modus wechseln. Man muss die Fähigkeit, auf unerwünschte Überraschungen zu reagieren, in seine (regulären) Prozesse und die Organisation integrieren. Auch hier muss man dafür nicht auf Effizienz verzichten. Man muss schlicht eine Balance zwischen Effizienz und Resilienz finden und den Sweet Spot ausloten.\nDennoch werden effizienzbesessene Menschen und Organisationen die erforderlichen Maßnahmen zur Stärkung der Resilienz als Bedrohung – nicht selten sogar als existenzielle Bedrohung – betrachten und sie daher bekämpfen.\nDaher besteht der schwierigste Teil des Wegs zur Resilienz in der Regel darin, die Effizienzbesessenheit zu überwinden und sie auf ein Niveau zurückzuführen, das die Resilienz nicht beeinträchtigt. Oder um unsere Bergsteiger-Metapher zu verwenden: Dieser Teil der Reise kann sich anfühlen, als würde man eine steile Wand mit einem Überhang erklimmen. 2\nZusammenfassung\nNun sind wir bereit, uns auf das Hochplateau der grundlegenden Resilienz zu begeben. Da dieser Beitrag jedoch bereits lang genug ist, werden wir unseren Aufstieg auf den nächsten Beitrag verschieben.\nWir haben diskutiert, dass Überraschungen unvermeidlich sind, egal wie sehr wir versuchen, sie auszumerzen. Deshalb müssen wir sie akzeptieren. Wir haben auch diskutiert, dass wir mit Überraschungen nicht allein auf technischer Ebene umgehen können, sondern dass wir dafür das gesamte soziotechnische System benötigen. Wir benötigen menschliche Kreativität, um mit Überraschungen umzugehen.\nAbschließend haben wir das größte Hindernis auf unserem Weg zur Resilienz diskutiert: die allgegenwärtige Effizienzbesessenheit, die wir in den meisten Unternehmen beobachten können. Wir können nur dann erfolgreich resilient werden, wenn wir bereit sind, Resilienz und Effizienz in Einklang zu bringen. Wenn wir uns ausschließlich auf die Steigerung der Effizienz konzentrieren, werden wir starr und fragil statt resilient.\nIm nächsten Beitrag werden wir das Hochplateau der grundlegenden Resilienz erkunden. Bleibt dran … ;)\n1) Der Vollständigkeit halber sei angemerkt: Sowohl Organic Computing als auch Residuality Theory behaupten, dass es möglich wäre, die Fähigkeit, mit unerwarteten und noch unbekannten widrigen Ereignissen und Situationen umzugehen, in technische Systeme einzubauen, indem ihre jeweiligen Techniken auf das Systemdesign angewendet werden. Allerdings ist das Organic Computing noch ein Forschungsgebiet und führt zu ganz anderen Systemdesigns als denen, die wir normalerweise in der Unternehmens-IT sehen. Und zum Zeitpunkt der Erstellung dieses Beitrags ist Residuality Theory noch eine Ein-Mann-Show, die sich in einem viel früheren Forschungsstadium befindet als Organic Computing. Viele Beweise für ihre zugrunde liegenden Annahmen sind bislang nicht öffentlich zugänglich und daher fehlt es an einer öffentlichen Validierung. Daher würde ich derzeit beide Ansätze zumindest mit Vorsicht genießen. Dennoch bin ich persönlich der Meinung, dass beide Ansätze zwar noch lange nicht „produktionsreif” sind, aber dennoch einen Blick wert sind. Darüber hinaus kann eine bestehende Prozedur zum Umgang mit Widrigkeiten möglicherweise auch mit einer noch unbekannten negativen Überraschung umgehen (was die Kernaussage ist, auf der Residuality Theory basiert). Dies ist jedoch etwas, das passieren könnte. Es garantiert jedoch nicht, dass unsere Systeme mit allen Überraschungen umgehen können, mit denen sie konfrontiert werden könnten. \n2) Wie ich in meinem (englischen) Blogbeitrag „\nForget Efficiency\n“ dargelegt habe, ist es auch aus vielen anderen Gründen sehr sinnvoll, sich von dieser allgegenwärtigen Effizienzbesessenheit zu lösen. 
⁠
⁠\nDieser Blogpost ist \nursprünglich auf Englisch\n in Uwe Friedrichsens Blog erschienen.

Resilienz statt Effizienz: Warum Unternehmen Überraschungen nur mit Mensch und Technik meistern – Teil 6 der Resilienz-Serie.

Was ist Resilienz? Grundlagen für IT-Systeme. Part 6.

Der lange und steinige Weg zur Resilienz – Teil 6

Wer mit Daten arbeitet, kennt den Frust: Dateien, die sich nicht an ihr eigenes Schema halten. CSVs, deren Spalten plötzlich mehrere Werte mit zusätzlichen Trennzeichen enthalten. Datenlager, in denen Tausende Tabellen existieren – mit unvollständiger Dokumentation. Kurz: viel Volumen, wenig Struktur und ein enormer Interpretationsaufwand.

In den letzten Monaten haben wir an zwei Szenarien gearbeitet, die genau in diesem Umfeld liegen. In beiden Fällen ging es um die Frage: Können Large Language Models (LLMs) helfen, Ordnung ins Chaos zu bringen und den Weg zu belastbaren Ergebnissen zu verkürzen? Die kurze Antwort: Ja – wenn man sie richtig einbettet. Die lange Antwort ist spannender und zeigt, wo die Grenzen sind, was wirklich funktioniert und wie man die Modelle produktiv in komplexen Datenlandschaften nutzt. Ich werde in zwei Artikeln ein paar unserer Erkenntnisse beschreiben, die wir in Zukunft für weitere LLM Use Cases anwenden werden.

### Vom Datenchaos zur Struktur: 
Ein häufig vorkommender Ausgangspunkt sind Datenquellen mit unsauberer Struktur. In unserem Fall eine CSV-Datei, bei der manche Spalten in Wahrheit ein kleines Universum sind: In manchen Zeilen steckt dort eine Liste von Attributen, getrennt durch ein Semikolon, in anderen Zeilen sind es kommagetrennte Paare aus Attributnamen und Werten. Die Datei war über ein Gigabyte groß, mit mehreren Hunderttausend Zeilen, für die so kein klares Schema erkennbar war.

Unsere Aufgabe war es, diese Datei in ein anderes, firmeninternes Datenschema zu übersetzen. Das Zielschema selbst war auch riesig, ein Attributraum im fünfstelligen Bereich, je nach Kategorie waren aber nur bis zu 3.000 Attribute wirklich relevant, von denen dann ein einzelner Artikel im Schnitt nur 100 - 300 wirklich befüllt. Zusätzlich war ein weiteres Problem, dass ein Attribut in dem Zielschema erst durch die Betrachtung mehrerer Spalten in der CSV bestimmt werden konnte. 

Zusammenfassend hier noch einmal eine Auflistung der Schwierigkeiten:

- Nur ein kleiner Teilraum der eigentlichen Zielmenge (knapp 10 %) war relevant in der Betrachtung, während ein noch kleinerer Teil (unter 1 %) wirklich durch das eigentliche Produkt abgedeckt wurde, also Teil des Endergebnisses war.
- Einzelne Zeilen folgen keiner Gesamtstruktur, sie sind also zu unterschiedlich, um eine klassische regelbasierte Transformation mit realistischem Aufwand hinzubekommen.
- Einzelne CSV-Spalten konnten auf mehrere Attribute im Zielschema abgebildet werden
- Einzelne Attribute im Zielschema benötigten teilweise mehrere Spalten aus der CSV-Datei, um eindeutig befüllt werden zu können.

Unser Versuch war es, diese Transformation durch ein LLM durchzuführen, ein eigentlicher Widerspruch zu den Faustregeln, die wir normalerweise selbst empfehlen. Denn im Normalfall sollten LLMs nicht dort eingesetzt werden, wo regelbasierte Ansätze funktionieren. Für das Team war aber klar, dass die klassischen Lösungen hier den Rahmen sprengen würden. Es gab zu viele Ausnahmen, um diese durch Code im erwarteten Zeitfenster abdecken zu können. 

### Der Kernansatz: Reduzieren, Struktur erzwingen, iterativ verfeinern 
Der erste Hebel ist Reduktion. Statt jede Zeile gegen das volle Zielschema zu prüfen, lassen wir das LLM zunächst die Kategorie erkennen. Damit schrumpft der relevante Attributraum drastisch, und wir konzentrieren uns nur auf das, was im jeweiligen Kontext plausibel ist. So werden Fehler unwahrscheinlicher und die Präzision steigt. 

Zweiter Hebel: strukturierte Ausgaben. Wir nutzen die Fähigkeit moderner LLMs, Daten in strukturierten Outputs auszugeben. Das LLM füllt nicht „irgendwas“, sondern genau die vorgesehenen Felder, mit klaren Constraints. In Python ist das sehr einfach zu erreichen, indem Pydantic-Klassen den Datentyp vorgeben und wir diesen dem LLM mitgeben. Dies funktionierte in unseren Tests immer, sodass wir uns keine Sorgen machen mussten, dass das LLM Text ausgibt, der danach nicht vom Code interpretiert werden kann. Wir nutzen auch die Möglichkeit, Klassenattribute nicht nur durch einen Namen, sondern auch durch eine „Description” zu definieren. Das klingt banal, ändert aber die Erfolgsquote merklich: Je weniger Interpretationsspielraum, desto robuster die Ergebnisse.

Dritter Hebel: iteratives Vorgehen. Statt alle potenziell relevanten Felder in einem Rutsch zu befüllen, arbeiten wir in Etappen. Statt alle Attribute haben wir dem LLM nur zehn Attribute auf einmal mitgegeben. Zwar haben moderne Modelle große Kontextfenster, aber eine hohe Ausgabelast macht sie anfällig für Ungenauigkeit. Unsere Erfahrung: Je größer der Output-Block, desto öfter schleichen sich kleine, aber bedeutsame Fehler ein. So wurden dann Attribute nicht nur falsch befüllt, sondern teilweise komplett vergessen. Ein Stichwort sei hierzu noch erwähnt, welches wir auch noch in einem weiteren Artikel thematisieren werden: Caching von LLM-Anfragen durch bewusstes Prompten.

### Details der Implementierung
Wichtig bei der Bestimmung der Kategorien, aber auch bei der Befüllung der Attribute war es, passendes Context Engineering zu betreiben. Damit ist gemeint, an den relevanten Stellen dem LLM die wichtigen externen Informationen mitzugeben und für diesen Schritt unwichtige Details wieder wegzunehmen. So haben wir während des Kategorisierungschritts dem LLM nicht nur die Namen der einzelnen Kategorien mitgegeben, sondern auch durch Domainexperten formulierte Beschreibungen, Beispielprodukte und Hinweise, was in den Daten drinstehen könnte, damit ein Produkt zu dieser Kategorie passt. Ähnlich haben wir es auch bei den Attributen gemacht. Die Präzision hat sich dramatisch erhöht, wenn jedes relevante Attribut auch eine Beschreibung hatte, worum es sich hier eigentlich genau handelt. 

![Screenshot 2025-10-15 at 11.15.08.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmgtabad1esbx07unarnimhny)
*Eine abstrakte Ansicht der Transformationsarchitektur*

Ein weiterer Trick, den wir genutzt haben, um die Genauigkeit der Ergebnisse zu verbessern, war es Chain-of-Thought-Techniken zu nutzen. In der Ausgabestruktur, sollte das LLM für jedes Attribut auch das Freitext Feld “Quelle” füllen, indem es beschreibt, wo der Wert für dieses Attribut in der Produktzeile zu finden ist, sowie auch “logische Schlussfolgerungen” wie das LLM einen Wert aus dem Text ableiten konnte. Danach sollte das LLM den boolean “Vorhanden” befüllen, also einfach nur true oder false, wenn das LLM der Meinung ist, dieses Attribut kann durch die Informationen in der Produktzeile gefüllt werden. Hierbei handelt es sich weniger um ein Debugfeld für die Menschen um eventuelle Unstimmigkeiten danach zu verstehen, sondern um echte Funktionalität. Wichtig ist, dass das LLM erst danach den echten Wert füllt. Das LLM sagt sich somit also vorher selbst vor, wie es den eigentlichen Wert zu füllen hat. Tauscht man hier die Reihenfolge, und lässt das LLM erst den Wert füllen, danach die Erklärungen, hat man nichts gewonnen, da ein falsch ausgefülltes Feld nicht durch eine nachträglich andere Erklärung geändert werden kann, da Tokens sequentiell generiert werden.

![Screenshot 2025-10-15 at 11.23.19.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmgtaj6i0f5li07unastwukv7)
*Das Ausgabeformat des LLM. Nur die attributeId, name und value werden vom System gebraucht. Die anderen beiden Werte erhöhen die Präzision, werden aber nicht gespeichert*

Ein ähnlicher Chain-of-Thought-Ansatz wurde auch angewendet, um sicherzustellen, dass auch alle Attribute wirklich betrachtet werden. So kann es durchaus sein, dass aus der Liste der in diesem Schritt zehn betrachteten Attribute das LLM welche „vergisst” und gar nicht füllt. Im strukturierten Output haben wir dem LLM also mitgeteilt, zuerst alle Attribute, die gefüllt werden sollen, aufzulisten und dann am Ende jedes gefüllten Attributs die ID des nächsten Attributs zu nennen. 

### Schluss
Durch die Reduktion der Zielmenge, einem iterativen Vorgehen und passendem Context Engineering, sowie durchdachten Prompting, waren wir in der Lage eine zufriedenstellende Datentransformation durchzuführen. Ein wichtiger Nachteil des LLM-basierten Ansatzes, gegenüber klassischen regelbasierten Ansätzen ist natürlich die Zufälligkeit der Antwort. Wiederholt man die Transformation, so waren die Antworten auch deutlich unterschiedlich. Tatsächlich war dies aber am Ende nur noch bei Freitextfeldern der Fall, wo Farben statt Weiß, manchmal Weiß (glänzend) waren. Zahlenwerte oder Booleans können wir zuverlässig befüllen und so eine interessante und flexible Alternative zum Transformieren von Daten schaffen.


Viele kennen den Frust: Dateien, die ein inkonsistentes Schema haben. Können (LLMs) helfen, Ordnung ins Chaos zu bringen und Daten zu transformieren?

LLMs im Data Engineering: Transformation großer Daten

LLMs im Data Engineering: Wie wir chaotische Daten in verlässliche Ergebnisse verwandeln

Bei der Installation von Keycloak hat man im Wesentlichen zwei Optionen: Eine traditionelle Installation oder eine containerisierte Installation. Bei ersterer wird Keycloak direkt als Java-Anwendung auf dem Betriebssystem installiert (sei es Bare Metal oder in einer VM). Containerisierte Lösungen setzen im Kleinen oft auf Docker und in komplexeren Umgebungen meist auf Kubernetes. 

Heute trifft man hauptsächlich containerisierte Lösungen an, denn diese bieten klare Vorteile in Bezug auf Flexibilität, Skalierbarkeit und Wartbarkeit. Die zentralen Vorteile sind:

* **Flexibilität**: Container laufen unabhängig von der darunterliegenden Infrastruktur gekapselt und getrennt von anderen Containern in ihrer Umgebung. Sie können einfach zwischen Hosts verschoben werden, sind an diese nicht eng gekoppelt und haben kaum Abhängigkeiten zu ihnen.  
* **Skalierbarkeit**: Container lassen sich binnen Sekunden multiplizieren und so mehrfach betreiben, um steigende Nachfrage bedienen zu können. Gleichzeitig führt das auch zur Möglichkeit, die Container auf verschiedene Hosts verteilen zu können.  
* **Wartbarkeit**: Da Container und Umgebung strikt getrennt sind, können Updates jeweils ohne Wechselwirkungen mit anderen Containern eingespielt werden. Gleichzeitig können diese Updates zuvor reproduzierbar in anderen Umgebungen getestet werden.

Container können ebenfalls extrem schnell bereitgestellt werden, da sie kaum Anforderungen an ihre Umgebung stellen und alles selbst mitbringen. Während bei einer Bare-Metal-Installation erst noch Java installiert werden muss, bringt ein Container sein eigenes Java in der korrekten Version und Konfiguration direkt mit. Updated man einen Container, erhält man auch Abhängigkeiten wie Java direkt in der zugehörigen, neuen Version.

## Keycloak nur noch mit Containern

Aufgrund der genannten Vorteile sollte Keycloak heute bis auf wenige Ausnahmen nur noch containerisiert installiert werden. Hier kommen Docker und Kubernetes mit zugehörigen Tools infrage.

* **Docker** eignet sich vor allem für kleinere Umgebungen, Tests und die lokale Entwicklung. Es ist schnell einzurichten und zu installieren und ermöglicht das Deployment eines Keycloaks binnen Minuten. Docker Compose ermöglicht das direkte Ausführen einer ganzen Umgebung, zum Beispiel eines Keycloaks mit Datenbank.  
* **Kubernetes** spielt seine Stärken vor allem in großen, produktiven Unternehmensumgebungen aus, da hier Skalierbarkeit und Ausfallsicherheit von größerer Relevanz sind. Kubernetes ist darauf ausgelegt, Umgebungen mit hoher Verfügbarkeit zu realisieren, da Redundanz einfach herzustellen ist. Helm-Charts sind im Kubernetes-Kontext als eine Art Kochrezept zu verstehen, wie eine Anwendung deployt wird.

## Docker Compose: “Mal eben” einen Keycloak deployen

Voraussetzung zum Betrieb eines Keycloak Docker Containers ist eine Docker-Installation. Dazu wählt man für Linux (Server) am besten Docker CE, während man auf Desktop-Rechnern am besten Docker Desktop oder das lizenzfreie Podman Desktop installiert.

Danach kann man in einem leeren Ordner einfach eine docker-compose.yaml Datei anlegen und folgenden Inhalt darin hinterlegen:

```
name: keycloak-codecentric
services:

 keycloak:
   image: quay.io/keycloak/keycloak:26.4.2
   environment:
     KEYCLOAK_ADMIN: admin
     KEYCLOAK_ADMIN_PASSWORD: admin
     KC_DB: postgres
     KC_DB_URL: jdbc:postgresql://postgres/keycloak
     KC_DB_USERNAME: postgres_user
     KC_DB_PASSWORD: postgres_pass
   volumes:
     - keycloak-data:/opt/keycloak/data:z
   ports:
     - 8080:8080
   networks:
     - backend
   command:
     - "--verbose"
     - "start-dev" # Only for Dev-Environment!

 postgres:
   image: postgres
   environment:
     POSTGRES_DB: keycloak
     POSTGRES_USER: postgres_user
     POSTGRES_PASSWORD: postgres_pass
   ports:
       - 5432:5432
   networks:
     - backend
   volumes:
       - postgres-data:/var/lib/postgresql/data

networks:
 backend:

volumes:
 keycloak-data:
 postgres-data:
```


Führt man jetzt innerhalb des Ordners auf der Konsole den Befehl docker compose up aus und wartet ein paar Sekunden, kann man unter http://localhost:8080 einen Keycloak-Server erreichen, der seine eigene PostgreSQL-Datenbank mitbringt. Der Login ist mit dem Benutzernamen admin und dem Passwort admin möglich.

## Kubernetes und Helm für professionelle Deployments

Voraussetzung zur Installation eines Helm-Charts ist eine Kubernetes-Umgebung. Die Einrichtung in Produktivumgebungen kann recht komplex sein \- für lokales Testen reichen aber die durch Docker Desktop oder Podman Desktop aktivierbaren lokalen Kubernetes Testumgebungen. Zusätzlich muss man noch den zu installierenden Helm-Chart auswählen.

Nachdem Bitnami als großer Anbieter einer Sammlung von Helm-Charts sein Repository hinter eine Paywall gestellt hat, suchen viele nach einer neuen Möglichkeit, Keycloak via Helm zu installieren. Hier bietet sich der codecentric Keycloak Helm-Chart an:

[https://github.com/codecentric/helm-charts/tree/master/charts/keycloakx](https://github.com/codecentric/helm-charts/tree/master/charts/keycloakx)

Im Folgenden wollen wir zeigen, wie eine kleine Basisinstallation vorgenommen werden kann. Im ersten Schritt muss eine values.yaml Datei als Konfiguration des Helm-Charts angelegt werden. Eine Datei mit minimaler Konfiguration könnte so aussehen:

```
command:
 - "/opt/keycloak/bin/kc.sh"
 - "start"
 - "--http-port=8080"
 - "--hostname-strict=false"
extraEnv: |
 - name: KEYCLOAK_ADMIN
   value: admin
 - name: KEYCLOAK_ADMIN_PASSWORD
   value: admin
 - name: JAVA_OPTS_APPEND
   value: >-
     -Djgroups.dns.query={{ include "keycloak.fullname" . }}-headless
```

Dann kann man das Repository des Helm Charts hinzufügen und im nächsten Schritt den Helm-Chart mit der vorherigen Konfigurationsdatei über die Konsole installieren:

```
helm repo add codecentric https://codecentric.github.io/helm-charts
helm install keycloak codecentric/keycloakx --values ./values.yaml

```

Wenige Sekunden später kann man beobachten, wie in Kubernetes (oder Docker/Podman Desktop) der entsprechende Keycloak-Container gestartet wird. Um auf den Container zugreifen zu können, muss noch eine Portweiterleitung eingerichtet werden. Diese mappt einen Port des Hosts auf einen Port des Containers:

```
export POD_NAME=$(kubectl get pods --namespace default -l "app.kubernetes.io/name=keycloakx,app.kubernetes.io/instance=keycloak" -o name)
kubectl --namespace default port-forward "$POD_NAME" 8080
```


Solange die Portweiterleitung und der Container aktiv sind, kann man den Keycloak im Browser über die URL [http://127.0.0.1:8080](http://127.0.0.1:8080) aufrufen und sich mit dem Benutzernamen admin und dem Passwort admin einloggen.

## Wie geht es weiter?

In diesem kurzen Tutorial haben sie gesehen, wie man Keycloak einfach via Docker oder Kubernetes installieren kann. Für Produktivumgebungen fehlt hier noch einiges in der Konfiguration, um Anforderungen an Skalierbarkeit, Sicherheit und Performance zu genügen. Hinweise zur Konfiguration des Helm-Charts sind im verlinkten Github-Repository zu finden.

Container (Docker/Kubernetes) sind Standard für Keycloak. Docker Compose ist schnell für Tests. Kubernetes mit Helm bietet Skalierbarkeit & HA für Produktion.

Keycloak Deployment: Docker vs. Kubernetes mit Helm-Chart

Keycloak Deployment: Docker Compose vs. Kubernetes mit Helm-Chart

Service Lead "Software Modernization" & People Lead

[Vibe Coding](https://www.codecentric.de/wissens-hub/blog/vibe-coding-was-nun) ist ein Programmieransatz, der so gut wie jede Aufgabe in der Arbeit mit Quellcode – von Verständnis über Erzeugung bis Veränderung – an eine GenAI delegiert und dabei den Ausgaben dieser KIs fast vollständig vertraut. Ausgehend von einem kürzlich durchgeführten [Architektur- und Code-Review](https://www.codecentric.de/leistungen/software-modernisierung#einstiegsangebote) einer Space-as-a-Service-Plattform (SPaaS-Plattform), die von Grund auf und vollständig mit Vibe Coding erstellt wurde, geben wir eine Einschätzung der Tauglichkeit dieses Programmieransatzes für die Umsetzung komplexer Softwareprodukte.

**Spoiler:** Ohne kontextbasierte Strukturierung und Orchestrierung der eingesetzten GenAI überwiegen die Qualitätsdefizite des erzeugten Codes den vermeintlichen Produktivitätsgewinn.

## Die Verlockung der Geschwindigkeit – Jede:r kann jetzt entwickeln(?)

Das Vibe Coding-Versprechen ist groß: Mit einfachen Anweisungen in natürlicher Sprache ([Prompting](https://www.codecentric.de/en/knowledge-hub/blog/how-to-program-my-llm)) lassen sich in kürzester Zeit ganze Anwendungen erstellen, ohne dass man selbst Wissen über die Software-Entwicklung besitzen muss. Möglich machen sollen dies immer leistungsfähigere GenAIs mit entsprechenden [Large Language Models](https://www.codecentric.de/wissens-hub/blog/grosse-sprachmodelle) wie bspw. Claude, Gemini oder GPT. Mit überschaubaren Kosten und einer wachsenden Auswahl an Agenten, Werkzeugen und Plattformen stellt sich die Frage, ob nun jede:r produktive Software umsetzen kann und Entwickler:innen sich auf kurz oder lang neue Tätigkeiten suchen müssen?

Mit dieser Frage waren wir konfrontiert, als wir kürzlich einen vollständig mit Vibe Coding erstellten Prototypen einer SPaaS-Plattform im Kundenauftrag reviewen durften. Die Plattform wurde ohne Programmiererfahrung innerhalb weniger Wochen mit einer überschaubaren Anzahl von Prompts und unter Einsatz eines spezialisierten Vibe Coding-Portals entwickelt. Neben der Kernfunktionalität, dem Angebot und der Buchung von Orten, integriert die Plattform weitere komplexe Funktionen wie User Management, Chat und Payment in einer modernen UI. Trotz des prototypischen Charakters und des relativ geringen Umfangs (ca. 50.000 Lines of TypeScript Code) zeigten erste Tests, dass die Anwendung grundsätzlich lauffähig ist.

Ziel des beauftragten Architektur- und Code-Reviews war nun die Einschätzung, ob der per GenAI erzeugte Quellcode eine qualitativ gute Basis darstellt, um den Prototyp der SPaaS-Plattform mittelfristig [zur Marktreife zu bringen](https://www.codecentric.de/leistungen/production-readiness-review).

Im Folgenden berichten wir von unseren Erkenntnissen aus dem Review und diskutieren die Chancen und Risiken der Realisierung von Softwareprodukten mit Vibe Coding, die trotz einer Vielzahl spezialisierter Anbieter nach wie vor bestehen.

## Die Analyse – Was unser Review aufdeckte

Für das Review der KI-generierten SPaaS-Plattform haben wir auf [etablierte Verfahren zur Architekturbewertung](https://www.codecentric.de/wissens-hub/blog/architektur-reviews-mit-lasr-in-lichtgeschwindigkeit) zurückgegriffen und Analyse-Tools für das Node.js-Ökosystem genutzt, auf dem die Anwendung letztlich aufsetzt. Die folgenden Absätze beschreiben unsere Erkenntnisse je aufgedecktem Qualitätsdefizit.

**Vendor Lock-In:** Für das Review haben wir den Quellcode der SPaaS-Plattform aus dem verwendeten Vibe Coding-Portal heruntergeladen und ihn standardmäßig auf möglichen Schadcode geprüft. Anschließend haben wir versucht, die Anwendung lokal auszuführen. Dabei folgten wir zunächst der KI-generierten Setup-Dokumentation, die sich jedoch als unzureichend erwies. Nach kleineren Anpassungen ließ sich die Plattform zwar lokal starten, allerdings waren Registrierung und Login nicht fehlerfrei ausführbar. Zudem blieb unklar, wie sich die von der Plattform benötigte Datenbank korrekt anbinden lässt. Benötigte Informationen fehlen in der Setup-Dokumentation. Da sich die Plattform auf Basis des Vibe Coding-Portals ohne Fehler und zusätzliche Konfiguration betreiben lässt, besteht hier also, bewusst oder unbewusst, die große Gefahr eines Vendor Lock-Ins.

**Risikobehaftete Dependencies:** Für die überwiegende Mehrzahl sicherheitskritischer Funktionen, bspw. User Management und Payment, wurden seitens der verwendeten GenAI korrekterweise etablierte, externe Bibliotheken und Frameworks eingebunden. Allerdings waren diese teilweise redundant oder konkurrierend, wie z. B. bei der Verwendung verschiedener Hash-Verfahren für denselben Zweck, was zu schwer lokalisierbaren Laufzeitproblemen führen kann. In anderen Fällen referenzierte die KI Versionen von Dependencies, die veraltet sind oder deren Produktionsreife unklar ist. In einem besonders schwerwiegenden Fall wurde für bestimmte Funktionen zum User Management auf eine externe Abhängigkeit zurückgegriffen, für die seit 2014 keine signifikante Weiterentwicklung mehr stattgefunden hat. Aufgefallen war dies nur, weil die Versionsnummer kleiner 1.0 verdächtig erschien und infolgedessen das zugehörige GitHub-Repository von uns überprüft wurde. Gerade für sicherheitskritische Aspekte einer Webanwendung, welche Benutzer-Sessions und Kund:innendaten verarbeitet, ist die Einbindung veralteter Abhängigkeiten und damit einhergehend das große Risiko von Sicherheitslücken sehr problematisch.

**Fehlende architekturbezogene Sicherheit:** Während bestimmte Sicherheitsfunktionen wie etwa Passwort-Hashing erfolgreich von der GenAI codiert wurden, fehlen sie auf architektonischer Ebene völlig. So wird die Kommunikation zwischen Frontend und Backend als wesentliche Bestandteile der Drei-Schichten-Architektur der SPaaS-Plattform nicht verschlüsselt. Alle Aufrufe der Backend-API durch das Frontend finden im Klartext per HTTP statt. Sie können somit vglw. einfach abgefangen und manipuliert werden, was Man-in-the-Middle-Angriffen, Session Hijacking und Credential Theft Tür und Tor öffnet.

**Verbesserungswürdige Code-Qualität:** Zur Beurteilung der Code-Qualität haben wir marktübliche Tools zur statischen Analyse eingesetzt. Die hierbei aufgedeckten Defizite sind, anders als die zuvor beschriebenen Sicherheitsrisiken, für eine prototypische Anwendung wie die SPaaS-Plattform zunächst weniger gravierend. Dennoch werden sie spätestens nach erfolgreicher Marktvalidierung relevant, wenn die mittel- bis langfristige Sicherstellung der Qualität der angebotenen Software und insbesondere ihre Wartbarkeit in den Fokus rückt. Einige der codebezogenen Mängel können aber auch schon in einer früheren Phase zum Tragen kommen, wenn sie Laufzeitfehler zeitigen, die den Plattformbetrieb in unvorhergesehener Weise beeinträchtigen. Tatsächlich birgt der gereviewte Quellcode großes Verbesserungspotenzial, da eine Vielzahl von Smells aufgedeckt wurde – angefangen bei einer sehr hohen kognitiven Komplexität einzelner Methoden über unbenutzte oder fehlerhafte `import`\-Statements bis hin zu falsch umgesetzter Nebenläufigkeit. Hinzu kamen eine starke Kopplung durch fehlende Separation of Concerns und damit einhergehendem Spaghetti-Code, zahllose unbenutzte Code-Fragmente und eine Aufteilung von Quellcode-Modulen in Ordner, die nicht den üblichen Best Practices folgt. Zusammengenommen legen alle genannten Erkenntnisse den Verdacht nahe, dass die eingesetzte GenAI in Verbund mit unstrukturiertem Vibe Coding Schwächen bei der Erweiterung der Codebasis aufweist: Die Integration neuer Features scheint nicht hinreichend mit qualitätsorientiertem Refactoring einherzugehen, das bspw. sinnvolle Modularisierung, Herstellung von Wiederverwendung oder Entfernung obsolet gewordenen Codes mit einbezieht.

**Mangelhafte Testabdeckung:** Das Risiko einer stark verringerten Wartbarkeit wird durch die mangelhafte Testabdeckung erhöht. Zwar hat die eingesetzte GenAI im Laufe der Entwicklung auch ohne explizites Prompting selbständig Tests erzeugt. Allerdings fokussieren diese nicht die Validierung der fachlich relevanten Abläufe wie etwa die Zahlungsabwicklung oder das Erstellen von Inseraten und deren Buchung. Stattdessen wird die technische Verbindung zur Datenbank geprüft, indem `INSERT`\-Statements abgesetzt und auf korrekte Ausführung geprüft werden.

## Die Bilanz – Konsequenzen unstrukturierten Vibe Codings

Zusammenfassend führte die Nutzung von Vibe Coding im Falle der analysierten SPaaS-Plattform zu einer Reihe von Qualitätsdefiziten unterschiedlicher Kritikalität. Trotz des Prototypen-Stadiums sollten die aufgedeckten Sicherheitsprobleme kurzfristig und insbesondere vor Beginn der Marktvalidierung der Anwendung behoben werden. Bei absehbar erfolgreicher Validierung am Markt sollten Vendor Lock-In und die mangelhafte Wartbarkeit bei der Weiterentwicklung der Plattform angegangen werden, da beide Defizite technische Schulden darstellen, die mittelfristig zu erheblichen Folgekosten führen und so die Wettbewerbsfähigkeit beeinträchtigen können.

Die Entwicklung von Softwaresystemen wird häufig mit dem Bau eines Hauses verglichen. Bleibt man bei diesem Bild, kann der Einsatz unstrukturierten Vibe Codings zum Bau eines Hauses mit brüchigem Fundament führen: Die Fassade sieht schnell gut aus und einzelne Räume sind auch nutzbar, andere aber wiederum nicht und bei der ersten Belastung ist unter Umständen das gesamte Haus einsturzgefährdet. Die anfängliche Zeitersparnis führt zu einer Hypothek mit aus unserer Sicht untragbar hohen Zinsen, sodass die Kosten für die Renovierung schlimmstenfalls die einer kompletten Neuentwicklung übersteigen. Für vermeintlich fertige Häuser bzw. produktive Anwendungen sind diese Kosten in der Regel jedoch hoch und es braucht Expert:innen, die die Probleme nach und nach aufdecken und beheben. Dementsprechend etablieren sich im Kontext des Vibe Codings gerade neue Berufsbilder wie das des [“Vibe Coding Cleanup Specialists”](https://t3n.de/news/vibe-coding-chaos-diese-menschen-reparieren-schlechte-ki-codes-1708009/).

Abschließend können wir, ausgehend von unserem Review der KI-generierten SPaaS-Plattform, festhalten, dass Vibe Coding und zugehörige Portale Personen ohne Erfahrung in der Softwareentwicklung in die Lage versetzen, schnell erste nutzbare Prototypen zu generieren. Diese Anwendungen stellen jedoch ohne besondere Vorkehrungen keine nachhaltigen, sicheren und wartbaren Produkte dar. [Der Traum des “Citizen Developer” wird auch im KI-Zeitalter nicht automatisch wahr](https://www.codecentric.de/wissens-hub/blog/ersetzt-ki-die-softwareentwickler), weil er die Komplexität professioneller Softwareentwicklung vernachlässigt.

## Unsere Empfehlung – Wettbewerbsvorteile durch strukturiertes Vibe Coding

Lässt man unsere Findings außer Acht, beschleunigt der Einsatz von GenAI die Entwicklung von Softwaresystemen – zumindest kurzfristig. Es stellt sich daher die Frage, wie sich dieser Geschwindigkeitsvorteil auch mittel- bis langfristig verstetigen lässt, indem der produzierte Code und seine Integration in eine bestehende Codebasis qualitativ möglichst hochwertig ist und bleibt? Der Schlüssel liegt hier in der Kombination von KI-Werkzeugen mit menschlicher Expertise und strukturierten Methoden.

Anstatt ausschließlich auf den Vibe zu vertrauen, sollte man der GenAI Leitplanken setzen, etwa mit Ansätzen wie [Product Requirements Prompts](https://github.com/Wirasm/PRPs-agentic-eng), [Context Engineering](https://github.com/coleam00/context-engineering-intro) oder [BMAD](https://github.com/bmad-code-org/BMAD-METHOD) (Breakthrough Method of Agile AI-Driven Development). Diese strukturierten Methoden haben gemein, dass die Produktidee zusammen mit grobgranularen technischen Vorgaben, bspw. dem anvisierten Architekturstil, sowie präzisen Anforderungen für die technische Implementierung definiert werden. Zusammen ergeben diese strukturierten Informationen dann den Kontext und einen Plan für die Entwicklung, dem die GenAI bzw. ihre Agenten folgen können. Dies lässt sich sehr gut an der BMAD-Methode und folgender Mnemonik illustrieren:

* **B**ig Picture: Das Big Picture erklärt der GenAI das Gesamtziel des Projekts (*“Wir bauen eine webbasierte SPaaS-Plattform für…”*).  
* **M**ethodology: Mit der Methodology setzt man klare Regeln und Leitplanken (*“Verwende React im Frontend, Express.js im Backend und schreibe sämtlichen Code in TypeScript.“*).  
* **A**ction: Die Action formuliert präzise, atomare Handlungsanweisungen (*“Erstelle eine Express-Route in der Datei `routes.ts`, die…”*).   
* **D**etails: Die Details liefern weitere Informationen zur Implementierung der Action (*“Definiere die API-Endpunkte mittels OpenAPI”*).

Diese Informationen werden i. d. R. in dedizierten Dateien und im Markdown-Format im Repository der betreffenden Anwendung abgelegt. Die Dateien folgen dabei einem bestimmten Namensschema, damit die GenAI sie automatisch als Kontext nutzt. Angaben zum Verwendungszweck der Anwendung, ihrer Architektur und der für die Implementierung zu verwendenden Frameworks müssen so nicht wiederholt für jeden Codegenerierung durch die KI angegeben werden und unterliegen bei Verwendung eines Revision Control Systems wie Git zudem der Versionierung. Für Prompts wie “Integriere einen Login-Button” berücksichtigt die GenAI demnach den bereitgestellten Kontext, was bei unstrukturiertem Vibe Coding nicht der Fall ist. Hier fehlen genaue Leitplanken, um die Freiheitsgrade der GenAI zu begrenzen, sodass die Wahrscheinlichkeit der Produktion defizitären Codes ungleich höher ist als bei Einsatz einer strukturierten Methode.

Der Nutzen solcher Methoden für KI-gestütztes Coding liegt damit auf der Hand: Mit klarem Zielbild und eindeutigen Regeln kann eine GenAI aus Prompts in natürlicher Sprache mit hoher Geschwindigkeit qualitativ guten, sicheren und wartbaren Code erzeugen, während die technischen Schulden relativ niedrig bleiben. Dies gilt insbesondere in Kombination mit deterministischen Ansätzen zur Sicherstellung einer hohen Softwarequalität, etwa Testautomatisierung und Infrastructure as Code, sowie der Einbeziehung menschlicher Expertise, die im Zweifelsfall KI-Entscheidungen beurteilen, redigieren und kontextualisieren kann.

## Fit werden für die KI-gestützte Zukunft der Softwareentwicklung

Was bedeutet dies nun konkret für unseren Kunden? In einem nächsten Schritt enablen wir ihn mit unserem [AI-Assisted Coding Workshop](https://www.codecentric.de/leistungen/generative-ki/ai-assisted-coding-workshop), in dem wir die praktischen Grundlagen strukturierter KI-gestützter Softwareentwicklung vermitteln, sodass er selbständig die Qualität seiner SPaaS-Plattform mit GenAI erhöhen und bei Markteintritt nachhaltig sicherstellen kann. Wer noch unsicher ist, wie man [die richtigen Anwendungsfälle für GenAI](https://www.codecentric.de/wissens-hub/blog/wie-finde-ich-die-richtigen-generative-ki-use-cases-5-learnings-aus-der-praxis) findet, für den empfiehlt sich ein [KI Use-Case Workshop](https://www.codecentric.de/leistungen/generative-ki/ki-use-case-workshop) zur Identifizierung und strategischen Priorisierung vielversprechender KI-Anwendungsfälle.

## Fazit

KI ist kein Autopilot, der aus einfachen Anweisungen in natürlicher Sprache komplexe, produktionsreife Anwendungen erzeugen kann. Vielmehr ist KI in den richtigen Händen ein extrem leistungsfähiger Copilot, der Softwareentwicklung beschleunigen kann. Der Vibe Coding-Ansatz ist nützlich für schnelle Experimente wie bspw. klickbare Prototypen. Für den Aufbau robuster Plattformprodukte, die gängige Sicherheitsanforderungen erfüllen und langfristig wartbar sind, braucht es jedoch mehr: Eine strukturierte Vorgehensweise für den Einsatz von KI-Werkzeugen sowie geschulte Entwickler:innen. Daher ist es wichtig, nicht nur in KI-Werkzeuge zu investieren, sondern auch in den Aufbau von Wissen, um diese effektiv einzusetzen. Dies macht den Unterschied zwischen teurem Experiment und echtem Wettbewerbsvorteil.

Ein Roboter versucht aus Prompts eine Anwendung zu bauen. Die Anwendung sieht sehr instabil aus und droht einzustürzen.

Ein Review von KI-Code deckt auf: Unstrukturiertes Vibe Coding führt zu Qualitäts- & Sicherheitsmängeln. Lerne, GenAI strukturiert & sicher einzusetzen.

Vibe Coding: Ein Praxisbericht zu Chancen & Risiken

Wo Vibe Coding hilft – und wo nicht: Ein Praxisbericht

Principal IT-Security Consultant

Ransomware ist nach wie vor eine der größten Bedrohungen für Unternehmen. Der aktuelle \nData Breach Investigations Report\n von Verizon zeigt, dass im EMEA-Raum nach wie vor 87 % aller Cyberangriffe finanziell motiviert sind und dass Ransomware-Vorfälle im Vergleich zum Vorjahr um 37 % gestiegen sind.\nAuch die Lage in Deutschland ist in Bezug auf Ransomware angespannt. Laut dem \nBundeslagebild Cybercrime\n des BKA war die Bundesrepublik im internationalen Vergleich das vierthäufigste Ziel für Ransomware-Angriffe. Die Erpressung durch Verschlüsselung und Veröffentlichung der erbeuteten Daten bleibt damit eine der zentralen Herausforderungen für Unternehmen jeder Größe und Branche.\nDoch wie genau gehen die Gruppen eigentlich vor und welche Techniken werden am häufigsten eingesetzt?\nUns hat besonders interessiert, welche Ransomware-Gruppen in den ersten drei Quartalen 2025 die meisten Opfer-Unternehmen mit Sitz in Deutschland hatten. Eine Zusammenführung unterschiedlicher Threat-Intelligence-Quellen führte zu unserer Top 5 Liste:\nSafePay\nAkira\nInc. Ransom\nQilin\nDragonForce\nDie Vorgehensweisen der genannten Gruppen haben wir konsolidiert (Stand Oktober 2025) und das Ergebnis grafisch dargestellt.\n\nAus diesem Bild lässt sich ableiten, dass die häufigsten initialen Eintrittsvektoren ins Unternehmen weiterhin die Nutzung bereits erbeuteter Anmeldedaten, das Ausnutzen von Schwachstellen exponierter Systeme, sowie jegliche Art von E-Mail-Angriffe (z. B. Phishing mit Link oder Anhang) sind.\nEbenfalls ist die Nutzung von "Remote Desktop Protocol" (siehe Spalte TA0008 Lateral Movement) zum Bewegen in kompromittierten Infrastrukturen bei Ransomware-Gruppen sehr weit verbreitet.\nUnternehmen sollten sich auf die Erkennung und Verhinderung der oben abgebildeten Techniken vorbereiten.\nWeiterführende Links\n\nhttps://www.bka.de/SharedDocs/Downloads/DE/Publikationen/JahresberichteUndLagebilder/Cybercrime/cybercrimeBundeslagebild2024.html\n\n\nhttps://www.verizon.com/business/resources/reports/dbir/\n\n

Wir haben die Vorgehensweisen der Top 5 in Deutschland aktiven Ransomware-Gruppen aus den ersten drei Quartalen analysiert und ihre Techniken konsolidiert.

Die Techniken der Top 5 Ransomware-Gruppen in Deutschland

## Überblick & Begriffe

Kurz gesagt wollen Passkeys nicht weniger als Passwörter obsolet machen. Und den Benutzernamen möglicherweise gleich mit. Ursprung dieser Lösung sind allerlei Probleme, die von der klassischen Kombination von Benutzernamen und Passwörtern, die üblicherweise bei jeder Benutzerauthentifizierung via Loginformular in eine geschützte Anwendung abgefragt werden, ausgehen. 

Passwörter können beispielsweise zu wenig komplex sein und sind so einfach zu erraten. Genauso muss sich der Anwender an Benutzernamen und Passwort erinnern, was dem ein oder anderen nicht leichtfällt. Passwörter können via Brute-Force erraten oder durch Datenlecks aufgedeckt werden. Gleichzeitig verwenden Benutzer gleiche Passwörter oft mehrfach bei verschiedenen Diensten und machen so direkt mehrere Dienste angreifbar, wenn das Passwort bekannt wird.

Viele dieser Probleme lassen sich durch die Verwendung von Passwortmanagern lösen, da komplexe und individuelle Passwörter sicher und unvergesslich gespeichert werden. Für andere Probleme kommen Passkeys ins Spiel. Sie sind vor allem sicherer, benutzerfreundlicher und bieten einen Phishing-Schutz.

Recherchiert man zum Thema Passkeys, stolpert man oft ebenfalls über die Begriffe WebAuthN und FIDO2. Einfach gesprochen:

* **WebAuthN** ist ein Webstandard der W3C, der eine API zur Authentication im Web festlegt, die über JavaScript angesprochen wird. Dadurch können Websites Benutzer mit Hilfe kryptografischer Schlüsselpaare authentifizieren.  
* **FIDO2** ist ein konkreter Standard, wie Authentifizierung im Web mit kryptografischen Schlüsselpaaren ablaufen sollte und umfasst auch eine Möglichkeit WebAuthN umzusetzen.    
* **Passkeys** sind eine Implementierung von FIDO2. Für jeden zu nutzenden Dienst wird ein Schlüsselpaar erzeugt.

## Passkeys aus technischer Sicht

Technisch handelt es sich bei einem Passkey um ein asymmetrisch Schlüsselpaar – also einen öffentlichen und einen privaten Schlüssel. Soll der Login via Passkey bei einem Dienst ermöglicht werden, geschieht das über eine *Credential Creation* in 3 Schritten:

1. Der Benutzer erzeugt lokal ein neues Schlüsselpaar.  
2. Der private Schlüssel wird sicher auf dem Gerät des Benutzers gespeichert und verlässt dieses im Bestfall nie.  
3. Der öffentliche Schlüssel wird an den Dienst übertragen und dort als Credential des Benutzers hinterlegt.

Wie bei asymmetrischen Schlüsseln üblich, lässt sich aus dem öffentlichen Schlüssel der private nicht ableiten. Daher eignet sich der private Schlüssel als sicherer Passwortersatz, da dieser das Gerät des Benutzers nicht verlässt. Der Login erfolgt dann so:

1. Der Benutzer ruft bei dem Server, bei dem er sich einloggen möchte, eine Challenge ab, die bei jedem Loginversuch anders ist.  
2. Der Benutzer nutzt seinen privaten Schlüssel, um die Challenge zu signieren und sendet nur die Signatur an den Server zurück.  
3. Der Server prüft mithilfe des ihm bekannten öffentlichen Schlüssel des Benutzers die Signatur auf Gültigkeit.

Durch diesen Ablauf kann der Benutzer nachweisen, dass er im Besitz des privaten Schlüssels ist, ohne diesen aus der Hand geben zu müssen. Durch die Signatur ist der Nachweis erbracht und der Server kann den Login zulassen.

## Passkeys in Keycloak

Beim Login in einen Benutzeraccount kann man grob zwischen drei Scenarios unterscheiden, wie Keycloak hier unterstützen kann. 

1. Login mit Benutzername und Passwort, zweiter Faktor via Passkey  
2. Login mit Benutzername und Passkey statt Passwort  
3. Login nur mit Passkey ohne Benutzernamen

### Möglichkeit 1 – Zweiter Faktor via Passkey

Um einen Passkey als zweiten Faktor beim Login nutzen zu können,  müssen wir am Browser Flow eine kleine Änderung vornehmen. Standardmäßig will Keycloak als zweiten Faktor ein OTP Form zeigen. Dieses können wir jedoch einfach durch den WebAuthn Authenticator ergänzen:

![image1.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmgrph083lg8r07uiqll83x7y)

Da der WebAuthn Authenticator teil eines Conditional Subflows ist, wird er nur angezeigt, wenn der Benutzer, der sich einloggen will, auch einen Passkey als zweiten Faktor in seiner Account Console hinterlegt hat:

![image3.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmgrpi1oql1xk07uqw93ok9ux)

Möchte man als Admin benutzer zwingen einen Passkey zu hinterlegen, geht dies über die Required Action „Webauthn Register“.

### Möglichkeit 2 – Passkey statt Passwort

Auch hierfür ist eine Änderung am Login Flow notwendig – schließlich wollen wir jetzt nichtmehr nach Benutzernamen und Passwort, sondern nach Benutzernamen und Passkey fragen beim Login. Daher muss das UsernamePasswordForm gegen ein Username Form und einen WebAuthn Passwordless Authenticator getauscht werden:

![image2.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmgrphfwilh2t07uipg1qhhws)

Dann hat ein User auch die Möglichkeit über die Account Console im Bereich Passwordless einen Passkey zu hinterlegen:

![image4.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmgrpib45lj6t07uips0qbnh3)

Da der Benutzer sich allerdings nicht mehr einloggen kann, sollte nur ein Login via Passkey erlaubt sein, dieser allerdings noch keinen konfiguriert haben, sollte der Passkey entweder schon bei der Registrierung hinterlegt werden, oder nur alternativ zum Passwort genutzt werden.

### Möglichkeit 3 – Login ohne Benutzernamen nur mit Passkey

Diese Möglichkeit wird ebenfalls frisch von Keycloak ab Version 26.4 unterstützt. Dazu muss unter Authentication -> Policies -> Webauthn Passwordless Policy die Option "Enable Passkeys" anschaltet werden. 

## Fazit

* Keycloak unterstützt bereits von Haus aus Basisfunktionalität zu Passkeys  
* Login ohne Benutzernamen ist ganz ohne eigenen Code noch nicht möglich, kann aber ergänzt werden  
* Sollten Auswahlseiten, auf denen der Benutzer entscheiden kann, ob Passwörter oder Passkeys genutzt werden sollen, gewünscht sein, müssen ebenfalls selbst implementiert werden

Passkeys (FIDO2/WebAuthn) ersetzen Passwörter für sicheren Login. Keycloak unterstützt sie als zweiten Faktor (OTP) oder passwortlose Authentifizierung. 

Keycloak & Passkeys: Was ist das, was geht und was nicht

IT-Expertenwissen von Entwickler*innen für Entwickler*innen

CODECENTRIC BLOG

Angular 17 – Eine echte Renaissance?

Für mehr Nachhaltigkeit – CO2 sparen mit Rust

Produktstrategie als Erfolgsgrundlage: Warum du nicht mit deiner Vision starten solltest

How to gain visibility as a software developer?

Wie als Software-Entwickler sichtbar werden?

Charge your APIs Volume 26: Choosing the Right API Development Strategy: A Guide to API Design First vs. Code First Approaches

Cloud

Data

Datenschutz

Digitale Souveränität

Generative KI

GitLab

Input-Management

IT-Security

Künstliche Intelligenz

Nachhaltigkeit

Software-Modernisierung

Bei codecentric leben wir eine offene Kultur und teilen gerne unser Wissen. Tauche weiter in unsere Welt ein.

WISSENS-HUB

Der Softwerker Spezial Generative KI

Drei Personen sitzen am Tisch in einem Meetingraum mit Laptop und besprechen sich.

Leistungen

codecentric weiterhin unter den Top 25 der Lünendonk-Liste 2025

In 2025 ist codecentric erneut unter den Top 25 mittelständischen IT-Beratungsunternehmen in der Lünendonk-Liste

Logo SoftwerkerCast - der IT-Podcast von Techies für Techies

Community

Softwareentwicklung

Kultur

SoftwerkerCast

Events – codecentric mittendrin

Webinar: CompanyGPT mit und ohne OpenAI™

Service Lead GenAI

WEBINAR on demand

Machine Learning

CompanyGPT mit und ohne OpenAI™: Umsetzung & Herausforderungen

CODECENTRIC ENTDECKEN

Logo der codecentric AG, einem in Deutschland führenden IT-Consulting Unternehmen

Logo der codecentric AG einem in Deutschland führenden IT-Consulting Unternehmen

Data Effectiveness

Digitale Produkte & Lösungen

Leistungen von A bis Z ...

Arbeitsweise

Referenzen

Berlin

Bielefeld

Dortmund

Erfurt

Frankfurt am Main

Hamburg

Karlsruhe

Leipzig

München

Münster

Nürnberg

Solingen

Stuttgart

Standorte

Blog

Events

Fachmedien

Softwerker

Webinare

Wissens-Hub

Jobs

Unsere Kultur

Karriere

Über uns

Aktuelles

Kontakt

Du hast Fragen oder möchtest dich mit mir austauschen? Gern – trag einfach deine Kontaktdaten ein.

Contact Us | Sub-Navi-Kontakt oder Zero Search Hits

Kontakt aufnehmen

Marketing & Community Management

Konntest du keine Einträge zu deinem Thema finden?  

Im codecentric Blog gibt es Expertenwissen zu aktuellen IT-Themen: Agile Methoden, Softwarearchitektur, KI, Testing und vieles mehr. ► Jetzt entdecken!

Blog: IT-Wissen von Entwickler*innen für Entwickler*innen

Vielen Dank für deine Anfrage. Ich melde mich bei dir.

Vielen Dank für deine Anmeldung. Eine E-Mail zur Bestätigung ist zu dir unterwegs.

Diese Seite ist eine Vorschau. \nKlicken Sie hier\n, um den Vorschaumodus zu verlassen.

Zu deiner Suche haben wir leider keine passenden Blogartikel gefunden. 

Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.

Du hast Fragen oder möchtest dich mit mir austauschen? Gern - trag einfach deine Kontaktdaten ein.

Die \nDatenschutzerklärung\n der codecentric AG habe ich zur Kenntnis genommen und bestätige das mit der Absendung des Formulars.*

Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.

Ich möchte eure Inhalte abonnieren. Diese Einwilligung kann ich jederzeit widerrufen bzw. den Blog Newsletter abbestellen. Die Datenschutzerklärung habe ich gelesen. Ich bin damit einverstanden, dass die codecentric AG, Hochstr. 11, 42697 Solingen, mich über eigene Dienstleistungen, branchenrelevante Events, Webinare und Publikationen der codecentric AG über die von mir angegebene E-Mail-Adresse informiert. Meine Einwilligung ist freiwillig. Ich kann meine Einwilligung jederzeit mit Wirkung für die Zukunft widerrufen (z.B. über den hierfür vorgesehenen Abmeldelink in unserem Newsletter, per E-Mail an datenschutz@codecentric.de oder per Post an die oben genannte Adresse der codecentric AG) erklären. Weitere Hinweise zur Verarbeitung meiner personenbezogenen Daten und zu meinen Rechten als betroffene Person finde ich hier: \nhttps://www.codecentric.de/datenschutzerklaerung\n

Bitte wähle deine/n gewünschte/n Standort/e aus.

Wir möchten dich als Mensch kennenlernen. Erzähle uns, wer du bist, worauf du Wert legst, wie du gerne arbeitest und was du von uns als Arbeitgeber erwartest.

Bitte füge deine Bewerbungsunterlagen ​(mind. Lebenslauf, gerne auch mehr)​​ ​als eine ​PDF-​Datei ​hinzu.

Es gilt die Datenschutzerklärung der codecentric AG, abrufbar unter \nDatenschutzbestimmungen\n. Mit dem Absenden des Formulars bestätige ich, dass ich diese zur Kenntnis genommen habe.

Job application form field placeholder 10

Keine passende Rolle gefunden? Bewirb dich bitte trotzdem initiativ! Jenseits von starren Schubladen zählen für uns vielmehr Motivation, Kompetenz und der Cultural Fit.

Job application form field placeholder 11

Dies ist ein Pflichtfeld, bitte fülle es aus.

codecentric Blog

IT-Expertenwissen von Entwicklerinnen für Entwicklerinnen

Themenfilter

CODECENTRIC ENTDECKEN

Der Softwerker Spezial Generative KI

SoftwerkerCast

Leistungen

Events – codecentric mittendrin

codecentric weiterhin unter den Top 25 der Lünendonk-Liste 2025

CompanyGPT mit und ohne OpenAI™: Umsetzung & Herausforderungen

codecentric Blog

IT-Expertenwissen von Entwickler*innen für Entwickler*innen

Themenfilter

Bitte Themen anklicken

CODECENTRIC ENTDECKEN

Der Softwerker Spezial Generative KI

SoftwerkerCast

Leistungen

Events – codecentric mittendrin

codecentric weiterhin unter den Top 25 der Lünendonk-Liste 2025

CompanyGPT mit und ohne OpenAI™: Umsetzung & Herausforderungen

Jetzt für unseren Newsletter anmelden

IT-Expertenwissen von Entwicklerinnen für Entwicklerinnen