Die neue KI-Architektur 2026: Harness, Evaluation, Open Source

Wer 2026 mit den drei Verschiebungen baut, hat 2027 mehrere Use Cases produktiv. Wer ohne sie baut, steckt 2027 noch immer der Pilotphase.

Die wichtigste Bewegung der PyCon DE & PyData 2026 zeiget sich nicht in einem einzelnen Talk. Sie lag im Tonwechsel: weg von „look at what's possible", hin zu „läuft seit Februar". Die Branche ist nicht am Ziel. Aber sie hat ihre erste LLM-Welle verarbeitet und daraus dreiLehren gezogen: vom Modell zum Harness, vom Test zur Architektur (Evaluation), von der Sparvariante zum Hebel für Souveränität (Open Source). 2026 trennt sich, wer mit diesen Verschiebungen plant, von denen, die nach der Logik von 2024 weiterbauen. Den Unterschied sieht man 2027: Die einen liefern produktive Use Cases, die anderen feilen weiter am ersten Piloten..

Auf einen Blick

• Drei Verschiebungen, die in dieser Serie sichtbar wurden, fügen sich zu einem Bild zusammen: KI-Architektur 2026 verlangt ein anderes Denken als 2024.
• Vom Modell zum Harness; vom Test zur Architektur (Evaluation); von der Sparvariante zum Souveränitätshebel (Open Source).
• 2026 trennt zwei Arten von Programmen: die einen rechnen mit diesen Verschiebungen, die anderen planen weiter nach der Logik von 2024. Der Unterschied zeigt sich 2027 in der Lieferfähigkeit.

Verschiebung 1: Vom Modell zum Harness

Seit 2024 war die zentrale Frage: welches Modell ist das beste? 2026 ist sie es nicht mehr. Sebastian Raschka brachte es in userem Fireside Chat Stop Waiting, Start Shipping, auf eineFormel, die für Europa besonders relevant ist: Post-Training und Harness, nicht Base-Modell-Race.

Das Lehrstück dazu war Cursors Composer 2: produktiv im Einsatz, besser als die meisten Coding-LLMs am Markt, aber nicht aus eigenem Pre-Training entstanden. Im Kern: ein offenes Basismodell, Kimi 2.5, mit zusätzlichem Reinforcement Learning. Cursor-Mitgründer Aman Sanger hat das im März 2026 öffentlich bestätigt; Moonshot AI beschrieb das Verfahren als „continued pretraining & high-compute RL training“ auf Kimi 2.5.

Dasselbe Muster zeigt Claude Code: Der Coding-Agent wurde besser, weil Anthropic ein gutes Harness für Programmierarbeit gebaut hat. Unter der Haube wirkt weniger Modell-Magie als eine zielgerichtete Arbeitsteilung spezialisierter Programme: Code suchen, Patches erzeugen, Tests ausführen, Diffs bauen, Sandboxes aufrufen. Das Modell orchestriert; die Tools arbeiten, einiges davon ist "try-and-error".

Für Agent-Architekturen ist diese Verschiebung doppelt relevant. Programme, die 2026 produktive Agenten betreiben, haben striktes Kontextmanagement, deterministische Fallback-Pfade und Releases, die an Evaluationen hängen. Sie behandeln Trust Boundaries als Vertrag, nicht als Slogan. Sie stellen für jeden autonomen Schritt die Frage, die Gabriela Bogk in ihrer Keynote zugespitzt hat: „Was ist der Blast Radius?“

Wer 2026 noch immer nur das beste Modell sucht, optimiert an der falschen Stelle.

Verschiebung 2: Von Test zu Architektur (Evaluation)

Die zweite Verschiebung ist unspektakulär, aber zentral: Teams bauen nicht mehr zuerst und schauen dann, ob es funktioniert. Sie testen zuerst und bauen dann gezielt gegen das, was sie messen wollen. Zuvor war Evaluation oft eine nachgelagerte Prüfung. Nun ist sie der Taktgeber produktiver KI-Entwicklung.

Frank Rust und Thomas Prexl haben in ihrem Talk It Works on My Machine exemplarisch beschrieben, wie das in der Praxis aussieht: bevor die erste Codezeile geschrieben wird, sammeln sie 100 oder mehr reale Nutzerfragen mit korrekten Antworten und Quellverweisen. Dieses Set dient als die Baseline für die Entwicklung gemeinsam mit den Domain-Experten. Andrei Beliankou und Evgeniya Ovchinnikova (E.ON) haben die operative Schicht darüber gezeigt: drei Beobachtbarkeits-Stacks parallel, Tracing einzelner Spans, Cost-Breakdown, und der pointierte Hinweis auf den Failure Mode der Eval-Schleife, in den jedes Programm ohne diese Disziplin läuft.

Die Konsequenz ist eine andere als die meisten Teams denken: nicht das Modell ist der strategische Kern, es ist das Eval-Set.

Modelle wechseln jedes Quartal. Eval-Sets bleiben.

Sie sind das wertvollste Asset einer KI-Anwendung, und sie gehören in Woche 1, nicht in Phase 4.

Damit verschiebt sich auch die Hiring-Anforderungen. Der Engpass-Hire 2026 ist nicht der ML-PhD, sondern der Domänenexperte mit Experimentierwillen, eine These, die ich in der Eval-Disziplin verankert habe. Eval-Disziplin lebt von Domänenwissen, nicht von KI-Tiefe.

Verschiebung 3: Von Sparvariante zu Souveränitätshebel

Die dritte Verschiebung trifft das Verhältnis zwischen Open-Source-Stacks und Enterprise-Strategie. Open Source wurde zu oft falsch eingeordnet: kostenlos, riskant, irgendwie nicht „ernsthaft". 2026 ist genau diese Zuordnung nicht mehr haltbar. Open Source ist die Architekturform, in der Datenkontrolle, Auditierbarkeit und strategisches Post-Training zusammenlaufen. Drei Achsen tragen den Wechsel.

Daten-Souveränität durch lokale Modelle

Lokale Modelle sind für sensible Workloads selbstverständlich, wie Bogk aus CISO-Perspektive bestätigt hat. Vertrauliche Tickets, Code-Repositories, Vertragsentwürfe verlassen den eigenen Kontrollraum nicht mehr. Souveränität wandert vom Strategiepapier in den Stack.

Audit-Souveränität durch offene Modelle

Sylvain Corlay (QuantStack/Jupyter) hat un unserem Open-Source-Business-Panel, formuliert, was für die Industrie als auch Forschung zutrifft: Black-Box-Werkzeuge sind dort, wo Nachvollziehbarkeit Pflicht ist, prinzipiell ungeeignet. Modellgewichte in eigener Hand, Audit-Logs auf Inferenz-Ebene, Inspektion des Modellverhaltens: Das geht ohne offene Modelle nicht.

Strategische Souveränität durch Post-Training

Yann Lechelle (Probabl/scikit-learn) hat im selben Panel die ökonomische Klarstellung geliefert: Open Source ist kein Geschäftsmodell, sondern Distributions-, Community-, Governance- und Marketing-Asset. Daraus formt sich eine andere Frage als „offen oder geschlossen": welche Schicht kontrollieren wir, welche delegieren wir? Differenzierung entsteht im Post-Training auf eigenen Daten, auf einem Base-Modell, das man sich nicht selbst leisten muss.

Das europäische Open-Source-Wirtschafts-Ökosystem (Probabl, QuantStack, spaCy und weitere) ist als Partner-Markt für genau diese Souveränitätsprogramme verfügbar, merh dazu in dem Sovereignty-Beitrag dieser Serie. Wer 2026 noch immer „Make-vs-Buy" zwischen US-Hyperscaler und eigenem Modell denkt, übersieht einen substantiellen Markt.

Standardisierung im LLMOps-Stack

Alejandro Saucedo (Zalando) brachte aus seiner Survey zum State of Production Machine Learning Operations eine unbequeme Zahl mit: rund die Hälfte der Organisationen hat noch immer kein produktives ML-Monitoring. Was im LLMOps-Stack 2026 fehlt, ist genau das, was im MLOps-Stack zwischen 2018 und 2022 langsam entstanden ist: gemeinsame Standards, gemeinsame Pattern, gemeinsame Tooling-Erwartungen. OpenTelemetry-Standards für GenAI sind ein Anfang, aber das Feld ist heterogen und wird es noch eine Weile bleiben.

Review-Kapazität bei Faktor-10-Code-Anstieg

Die New York Times hat im April 2026 den Fall eines Finanzdienstleisters dokumentiert, be dem die KI-gestütze Code Generierung von 25.000 auf 250.000 Code-Zeilen pro Monat sprang und einen Review-Backlog von einer Million Zeilen aufbaute. Review ist in gerade in regulierten Bereichen Pflicht. Diese Schere zwischen Code-Generierung und Review-Kapazität ist 2026 nicht gelöst.

Klare Skill-Pfade für Domänenexperten

Wenn der Engpass-Hire 2026 der Domänenexperte mit Experimentierwillen ist, brauchen diese Menschen einen Lernpfad. Den gibt es heute noch nicht in strukturierter Form. Bootcamps treffen das Profil nicht, klassische ML-Studiengänge auch nicht. Was 2026 entsteht, ist im besten Fall ein Mentoring-Modell: externe Beratung trifft interne Domäne.

2026 markiert eine Trennlinie in der KI-Strategie von Unternehmen. Es entstehen zwei sehr unterschiedliche Arten von Anwendungen.

Die einen haben verstanden, dass der Wettbewerb nicht mehr allein über größere Modelle und mehr Rechenleistung entschieden wird. Sie investieren gezielt in die Schichten, die für das eigene Geschäft wirklich relevant sind: die Ein- und Anpassung von Modellen an eigene Daten und Prozesse, die Qualitätssicherung von KI-Ergebnissen, die Einbindung in bestehende Systeme und eine Architektur, die Compliance, Datensicherheit und Nachvollziehbarkeit von Anfang an mitdenkt.

Diese Unternehmen machen KI-Souveränität praktisch. Sie sprechen nicht nur darüber, sondern betreiben erste Anwendungen auf kontrollierbaren eigenen oder offenen Stacks. Sie dokumentieren, wie ihre Systeme getestet werden, welche Daten genutzt werden dürfen, wo Risiken entstehen und wie Entscheidungen überprüfbar bleiben. Sie suchen dafür nicht nur klassische KI-Forscher, sondern vor allem Menschen, die Domänenwissen, technisches Verständnis und Experimentierfähigkeit verbinden.

Für Entscheider heißt das

Erstens: Mehr Fokus auf Harness & AI-Evals, weniger auf von Base-Modell-Compute

Fokus und Budget gehören nicht in Vendor-Vergleiche, sondern in Post-Training, Harness und Eval-Pipelines. Wer 2026 noch immer auf Modellwahl optimiert, optimiert auf der falschen Ebene. Cursors Composer 2 ist ein Lehrstück: der Produktionsgewinn entstand nicht aus dem Base-Modell, sondern aus Schichten darüber.

Zweitens: Domänenexpertise ist wichtiger als ML-Expertise

Domänenexperten mit Experimentierwillen sind 2026 beim Hiring ein Engpass, nicht PhDs mit ML Hintergrund. AI Evals profitieren von Domänenwissen, nicht von technisch/algorithmischer Expertise.

Drittens: Souveränität operativ machen, nicht rhetorisch

Souveränität gehört nicht auf die Vorstandsfolie, sondern in den Stack: lokale Modelle für sensible Workloads, offene Modelle für Audit-Pflicht, Post-Training auf eigenen Daten für strategische Differenzierung. Mehrere Use Cases auf eigenem Stack mit dokumentierter Eval-Spur und nachvollziehbarem Compliance-Frame: Das ist die operative Marke 2026.

2026 entscheidet nicht mehr, wer das größte Modell hat. Entscheidend ist, wer Harness, Evaluation und Open-Source-Souveränität als Architektur ernst nimmt.