Kategorie: Erklärer

Die gängige Annahme in der Datenwelt lautet: erst sammeln, dann aufräumen. Daten werden in Seecontainer gekippt, später im Bronze-, Silber- und Gold-Verfahren gefiltert, bereinigt und angereichert. Doch wer zu spät annotiert, verliert den Kontext, den generative KI braucht. Organisationen sollten Daten bereits im Moment ihrer Entstehung mit Metadaten und Herkunftsinformationen versehen – sonst bleiben die teuer erkauften Daten für KI-Projekte wertlos.

Das Problem ist bekannt: Ein KI-Modell liefert mit hoher Konfidenz eine falsche Antwort, weil es auf veralteten oder nicht-kanonischen Daten trainiert wurde. Die Ursache liegt oft nicht im Modell, sondern darin, dass der ursprüngliche Zustand der Daten nicht dokumentiert wurde. Später den Kontext zu rekonstruieren, ist meist unmöglich – die Details sind unwiederbringlich verloren. Die Idee: Datenannotation als Teil des Sammelprozesses begreifen, nicht als nachgelagerte Pflicht.

Das Problem mit dem Putzen: Warum saubere Daten allein nicht reichen

Die klassische Datenarchitektur mit Bronze-, Silber- und Gold-Stufen verspricht eine schrittweise Verbesserung der Datenqualität. In Bronze liegen Rohdaten, in Silber werden sie validiert und angereichert, in Gold entsteht die produktive Sicht. Das klingt logisch, hat aber einen Haken: Die Reinigung entfernt nicht nur Müll, sondern auch wichtige Kontextinformationen. Ein Temperatursprung in einer IoT-Sensormessung könnte eine kritische Fehlfunktion bedeuten – oder eine routinemäßige Kalibrierung. Ohne die Information, welches Gerät gemessen hat und unter welchen Bedingungen, ist die Entscheidung später kaum zu treffen.

David Aronchick, Gründer von Kubeflow und CEO des Pipeline-Anbieters Expanso, formuliert es nüchtern: „Du kannst nicht ausschließlich saubere Daten verfolgen – das ist einfach nicht möglich. Wenn du Daten in dein ML-Modell ziehst, muss jede Zeile einen Mechanismus haben, der sagt, woher sie stammt. Sonst wirst du es nie wirklich wissen, weil du die Daten später nicht mehr trennen kannst.“ Er vergleicht das mit einer Küche: Wenn du die Zutaten sofort mischst und würzt, ohne zu notieren, woher sie kommen, kannst du das Rezept später nicht mehr nachvollziehen. Und du kannst auch nicht entscheiden, ob eine Abweichung gewollt war oder ein Fehler.

In-Stream-Labeling: Kontext dort erfassen, wo er entsteht

Die Lösung heißt In-Stream-Labeling – eine Methode, bei der Daten bereits während der Erfassung annotiert werden. Ulrik Hansen, Co-CEO von Encord, einer Plattform für Datenannotation, warnt davor, das als Ersatz für das Bereinigen zu verstehen. „Schmutzige Daten vereinen zwei Dinge: echte Korruption, die du beheben solltest, und Kontextabhängigkeit, bei der eine Messung nur anomal aussieht, weil der erklärende Rahmen weggeworfen wurde“, sagt er. „Das Bereinigen tötet beides. Es geht nicht darum, mit dem Putzen aufzuhören, sondern darum, Kontext nicht wegzunormalisieren, den du nie wieder zurückbekommst.“

Kontext kann an der Quelle billig erfasst werden – ein paar zusätzliche Felder, ein Zeitstempel, ein Geräte-Identifier. Danach wird es fast unmöglich, die fehlenden Informationen zu rekonstruieren. Hansen rät, nur das zu erfassen, was gratis und unwiederbringlich ist: „Das Ursprungssystem ist das Etikett. Du taggst nicht die HR-Policy, sondern du erfasst, dass sie aus dem HR-System stammt. Alles, was ein Modell später ableiten kann, kannst du weglassen.“ Das hält den Zusatzaufwand gering und verhindert Datenblähung.

Schema-Validierung als Sicherheitsnetz: Fehler früh abfangen

Neben der Annotation spielt die Validierung gegen ein Schema eine zentrale Rolle. Aronchick beschreibt, wie ein Sensor für Temperatur und Feuchtigkeit zusätzlich die Skala, die Einheit und das Zeitformat liefern muss. Wenn du diese Felder beim Ingest prüfst, kannst du abweichende Daten sofort aussortieren oder zur manuellen Prüfung weiterleiten. „Vielleicht lösche ich sie, oder ich schicke sie an einen Ort, wo ein Mensch oder ein anderes Tool sie in etwas Wertvolles rekonstruieren kann. Aber das Wichtige ist: Die verschmutzten Daten gelangen nicht in meine Pipeline.“

Änderungen an APIs, Schemas, Speicherformaten passieren in jeder Organisation. Diese Änderungen müssen in den Metadaten festgehalten werden, die mit den Daten reisen. Google hat in der Forschung zu „Data Cascades“ gezeigt, wie leicht Kontext verloren geht und wie stark das die Datenqualität beeinträchtigt. Wer die Schema-Prüfung weit nach links verschiebt, also direkt beim Sammeln, kann bessere Downstream-Entscheidungen treffen. Dann ist klar, ob ein Datensatz für ein bestimmtes Modell taugt oder nicht.

Vom Papier zum strukturierten Datensatz: Annotation bei unstrukturierten Daten

Unstrukturierte Daten wie PDFs, Word-Dokumente oder Bilder erfordern zusätzliche Anstrengung. Ein PDF hat Autor und Erstellungsdatum, aber nicht die Information, ob der Autor eine Führungsposition innehat, ob das Dokument noch aktuell ist oder nur für eine bestimmte Kundengruppe gilt. Diese Kontexte müssen als Metadaten ergänzt werden – und zwar direkt beim Erfassen, nicht in einer separaten Compliance-Tabelle. Datenplattformen wie DataHub oder SurrealDB helfen dabei.

SurrealDB-CEO Tobie Morgan Hitchcock erklärt, wie sein System ein Foto mit Vision-KI analysiert, um zu verstehen, was im Bild ist. „Aus völlig unstrukturierten Daten gewinnen wir so viel Struktur wie möglich.“ Das wird mit anderen Daten angereichert – etwa Gesprächsverlauf, Telemetrie, Standortdaten – um für einen späteren KI-Agenten ein genaues Verständnis des Ereignisses zu ermöglichen. „Je mehr Kontext du erfasst, desto besser kannst du später eine genaue Antwort geben“, sagt er.

Die Herkunft eines Dokuments spielt auch für die Vertrauenswürdigkeit eine Rolle. Wer hat es erstellt? Aus welcher Abteilung? Wie oft wird es aktualisiert? Das kann über das Firmenverzeichnis ermittelt werden. „Wenn ein Dokument von der Geschäftsleitung stammt, hat es mehr Autorität als ein Beitrag aus einem Forum“, erklärt Hitchcock. So lässt sich im Laufe der Zeit ein Verständnis von Vertrauen und Provenienz aufbauen – entscheidend für KI-Agenten, die auf Informationen vertrauen müssen.

Praktische Umsetzung: Anreize schaffen und DevOps-Prinzipien übertragen

Wie schafft man es, dass Menschen die Annotation nicht als lästige Pflicht sehen? Shirshanka Das, CTO von DataHub, hat das bei LinkedIn erlebt. Er half dort, die GDPR-Strategie umzusetzen, und stellte fest, dass selbst mit guten Schema-first-Praktiken der Data Lake zum Sumpf wurde. Die Lösung: Er integrierte die Metadaten-Erfassung in die CI/CD-Pipeline. Entwickler konnten kein Schema einchecken, ohne die Bedeutung jeder Spalte zu deklarieren. Anfangs unbeliebt – bis die Teams, die nicht mitmachten, mit Anfragen von Data Scientists überhäuft wurden. Der Anreiz war klar: Wer dokumentiert, spart sich später die Arbeit.

Megha Kumar, Research VP für Analytics und KI bei IDC, sieht die Realität jedoch skeptisch: „Die meisten Organisationen verarbeiten Daten in Batches, daher findet eine Echtzeit-Kontexterfassung selten statt. Selbst die, die Echtzeit verarbeiten, haben vordefinierte Schemas, und das Hinzufügen von Kontext erfordert Änderungen, die leider später passieren.“ DataHub Cloud versucht deshalb, den Kontext nachträglich zurückzugewinnen, indem es Abfragen und BI-Tools analysiert, um ein semantisches Modell abzuleiten. Das gibt den Teams einen Ausgangspunkt, den sie validieren und dann als Governance-Layer nutzen können.

Ein gelungenes Beispiel ist Miro: Der Online-Whiteboard-Anbieter verbesserte die Genauigkeit seiner KI-Agenten von etwa 50 % auf 90 %, indem er DataHub einführte und die abgeleiteten Metadaten mit einem menschlichen Genehmigungsprozess kombinierte – also GitOps-Prinzipien auf die Datenverwaltung übertrug. „Wenn ein Data Scientist zehnmal mehr Anfragen bekommt, weil er seine Arbeit nicht dokumentiert hat und die KI Fehler macht, dann hat er den Anreiz, die Annotation direkt bei der Erstellung hinzuzufügen“, sagt Das.

Datenherkunft für den EU AI Act und zukunftssichere KI

Der EU AI Act verlangt, dass Organisationen die Herkunft ihrer Trainingsdaten nachweisen können. Das geht nur, wenn Provenienz und Linie von Anfang an dokumentiert sind. Aronchick empfiehlt eine „Data Bill of Materials“ im Stil der SLSA-Spezifikation, die signierte Provenienz und Beglaubigungen hinzufügt. Mit Tools wie Makoto lässt sich festhalten, wer Daten gesammelt hat, wann, woher, ob die Quelle autoritativ war, welche Transformationen durchgeführt wurden und was genau das Modell gesehen hat. „Es geht nicht nur um Version und Metadaten“, erklärt er. „Es geht darum, zu wissen, dass diese Daten diese Schritte durchlaufen haben, dass dies die Wurzelquelle ist und welche anderen Elemente dabei waren.“

Diese Transparenz ist keine bürokratische Pflicht, sondern ein Qualitätssiegel für deine KI. Wenn du einem Modell vertrauen willst, musst du wissen, welche Daten es gefüttert hat. Eine saubere, aber kontextlose Datenbasis kann schnell zu falschen Entscheidungen führen – im schlimmsten Fall mit rechtlichen Konsequenzen. Wer dagegen beim Sammeln annotiert, spart später Zeit, Geld und Nerven. Gartner schätzt, dass 60 % der KI-Projekte an schlechtem Metadatenmanagement, Datenqualität und fehlender Datenobservability scheitern. Das lässt sich vermeiden, wenn man den Kontext nicht wegwirft.

Die Perspektive muss sich verschieben: nicht Daten erst sauber machen und dann anreichern, sondern Daten von Anfang an mit Kontext versehen. Das erfordert etwas mehr Aufwand an der Quelle, zahlt sich aber später durch weniger Fehlentscheidungen und schnellere Abläufe aus. Für Entwickler, Data Scientists oder KI-Verantwortliche bedeutet das: Schau nicht nur auf das „Gold“ am Ende der Pipeline. Achte darauf, dass jede Zeile, die hereinkommt, ihre Geschichte mit sich trägt. Dann wird deine KI nicht nur smarter, sondern auch vertrauenswürdiger.

Quelle: cio.com

Der klassische Code-Review-Prozess stirbt langsam – zumindest dort, wo Software nicht mehr ausschließlich von Menschen geschrieben wird. Wenn täglich hunderttausende Änderungsvorschläge von KI-Agenten durch ein System rauschen, kann kein Mensch mehr jeden einzelnen Commit lesen. Der Autor des ursprünglichen Artikels beschreibt genau diesen Punkt: Qualitätssicherung darf nicht mehr allein auf menschlicher Aufmerksamkeit beruhen, sondern muss in die Umgebung, die Constraints und die Werkzeuge rund um den Agenten eingebaut werden. Was das praktisch bedeutet, schauen wir uns an.

Der Qualitätsverlust durch die Agentenflut

Stell dir vor, du hast ein Team aus zehn Entwicklern, die alle gleichzeitig Code in eine gemeinsame Codebasis schreiben – und niemand liest die Änderungen der anderen. Genau das passiert, wenn du KI-Agenten in deinen Entwicklungsprozess integrierst. Der Autor berichtet von einem Experiment, bei dem ein Coding-Agent eine App baute und zwei weitere Agenten diese App anschließend bewerteten – mit widersprüchlichen Ergebnissen. Ein dritter Durchlauf lieferte eine komplett andere Meinung. Das ist kein Einzelfall. Wenn du Qualität auf ein subjektives Review stützt, bekommst du bei Maschinen Geschwätz statt verlässlicher Aussagen.

Die Lösung liegt nicht darin, mehr Menschen einzustellen, sondern darin, die Umgebung so zu bauen, dass schlechte Vorschläge gar nicht erst durchkommen. Der Autor nennt das „Constraints“: Regeln, Tests, Metriken und Gateways, die zwischen dem Agenten und der Produktion liegen. Diese Constraints fungieren wie ein Sicherheitsnetz, das den Spielraum des Agenten einschränkt, ohne seine Produktivität zu bremsen. Entscheidend ist, dass diese Grenzen nicht einmalig gesetzt werden, sondern als permanenter Bestandteil der Entwicklungsumgebung wirken.

Das Konzept erinnert an eine Qualitätsschleuse in der Fertigung: Ein Produkt durchläuft mehrere Stationen, an denen es geprüft wird, bevor es das Werk verlässt. Je früher ein Fehler entdeckt wird, desto billiger ist die Korrektur. Bei KI-Agenten verschiebst du diese Stationen in den Code-Review-Prozess, in die Testsuite, in statische Analysewerkzeuge und in die CI-Pipeline.

Welche Qualitätsgates funktionieren – und welche nicht

Der Autor unterscheidet zwischen verschiedenen Arten von Constraints, die alle das gleiche Ziel haben: Sicherzustellen, dass ein Vorschlag des Agenten sicher, korrekt und im Rahmen des Projekts ist. An erster Stelle stehen klassische Unit-Tests, die einzelne Funktionen isoliert prüfen. Dann kommen Property-Tests, die generische Eigenschaften von Code verifizieren, und Akzeptanztests, die das Verhalten aus Nutzersicht abbilden. Besonders interessant ist Mutation Testing: Dabei wird der Code absichtlich leicht verändert, also zum Beispiel ein Vergleichsoperator umgedreht, und dann überprüft, ob die vorhandenen Tests diese Mutation erkennen. Wenn die Tests die Veränderung nicht bemerken, ist das ein Zeichen dafür, dass sie zu schwach sind – und genau das ist eine wertvolle Information für die Qualitätssicherung.

Hinzu kommen Metriken wie zyklomatische Komplexität oder Zeilenlänge, die dabei helfen, Code lesbar und wartbar zu halten. Diese Metriken sind keine Selbstzwecke, sondern Werkzeuge, um die kognitive Belastung für Menschen zu begrenzen, die später an dem Code arbeiten. Der Autor betont, dass ein einzelner Test allein nicht reicht – es braucht eine Kombination aus verschiedenen Checks, die unterschiedliche Aspekte der Qualität abdecken: Typensicherheit, Performance, Sicherheitslücken.

Wichtig ist der Gedanke, dass Constraints nicht nur ablehnen, sondern auch positive Signale senden können. Sie zeigen dem Agenten, was funktioniert und was nicht, und geben damit eine Art Trainingsfeedback. Je besser diese Rückmeldung ist, desto schneller lernt der Agent, innerhalb der gesetzten Grenzen zu arbeiten.

Autonomie, Vertrauen und die Grenzen des Machbaren

Ein Problem, das der Autor explizit anspricht, ist die Autonomie der Agenten. Selbst die besten Modelle scheitern, wenn Informationen fehlen oder die Aufgabenstellung mehrdeutig ist. Das betrifft sowohl die eigentliche Aufgabe als auch die Parametrisierung durch die Umgebung. Wenn die Entwicklungsumgebung brüchig ist – zum Beispiel durch nichtdeterministische Builds oder fehlende Berechtigungen –, dann bekommt der Agent widersprüchliche Rückmeldungen und produziert entsprechend schlechten Code.

Vertrauen ist hier ein zentraler Begriff. Der Autor sagt, man müsse einem Agenten zunächst vertrauen, aber dieses Vertrauen müsse hart erarbeitet sein. Das heißt: Jeder Schritt des Agenten sollte durch automatisierte Checks abgesichert sein, bevor er Einfluss auf das System nimmt. Man kann sich das wie einen Budenbetreuer auf einem Markt vorstellen: Man lässt ihn erst einmal an einem kleinen Stand arbeiten, beobachtet ihn und gibt ihm mehr Verantwortung, sobald er zuverlässig arbeitet. Genauso sollten Agenten in einer Umgebung laufen, in der Fehler wenig Schaden anrichten und wo sie schrittweise mehr Freiheiten bekommen.

Die Krux liegt darin, dass die Umgebung diese kalkulierten Risiken zulässt. Ein System, das bei jedem Fehler sofort abstürzt, ist für Agenten unbrauchbar. Es braucht also eine Sandbox, in der Agenten experimentieren können, ohne die Produktion zu gefährden. Das ist ein entscheidender Unterschied zu menschlichen Entwicklern, die solche Risiken oft aus Erfahrung vermeiden.

Back-Pressure: Wie Qualität zur Steuerung wird

Unter „Back-Pressure“ versteht der Autor den Widerstand, den das System einem Änderungsvorschlag entgegensetzt – je stärker dieser Widerstand, desto eher wird der Vorschlag abgelehnt oder zur Korrektur zurückgeschickt. Diese Steuerung kann über Compiler, Tests, Sicherheitsrichtlinien oder CI-Systeme erfolgen. Ideal ist es, wenn dieser Druck über den gesamten Entwicklungsprozess verteilt ist und nicht erst am Ende in der CI-Pipeline auftritt.

Der Autor warnt davor, menschliche Reviews in einen ansonsten automatisierten Prozess einzubauen, weil das die Durchsatzrate drastisch senkt. Stattdessen sollte man menschliche Aufmerksamkeit nur für die kniffligen Probleme reservieren, die Urteilsvermögen erfordern – etwa Designentscheidungen oder die Bewertung von Kompromissen zwischen verschiedenen Qualitätsdimensionen.

Gleichzeitig gibt es eine Skalierungsgrenze: Wenn die Anzahl der Agenten-Änderungen die Kapazität der automatisierten Verifikation übersteigt, entsteht ein Flaschenhals. Der Autor schlägt drei Lösungswege vor: Erstens, die Verifikationsinfrastruktur ausbauen – also mehr Tests, schnellere Analysen. Zweitens, die Rate der Agenten-Änderungen reduzieren. Drittens, die Qualitätsanforderungen lockern. Aus der Skalierungsperspektive ist es klug, alle drei Optionen verfügbar zu halten und je nach Situation einzusetzen.

Weniger Constraints, mehr Freiheit – aber nur an den richtigen Stellen

Interessant ist die These, dass mehr Constraints nicht immer besser sind. Der Autor plädiert für eine bewusste Verteilung: An den Stellen, wo Qualität kritisch ist, solltest du starke Constraints setzen. An anderen Stellen hingegen kann mehr Freiheit für Agenten die Produktivität steigern, ohne das Gesamtergebnis zu gefährden. Diese Abwägung muss aber explizit getroffen werden und nicht dem Zufall überlassen bleiben.

Die gesamte Qualitätsstrategie lässt sich als Spektrum beschreiben – von innovationsgetrieben bis risikominimierend. Jede Organisation muss ihren Platz darauf finden. Der Autor betont, dass Qualität kein einzelner Kennwert ist, sondern ein Bündel von Signalen: Korrektheit, Wartbarkeit, Performance, Sicherheit, Effizienz, Verständlichkeit. Jede dieser Dimensionen kann unterschiedlich gewichtet werden.

Die entscheidende Frage lautet: Wie viel Back-Pressure willst du an welcher Stelle? Ein Tool, das jede Änderung einer strengen statischen Analyse unterzieht, produziert viele Warnungen und bremst vielleicht den Agenten aus. Ein Tool, das nur die kritischen Pfade prüft, lässt mehr durch – aber auch mehr Fehler. Die Kunst besteht darin, die Qualitätsbarrieren dort zu platzieren, wo sie den größten Nutzen stiften.

Die Zukunft der Code-Review – und deine Rolle dabei

Der Autor schließt mit einem Gedanken, der auf den ersten Blick trivial klingt, aber tiefgreifende Folgen hat: Softwarequalität ist eine direkte Funktion der Constraints, die du um deine Agenten herum aufbaust. Das ist ein Perspektivwechsel weg vom Individuum und hin zum System. Du ersetzt das menschliche Auge durch eine Kette von automatisierten Prüfungen, die zusammen ein Sicherheitsnetz spannen.

Das bedeutet für dich als Entwickler oder Tech-Lead: Du musst lernen, Quality Gates zu entwerfen – nicht nur zu nutzen. Du musst verstehen, welche Metriken und Tests für deinen Code relevant sind und wo du Lücken lässt. Der Autor empfiehlt, mit einem breiten Satz an Checks zu starten und diese dann gezielt an deine Bedürfnisse anzupassen. Tools wie ESLint für Architekturregeln oder Sonar für Qualitätsgates können dabei helfen, aber der entscheidende Teil ist die intentionale Gestaltung.

Am Ende bleibt eine Erkenntnis: Die Kontrolle über den Code liegt nicht mehr in den Händen einzelner Reviewer, sondern in der Qualität der Constraints. Wenn dein System gut gewartete Gates hat, kann es auch Millionen von Agenten-Änderungen verarbeiten – und trotzdem liefert es Software, die man stolz ausliefern kann. Das ist der Preis für den Einstieg in die Welt der agentischen Softwareentwicklung: Du gibst die direkte Kontrolle über den Code ab, aber du gewinnst die Kontrolle über das System, das diese Kontrolle ausübt.

Nimm dir die Zeit, deine eigenen Qualitätsgates zu überdenken. Frage dich, wo dein System zu nachsichtig ist und wo du vielleicht zu streng bist. Denn die Qualität deiner Software wird in Zukunft mehr von diesen Entscheidungen abhängen als von der Brillanz eines einzelnen Entwicklers.

Quelle: addyo.substack.com

Fünf Prozent des üblichen Rechenbudgets genügen, um bei generativen multimodalen Modellen starke Ergebnisse zu erzielen. Das ist das Ergebnis einer systematischen Studie, die auf arXiv erschienen ist. Die Autoren untersuchten mit kontrollierten Experimenten auf synthetischen und realen Datensätzen, wie Sprach-, Bild- und Video-Modalitäten während des gemeinsamen Trainings interagieren. Sie identifizierten vier grundlegende Muster, die sie als „Physik des multimodalen Pretrainings“ bezeichnen. Wer verstehen will, warum manche Modelle besser mit Bild und Text umgehen, findet hier eine empirisch fundierte Antwort.

Wissen fließt – aber nicht symmetrisch

Die erste Erkenntnis betrifft den Wissensfluss zwischen den Modalitäten. Das Forschungsteam fand heraus, dass Sprache, visuelle Wahrnehmung und visuelle Generierung Wissen in unterschiedlichen Mustern übertragen – und diese Übertragung ist nicht symmetrisch. Das Sprachverständnis profitierte erheblich von visuellen Daten. Die visuelle Wahrnehmung profitierte kaum von reinem Sprachinput. Die visuelle Generierung hing stark von beiden anderen Modalitäten ab, aber auch hier zeigte sich eine klare Asymmetrie: Ohne sprachliche Anleitung blieb die Bildgenerierung deutlich schwächer.

Diese Asymmetrie erinnert an ein Team, in dem einige Mitglieder viel von anderen lernen, ohne selbst viel beizutragen. Der Transfer ist gerichtet und nicht reziprok. Das hat praktische Konsequenzen für das Design von Trainingspipelines. Wer weiß, welche Modalität von welcher profitiert, kann Datenmengen und Trainingszeitpunkt entsprechend gewichten. Die Autoren zeigen, dass dieser Wissenstransfer über verschiedene Architekturen hinweg stabil bleibt. Es handelt sich also um ein grundlegendes Prinzip, nicht um einen Zufall einer bestimmten Modellfamilie.

Synergie oder Konkurrenz? Die Komplexität entscheidet

Die zweite Erkenntnis betrifft das Verhältnis von Synergie und Konkurrenz zwischen den Modalitäten. Die Forscher fanden heraus, dass die Komplexität der Daten der entscheidende Faktor dafür ist, ob sich Modalitäten gegenseitig unterstützen oder behindern. Bei einfachen, gut strukturierten Daten überwiegt oft die Konkurrenz: Das Modell stützt sich auf eine dominante Modalität und ignoriert die andere. Bei komplexen, realitätsnahen Daten entsteht echte Synergie – das Modell lernt, die Stärken beider Modalitäten zu kombinieren.

Architektonisch zeigte sich, dass bestimmte Bausteine diese Synergie fördern. Besonders wirksam waren geteilte Aufmerksamkeitsmechanismen (shared attention) kombiniert mit modalitätsspezifischen Feed-Forward-Schichten und einer gemeinsamen Normalisierung. Diese Kombination erlaubt es dem Modell, ein gemeinsames Verständnis aufzubauen, ohne die individuellen Besonderheiten jeder Modalität zu verlieren. Die Effekte blieben über verschiedene visuelle Tokenizer hinweg stabil – die Forscher testeten mehrere Designs und kamen zu konsistenten Ergebnissen.

Für Modellentwickler heißt das: Die Wahl der Architektur ist ebenso wichtig wie die Wahl der Daten. Wer Synergie fördern will, investiert in geteilte Aufmerksamkeit und achtet auf die Komplexität der Trainingsdaten. Es geht nicht darum, einfach alles zu mischen, sondern die Bedingungen zu schaffen, unter denen Modalitäten voneinander profitieren.

Frühe Vereinheitlichung verhindert Sehfaulheit

Die dritte Erkenntnis ist vielleicht die folgenreichste: Modalitäten sollten von Anfang an gemeinsam trainiert werden, nicht erst später zusammengeführt werden. Die Studie nennt das „Early Unification“ und zeigt, dass eine späte Alignierung oder sequenzielles Training deutlich schlechtere Ergebnisse liefert. Der Grund ist ein Phänomen, das die Autoren als „Vision Laziness“ bezeichnen – übersetzt etwa „Sehfaulheit“. Wenn das Modell zunächst nur mit Sprache trainiert wird und später Bilder hinzukommen, hat es sich bereits an sprachliche Prioritäten gewöhnt und ignoriert die visuellen Informationen weitgehend. Es nutzt die Bilder nur noch als oberflächliche Bestätigung für das, was es schon aus dem Text erwartet.

Die Folge ist ein Modell, das auf Bildern hervorragend funktioniert, solange der Text eindeutig ist, aber sofort scheitert, wenn die visuelle Information wirklich entscheidend wird. Ein Beispiel: Das Modell sieht ein Bild eines Hundes im Wasser und hört den Satz „Das Tier schwimmt“. Statt das Bild tatsächlich zu analysieren, verlässt es sich auf den Text und rät, dass es sich um einen Hund handelt – auch wenn es in Wahrheit ein Otter ist.

Frühe Vereinheitlichung verhindert dieses Problem, weil das Modell von Anfang an lernt, dass visuelle und sprachliche Information gemeinsam relevant sind. Die Forscher zeigen in ihren Experimenten, dass diese Strategie nicht nur die Genauigkeit verbessert, sondern auch die Robustheit gegenüber unvollständigen oder irreführenden Texten erhöht. Wer ein multimodales Modell aufbaut, sollte das Training niemals mit einer einzelnen Modalität beginnen.

Effiziente Rezepte: Fünf Prozent Rechenbudget reichen

Die vierte Erkenntnis ist praktisch: Die Autoren haben aus ihren Erkenntnissen konkrete Trainingsrezepte abgeleitet, die mit nur 5 % des üblichen Rechenbudgets auskommen und trotzdem starke generative Leistung erzielen. Das klingt fast zu gut, um wahr zu sein, aber die Ergebnisse sind reproduzierbar. Der Schlüssel liegt darin, die richtigen Voraussetzungen für Synergie zu schaffen und die frühe Vereinheitlichung konsequent umzusetzen. Anstatt riesige Mengen an Daten mit einer standardisierten Pipeline zu verarbeiten, wählt man eine Architektur, die den Wissensfluss zwischen Modalitäten begünstigt, und trainiert von Anfang an gemeinsam.

Ein zentraler Baustein ist die gemeinsame Aufmerksamkeit, gepaart mit modalitätsspezifischen Feed-Forward-Schichten. Das Modell lernt dadurch, gemeinsame Repräsentationen zu bilden, ohne die Besonderheiten der jeweiligen Modalität zu verlieren. Die Autoren zeigen außerdem, dass eine geschickte Reihenfolge der Datenmischung – zuerst komplexe Beispiele, später einfachere – den Trainingsprozess zusätzlich beschleunigt. Diese Rezepte sind keine theoretischen Spekulationen, sondern wurden in kontrollierten Experimenten validiert.

Das hat konkrete Folgen: Wer bisher glaubte, dass multimodale Modelle nur von großen Tech-Unternehmen mit riesigen Rechenkapazitäten trainiert werden können, muss sein Bild revidieren. Die Studie zeigt einen Weg, wie auch mit begrenzten Ressourcen beeindruckende Ergebnisse möglich sind – vorausgesetzt, man versteht die zugrunde liegende Physik.

Die Bestätigung bei 13,5 Milliarden Parametern

Um zu prüfen, ob ihre Erkenntnisse auch auf große Modelle übertragbar sind, haben die Forscher zusätzlich mehrere 13,5-Milliarden-Parameter-Mischmodelle (MoE) mit 2 Billionen Tokens trainiert. Das ist ein massiver Rechenaufwand – aber genau hier zeigte sich, dass die zuvor identifizierten Prinzipien auch in der Skalierung Bestand haben. Die Modelle mit früher Vereinheitlichung und synergetisch-fördernder Architektur übertrafen klar die Varianten mit später Alignierung, und zwar sowohl bei der Bildgenerierung als auch bei der visuellen Verständnisleistung.

Bemerkenswert ist, dass auch auf dieser Skala die Effizienzgewinne spürbar waren: Die mit den optimierten Rezepten trainierten Modelle erreichten mit deutlich weniger Trainingsschritten die gleiche Leistung wie Modelle mit herkömmlichen Methoden. Das bestätigt, dass die „Physik des multimodalen Pretrainings“ kein Artefakt kleiner Experimente ist, sondern ein grundlegendes Prinzip, das mit wachsender Modellgröße sogar noch relevanter wird.

Die Studie liefert eine empirische Landkarte, die zeigt, welche Stellschrauben wirklich wichtig sind. Das reicht über akademische Zirkel hinaus – es demokratisiert den Zugang zu leistungsfähigen multimodalen Systemen.

Frühe Vereinheitlichung, geteilte Aufmerksamkeit und ein Bewusstsein für den asymmetrischen Wissensfluss sind die Hebel, die den Unterschied machen. Wer diese Prinzipien beachtet, kann mit einem Bruchteil der Ressourcen erstaunlich weit kommen. Rechenzeit ist die teuerste Ressource im modernen KI-Betrieb.

Quelle: arxiv.org

Ein Chief Financial Officer sitzt an einem Montagmorgen in seinem Büro und öffnet das Dashboard der IT-Ausgaben. Die Zahlen für das laufende Quartal zeigen eine Abweichung, die er nicht einordnen kann: Die Kosten für künstliche Intelligenz sind um 40 Prozent höher als geplant. Niemand hat ihn vor dieser Entwicklung gewarnt – keine Prognose, keine Risikoanalyse, kein Hinweis in den wöchentlichen Statusberichten.

Die Szene ist kein Einzelfall. Sie wiederholt sich in immer mehr Unternehmen. KI-Projekte entpuppen sich als Kostenfalle, die erst spät sichtbar wird. Ein neuer Report des Softwarehauses Mavvirk zeichnet ein deutliches Bild: Fast die Hälfte aller befragten Organisationen musste KI-bedingte Ausgaben-Überraschungen bereits im Vorstand diskutieren. Ein Viertel hat laufende oder geplante KI-Initiativen wegen unvorhergesehener Kosten gestoppt oder verschoben.

Die Zahlen des Mavvirk-Reports

Mavvirk, ein Anbieter für Kostenmanagement-Software, hat für seinen „State of AI Cost Governance Report 2026“ insgesamt 396 Unternehmen aus verschiedenen Branchen befragt. Zwei Drittel der Befragten geben an, dass unerwartete KI-Kosten mindestens eine Geschäftsentscheidung materiell beeinflusst haben. Ein Drittel musste einen Notfall-Stopp für neue Ausgaben verhängen, um die steigenden Rechnungen einzudämmen.

Besonders auffällig ist, dass die Kostenprobleme nicht allein aus den Preisen für KI-Modelle entstehen. Sundeep Goel, CEO von Mavvirk, sagt im Report: „KI verändert grundlegend, wie Infrastruktur verbraucht wird und wie sich Kosten ansammeln. Was früher planbare IT-Ausgaben waren, ist heute dynamisch, verteilt und schwer zuzuordnen.“ Ausgaben für KI verteilen sich über viele Einzelposten – von Developer-Tools über Datenplattformen bis hin zu autonomen Agenten, die quasi endlos Rechenleistung konsumieren. Viele Firmen haben keine Werkzeuge, um diese Ausgaben sauber zu erfassen.

Weil niemand die Gesamtkosten überblickt, kann auch niemand den Return on Investment (ROI) belastbar berechnen. Ray Rike, CEO von Benchmarkit, sagt im Report: „Alle reden über KI und ROI, aber ROI ist Mathematik. Man kann keine Rendite berechnen, wenn man die Kosten nicht kennt.“ Daran scheitern viele Projekte: Sie werden nicht zu Ende gedacht, weil niemand die langfristigen Kosten verantwortlich budgetiert hat.

Warum KI-Kosten schwer zu kontrollieren sind

Die Gründe für die Überraschungen liegen in der Fragmentierung der KI-Landschaft. Unternehmen nutzen eine Vielzahl von Diensten: einzelne LLM-Modelle, Datenpipelines, Vektordatenbanken, Inferenz-Server und immer häufiger auch agentische Workflows, die mehrere Schritte autonom abarbeiten. Jeder dieser Bausteine erzeugt eigene Kosten – und die Summe ist kaum im Voraus abzuschätzen.

Rita Sallam, Chief of Research für Daten und Analytik bei Gartner, weist auf einen Widerspruch hin: Während die reinen Modellpreise (etwa Kosten pro Token) sinken, steigen die Gesamtkosten pro Aufgabe. Der Grund: Agentische Systeme verlangen zunehmend komplexere Denkprozesse, die deutlich mehr Rechenschritte benötigen – und die Rechnung dafür wächst exponentiell. „Die Preisgestaltung verlagert sich auf nutzungsbasierte Modelle, was die Kosten für komplexe, autonome Workflows in die Höhe treibt und häufig die Einsparungen übersteigt, die sie eigentlich erzeugen sollten“, erklärt sie gegenüber CIO Dive.

Hinzu kommt, dass viele Entscheidungsträger erst spät von den hohen Ausgaben erfahren. Die Sichtbarkeit ist schlecht, weil die Kosten nicht einem einzelnen Projekt zugeordnet werden können, sondern über verschiedene Konten und Teams verstreut sind. Das erinnert an ein bekanntes Problem aus der Cloud-Ära: Auch dort überschritten Budgets oft die Planung, weil Speicher- und Transfergebühren nicht im Blick waren. Daten von Wasabi Technologies aus dem letzten Jahr zeigen, dass fast zwei Drittel der Unternehmen ihr Cloud-Speicherbudget überschritten – wegen unvorhergesehener Nutzung und Egress-Fees.

FinOps: Ein Ansatz aus der Cloud-Welt

Aus der Cloud-Welt gibt es einen etablierten Lösungsansatz: FinOps. Was ursprünglich entwickelt wurde, um Cloud-Kosten zu kontrollieren, wird zunehmend auch auf KI angewandt. FinOps steht für ein Bündel aus Prozessen, Tools und kulturellen Praktiken, die Finanzen, Technik und Business zusammenbringen, um Ausgaben transparent zu machen und zu optimieren. Der Grundgedanke ist simpel: Erst wer die Kosten versteht, kann sie steuern.

Mittlerweile reagieren auch die großen Cloud-Anbieter auf den Druck. Google Cloud, AWS und Microsoft haben in den vergangenen Monaten einige Speicher- und Transfergebühren reduziert, um Kunden zu entlasten. Das hilft, löst das Grundproblem aber nicht. Denn die KI-Kosten entstehen nicht nur in der Cloud-Infrastruktur, sondern auch in den Modellausgaben selbst, die sich nur schwer standardisieren lassen.

Rita Sallam vom Gartner fordert deshalb einen Perspektivwechsel: „Unternehmen sollten die KI-Kostenoptimierung als architektonische Anforderung betrachten, nicht als nachträgliche Finanzübung.“ Das bedeutet, schon bei der Entwicklung über Kostenaspekte nachzudenken – nicht erst, wenn die Rechnung kommt. Modellwahl, Pipelinedesign und Nutzungspolitik müssen frühzeitig auf Kosteneffizienz ausgelegt sein.

Gegenmaßnahmen: Modelle, Routen, Bildung

Sallam empfiehlt, einfache Anfragen zu preisgünstigeren Modellen zu routen, anstatt immer das teuerste Reasoning-Modell zu verwenden. „Man sollte keine Ferrari nehmen, wenn ein Kia auch reicht.“ Es geht nicht um Leistungsverzicht, sondern um wirtschaftlichen Einsatz. Ein kleines, domänenspezifisches Sprachmodell kann oft genauso gute Ergebnisse liefern wie ein großes, universelles Modell – zu einem Bruchteil der Kosten.

Darüber hinaus betont Sallam, wie wichtig es ist, die KI-Fähigkeiten der Mitarbeiter zu fördern. „Die Nutzer müssen die finanziellen Konsequenzen ihres KI-Einsatzes verstehen. Es bringt nichts, wenn sie das teuerste Reasoning-Modell nutzen, um das Wetter zu checken.“ Sie fordert verbindliche Schulungen zu „KI-Token-Finanzkompetenz“. Wenn die Belegschaft versteht, dass jede Anfrage reale Kosten erzeugt, stellt sich ein achtsameres Nutzungsverhalten ein.

Die Empfehlungen der Experten lassen sich zu einem Drei-Punkte-Plan zusammenfassen: Erstens, die Kostenarchitektur fest ins Design integrieren. Zweitens, ein Governance-Rahmenwerk schaffen, das technische und finanzielle Aspekte abdeckt. Drittens, die Mitarbeiter aktiv schulen und in die Verantwortung nehmen.

Was du jetzt in deinem Unternehmen tun kannst

Die Entwicklung betrifft nicht nur Großkonzerne – auch mittelständische Unternehmen, die gerade mit KI experimentieren, stehen vor den gleichen Herausforderungen. Wenn du in deinem Unternehmen für IT-Strategie oder Finanzen zuständig bist, gibt es konkrete Schritte, die du sofort einleiten kannst. Beginne damit, eine Inventur deiner KI-Systeme zu erstellen: Welche Modelle werden genutzt? Welche Workflows laufen auf welcher Infrastruktur? Wer hat Zugriff auf welche Ressourcen? Ohne diese Grundlagen bleibt jede Kostendiskussion Stückwerk.

Setze klare Budgetgrenzen und implementiere Monitoring-Tools, die dir Echtzeitdaten über die KI-Ausgaben liefern. Es gibt spezialisierte Lösungen, die Token-Verbrauch und Modellkosten transparent machen und Alarme bei Abweichungen auslösen. Scheue dich nicht davor, Projekte zu verlangsamen, wenn die Wirtschaftlichkeit nicht stimmt. Ein Viertel der Unternehmen hat bereits KI-Initiativen pausiert oder gestoppt – das ist keine Niederlage, sondern eine bewusste Entscheidung.

Am Ende braucht es eine kulturelle Veränderung. KI verursacht Kosten wie jede andere Technologie. Wer diese Realität akzeptiert, plant realistisch. Die Zahlen aus dem Mavvirk-Report zeigen: KI erfordert finanzielle Disziplin, sonst übersteigen die Ausgaben den Nutzen.

Quelle: ciodive.com

95 Sicherheitsberichte über 32 Produkte und Konfigurationen ergeben ein eindeutiges Bild: Jede getestete NAT-Implementierung ist verwundbar. Der unabhängige Forscher Malcolm Stagg präsentierte auf der Black Hat USA 2026 die Angriffsklasse NatJack. Sie manipuliert die Verbindungsverwaltung von Network Address Translation (NAT) direkt. Aktive Verbindungen lassen sich entführen, DNS-Antworten vergiften und Denial-of-Service auslösen. Klassische IP-Spoofing-Angriffe oder Zugriff auf den Broadcast-Domänen-Bereich sind nicht nötig.

Wenn du ein Netzwerk betreibst, solltest du genau hinschauen. NatJack funktioniert gegen Windows, Linux und macOS gleichermaßen – obwohl diese Systeme keinen gemeinsamen NAT-Codebase haben. Das deutet auf ein grundlegendes Designproblem hin, nicht auf einen einzelnen Programmierfehler.

Stell dir NAT wie eine Hausverwaltung vor, die alle Briefe für ein Mehrfamilienhaus an einer Adresse annimmt und dann an die Wohnungen weiterleitet. Die Hausverwaltung prüft nicht, ob ein Absender wirklich der ist, der er zu sein behauptet. Sie vertraut darauf, dass niemand böswillig handelt. Genau diese Vertrauenslücke macht NatJack aus.

Die Vertrauensannahme in NAT

NAT entstand in den frühen 1990er-Jahren als Übergangslösung gegen die IPv4-Adressknappheit. Mehrere Geräte teilen sich eine öffentliche IP-Adresse, intern verwenden sie private Adressen. Die Spezifikationen, die dieses Verhalten festlegten, gingen von einer friedlichen Umgebung aus. Stagg erklärt, dass diese Annahme tief in den RFCs verankert ist und bis heute fortbesteht.

Die Unter-Spezifikation erlaubt es der NAT, Verbindungen anhand von Quell- und Zieladressen sowie Ports zu verfolgen. Die dabei entstehende Tabelle, die Connection Tracking Table, ist das Herzstück von NAT. Sie hält fest, welches interne Gerät mit welchem externen Ziel kommuniziert und welche temporären Ports zugeordnet wurden. Wer die Kontrolle über diese Tabelle erlangt, kann praktisch jede Verbindung durch den NAT-Punkt umleiten.

Die Sicherheitslücke ist nicht neu. 2010 zeigte Samy Kamkar mit NAT Pinning, wie sich NAT-Verhalten manipulieren lässt. 2020 folgte NAT Slipstreaming, das das Application Level Gateway (ALG) ausnutzte. Diese Angriffe erforderten aber entweder eine Interaktion des Opfers oder den Einsatz von ALG-Diensten. NatJack umgeht diese Hürden: Es greift direkt auf die Connection Tracking Table zu, benötigt keine ALG-Unterstützung und genügt eine aktive Verbindung, die das Opfer bereits aufgebaut hat.

Layer-2-Isolationen wie VLAN-Segmentierung oder Switch-Port-Isolation bieten keinen Schutz. Die Angriffe finden auf Ebene 3 und 4 statt – in der Vermittlungs- und Transportschicht – und richten sich gegen die gemeinsame NAT-Infrastruktur. Selbst wenn du deine Netzwerksegmente strikt trennst, bleiben alle Geräte, die dieselbe NAT verwenden, verwundbar.

Vier Techniken, ein gemeinsamer Kern

NatJack umfasst vier verschiedene Angriffsvarianten, die alle auf derselben Schwachstelle beruhen: der fehlenden Überprüfung von Paketen, die die NAT-Tabelle verändern können. Stagg hat diese Techniken dokumentiert und veröffentlicht.

Die erste Technik ist die TCP-Verbindungsentführung. Der Angreifer sendet manipulierte Pakete, die eine laufende Verbindung in den Zustand „geschlossen“ versetzen. Dafür nutzt er den RFC-1337-Mechanismus namens TIME-WAIT Assassination. Der Zustand lässt sich mit wenigen Paketen erreichen, ohne auf ein normales Timeout zu warten. Anschließend ersetzt der Angreifer den Tabelleneintrag der Verbindung durch einen eigenen, sodass die Kommunikation über ihn umgeleitet wird. So kann er Daten abfangen oder sich in die Verbindung einschleusen.

Die zweite Technik ist die DNS-Antwort-Vergiftung. NatJack fängt UDP-DNS-Antworten ab, die durch die NAT laufen, und verändert sie. Das Opfer erhält gefälschte IP-Adressen für angefragte Domains, was zu Phishing oder Weiterleitungen auf Malware-Server führen kann. Der Angriff bleibt für den Nutzer unsichtbar: Die DNS-Antworten kommen ja von der NAT, der Browser ahnt nicht, dass sie manipuliert wurden.

Die dritte Technik ist ein Denial-of-Service-Angriff auf die NAT-Tabelle selbst. Der Angreifer sendet massenhaft Verbindungsanfragen oder Pakete mit gefälschten Adressen und füllt die Tabelle, bis keine neuen Verbindungen mehr aufgebaut werden können. Das betrifft nicht nur das einzelne Gerät, sondern alle Geräte hinter derselben NAT. Ein einziges bösartiges Gerät kann das gesamte Netzwerk lahmlegen.

Viertens gibt es die Verbindungs-Port-Identifikation. Der Angreifer findet heraus, welchen externen Port die NAT einem aktiven Datenstrom zugewiesen hat. Diese Information ist die Grundlage für die anderen drei Angriffe – ohne den korrekten Port lassen sich die Tabelleneinträge nicht gezielt manipulieren. Die Identifikation selbst ist nicht schädlich, dient aber als Aufklärungsphase.

Alle vier Techniken sind kombinierbar. Ein Angreifer kann zuerst den Port einer Verbindung ermitteln, dann die Verbindung beenden, den Tabelleneintrag übernehmen und anschließend gefälschte DNS-Antworten einschleusen. Das geht in Sekundenschnelle und erfordert keine besonderen Privilegien – lediglich die Möglichkeit, Pakete durch dieselbe NAT zu senden.

Herstellerreaktionen: Uneinheitlich und teils enttäuschend

Stagg meldete die Schwachstellen an dreizehn Hersteller. Die Antworten fielen sehr unterschiedlich aus. Das Linux-Kernel-Team wies den Bericht zunächst mit den Worten „total bogus“ zurück, wie Stagg in einem Interview berichtete. Er war überrascht und enttäuscht, doch später änderte sich die Lage: Auf Anfrage von Microsoft hin wurde der Fehler im Linux-Kernel behoben, um Azure Kubernetes Service zu unterstützen. Dafür erhielt die Schwachstelle die CVE-2026-63913.

Auch Microsoft selbst war betroffen: Die Windows-NAT-Implementierung für Hyper-V erhielt die CVE-2026-56181. Der Patch wurde im Rahmen eines regulären Sicherheitsupdates ausgeliefert. Andere Anbieter wie Cisco und Apple bewerteten die Ergebnisse jedoch nicht als Sicherheitslücken. Cisco verwies auf dokumentierte Mitigationsmaßnahmen für seine Produkte, Apple auf die Annahme, dass lokale Netzwerke feindlich sein können und End-to-End-Verschlüsselung wie TLS den Schaden begrenzt.

Stagg merkt an, dass Verschlüsselung tatsächlich hilft, aber sie kann nicht alles verhindern. Ein Angreifer, der eine Verbindung entführt, kann den verschlüsselten Datenstrom nicht lesen, aber er kann die Verbindung abrupt beenden oder blockieren. Das führt zu einem Denial-of-Service auf Anwendungsebene. Zudem sind nicht alle Protokolle standardmäßig verschlüsselt, und auch verschlüsselte Verbindungen können durch die Manipulation der NAT-Parameter unterbrochen werden.

Die unterschiedlichen Reaktionen zeigen, wie uneinheitlich die Branche mit Designfehlern umgeht. Einige Hersteller erkennen das Problem an und liefern Patches aus, andere sprechen von „Design-Limitationen“ und verweisen auf Best-Practice-Empfehlungen. Für dich als Netzwerkbetreiber bedeutet das: Du kannst dich nicht darauf verlassen, dass dein NAT-Gerät von Haus aus sicher ist. Du musst selbst aktiv werden.

Schutzmaßnahmen: Was Netzwerkbetreiber jetzt tun können

Auch ohne vollständige Patches gibt es mehrere konkrete Schritte, die das Risiko deutlich reduzieren. Stagg nennt in seinem Vortrag eine Reihe von Empfehlungen, die du direkt umsetzen kannst.

Überwache deine Netzwerk-Infrastruktur auf Auffälligkeiten. Dazu gehören eine vollständige oder fast volle NAT-Tabelle, ungewöhnliche Paketfluten über weite Portbereiche, die gleiche IP-Adresse an zwei physischen Standorten oder anomale SYN- und RST-Paketfolgen. Solche Anzeichen deuten darauf hin, dass ein Angreifer versucht, die Verbindungstabelle zu manipulieren.

Aktiviere den IP-Source-Guard an deinen Routern und Firewalls. Diese Schutzfunktion blockiert Pakete mit gefälschten Quelladressen, was viele NatJack-Varianten erschwert. Zusätzlich solltest du unvertrauenswürdige Geräte in separate Subnetze oder VLANs auslagern und die Verbindungsanzahl pro Client begrenzen – Stagg empfiehlt einen Wert von unter 10.000 gleichzeitig aktiven Verbindungen. Eine solche Begrenzung verhindert, dass ein einzelner Client die NAT-Tabelle überfluten kann.

Prüfe, ob dein NAT-Gerät sogenannte „Loose Connection Tracking“ oder „Port Preservation“ verwendet. Diese Modi erhöhen den Komfort für Anwendungen, schwächen aber auch die Sicherheit. Wenn möglich, deaktiviere sie und verwende striktes Adress- und Port-Mapping. Bei Containern solltest du den Netzwerkzugriff für unvertrauenswürdige Workloads einschränken: keine root-Rechte, keine Standard-Capabilities, und deaktiviere das Netzwerk für Container, die nicht zwingend erreichbar sein müssen.

In Cloud-Umgebungen gilt dieselbe Logik: Halte vertrauenswürdige und unvertrauenswürdige Workloads strikt getrennt, und nutze für Serverless-Funktionen dedizierte öffentliche IPs, anstatt sie über einen gemeinsamen NAT-Gateway laufen zu lassen. Stagg weist darauf hin, dass eine der Angriffsvarianten auch zwischen verschiedenen Subnetzen funktioniert, also eine Trennung auf Subnetzebene nicht ausreicht. Die Isolation muss auf NAT-Ebene erfolgen.

Die Lektion aus NatJack: Historische Annahmen neu bewerten

NatJack ist mehr als nur eine weitere Sicherheitslücke. Es zeigt, wie sehr sich die Bedrohungslandschaft verändert hat, während unsere Netzwerktechnik in den 1990er-Jahren stehen geblieben ist. Die Annahme, dass alle Geräte hinter einer NAT vertrauenswürdig sind, war vielleicht einmal vertretbar – in Zeiten, in denen Netzwerke aus wenigen Rechnern bestanden, die von derselben Administration kontrolliert wurden. Heute jedoch verbinden sich unzählige IoT-Geräte, Gastnotebooks, Smartphones und Cloud-Workloads über denselben NAT-Punkt. Jedes dieser Geräte könnte bereits kompromittiert sein oder böswillig agieren.

Die Tatsache, dass NatJack auf allen drei Betriebssystemfamilien funktioniert, ohne dass der Code geteilt wird, unterstreicht den systemischen Charakter des Problems. Es handelt sich nicht um einen einzelnen Fehler, sondern um ein grundlegendes Vertrauensmodell, das der heutigen Realität nicht mehr standhält. Sicherheitsarchitekten müssen sich daher von der Vorstellung verabschieden, dass eine NAT automatisch Schutz bietet. Sie ist eine Adressumsetzung, keine Firewall.

Für dich als Entscheider im Netzwerk bedeutet das: Du musst deine Sicherheitslösungen auf mehreren Ebenen implementieren. Verschleiere die interne Struktur nicht durch NAT allein, sondern setze zusätzlich auf robuste Firewall-Regeln, Intrusion-Detection-Systeme und eine konsequente Segmentierung. Und überprüfe regelmäßig die Designannahmen deiner Infrastruktur. Was vor zwanzig Jahren sicher war, kann heute ein Einfallstor sein.

Stagg fasst es treffend zusammen: Man dürfe sich nicht auf die historischen Designentscheidungen verlassen, sondern müsse die Bedrohungsmodelle von heute anwenden. NatJack ist ein Weckruf – und eine Chance, die Sicherheitsarchitektur endlich an die Realität anzupassen.

Quelle: networkworld.com