Val Bercovici, Chief AI Officer bei WEKA – Interviewreihe

Val Bercovici, Chief AI Officer bei WEKA, ist ein Führungskraft für KI‑ und Dateninfrastruktur, die sich darauf konzentriert, die Technologien voranzutreiben, die die nächste Generation künstlicher Intelligenz ermöglichen. Seit seinem Einstieg bei WEKA im Januar 2025 als Chief AI Officer konzentriert er sich auf den Aufbau von KI‑Agenten‑Infrastruktur, die Beschleunigung von Trainings‑ und Inferenz‑Workloads sowie die Verbesserung der Wirtschaftlichkeit von KI‑Rechenleistung. Neben seiner Rolle bei WEKA ist Bercovici KI‑Berater bei Home Dock, strategischer Berater für FermiHDI und The Hive sowie Vorsitzender von PencilDATA, wo seine Arbeit KI, Cybersicherheit, Blockchain, Cloud‑Computing und Dateninfrastruktur umfasst. Seine Laufbahn zeigt einen langjährigen Fokus auf die Entwicklung und Beratung aufkommender Technologien, die immer datenintensivere KI‑Systeme unterstützen sollen.

WEKA ist ein KI‑native Dateninfrastruktur‑Unternehmen, das eine softwaredefinierte Plattform baut, die den anspruchsvollen Datenanforderungen von Künstlicher Intelligenz, Machine Learning, Hochleistungsrechnen und anderen beschleunigten Workloads gerecht wird. Die WEKA Data Platform bietet Organisationen eine einheitliche Architektur, die in On‑Premises‑, Cloud‑, Hybrid‑ und Edge‑Umgebungen betrieben werden kann, um Speicherengpässe zu beseitigen, die GPU‑Auslastung zu verbessern und das Training sowie die Inferenz von KI‑Modellen zu beschleunigen. Das Unternehmen positioniert seine Technologie zunehmend rund um die entstehende Inferenz‑Wirtschaft und agentische KI, wobei die Infrastruktur für hochdurchsatz‑ und latenzarme Datenzugriffe in massivem Maßstab konzipiert ist und gleichzeitig komplexe KI‑Datenpipelines vereinfacht. WEKA bedient Unternehmen, Cloud‑Provider, Forschungseinrichtungen und KI‑Entwickler, die einige der leistungsintensivsten Rechenumgebungen der Welt betreiben.

Ihre Laufbahn führte Sie von der Gestaltung von NetApps früher Cloud‑Strategie und der Mitarbeit im Gründungs‑Governing‑Board von Kubernetes bis hin zum Aufbau von KI‑Infrastruktur bei WEKA. Wie hat diese Entwicklung Ihre Sichtweise darauf geprägt, wie man Infrastruktur für die nächste Phase der KI vorbereitet?

Jede Phase meiner Karriere wurde durch dasselbe Muster definiert: das Engpass verschiebt sich, und die Branche braucht Jahre, um es zu bemerken. In den frühen Tagen von Cloud und Kubernetes beobachteten wir, wie Rechenleistung elastisch wurde und Orchestrierung zum neuen Flaschenhals avancierte. Nachdem ich NetApp verlassen hatte, wo ich nach der SolidFire‑Akquisition CTO war, dachte ich, ich wüsste, wie schnell aussieht: niedrige Millisekunden für einen wirklich zufälligen First‑Byte‑Read unter Produktions‑Workloads.

Der Grund, warum ich zu WEKA kam, ist wirklich geekig. Es war eine Kennzahl: der erste nicht‑gecachte zufällige Byte‑Read dauert 70 µs, was keine Speicher‑Klassen‑Zahl ist. Ich hatte die Vorstellung von Latenz im Mikrosekunden‑Bereich bei dieser Art von System noch nie in Betracht gezogen. Das war die Erleuchtung: diese Technologie könnte Speicher‑Anwendungen, DRAM‑Klassen‑Anwendungen wie Redis und KV‑Cache bedienen, nicht nur Speicher. Und genau zu diesem Zeitpunkt begann die Inferenz das Training zu übertreffen, weil die Branche diese Modelle monetarisieren musste, und Agenten kamen, um den Speicher zum zentralen Faktor zu machen.

Das ist die Perspektive, die ich in die KI‑Infrastruktur einbringe. Wir haben dieses Szenario schon einmal erlebt. Cloud‑FinOps entstand, weil Unternehmen Infrastruktur ohne rigorose Unit‑Economics‑Betrachtung aufbauten und dann die Rechnung bekamen. KI befindet sich auf derselben Kurve, jedoch mit höherer Geschwindigkeit.   Da Unternehmen unvermeidlich gegen das „Token‑Maximieren“ ankämpfen, weil die API‑Verbrauchsrechnungen die geplanten Token‑Budgets bei weitem übersteigen, erleben wir den Aufstieg von KI‑FinOps. Dies ist der Punkt, an dem Organisationen die Inferenz nicht mehr als billige Utility betrachten, sondern die Token‑Effizienz als finanzielle Disziplin managen. KI‑FinOps beginnt mit Tokenomics: der Optimierung jeder Hardware‑ und Software‑Schicht des Inferenz‑Stacks, die die Stück‑Kosten pro Token beeinflusst. Momentan ist der größte Verschwendung in diesem Stack teure GPUs und neue ASICs, die untätig auf Speicher und Daten (auch „decode“ genannt) warten, anstatt FLOPS (auch „prefill“ genannt) zu nutzen. Wer das behebt, besitzt die nächste Phase der KI.

Das Weiße Haus hält die Details seines neuen KI‑Sicherheitsrahmens vertraulich. Wie können Unternehmen sich auf regulatorische Anforderungen vorbereiten, wenn sie noch nicht genau wissen, was getestet oder verlangt wird?

Unternehmen sollten nicht auf die endgültige Checkliste warten. Die konkreten Tests werden sich ändern, aber die zugrunde liegende Verpflichtung bleibt bestehen: Sie müssen nachweisen, was Ihr KI‑Modell getan hat, welche Daten es berührt hat und wie es sich zu einem bestimmten Zeitpunkt verhalten hat. Und Warten ist bereits weltweit keine Option. Der EU‑AI‑Act ist diesen Monat in Kraft getreten und stuft die meisten Agenten‑Orchestrierungen als Hochrisiko ein.

Das bedeutet, dass die Vorbereitungsarbeit Infrastrukturarbeit ist. Datenherkunft, Beobachtbarkeit, Reproduzierbarkeit und die Fähigkeit, den Modellzustand bei Bedarf zu rekonstruieren, sind für Unternehmen entscheidend. Schließlich müssen Organisationen Guardrail‑Modelle vor den Ausgaben implementieren, mit zugehörigen Latenz‑ und Token‑Budgets für die semantischen Verteidigungsschichten. Wenn Sie diese Fähigkeiten jetzt aufbauen, wird jedes Rahmenwerk zu einer Formatierungsübung. Warten Sie auf die endgültigen Regeln, und Sie werden Nachrüstungen zur Verantwortlichkeit in Systeme einbauen, die nie dafür konzipiert wurden, sich selbst zu erklären. Diese Nachrüstung ist immer teurer, als sie von Anfang an einzuplanen.

Letztendlich besteht die Lösung für den Aufbau sicherer KI darin, mehr KI einzusetzen, optimal und bewusst angewendet.

Welche neuen Infrastruktur‑Anforderungen könnte das Testen von KI‑Sicherheit erzeugen, und wie könnten diese Workloads im Vergleich zu herkömmlichem Modell‑Training oder Inferenz aussehen?

Training ist ein Feuerhose‑Ansatz. Man schiebt enorme Datenmengen durch ein Modell in einem kontinuierlichen, vorhersehbaren Muster. Sicherheitstests sind das Gegenteil: tausende Evaluations‑Szenarien, wiederholtes Probing, Versions‑über‑Versions‑Verhaltensvergleiche und adversariale Red‑Team‑Tests, die nie wirklich enden.

Dieses Profil ist entscheidend. Sicherheitstraining und -tests sind burstartig, leseintensiv und vergleichend. Sie erzeugen und verbrauchen enorme Mengen an Zwischenzuständen. Guardrail‑Modelle müssen von Natur aus heterogen und geschichtet sein, innerhalb enger Latenz‑Budgets implementiert werden und Evaluierungen mit dieser neuen Dimension von Sicherheitskriterien verstärken. Für solch fortgeschrittene oder cyber‑fähige Modelle ist das Workload‑Profil 24/7 persistent statt episodisch. Man führt keinen Test einmalig durch und archiviert die Ergebnisse. Man betreibt kontinuierliche Agent‑Schwarm‑Workloads, die in der Produktion mit Rechen‑, Speicher‑ und Daten‑Bandbreite um die kritischen Anwendungen konkurrieren, die sie schützen. Nach Qualität und Geschwindigkeit ist die heutige Infrastruktur meist nicht für diesen dritten Grundsatz ausgelegt.

Es gibt auch ein Messproblem darunter. Die meisten KI‑Benchmarks laufen heute mit 8.000 Tokens oder weniger, ein Prompt, eine Antwort. Ich scherze, dass sie künstliche Benchmarks künstlicher Intelligenz sind. Mitte 2026 laufen reale Agent‑Workloads mit 100.000 bis 400.000 Tokens Kontext über tausende Turns. Wenn Sicherheitsbewertungen diese Spielzeug‑Benchmarks übernehmen, zertifizieren wir Systeme für eine Welt, die es nicht gibt. Regulierungsbehörden bauen bereits mehr Kompetenz auf: NIST hat Agent‑Sicherheits‑Evaluierungs‑Tools Open‑Source gestellt, und frühe veröffentlichte Ergebnisse zeigen neuartige Agent‑Hijack‑Angriffe, die mehrmals so häufig erfolgreich sind wie bekannte Baselines. Genau das ist die Art von kontinuierlichem, adversarialem, kostenintensivem Testen, zu dem ich erwarte, dass Sicherheitsrahmen konvergieren.

Sollten Organisationen übermäßige Rechen‑ und Datenkapazitäten speziell für zukünftige Compliance‑ und Sicherheits‑Workloads aufbauen, oder gibt es einen effizienteren Ansatz, um für diese Unsicherheit zu planen?

Der Kauf von überschüssigen GPUs in der Hoffnung, dass die Auslastung nachkommt, lässt Kapital in depreciierender Hardware feststecken.

Die effiziente Lösung ist Infrastruktur, die zwischen Produktions‑ und Evaluierungs‑Workloads flexibel wechselt, ohne einen separaten Stack zu benötigen. Das ist im Kern ein Datenproblem. Wenn Sie Daten effizient bewegen und wiederverwenden, Kontext zwischen Workloads bewahren und Ihre Beschleuniger mit echter Arbeit beschäftigen können, wird Compliance zu einem inkrementellen Kostenfaktor statt zu einem parallelen Ausbau. Die Wirtschaftlichkeit von KI reduziert sich zunehmend darauf, welchen Wert Sie aus jedem Token, Byte und Watt ziehen. Machen Sie es richtig, und Sie können 3–4 × mehr Wert aus derselben Infrastruktur erzeugen oder den Rack‑Fußabdruck um bis zu 75 % reduzieren. Compliance sollte nach demselben Standard bewertet werden.

Der aktuelle Rahmen konzentriert sich offenbar auf fortgeschrittene geschlossene Modelle und schließt Open‑Weight‑Modelle aus. Welche Infrastruktur‑ oder Sicherheitsherausforderungen könnten entstehen, wenn man diese beiden Kategorien unterschiedlich behandelt?

Wenn Sie geschlossene Modelle und Open‑Weight‑Modelle unterschiedlich behandeln, erhalten Sie zwei Compliance‑Frameworks für Technologien, die dieselben Dinge tun, und die Lücke dazwischen ist der Risikobereich.

Ein Open‑Weight‑Modell kann feinabgestimmt und in Umgebungen eingesetzt werden, in denen der ursprüngliche Anbieter keinerlei Sicht hat. Die Regulierung des Anbieters bewirkt dort nichts. Und die Aufteilung ist bereits sichtbar: Exportkontrollen trafen in diesem Jahr die neuesten geschlossenen Frontier‑Modelle, während Open‑Weight‑Modelle frei Grenzen überschreiten und nun an der Spitze öffentlicher Fähigkeits‑Leaderboards stehen. Allerdings definiert die Verwaltung letztlich Frontier‑Modelle, die Governance kann nicht beim Modell selbst enden. Man benötigt Sichtbarkeit darüber, wo Modelle laufen, auf welche Daten sie zugreifen, welche Prompts, Antworten und Metadaten gespeichert werden, wie sie modifiziert wurden und ob die zugrunde liegende Infrastruktur tatsächlich skalierbare, gesteuerte KI unterstützen kann. Neue Updates zu ISO27001 und SOC2 werden erforderlich sein.

Meine Antwort lautet: Vertrauen, aber prüfen. Wenn Ihre Infrastruktur Ihnen die Token‑Kapazität bietet, können Sie heterogene Guardrails gegen jedes Modell einsetzen, bevor dessen Ausgabe verschickt wird: in‑ oder ausländisch, offen oder geschlossen. Objektive Verifikation übertrifft pauschales Vertrauen oder Misstrauen, das allein vom Herkunftsland eines Modells abhängt. Während offene Modelle proliferieren, liegt diese Verifikationsfähigkeit in der Infrastrukturschicht, und dort werden Unternehmen differenzieren. Richtlinien können festlegen, welche Modelle erlaubt sind. Die Infrastruktur entscheidet, ob diese Modelle verantwortungsbewusst und wirtschaftlich eingesetzt werden können.

Wenn KI‑Agenten autonomer werden und über längere Kontexte agieren, wie verändert das den Bedarf an Daten, Speicher und Rechenleistung, den Organisationen für Monitoring und Sicherheit bereitstellen müssen?

Ein Chatbot besteht aus einem Prompt und einer Antwort. Ein autonomer Agent ist ein laufender Prozess. Er berührt Dutzende von Systemen, ruft Informationen ab, trifft Zwischentscheidungen und akkumuliert über Stunden oder Tage einen Zustand, bevor er eine Aufgabe abschließt.

Sie können das nicht durch das Stichproben einzelner Tokens oder Antworten überwachen. Sie müssen die gesamte Sequenz erfassen: was der Agent wusste, wann er es wusste und was er als Nächstes tat. Jede Stunde, in der ein Agent läuft, wächst sein Zustand, ebenso wie der Speicher, die Datenbewegung und die Infrastruktur, die nötig sind, um ihn zu erfassen und zu analysieren. Monitoring hört auf, nur ein Logging‑Feature zu sein, und wird zu einer eigenständigen Arbeitslast mit eigenem Ressourcenbudget.

Verteidigung ist hier das dringende Thema. Das Speicherproblem der KI wird zum Sicherheitsproblem. Ein Coding‑Agent kann hochfahren, liefern und abschalten. Ein Cyber‑Security‑Agent kann das nicht. Er muss Kontext über tägliche Schichtwechsel in einem Security‑Operations‑Center, häufige Modell‑Updates und komplexe mehrstufige Angriffskampagnen behalten, die früher Wochen dauerten, heute jedoch mit koordinierten Maschinen­geschwindigkeiten operieren. Wenn dieser KI‑Arbeits‑Speicher alle paar Minuten verworfen und von Grund auf neu berechnet wird, hat ein Agent, der im ersten Stundenabschnitt eines Vorfalls ein anomales Verhalten erkannt hat, im zweiten Stundenabschnitt keine Erinnerung daran. Angreifer haben dieses Problem nicht. Ihre Agenten identifizieren und verfolgen Schwachstellen beständig, und Kill‑Chains schließen jetzt bei tokenomics‑optimierten Maschinen­geschwindigkeiten ab, sodass KI‑gestützte Cyber‑Verteidigung rund um die Uhr autonom laufen muss. Und das ist nicht theoretisch. Sicherheitsanbieter bereiten derzeit 24/7‑persistente Cyber‑Agenten vor, und das Erste, was sie feststellen, ist, dass die Wirtschaftlichkeit nichts mit Chat‑Workloads gemein hat. Einige Organisationen benötigen diese Agenten am Edge, in Einrichtungen, in die man in diesem Jahr weder ein GPU‑Rack noch eine Kühlanlage transportieren kann. Der eigentliche Test für Unternehmens‑KI ist die anhaltende Kontext‑Retention, nicht die Inferenz zu einem einzelnen Zeitpunkt. Das wird zu einem Kampf um Token‑Verbrauch, und wer das persistente Kontext‑Speichern in großem Maßstab löst, wird die erste horizontale Killer‑App im Unternehmens‑KI‑Umfeld antreiben: stets aktive blaue Agenten‑Schwärme.

Sie haben über die wachsende Bedeutung des „Kontext‑Speichers“ gesprochen, da KI‑Workloads über einfachen Chat hinaus zu persistierenden Agenten gehen. Könnte Kontext‑Speicher auch für Audits, Reproduktion oder Untersuchung von KI‑Verhalten wichtig werden?

Absolut, und das ist ein wichtiger Anwendungsfall. Jahrelang war Speicher eine Performance‑Frage: wie schnell man die GPU füttern kann, wie viel Kontext man halten kann. Sobald Agenten autonom handeln, wird derselbe Speicher zum Beweis. Wenn ein Agent eine Entscheidung auf Basis von Kontext trifft, den er über Tage angesammelt hat, sagen Ihnen der abschließende Prompt und die Ausgabe fast nichts darüber, warum er gehandelt hat. Die Erklärung liegt im angesammelten Zustand.

Technisch gesehen befindet sich der Großteil dieses Zustands im KV‑Cache, und die Branche behandelt ihn immer noch als entbehrlichen Scratch‑Space statt als dauerhafte Daten. Wenn Sie diesen Zustand bewahren und effizient abrufen können, können Sie rekonstruieren, was das System zum Zeitpunkt seiner Handlung wusste. Teams werden das zunächst zum Debuggen, dann für Sicherheitsbewertungen und schließlich für Ermittlungen nutzen. Den Kontext‑Speicher zu verwerfen bedeutet, das einzige Protokoll zu verlieren, das erklärt, warum Ihre KI getan hat, was sie getan hat.

Könnte KI‑Regulierung letztlich Unternehmen dazu zwingen, deutlich mehr Informationen über Modell‑Inputs, -Outputs, Checkpoints, Datenherkunft und Agenten‑Aktivität zu speichern? Was würde das für die KI‑Infrastruktur‑Architektur bedeuten?

Richtungsweisend, ja. Da KI‑Systeme immer folgenreicher werden, werden die Sichtbarkeitsanforderungen jeden Schritt der Pipeline abdecken. Man sieht bereits die frühen Signale: Teams planen, veralteten Kontext‑Speicher in günstigeren Object‑Storage‑Klassen ausschließlich für Audit‑Zwecke zu behalten, noch bevor eine Regulierung dies verlangt.

Die Authentifizierung von Monitoring mit Unveränderlichkeit ist essenziell. Das Manipulieren von Logs und anderen forensischen Artefakten durch bösartige Agenten ist zur Routine geworden und erfordert ausgeklügelte kryptografische Verifikationssysteme, die nicht anfällig für konzentrierte, zentrale Integritätsziele von Angriffen sind. Einfache Transparenz‑Logs oder Hash‑Ketten reichen nicht aus, um den Kollaborationsfähigkeiten koordinierter Agenten‑Schwärme zu begegnen. Hochgradig dezentralisierte, öffentliche Blockchain‑Architekturen eignen sich dafür ideal und heben den oft übersehenen Integritätswert im Kern der C‑I‑A‑Triade der Cybersicherheit hervor.

Retention ist nicht nur ein gewaltiges, unveränderliches Speicherproblem in großem Maßstab. Der schwierige Teil besteht darin, diese Informationen vertrauenswürdig, organisiert, indiziert und schnell genug abrufbar zu halten, um sie innerhalb einer Frist zu nutzen – sei es von einem Regulierer, einer Incident‑Response oder einem Gericht. Ein Petabyte an Agenten‑Aktivität, das Sie nicht abfragen können, ist eine Haftung, kein Protokoll. Der architektonische Wandel geht von „mehr Speicher“ zu einer Infrastruktur, die um objektiv verifizierbare, persistente, abfragbare KI‑Daten als Kern‑Workload herum gestaltet ist.

Viele Organisationen konzentrieren sich darauf, mehr GPUs zu kaufen, aber wo sehen Sie die weniger offensichtlichen Infrastruktur‑Engpässe, die entstehen, wenn KI‑Workloads skalieren und Sicherheitsanforderungen anspruchsvoller werden?

Die GPU steht im Fokus, weil sie kein unwesentlicher Kostenfaktor ist. Doch GPUs und insbesondere neue decode‑optimierte Beschleuniger (ASIC+SRAM) sind selten der eigentliche Engpass. Speicherbandbreite, Daten‑Gravitation und -Bewegung, Speicher‑Performance und Netzwerk bestimmen, ob diese Beschleuniger produktiv arbeiten oder unterausgelastet warten.

Wenn KI kontextintensiver wird, wird die Speicher‑Wall zum bestimmenden Engpass. Man kann weiter GPUs hinzufügen, aber wenn sie ihre Zyklen damit verbringen, Tokens neu zu berechnen oder Kontext zwischen Systemen zu verschieben, zahlt man für verschwendete Arbeit, immer wieder. Die Skalierung der Speicher‑Wall bedeutet, die Datenschicht wie gemeinsamen Speicher zu verhalten, jedoch mit echter Speicher‑Geschwindigkeit zu arbeiten. Diese HBM‑nahe Geschwindigkeitsbarriere ist für die aktuelle Welle profitabler KV‑Cache‑Offloading‑Lösungen entscheidend: jede von ihnen muss echte Speicher‑Klassen‑Performance liefern, damit die Tokenomics stimmen. Der Retentionswert für KV‑Cache ist eine Kosten‑Center‑Diskussion, sekundär zum Profit‑Center. Und wenn das Lesen von gecachtem Kontext langsamer ist als das reine Neuberechnen, ist der Cache für die Geschäfts‑Gleichung wertlos. Entscheidend ist nicht, wie viele GPUs Sie besitzen, sondern wie produktiv jede einzelne ist. Die Wirtschaftlichkeit von KI reduziert sich darauf, welchen Wert Sie aus jedem Token, Byte und Watt ziehen, und Sicherheitsanforderungen werden die Einsätze in dieser Rechnung nur erhöhen.

Wie Sie in die Zukunft blicken, erwarten Sie, dass KI‑Sicherheit und Compliance zu einer eigenständigen Infrastruktur‑Workload werden, ähnlich wie die Cybersicherheit zu einer dedizierten Schicht der Unternehmens‑Technologie wurde?

Wir werden sehen, dass KI‑Sicherheit und Compliance zu einer eigenständigen Workload werden, und die Parallele zur Cybersicherheit wirkt in beide Richtungen. Sicherheit wurde zu einer eigenen Schicht, sobald die Branche akzeptierte, dass sie kein gelegentliches Unterfangen sein kann. Die Cyber‑Versicherungsbranche machte das zu einer unverzichtbaren Notwendigkeit. KI‑Sicherheit folgt derselben zwingenden Entwicklung, da Modelle immer leistungsfähiger und autonomer werden.

Aber wir sollten aus den Fehlern der Sicherheit lernen. Sie wurde zu einem Nachrüstsatz: ein separater Stack, ein separates Budget, ein separates Team, das Probleme nachträglich entdeckt. Sicherheits‑Infrastruktur sollte diesen Fehler nicht wiederholen. Monitoring, Evaluation, Auditierbarkeit und unveränderliche Retention gehören in die KI‑Infrastruktur selbst und sollten von Anfang an gemeinsam entworfen werden.

Hier ist der Teil, den die meisten übersehen: sichere KI erfordert mehr KI. Guardrail‑Modelle sind nicht kostenlos. Sie müssen kontinuierlich trainiert, feinabgestimmt und bei jedem Schritt der Agenten‑Laufzeit inferenziert werden. Token‑Latenz‑Budgets machen das greifbar: jede Antwort hat ein festes Zeitfenster, und je mehr Tokens Sie innerhalb dieses Fensters verarbeiten können, desto mehr Verifikation können Sie durchführen, bevor die Ausgabe das System verlässt. Und die eigentliche Bedrohung durch Frontier‑Modelle liegt in ihrer agentischen Anwendung. Agenten laufen als hochvolumige Inferenz‑Schleifen und rufen Modelle über lange Zeiträume wiederholt auf. Jede Schleife besteht aus Beobachten, Orientieren, Entscheiden, Handeln, und jeder Schritt verbraucht Tokens. Das verwandelt KI‑Sicherheit in einen Krieg um Token‑Verbrauch. Angreifer setzen rote Agenten‑Schwärme ein, Verteidiger blaue Agenten‑Schwärme, und die Seite, die mehr Tokens pro Dollar und pro Watt erzeugen kann, gewinnt. Tokenomics liegen auf dem kritischen Pfad sowohl von Angriff als auch von Verteidigung. Das war im Sommer kein Gedankenexperiment mehr, als ein roter Agenten‑Schwarm‑Angriff auf ein großes Modell‑Repository die Branche wachrüttelte und innerhalb weniger Tage eine dedizierte Secure‑AI‑Allianz entstand. Inzwischen vervielfachen sich die Volumina weiter: die Token‑Verarbeitung der Branche hat sich von Billionen auf Billiarden erhöht.

Sobald Sicherheit zu einer stets aktiven Anforderung wird, hören ihre Rechen‑, Speicher‑ und Datenkosten auf, ein Overhead zu sein. Sie werden Teil der grundlegenden Unit‑Economics des KI‑Betriebs. Unternehmen, die das früh internalisieren, werden Sicherheit als Designeingabe behandeln. Alle anderen werden sie als Steuer ansehen.

Vielen Dank für das großartige Interview, Leser, die mehr erfahren möchten, sollten WEKA besuchen.