bks-lab Blog

Souveräne KI für vertrauliches Unternehmenswissen

BKS-Lab — Sun, 26 Jul 2026 00:00:00 GMT

„Unsere Daten liegen in Frankfurt, also sind sie sicher.“ Diesen Satz hören wir in fast jedem Erstgespräch über KI mit sensiblen Daten. Er kommt von IT-Leitern, von Datenschutzbeauftragten, manchmal vom Geschäftsführer selbst. Er ist verständlich. Und er greift zu kurz. Denn die eigentliche Frage beantwortet ein deutsches Rechenzentrum nicht. Wer kann rechtlich auf unsere Daten zugreifen? Die Antwort hängt nicht an der Postleitzahl des Serverraums. Sie hängt an der Jurisdiktion, der der Betreiber unterliegt. Wir sind BKS-Lab, eine Marke der Boiman Kupermann Solutions GmbH aus Köln. Wir machen vertrauliches Unternehmenswissen durchsuchbar, analysierbar und automatisierbar. Die Systeme dafür laufen lokal oder selbstgehostet. Daten und Infrastruktur bleiben unter der Kontrolle des Unternehmens. In diesem Beitrag legen wir ausführlich dar, warum wir dieses Problem für eines der unterschätztesten der aktuellen KI-Welle halten. Wir zeigen, was wir konkret liefern und wie ein Projekt bei uns abläuft. Der Text ist lang geworden, mit Absicht. Wer über den Umgang mit seinem wertvollsten Wissen entscheidet, hat mehr verdient als drei Bulletpoints. Vorab eine Einordnung, die uns wichtig ist. Dieser Beitrag enthält rechtliche Fakten zum US CLOUD Act, zur DSGVO und zum EU AI Act. Wir haben sie sorgfältig recherchiert. Wir sind aber Technologen und keine Kanzlei. Für die rechtliche Bewertung im Einzelfall ziehen Sie bitte fachkundigen Rat hinzu. Die erste Herausforderung. Ihr wertvollstes Wissen ist verteilt Jedes Unternehmen, mit dem wir sprechen, hat denselben Befund, nur in unterschiedlicher Ausprägung. Das Wissen, das den eigentlichen Wert des Unternehmens ausmacht, liegt in Dokumenten, Datenbeständen und Prozessen. Aber es liegt dort nicht geordnet. Es verteilt sich über Netzlaufwerke, ein ungepflegtes Wiki, Postfächer einzelner Mitarbeiter, Ticketsysteme und Fachanwendungen ohne Schnittstellen. Wer eine konkrete Frage hat, sucht an fünf Stellen. Was haben wir diesem Kunden 2022 zugesagt? Welche Variante dieser Klausel haben wir schon einmal verhandelt? Gab es diesen Schadensfall schon einmal? Im Zweifel findet er die veraltete Version. Die Kosten dieses Zustands sind gut belegt, auch wenn sie in keiner Bilanz auftauchen. Das McKinsey Global Institute hat bereits 2012 in der Studie „The Social Economy“ errechnet, dass Wissensarbeiter rund 19 Prozent ihrer Arbeitswoche mit dem Suchen und Zusammentragen von Informationen verbringen. Das ist fast ein voller Arbeitstag. Neuere Erhebungen von IDC und anderen Marktforschern kommen auf vergleichbare Größenordnungen. Für ein mittelständisches Unternehmen mit 200 Wissensarbeitern entspricht das rechnerisch etwa 35 Vollzeitkräften, die nichts anderes tun als suchen. Diese Zeit fehlt im Vertrieb, in der Projektarbeit und in der Entwicklung. Bis vor wenigen Jahren gab es darauf nur zwei Antworten, und beide waren unbefriedigend. Die erste hieß mehr Disziplin, also Ablagerichtlinien, Dokumentationspflichten und noch ein Wiki. Das scheitert regelmäßig an der Realität des Tagesgeschäfts. Die zweite war die klassische Enterprise-Suche, ein Volltextindex über die Ablagen. Sie findet Zeichenketten, versteht aber keine Zusammenhänge. Wer nach „Gewährleistungsfrist“ sucht, findet das Dokument nicht, in dem „Mängelhaftung 24 Monate“ steht. Erst große Sprachmodelle haben diese Lücke geschlossen. Semantische Suche findet Inhalte nach Bedeutung statt nach Wortlaut. Ein Sprachmodell zieht aus einem 80-seitigen Vertrag die drei relevanten Passagen. Es erkennt Vertragspartner, Fristen und Beträge und beantwortet Fragen in natürlicher Sprache, mit Quellenverweis auf die Fundstelle. Für das Geschäft heißt das, die verstreute Ablage ist kein Naturgesetz mehr. Und genau an diesem Punkt beginnt die zweite Herausforderung. Verschärft wird das Problem durch zwei Entwicklungen, die selten zusammen gedacht werden. Erstens wächst der unstrukturierte Teil der Unternehmensdaten seit Jahren deutlich schneller als der strukturierte. Dazu zählen Dokumente, E-Mails, Präsentationen und Protokolle. Gängige Analysen von Marktforschern wie IDC verorten diesen Anteil bei achtzig Prozent und mehr des gesamten Bestands. Genau dieser Teil ist mit klassischen Datenbankwerkzeugen am schlechtesten erschlossen. Zweitens verlassen mit der Verrentung der geburtenstarken Jahrgänge viele Erfahrungsträger den deutschen Arbeitsmarkt. Mit ihnen geht Wissen, das nie dokumentiert wurde oder in Ablagen liegt, die nur sie noch durchschauen. Wer Wissen erst erschließt, wenn die Person weg ist, die es einordnen könnte, hat das Fenster verpasst. Die zweite Herausforderung. Der bequeme Weg in die Cloud kostet Kontrolle Die naheliegende Lösung liegt scheinbar auf der Hand. Die großen Cloud-Anbieter liefern KI-Dienste, die sich in wenigen Tagen anbinden lassen. Dokumente hochladen, API-Schlüssel erzeugen, fertig. Für unkritische Daten ist dagegen wenig einzuwenden. Niemand muss öffentlich verfügbare Produktbroschüren lokal verarbeiten. Das Problem beginnt dort, wo das Wissen vertraulich ist. Dazu gehören Verträge, Kalkulationen, Personalunterlagen, Konstruktionsdaten sowie Mandanten- oder Patientendaten. Wer diese Bestände in externe KI-Dienste gibt, schafft Abhängigkeiten auf drei Ebenen zugleich. Sie entstehen bei den Daten, beim Modell und bei der Infrastruktur. Jede dieser Abhängigkeiten ist für sich genommen beherrschbar. Zusammen ergeben sie einen Zustand, in dem das Unternehmen die Verfügungsgewalt über sein wertvollstes Wissen faktisch geteilt hat. Wie ungleich diese Teilung ist, zeigt der Blick auf den europäischen Cloud-Markt. Nach Zahlen von Synergy Research erreichte er 2024 ein Volumen von rund 61 Milliarden Euro. Das ist das Sechsfache des Werts von 2017. Europäische Anbieter haben von diesem Wachstum kaum profitiert. Ihr Marktanteil fiel im selben Zeitraum von 29 auf etwa 15 Prozent und stagniert dort seit 2022. Amazon, Microsoft und Google vereinen rund 70 Prozent des europäischen Markts auf sich. Die größten europäischen Anbieter, SAP und die Deutsche Telekom, kommen auf jeweils etwa 2 Prozent. Die US-Hyperscaler investieren nach Synergy-Angaben Quartal für Quartal einen zweistelligen Milliardenbetrag in europäische Rechenzentren. Diesen Wettlauf holt auf der Infrastrukturebene niemand mehr auf. Im März 2025 forderten deshalb mehr als 100 europäische Organisationen in einem offenen Brief an die EU-Kommission mehr technologische Unabhängigkeit. Die Abhängigkeit von den Hyperscalern schaffe Sicherheits- und Verlässlichkeitsrisiken. Zur wirtschaftlichen Abhängigkeit kommt die rechtliche. Ihre Geschichte beginnt 2013. Damals verlangten US-Ermittler von Microsoft die Herausgabe von E-Mails, die auf einem Server in Irland lagen. Microsoft weigerte sich. Ein US-Durchsuchungsbeschluss, so das Argument, reiche nicht über die Landesgrenze. Der Streit ging durch die Instanzen bis vor den Supreme Court und wurde dort nie entschieden. Im März 2018 verabschiedete der US-Kongress den Clarifying Lawful Overseas Use of Data Act, kurz CLOUD Act. Das Gesetz beantwortete die offene Frage. US-Anbieter müssen Daten auf behördliche Anordnung herausgeben, unabhängig davon, wo diese Daten physisch gespeichert sind (18 U.S.C. § 2713). Das Verfahren gegen Microsoft war damit gegenstandslos. Die Rechtslage ist seither eindeutig. Entscheidend ist nicht der Standort des Rechenzentrums, sondern die Jurisdiktion, der das Unternehmen unterliegt. Ein Server in Frankfurt, Magdeburg oder Mailand ändert daran nichts, wenn der Betreiber oder dessen Konzernmutter US-amerikanischem Recht untersteht. Zwei Jahre später verschärfte der Europäische Gerichtshof die Lage aus der anderen Richtung. Im Schrems-II-Urteil vom Juli 2020 (C-311/18) erklärte er das Privacy-Shield-Abkommen für ungültig, weil US-Überwachungsgesetze kein gleichwertiges Schutzniveau gewährleisten. Das 2023 nachgeschobene EU-U.S. Data Privacy Framework hat den Datentransfer auf neue Füße gestellt. Es wird aber bereits juristisch angegriffen, und am CLOUD Act selbst ändert es nichts. Wie real der Konflikt ist, zeigte sich im Juni 2025 im französischen Senat. Dort räumte der Rechtsdirektor von Microsoft France unter Eid ein, das Unternehmen könne nicht garantieren, dass Daten französischer Bürger niemals ohne ausdrückliche französische Genehmigung an US-Behörden übermittelt werden. Ehrlicher lässt sich die Grenze vertraglicher Zusicherungen kaum benennen. Für Entscheider in Compliance, Datenschutz und IT-Sicherheit ist das in unserer Erfahrung das präziseste Argument der gesamten Debatte. Es braucht keine Verschwörungstheorien und keine Anti-Amerika-Rhetorik. Es braucht nur eine nüchterne Feststellung. Die Postleitzahl des Rechenzentrums beantwortet die eigentliche Frage nicht. Wer vertrauliches Wissen in die Systeme eines US-Anbieters gibt, akzeptiert eine fremde Jurisdiktion über diese Daten. Daran ändern weder ein europäisches Rechenzentrum noch ein Zertifikat etwas. Die Debatte hat inzwischen auch die europäische Politik erreicht. Der Draghi-Bericht zur Wettbewerbsfähigkeit Europas vom September 2024 benannte die technologische Abhängigkeit des Kontinents als strategisches Problem. Initiativen wie Gaia-X oder die 2025 formierte EuroStack-Bewegung arbeiten an europäischen Alternativen auf Infrastrukturebene. Wir beobachten das mit Sympathie und mit Nüchternheit. Bis solche Vorhaben Hyperscaler-Angebote ersetzen können, vergehen Jahre. Ein Unternehmen, das heute über KI für seine vertraulichen Daten entscheidet, kann darauf nicht warten. Es braucht einen Weg, der jetzt funktioniert und die eigene Handlungsfähigkeit sichert, unabhängig davon, wie die Infrastrukturdebatte ausgeht. Dieser Weg steht heute offen. Er führt über souveräne KI-Workloads in der eigenen Infrastruktur. Warum eine C5-Zertifizierung nicht davor schützt An dieser Stelle des Gesprächs fällt regelmäßig ein Einwand. „Aber der Anbieter ist doch C5-zertifiziert.“ Der Einwand verdient eine genaue Antwort. Er beruht auf einer Verwechslung, und das Marketing der großen Anbieter pflegt diese Verwechslung nach Kräften. Der Cloud Computing Compliance Criteria Catalogue, kurz C5, ist ein Kriterienkatalog des Bundesamts für Sicherheit in der Informationstechnik. Das BSI hat ihn 2016 eingeführt und 2020 überarbeitet. Die aktuelle Fassung umfasst 121 Grundkriterien in 17 Bereichen. Sie reichen von der Organisation der Informationssicherheit über physische Sicherheit bis zum Umgang mit behördlichen Auskunftsersuchen. Ein C5-Testat bescheinigt, dass ein Wirtschaftsprüfer die Einhaltung dieser Kriterien geprüft hat. Das ist wertvoll. Wer einen Cloud-Dienst betreibt, sollte ein solches Testat vorweisen können. Für viele öffentliche Auftraggeber in Deutschland ist es faktisch eine Einkaufsvoraussetzung. Nur beantwortet das Testat eine andere Frage als die, um die es hier geht. C5 prüft die Betriebssicherheit. Ist das Rechenzentrum ordentlich gesichert? Sind Zugriffe protokolliert? Funktioniert das Patch-Management? Welchem Recht der Betreiber unterliegt, prüft C5 nicht und kann es auch nicht prüfen. Ein US-Anbieter mit tadellosem C5-Testat bleibt ein US-Anbieter. Er unterliegt weiterhin dem CLOUD Act. Tatsächlich sind auch die ausdrücklich als „souverän“ vermarkteten Cloud-Angebote US-amerikanischer Hersteller C5-testiert. Das Testat trifft eine Aussage über Schlösser und Prozesse. Über staatliche Zugriffsrechte sagt es nichts. In Gesprächen formulieren wir das zugespitzt. Ein Zertifikat über Betriebssicherheit schützt vor Einbrechern, nicht vor Gerichtsbeschlüssen. Wer beides verwechselt, wiegt sich in einer Sicherheit, die auf dem Papier gut aussieht und im Ernstfall nicht trägt. Für die Anbieterauswahl heißt das nicht, C5 zu ignorieren. Es heißt, C5 als notwendige, aber nicht hinreichende Bedingung zu lesen, sobald die Jurisdiktionsfrage im Raum steht. Was souveräne KI bedeutet und was sie nicht bedeutet Souveräne KI heißt für uns, dass KI-Systeme vollständig in der Infrastruktur des Kunden laufen. Das kann auf eigenen Servern sein, in einem eigenen Rechenzentrum oder in einer abgeschotteten Umgebung ohne Internetzugang. Wo es passt, kommt auch ein europäischer Cloud-Anbieter in Frage, der keiner Drittstaaten-Jurisdiktion unterliegt. Die Daten verlassen den Kontrollbereich des Unternehmens nicht. Die Modelle laufen dort, wo die Daten liegen, und nicht umgekehrt. Zudem bleibt jede Komponente der Architektur austauschbar, das Sprachmodell eingeschlossen. Kein Anbieter kann das Unternehmen festhalten. Das ist eine strategische Eigenschaft, keine technische Fußnote. Ebenso wichtig ist uns die Abgrenzung, denn um den Begriff der Souveränität hat sich ein Markt gebildet, in dem sehr Verschiedenes unter demselben Etikett verkauft wird. Unser Liefergegenstand sind neue KI-Workloads. Sie entstehen bei unseren Kunden von vornherein dort, wo die Daten bleiben dürfen. Bestehende Cloud-Landschaften reißen wir dafür nicht ein. Das hält den Einstieg klein, das Risiko begrenzt und den Nutzen konkret. Zugleich lassen wir unsere Kunden mit der größeren Frage nicht allein. Wer über souveräne KI nachdenkt, denkt meist auch über souveräne IT insgesamt nach. Es geht dann um das ERP, um die Office-Umgebung und um den Schritt von der Public Cloud in eine private Cloud. In diesen Fragen beraten wir. Was das umfasst, beschreiben wir weiter unten in einem eigenen Abschnitt. Diese Fokussierung hat einen zweiten Grund, über den wir offen sprechen. Das Jurisdiktions-Argument ist in vielen Organisationen der Türöffner. Mit ihm stimmen Datenschutzbeauftragte, CISO oder Betriebsrat einem KI-Vorhaben überhaupt erst zu. Aber ein Motiv ist keine Lösung. Niemand führt ein KI-System ein, um ein Compliance-Problem zu vermeiden. Man führt es ein, weil es Arbeit abnimmt. Die eigentliche Antwort auf die Souveränitätsfrage ist deshalb ein Nutzenversprechen und kein Infrastrukturprojekt. Vertrauliches Unternehmenswissen wird lokal durchsuchbar, analysierbar und automatisierbar. Die Souveränität ist die Bedingung, unter der das geschieht. Der Grund für das Projekt ist der Nutzen. Ein dritter Punkt gehört zur Ehrlichkeit dazu. Lokale Modelle sind in den letzten zwei Jahren dramatisch besser geworden. Offene Modellfamilien wie Llama, Mistral oder Qwen erreichen heute bei vielen Aufgaben eine Qualität, die für den produktiven Einsatz in klar umrissenen Prozessen ausreicht. Den größten Cloud-Modellen sind sie aber nicht in jeder Disziplin ebenbürtig. Wer das behauptet, verkauft unseriös. Unsere Antwort darauf ist ein hybrides Vorgehen in der Aufbauphase. Wir beschreiben es weiter unten im Abschnitt zum Vorgehen. Solange keine sensiblen Daten im Spiel sind, misst ein Cloud-Modell die Qualität des lokalen Systems und hilft bei der Kalibrierung. Im Produktivbetrieb mit echten Daten arbeitet das System rein lokal. Der Regulierungsrahmen 2026. DSGVO und AI Act Neben dem CLOUD Act prägen zwei europäische Rechtsakte die Rahmenbedingungen für KI-Projekte mit sensiblen Daten. Beide sprechen aus unterschiedlichen Gründen für lokale Architekturen. Und beide lassen sich mit der richtigen Architektur von der Risikoliste streichen, statt sie jahrelang zu verwalten. Der erste ist die DSGVO. Sobald personenbezogene Daten verarbeitet werden, greifen die Regeln zum Drittlandtransfer nach Art. 44 ff. Genau hier wird jede US-Cloud-Anbindung zur Dauerbaustelle. Angemessenheitsbeschlüsse können fallen, wie Schrems II gezeigt hat. Standardvertragsklauseln verlangen Transfer-Folgenabschätzungen. Die Aufsichtsbehörden prüfen zunehmend genau. Eine Architektur, in der personenbezogene Daten die eigene Infrastruktur gar nicht erst verlassen, macht diesen gesamten Problemkomplex gegenstandslos. Es gibt keinen Drittlandtransfer, den man rechtfertigen müsste. Bei Bußgeldern von bis zu 20 Millionen Euro oder 4 Prozent des weltweiten Jahresumsatzes ist das kein akademischer Vorteil. Es ist Risikovorsorge mit unmittelbarem Geschäftswert. Der zweite ist der EU AI Act, die Verordnung (EU) 2024/1689. Sie ist seit dem 1. August 2024 in Kraft und das weltweit erste umfassende KI-Gesetz. Sie gilt gestaffelt, und der Zeitplan hat sich 2026 noch einmal verschoben. In vielen Unterlagen ist das noch nicht angekommen. Der Stand bei Veröffentlichung dieses Textes sieht so aus. Die Verbote inakzeptabler Praktiken und die KI-Kompetenzpflicht nach Artikel 4 gelten seit Februar 2025. Am 2. August 2026 werden die Transparenzpflichten nach Artikel 50 anwendbar. Wer Chatbots mit Kundenkontakt einsetzt oder KI-generierte Inhalte veröffentlicht, muss das offenlegen. Die umfangreichen Pflichten für eigenständige Hochrisiko-Systeme nach Anhang III wurden dagegen verschoben. Das Digital-Omnibus-Paket, im Mai 2026 politisch vereinbart und Ende Juni 2026 vom Rat bestätigt, verlegt sie vom August 2026 auf den 2. Dezember 2027. Für Hochrisiko-KI, die in Produkte eingebettet ist, gilt nun der 2. August 2028. Die Bußgeldrahmen bleiben erheblich. Bei verbotenen Praktiken drohen bis zu 35 Millionen Euro oder 7 Prozent des weltweiten Umsatzes. Wichtig ist uns dabei eine Klarstellung. Der AI Act unterscheidet nicht danach, ob ein System lokal oder in der Cloud läuft. Wer ein Hochrisiko-System betreibt, trägt die Pflichten in beiden Fällen. Die Erfüllbarkeit der Pflichten unterscheidet sich aber deutlich. Risikomanagement, Daten-Governance, technische Dokumentation, Protokollierung und menschliche Aufsicht lassen sich in einer selbst betriebenen Umgebung vollständig nachweisen, weil jede Komponente unter eigener Kontrolle steht. Wer auf einen externen Dienst aufsetzt, dokumentiert dagegen eine Blackbox und haftet trotzdem. In unseren Assessments gehört ein DSGVO- und AI-Act-Readiness-Check deshalb von Anfang an zum Lieferumfang. Er ist keine Rechtsberatung, sondern eine technische Bestandsaufnahme. Sie zeigt, welche Pflichten das geplante System auslöst und wie die Architektur sie erfüllbar macht. Unser Ansatz. Eine integrierte Lösung statt einzelner Werkzeuge BKS-Lab ist kein allgemeiner KI-Dienstleister. Wir bauen keine Websites mit Chatbot, wir schulen keine Prompt-Techniken, und wir implementieren nicht das zwanzigste Copilot-Rollout. Wir sind ein spezialisiertes Team für lokale und selbstgehostete KI-Systeme. Alles, was wir tun, zahlt auf einen Kern ein. Vertrauliches Unternehmenswissen wird in der Infrastruktur des Kunden nutzbar. Unsere Kunden kaufen damit keine Technologieliste, sondern ein Ergebnis. Technisch verbinden wir dafür Bausteine, die es einzeln längst gibt. Erst im Zusammenspiel ergeben sie eine brauchbare Lösung. Volltext- und semantische Suche. Die klassische Stichwortsuche und die bedeutungsbasierte Suche über lokale Embeddings arbeiten in einem gemeinsamen Index. Fuzzy Search. Fehlertolerantes Finden sorgt dafür, dass Tippfehler und abweichende Schreibweisen nicht ins Leere laufen. Wissensmodellierung und Knowledge Graph. Dokumente werden nicht nur indexiert, sondern in ihren Beziehungen erfasst. Welcher Vertrag gehört zu welchem Kunden, welche Anlage zu welchem Vertrag? Named Entity Recognition. Personen, Firmen, Beträge, Fristen und Fachbegriffe werden im Bestand automatisch erkannt. Retrieval-Augmented Generation mit lokalen LLMs. Das Sprachmodell antwortet auf Grundlage der gefundenen Dokumente und belegt jede Antwort mit Quellenverweisen. Kontrolliertes Staging. Inhalte durchlaufen einen geprüften Aufnahmeprozess, bevor sie für Suche und KI freigegeben werden. Prozessautomatisierung. Aus Wissen wird Handlung, etwa durch Klassifizierung, Weiterleitung, Extraktion und Antwortentwürfe. Der entscheidende Punkt ist das Wort „integriert“. Jede dieser Fähigkeiten gibt es als Einzelwerkzeug zu kaufen. Aber sieben Einzelwerkzeuge ergeben kein System. Sie ergeben sieben neue Silos mit sieben Administrationsoberflächen. Wir liefern die Bausteine als eine Engine mit einem gemeinsamen Datenmodell und einem gemeinsamen Berechtigungskonzept. Jeder Inhalt nimmt denselben Weg von der Rohdatei bis zur freigegebenen, durchsuchbaren Wissenseinheit. Am Ende steht eine Auskunft aus einem System mit einem Verantwortlichen. Über allem stehen drei Prinzipien, an die wir uns in jedem Projekt halten. Erstens die Modell- und Infrastruktur-Agnostik. Das Sprachmodell ist bei uns eine austauschbare Komponente, die Umsetzung nicht. Der KI-Markt sortiert sich derzeit im Monatsrhythmus neu. Anbieter können vom Markt verschwinden, Lizenzmodelle können kippen. Die Architektur unserer Kunden darf davon nicht abhängen. Zweitens die hybride Validierung in der Aufbauphase bei rein lokalem Produktivbetrieb. Drittens das automatisierte Staging mit gezielter menschlicher Kontrolle statt manueller Prüfung jedes einzelnen Dokuments. Die beiden letzten Prinzipien beschreiben wir im Abschnitt zum Vorgehen genauer. Sie machen den Unterschied zwischen einem Demo-Piloten und einem belastbaren System aus. Drei Kompetenzbereiche, ein Produktkern Der Kern unserer Strategie ist nicht, möglichst viele KI-Themen gleichzeitig zu bedienen. Wir haben uns bewusst gegen das Bauchladen-Modell entschieden, mit dem viele Beratungen auf die KI-Welle reagiert haben. Stattdessen bündeln wir die Stärken des Teams in drei abgegrenzten Bereichen. Sie zahlen aufeinander ein, und einer von ihnen ist klar der Kern. Bereich 01 · Knowledge Automation als Produktkern Hier liegt das Zentrum unserer Arbeit. Vertrauliches Wissen wird lokal oder selbstgehostet erschlossen. Aus Dokumenten und Datenbeständen wird durchsuchbares, analysierbares und automatisierbares Wissen. Die Grundlage dafür ist die im vorigen Abschnitt beschriebene integrierte Engine. Alles andere, was wir tun, dient letztlich diesem Bereich. Er ist der Grund, warum es BKS-Lab gibt. Er ist auch die Basis des Produkts, das wir weiter unten vorstellen. Bereich 02 · Self-Hosted LLM Enablement als Differenzierung Der zweite Bereich beantwortet die Frage, die am häufigsten unterschätzt wird. Wie betreibt man ein Sprachmodell sinnvoll, sicher und wirtschaftlich selbst? Die Modellwahl ist dabei der kleinste Teil. Wir dimensionieren die Hardware so, dass sie zum tatsächlichen Bedarf passt und nicht zum Wunschdenken. Wir gestalten die Inferenz-Architektur und klären die Betriebsfragen danach, also Updates, Monitoring und Modellwechsel. Für jeden Use Case bewerten wir den richtigen Betriebsort. Das kann im eigenen Unternehmen sein, in einer abgeschotteten Air-Gap-Umgebung oder in einer souveränen EU-Cloud. Dieser Bereich ist keine eigene Produktlinie. Er ist die technologische Grundlage, auf der Bereich 01 überhaupt funktioniert. Für den Kunden bedeutet er vor allem Investitionssicherheit, weil Hardware, Modell und Architektur zum Geschäftszweck passen. Bereich 03 · Quality & Automation als Delivery-Stärke Der dritte Bereich ist der älteste. Test- und Prozessautomatisierung, CI/CD-Pipelines, Quality Gates und dokumentengetriebene Prozesse sind die Arbeit, aus der das Team kommt. Diese Stärke ist durch gelieferte Projekte belegt, etwa durch durchgängig automatisierte Peppol-Rechnungsflüsse. Im KI-Kontext bekommt sie neues Gewicht. Ein KI-System ohne systematische Qualitätssicherung ist ein Demo und kein Werkzeug. Die Disziplin, Qualität messbar zu machen und Prozesse ohne Medienbrüche zu automatisieren, macht aus einem Piloten ein produktives System. Hinter den drei Bereichen steht die gebündelte Erfahrung eines kleinen, tiefen Teams. Dazu gehören lokale und selbstgehostete LLMs, KI-gestützte Software- und Produktentwicklung, Testautomatisierung, Prozessautomatisierung, Data Analytics, Requirements Engineering, Produktmanagement, Consulting, Projektmanagement, Wissensmanagement, Enterprise-Integration und Digitalisierung. Das klingt nach viel für vier Leute. Der Abschnitt zum Team erklärt, warum genau diese Breite bei genau dieser Größe funktioniert. Souveräne IT über die KI hinaus Die Souveränitätsfrage endet nicht bei der KI. Wer einmal angefangen hat, seine Abhängigkeiten zu sortieren, schaut schnell auf die gesamte IT-Landschaft. Auf das ERP-System, dessen Hersteller in die Cloud drängt. Auf die Office- und Collaboration-Umgebung, deren Daten längst außerhalb des Unternehmens liegen. Auf Workloads, die in den vergangenen Jahren in die Public Cloud gewandert sind und dort Jahr für Jahr teurer werden. Aus diesen Gesprächen ist ein eigenes Beratungsfeld entstanden. Wir begleiten Unternehmen strategisch auf dem Weg zu einer souveränen IT, über den einzelnen KI-Anwendungsfall hinaus. Drei Themen kehren dabei regelmäßig wieder. Erstens das ERP. Viele Hersteller drängen ihre Kunden in Cloud-Abonnements, mit Lizenzdruck und auslaufendem Support für Versionen im eigenen Betrieb. Wir helfen bei der nüchternen Bewertung. Welche Daten dürfen in welche Betriebsform? Welche Alternativen gibt es, und wie sieht ein realistischer Fahrplan aus? Zweitens die Office- und Zusammenarbeitsumgebung. Hier prüfen wir, welche vertraulichen Inhalte in welchen Diensten liegen und wo europäische oder selbst betriebene Alternativen wirtschaftlich tragfähig sind. Drittens der Shift von der Public Cloud in die private Cloud. Für Workloads mit stabiler Last und sensiblen Daten rechnet sich der eigene Betrieb oft schon nach wenigen Jahren. Die gewonnene Kontrolle kommt hinzu. Unsere Rolle ist dabei die des Beraters, nicht die des Generalunternehmers für Großmigrationen. Wir analysieren, bewerten und priorisieren, erstellen Zielbilder und begleiten die Umsetzung dort, wo unsere technische Tiefe den Unterschied macht. Der Nutzen liegt in einer Strategie aus einem Guss. KI-Vorhaben, ERP-Entscheidung und Cloud-Strategie folgen denselben Souveränitätskriterien, statt sich zu widersprechen. Unsere Erfahrung aus Enterprise-Integration, Prozessautomatisierung und Selbstbetrieb liefert dafür die Grundlage. Ein Blick in die Werkstatt. Was lokale KI heute kann Wer vor zwei oder drei Jahren zuletzt auf lokale Sprachmodelle geschaut hat, unterschätzt fast zwangsläufig, was heute möglich ist. Seit Meta 2023 mit der Llama-Familie begonnen hat, leistungsfähige Modelle mit offenen Gewichten zu veröffentlichen, hat sich ein breites Feld entwickelt. Das Pariser Unternehmen Mistral AI, ebenfalls 2023 gegründet, liefert offene Modelle aus Europa. Alibabas Qwen-Familie gehört in vielen unabhängigen Vergleichen zu den stärksten offenen Modellen überhaupt. Offene Gewichte bedeuten, dass das Modell als Datei geliefert wird und vollständig auf eigener Hardware läuft. Es gibt keinen API-Aufruf, keinen Datenabfluss und keine Abhängigkeit von der Preispolitik eines Anbieters. Strategisch ist das der entscheidende Punkt. Das Unternehmen besitzt seine KI-Fähigkeit, statt sie zu mieten. Auch wirtschaftlich hat sich die Lage zugunsten des Selbstbetriebs entwickelt. Moderne Verfahren senken den Rechenbedarf der Modelle bei geringem Qualitätsverlust. Mittelgroße Modelle laufen dadurch heute auf einer einzelnen Workstation mit leistungsfähiger Grafikkarte. Für viele Unternehmens-Use-Cases genügt Hardware im Wert eines fünfstelligen Betrags. Sie wird einmal angeschafft, während Cloud-Kosten mit der Nutzung immer weiter wachsen. Wo höhere Last oder größere Modelle gebraucht werden, wächst das Setup auf dedizierte Server mit. Welche Konfiguration wirtschaftlich ist, hängt vom Prozess ab. Genau deshalb gehört die Modell- und Hardwarebewertung bei uns zu jedem Pilotprojekt. Ein weit verbreitetes Missverständnis wollen wir dabei ausräumen. Ein lokales System muss das große Cloud-Modell nicht schlagen, um nützlich zu sein. Es muss die konkrete Aufgabe zuverlässig erfüllen. Für die Klassifikation eingehender Post, die Extraktion von Rechnungsfeldern oder die Beantwortung von Fragen zu einem definierten Dokumentenbestand braucht es kein Modell, das auch Gedichte schreiben kann. Es braucht ein Modell, das die eine Aufgabe messbar gut erledigt. Dazu gehört ein System, das Suche, Kontext und Quellenverweise beisteuert. Die Architektur macht hier mehr Unterschied als die reine Modellgröße. Ein mittleres Modell mit sauberem Zugriff auf die relevanten Dokumente schlägt in umgrenzten Aufgaben regelmäßig ein großes Modell ohne diesen Zugriff. Beim Deployment kennen wir drei Grundmuster. On-Premise auf Servern im eigenen Unternehmen ist der Normalfall. Abgeschottete Umgebungen ganz ohne Internetverbindung setzen wir dort um, wo die Schutzanforderungen es verlangen. Das System wird dann samt Modellen und Updates über kontrollierte Wege versorgt. Wo eigene Hardware nicht infrage kommt, bleibt der Betrieb bei einem europäischen Anbieter, der ausschließlich europäischem Recht unterliegt, eine tragfähige Lösung. Alle drei Varianten folgen derselben Architektur. Der Wechsel zwischen ihnen ist eine Betriebsentscheidung und kein Neubau. Unsere Leistungen. Ein modularer Pfad, kein Katalog Viele Beratungshäuser führen ein Dutzend unabhängiger KI-Angebote im Portfolio. Wir haben uns bewusst dagegen entschieden. Was wir anbieten, ist ein Kundenpfad mit aufeinander aufbauenden Stufen. Am Anfang steht die Orientierung, dann folgt die fokussierte Validierung, am Ende die Produktivsetzung. Kein Kunde muss alle Stufen durchlaufen, und niemand muss in einer festen Reihenfolge einsteigen. Aber jede Stufe erzeugt genau die Entscheidungsgrundlage, die die nächste braucht. Das unterscheidet einen Pfad von einem Katalog. Am Ende jeder Stufe wissen Sie, ob und wie es weitergeht. Der Einstieg. Sovereign AI Starter Der einfachste Einstieg in die Zusammenarbeit ist der Sovereign AI Starter. Nach außen ist er ein Angebot. Intern besteht er aus zwei Teilen, und genau darin liegt sein Nutzen für Sie. Teil eins ist ein Readiness-Check von rund zwei Wochen. Wir nehmen Ihren Use Case auf, sichten die Daten- und Systemlandschaft und prüfen, was wirklich geht. Teil zwei ist eine klar abgegrenzte Umsetzung von rund vier bis sechs Wochen. Den Festpreis dafür legen wir erst nach dem Readiness-Check fest. Zwischen beiden Teilen liegt ein vertraglicher Ausstiegspunkt. So bleibt Ihr Risiko von Anfang an überschaubar. Warum dieser Aufbau? Weil das größte Risiko in frühen KI-Projekten das Scope-Risiko ist, und zwar auf beiden Seiten. Ein Anbieter, der Ihnen vor jeder Analyse einen Festpreis nennt, hat entweder viel Puffer eingepreist oder verhandelt später nach. Wir haben beides erlebt und wollten beides nicht. Der Ausstiegspunkt schützt Sie. Trägt Ihr Use Case nicht, reicht die Datenlage nicht oder liegen die Erwartungen auseinander, endet das Engagement an dieser Stelle. Sie behalten einen verwertbaren Ergebnisbericht statt eines halbfertigen Projekts. Stufe 01. Sovereign AI Assessment Das Assessment richtet sich an Unternehmen, die KI nutzen wollen, aber zuerst Datenkontrolle, Datenschutz, Cloud-Abhängigkeit oder die technische Umsetzbarkeit klären müssen. Es ist ein Beratungsprodukt mit Festpreis. Es liefert eine Entscheidungsgrundlage, keine Software. Wir erarbeiten die Use-Case-Aufnahme, eine Übersicht der Daten- und Systemlandschaft und eine Bewertung der Souveränitätsrisiken. Dazu kommt ein strukturierter Vergleich zwischen Cloud- und Self-Hosted-Varianten, eine technische Zielarchitektur sowie ein Pilotvorschlag mit Roadmap. Seit 2025 gehört ein DSGVO- und AI-Act-Readiness-Check dazu. Er bricht die genannten Fristen auf Ihren konkreten Anwendungsfall herunter. Das Assessment beantwortet die Frage, an der die meisten KI-Vorhaben scheitern, bevor sie beginnen. Lohnt sich das überhaupt, und wenn ja, wo genau? Nicht jeder Use Case rechtfertigt ein lokales LLM. Manche Prozesse sind mit klassischer Volltextsuche besser bedient. Manche Datenbestände sind schlicht nicht souveränitätskritisch. Auch das ist ein Ergebnis, und wir sprechen es offen aus. Stufe 02·A. Sovereign Knowledge Base Pilot Der Knowledge Base Pilot ist unser wichtigstes Pilotangebot und der bevorzugte Weg zu unserem Produktkern. Ein begrenzter, gemeinsam ausgewählter Dokumentenbestand wird lokal oder selbstgehostet nutzbar gemacht. Das können die Verträge einer Abteilung sein, ein technisches Archiv oder ein Bestand an Prüfberichten. Zum Lieferumfang gehören der Volltextindex, semantische Suche und Fuzzy Search, lokal berechnete Embeddings, eine erste Entity-Erkennung, durchgängige Quellenverweise sowie eine Chat- und Analysefunktion über den Bestand. Zwei Dinge sind uns dabei wichtig. Das Erste sind die Quellenverweise. Jede Antwort des Systems verweist auf die Dokumente und Passagen, aus denen sie stammt. Ein System, dessen Antworten man nicht nachprüfen kann, ist für den Unternehmenseinsatz wertlos, egal wie flüssig die Antworten klingen. Das Zweite ist die Messbarkeit. Wir legen vor dem Piloten fest, woran Such- und Antwortqualität gemessen werden. Am Ende liefern wir Zahlen statt Eindrücke. Stufe 02·B. Local LLM und Automation Pilot Nicht jeder Anwendungsfall ist eine Wissensdatenbank. Im zweiten Pilotformat übernimmt ein lokales oder selbstgehostetes LLM einen konkreten Prozess. Das reicht von der Dokumentenanalyse über Support-Szenarien bis zur Vertragsprüfung. Wir wählen Modell und Hardware passend zum Prozess aus, übernehmen das Deployment und integrieren das System in einen Beispielprozess. Test- und Ausgabequalität bewerten wir systematisch. Dazu kommen ein Sicherheits- und Betriebskonzept sowie eine Entscheidungsvorlage. Mit ihr können Sie intern begründen, ob und wie der Prozess produktiv gehen soll. Stufe 03. Produktivsetzung und Betrieb Ein erfolgreich validierter Pilot ist noch kein System für den Alltag. In der dritten Stufe härten wir ihn zu einer belastbaren, integrierten und betreibbaren Lösung. Dazu gehören die technische Härtung und Integration in Ihre Systemlandschaft, ein Rollen-, Sicherheits- und Betriebskonzept, dokumentierte Qualitäts- und Akzeptanznachweise sowie ein Update-, Monitoring- und Supportmodell. Auf Wunsch übernehmen wir den Übergang in Wartung oder Managed Service. Diese Stufe ist bewusst als Verstetigung angelegt. Hier entsteht die langfristige Zusammenarbeit, und hier zeigt sich, ob eine Lösung im echten Betrieb hält, was der Pilot versprochen hat. Aufwände und Angebote stimmen wir individuell auf Ihren Use Case ab. Die genannten Zeiträume sind Erfahrungswerte aus bisherigen Projekten, keine Pauschalen. Wer einen konkreten Rahmen braucht, bekommt ihn im Gespräch und nicht aus einer Preisliste, die Ihren Fall nicht kennt. Wie wir liefern. Vorgehen und Qualitätssicherung Ein Team unserer Größe kann sich weder lange Irrwege noch späte Überraschungen leisten. Unser Vorgehen ist deshalb auf zwei Dinge ausgelegt. Wir machen Fehlannahmen so früh wie möglich sichtbar. Und wir prüfen jedes Projektergebnis darauf, ob es wiederverwendbar ist. Beides klingt selbstverständlich. In der Praxis der Branche wird beides erstaunlich selten diszipliniert betrieben. Für Sie bedeutet dieser Ansatz vor allem Planbarkeit. Agile Validierungszyklen statt Projektende-Überraschung Wir lernen nicht erst am Projektende, ob eine Lösung trägt. Jeder abgegrenzte Delivery-Zyklus folgt demselben kurzen Muster. Kundenproblem und Lernziel präzisieren Requirements und Lösungshypothese festlegen Kleinstmöglichen Prototyp oder nutzbaren Inkrementstand erstellen Nutzen, Qualität, Machbarkeit und Souveränität validieren Kunden- und Nutzungsfeedback auswerten Über Fortführung, Anpassung, Skalierung oder Stopp entscheiden Wiederverwendbare Ergebnisse durch das Productization (Production-Ready) Gate führen Der wichtigste Punkt in dieser Liste ist der sechste. Ein Zyklus darf mit der Entscheidung enden, ein Vorhaben zu stoppen. Das ist kein Scheitern, sondern der Zweck der Übung. Ein nach vier Wochen gestoppter Pilot kostet einen Bruchteil eines nach vierzehn Monaten gescheiterten Projekts. Diese Ehrlichkeit spart Ihnen Geld und schützt Ihre interne Glaubwürdigkeit. Automatisiertes Staging mit Human-in-the-loop Bevor ein Dokument in einem produktiven Index landet, durchläuft es bei uns eine kontrollierte Aufbereitungsstrecke. Erkennung, Extraktion, Klassifikation und Entity-Erkennung laufen automatisch. Dasselbe gilt für Qualitäts-, Plausibilitäts- und Confidence-Prüfungen. Nur Ergebnisse mit geringer Konfidenz, Widersprüchen oder besonderer Kritikalität gehen an einen Menschen. Alles andere läuft durch. Wir nennen das automatisiert-first. Das ist weder die manuelle Prüfung jedes Dokuments noch blindes Vertrauen in die Maschine. Am Ende steht ein auditierbarer Weg von den Rohdaten bis zur produktiven Nutzung. Für jedes Dokument lässt sich nachvollziehen, wann es aufbereitet, geprüft und freigegeben wurde. Genau diese Nachvollziehbarkeit brauchen Sie, wenn eine Aufsichtsbehörde oder ein wichtiger Kunde nachfragt. Hybride LLM-Systeme als Qualitätsstandard Am häufigsten hören wir eine Frage. Ist ein lokales Modell gut genug? Unsere Antwort ist ein Messverfahren, keine Meinung. In der Aufbauphase einer Lösung verarbeiten wir noch keine sensiblen Daten. In dieser Phase setzen wir ein cloudbasiertes Frontier-Modell als Schiedsrichter ein. Es bewertet die Ausgaben des lokalen Modells, deckt systematische Schwächen auf und kalibriert die Qualitätsmetriken. So entsteht ein belastbares Bild davon, wo das lokale System steht und wo nachgesteuert werden muss. Im Produktivbetrieb mit sensiblen Daten arbeitet das System dann rein lokal oder selbstgehostet. Das Cloud-Modell hat seine Aufgabe dann erfüllt und verschwindet aus der Architektur. Sensible Daten haben die Infrastruktur des Kunden zu keinem Zeitpunkt verlassen. Standardisierte Artefakte in jedem Projekt Jedes unserer Projekte arbeitet mit denselben standardisierten Artefakten. Dazu gehören Discovery-Fragebogen und Use-Case-Canvas, Datenklassifikationsbogen, Architekturtemplate und ein Security-und-Sovereignty-Check. Dazu kommen Scope-Dokument, Akzeptanzkriterien, Testplan, Risiko- und Entscheidungslog und Abschlussbericht. Das klingt nach Bürokratie und ist das Gegenteil davon. Weil die Struktur steht, verhandeln wir nicht in jedem Projekt neu, wie ein Statusbericht aussieht. Die Zeit fließt in Inhalte statt in Form. Für Sie hat das einen handfesten Nebeneffekt. Ergebnisse aus verschiedenen Projektphasen bleiben vergleichbar. Und Entscheidungen sind Monate später noch nachvollziehbar. AI-native. Wir arbeiten selbst so, wie wir bauen Unsere interne Arbeit ist gelebte Anwendung der eigenen Strategie. Meeting-Zusammenfassungen, Requirements-Extraktion, Testfallgenerierung, Code-Reviews, Dokumentations- und Angebotsentwürfe, Recherche, Wissensindexierung und Projektstatus-Analysen laufen bei uns KI-gestützt. Wir nutzen dieselben Werkzeugklassen, die wir Kunden empfehlen. Das hat zwei Effekte. Der offensichtliche ist Effizienz. Ein Vier-Personen-Team liefert damit ein Volumen, für das klassisch ein Vielfaches an Personal nötig wäre. Der wichtigere Effekt ist der Praxistest. Wir spüren die Schwächen unserer eigenen Werkzeuge vor unseren Kunden, weil wir täglich damit arbeiten. Das Productization Gate Kundenprojekte werden bei uns nicht automatisch zu Produkten. Aber auch nicht zufällig. Am Ende jedes relevanten Meilensteins entscheidet ein formales Gate über den weiteren Weg eines Ergebnisses. Es kann in den Produktkern übergehen, als wiederverwendbarer Baustein abgelegt werden, ein kundenspezifisches Artefakt bleiben oder bewusst nicht weitergeführt werden. Dahinter steht eine klare Kette. Aus einem validierten Kundenproblem wird ein generalisierbares Lösungsmuster. Daraus wird ein qualifizierter Produktbaustein. Und daraus wird über mehrere Projekte hinweg echte Produktfunktionalität. Diese Disziplin ist der Grund, warum unser Produkt aus gelieferten Projekten entstanden ist und nicht aus einem Pitch-Deck. Aus der Praxis. Drei gelieferte Projekte Versprechen kann jeder. Deshalb an dieser Stelle drei Projekte, die wir tatsächlich geliefert haben. Sie sind anonymisiert, weil unsere Kunden das so wünschen. Konkret genug sind sie trotzdem, um den Zuschnitt unserer Arbeit zu zeigen. Für ein führendes Job-Portal haben wir den Rechnungsprozess durchgängig automatisiert. Peppol-Eingang und -Ausgang, ERP-Integration und Archivierung laufen end-to-end und ohne Medienbrüche. Das Projekt zeigt unsere Delivery-Stärke jenseits der reinen KI-Themen. Elektronische Rechnungsflüsse sind ein dokumentengetriebener Prozess wie aus dem Lehrbuch. Genau auf solchen Strecken übersetzt sich Automatisierung unmittelbar in eingesparte Arbeitsstunden. Seit der E-Rechnungspflicht für inländische B2B-Umsätze, die in Deutschland ab Januar 2025 stufenweise greift, ist das zudem kein freiwilliges Modernisierungsthema mehr. Für ein europäisches Verkehrsunternehmen haben wir CI/CD-Pipelines mit Testautomatisierung und Quality Gates aufgebaut und integriert. Der Fokus lag auf hoher Codequalität in einer gewachsenen Systemlandschaft. Solche Projekte sind die Schule, aus der unsere Qualitätsdisziplin stammt. Wer Quality Gates für fremde Entwicklungsteams baut, lernt Qualität messbar zu machen statt sie zu behaupten. Diese Haltung übertragen wir eins zu eins auf die Bewertung von LLM-Ausgaben. Für ein führendes Verlagshaus haben wir einen MVP zur KI-gestützten Klassifizierung eingehender Post entwickelt. Eingehende E-Mails werden mit NLP und lokalen Modellen klassifiziert und der Bearbeitung zugeführt. Das Projekt zeigt den Kern unseres Ansatzes im Kleinen. Ein begrenzter, klar messbarer Prozess. Lokale Modelle statt Cloud-Abfluss. Und ein MVP-Zuschnitt, der eine Entscheidungsgrundlage liefert, bevor größer investiert wird. Was diese Projekte verbindet, ist kein gemeinsames Werkzeug, sondern ein gemeinsames Muster. In allen drei Fällen ging es um dokumentengetriebene Prozesse. Bisher trugen dort Menschen Informationen von einem System ins nächste. In allen drei Fällen war der Zuschnitt eng genug, um das Ergebnis zu messen. Durchlaufzeit, Fehlerquote, Klassifikationsgüte. Und in allen drei Fällen entstanden Bausteine, die wir über unser Production-Ready Gate weiterverwendet haben. Der Peppol-Baustein aus dem Rechnungsprojekt, die Pipeline-Muster aus dem Verkehrsprojekt und die Klassifikationslogik aus dem Verlagsprojekt fließen heute in die Sovereign Knowledge Engine ein. Fünf Einwände, die wir ernst nehmen In fast jedem Entscheidungsprozess begegnen uns dieselben Einwände. Wir halten sie für berechtigt. An ihnen entscheidet sich, ob ein souveränes KI-Projekt trägt. Deshalb beantworten wir sie hier so, wie wir sie auch im Gespräch beantworten. „Das ist doch teurer als ein Cloud-Abo.“ In der Anschaffung stimmt das. Ein Cloud-Dienst kostet am ersten Tag ein paar hundert Euro im Monat, ein eigener Inferenz-Server einen fünfstelligen Betrag. Über die Laufzeit dreht sich die Rechnung. Cloud-KI wird pro Nutzung abgerechnet. Wer einen Dokumentenprozess mit zehntausenden Vorgängen im Monat automatisiert, zahlt dauerhaft und volumenabhängig. Eigene Hardware ist gekauft und rechnet sich über Jahre. Die laufenden Kosten bestehen im Wesentlichen aus Strom und Wartung. Dazu kommt ein Posten, der in keinem Preisvergleich auftaucht. Was kostet es, wenn vertrauliche Daten in einer fremden Jurisdiktion liegen und Sie das eines Tages erklären müssen? Ihrem Aufsichtsrat, Ihrer Aufsichtsbehörde oder Ihrem wichtigsten Kunden. „Lokale Modelle sind schlechter als GPT und Co.“ In der Breite stimmt das, und wir sagen das auch so. Nur ist die Breite nicht der Maßstab. Ein Unternehmensprozess braucht kein Modell, das Gedichte schreibt und Physikaufgaben löst. Er braucht ein Modell, das die immer gleiche, klar umrissene Aufgabe zuverlässig erledigt. Genau dafür messen wir in jedem Piloten die Qualität am konkreten Korpus, mit dem hybriden Verfahren von oben. Wenn die Qualität nicht reicht, sagen wir das. Und zwar vor der Produktivsetzung, nicht danach. „Unsere IT hat dafür keine Kapazität.“ Das hören wir oft. Es ist der Grund, warum die Stufe der Produktivsetzung ein eigenes Update-, Monitoring- und Supportmodell enthält. Ein souveränes System, das nach dem Projektende niemand betreibt, ist keine Souveränität, sondern ein Risiko. Deshalb übernehmen wir auf Wunsch den Betrieb als Managed Service. Die Daten bleiben dabei in Ihrer Infrastruktur. Wir kümmern uns um Updates, Modellpflege und Überwachung. Ihre IT muss das System nicht bauen und nicht allein tragen. „Was ist, wenn der Modellanbieter morgen verschwindet?“ Diese Frage ist berechtigter, als viele denken. Der KI-Markt konsolidiert sich. Einzelne Anbieter werden verschwinden oder ihre Lizenzbedingungen ändern. Unsere Antwort ist architektonisch. Ein einmal heruntergeladenes offenes Modell läuft weiter, egal was mit seinem Hersteller geschieht. Weil unsere Systeme modell-agnostisch geschnitten sind, ist der Wechsel auf ein anderes Modell ein Austausch, kein Neubau. Das unterscheidet die Lage grundlegend von der Abhängigkeit von einem API-Anbieter, dessen Abschaltung ein System sofort stilllegt. „Wir wissen gar nicht, wo wir anfangen sollen.“ Das ist der häufigste Einwand und der am leichtesten auflösbare. Niemand muss mit einer Unternehmensstrategie beginnen. Der Einstieg, den wir empfehlen, ist ein einzelner, klar abgegrenzter Use Case. Ein begrenzter Dokumentenkorpus und ein erreichbarer Entscheider genügen. Genau dafür haben wir den Sovereign AI Starter gebaut. Zwei Wochen Readiness-Check, dann eine überschaubare Umsetzung. Mehr braucht es nicht, um belastbar zu wissen, ob der Weg für Ihr Unternehmen trägt. Das Produkt. BKS Sovereign Knowledge Engine Aus den validierten Bausteinen unserer Projekte produktisieren wir schrittweise eine eigene Engine, die BKS Sovereign Knowledge Engine. Sie ist installierbar und läuft lokal oder auf Ihren Unternehmensservern. Sie indexiert Dokumente und Datenbestände out-of-the-box, durchsucht und erschließt sie semantisch und macht sie mit lokalen LLMs nutzbar. Ein Missverständnis wollen wir gleich ausräumen. Die Engine ist kein weiteres Wiki, kein Chatbot und kein Dokumentenmanagementsystem. Sie ist eine Wissens- und Automatisierungsschicht über den Informationen, die Sie bereits haben. Ihre Dokumente bleiben, wo sie sind. Die Engine erschließt sie, statt ein weiteres Silo zu schaffen. Dieser Charakter bleibt in allen Ausbaustufen gleich. Souverän betreibbar, herstellerunabhängig auf Modell- und Infrastrukturebene, aus wiederverwendbaren Bausteinen gebaut. Der MVP-Zuschnitt. Bewusst klein, sofort nützlich Der erste nutzbare Stand der Engine umfasst folgende Funktionen. Import lokaler Ordner mit Unterstützung für PDF, Office-Formate, Markdown und Text Volltextsuche, semantische Suche und Fuzzy Search über den gesamten Bestand Lokal berechnete Embeddings und Named Entity Recognition Quellenanzeige für jede Antwort und jeden Treffer Lokaler Chat über die eigenen Dokumente, per Web- oder Desktop-Oberfläche API für Integrationen sowie Export- und Backup-Funktion Genauso bewusst ist die Liste dessen, was der MVP nicht enthält. Dazu zählen vollständige Mandantenfähigkeit, ein Enterprise-Rollenmodell, tiefe SharePoint- oder Confluence-Integration, komplexe Knowledge-Graph-Visualisierung, eine umfangreiche Workflow-Engine, ein App-Marketplace oder gar eine allgemeine No-Code-Plattform. All das gehört in spätere Versionen. Fokus heißt Weglassen. Wir schreiben lieber auf, was fehlt, als es in einer Demo zu verstecken. Wer je ein Produkt gekauft hat, dessen Roadmap-Folien mehr konnten als die Software, weiß, warum uns das wichtig ist. Der Wissenslebenszyklus. Auditierbar von Rohdaten bis zur Nutzung Was die Engine von Ansätzen unterscheidet, die Dokumente ohne kontrollierten Lebenszyklus unmittelbar in einen Index kippen, ist der Weg, den jedes Dokument nimmt. Erkennung, Klassifikation und Entity-Extraktion laufen automatisch. Unsichere Ergebnisse werden markiert und gezielt menschlich geprüft. Erst freigegebene Inhalte stehen für Suche, RAG und Automatisierung bereit. Für regulierte Branchen ist dieser auditierbare Lebenszyklus kein Nice-to-have, sondern die Voraussetzung, um ein solches System überhaupt einführen zu dürfen. Für alle anderen ist er der Unterschied zwischen einem Index, dem man vertraut, und einem, den man nach dem dritten falschen Treffer nicht mehr benutzt. Reifegrad. Aus Piloten zu Version 1.0 Wir vermarkten die Engine nicht als fertiges Enterprise-Produkt, denn das wäre gelogen. Der Reifegradpfad ist öffentlich Teil unserer Strategie. Er führt von der MVP-Demo über erste echte Piloten und daraus extrahierte wiederverwendbare Komponenten bis zum Kandidaten für Version 1.0. Jeder Pilot im Rahmen unserer Leistungsstufe 02·A zahlt auf diesen Pfad ein. Die Kunden der frühen Phasen bekommen dafür überproportional viel Gestaltungseinfluss und Konditionen, die es später nicht mehr geben wird. Wer die Engine am eigenen Korpus sehen will, startet genau dort. Wir indexieren einen begrenzten Dokumentenbestand und messen gemeinsam Such- und Antwortqualität. Woran wir gerade schreiben Ein Teil unserer Arbeit ist das Aufschreiben. Nicht aus Marketinggründen, sondern weil das Formulieren die Gedanken schärft. Und weil die Fragen, die uns Kunden stellen, oft bessere Artikel ergeben als jede Redaktionsplanung. Auf unserer Website erscheint dazu die Insights-Reihe mit kurzen, sachlichen Beiträgen aus der Projektpraxis. Den Anfang hat im Juli 2026 ein Beitrag gemacht, dessen Kernargument auch diesen Text trägt. Die Jurisdiktion zählt, nicht die Postleitzahl. Drei weitere Beiträge sind in Vorbereitung. Ihre Themen zeigen ganz gut, womit wir uns täglich beschäftigen. Der erste erklärt, warum lokale Knowledge Automation kein besseres Wiki ist. Kontrolliertes Staging, Entity-Erkennung und RAG unterscheiden eine Wissens-Engine von einer Volltextsuche mit Chat-Fenster. Der zweite beschreibt die Architektur hybrider LLM-Systeme. Wie kalibriert ein Cloud-Frontier-Modell die Qualität eines lokalen Modells, ohne dass sensible Daten je die eigene Infrastruktur verlassen? Der dritte handelt von uns selbst. Warum ein sehr kleines, hoch automatisiertes Team im KI-Zeitalter einen Struktur- und Kostenvorteil hat. Zu diesem letzten Punkt gleich mehr. Das Team. Klein bleiben als Strategie BKS-Lab ist bewusst kein großes Beratungs- oder Softwarehaus. Wir sind ein sehr kleines, hoch spezialisiertes Technologieunternehmen mit vier Köpfen. Das ist keine Verlegenheit, aus der wir herauswachsen wollen, sondern eine strategische Festlegung. Wir halten die geringe Größe im KI-Zeitalter für einen Struktur- und Kostenvorteil. Intern haben wir sie als Prinzip festgeschrieben. BKS bleibt klein. Michael Boiman verantwortet als CTO und Principal Engineer die technische Gesamtarchitektur, lokale LLMs und Self-Hosted-Setups sowie die Kernentwicklung. Er übersetzt Kundenanforderungen in wiederverwendbare Architektur- und Code-Bausteine. Aus diesen Bausteinen wächst über das Productization Gate unser Produkt. Axel von Dielingen ist die Brücke zwischen Markt, Kunden, Produkt und Umsetzung. Als Product und Delivery Lead verantwortet er Produktmanagement, Angebotsstrukturierung, Consulting und Projektmanagement. Seine Aufgabe lässt sich in einem Satz fassen. Aus Kundenproblemen macht er wiederverwendbare Produktmodule. Michael Kupermann führt Marktentwicklung, Vertrieb und Positionierung. Er fokussiert die Vertriebsarbeit auf Kunden, deren Problem tatsächlich zu unserem Kern passt, also vertrauliches Wissen, lokale KI und Datenkontrolle. Interessenten mit anderen Problemen sagt er lieber früh ab, als Projekte anzunehmen, die nicht zu uns gehören. Als TÜV-Nord-zertifizierter Datenschutzbeauftragter bringt er zudem die Datenschutzperspektive von innen mit. Lior Boiman führt als Geschäftsführer die kaufmännische Seite und verantwortet Requirements Engineering und fachliches Solution Design. Er verbindet Kundenproblem, Produktanforderung und Wirtschaftlichkeit. Er ist die Instanz, die dafür sorgt, dass technisch Elegantes auch ökonomisch trägt. Warum wir das Kleinbleiben für einen Vorteil halten, lässt sich an unserer Arbeitsweise ablesen. Wir wachsen nicht über Headcount, sondern über KI-Unterstützung in der eigenen Arbeit, über wiederverwendbare Bausteine und über einen fokussierten Produktkern. Kurze Entscheidungswege, geringe Fixkosten, hohe technische Tiefe, direkte Kundennähe und schnelle Prototypen sind die Folge dieser Struktur, nicht ihr Marketingversprechen. Für Kunden heißt das etwas sehr Konkretes. Die Person, die im Erstgespräch sitzt, ist dieselbe, die später die Architektur verantwortet. Eine Übergabe vom Vertrieb an ein Delivery-Team, das den Fall zum ersten Mal sieht, gibt es bei uns nicht. Fazit. Souveränität ist machbar, wenn man klein anfängt Fassen wir zusammen. Das wertvollste Wissen der meisten Unternehmen liegt verstreut in Dokumenten, Postfächern und Fachanwendungen. Dort ist es weder auffindbar noch automatisiert nutzbar. Der bequemste Ausweg ist externe Cloud-KI. Er schafft neue Abhängigkeiten und wirft eine Jurisdiktionsfrage auf, die weder ein deutsches Rechenzentrum noch ein C5-Testat beantwortet. US-Anbieter unterliegen dem CLOUD Act, unabhängig davon, wo ihre Server stehen. Gleichzeitig sind lokale Modelle so gut geworden, dass souveräne KI für klar umrissene Prozesse keine Kompromisslösung mehr ist. Sie ist eine belastbare Architekturentscheidung. Unsere Antwort darauf ist kein Großprojekt. Es ist ein Pfad aus kleinen, einzeln absicherbaren Schritten. Ein Readiness-Check von rund zwei Wochen, eine abgegrenzte Umsetzung von vier bis sechs Wochen, mit vertraglichem Ausstiegspunkt dazwischen. Wer danach weitergehen will, dem stehen die Pilotformate und die Produktivsetzung offen. Wer nicht, hat für überschaubares Geld Klarheit gewonnen. Auch das ist ein Ergebnis. Wenn Sie aus diesem langen Text nur drei Dinge mitnehmen, dann diese. Erstens, stellen Sie bei jedem KI-Angebot die Jurisdiktionsfrage, nicht die Standortfrage. Fragen Sie nicht, wo die Server stehen, sondern welchem Recht der Betreiber unterliegt und wer ihn zur Herausgabe verpflichten kann. Die Antwort auf diese eine Frage sortiert den Anbietermarkt schneller als jeder Kriterienkatalog. Zweitens, unterschätzen Sie lokale Modelle nicht anhand von Schlagzeilen über die jeweils neuesten Cloud-Modelle. Für den klar umrissenen Unternehmensprozess, also Dokumente finden, klassifizieren, extrahieren und zusammenfassen, ist die Qualität offener Modelle heute messbar ausreichend. Messen lässt sie sich vor jeder Investitionsentscheidung. Drittens, fangen Sie klein an, aber fangen Sie mit einem echten Korpus an. Ein Pilot mit zwanzig Testdokumenten beweist nichts. Ein abgegrenzter, aber realer Dokumentenbestand mit gemessener Such- und Antwortqualität beweist alles, was Sie für die nächste Entscheidung brauchen. Diese drei Punkte kosten nichts. Und sie funktionieren unabhängig davon, ob Sie am Ende mit uns arbeiten oder mit jemand anderem. Für wen passt dieser Weg? Nach unserer Erfahrung vor allem für Organisationen, deren Wissen zugleich wertvoll und schutzbedürftig ist. Dazu zählen mittelständische Unternehmen mit gewachsenen Dokumentenbeständen aus Jahrzehnten. Ebenso Unternehmen aus regulierten Branchen wie dem Finanz- und Gesundheitswesen. Dazu Kanzleien und Beratungen mit mandantenbezogenen Unterlagen. Und Ingenieur- und Technologieunternehmen, deren Konstruktions- und Entwicklungswissen die eigentliche Substanz der Firma ausmacht. Schließlich öffentliche Stellen, für die die Jurisdiktionsfrage keine Abwägung ist, sondern eine Vorgabe. Gemeinsam ist ihnen, dass ein Datenabfluss nicht nur ärgerlich wäre, sondern existenziell oder rechtlich untragbar. Wer dagegen unkritische Daten verarbeitet und vor allem schnell skalieren will, fährt mit Cloud-KI möglicherweise besser. Auch das sagen wir im Erstgespräch offen. Ein Gespräch mit uns beginnt am besten konkret. Ein klar umrissenes Problem, ein erreichbarer Entscheider, ein begrenzter Dokumentenkorpus. Typische Einstiege aus den letzten Monaten sehen so aus. Die Prüfung, ob vertrauliche Dokumente lokal KI-gestützt durchsuchbar gemacht werden können. Ein begrenzter Pilot, der zeigt, wie lokale LLMs ohne Cloud-Abfluss in einem konkreten Prozess arbeiten. Oder eine lokale Knowledge Base für einen abgegrenzten Korpus mit gemessener Such- und Antwortqualität. Sie erreichen uns per E-Mail an info@bks-lab.com. Die Postadresse lautet Boiman Kupermann Solutions GmbH, Im Zollhafen 12, 50678 Köln. Wir antworten selbst. Das ist ein Vorteil kleiner Teams. BKS-Lab ist eine Marke der Boiman Kupermann Solutions GmbH, Köln. Dieser Beitrag gibt den Stand von Juli 2026 wieder. Insbesondere die regulatorischen Fristen des EU AI Act können sich durch weitere Gesetzgebungsverfahren ändern. Der Text dient der Einordnung und ist keine Rechtsberatung.

Die Jurisdiktion zählt, nicht die Postleitzahl

Michael Kupermann — Wed, 22 Jul 2026 00:00:00 GMT

„Unsere Daten liegen in Frankfurt, also sind sie sicher.“ Dieser Satz fällt in fast jedem Gespräch über KI mit sensiblen Daten. Er ist verständlich, und er greift zu kurz. Was der CLOUD Act tatsächlich regelt Der US CLOUD Act verpflichtet US-Anbieter, auf Anordnung Daten herauszugeben, unabhängig davon, wo diese Daten physisch gespeichert sind. Entscheidend ist nicht der Standort des Rechenzentrums, sondern die Jurisdiktion, der das Unternehmen unterliegt. Ein Server in Deutschland ändert daran nichts, wenn der Betreiber US-amerikanischem Recht unterliegt. Für Entscheider in Compliance, Datenschutz und IT-Sicherheit ist das oft das präziseste Argument überhaupt: Die Postleitzahl des Rechenzentrums beantwortet die eigentliche Frage nicht. Warum eine C5-Zertifizierung nicht davor schützt Das BSI-Testat C5 ist ein wertvoller Sicherheitsnachweis, aber es ändert nichts an der Jurisdiktion. Auch als „souverän“ vermarktete Cloud-Angebote US-amerikanischer Anbieter sind C5-zertifiziert und unterliegen weiterhin dem CLOUD Act. Ein Zertifikat über Betriebssicherheit ist keine Aussage über staatlichen Zugriff. „Wir migrieren nicht Ihre Cloud. Wir bauen Ihre KI souverän.“ Türöffner, aber nicht der Liefergegenstand So wichtig das Jurisdiktions-Argument als Türöffner ist: Es beschreibt ein Motiv, keine Lösung. Wir sind keine Cloud-Migrations- oder Cloud-Exit-Dienstleister. Bestehende Cloud-Landschaften bauen wir nicht zurück. Was wir tun, ist neue KI-Workloads von vornherein dort entstehen zu lassen, wo die Daten bleiben dürfen. Die eigentliche Antwort ist deshalb ein Nutzenversprechen, kein Infrastrukturprojekt: vertrauliches Unternehmenswissen lokal durchsuchbar, analysierbar und automatisierbar machen, ohne Kontrollverlust über Daten und Infrastruktur. Was das praktisch heißt In der Aufbauphase einer Lösung, solange noch keine sensiblen Daten im Spiel sind, darf ein cloudbasiertes Frontier-Modell als Schiedsrichter dienen und die Qualität des lokalen Modells kalibrieren. Im Produktivbetrieb mit sensiblen Daten arbeitet das System dann rein lokal oder selbstgehostet. Modell und Infrastruktur bleiben austauschbar, die Architektur hängt nicht von einem einzelnen Anbieter ab. So wird aus einer abstrakten Souveränitäts-Debatte ein konkreter, überprüfbarer Aufbau: kontrollierbar in Ihrer Infrastruktur, mit einem auditierbaren Weg von den Rohdaten bis zur produktiven Nutzung. Dieser Beitrag dient der Einordnung und ist keine Rechtsberatung. Für die rechtliche Bewertung im Einzelfall ziehen Sie bitte fachkundigen Rat hinzu.

Fünf Loop-Muster für KI-Agenten, und warum das Erzeugen nie der Engpass war

Michael Boiman — Sun, 19 Jul 2026 00:00:00 GMT

import LoopVizBase from '../../components/blog/loop-visualizations/LoopVizBase.astro'; import TopologyOverview from '../../components/blog/loop-visualizations/TopologyOverview.astro'; import MechStateless from '../../components/blog/loop-visualizations/MechStateless.astro'; import MechLearning from '../../components/blog/loop-visualizations/MechLearning.astro'; import MechReview from '../../components/blog/loop-visualizations/MechReview.astro'; import MechVerification from '../../components/blog/loop-visualizations/MechVerification.astro'; import MechWorkflow from '../../components/blog/loop-visualizations/MechWorkflow.astro'; import DecisionTree from '../../components/blog/loop-visualizations/DecisionTree.astro'; import Coverage from '../../components/blog/loop-visualizations/Coverage.astro'; import LensYield from '../../components/blog/loop-visualizations/LensYield.astro'; import ProposalFlow from '../../components/blog/loop-visualizations/ProposalFlow.astro'; import RunCost from '../../components/blog/loop-visualizations/RunCost.astro'; import GateReadings from '../../components/blog/loop-visualizations/GateReadings.astro'; Ein Prompt erzeugt einen Versuch. Eine Schleife erzeugt Versuche, bis ein Kriterium hält. Das klingt nach einer kleinen Änderung, ist aber eine kategorische: Sobald der Agent mehr als einmal läuft, braucht jemand eine Antwort auf zwei Fragen, die vorher der Mensch beiläufig beantwortet hat: ist das gut genug und wann hören wir auf. Genau da entscheidet sich, ob eine Schleife etwas taugt. Nicht am Modell, nicht am Prompt, sondern an dem Teil, den man beim Bauen am liebsten überspringt: dem Bewerter. Dieser Artikel sortiert die fünf Loop-Muster, die sich in der Praxis herausgeschält haben, und hält sie anschließend gegen ein System, das seit Monaten produktiv läuft. Die beiden Befunde daraus sind unbequemer als die Muster selbst. Was ein Loop überhaupt ändert Zwei Bauarten sind zu unterscheiden, und die Verwechslung kostet Geld. Deterministisch heißt: Die Orchestrierung ist geskriptet. Ein Programm entscheidet, was als Nächstes läuft, wie oft und in welcher Reihenfolge; das Modell füllt nur die einzelnen Schritte. Der Ablauf ist damit reproduzierbar und die Kosten sind vorher abschätzbar. Die Ergebnisse nicht, denn das Modell bleibt in jedem einzelnen Schritt nicht-deterministisch. Nicht-deterministisch heißt: Das Modell entscheidet selbst, was der nächste Schritt ist. Flexibler, und für offene Aufgaben oft der einzige Weg. Aber ohne harte Abbruchbedingung läuft so etwas gern länger, als jemandem lieb ist. Alle fünf Muster unten gibt es in beiden Bauarten. Was sie voneinander unterscheidet, ist nicht die Technik, sondern wohin der Rückweg zeigt. Die fünf Muster Vier der fünf schließen sich auf die Arbeit: Das Ergebnis wird geprüft und neu angefasst. Nur das fünfte schließt sich auf den Ablauf. Es verbessert nicht das Ergebnis, sondern die Art, wie das Ergebnis zustande kommt. Deshalb steht seine Rückkante gestrichelt. ① Stateless: läuft, bis es hält Die simpelste Form: Dieselbe Aufgabe läuft wieder und wieder, bis sie als erledigt gilt. Zwischen den Runden bleibt nichts zurück, weder Gedächtnis noch akkumulierte Erkenntnis. Der Reiz liegt genau darin: Es gibt keinen Zustand, der verderben kann. Die Schwachstelle steckt im Wort gilt. Wenn der bauende Agent selbst entscheidet, wann er fertig ist, ist die Abbruchbedingung eine Meinung. Zwei Härtungen machen daraus ein Kriterium: Die Tests entstehen vor dem Bau, und ein zweites, kleineres Modell prüft das Ergebnis gegen die ursprüngliche Anforderung, nicht gegen die Behauptung des ersten, fertig zu sein. Das kleinere Modell spart nebenbei Kosten; der eigentliche Punkt ist aber die Trennung der Rollen. Ein Prüfer, der ein Ergebnis gegen eine Anforderung hält, arbeitet an einer engeren Aufgabe als der Erzeuger. Kontext und Urteilsvermögen braucht er trotzdem, und in manchen Domänen ist Bewerten das Schwerere von beidem. Wie klein er ausfallen darf, ist eine Abwägung und keine Regel. ② Learning: verbessert die Fähigkeit, nicht das Ergebnis Hier ist das Artefakt nicht das Ziel. Das Ziel ist die Fähigkeit, die das Artefakt erzeugt hat. Der Loop lässt sie laufen, beobachtet, und schreibt die Lehren in ein Journal, das die nächste Runde liest. Der entscheidende und meist weggelassene Teil ist der Doppellauf: einmal mit, einmal ohne die Fähigkeit, dieselbe Aufgabe. Ohne diesen Vergleich sammelt man Behauptungen darüber, dass etwas hilft. Mit ihm hat man eine Messung. Das Journal gehört dabei zur Fähigkeit, nicht in eine zentrale Ablage. Eine Lehre, die nicht dort liegt, wo sie gebraucht wird, wird nicht gelesen. ③ Multi-Agent-Review: mehrere Kritiker statt eines Prüfers Statt eines Reviewers laufen mehrere parallel über dasselbe Artefakt, jeder mit einem eigenen Blickwinkel: Fakten, Fachlichkeit, Sicherheit, Stil. Die Befunde laufen zusammen, werden zu Änderungen, und die nächste Runde beginnt. Der Wirkstoff sind die getrennten Blickwinkel. Vier gleich aufgestellte Kritiker liefern nicht etwa viermal exakt dieselbe Liste; dafür sorgt schon das Sampling. Sie teilen aber ihre blinden Stellen, und die bleiben dann zuverlässig unentdeckt, während die schiere Zahl der Durchgänge Absicherung suggeriert. Vier Stimmen, die dieselbe Frage stellen, sehen aus wie Konsens. Andrej Karpathy hat die Variante mit mehreren Modellen, die sich gegenseitig bewerten, unter dem Namen LLM council bekannt gemacht. ④ Verification: einer baut, einer benotet Kein Fächer, sondern ein Gegenüber. Ein Agent implementiert, ein zweiter bewertet gegen eine Metrik und gibt eine Note zurück. Der Bauende hat genau einen Auftrag: die Note hochtreiben. Zwei Details tragen das Muster. Erstens braucht der Bewerter einen Maßstab: eine Spezifikation, eine Rubrik, eine Testsuite. Ohne den bewertet er sein eigenes Bauchgefühl. Zweitens fehlen ihm die Werkzeuge zum Editieren, und das ist kein Versehen: Wer bewerten und zugleich reparieren darf, bewertet milder. Cursor liefert eine besonders strenge Ausprägung davon als Skill in seinem Team-Kit aus: thermo-nuclear review, in zwei Zuschnitten für Codequalität sowie für Sicherheit und Korrektheit. Beide laufen als eigene Subagenten parallel, ihre Befunde werden anschließend zusammengeführt. ⑤ Workflow-Improvement: der Loop verbessert den Loop Der einzige, dessen Rückweg nicht auf die Arbeit zeigt. Drei Rollen: Ein Builder liefert, ein Scorer benotet gegen eine Rubrik, ein Process-Optimizer ändert daraufhin den Ablauf: die Reihenfolge der Schritte, die Aufteilung der Rollen, die Rubrik selbst. Das ist der mächtigste und der heikelste der fünf. Mächtig, weil er das Einzige angreift, was die anderen vier unangetastet lassen. Heikel, weil ein Prozess, der sich selbst umschreibt, per Definition den Zustand verlässt, den jemand einmal freigegeben hat. Welches Muster wann Die Auswahl hängt an einer einzigen Frage: Gibt es einen harten Maßstab? Wenn ja, also eine Testsuite, ein Schema oder ein Compiler, dann braucht es keinen bewertenden Agenten, und die einfachste Schleife genügt. Erst wenn die Qualität nicht mechanisch prüfbar ist, lohnt sich ein Bewerter, und erst dann stellt sich die Frage nach seiner Bauart. Der Test: fünf Muster gegen ein laufendes System Muster sind billig zu beschreiben. Interessant wird es, wenn man sie gegen etwas hält, das wirklich läuft. Wir haben das mit unserem eigenen Agenten-Substrat gemacht, also dem Repo, aus dem heraus wir bei BKS-Lab arbeiten. Nicht als Gedankenspiel, sondern belegt: jede Zeile in der folgenden Übersicht hat eine Datei oder eine Messung hinter sich. Zwei Muster sind da, zwei halb, eines gar nicht. Bemerkenswert ist weniger die Lücke als ihre Art. Alle Lern-Mechanismen in diesem System greifen nach der Arbeit: Der Rückblick am Ende einer Aufgabe, der periodische Audit, die Konsolidierung. Keiner greift währenddessen. Und die A/B-Messung aus Muster ②, der Teil, der aus Behauptung Messung macht, die gibt es nirgends. Ein Grep über das gesamte Repo nach A/B, Ablation, Baseline liefert keinen echten Treffer. Das ist die Sorte Befund, für die man die Muster überhaupt aufschreibt. Ohne den Raster hätte niemand gefragt, ob es einen Loop gibt, der während der Arbeit lernt. Befund 1: Der Bewerter ist der Loop Beim Bauen der Diagramme für diesen Artikel lief das dritte Muster gegen die Seite selbst: drei unabhängige Kritiker, jeder mit einer eigenen Linse, alle über dasselbe Artefakt. Das Ergebnis war so ungleich, dass es zum eigentlichen Befund wurde. Die Linse, die auf Fakten und Ton sah, fand nichts. Sie bestätigte. Die Linse, die das Ergebnis gegen die Quelle hielt, fand einen echten Fehler. Die messende Linse fand acht, mit Zahlen. Zwei davon lagen für die ersten beiden Linsen praktisch außer Reichweite, und zwar nicht weil sie schlechter gearbeitet hätten, sondern weil sie diese Frage gar nicht erst stellten: Die Umrisse der Diagrammkästen lagen bei einem Kontrastverhältnis von 1,18:1 gegen den Hintergrund. Die WCAG fordern für grafische Objekte, die zum Verständnis nötig sind, 3:1. Da die Legende die Kastenform ausdrücklich zur Bedeutung erklärt (durchgezogen heißt vorhanden, gestrichelt heißt fehlend), war der Rand tragend und nicht Dekoration. In einer Zeitleiste war dadurch das erste Segment praktisch unsichtbar, obwohl die Bildunterschrift „Breite = Laufzeit" versprach. Und die kleinste Beschriftung fiel real auf 8,51 Pixel, sobald die Mindestbreite der Grafik griff, also auf jedem Laptop unter etwa 1230 Pixel Breite und auf jedem Telefon. Das sind keine Geschmacksfragen. Beide Befunde lassen sich mit einer Zahl belegen, und beide bleiben unsichtbar für einen Prüfer, der nach Sachfehlern und Tonlage sucht. Daraus folgt eine Regel, die uns einiges erspart hätte: Ein Review ohne Befunde ist kein Gütesiegel, sondern ein Anlass, die Linse zu prüfen. Wenn ein Kritiker nichts findet, ist die erste Frage nicht „ist es gut", sondern „konnte diese Linse überhaupt etwas finden". Ehrlicherweise gehört die Fortsetzung dazu: Beim Nachziehen derselben Korrektur für diesen Artikel stellte sich heraus, dass exakt derselbe Fehler ein zweites Mal in denselben Dateien steckte, nicht in den Kästen, sondern in den Verbindungspfeilen. Wir hatten die Kästen repariert und die Pfeile stehen lassen. Weder der messende Kritiker noch wir hatten danach gesehen. Eine Linse, die einmal etwas findet, findet nicht automatisch alles derselben Art. Befund 2: Erzeugen läuft, Entscheiden staut Der zweite Befund kam ungefragt und ist der unangenehmere. Das System erzeugt Verbesserungsvorschläge über drei verschiedene Mechanismen. Jeder legt seine Vorschläge als Klartext-Datei in einen Ordner, aus dem ein Mensch sie annimmt oder ablehnt. Das ist die bewusst gesetzte Bremse: Der Agent schlägt vor, der Mensch entscheidet. Fünf Vorschläge liegen unentschieden in der Warteschlange. Der älteste liegt dort seit dem 24. Mai, also knapp acht Wochen. Über die Laufzeit wurden acht angenommen und fünf abgelehnt, das Verfahren funktioniert also grundsätzlich. Aber der Stau sitzt nicht beim Erzeugen. Das hat eine unmittelbare Konsequenz für die naheliegendste Reaktion auf diesen ganzen Artikel. Wer jetzt einen weiteren Lern-Loop baut, vergrößert die Warteschlange und löst nichts. Bevor man einen Generator hinzufügt, misst man die Warteschlange. Ein Detail am Rande, das denselben Punkt trifft: Der Ordner, in dem dieses System seine Trend-Historie sammeln sollte, ist leer. Die beobachtende Hälfte des Lern-Loops hat nie Daten gesammelt, nicht weil sie kaputt wäre, sondern weil niemand sie je angestoßen hat. Ein Mechanismus, den niemand vermisst, wenn er nicht läuft, läuft irgendwann nicht mehr. Und noch etwas: Der älteste unentschiedene Vorschlag beschreibt sinngemäß, dass Fähigkeiten mit Nachschlagetabellen einen Lern-Loop brauchen. Also genau das, was Muster ② beschreibt. Der Vorschlag lag zwei Monate herum, bevor uns die Systematik dazu über den Weg lief. Das Wissen war da. Die Entscheidung fehlte. Was eine offene Schleife kostet Eine Schleife ohne funktionierende Abbruchbedingung ist kein theoretisches Risiko. Ein Loop in unserem System hatte eine Obergrenze für seine Runden und einen Zähler, der sie hochzählen sollte. Nur zählte er nicht. Vierzig bezahlte Durchläufe bei Zählerstand null, bevor es jemandem auffiel. Nach der Reparatur: drei Durchläufe, dann geparkt und ein Mensch benachrichtigt. Das ist kein gerechnetes Beispiel, sondern ein protokollierter Vorfall aus dem eigenen Betrieb. Die Lehre ist unspektakulär und wird trotzdem ständig übersprungen: Die Abbruchbedingung ist nicht der langweilige Teil des Loops. Sie ist der Teil, der die Rechnung schreibt. Die Grenze, die wir nicht überschritten haben Bleibt Muster ⑤, der Loop, der den Loop verbessert. Wir haben ihn nicht gebaut, und der Grund ist keine technische Hürde. Die Betriebsregel unseres Systems sagt, dass Beobachtungen und Trends vorschlagen, aber nicht anwenden. Jede dauerhafte Änderung am System geht durch ein menschliches Gate. Ein Process-Optimizer, der seine eigenen Schlüsse umsetzt, bricht diese Regel per Konstruktion. Es gibt zwei ehrliche Lesarten. Eng gefasst wirkt der Optimizer nur innerhalb eines einzelnen Laufs, schreibt keine Datei und schickt seine Erkenntnis als Vorschlag durch dasselbe Gate wie alles andere, und die Regel bleibt intakt. Weit gefasst schreibt er selbst, und dann ist die Regel gefallen, egal wie man es nennt. Das ist eine Haltungsfrage, keine Technikfrage, und sie ist bei uns bewusst offen. Wir schreiben sie hier hin, statt sie zu übergehen: Wer Loops baut, die sich selbst umbauen, sollte vorher wissen, welche Zusage er damit aufgibt. Wo das alles überhaupt sichtbar wurde Beide Befunde oben haben eine unauffällige Gemeinsamkeit, und die ist wichtiger als die Befunde selbst. Wir konnten die Warteschlange zählen, weil sie eine Warteschlange ist: fünf Markdown-Dateien in einem Ordner, mit Datum im Dateinamen. Wir konnten sagen, dass die Trend-Historie leer ist, weil sie ein Verzeichnis ist, das man auflisten kann. Wir konnten belegen, dass die A/B-Messung fehlt, weil ein Grep über ein Repo eine belastbare Aussage ergibt. Und die vierzig bezahlten Läufe stehen in einem Protokoll, das jemand nachlesen kann. Nichts davon wäre in einem gehosteten Dienst mit einem Dashboard sichtbar gewesen, das genau die Metriken zeigt, die sich jemand vorher ausgedacht hat.

Kein Dashboard entscheidet hier, was sichtbar ist. Wer den Zustand zählen will, listet den Ordner auf.

Das Substrat, auf dem unsere Agenten arbeiten, ist deshalb bewusst langweilig: ein Git-Repository aus Markdown und YAML, das der Agent zu Beginn jeder Session liest und im Lauf der Arbeit beschreibt. Keine Datenbank, kein Daemon, nichts zu hosten. Der Zustand des Systems ist eine Menge von Dateien, die man klonen, diffen und zählen kann. Und ein Loop, dessen Ausgabe in solchen Dateien landet, ist von außen prüfbar, statt nur behauptet zu sein. Wir haben dieses Substrat unter MIT-Lizenz veröffentlicht: open-bridge. Es ist bei BKS-Lab entstanden, um BKS-Lab zu betreiben, und es ist genau das Repo, dessen Warteschlange, leeres Trend-Verzeichnis und protokollierte vierzig Läufe in diesem Artikel vorkommen. Was es ist, wie es aufgebaut ist und wo es ehrlicherweise noch dünn ist, steht ausführlich im Artikel zur Freigabe. Wer die fünf Muster hier interessant fand, braucht dafür kein bestimmtes Substrat. Aber irgendeinen Ort, an dem die Ausgabe der Schleife liegen bleibt und zählbar wird, braucht man. Sonst baut man Loops, deren Nutzen sich nie belegen lässt, und merkt den Stau erst, wenn er acht Wochen alt ist. Quellen Die hier verwendete Sortierung in fünf Loop-Typen folgt der Darstellung von AI LABS, Loop Engineering Just 10x Claude Code (Juli 2026): youtube.com/watch?v=8wsM0euQOvc. Die Bestandsaufnahme, beide Befunde und alle Zahlen in diesem Artikel stammen aus unserem eigenen System. LLM council, Andrej Karpathy: github.com/karpathy/llm-council thermo-nuclear review, Cursor Team Kit: github.com/cursor/plugins und cursor.com/marketplace WCAG 2.2, Erfolgskriterium 1.4.11 „Non-text Contrast" (3:1 für grafische Objekte): w3.org/WAI/WCAG22/Understanding/non-text-contrast open-bridge, MIT-lizenziert: github.com/bks-lab/open-bridge · Doku: bks-lab.github.io/open-bridge

open-bridge: Warum wir das Werkzeug, mit dem wir BKS-Lab betreiben, als Open Source freigegeben haben

Michael Boiman — Sun, 21 Jun 2026 00:00:00 GMT

Wer den ganzen Tag mit einem KI-Coding-Agenten arbeitet, kennt den Moment: Man öffnet eine neue Session und fängt bei null an. Man erklärt erneut, wer man ist, welche Repos und Kunden gerade zur Hand sind, welche Konventionen wo gelten und was letzte Woche eigentlich entschieden wurde. Der typische Arbeitsstand ist ein nackter „Eigene-Dateien"-Ordner. Jede Konversation baut Kontext und Struktur von Grund auf neu auf. So fühlt es sich konkret an: „Ich wechsle zwischen Kunden und lade den falschen Kontext." „Ich habe keinen Nachweis, was ich letzte Woche entschieden habe." „Mein Agent vergisst, welche Konventionen wo gelten." „Jede Session erkläre ich neu, wer ich bin und woran ich arbeite." Wir bei BKS-Lab hatten genau dieses Problem, Tag für Tag, über mehrere parallele Kundenkontexte hinweg. Die Lösung, die sich bei uns durchgesetzt hat, ist nicht der nächste clevere Prompt. Es ist ein dauerhafter Ort, den der Agent bei jeder Session liest und beschreibt. Dieser Ort heißt open-bridge, gebaut, um BKS-Lab selbst zu betreiben, und jetzt unter MIT-Lizenz freigegeben. Was open-bridge ist open-bridge ist ein schlichtes Git-Repository aus Markdown- und YAML-Dateien, das ein KI-Coding-Agent zu Beginn jeder Session liest, unabhängig davon, welches Modell oder welches Frontend man verwendet. Das Substrat selbst betreibt nichts: keine Datenbank, kein Daemon, kein SaaS, kein gehosteter Dienst. Nichts zu hosten, keine zweite App zu pflegen. Es sind nur Dateien, die der Agent liest.

„Ein Agent kann eine Datei lesen, aber keinen API-Key halten."

Genau das ist der ganze Punkt. Was Sie heute hineinschreiben, liest Ihr Agent in sechs Monaten noch, ohne Migration, ohne Vendor-Lock-in.

Und weil das Substrat inspizierbarer Klartext ist, muss man keiner Blackbox vertrauen. Repo klonen, jede Datei mit cat ansehen, diffen, versionieren. Das „Gedächtnis" des Agenten sind einfach Dateien, die einem selbst gehören.

Die Analogie

Stellen Sie sich open-bridge als einen Ort vor, an dem sich der Agent erinnern kann: neben Ihrem Modell und Ihrem Werkzeug eine dritte, ortsfeste Schicht. Sie hängt nicht an der Konversation, die endet, sondern liegt im Repo und wird Session für Session dichter.

Zwei Eigenschaften, um die herum es gebaut ist Das Projekt steht auf zwei benannten Ideen. Beide haben wir bei BKS-Lab geprägt; die einfache Bedeutung führt, der Begriff folgt. Context Booster: die dritte Seite Welches Modell und welches Frontend man auch nutzt: open-bridge legt eine unabhängige Kontextschicht daneben, die der Agent immer liest, eine „dritte Seite" neben Modell und Tool. Eine Ecosystem-Registry plus always-on geltende Standing Orders geben dem Agenten dauerhaftes, strukturiertes Wissen über die eigene Welt: wer man ist, welche Repos und Kunden es gibt, was man gestern gemacht hat. Der Agent hört auf zu fragen „GitHub oder Jira?", lädt nicht mehr den falschen Kunden, und auf ein schlichtes „guten Morgen, Briefing" liefert er, was heute zählt. Das ist für uns der wichtigste Zweck von open-bridge. Chaos Tamer: Struktur in unstrukturierte KI-Dialoge Die meiste KI-Arbeit sieht aus wie dieser nackte Ordner: Jeder häuft seinen eigenen Wust an, jede neue Konversation beginnt von vorne. open-bridge bändigt das, indem es eine fertige Struktur mitliefert, statt sie erfinden zu lassen. Es tut drei Dinge: Es hält eine Struktur: ein Board, ein tägliches Log und ein STATUS pro Task. Es legt Wissen während der Arbeit ab: Entscheidungen, Funde und Status landen in Klartext, den der Agent später zurückliest. Und es hält die Arbeit davon ab abzudriften, zurück in den unsortierten Haufen. Aus unstrukturierten Sessions wird ein abgelegtes, dauerhaftes, kumulierendes Protokoll. Wie es aufgebaut ist Im Kern liegen drei semantische Cluster-Ordner und ein Arbeitsbereich: Ein Task-STATUS und eine Log-Zeile sind nichts weiter als Text, den der Agent liest und schreibt, und der in sechs Monaten noch im Diff steht: Der Status-Lebenszyklus ist ein geschlossenes Enum: backlog → doing → review → done. Daneben sitzen die Skills, die modell-agnostischen Verben über dem Substrat, ein einziger skills/-Baum, der per Symlink in die Pfade von Claude Code, Codex, Copilot CLI und Cursor zeigt. Commands sind Skills mit /cmd-Trigger (/briefing, /debrief, /archive, /bridge-status, /bridge-onboard). Und Standing Orders sind always-on geltende Regeln (Code-Stil, Security-Baselines, Logging-Gewohnheiten), die in jeden Dispatch injiziert werden. Warum nicht einfach eine CLAUDE.md Eine CLAUDE.md ist ein einzelnes, flaches Anweisungsblatt. open-bridge ist ein dauerhafter, strukturierter Arbeitsbereich und kann drei Dinge, die eine Dotfile nicht kann: Es trennt Kontext-Welten. Jeder Kunde, jedes Engagement bekommt seinen eigenen Arbeitsbereich, so lädt der Agent nicht die Fakten des falschen Kunden in die Zusammenfassung dieses Kunden. Es führt ein dauerhaftes Arbeitsprotokoll über Sessions hinweg: Board, Log und Task-STATUS überleben das Ende der Konversation. Es zieht geteilte Templates nach, ohne private Daten zu überschreiben, denn der CORE/USER-Split macht genau das. Dieser Split sind zwei Branches, die unterschiedliche Pfade berühren. Die ausgelieferten Templates, Skills und Docs leben auf CORE (main); der eigene angesammelte Kontext (Tasks, Config, Credentials) lebt auf user/{name}. Weil sie sich nicht überschneiden, kollidieren Merges nie: Ein git merge main zieht Upstream-Verbesserungen herein, eigene Daten landen nie auf dem geteilten Branch, und Verbesserungen fließen über /promote zurück, der pro Datei das scope:-Feld liest und routet entsprechend (core → Upstream, org → eigenes Overlay, user → lokal). Ehrlicher Stand Der Teil, den ich am wenigsten überspringen möchte: Wo steht das Projekt wirklich.

Ehrlicher Stand

open-bridge wird von einem kleinen Team gepflegt und läuft auf genau einer selbst-gehosteten Instanz, bei BKS-Lab gebaut, um BKS-Lab zu betreiben, und dann geöffnet. N=1, noch keine externen Nutzer, frisch veröffentlicht. Dieser Artikel beschreibt die Methode und das Substrat, nicht Verbreitungszahlen.

Wir trennen das bewusst in drei Schichten. Erprobt (gebaut und selbst genutzt): das Drei-Cluster-Layout, das Work-System, der CORE/USER-Split, Personas, Standing Orders, die Skills-Schicht und das Scope-Routing laufen ab dem frischen Klon. GitHub-Task-Sync funktioniert für unseren eigenen Gebrauch, Jira ist ungetestet. Wette (falsifizierbar): dass Markdown plus YAML plus git das Substrat bleibt, das künftige Agent-Generationen nativ lesen, und dass eine schlanke MIT-OSS-Methode einen Vendor-Workflow-Builder schlägt für alle, die das Modell frei wechseln wollen. Offen (ungelöst): null externe Nutzer, jede Aussage über die Zielgruppe ist Hypothese, kein Markttest. Die als Default gedachte Workspace-Trennung ist im Prinzip vereinbart, aber noch nicht in open-bridge gebaut. Lesen Sie sie nicht als ausgeliefertes Feature. Und der Wert der ersten Session ist dünn, bis die work/log.md über die Zeit mit echter Arbeit gefüllt ist. Zur Sicherheit gehört dieselbe Nüchternheit: Der Agent schlägt vor, der Mensch entscheidet. Destruktive und ausgehende Aktionen sind pro Aktion gegated ([y]). Secrets leben nie im Repo, nur Referenz-URIs wie azure-keyvault://, 1password:// oder keychain://, und die CI bricht bei einem committeten Secret ab. Nichts telefoniert nach Hause: keine Telemetrie, keine Analytics. Das sind Konventionen, denen der Agent folgt, keine OS-Level-Sandbox. Warum MIT, warum überhaupt öffnen Wir hätten das intern halten können. Aber das Substrat ist die Wette: Wenn Markdown-in-git die richtige Grundlage ist, dann ist sie es für alle, nicht nur für uns. MIT war die bewusste Wahl, für Code und Inhalt gleichermaßen, damit es einen einzigen, unmissverständlichen Wiederverwendungs-Pfad gibt. Eine separate Markenrichtlinie schützt lediglich Name, Brand und Logo; Lizenzen decken Copyright ab, keine Marken. So bleibt die Wiederverwendung reibungsfrei, während die Marke für kommerzielle Angebote auf derselben Architektur geschützt bleibt. So fangen Sie an Kein Signup, keine Warteliste, nichts zu hosten: /bridge-onboard führt durch das geführte Onboarding und richtet alles ein: Ecosystem-Erkennung, Work-System-Config, ein eigener user/{name}-Branch. Die Cross-Tool-Discovery-Symlinks sind committed, daher laufen macOS, Linux und WSL out of the box; unter nativem Windows einmal bin/setup.ps1. Was sofort da ist: ein laufender, leerer Arbeitsbereich. Was eine Wette ist: der kumulierende Wert, der eine über die Zeit gefüllte work/log.md braucht. Ein komplettes Zwei-Kunden-Beispiel liegt in examples/agency/ zum Klonen und Lesen. Am vollständigsten getestet ist open-bridge mit Claude Code (Slash-Commands und Hooks unter .claude/); Codex und Copilot CLI funktionieren über AGENTS.md plus den skills/-Symlink. Gemini CLI, Cursor und Windsurf folgen demselben Standard, sind aber ungetestet. Es ist frisch veröffentlicht, rechnen Sie mit rauen Kanten, und der nützlichste Beitrag gerade ist, ein Issue zu öffnen, wenn Sie eine finden.

open-bridge ausprobieren

MIT-lizenziert, ein git clone entfernt. Klonen, /bridge-onboard starten, fertig.

Auf GitHub ansehen →

Doku + Konzepte: bks-lab.github.io/open-bridge

BKS News: Wie KI einen Newsletter mit 4 Agenten validiert

Michael Boiman — Sun, 28 Dec 2025 00:00:00 GMT

{/ HERO HOOK /}

📰

bks-news: Der AI-Newsletter, der sich selbst validiert

Quellensammlung, Faktencheck, Balance-Prüfung und Urheberrechts-Compliance, automatisiert in 30 Minuten

Was passiert, wenn KI einen Newsletter schreibt und KI ihn anschließend prüft? Hier übernehmen das vier Agenten parallel, jeder mit einer anderen Perspektive. Das Ergebnis ist bks-news: Ein wöchentlicher AI-Newsletter, der durch einen 6-Phasen-Workflow läuft, bevor er veröffentlicht wird. Die 4-Augen-Regel (aber mit KI) Ein Agent sieht Fakten. Ein anderer sieht Bias. Ein dritter sieht Struktur. Ein vierter sieht Risiken. Zusammen sehen sie mehr als du allein. Das ist meine Faustregel für KI-generierte Inhalte: Vier spezialisierte Perspektiven schlagen einen Generalisten. Das Problem mit AI-generierten Inhalten AI kann schreiben. Schnell. Viel. Aber:

🎭

Halluzinationen

Fakten erfunden, Zahlen falsch, Zitate verzerrt

⚖️

Einseitigkeit

Hype-Narrative, fehlende Kritik, keine Gegenperspektiven

⚠️

Urheberrecht

Copy-Paste von Texten, externe Bilder = Abmahnrisiko

Die Lösung: Checks and Balances, aber automatisiert. Die Architektur: 4 Agenten, 4 Perspektiven

🔄 Multi-Agent-Validierung

{/ Fact-Check Agent /}

🔍 Fact-Check Agent

Verifiziert alle Fakten gegen Originalquellen:

• Alle Zahlen und Prozente
• Alle Zitate (Wortlaut + Zuordnung)
• Alle Daten und Release-Dates
• Superlative ("erster", "größter")

WebFetch → Original-Artikel → Vergleich

{/ Devil's Advocate Agent /}

😈 Devil's Advocate Agent

Hinterfragt jede Story kritisch:

• Einseitige Narrative entdecken
• Fehlende Perspektiven aufzeigen
• Hype vs. Substanz unterscheiden
• Gegenargumente recherchieren

WebSearch → Kritische Quellen → Balance

{/ Quality Editor Agent /}

✏️ Quality Editor Agent

Prüft Struktur und Vollständigkeit:

• Alle 10 Sektionen vorhanden?
• Links funktionieren?
• Ton konsistent?
• Frontmatter vollständig?

Struktur-Check → Style-Guide → Fixes

{/ Legal Compliance Agent /}

⚖️ Legal Compliance Agent

BLOCKER, prüft Urheberrecht:

• Keine externen Bilder (§2 UrhG)
• Keine 1:1 Textübernahme
• Zitate korrekt attributiert (§51 UrhG)
• Alle Quellen verifiziert

Verstöße = Veröffentlichung blockiert

Alle 4 Agenten laufen parallel in einem einzigen API-Call. Das macht den Unterschied: ~3 Minuten statt ~12 Minuten sequentiell.

Der 6-Phasen-Workflow

{/ Vertical line /}

{/ Phase 1 /}

📡 Quellensammlung (5 min)

RSS-Feeds von TechCrunch, Ars Technica, The Verge + WebSearch für Breaking News. Ergebnis: 15-20 potenzielle Stories.

WebFetch(rss-feeds) + WebSearch("AI news this week")

{/ Phase 2 /}

🎯 Story-Selektion (10 min)

User wählt 5-7 Stories. Für jede: Deep Dive per WebFetch. Extraktion von Kernaussagen, Zitaten, Zahlen.

🚦 Gate: User bestätigt Auswahl

{/ Phase 3 /}

📝 Draft-Generierung (5 min)

10-Sektionen-Struktur: TL;DR, Story der Woche, Top-Stories, Quick Hits, Tool/Fail/Zahl der Woche, Leseliste, Ausblick.

🚦 Gate: User reviewt Draft

{/ Phase 4 /}

🤖 Multi-Agent-Validierung (3 min)

4 spezialisierte Agenten prüfen parallel. Legal Compliance ist Blocker: Verstöße verhindern die Veröffentlichung.

Task(fact-check) || Task(devil) || Task(quality) || Task(legal)

{/ Phase 5 /}

✅ Finalisierung (2 min)

Korrekturen einarbeiten, finaler Review, Commit ins Repository. GitHub Actions deployen automatisch.

git commit → GitHub Actions → GitHub Pages

{/ Phase 6 /}

🌍 EN-Übersetzung (5 min)

Optionale englische Version. Kulturelle Anpassungen, gleiches Format. Separates Content-Directory für i18n.

Der Tech-Stack

Komponente	Technologie	Warum
Static Site	Astro 5	Content Collections, Zero JS by default
Content	Markdown + Zod	Type-safe Frontmatter, Git-versioniert
Generation	Claude Code + Skills	6-Phasen-Workflow als Skill definiert
Validierung	4 parallele Subagenten	Spezialisierte Perspektiven
Scheduling	launchd + Claude Scheduler	Montag 8:00 automatisch
Hosting	GitHub Pages	Kostenlos, CI/CD integriert

Die Content-Pipeline

Content-Pipeline: Von Cron bis Website

launchd (cron) → run-task.sh

↓

Claude CLI → 6-Phasen-Workflow

↓

output-repo.sh → Git push

↓

GitHub Actions → Static Site live

Warum diese Architektur?

"Warum nicht einfach GPT/Claude direkt nutzen?"

Ein einzelner Agent hat Blind Spots. Der Fact-Checker prüft Zahlen, aber nicht Balance. Der Devil's Advocate hinterfragt alles, prüft aber keine Urheberrechte. Spezialisierung + Parallelisierung = bessere Ergebnisse.

"Warum User-Gates statt Full-Auto?"

Human-in-the-Loop für kritische Entscheidungen: Welche Stories sind relevant? Welche Korrekturen sind nötig? Full-Auto für repetitive Tasks, Human für Judgment Calls.

"Warum Static Site statt CMS?"

Git = Single Source of Truth. Jeder Newsletter ist ein Commit. Rollback jederzeit möglich. Kein Server = keine Angriffsfläche. GitHub Actions = kostenlose CI/CD.

Das Ergebnis

bks-news in Zahlen

~30

Minuten pro Newsletter

Validierungs-Agenten

Sektionen pro Ausgabe

Sprachen (DE + EN)

Was ich dabei gelernt habe Der wichtigste Punkt: Mehr Agenten ≠ besser. Vier ist der Sweet Spot: genug Perspektiven, wenig Overhead. Mit zwei Agenten hast du zu wenig Abdeckung, mit sechs wird's unübersichtlich. Was noch hakt: Der Devil's Advocate ist manchmal zu kritisch, da muss ich die Prompts noch nachschärfen Manche Stories brauchen mehr manuelle Recherche als andere Die EN-Übersetzung könnte kulturell besser angepasst sein (amerikanische Beispiele statt deutsche) Stand heute funktioniert das System, aber ich iteriere weiter. Das ist der Kern von agentic coding: Bauen, testen, verbessern.

Selbst ausprobieren?

bks-news ist live und wird wöchentlich aktualisiert. Der Generator-Skill ist Teil meines Claude Code Setups.

📰 bks-news lesen 🔧 Skills vs. MCP Artikel

Quellen & Weiterführendes bks-news auf GitHub Pages Skills vs. MCP: Warum Markdown Server schlägt Anthropic: Claude Code Best Practices Astro 5 Content Collections

Skills vs. MCP: Warum Markdown-Dateien Server-Protokolle schlagen

Michael Boiman — Fri, 19 Dec 2025 00:00:00 GMT

{/ NEWS HOOK /}

📢

18. Dezember 2025

Anthropic macht Skills zum Open Standard

9 Tage nach Gründung der Agentic AI Foundation bei der Linux Foundation

KI-Automation verlangt eine Grundsatzentscheidung: MCP-Server oder Markdown-Skills? Nach einem Jahr MCP (seit November 2024) und intensiver Skills-Nutzung seit Oktober 2025 kenne ich die Antwort. 20+ produktive Skills später – vom 337-Zeilen Job-Application-Workflow bis zum Meta-Skill – bin ich komplett MCP-frei. Alles läuft über Skills mit curl, CLI-Tools und Shell-Scripts. Die Ausgangslage: Zwei Standards, ein Ziel MCP (Model Context Protocol) war der Hype 2024. Das Protokoll verbindet KI-Modelle mit externen Tools und Datenquellen. Leistungsfähig, flexibel – und komplex. Skills sind die Evolution: Markdown-Dateien, die Claude Workflows, Wissen und Prozesse beibringen. Ohne Server. Ohne Dependencies. Ohne Konfiguration.

💡 Meine Erfahrung

Ich habe beide Ansätze intensiv genutzt. Anfangs MCP für GitHub, Clockify, Teams. Dann alles zu Skills migriert: Die gleichen APIs, aber ohne Server – nur curl und CLI. Heute? 100% Skills, 0% MCP.

Case Study: Der job-application Skill Erst das Beispiel, dann die Theorie. So komplex können Skills sein:

🎯 job-application Skill – Enterprise-Komplexität in Markdown

337

Zeilen Code

Workflow-Phasen

Modi (Single/Batch)

36x

Schneller

Enthält:

• 7 separate Phasen-Dokumentationen in references/
• Helper-Scripts für EML-Parsing und URL-Extraktion
• Integration mit brainstorming und verification Skills
• Automatische Modus-Erkennung (Single vs. Batch)

Ein vollständiges Workflow-System – in Markdown.

Pro-Techniken: Ultrathink & Claude Code Power-Features Skills entfalten ihre Kraft mit den richtigen Techniken. Die wichtigsten seit Dezember 2025:

🧠 Ultrathink Mode

Claude Code hat abgestufte Thinking-Budgets. Je komplexer das Problem, desto mehr Rechenzeit:

"think" → ~4.000 Tokens

"think hard" → ~10.000 Tokens

"ultrathink" → ~32.000 Tokens

Wann nutzen? Architektur-Entscheidungen, komplexes Debugging, Multi-File-Refactoring.

⏪ Checkpoints & Rewind

Claude speichert automatisch Code-Snapshots vor jeder Änderung. Zurückspulen:

Esc + Esc oder /rewind

Der praktische Effekt: Mutigere Experimente, keine Angst vor Fehlern. Code und Konversation separat wiederherstellbar.

🔌 Plugin System

Skills, Hooks, Commands und MCP-Server als verteilbare Bundles:

/plugin install superpowers

/plugin marketplace

/plugin enable/disable

Team-Vorteil: Komplettes Setup in Sekunden teilbar. Onboarding wird trivial.

🔧 LSP Integration

Claude Code 2.0.74 bringt Language Server Protocol direkt ins Terminal:

✓ Go-to-Definition
✓ Find References
✓ Hover Documentation

Bedeutung: IDE-Level Code-Intelligence ohne IDE.

💡 Praxis-Tipp: Ultrathink + Skills

Kombiniere Skills mit Ultrathink für maximale Qualität. Beispiel:

In deinem Prompt:
"ultrathink" und analysiere diese Architektur mit dem code-review Skill

Der Skill gibt die Struktur vor, Ultrathink liefert die Tiefe. Beides zusammen = Enterprise-Grade Reviews.

Die 3 Säulen der Skills-Überlegenheit Token-Effizienz: Das Killer-Argument Das Kontext-Fenster ist begrenzt. Jedes geladene Token verdrängt Arbeitsinhalt.

📊 Token-Verbrauch im Vergleich

{/ Skills /}

✅ Skills: Progressive Loading

Metadata (immer geladen) ~100 Tokens

SKILL.md Body (bei Trigger) ~500 Tokens

Resources (on-demand) Optional

{/ MCP /}

⚠️ MCP: Vollständig geladen

Tool-Definitionen 10.000+ Tokens

Schema-Validierung 5.000+ Tokens

Error Handling 2.000+ Tokens

Simon Willison: GitHubs MCP-Definition allein verbraucht "tens of thousands of tokens"

Zero-Setup: Der kategorische Unterschied

{/ Skill /}

✅ Skill installieren

{cp -r my-skill/ ~/.claude/skills/

Fertig. }

⏱️ <1 Minute

{/ MCP /}

⚠️ MCP Server installieren

{git clone server-repo
cd server-repo
npm install
npm run build
.mcp.json konfigurieren
Credentials einrichten
Server starten
Fehler debuggen...}

⏱️ 30-60 Minuten

Portabilität: Einmal schreiben, überall nutzen Skills sind Markdown-Dateien. Dieselbe Datei funktioniert in:

Claude Desktop Claude Code Cursor Weitere Plattformen

MCP-Server erfordern plattformspezifische Implementierungen. Der Aufwand vervielfacht sich mit jeder Plattform. Wann Skills, wann MCP?

🎯 Entscheidungsbaum

{/ Start /}

Braucht dein Workflow persistente/streaming Verbindungen?

{/ Branch /}

NEIN (fast immer)

↓

✅

Skills verwenden

• REST/GraphQL APIs

• Workflows & Prozesse

• Domain-Wissen

• CLI-Tools (gh, curl, etc.)

JA (selten)

↓

🔌

MCP erwägen

• WebSocket-Streaming

• Pub/Sub-Events

• Connection-Pooling

• Echtzeit-Feeds

Was Skills wirklich können: Live-APIs ohne MCP

Skills können jede API aufrufen, die über HTTP erreichbar ist – sie wissen, wie man curl, CLI-Tools und Shell-Scripts verwendet.

{/ Clockify /}

⏱️

clockify-skill

curl -X POST clockify.me/api/v1/...

REST API direkt

{/ GitHub /}

🐙

github-manager

gh api graphql -f query='...'

GraphQL via CLI

{/ Teams /}

💬

teams-analyzer

curl graph.microsoft.com/...

Microsoft Graph API

Das sind keine Toys – das sind 33+ produktive Shell-Scripts, die täglich laufen.

Die häufigsten Einwände

{/ Einwand 1 /}

"Für Live-Daten braucht man MCP" Falsch

Skills können ebenfalls Live-Daten holen – über curl, CLI-Tools und Scripts.

Mein clockify-skill ruft die Clockify REST API direkt auf.
Mein teams-analyzer nutzt Microsoft Graph API.
Mein github-manager führt GraphQL-Mutations aus.

Kein MCP-Server nötig. Ich bin inzwischen komplett MCP-frei.

{/ Einwand 2 /}

"Skills sind nur für simple Aufgaben" Falsch

Mein job-application Skill hat 337 Zeilen, 7 Phasen, 2 Modi und Helper-Scripts.

Das ist Enterprise-Komplexität – in einer Markdown-Datei. Die Grenze ist nicht die Technologie, sondern die Vorstellungskraft.

{/ Einwand 3 /}

"MCP ist der Industriestandard" Beide

Die Linux Foundation übernahm MCP. Anthropic öffnete Skills am 18. Dezember 2025. Beide Standards haben Berechtigung.

Die Frage ist nicht "Standard oder nicht", sondern "Welches Tool für welchen Job?" – und für die meisten Aufgaben brauchst du keinen Server.

{/ Einwand 4 - NEU /}

"MCP-Server sind sicher" Vorsicht

Bitsight Technologies (Dezember 2025): Rund 1.000 MCP-Server sind öffentlich im Internet ohne Authentifizierung erreichbar.

Die MCP-Spezifikation empfiehlt OAuth 2.1, aber Authentifizierung ist optional. Viele Deployments sind ungeschützt.

Skills haben dieses Problem nicht: Keine Server = keine Angriffsfläche.

Skills + MCP: Die richtige Kombination Skills und MCP ergänzen sich.

Aufgabe	Bessere Wahl	Warum
Wiederholbare Workflows	Skills	Prozesse in Markdown dokumentiert
Domain-Wissen einbetten	Skills	References-Ordner für Dokumentation
Checklisten & Prozesse	Skills	Strukturierte Anleitungen
REST/GraphQL APIs	Skills	curl/CLI in Scripts reicht
WebSocket-Streaming	MCP	Persistente Verbindung nötig
Connection Pooling	MCP	Server-State erforderlich

🍳 Die Kochen-Analogie

📖

Skills = Rezepte

WAS kochen, welche Zutaten, welche Schritte

🔧

MCP = Küchengeräte

WIE schneiden, mixen, garen

Die meisten brauchen bessere Rezepte, nicht bessere Geräte.

Der Weg zu produktiven Skills

{/ Vertical line /}

{/ Phase 1 /}

Assessment: Deine Top-5 Aufgaben

1. Welche 5 Aufgaben hast du diese Woche am häufigsten wiederholt?
2. Welche davon folgen einem klaren Ablauf (Schritte 1-2-3)?
3. Wähle die einfachste mit dem höchsten Wiederholungsfaktor

Beispiel: "E-Mails beantworten" → zu komplex. "Meeting-Protokoll erstellen" → perfekt.

{/ Phase 2 /}

Erster Skill: 20 Minuten bis zum Prototyp

1. Erstelle ~/.claude/skills/mein-skill/SKILL.md
2. Schreibe: name: + description: (wann triggern?)
3. Füge 3-5 Workflow-Schritte hinzu
4. Teste mit Claude: Triggert der Skill?

Tipp: Starte mit einem Skill, der nur Anweisungen gibt – keine Scripts, keine Komplexität.

{/ Phase 3 /}

Skill-Library: Wachsen lassen

• references/ für Dokumentation, die Claude lesen soll
• scripts/ für Operationen, die nicht im Chat passieren sollten
• Jeden Monat: 1 neuer Skill für eine wiederkehrende Aufgabe

Nach 6 Monaten hast du 6+ Skills – das entspricht meiner Erfahrung nach ~80% der Routine-Automation.

Das Ökosystem wächst

✅ Skills Partner Directory

Atlassian Canva Notion Figma Cloudflare Stripe Zapier

🔌 MCP Adoption

VS Code GitHub Cursor Goose Amp OpenCode

Fazit: Skills first – und oft nichts anderes

Meine Realität

20+ produktive Skills später: komplett MCP-frei. Alles läuft über Skills mit curl, CLI-Tools und Shell-Scripts.

1 Starte mit Skills – sie können mehr als erwartet
2 REST, GraphQL, OAuth? Skills beherrschen das
3 MCP bleibt für WebSocket-Streaming und persistente Verbindungen

Für die meisten Aufgaben reicht eine Markdown-Datei.

Bereit für deine ersten Skills?

Starte mit dem offiziellen Skill-Creator von Anthropic oder lass uns gemeinsam deine Workflows automatisieren.

🚀 Skills auf GitHub 💬 Beratung anfragen

Quellen Standards & Ankündigungen VentureBeat: Anthropic launches enterprise Agent Skills and opens the standard TechCrunch: OpenAI, Anthropic, and Block join new Linux Foundation effort SiliconANGLE: Anthropic makes agent Skills open standard TechCrunch: Google lanciert managed MCP Server Claude Code Features Anthropic: Claude Code Best Practices ClaudeLog: What is Ultrathink GitHub: Claude Code CHANGELOG Anthropic Skills GitHub Analysen & Deep Dives tty4.dev: Agent Skills - a thin alternative to MCP? Simon Willison: MCP Token Overhead Analysis Armin Ronacher: Agentic Coding Recommendations SiliconANGLE: MCP Security Risks

Bewerbung 2.0: KI-gestützte Bewerbungserstellung

Michael Boiman — Sun, 16 Nov 2025 00:00:00 GMT

Bewerbungen schreiben ist zeitfressend: Stellenausschreibung analysieren, Anforderungen extrahieren, mit dem eigenen CV abgleichen, ein überzeugendes Anschreiben formulieren, PDF erstellen. Pro Bewerbung 30-45 Minuten – bei zehn Stellenangeboten sind das 6 Stunden konzentrierte Arbeit. Ich habe einen systematischen Prozess entwickelt, der das automatisiert und dabei die Qualität sicherstellt. Das Ergebnis: Von der Stellenausschreibung zur fertigen Bewerbungs-PDF in durchschnittlich 10 Minuten – inklusive menschlicher Review-Schritte. Die 80%-Regel für Bewerbungen Erst ab 80% Match zwischen deinen Skills und den Anforderungen lohnt sich die Bewerbung. Darunter? Zeit besser investieren. Das ist meine Faustregel, die der Skill automatisch prüft. Jede Bewerbung durchläuft sechs Phasen mit Quality Gates – und die Coverage-Rate ist das erste harte Kriterium. Der Prozess: Sechs Phasen zur fertigen Bewerbung Jede Bewerbung durchläuft einen strukturierten Workflow mit automatischen Qualitätsprüfungen und menschlicher Kontrolle an kritischen Stellen.

{/ START INPUT /}

📥 Input: Stellenausschreibung URL

{/ VERTICAL TIMELINE /}

{/ Vertical Gradient Line /}

{/ PHASE 1: BRAINSTORMING /}

💡

Phase 1: Brainstorming

🎯 Positionierungsstrategie festlegen

• Unternehmenskultur analysieren (Startup/Enterprise/Corporate)
• 4 Strategien evaluieren und vergleichen
• Tone & Balance für Anschreiben festlegen

✓ Quality Gate: Strategie explizit dokumentiert

{/ PHASE 2: REQUIREMENT EXTRACTION /}

📋

Phase 2: Requirement Extraction

🔍 Anforderungen aus Stellenausschreibung extrahieren

• Must-Have & Nice-to-Have Skills identifizieren
• Firmendaten und Ansprechperson extrahieren
• Anforderungen mit Job-Posting vergleichen
• Datum verifizieren (immer aktuell)

✓ Quality Gate: Mindestens 6 Requirements

{/ PHASE 3: CV MAPPING - HIGHLIGHTED /}

🔗

Phase 3: CV Mapping

🎯 Kernaktivität: Requirement-zu-CV Matching

Format: "Sie suchen → Ich biete → Siehe CV"

Beispiel: Playwright → BKS E2E Framework → Seite 2, Berufserfahrung

• Jedes Requirement mit CV vergleichen und matchen
• Konkrete CV-Referenzen mit Sektion angeben
• Coverage-Rate berechnen

✓ Quality Gate: ≥80% Coverage erforderlich

{/ PHASE 4: CONTENT GENERATION - HIGHLIGHTED /}

✍️

Phase 4: Content Generation

📧 Kernaktivität: Anschreiben & Email erstellen

• Test-driven Approach (Tests BEFORE Content)
• Mapping in Anschreiben integrieren
• Email-Draft mit AI-Disclosure erstellen
• Generated Content mit Tests vergleichen

✓ Quality Gate: Alle Tests PASS

{/ PHASE 5: INTERACTIVE REVIEW - HUMAN HIGHLIGHT /}

👁️

Phase 5: Interactive Review

🎯 Human-in-the-Loop: Pflicht-Checkpoint

• Vollständiges Anschreiben anzeigen
• Alle Requirement-Mappings präsentieren
• Coverage-Analyse zeigen
• User MUSS explizit bestätigen

✓ Quality Gate: User Approval erforderlich

{/ PHASE 6: PDF GENERATION & VERIFICATION /}

📄

Phase 6: PDF Generation & Verification

✅ PDF erstellen und verifizieren

• JSON validieren vor Script-Ausführung
• PDF generieren (Anschreiben + CV)
• PDF mit Erwartungen vergleichen (Size, Type)
• PDF öffnen für manuelle Review
• Evidence sammeln und dokumentieren

✓ Quality Gate: 7-Punkte Verification PASS

{/ END OUTPUT /}

📤 Output: Bewerbungs-PDF + Email Draft

Intelligentes Batch-Processing Der entscheidende Punkt: Du kannst mehrere Stellenausschreibungen parallel verarbeiten. Das macht den Unterschied.

{/ Step 1 /}

📋

10 Job-URLs

Input

→

{/ Step 2 /}

🤖

Parallel-Analyse

Alle gleichzeitig

→

{/ Step 3 /}

📊

Intelligentes Scoring

Ranking & Priorisierung

→

{/ Step 4 /}

⚡

Top 3 parallel

6-Phasen je Job

→

{/ Step 5 /}

✅

3 PDFs + Emails

Versandbereit

⚡ Der Effizienzgewinn

Sequenziell:

10 Bewerbungen nacheinander
→ 6 Stunden

Parallel:

Alle 10 Jobs gleichzeitig!
Max(Job Times) = 10 Minuten

Was ich dabei gelernt habe Nach 10+ Bewerbungen mit diesem System kann ich sagen: Das Scoring funktioniert bemerkenswert gut. Die Jobs mit 85%+ Match haben tatsächlich zu Gesprächen geführt. Die mit 72% waren Zeitverschwendung. Was noch nicht perfekt läuft: Bei sehr kreativen Stellenausschreibungen (ohne klare Requirements) muss ich manuell nachhelfen Manche Unternehmen haben keine klare Ansprechperson – da rate ich noch Das PDF-Layout könnte schöner sein (arbeite an einem LaTeX-Generator) Der wichtigste Punkt: Transparenz ist kein Nachteil. Bei KI-fokussierten Positionen ist es sogar ein Pluspunkt – du demonstrierst, was du kannst. Der META-Aspekt: Wenn sich der Prozess selbst demonstriert Bei Bewerbungen auf KI-fokussierte Positionen passiert etwas Interessantes: Der Prozess demonstriert sich selbst. Eine Bewerbung, die mit KI-Unterstützung erstellt wurde, zeigt gleichzeitig, wie Multi-Agent-Systeme, intelligente Workflows und automatisierte Qualitätsprüfung funktionieren. Das macht die Art der Bewerbung zur Kompetenz-Demonstration. AI-Transparenz als Prinzip Wichtig zu verstehen: Jede Bewerbung kommuniziert klar, dass KI-Unterstützung im Prozess eingesetzt wird. Keine Täuschungsversuche, keine Verschleierung. Ich nutze moderne Werkzeuge – und sage das offen.

🔍 Warum Transparenz wichtig ist

Ehrliche Kommunikation schafft Vertrauen. Der Einsatz von KI-Tools zur Effizienzsteigerung ist eine professionelle Entscheidung – die finale Verantwortung und alle inhaltlichen Entscheidungen bleiben beim Menschen.

Wie du das nutzen kannst Dieser Artikel dient als Referenz für Bewerbungen, in denen du KI-Unterstützung erwähnst. Er zeigt: Systematisches Vorgehen, technische Kompetenz, transparenter Umgang mit modernen Werkzeugen. Konkret bedeutet das: Process Engineering, Workflow-Automatisierung, Qualitätssicherung und ethischer KI-Einsatz – alles Fähigkeiten, die in modernen Tech-Positionen gefragt sind.

Interesse an diesem Ansatz?

Für Fragen zu KI-gestützten Prozessen, Workflow-Automatisierung oder Beratung zu ähnlichen Projekten stehe ich gerne zur Verfügung.

💬 Kontakt aufnehmen 🔗 LinkedIn Profil

Googles A2A-Protokoll: Warum KI-Agenten endlich miteinander sprechen lernen

Michael Boiman — Sat, 13 Sep 2025 00:00:00 GMT

import Tabs from '../../components/Tabs.tsx'; import BlogDashboardVisualization from '../../components/blog/BlogDashboardVisualization.astro'; {/ Die Revolution, die niemand kommen sah /} Das alltägliche Problem: Isolierte KI-Systeme Viele Unternehmen nutzen heute verschiedene KI-Systeme: ChatGPT für den Kundenservice, Claude für Dokumentenanalyse, spezialisierte Tools für einzelne Aufgaben. Jedes System funktioniert gut, aber sie können nicht miteinander kommunizieren. Das ist ineffizient: Mitarbeiter müssen Daten manuell zwischen Systemen übertragen, was Zeit kostet und Fehler verursacht. Google hat mit dem Agent-to-Agent (A2A) Protocol eine praktische Lösung entwickelt. Die Linux Foundation unterstützt das Projekt. Hier erfahren Sie, was das konkret bedeutet.

Testen Sie A2A live in unserer Demo

Der A2A-Agent im BKS Labor läuft in zwei Modi:

🎬 Dashboard-Visualisierung

Beobachten Sie unten die animierte Darstellung des A2A-Netzwerks mit MCP-Integration, Tool-Orchestrierung und Echtzeit-Verarbeitung.

💬 Interaktiver Chat

Testen Sie den A2A-Agenten selbst. Stellen Sie Fragen und verfolgen Sie die Orchestrierung live.

🎯 Dashboard-Demo ansehen 💬 Mit A2A-Agent chatten

Was A2A ist, in einfachen Worten

KI-Agenten heute

87%

der Unternehmen nutzen 3+ KI-Systeme

Integrationsaufwand

4.2h

täglich pro Wissensarbeiter

Marktpotenzial

$7.6B

Agent-Markt 2025

Die Grundidee A2A ist wie ein universeller Übersetzer für KI-Systeme. So wie Menschen verschiedene Sprachen sprechen, "sprechen" auch KI-Agenten verschiedene Protokolle. A2A schafft eine gemeinsame Sprache, damit alle miteinander arbeiten können.

🌐 Service Discovery Visualisierung:

Diese Animation demonstriert den A2A Service Discovery Prozess:

1. Registrierung: Agenten melden ihre Fähigkeiten beim Service Registry an
2. Discovery: Agenten suchen und finden benötigte Services automatisch
3. Direkte Kommunikation: Peer-to-Peer Verbindungen ohne zentrale Vermittlung

💡 Beobachten Sie, wie die Agenten sich automatisch vernetzen

Ein praktisches Beispiel:

Vorher vs. Nachher

Ohne A2A

1. Kunde sendet E-Mail mit Rechnung
2. Mitarbeiter lädt Rechnung manuell herunter
3. Öffnet OCR-Software, scannt Rechnung
4. Kopiert Daten in Excel
5. Überträgt Daten ins ERP-System
6. Sendet Bestätigung an Kunden

Dauer: 15-20 Minuten

Mit A2A

1. E-Mail-Agent empfängt Rechnung
2. Übergibt automatisch an OCR-Agent
3. OCR-Agent extrahiert Daten
4. Validierungs-Agent prüft Richtigkeit
5. ERP-Agent bucht automatisch
6. Kommunikations-Agent bestätigt Kunde

Dauer: 30 Sekunden

📊 Rechnungsverarbeitung im Zeitraffer:

Diese Visualisierung zeigt den kompletten Workflow einer automatischen Rechnungsverarbeitung:

• 30-Sekunden-Prozess: Von der E-Mail bis zur ERP-Buchung
• 6 spezialisierte Agenten: E-Mail, OCR, Validierung, Compliance, ERP, Bestätigung
• Performance: 120 Rechnungen/Stunde mit 99.8% Automatisierung
• Protokolle: JSON-RPC für Kommunikation, mTLS für Sicherheit

💡 Im Activity-Log sehen Sie jeden einzelnen Verarbeitungsschritt

Warum das den Integrationsaufwand senkt Bisher mussten Unternehmen für jede Verbindung zwischen zwei KI-Systemen eine eigene Schnittstelle programmieren. Bei 10 Systemen sind das theoretisch 45 verschiedene Verbindungen. Mit A2A braucht jedes System nur eine Verbindung: zum A2A-Netzwerk.

Das Netzwerk-Effekt-Prinzip

Ohne A2A: O(n²) Komplexität

• 5 Systeme = 10 Verbindungen
• 10 Systeme = 45 Verbindungen
• 20 Systeme = 190 Verbindungen

Mit A2A: O(n) Komplexität

• 5 Systeme = 5 Verbindungen
• 10 Systeme = 10 Verbindungen
• 20 Systeme = 20 Verbindungen

Drei Vorteile für Unternehmen Sofortige Interoperabilität Was es bedeutet: Ihre bestehenden KI-Investitionen werden nicht obsolet, sondern wertvoller.

Business Case

Ein mittelständisches Logistikunternehmen hatte:

ChatGPT für Kundenanfragen
Claude für Dokumentenanalyse
Eigene KI für Routenoptimierung
SAP für Auftragsmanagement

Mit A2A arbeiten alle Systeme zusammen. Der ROI der bestehenden Investitionen steigt um 300%.

Neue Services in Minuten statt Monaten Was es bedeutet: Neue KI-Services lassen sich integrieren, ohne ein eigenes Projekt aufzusetzen. Ein Beispiel: Ein spezialisierter Übersetzungs-Agent kommt hinzu und kommuniziert sofort mit dem gesamten System. Ohne Integrationsprojekt, ohne Wartezeit. Kostenreduktion durch Spezialisierung Was es bedeutet: Statt einer teuren Allzweck-KI nutzen Sie viele günstige Spezial-Agenten.

Kostenvergleich

Ansatz	Monatliche Kosten	Leistung
Eine große Enterprise-KI	50.000€	Gut in allem, stark in nichts
10 spezialisierte A2A-Agenten	15.000€	Stark in ihrem jeweiligen Bereich

Konkrete Anwendungsfälle nach Branchen 💳 Finanzwesen & Banking

Automatisierte Rechnungsverarbeitung mit A2A

Agent-Netzwerk:

📧

E-Mail Agent: Empfängt und kategorisiert

👁️

OCR Agent: Extrahiert Daten aus PDFs

⚖️

Compliance Agent: Prüft Richtlinien

✅

Freigabe Agent: Automatische Genehmigung

💰

Payment Agent: Optimale Zahlungsausführung

Business Impact:

95%

Weniger manuelle Arbeit

60%

Schnellere Durchlaufzeiten

Zahlungsverzug

💡 Weitere Use Cases im Finanzwesen: KYC-Prozesse, Fraud Detection, Kreditprüfung, Regulatory Reporting

🛍️ E-Commerce & Retail

Kundenservice in Echtzeit

Ein Kunde beschwert sich über eine verspätete Lieferung. Das A2A-Netzwerk reagiert sofort:

⚡ Parallele Verarbeitung in 3 Sekunden:

Input-Phase

• Sprach-Agent transkribiert
• Sentiment-Analyse läuft

Processing-Phase

• CRM ruft Historie ab
• Logistik prüft Status
• Lösungs-Agent kalkuliert

Output-Phase

• Personalisierte Antwort
• Kompensation angeboten
• Follow-up geplant

💡 Weitere Use Cases im E-Commerce: Produktempfehlungen, Bestandsmanagement, Dynamic Pricing, Returns Processing

🏭 Produktion & Industrie 4.0

Supply Chain Orchestrierung

A2A-gesteuerte Prozesse:

🏭 Produktions-Agent: Optimiert Fertigungslinien
📦 Lager-Agent: Predictive Inventory Management
🚚 Logistik-Agent: Route Optimization
🔧 Maintenance-Agent: Predictive Maintenance
⚠️ Quality-Agent: Echtzeit-Qualitätskontrolle

Messbare Erfolge:

Produktionseffizienz +35%

Ausfallzeiten -60%

Lagerkosten -25%

Liefergenauigkeit 99.5%

💡 Weitere Use Cases in der Produktion: Digital Twin Integration, Energy Management, Workforce Planning, Supplier Collaboration

🏥 Gesundheitswesen

Koordinierte Patientenversorgung

🚨 Kritische Prozesse mit A2A:

Notfallmanagement:

• Triage-Agent priorisiert Fälle
• Ressourcen-Agent koordiniert Personal
• Dokumentations-Agent erfasst alles

Patientenbetreuung:

• Diagnose-Agent unterstützt Ärzte
• Medikations-Agent prüft Wechselwirkungen
• Follow-up-Agent plant Nachsorge

💡 Weitere Use Cases im Gesundheitswesen: Telemedizin, Laborautomation, Versicherungsabwicklung, Forschungsdatenanalyse

🎯 Orchestrator-Visualisierung:

Beobachten Sie, wie der zentrale A2A-Orchestrator multiple Services koordiniert:

• Parallele Abfragen: CRM, Logistik und Lösungs-Services arbeiten gleichzeitig
• Koordination: KI-gesteuerte Entscheidungsfindung
• 3 Sekunden Antwortzeit: Von der Kundenanfrage zur fertigen Lösung
• Multi-Channel: Ein System für alle Kommunikationskanäle

💡 Die Animation zeigt die gleichzeitige Verarbeitung aller Services

Die Herausforderungen Offene Punkte Standardisierung dauert: Nicht alle Anbieter werden sofort mitmachen Sicherheitsbedenken: Mehr Vernetzung bedeutet mehr Angriffsfläche Abhängigkeiten: Was passiert, wenn ein kritischer Agent ausfällt? Kosten der Umstellung: Bestehende Systeme müssen angepasst werden Warum es sich trotzdem lohnt Die Geschichte zeigt: Standards setzen sich durch, wenn der Nutzen die Kosten übersteigt. E-Mail, Internet, Cloud Computing: Alle hatten anfangs Skeptiker. A2A löst ein so grundlegendes Problem, dass mit breiter Adoption zu rechnen ist. Technische Basis Kernkomponenten: Service Discovery, JSON-RPC 2.0, WebSockets Sicherheit: Zero-Trust, mTLS, End-to-End Encryption Standards: Linux Foundation geprüft und unterstützt Der Weg zur Implementierung Starten Sie mit einem Pilot-Projekt Wählen Sie einen Prozess, zum Beispiel Rechnungsverarbeitung oder Kundenservice Verbinden Sie 2-3 Systeme: klein anfangen, schnell lernen Messen Sie den Erfolg: Zeit, Kosten, Fehlerquote Skalieren Sie schrittweise: bei Erfolg weitere Prozesse einbinden Zeithorizont 2025: Early Adopters starten erste Pilotprojekte 2026: A2A wird zum de-facto Standard 2027+: Vollautonome Geschäftsprozesse werden Realität Was für einen frühen Einstieg spricht Wer bei Cloud Computing zu spät kam, zahlt heute noch den Preis. Bei A2A verhält es sich ähnlich. Early Adopters können: Erfahrung sammeln, während andere noch evaluieren Talente anziehen, die mit neuen Protokollen arbeiten wollen Standards mitgestalten, statt ihnen später folgen zu müssen Wettbewerbsvorteile sichern, bevor es alle machen Der entscheidende Unterschied A2A ist die Infrastruktur für die nächste Generation von Geschäftsprozessen. Wie das Internet die Grundlage für E-Commerce schuf, ermöglicht A2A autonome Geschäftsprozesse. Offen ist weniger das Ob als der Zeitpunkt. Wer früh beginnt, verschafft sich einen Vorsprung.

A2A im eigenen Prozess erproben?

Im Local LLM & Automation Pilot zeigen wir, wie Agenten-Protokolle wie A2A in einem konkreten, abgegrenzten Prozess arbeiten, lokal oder selbstgehostet, ohne Cloud-Abfluss.

Gespräch vereinbaren Offizielle Ankündigung lesen

Weiterführende Informationen Linux Foundation: A2A Project Launch Google Cloud: A2A Donation to Linux Foundation GitHub: A2A Specification

CI/CD-Pipelines mit Quality Gates nach der Testpyramide

Michael Boiman — Wed, 10 Sep 2025 00:00:00 GMT

import BlogDashboardVisualizationEnhanced from '../../components/blog/BlogDashboardVisualizationEnhanced.astro'; Das Problem mit manuellen Deployments Wer kennt es nicht: Ein kritischer Fix muss in Production, aber niemand traut sich so richtig. Die Tests wurden "lokal ausgeführt", die Integration "sollte funktionieren". Das Ergebnis ist oft vorhersehbar.

⚡

12 Min

Pipeline-Dauer

Statt 45 Min manuell

🧪

3200+

Tests automatisiert

Unit, Integration, E2E

🚀

95%

Success Rate

Mit Quality Gates

⏮️

< 2 Min

Rollback-Zeit

Bei Problemen

Nach Jahren in verschiedenen Teams habe ich gelernt: Der Unterschied zwischen chaotischen und stabilen Deployments liegt in gut durchdachten Quality Gates. Nicht in perfekten Prozessen oder teuren Tools, sondern in pragmatischen Checkpoints, die Fehler früh abfangen. Interaktive Pipeline-Visualisierung Bevor wir in die Details gehen, hier eine interaktive Visualisierung einer modernen CI/CD-Pipeline. Sie zeigt alle wichtigen Stages von Commit bis Production:

💡 Tipp: Die Visualisierung zeigt den Datenfluss durch die Pipeline. Jede Stage fungiert als Quality Gate mit spezifischen Checks.

Die Testpyramide als Grundlage Die Testpyramide ist ein simples Konzept, das oft missverstanden wird. Es geht nicht darum, möglichst viele Tests zu haben, sondern die richtigen Tests zur richtigen Zeit. In der obigen Visualisierung sehen Sie, wie die verschiedenen Test-Typen in die Pipeline integriert sind. Unit Tests (Die Basis) Unit Tests sind der Workhorse jeder Pipeline. Sie laufen in Millisekunden und prüfen isolierte Funktionen. Ein Beispiel aus einem aktuellen Projekt: Wir hatten 3000+ Unit Tests, die in unter 30 Sekunden durchliefen. Das ermöglichte schnelles Feedback bei jedem Commit. Der Trick dabei: Unit Tests müssen wirklich isoliert sein. Keine Datenbankzugriffe, keine API-Calls, keine Dateisystem-Operationen. Alles wird gemockt. Das macht sie schnell und zuverlässig. Integration Tests (Die Mitte) Integration Tests prüfen, ob Komponenten zusammenarbeiten. Typisches Beispiel: Ein API-Endpoint, der Daten aus der Datenbank holt. Hier nutzen wir TestContainers für eine echte Postgres-Instanz, die für jeden Testlauf frisch gestartet wird. Diese Tests dauern länger (bei uns etwa 2-3 Minuten für 200 Tests), finden aber Probleme, die Unit Tests nicht sehen können: SQL-Syntax-Fehler, falsche Joins, Transaktionsprobleme. E2E Tests (Die Spitze) End-to-End Tests simulieren echte User-Interaktionen. Wir nutzen Playwright für kritische User Journeys: Login, Checkout, Hauptfeatures. Mehr als 20-30 E2E Tests sind meist Overkill - sie sind langsam, flaky und teuer in der Wartung. Ein Learning aus der Praxis: E2E Tests nur für business-kritische Pfade. Alles andere testet man besser auf niedrigeren Ebenen. Vorher vs. Nachher: Der Unterschied ist dramatisch

Deployment-Prozess im Vergleich

❌ Ohne CI/CD Pipeline

💻

Code lokal testen 10 Min

📦

Manuell builden 5 Min

🧪

Tests manuell ausführen 15 Min

📤

Auf Server hochladen 5 Min

🔧

Server konfigurieren 10 Min

Total: 45-60 Minuten

🔄 Manuelle Schritte fehleranfällig
⚠️ Keine automatischen Rollbacks
⏰ Zeitintensiv und repetitiv

✅ Mit CI/CD Pipeline

📦

Git Push triggert Pipeline 0 Sek

🔨

Automatischer Build 2 Min

🧪

3200+ Tests parallel 5 Min

🔒

Security & Quality Checks 3 Min

🚀

Auto-Deploy mit Rollback 2 Min

Total: 12 Minuten

✨ Vollautomatisch und reproduzierbar
🎯 95% Success Rate
⚡ 4x schneller als manuell

Quality Gates in der Pipeline Quality Gates sind automatische Checkpoints, die entscheiden, ob Code weitergehen darf. In der Visualisierung oben sind sie als Verbindungen zwischen den Stages dargestellt - jede mit spezifischen Bedingungen. Hier unsere wichtigsten Gates: Gate 1: Build & Compile Klingt trivial, ist aber wichtig. Der Code muss kompilieren, Dependencies müssen auflösbar sein, Linting-Regeln erfüllt. Dauert bei uns unter 2 Minuten. Schlägt dieses Gate fehl, geht nichts weiter. Gate 2: Unit Tests & Coverage Alle Unit Tests müssen grün sein. Code Coverage sollte nicht unter einen definierten Wert fallen (bei uns 80%). Wichtig: Coverage ist kein Selbstzweck. 80% sinnvolle Tests sind besser als 100% mit sinnlosen Assertions. Gate 3: Security Scanning Automatische Checks auf bekannte Vulnerabilities in Dependencies. Wir nutzen Trivy, das in unter einer Minute durchläuft. Critical Issues blockieren sofort, High Issues erzeugen Warnings. Ein praktischer Tipp: Nicht jede "High" Vulnerability ist wirklich kritisch für eure Anwendung. Kontext matters. Aber ignoriert sie nicht einfach - dokumentiert, warum ihr sie akzeptiert. Gate 4: Integration Tests Hier wird's interessant. Integration Tests in der CI sind eine Herausforderung. Unsere Lösung: Eine dedizierte Test-Datenbank, die nach jedem Run zurückgesetzt wird. TestContainers für externe Services. Das Gate blockiert bei fehlgeschlagenen Tests oder wenn die Performance drastisch abfällt. Gate 5: Deployment in Staging Nach allen Tests deployen wir automatisch in eine Staging-Umgebung. Smoke Tests prüfen, ob die Anwendung überhaupt startet und basic Health-Checks durchlaufen. Erst wenn das funktioniert, ist der Code bereit für Production. Multi-Service Deployments In einer Microservice-Architektur wird's komplexer. Services haben Dependencies, müssen in der richtigen Reihenfolge deployed werden.

Service-Dependency Management in der Praxis

Unser Ansatz: Service-Independence durch API-Versioning. Jeder Service muss mit der vorherigen Version der anderen Services funktionieren.

Beispiel: User-Service Update

✓ User-Service v2 funktioniert mit Order-Service v1

✓ Feature Flags für neue Features

✓ Rollback jederzeit möglich

Deployment-Strategien im Detail

🔵 Blue-Green

Zwei identische Umgebungen

Rollback < 30s

Downtime 0

Kosten 2x Infra

🐤 Canary Release

Schrittweises Rollout

Start 5% Traffic

Monitoring Real-time

Rollout Graduell

🚩 Feature Flags

Deploy ≠ Release

Toggle Instant

A/B Tests ✓

Risk Minimal

Feature Flags in Action:

Mein persönlicher Favorit: Code ist deployed aber deaktiviert. Aktivierung ohne neues Deployment.

Wenn's schiefgeht: Rollback-Strategien Trotz aller Gates gehen Dinge schief. Wichtig ist, wie schnell man reagieren kann. Automatische Rollbacks triggern bei uns bei: Error-Rate über 5%, Response-Time über 2 Sekunden (p95), Memory/CPU über 90%. Das System switched automatisch zur letzten stabilen Version. Manuelle Rollbacks sind manchmal nötig bei Business-Logic-Fehlern, die technisch korrekt sind. Beispiel: Ein Rabatt-Code, der 90% statt 9% Rabatt gibt. Technisch läuft alles, Business ist not amused. Learnings aus der Praxis Nach mehreren Jahren mit CI/CD-Pipelines in verschiedenen Teams: Fangt klein an. Nicht gleich die perfekte Pipeline bauen wollen. Erst Build automatisieren, dann Tests, dann Deployment. Step by step. Tests müssen schnell sein. Wenn die Pipeline 30 Minuten läuft, nutzt sie keiner. Optimiert für Geschwindigkeit. Parallelisiert wo möglich. Flaky Tests sind Gift. Ein Test, der random fehlschlägt, zerstört das Vertrauen in die Pipeline. Entweder fixen oder löschen. Monitoring ist wichtiger als Tests. Ihr könnt nicht alles testen. Aber ihr könnt alles monitoren. Gute Observability findet Probleme, die Tests nie gefunden hätten. Menschen sind wichtiger als Prozesse. Die beste Pipeline nützt nichts, wenn das Team sie nicht versteht oder umgeht. Holt alle ins Boot, erklärt das Warum, nicht nur das Was. Tools sind zweitrangig Jenkins, GitLab CI, GitHub Actions - am Ende ist es egal. Wichtiger sind die Prinzipien: Automatisierung, schnelles Feedback, sichere Rollbacks. Wir nutzen GitHub Actions, weil es gut in unseren Stack passt. Vorher war's Jenkins, davor TeamCity. Die Migration war jeweils in einer Woche erledigt, weil die Konzepte gleich blieben. Der wichtigste Tipp Wenn ihr nur eine Sache aus diesem Artikel mitnehmt: Automatisiert eure Deployments. Nicht perfekt, nicht vollständig, aber automatisiert. Manuelle Deployments sind der größte Risikofaktor in der Software-Entwicklung. Jeder manuelle Schritt ist eine Fehlerquelle. Jede Checkliste wird irgendwann ignoriert. Automation vergisst nicht, macht keine Tippfehler, deployed nicht aus Versehen auf dem falschen Server. Fazit CI/CD mit Quality Gates ist kein Hexenwerk. Es ist die konsequente Anwendung simpler Prinzipien: Teste früh, teste oft, automatisiere alles, sei bereit für Rollbacks. Die Testpyramide gibt die Struktur vor, Quality Gates setzen sie durch. Das Ergebnis: Schnellere, sicherere Deployments mit weniger Stress für alle Beteiligten. Start where you are, use what you have, do what you can. Der beste Zeitpunkt für CI/CD war gestern, der zweitbeste ist heute.

KI-Agenten in der Praxis: Erkenntnisse aus einem 90-Minuten-Workshop

Michael Boiman — Tue, 15 Jul 2025 00:00:00 GMT

import StatsDashboard from '../../components/blog/a2a-visualizations/StatsDashboard.astro'; Was KI-Agenten heute schon können In einem 90-minütigen Remote-Workshop für einen deutschen Transport-Konzern ging es um eine zentrale Frage: Wie können KI-Agenten die tägliche Entwicklungsarbeit unterstützen? 12 Entwickler nahmen teil, um zu sehen, was über einfache Code-Vervollständigung hinaus möglich ist. Das Ergebnis: Ein Python-Bug wurde in 5 Minuten analysiert, getestet und behoben - vollständig automatisiert. Die Kern-Demonstration: 5-Minuten Bug-Fix Das Highlight des Workshops war eine Live-Demonstration mit einem fehlerhaften Python-Skript. Der KI-Agent durchlief dabei drei Phasen: Analyse: Der Agent identifizierte mehrere Probleme im Code - von Logik-Bugs bis zu fehlender Fehlerbehandlung Refactoring: Automatische Umstrukturierung nach Python Best Practices Testing: Erstellung und Ausführung von Tests, inklusive automatischer Fehlerbehebung Das Besondere: Der gesamte Prozess dauerte nur 5 Minuten. Was normalerweise Stunden in Anspruch nimmt, wurde live vor den Augen der Teilnehmer automatisiert. Weitere Demonstrationen Terminal-Steuerung Ein weiteres Beispiel zeigte die Fähigkeit von Agenten, komplexe Terminal-Operationen durchzuführen. Bei einem Kubernetes-Problem identifizierte und behob der Agent selbstständig eine fehlerhafte Deployment-Konfiguration - alles über natürlichsprachliche Anweisungen. Integration mit externen Tools Das Model Context Protocol (MCP) ermöglicht Agenten die direkte Integration mit externen Tools. Im Workshop wurden Integrationen mit GitHub, Jira, Elastic und Browser-Automation demonstriert. Beispiel: Ein Agent kann eigenständig GitHub Issues erstellen, Jira-Stories abrufen oder Logs in Elastic durchsuchen - alles über natürlichsprachliche Befehle. Qualitätssicherung durch Instructions Ein wichtiges Konzept sind "Instructions" - wiederverwendbare Regeln für konsistente Code-Qualität. Diese können auf verschiedenen Ebenen definiert werden: Unternehmensweite Standards (Security, Compliance) Architektur-Vorgaben (Clean Code, Design Patterns) Tool-spezifische Regeln (Linter, Frameworks) Im Workshop wurde gezeigt, wie der gleiche Prompt mit unterschiedlichen Instructions zu deutlich unterschiedlicher Code-Qualität führt. Zusammenarbeit mehrerer Agenten Besonders interessant wurde es bei der Demonstration von Multi-Agent-Workflows. Mehrere spezialisierte Agenten können zusammenarbeiten - ähnlich wie ein Entwickler-Team: Ein Agent schreibt Tests Ein anderer implementiert die Funktionalität Ein dritter überprüft die Code-Qualität Diese Agenten arbeiten koordiniert zusammen und übergeben sich gegenseitig die Ergebnisse. Task Master: Automatisches Projekt-Management Ein weiteres Tool namens "Task Master" wurde vorgestellt. Es verwandelt Product Requirements in strukturierte Aufgabenlisten: Liest Requirements-Dokumente ein Erstellt automatisch priorisierte Aufgaben Analysiert Komplexität und teilt große Aufgaben auf Integriert sich direkt in gängige Entwicklungsumgebungen In der Demo wurde aus einem dreiseitigen Dokument in zwei Minuten ein vollständiger Projektplan mit über 50 Aufgaben generiert. Workshop-Materialien Alle technischen Details, Code-Beispiele und Workshop-Materialien sind verfügbar unter: github.com/bks-lab/ai-dev-playbook Das Repository enthält: Präsentationsfolien Demo-Anleitungen Code-Beispiele Best Practices Praktische Erkenntnisse Was funktioniert gut: Einfache, repetitive Aufgaben werden zuverlässig automatisiert Code-Analyse und Refactoring sparen Zeit Tests können schnell generiert werden Integration mit bestehenden Tools ist möglich Wichtige Überlegungen: Sicherheitsaspekte müssen bedacht werden Nicht jede Aufgabe eignet sich für Automatisierung Die Qualität hängt stark von den Instructions ab Entwickler behalten die Kontrolle und Verantwortung Fazit KI-Agenten können bereits heute viele Entwicklungsaufgaben unterstützen. Die im Workshop gezeigten Beispiele sind keine Zukunftsmusik, sondern praktisch einsetzbar. Der Schlüssel liegt in der schrittweisen Einführung: Erst kleine Experimente, dann Integration in bestehende Prozesse. Weiterführende Informationen Für Teams, die das Thema vertiefen möchten, bieten wir verschiedene Workshop-Formate an - von Halbtages-Sessions bis zu mehrtägigen Implementierungs-Workshops. Bei Interesse an einem Workshop oder weiteren Informationen können Sie uns gerne kontaktieren.

KI-Textanalyse: Aus E-Mails werden strukturierte Daten

Michael Boiman — Tue, 15 Oct 2024 00:00:00 GMT

Wir haben eine Textanalyse-App entwickelt, die aus unstrukturierten Texten konkrete Informationen extrahiert. Keine Theorie, sondern direkt nutzbar. Live-Demo

Textanalyse testen

Fügen Sie einen Text oder eine URL ein. Die App zeigt, was sie daraus lesen kann.

Vollbild öffnen

Was kann die App? Die Textanalyse erkennt aus beliebigen Texten: Sentiment: Ist der Text positiv, negativ oder neutral? Aufgaben: Welche To-Dos stecken im Text? Mit Prioritäten. Termine: Alle Datumsangaben werden erkannt und normalisiert Personen: Wer wird erwähnt und in welcher Rolle? Technologien: Welche Tools und Systeme kommen vor? Ein konkretes Beispiel Sie kopieren eine lange E-Mail-Kette in die App. Nach wenigen Sekunden bekommen Sie: Das Ergebnis lässt sich als JSON exportieren und direkt in andere Systeme einspeisen. Wo hilft das konkret? Nach zwei Monaten Praxiseinsatz haben wir gesehen, dass die App vor allem in drei Bereichen Zeit spart: Meeting-Protokolle: Statt manuell alle Aufgaben rauszuschreiben, macht das die App. Die Kollegen aus dem Projektmanagement sparen pro Meeting etwa 15 Minuten. Support-Tickets: Die Sentiment-Analyse zeigt sofort, welche Kunden wirklich verärgert sind. Das Support-Team kann kritische Fälle priorisieren. Dokumenten-Review: Bei der Durchsicht von Anforderungsdokumenten findet die App alle versteckten Deadlines und technischen Abhängigkeiten. Technische Details Die App basiert auf einem Large Language Model, das wir für Unternehmenstexte optimiert haben. Die Verarbeitung läuft über eine REST-API: Das Frontend ist mit Streamlit gebaut - nichts Fancy, aber es funktioniert. Die durchschnittliche Antwortzeit liegt bei 2-3 Sekunden für normale Texte. Integration in bestehende Systeme Die meisten unserer Kunden nutzen die API-Schnittstelle. Ein Beispiel: Automatisches Tagging von Jira-Tickets basierend auf der Textanalyse. Der Webhook empfängt neue Tickets, schickt den Text an unsere API und updated die Labels. Für Batch-Verarbeitung gibt es einen CSV-Import. Praktisch für die monatliche Auswertung von Kundenfeedback.

Textanalyse für Ihr Unternehmen

Die Demo zeigt die Grundfunktionen. Für Unternehmen passen wir die Analyse an spezifische Anforderungen an.

Kontakt aufnehmen

Elevator Pitch Generator: Zeit ist Geld

Michael Boiman — Tue, 01 Oct 2024 00:00:00 GMT

Je nachdem welche Etage Sie wählen, generiert dieses Tool einen passenden Pitch für Ihr Unternehmen. Von der kurzen 30-Sekunden-Version bis zum ausführlichen 10-Minuten-Gespräch. Die Idee: Im Aufzug hat man unterschiedlich viel Zeit - nutzen wir sie optimal. Das Tool in Aktion

In Vollbild öffnen

Wie es funktioniert Das Prinzip ist simpel: Sie wählen eine Etage zwischen 10 und 100. Je höher die Etage, desto länger die Fahrt, desto ausführlicher der generierte Pitch. Die Software nutzt ein Sprachmodell, das den Inhalt in Echtzeit an die gewählte Länge anpasst. Bei der 10. Etage bekommen Sie die Kernbotschaft in 30 Sekunden. Bei der 50. Etage gibt es mehr Details zu Produkten und Services. Wer bis zur 100. Etage fährt, erhält eine komplette Unternehmenspräsentation mit allen relevanten Informationen. Die Animation des Aufzugs macht das Ganze visuell nachvollziehbar. Man sieht förmlich, wie die Zeit läuft und der Pitch sich entwickelt. Praktisch für alle, die oft in Situationen kommen, wo sie ihr Unternehmen spontan präsentieren müssen - sei es auf Messen, bei Netzwerk-Events oder tatsächlich im Aufzug.

Die 10 Gebote der Software-Qualität

Michael Boiman — Sun, 15 Sep 2024 00:00:00 GMT

Erstes Gebot: Deployment-Qualität sicherstellen Du sollst nicht in die nächste Umgebung deployen, ohne das Quality Gate zu passieren. Automatisierte Quality Gates mit definierten Kriterien für Code-Coverage, Performance-Benchmarks und Security-Scans sind essentiell für Enterprise-Deployments. Jede Umgebung erfordert nachweisbare Qualitätsstandards. Zweites Gebot: Transparenz in der Pipeline Du sollst stets die Wahrheit über den Zustand deiner Pipeline sprechen. Monitoring und Reporting-Dashboards müssen den aktuellen Status aller Systeme in Echtzeit abbilden. Stakeholder benötigen verlässliche Informationen für strategische Entscheidungen. Drittes Gebot: Anforderungs-Traceability Achte die Anforderungen und beweise ihre vollständige Umsetzung. Jede Anforderung muss durch automatisierte Tests validiert und ihre Implementierung nachverfolgbar sein. Traceability-Matrizen gewährleisten Compliance und Auditierbarkeit. Viertes Gebot: Test-Asset-Management Halte deine Tests in Ehren und pflege sie mit Sorgfalt. Tests sind kritische Business-Assets, die kontinuierliche Wartung und Refaktorierung erfordern. Obsolete Tests reduzieren Vertrauen und verlängern Feedback-Zyklen. Fünftes Gebot: Automatisierung als Standard Wo manuelle Tests herrschen, sollst du Automatisierung bringen. Manuelle Prozesse skalieren nicht und sind fehleranfällig. ROI von Testautomatisierung zeigt sich besonders in Regressionstests und CI/CD-Pipelines. Sechstes Gebot: Proaktive Fehlerbehandlung Entdeckst du Fehler, so behebe sie und schütze dich durch Tests vor ihrer Wiederkehr. Jeder Produktionsfehler erfordert entsprechende Automatisierung zur Prävention. Root-Cause-Analyse und präventive Maßnahmen reduzieren technische Risiken. Siebtes Gebot: Technical Debt Management Du sollst technische Schulden nicht anhäufen, sondern regelmäßig tilgen. Technical Debt beeinflusst Entwicklungsgeschwindigkeit und Systemstabilität exponentiell. Regelmäßige Refaktorierung und Modernisierung sind strategische Investitionen. Achtes Gebot: Clean Code als Grundlage Ehre die Prinzipien sauberen Codes in all deinem Schaffen. Wartbarer Code reduziert Onboarding-Zeit neuer Entwickler und minimiert Fehlerquellen. Code-Reviews und statische Analyse-Tools unterstützen Konsistenz. Neuntes Gebot: Performance Engineering Du sollst die Leistung deiner Anwendung messen und stetig verbessern. Performance-Monitoring und Load-Testing müssen integraler Bestandteil der Entwicklung sein. SLAs und Performance-Budgets definieren messbare Qualitätsziele. Zehntes Gebot: Kontinuierliche Verbesserung Strebe nach Wissen und Verbesserung, denn Qualität kennt kein Ende. Retrospektiven, Metriken-Analyse und Team-Learning fördern eine Kultur der kontinuierlichen Verbesserung. Qualität ist ein evolutionärer Prozess, kein statisches Ziel.

LM Studio: Large Language Models lokal nutzen

Michael Boiman — Thu, 15 Aug 2024 00:00:00 GMT

!LM Studio Interface Was ist LM Studio? LM Studio ist eine Desktop-Anwendung für Windows, macOS und Linux, mit der sich Open-Source Language Models lokal ausführen lassen. Die Software bietet eine grafische Oberfläche für Modelle, die sonst nur über die Kommandozeile nutzbar wären. Das Programm lädt Modelle direkt von Hugging Face herunter und bietet sowohl ein Chat-Interface als auch eine OpenAI-kompatible API. Letzteres bedeutet: Bestehende Anwendungen, die mit ChatGPT arbeiten, lassen sich oft durch einfaches Ändern der API-URL auf lokale Modelle umstellen. Installation und erste Schritte Die Installation ist unkompliziert: Software von lmstudio.ai herunterladen und installieren. Nach dem Start präsentiert LM Studio eine Übersicht verfügbarer Modelle. Für den Einstieg eignen sich kleinere Modelle wie Phi-3 oder Llama-3.1-8B. Diese benötigen zwischen 4 und 8 GB Speicherplatz und laufen auch auf durchschnittlicher Hardware flüssig. Größere Modelle wie Mixtral bieten bessere Ergebnisse, brauchen aber entsprechend mehr Ressourcen. !LM Studio Chat Interface Praktische Anwendungsfälle Dokumentenanalyse ohne Datenschutzrisiko Vertrauliche Dokumente, Verträge oder interne Berichte können analysiert werden, ohne dass Daten das Unternehmensnetzwerk verlassen. Das ist besonders für Branchen mit strengen Compliance-Anforderungen relevant. Code-Entwicklung Modelle wie CodeLlama unterstützen bei der Programmierung. Der eigene Code bleibt dabei lokal - keine Sorge um Intellectual Property oder versehentlich geleakte Geschäftsgeheimnisse. Offline-Verfügbarkeit Nach dem Download funktionieren die Modelle komplett ohne Internet. Das ist praktisch für Arbeiten in abgeschotteten Umgebungen oder unterwegs. Kostenaspekt Statt monatlicher API-Gebühren fallen nur einmalige Hardware-Kosten an. Bei intensiver Nutzung kann sich das schnell rechnen. Warum lokale KI? Der Hauptvorteil liegt in der Datenkontrolle. Keine Nutzerdaten werden an externe Server übertragen, was DSGVO-Compliance vereinfacht und Datenlecks verhindert. Zudem gibt es keine Rate-Limits oder Ausfallzeiten durch überlastete Server. Die Performance hängt nur von der eigenen Hardware ab. Ein weiterer Punkt: Modellauswahl. Während Cloud-Dienste meist nur ihre eigenen Modelle anbieten, stehen bei LM Studio hunderte verschiedene Open-Source-Modelle zur Verfügung. Man kann verschiedene Modelle für unterschiedliche Aufgaben nutzen oder spezialisierte Varianten einsetzen. Systemanforderungen Minimum: 8 GB RAM (für kleine Modelle) 10 GB freier Speicherplatz Windows 10, macOS 12 oder Ubuntu 20.04 Empfohlen: 16-32 GB RAM Dedizierte Grafikkarte (NVIDIA mit CUDA oder Apple Silicon) 50+ GB Speicher für mehrere Modelle Die GPU-Beschleunigung macht einen deutlichen Unterschied - Antworten kommen etwa 5-10x schneller als bei reiner CPU-Nutzung. Grenzen und Überlegungen Lokale Modelle erreichen (noch) nicht die Qualität von GPT-4 oder Claude. Für viele Anwendungsfälle reichen sie aber völlig aus. Die Modellgröße ist durch den verfügbaren Arbeitsspeicher begrenzt - die besten Open-Source-Modelle mit 70B+ Parametern brauchen High-End-Hardware. Updates und neue Modelle muss man selbst verwalten. Dafür hat man volle Kontrolle über Versionen und kann bei Bedarf auf ältere Modelle zurückwechseln. Fazit LM Studio macht KI-Technologie zugänglich, ohne Kompromisse beim Datenschutz einzugehen. Für Unternehmen mit sensiblen Daten oder Entwickler, die unabhängig arbeiten wollen, ist es eine praktische Alternative zu Cloud-Diensten. Die Software entwickelt sich stetig weiter und die verfügbaren Open-Source-Modelle werden immer besser. Wer Wert auf Datenkontrolle legt oder einfach experimentieren möchte, sollte LM Studio ausprobieren.

KI muss nicht kompliziert sein

Michael Boiman — Mon, 05 Aug 2024 00:00:00 GMT

E-Mails kosten Zeit. Besonders wenn sie freundlich, rechtlich korrekt und fehlerfrei sein sollen. Ein einzelner Button in Outlook kann das ändern. Wir haben KI direkt in Outlook integriert. Kein separates Tool, keine Schulung, nur ein zusätzlicher Button in der gewohnten Umgebung. Damit lassen sich E-Mails auf Compliance prüfen, in andere Sprachen übersetzen oder im Ton anpassen – alles ohne die Mail-Oberfläche zu verlassen. Die technische Basis bildet wahlweise ein lokales bzw. selbstgehostetes LLM im firmeneigenen Rechenzentrum, oder, für unkritische Inhalte, ein Cloud-Modell wie GPT oder Claude. Die Integration dauert einen Tag, danach funktioniert es einfach. Der praktische Nutzen zeigt sich im Alltag: Support-Teams antworten schneller mit passenderen Formulierungen. Vertriebsmitarbeiter ergänzen automatisch aktuelle Produktinfos. Die Rechtsabteilung prüft ausgehende Mails auf kritische Formulierungen. !AI-Button Outlook Integration Demo

Die 12 Gebote der Microservices: So bauen Sie unzerstörbare Systeme

Michael Boiman — Thu, 01 Aug 2024 00:00:00 GMT

Stellen Sie sich vor: Ihr E-Commerce-System bricht am Black Friday zusammen. 2 Millionen Euro Umsatz verloren in 3 Stunden. Der Grund? Ein einziger fehlerhafter Payment-Service legt Ihre gesamte Monolith-Architektur lahm. Das muss nicht sein. Netflix streamt täglich 100 Millionen Stunden Content. Amazon verarbeitet 66.000 Bestellungen pro Stunde. Spotify bedient 574 Millionen Nutzer gleichzeitig. Ihr Geheimnis? Microservices-Architektur nach klaren Prinzipien. Die harte Realität: 73% aller Microservices-Projekte scheitern Warum? Weil Teams ohne klare Prinzipien starten. Sie zerlegen Monolithen willkürlich, ignorieren Domänengrenzen und enden mit einem "distributed monolith" – dem Worst-Case-Szenario. Die Lösung: 12 battle-getestete Prinzipien, die aus der ursprünglichen 12-Factor-App-Methodologie weiterentwickelt wurden. Diese Regeln haben sich in hunderten Production-Deployments bewährt. Die 12 Prinzipien – Mit praktischen Beispielen 🎯 Fachlichkeit first, Technik second Das Problem: Teams starten mit Technologie-Entscheidungen statt mit Domänenverständnis. Die Lösung: Deep-Dive in die Fachdomäne VOR dem ersten Code. Praktisches Beispiel: ROI: Teams mit klarem Domain-Driven Design reduzieren Refactoring-Aufwand um 65%. 📦 Ein Service = Ein Prozess = Ein Repository Die Regel: Absolute Trennung für maximale Unabhängigkeit. Real-World Setup: Metrik: Teams mit dieser Struktur deployen 4x häufiger ohne Koordination. 🔨 Ein Build-Skript für alle Das Ziel: Jeder Service baut identisch. Beispiel Makefile: Vorteil: Neue Entwickler sind in 30 Minuten produktiv (statt 3 Tagen). 🌳 Main Branch = Production Ready Die Regel: Jeder Commit auf main MUSS deploybar sein. Enforcement: Ergebnis: 0% Broken Builds, 100% Deployment-Confidence. 🐳 Versionierte Container für jeden Commit Best Practice: Business Value: Rollback in < 30 Sekunden statt stundenlangem Debugging. 📡 HTTP + CQRS = Universelle API Pattern für saubere APIs: Warum CQRS? Separate Skalierung: Read-Replicas für Queries, Write-Master für Commands. 🔌 Alternative Protokolle bei Bedarf Die Realität: 95% brauchen nur HTTP. Aber für die anderen 5%: 🧊 Zustandslosigkeit ist Pflicht Anti-Pattern vs. Pattern: Skalierbarkeit: Zustandslose Services skalieren linear – 10x Traffic = 10x Pods. 🌐 Services als Black Boxes Kommunikation nur über Netzwerk: Vorteil: Services können in verschiedenen Sprachen/Frameworks implementiert werden. 🔐 Konfiguration via Environment 12-Factor-konform: Security: Secrets niemals im Code, immer aus Kubernetes Secrets/Vault. 📊 Logging auf stdout Einfachheit siegt: Integration: Fluentd/Logstash sammelt automatisch → ElasticSearch → Kibana Dashboards. 🔑 Token-basierte Security JWT für Service-to-Service: 💰 Der Business Case: ROI-Berechnung Vorher (Monolith) Deployment: 1x pro Woche, 4 Stunden Downtime Skalierung: Gesamtes System, 50.000€/Monat AWS Time-to-Market: 3 Monate für neue Features Ausfälle: 12 Stunden/Jahr (99.86% Uptime) Nachher (Microservices) Deployment: 50x pro Tag, Zero Downtime Skalierung: Nur belastete Services, 18.000€/Monat AWS Time-to-Market: 2 Wochen für neue Features Ausfälle: 26 Minuten/Jahr (99.995% Uptime) Ersparnis pro Jahr 🚀 Ihre Microservices-Journey startet JETZT Quick-Win für diese Woche Identifizieren Sie EINEN Business-Service mit klaren Grenzen Extrahieren Sie ihn als ersten Microservice Messen Sie die Deployment-Frequenz vorher/nachher Die häufigsten Fehler vermeiden ❌ "Wir machen ALLE Services gleichzeitig" → Evolutionär vorgehen, Service für Service ❌ "Wir teilen die Datenbank" → Jeder Service besitzt seine Daten komplett ❌ "Wir brauchen erstmal Service Mesh" → Starten Sie simpel, komplexität kommt später 🎯 Praxis-Beispiel: E-Commerce Migration Ein deutscher Online-Händler (500 Mio € Umsatz) migrierte in 18 Monaten: Phase 1 (Monat 1-3): Payment-Service extrahiert Sofort 50% weniger Payment-Ausfälle ROI nach 2 Monaten Phase 2 (Monat 4-9): Inventory & Shipping Black Friday erstmals ohne Ausfall 3x schnellere Feature-Releases Phase 3 (Monat 10-18): Komplette Migration 73% Infrastruktur-Kosten gespart 10x Deployments pro Tag 99.99% Verfügbarkeit Weiterführende Ressourcen 📚 Deep Dives: Original 12-Factor App Methodology - Die Basis verstehen Heise Artikel: Zwölf Regeln für Microservices - Deutsche Perspektive Martin Fowler: Microservices - Der Klassiker 🛠️ Tools & Frameworks: Kubernetes: Der de-facto Standard für Container-Orchestrierung Istio/Linkerd: Service Mesh für fortgeschrittene Patterns Apache Kafka: Event-Streaming zwischen Services Prometheus/Grafana: Monitoring & Observability Fazit Die 12 Prinzipien bieten einen bewährten Leitfaden für erfolgreiche Microservices-Architekturen. Der Schlüssel liegt in der schrittweisen Umsetzung: Beginnen Sie mit einem Service, sammeln Sie Erfahrungen, skalieren Sie nach Bedarf. Wo Microservices auf Automatisierung treffen: In unseren Projekten spielen diese Prinzipien vor allem bei CI/CD-Pipelines, Quality Gates und dokumentengetriebenen Prozessen eine Rolle. → Mehr zu unserem Vorgehen

Live-Coding mit ChatGPT: Von Web Scraping zum Chatbot

Michael Boiman — Thu, 31 Aug 2023 00:00:00 GMT

In meinem jüngsten Vortrag zeigte ich, wie ChatGPT Programmieraufgaben in Echtzeit löst. Die Live-Demo machte konkret, was KI-Tools in der Softwareentwicklung heute leisten. Was wir gebaut haben In der Live-Demo entwickelten wir Schritt für Schritt einen Chatbot, der: Webseiten-Daten automatisch erfasst und verarbeitet Mittels Embeddings semantische Suchen ermöglicht Durch Similaritätsanalysen die relevantesten Antworten findet Über eine Streamlit-Oberfläche bedient wird Die Technologie dahinter Tech-Stack der Demo Web Scraping für die Datenerfassung Embeddings für semantische Suche Similaritätsanalysen für relevante Ergebnisse Streamlit für die interaktive Oberfläche Prompt Engineering für präzise Antworten Was die Demo zeigte Der Chatbot antwortete ausschließlich auf Basis der bereitgestellten Daten. Gezieltes Prompt-Engineering verhinderte Halluzinationen. Die Demo zeigte zudem, dass KI-Tools über einzelne Code-Schnipsel hinaus komplette Anwendungen strukturiert aufbauen. Code & Ressourcen Der vollständige Code mit Schritt-für-Schritt-Anleitung liegt im GitHub Repository. Wie es weitergeht Die Resonanz bestärkt mich darin, weitere praktische KI-Workshops anzubieten. Bei Interesse an einem Workshop für Ihr Team: Sprechen Sie uns an. Die Erfahrung aus dem Vortrag: KI ist ein praktisches Werkzeug, das die Art zu programmieren verändert.