GenU: AWS' Referenzimplementierung für generative KI im Geschäftsbetrieb

Welches Problem GenU löst und für wen es gedacht ist

Die README beschreibt das Projekt als "Well-architected application implementation with business use cases for utilizing generative AI in business operations". Das ist eine präzise Selbstbeschreibung: Es geht nicht um eine Bibliothek, die man in eine bestehende Anwendung importiert, sondern um eine vollständige Anwendung, die man deployt und dann benutzt oder anpasst. Die Zielgruppe sind Teams, die generative KI im Unternehmen einführen wollen und dafür einen Ausgangspunkt suchen, der nicht bei einem leeren Repository beginnt.

Der Nutzen liegt in der Breite der mitgelieferten Use Cases. Die README listet Chat, Text Generation, Summarization, Meeting Minutes, Writing, Translation, Web Content Extraction, Image Generation, Video Generation, Video Analysis, Diagram Generation und Voice Chat. Diese Liste ist als Ideensammlung gedacht, nicht als Produktumfang. Ein Team, das nur einen internen Chatbot braucht, deployt zwölf Funktionen mit, die es nie nutzt. Die Dokumentation kennt dafür einen Ausweg: "If unnecessary, you can also hide specific use cases with an option", verlinkt auf docs/en/DEPLOY_OPTION.md#hiding-specific-use-cases. Wer die Anwendung produktiv betreibt, sollte diesen Schritt nicht überspringen, weil jede sichtbare Funktion auch eine Oberfläche ist, die erklärt und abgesichert werden muss.

Was tatsächlich im Repository steckt

Die Sprache ist TypeScript, das Frontend ist React, die Infrastruktur läuft über AWS CDK, und die Modellanbindung erfolgt über Amazon Bedrock, ergänzt um Amazon SageMaker in den Topics. Die Topics nennen konkret bedrock, claude, claude3, claude4, command-r, deepseek-r1, llama3, mistral und nova. Das ist kein Zufall: Die Anwendung ist modellagnostisch gebaut, aber innerhalb der Modellpalette, die Bedrock anbietet. Wer ein Modell außerhalb dieses Katalogs einsetzen will, muss die Anbindung selbst bauen.

Neben der Webanwendung existiert eine Browser-Extension. Der Badge browser-extension.yml im README verweist auf einen eigenen CI-Workflow dafür, das Repository enthält also mindestens zwei ausgelieferte Artefakte. Dazu kommt eine Dokumentationsseite unter aws-samples.github.io/generative-ai-use-cases, die als eigentliche Referenz dient. Das README selbst ist im Wesentlichen eine Weiche: Es beschreibt Nutzungsmuster in ausklappbaren Abschnitten und verweist für Details konsequent auf die Dokumentationsseite. Wer nur das README liest, kennt die Anwendung nicht.

Der Datenfluss bei RAG: Kendra oder Knowledge Base

Der interessanteste Teil der Architektur ist RAG Chat, weil dort die eigentliche Entscheidung für Betreiber steckt. Die README beschreibt zwei Informationsquellen: Amazon Kendra und Knowledge Base. Bei Kendra heißt es, man könne "manually created S3 Buckets or Kendra Indexes as they are" weiterverwenden. Das ist der Pfad für Organisationen, die bereits einen gepflegten Index betreiben. Der Preis dafür ist, dass die Qualität des Index außerhalb von GenU entsteht und außerhalb von GenU gepflegt werden muss.

Bei Knowledge Base nennt die Dokumentation vier Funktionen, die über die einfache Vektorsuche hinausgehen: Advanced Parsing, Chunk Strategy Selection, Query Decomposition und Reranking. Jede dieser Optionen ist ein eigener Abschnitt in DEPLOY_OPTION.md, was bedeutet, dass sie über Deployment-Parameter gesteuert werden und nicht über die Oberfläche. Das ist eine bewusste Entscheidung: Retrieval-Qualität ist eine Infrastrukturfrage, keine Endnutzerfrage. Für Betreiber heißt das aber auch, dass jede Änderung an der Chunking-Strategie ein erneutes Deployment bedeutet. Wer schnelle Iteration an der Retrieval-Qualität braucht, arbeitet hier gegen den Stack statt mit ihm.

Die README begründet RAG zusätzlich mit Halluzinationskontrolle: RAG verhindere "plausible but incorrect information" dadurch, dass Antworten nur auf Belegen basieren. Das ist die Absicht, nicht die Garantie. Ob das Modell sich an die Belege hält, hängt vom Prompt und vom Modell ab, und beides ist konfigurierbar.

Deployment: was die Optionen tatsächlich steuern

Die zentrale Datei für Betreiber ist docs/en/DEPLOY_OPTION.md. Sie ist im README mehrfach verlinkt, unter anderem für das Ausblenden von Use Cases, für die Aktivierung des RAG-Chat-Knowledge-Base-Use-Cases, für Advanced Parsing, für die Änderung der Chunking-Strategie und für die Nutzung eines bestehenden Amazon-Kendra-Index. Das Muster ist erkennbar: GenU wird nicht durch Codeänderung konfiguriert, sondern durch Deployment-Parameter, die in CDK-Kontexte oder Parameterdateien fließen.

Für den Einstieg bedeutet das, dass der erste sinnvolle Schritt nicht das Lesen des Quellcodes ist, sondern das Durchgehen der Deployment-Optionen. Wer dort einen bestehenden Kendra-Index einträgt, überspringt den Aufbau einer eigenen Wissensbasis. Wer stattdessen Knowledge Base aktiviert, bekommt die zusätzlichen Retrieval-Funktionen, muss aber die Datenaufbereitung selbst verantworten. Diese Wahl ist die wichtigste architektonische Entscheidung im gesamten Projekt, und sie fällt vor dem ersten Deployment, nicht danach.

Ein Punkt, den die Materialbasis nicht klärt: Die README nennt keine konkreten Umgebungsvariablen, keine CDK-Kontextschlüssel und keine Beispielbefehle. Wer wissen will, wie ein Parameter genau heißt, muss DEPLOY_OPTION.md öffnen. Ich kann hier keine Befehle wiedergeben, die ich nicht belegen kann.

Wo GenU an seine Grenzen stößt

Die erste Einschränkung ist struktureller Natur. GenU ist eine Beispielanwendung, kein Produkt. Das Repository liegt unter aws-samples, die Lizenz ist MIT-0, und der Zweck laut Beschreibung ist die Demonstration von Business-Use-Cases. Daraus folgt, dass Betriebsfunktionen, die ein Unternehmen typischerweise selbst baut, hier nicht zu erwarten sind: Mandantenfähigkeit, Kostensteuerung pro Abteilung, Aufbewahrungsfristen für Chatverläufe, Freigabeprozesse für Prompt-Änderungen. Die README erwähnt nichts davon.

Die zweite Einschränkung betrifft die Modellbindung. Die Topics nennen ausschließlich Modelle, die über Bedrock oder SageMaker verfügbar sind. Wer aus regulatorischen Gründen ein selbst gehostetes Modell oder einen anderen Anbieter braucht, muss die Anbindung ersetzen. Das ist bei einer TypeScript-Anwendung mit klarer Trennung machbar, aber es ist Arbeit, die nicht im Projektumfang enthalten ist.

Die dritte Einschränkung ist die Update-Kadence. Zwischen v5.4.0 im Januar 2026 und v5.5.0 im Juli 2026 liegen sechs Monate, zwischen v5.3.0 im Oktober 2025 und v5.4.0 knapp drei. Wer GenU forkt und anpasst, muss bei jedem Update die eigenen Änderungen gegen die neuen Deployment-Optionen abgleichen. Je tiefer die Anpassung, desto teurer der Sprung. Das ist kein Argument gegen das Projekt, sondern eine Kostenposition, die man vor dem Fork einplanen sollte.

Der Unterschied zu einem eigenen Aufbau auf Bedrock

Die naheliegende Alternative ist, direkt gegen die Bedrock-API zu entwickeln und nur die Teile zu bauen, die man braucht. Der Unterschied liegt nicht in der Modellanbindung, die ist in beiden Fällen dieselbe, sondern im Umfang der Entscheidungen, die schon getroffen sind. GenU bringt eine React-Oberfläche mit zwölf Use Cases, eine Browser-Extension, CDK-Stacks und eine Dokumentationsstruktur mit. Ein eigener Aufbau beginnt bei null und hat dafür keine Altlasten.

Konkret sichtbar wird der Unterschied bei RAG. GenU bietet zwei fertige Pfade, Kendra und Knowledge Base, jeweils mit dokumentierten Optionen für Parsing, Chunking, Query Decomposition und Reranking. Wer selbst baut, muss diese Kette aus S3, Embedding, Vektorspeicher und Abruf selbst zusammenstellen und selbst dokumentieren. Das ist mehr Kontrolle über jeden Schritt und mehr Verantwortung für jeden Fehler.

Die zweite Alternative ist ein kommerzielles Chat-Frontend mit Bedrock-Anbindung. Der Unterschied ist der Betrieb: Bei GenU gehört die Infrastruktur dem eigenen Konto, die Daten verlassen die eigene Region nicht, und die Kosten sind Bedrock- und Infrastrukturkosten ohne Lizenzgebühr. Der Preis ist, dass Updates und Sicherheitspatches aus dem eigenen Team kommen müssen. Bei MIT-0 gibt es keinen Support-Anspruch, und die Lizenz erlaubt ausdrücklich die kommerzielle Nutzung und Modifikation ohne Namensnennungspflicht. Das ist für Unternehmen angenehm, entbindet aber nicht von der Pflicht, die Herkunft des Codes im eigenen Repository nachvollziehbar zu halten.

Wartung, Updates und was vor dem Fork zu klären ist

Die Lizenz MIT-0 ist die permissivste Variante der MIT-Familie: Sie erlaubt Nutzung, Änderung und Weitergabe, auch kommerziell, ohne dass der Urheber genannt werden muss. Für ein Unternehmen, das GenU als Basis nimmt und intern weiterentwickelt, bedeutet das maximale Freiheit bei minimaler Rechtssicherheit in eine Richtung: Es gibt keine Garantie, keine Haftung und keinen Anspruch auf Unterstützung durch AWS. Wer den Code in ein Produkt einbettet, trägt das Risiko vollständig selbst. Das ist keine Rechtsberatung, sondern eine Beschreibung dessen, was die Lizenzkennung aussagt.

Für die Wartung ist die Release-Historie der relevante Anhaltspunkt. Drei Releases in etwa einem Jahr, dazwischen Phasen von mehreren Monaten ohne neue Version. Wer GenU produktiv einsetzt, sollte die eigenen Änderungen so flach wie möglich halten und möglichst viele Anpassungen über die dokumentierten Deployment-Optionen lösen statt über Patches am Quellcode. Das ist der einzige Weg, bei dem ein Versionssprung nicht zur Merge-Session wird.

Ein letzter Punkt, den die Materialbasis offenlässt: Die README nennt keine Angaben zu unterstützten AWS-Regionen, zu erwarteten Bedrock-Kontingenten oder zu den laufenden Kosten eines Deployments. Wer GenU einführt, muss diese Zahlen selbst ermitteln, bevor er sie einem Budgetverantwortlichen vorlegt.

Redaktionelles Fazit

Wer eine Bedrock-basierte Chat- und RAG-Oberfläche für einen internen Piloten braucht und die Betriebsverantwortung akzeptiert, findet in GenU eine vollständige Ausgangsbasis. Wer eine mandantenfähige Plattform mit eigener Autorisierung, Kostensteuerung pro Team und Audit-Trail plant, sollte zuerst die IAM-Rollen und die Cognito-Konfiguration im CDK-Stack prüfen, bevor er GenU als Fundament einplant. Der erste konkrete Schritt ist ein Deployment mit dem Knowledge-Base-Modus und anschließendem Blick in CDK Outputs, um zu sehen, welche Ressourcen tatsächlich in der eigenen Region entstehen.

Offizielle Quellen

1. aws-samples/generative-ai-use-cases on GitHub
2. License: MIT-0
3. Project website
4. README
5. Releases