Cloudflare öffnet sein OAuth-Ökosystem für alle Kunden, unter dem Namen Self-managed OAuth. Unternehmen und Entwickler können nun eigene OAuth-Anwendungen anlegen, die auf ihr Cloudflare-Konto zugreifen dürfen, und damit Integrationen auf Basis der Cloudflare-API bauen. Bislang stand Third-Party-OAuth nur für wenige, manuell zugelassene Partner zur Verfügung. Wer eigene Anbindungen entwickeln wollte, musste meist auf API-Tokens ausweichen, die für delegierte Zugriffe oft weniger geeignet sind und sich schlechter verwalten lassen.

OAuth ist ein Standard, mit dem eine Anwendung im Namen eines Nutzers auf begrenzte Ressourcen zugreift, ohne dessen Passwort zu erhalten. Das Verfahren nutzt Zustimmungsdialoge, begrenzt Berechtigungen (Scopes) und ermöglicht es Anwendern, erteilte Zugriffe zentral zu widerrufen.

Mehr Kontrolle für Entwickler und Anwender

Cloudflare begründet in seinem Blog die Öffnung mit dem gewachsenen Bedarf der Entwicklerplattform. Da immer mehr Kunden Integrationen, Automatisierungen und agentische Werkzeuge nutzen, ist ein delegierter Zugriff für SaaS-Anbindungen und interne Entwicklerplattformen wichtiger geworden.

Parallel zur Öffnung hat Cloudflare die Sicherheits- und Verwaltungsfunktionen ausgebaut. Dazu gehören ein präziserer Zustimmungsdialog, eine bessere Sichtbarkeit der App-Inhaberschaft zur Abwehr von Phishing sowie eine zentrale Widerrufsfunktion im Dashboard.

Videos by heise

Aufwendiger Umbau im Hintergrund

Die Freigabe erforderte tiefgreifende Änderungen an der OAuth-Infrastruktur. Cloudflare setzt weiterhin auf die Open-Source-Engine Hydra, musste jedoch auf eine neuere Version migrieren. Der Anbieter teilte den Umbau in zwei Schritte auf: erst ein Upgrade auf die aktuelle 1.x-Reihe, danach der Wechsel auf 2.x.

Das erste Upgrade brachte technische Hürden mit sich. Die Datenbankmigrationen hätten Tabellen zeitweise exklusiv gesperrt und damit laufende OAuth-Operationen blockiert. Cloudflare passte deshalb die SQL-Migrationen an, nutzte CREATE INDEX CONCURRENTLY und änderte die Abfragen der Hydra-SDKs, um deserialisierungsanfällige SELECT *-Operationen zu vermeiden.

Für den größeren Sprung auf 2.x wählte Cloudflare ein Blue-Green-Verfahren. Dabei lief die neue Version auf einer Kopie der Produktionsdatenbank parallel. Erst nach Abschluss der Migration schaltete der Betreiber um. Um Datenverlust während der Übergangsphase zu verhindern, fing Cloudflare Widerrufe über eine Queue ab und spielte diese nach dem Umschalten in die neue Umgebung zurück.

Token-Verhalten und Migrationseffekte

Nach dem Wechsel auf 1.x registrierte Cloudflare vermehrt Fehler bei Refresh Tokens. Die Ursache lag in einem strengeren Verhalten der neuen Version: Wurde ein Refresh Token erneut verwendet, invalidierte Hydra die gesamte Kette aus Zugriffs- und Refresh-Token. Dies betraf insbesondere Clients mit hoher Anfragefrequenz wie Wrangler und MCP-Clients. Cloudflare fing dies vorübergehend in einem Worker ab, der den OAuth-Verkehr weiterleitet: Doppelte Refresh-Versuche werden dort kurz gepuffert und nicht an Hydra durchgereicht.

Auch der Wechsel auf 2.x verlief nicht völlig reibungslos. Ein Bereinigungsjob im Autorisierungsdienst löschte OAuth-Policy-Daten zu aggressiv. Ursache davon war eine fehlerhafte Hydra-Migration, die den Zustand gültiger Sitzungen beschädigte. Dies führte zu abweichenden Bewertungen zwischen Hydra und dem Autorisierungsdienst, was sich in gehäuften 403-Fehlern äußerte. Cloudflare spielte daraufhin Daten zurück und optimierte das Autorisierungsverhalten.

Mit dem Abschluss der Migration läuft der OAuth-Verkehr nach Angaben des Unternehmens stabiler und performanter. Das Live-System basiert nun auf derselben Grundlage wie die neueren OAuth-APIs, die Cloudflare bereits zuvor in der Staging-Umgebung validiert hatte. Kunden können jetzt ohne Sonderfreigabe eigene OAuth-Apps anlegen und Integrationen auf dieser Basis entwickeln.

Lesen Sie auch

Bots übernehmen Internet früher als gedacht

Cloudflare kauft Vite: Open Source und herstellerneutral – mit Millionenfonds

KI-Update: Verstörende Chatbots, Neue Audio-Modelle, Mythos, Cloudflare

Cloudflares KI-Umbau kostet ein Fünftel der Arbeitsplätze

Cloudflare gibt KI-Agenten ein Langzeitgedächtnis

Testsieger: Die beste mobile Klimaanlage

Top 10: Der beste Ventilator im Test

Prime Day 2026: Das sind die besten Deals

Software Testing: Was KI mit Vertrauen und Teamgefüge wirklich anrichtet

2026-06-25T08:33:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Richard Seidl diskutiert mit Jasmine Simons-Zahno darüber, wie künstliche Intelligenz das soziale Miteinander verändert.

(Bild: Richard Seidl)

10:33 Uhr

Lesezeit: 2 Min.

Developer

Von

Richard Seidl
Jasmine Simons-Zahno

Wie wirkt sich KI auf Teams aus? Mit Jasmine Simons-Zahno spricht Richard Seidl darüber, wie der zunehmende KI-Einsatz unser soziales Miteinander verändert: Kommunikation wird sachlicher, Vertrauen erodiert langsam, und das soziale Lernen, das gerade junge Menschen am Anfang ihrer Karriere brauchen, findet schlicht nicht mehr statt.

Jasmine Simons-Zahno erklärt, warum Reibung im Team kein Fehler ist, sondern eine Voraussetzung für Innovation, und warum der Allwissende in der Tasche uns gegenüber anderen glatter, aber nicht vertrauenswürdiger macht. Ihr Vorschlag klingt einfach, braucht aber echte Entscheidung: KI wie ein neues Teammitglied integrieren, also mit klaren Rollen, expliziten Vereinbarungen und dem Bewusstsein, dass dieser Aufwand kein Nice-to-have ist.

Richard Seidl ist Berater, Speaker und Podcast-Host. Für ihn ist klar: Wer heute exzellente Software kreieren möchte, denkt den Entwicklungsprozess ganzheitlich: Menschen, Kontext, Methoden und Tools. Er hat seine Erfahrungen in acht Fachbüchern veröffentlicht, betreibt erfolgreich zwei Community-Podcasts und ist Beirat der heise-Konferenz betterCode() Testing.

„Es gibt eine hohe Korrelation zwischen Vulnerabilität und Likeability.“ – Jasmine Simons-Zahno

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.

Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Google Ireland Limited) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.

Jasmine Simons-Zahno brennt für die menschliche Seite der Produktentwicklung. Sie coacht mit Leichtigkeit, Leidenschaft und Anspruch in Führungskontexten beliebiger Flughöhen in Unternehmen verschiedenster Größen. Ihre Stärke ist es, authentischer Spiegel für Menschen zu sein, die sich entwickeln dürfen, aber dem Ruf dazu gerade noch allzu gerne ausweichen möchten. Als Mitgründerin der Agile Growth, dreifache Mutter und ambitionierte Hobby-Köchin lässt sie nichts anbrennen.

Softwarequalität im Gespräch

Dieses Format fokussiert sich auf Softwarequalität: Ob Testautomatisierung, Qualität in agilen Projekten, Testdaten oder Testteams – Richard Seidl und seine Gäste betrachten die Dinge, die die Qualität in der Softwareentwicklung steigern.

Die aktuelle Episode ist auch auf Richard Seidls Blog verfügbar.

(mai)

Testsieger: Die beste mobile Klimaanlage

Top 10: Der beste Ventilator im Test

Prime Day 2026: Das sind die besten Deals

Mistral OCR 4: Dokumentenanalyse für 170 Sprachen

2026-06-24T15:13:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Mistral AI hat OCR 4 vorgestellt. Das Modell liest nicht nur Text aus, sondern strukturiert Inhalte für Enterprise Search und RAG-Pipelines.

(Bild: Mehaniq/Shutterstock.com)

24.06.2026, 17:13 Uhr

Lesezeit: 5 Min.

iX Magazin

Von

Moritz Förster

Mistral AI hat mit OCR 4 eine neue Version seines Dokumentenerkennungsmodells vorgestellt. Die Software soll nicht mehr nur Text aus PDFs und anderen Dokumenten auslesen, sondern den Inhalt zugleich strukturieren. Neu sind unter anderem Positionsangaben für Textblöcke, eine Klassifizierung der erkannten Elemente und Vertrauenswerte für einzelne Wörter und Seiten. Damit zielt das Modell auf Dokumentenverarbeitung in Unternehmenssuchsystemen, RAG-Pipelines und ähnlichen Workflows.

OCR 4 liefert mehr als reinen Text

Bisherige Systeme für die Optical Character Recognition (OCR) geben vor allem den reinen Text einer Seite aus. OCR 4 geht weiter: Das Modell markiert jedes erkannte Element mit einer Bounding Box, also einem Begrenzungsrahmen auf der Seite. Zusätzlich ordnet es Inhalte bestimmten Blocktypen zu, etwa Überschriften, Tabellen, Gleichungen oder Signaturen. Confidence Scores zeigen an, wie sicher das Modell bei der Erkennung ist.

So sollen sich Dokumente besser weiterverarbeiten lassen. Eine Suchanwendung kann etwa nicht nur den Wortlaut indexieren, sondern auch erkennen, ob ein Textabschnitt eine Überschrift oder ein Tabellenwert ist. Ein Prüfsystem kann die unsicheren Stellen an einen Menschen geben. Und ein Redaktions- oder Compliance-Workflow kann Textpassagen im Originaldokument exakt hervorheben oder schwärzen.

Einsatz in Suche, RAG und Agenten

Mistral sieht OCR 4 als Baustein für Enterprise Search, Retrieval-Augmented Generation und domänenspezifische Suchpipelines vor. Die strukturierte Ausgabe soll dabei helfen, Dokumente in sinnvolle Such- und Antwortbausteine zu zerlegen. Mistral bezeichnet das als semantisches Chunking: Nicht die Seitenlänge entscheidet über die Aufteilung, sondern die Struktur des Dokuments. Eine Tabelle oder ein Absatz bleiben dann eher als Einheit erhalten.

Auch für agentische Workflows plant Mistral den Einsatz – also in KI-Systemen, die nicht nur Informationen lesen, sondern auf Basis davon Aufgaben anstoßen, etwa Formulare ausfüllen, Rechnungen verarbeiten oder Compliance-Prüfungen vorbereiten. Entsprechend hilfreich ist es hierbei, wenn ein OCR-System nicht bloß Text liefert, sondern zugleich die strukturelle Funktion eines Inhaltselements kennt.

Mehrsprachigkeit und Self-Hosting

OCR 4 unterstützt nach Angaben von Mistral 170 Sprachen in zehn Sprachgruppen. Zu den genannten Gruppen zählen Englisch, westeuropäische und osteuropäische Sprachen, chinesische und ostasiatische Sprachen, ferner eine Sonderkategorie für Sprachen wie Hindi, Japanisch, Georgisch, Bengalisch oder Tamil. Das Unternehmen verweist dabei besonders auf bessere Ergebnisse bei Sprachen seiner Sonderkategorie sowie bei weniger verbreiteten Sprachen, bei denen andere Systeme häufiger Schwächen zeigen.

Das Modell lässt sich laut Mistral auf Wunsch in einer eigenen Container-Instanz betreiben, damit OCR 4 auch bei hohen Anforderungen an Datensouveränität, Datenschutz oder Compliance verwendet werden kann. Unterstützt werden gängige Formate wie PDF, DOC, PPT und OpenDocument.

Einordnung der Benchmarks

Mistral verweist bei OCR 4 auf eigene und externe Benchmarks. In einer Blindbewertung durch unabhängige Prüfer soll das Modell im Mittel besser abgeschnitten haben als konkurrierende OCR- und Document-AI-Systeme. Auf dem öffentlichen Benchmark OlmOCRBench erreichte OCR 4 laut Mistrals Ankündigung einen Spitzenwert von 85,20 Punkten. Auf OmniDocBench nennt das Unternehmen 93,07 Punkte.

Mistral weist aber selbst darauf hin, dass Benchmark-Ergebnisse bei mathematischen Formeln, mehrspaltigen Dokumenten oder fehlerhaften Referenzdaten verzerrt sein können. Ein Modell kann also in der Praxis richtig liegen, aber im Test trotzdem als falsch gewertet werden. Für eine belastbare Bewertung empfiehlt das Unternehmen deshalb eigene Dokumente und Workflows.

Videos by heise

API, Document AI und Preise

OCR 4 lässt sich per API anbinden. Die Grundfunktion liefert immer extrahierten Inhalt, Bounding Boxes, Blocktypen, Confidence Scores und Markdown-ähnlich strukturierten Text. Wer mehr Struktur braucht, kann zusätzliche Document-AI-Funktionen aktivieren. Dann lässt sich etwa eine JSON-Ausgabe nach einem vorgegebenen Schema erzeugen oder das Modell interpretiert Inhalte mit einem zusätzlichen Prompt.

Mistral trennt damit zwischen reiner Extraktion und strukturierter Weiterverarbeitung. Für Entwickler heißt das: Wer nur den OCR-Output benötigt, bleibt bei der Basiskonfiguration. Wer Rechnungen, Formulare oder andere Dokumente direkt in feste Felder überführen will, ergänzt die Document-AI-Parameter in derselben Anfrage. Nach Angaben von Mistral kostet die OCR-API 4 US-Dollar pro 1000 Seiten, im Batch-Betrieb 2 Dollar pro 1000 Seiten. Document AI liegt bei 5 Dollar pro 1000 Seiten.

Verfügbarkeit

Mistral OCR 4 und die darauf aufsetzenden Document-AI-Funktionen sind laut dem Unternehmen über Mistral Studio, Amazon SageMaker und Microsoft Foundry verfügbar. Zudem hat Mistral OCR 4 in das eigene Search Toolkit eingebunden, das sich derzeit in einer öffentlichen Vorschau befindet.

Lesen Sie auch

Mistrals Chatbot heißt jetzt „Vibe“ und erhält neue Fähigkeiten

Mistral und Harvey AI: Den Rechtssektor im Visier

Mistral AI: Neues Sprachmodell Medium 3.5 und Cloud-Coding-Agenten

KI-Update: 122 Milliarden für OpenAI, Regulierung, KI in der Musik, KI-Drohnen

Europäische KI-Autonomie: Mistral investiert 830 Mio. US-Dollar in Rechenzentrum

Prime Day 2026: Wir prüfen die besten Deals

Top 10: Der beste Ventilator im Test

Top 8: Die beste Kompressor-Kühlbox im Test

Sichere API-Zugriffe für Agenten mit Postman Passport

2026-06-24T13:04:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Mit Passport führt Postman ein sicheres Zugangssystem für APIs ein, das nicht mehr auf Credentials, sondern auf Access Control basiert.

(Bild: Wolf Hosbach / heise medien / KI)

24.06.2026, 15:04 Uhr

Lesezeit: 2 Min.

Developer

Von

Wolf Hosbach

Postman, Hersteller des gleichnamigen API-Entwicklungs-Tools, führt mit Passport ein sicheres Zugangssystem für APIs ein. Es basiert nicht mehr auf Zugangsschlüsseln (API-Keys, Credentials), die jeder verwenden kann, der sie besitzt – also auch Einbrecher. Sondern es führt eine Zugangskontrolle mit individuellen Zertifikaten ein.

API-Nutzer sind dabei kryptografisch eindeutig identifiziert und bekommen Zugänge von Postman granular und kontrolliert freigeschaltet. Der private Schlüssel verbleibt jeweils beim Nutzer, sodass niemand anderes die zugehörigen Zugangsschlüssel verwenden kann. Die Zugangsprüfung findet in einem speziellen Postman-Proxy innerhalb des Kundennetzwerks statt.

Privater Schlüssel und der Zugangs-Proxy verbleiben in der Umgebung des API-Nutzers.

(Bild: Postman)

Postman prüft das Zertifikat des Kunden und erteilt dauerhaften oder temporären Zugang zu API-Endpunkten. Agenten können Zugänge an Unteragenten weitergeben, aber nur kurzzeitig im zertifizierten Bereich. Unternehmensweite Access Points lassen sich ebenfalls in das System integrieren.

Videos by heise

Ein Zugriff am Proxy vorbei ist nicht möglich. Über die Zertifikate lassen sich auch feingranulare Zugriffsmodelle auf Endpunkte umsetzen.

Immer mehr API-Aufrufe durch Agenten

Postman reagiert damit auf die zunehmende und unkontrollierte Verbreitung von API-Credentials, die oft nur in Profilen, Textdateien oder YAML-Konfigurationen vorliegen und von Entwicklern im Alltag oft schnell hin- und herkopiert werden, gerne auch über Git, MS Teams oder Slack. Während eines Einsatzes findet sich ein Schlüssel laut Postman an acht Plätzen in einem Rechner und wird so zur leichten Beute für Angreifer.

Der zunehmende Einsatz von KI-Agenten im Entwicklungszyklus von Software erhöht diese Risiken noch, da Agenten selbsttätig mit den Schlüsseln umgehen und diese eventuell in der Infrastruktur oder an Unteragenten weitergeben.

Das neue System von Postman erhöht durch den Proxy zwar den Aufwand im Unternehmen, löst aber eine Reihe von Sicherheitsproblemen.

Lesen Sie auch

Secure-Boot: Zertifikatablauf steht an, Microsoft gibt weitere Hilfestellung

Vom Postweg ins BundID-Konto: Bundestag stimmt für digitales Führungszeugnis

C3A: Der neue BSI-Maßstab für souveräne Clouds im Überblick

BSI aktualisiert C5-Kriterienkatalog für Cloud-Sicherheit

„Passwort“ Folge 56: Unwirksame Beweise, ungültige Zertifikate, unverplante CVEs

Prime Day 2026: Wir prüfen die besten Deals

Top 10: Der beste Ventilator im Test

Top 8: Die beste Kompressor-Kühlbox im Test

KI-Coding-Tools: Geschwindigkeit ohne Kontrolle als Risiko

2026-06-24T12:25:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Der GitLab AI Accountability Report zeigt: Der Einsatz von KI macht das Coding schneller, aber ohne Kontrolle entstehen neue Risiken und technische Schulden.

(Bild: Manuel Masiero / KI / iX)

24.06.2026, 14:25 Uhr

Lesezeit: 4 Min.

Developer

Von

Manuel Masiero

Für die meisten Unternehmen zahlt sich der Einsatz von KI‑Coding‑Tools stärker aus als erwartet. Das hohe Tempo agentischer Softwareentwicklung wirft aber die Frage auf, inwieweit Teams noch kontrollieren können, was sie an Code ausliefern. Zu diesen Ergebnissen kommt der AI Accountability Report von GitLab.

Im Unternehmensumfeld ist KI-gestützte Softwareentwicklung längst Standard. Laut dem GitLab-Report haben 91 Prozent der DevSecOps‑Befragten mindestens zwei Coding-Tools im Einsatz, 54 Prozent drei oder mehr. Dabei berichten 60 Prozent von einer höheren Investmentrendite als ursprünglich erwartet, 78 Prozent von schnellerem Code-Output und 73 Prozent sagen, dass sich die Codequalität verbessert habe.

Die beiden Bereiche Compliance & Audits sowie Sicherheit profitieren laut Umfrage am wenigsten von KI.

(Bild: GitLab)

Die Umfrage-Teilnehmerinnen und -Teilnehmer wenden lediglich 16 Prozent ihrer Arbeitszeit dafür auf, neuen Code zu schreiben. Eine deutliche Mehrheit von 85 Prozent sagt, dass sich der Fokus stattdessen auf Review und Validierung von KI-Output verschoben hat. Dort trägt KI allerdings am wenigsten dazu bei, die Geschwindigkeit oder Effizienz zu steigern.

Das KI-Produktivitäts-Paradoxon spüren deshalb 79 Prozent der Befragten: Die individuelle Produktivität hat nach ihrem Empfinden zugenommen, die Geschwindigkeit des Software‑Lieferprozesses als Ganzes hingegen kaum.

Governance wichtiger als Geschwindigkeit

GitLab macht AI Accountability, sinngemäß die Verantwortung eines Unternehmens im Umgang mit KI, an der Fähigkeit fest, drei Fragen beantworten zu können: Woher kommt der KI-generierte Code, wofür war er gedacht und wer ist dafür verantwortlich, sobald er Produktionsstatus erreicht hat?

Laut GitLab haben die meisten Unternehmen keine Antworten darauf. „Die Ereignisse der letzten Monate, die von Lieferketten-Angriffen über Zuverlässigkeitsprobleme bis hin zu strengeren behördlichen Auflagen hinsichtlich Nachverfolgbarkeit und Herkunft von KI reichen, zeigen, dass Geschwindigkeit ohne Kontrolle kein Vorteil, sondern ein Risiko ist“, so Manav Khurana, Chief Product and Marketing Officer von GitLab.

Videos by heise

Im Report äußern 73 Prozent der Teilnehmerinnen und Teilnehmer Bedenken hinsichtlich der langfristigen Wartbarkeit von KI-generiertem Code; 80 Prozent meinen, dass ihr Unternehmen die KI-Werkzeuge schneller eingeführt hat, als Richtlinien zu deren Steuerung entwickelt wurden. Zudem birgt KI-generierter Code für 82 Prozent das Risiko, dass neue technische Schulden entstehen, auf die ihr Unternehmen noch nicht vorbereitet ist.

Besserung ist jedoch in Sicht: So wollen 91 Prozent der Teilnehmenden in den nächsten 12 Monaten Tools für KI-Code-Governance anschaffen. Ein Budget dafür haben 98 Prozent entweder bereits vorliegen oder zumindest eingeplant.

Wurde das Softwareproblem von KI-generiertem Code mitverursacht? 34 Prozent der Befragten konnten das im konkreten Fall nicht beantworten.

(Bild: GitLab)

Mensch oder Maschine: Wer hat’s geschrieben?

Bereits jetzt sind 87 Prozent der Befragten zuversichtlich, dass sie innerhalb von 24 Stunden feststellen könnten, ob KI-Code ein Produktionsproblem mitverschuldet hat. Allerdings waren 34 Prozent der Unternehmen genau dazu nicht in der Lage, als es zu einem solchen Vorfall kam. Als größte Hürden für Kontrolle und Nachverfolgbarkeit nennen 43 Prozent die Schwierigkeit, KI-generierten Code von manuell geschriebenem Code zu unterscheiden. Auf Platz zwei und drei folgen fragmentierte Toolchains (40 %) und Systeme, die die Code-Herkunft nicht erfassen (39 %).

Für den AI Accountability Report befragte GitLab im Februar 2026 insgesamt 1528 Personen, die sich zu etwa gleichen Anteilen aus sechs Ländern rekrutieren: USA, Deutschland, Großbritannien, Frankreich, Japan und Australien. Davon ordnen sich 43 Prozent dem Bereich IT Operations zu, 37 Prozent zu IT-Security und 20 Prozent zum Bereich Softwareentwicklung. Die vollständige Umfrage steht auf der GitLab-Webseite gegen Registrierung kostenlos zum Download bereit.

(mro)

Prime Day 2026: Wir prüfen die besten Deals

Top 10: Der beste Ventilator im Test

Top 8: Die beste Kompressor-Kühlbox im Test

Minimus stellt tausende CVE-freie Container-Images kostenlos bereit

2026-06-24T10:46:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Entwickler erhalten uneingeschränkten Zugriff auf tausende nahezu CVE-freie Images aus dem Minimus-Katalog distroloser, gehärteter Container-Images.

(Bild: cybrain / Shutterstock.com)

24.06.2026, 12:46 Uhr

Lesezeit: 4 Min.

Developer

Von

Matthias Parbel

Das auf Containersicherheit spezialisierte Unternehmen Minimus stellt den kompletten Katalog seiner gehärteten Container-Images ohne Registrierung für alle Softwareentwickler frei zur Verfügung. Im Rahmen der Community Edition liegen tausende distrolose Images bereit, die nahezu frei von bekannten CVEs sein sollen – darunter Images für Anwendungen wie nginx, Python, PostgreSQL, Elasticsearch, RabbitMQ, Argo CD und cert-manager. Für den Zugriff auf die Image-Gallery-Bibliothek sind laut Minimus weder ein Login noch Budgetfreigaben erforderlich, auch auf Download-Limits verzichtet der Anbieter.

Wie Minimus in seiner Ankündigung erläutert, reagiert das Unternehmen damit auf eine dramatisch wachsende Zahl entdeckter Schwachstellen. CEO Ben Bernstein verweist in diesem Zusammenhang auf KI-Modelle und -Programme von Anthropic: „Modelle wie Mythos und (das Projekt) Glasswing haben den Umfang und das Tempo der Schwachstellenentdeckung erheblich gesteigert, während die Fähigkeiten zur Behebung nicht Schritt halten“, so Bernstein. Tatsächlich belegen Analysen, etwa von VulnCheck, massiv gestiegene CVE-Volumina unter anderem bei GitHub-Projekten, teils getrieben durch KI-gestützte Discovery. Für DevSecOps-Teams bedeutet das: Klassische „Alles patchen“-Strategien stoßen an ihre Grenzen. Stattdessen rücken risikobasierte Priorisierung – etwa entlang der CISA-KEV-Liste oder bekannter Exploits – und der Einsatz minimaler Baselines in den Vordergrund.

Die auf Developer Experience (DX) und Platform Engineering spezialisierte CLC-Konferenz findet vom 11. bis 12. November 2026 in Mannheim statt. Ein besonderer Fokus liegt darauf, wie Agentic AI die Arbeit von Developern, Software-Architekten, DevOps- und Platform Engineers verändert und wie sich digitale Souveränität nachhaltig erreichen lässt.

Ab sofort sind Tickets zum Frühbucherpreis verfügbar.

Distrolos, gehärtet und als Drop-in-Ersatz konzipiert

Die Minimus-Images werden laut Anbieter kontinuierlich aus Upstream-Quellcode auf einer distrolosen Basis neu gebaut, gescannt und gehärtet. Sie enthalten ausschließlich die Komponenten, die eine Anwendung zur Laufzeit tatsächlich benötigt – Shells, Paketmanager und Debug-Tools fehlen bewusst. Minimus gibt an, dass die Images oft bis zu 95 Prozent kleiner als herkömmliche Standard-Images seien und als API-kompatible Drop-in-Replacements dienen sollen. Im einfachsten Fall genüge die Änderung einer einzigen Zeile im Dockerfile.

Wie praxistauglich distrolose Ansätze in produktiven Kubernetes-Umgebungen sind, beleuchtet ein mehrteiliger Artikel zu minimalen und sicheren Docker-Images sowie zum Selbstbauen sicherer Container-Images. Der Kernbefund: Funktional können solche Images klassische „Full-Fat“-Varianten in vielen Fällen ersetzen, sofern Debugging-Workflows auf Kubernetes-Bordmittel wie Ephemeral Containers umgestellt werden. Gerade für regulierte Branchen in Deutschland – etwa Finanzwesen, Gesundheitssektor oder KRITIS-Betreiber – kann der Wegfall unnötiger Angriffsfläche ein erheblicher Vorteil sein.

Videos by heise

Compliance-Fokus: FIPS, CIS, NIST und STIG

Minimus wirbt damit, dass sämtliche Images die Anforderungen nach FIPS, CIS, NIST und STIG erfüllen. FIPS zielt dabei auf die Validierung kryptografischer Module, NIST liefert mit Publikationen wie SP 800-190 konkrete Leitlinien für Container-Sicherheit, CIS stellt Härtungs-Benchmarks bereit und STIG definiert detaillierte Konfigurationsvorgaben des US-Verteidigungsministeriums. Für Compliance- und Datenschutzbeauftragte in der DACH-Region vereinfacht das potenziell Audits erheblich – insbesondere wenn Nachweise sicherer Konfigurationen, SBOM-Dokumentation und Provenance-Attestierungen gefordert sind, wie sie etwa ISO 27001 oder BSI-Grundschutz verlangen. Minimus stellt nach eigenen Angaben signierte SBOMs und kryptografische Signaturen für jedes Build bereit und nennt als Ziel SLSA Level 3, was reproduzierbare Builds mit gesicherten CI/CD-Pipelines impliziert.

Dass gehärtete Container-Images zunehmend zum wettbewerbsentscheidenden Thema werden, zeigte bereits zum vergangenen Jahreswechsel die Entscheidung von Docker Inc., seine Hardened Images kostenlos anzubieten. Gleichzeitig verdeutlichen Befunde wie die Entdeckung von geheimen Zugangsdaten in über 10.000 Docker-Hub-Images, wie groß der Handlungsbedarf bei Container-Sicherheit bleibt.

Enterprise Edition mit SLAs und KI-Integrationen

Neben der kostenlosen Community Edition bietet Minimus eine Enterprise Edition mit vertraglich zugesicherten Remediation-SLAs: 24 Stunden für kritische und hohe CVEs auf der CISA-KEV-Liste, 48 Stunden für alle übrigen kritischen und hohen Schwachstellen. Enterprise-Kunden erhalten zudem einen Image Creator für kundenspezifische Images, Enterprise-SSO, rollenbasierte Zugriffskontrolle sowie die Möglichkeit, Images in bestehende Registries – auch in Air-Gap-Umgebungen – zu synchronisieren.

Entwicklerinnen und Entwicklern stellt Minimus darüber hinaus das CLI-Tool minicli bereit, das als „agent-ready“ beschrieben wird. Es soll sich in Workflows mit KI-Assistenten wie Claude, Codex oder Cursor einbinden lassen, um Migrationen auf gehärtete Images zu automatisieren. Minimus wurde 2022 von Ben Bernstein, Dima Stopel und John Morello gegründet – alle drei waren bei Twistlock tätig; John Morello war zudem Mitautor des NIST-Dokuments SP 800-190 zur Container-Sicherheit.

(map)

Prime Day 2026: Wir prüfen die besten Deals

Top 10: Der beste Ventilator im Test

Top 8: Die beste Kompressor-Kühlbox im Test

Serverless mit Pausenfunktion: AWS stellt Lambda MicroVMs vor

2026-06-24T10:23:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

AWS führt Lambda MicroVMs ein, die VM-Isolation mit schnellen Startzeiten und Zustandserhaltung für serverlose Workloads verbinden.

(Bild: Michael Vi / Shutterstock.com)

24.06.2026, 12:23 Uhr

Lesezeit: 2 Min.

iX Magazin

Von

Moritz Förster

AWS hat mit Lambda MicroVMs eine neue Laufzeitumgebung für serverlose Workloads vorgestellt. Die MicroVMs sollen VM-Level-Isolation mit sehr schnellen Start- und Fortsetzungszeiten verbinden und den Zustand einer laufenden Session erhalten. Amazon zielt damit auf Anwendungen, die Nutzer- oder KI-generierten Code ausführen und für jeden Nutzer oder Job eine eigene, abgeschottete Umgebung brauchen. Bisher mussten Entwickler laut AWS zwischen starker Isolation, schnellen Startzeiten und der Möglichkeit wählen, den Zustand einer Sitzung zu speichern.

Start aus Dockerfile, Zugriff per HTTPS

Zum Einstieg erzeugen Entwickler ein MicroVM-Image aus einem Dockerfile. Auf Basis dieses Images lassen sich MicroVMs starten. Jede MicroVM erhält eine dedizierte HTTPS-URL. Die Umgebung unterstützt laut Ankündigung HTTP/2, gRPC und WebSockets. Zudem gibt AWS an, dass sich die Ausführung für bis zu acht Stunden anhalten und später fortsetzen lässt.

Technisch basiert Lambda MicroVMs auf Firecracker, der Virtualisierungstechnik, die auch AWS Lambda selbst nutzt. Firecracker bildet aktuell die Grundlage für mehr als 15 Billionen Lambda-Aufrufe pro Monat, so Amazon.

Videos by heise

Verfügbarkeit und Preis

Lambda MicroVMs ist laut AWS ab sofort in fünf Regionen verfügbar: US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Tokyo) und Europe (Ireland). Die Steuerung ist über die AWS Lambda Console, CloudFormation, das Cloud Development Kit und das Agent Toolkit for AWS möglich.

Beim Preis berechnet AWS die Baseline-Compute-Ressourcen, solange die MicroVM läuft. Zusätzliche Ressourcen fallen nur für die Zeit an, in der eine Workload über dieses Baseline-Niveau hinausgeht.

(fo)

Prime Day 2026: Wir prüfen die besten Deals

Top 10: Der beste Ventilator im Test

Top 8: Die beste Kompressor-Kühlbox im Test

Claude mischt sich ein: Der neue proaktive KI-Kollege für Slack

2026-06-24T08:59:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Mit Claude Tag macht Anthropic sein KI-Modell zum aktiven Teamkollegen in Slack. Er lernt aus dem Kanalverlauf und erledigt Aufgaben selbstständig.

(Bild: Anthropic)

24.06.2026, 10:59 Uhr

Lesezeit: 3 Min.

iX Magazin

Von

Moritz Förster

Anthropic hat mit Claude Tag eine neue Integration für sein KI-Modell Claude vorgestellt. Der Dienst startet zunächst in Slack und soll dort als Teammitglied in ausgewählten Kanälen arbeiten. Nutzer können @Claude in einem Channel ansprechen, Aufgaben anstoßen und das Modell mit freigegebenen Tools, Daten und auch Codebasen verbinden. Claude soll dabei den Kontext aus dem Kanal aufbauen, relevante Informationen behalten und Aufgaben auch über längere Zeiträume verfolgen. Die Beta startet ab sofort für Claude-Enterprise- und Team-Kunden.

Claude als gemeinsamer Kanal-Agent

Claude Tag unterscheidet sich nach Angaben von Anthropic deutlich von einem klassischen Chatbot. In einem Slack-Channel arbeitet nicht jeder mit einer eigenen Instanz, sondern alle Beteiligten greifen auf dieselbe Claude-Instanz zu. Wer später in die Unterhaltung einsteigt, kann an frühere Arbeit anknüpfen, ohne den Kontext erneut erklären zu müssen. Das System zerlegt Aufgaben in Schritte und antwortet nach Abschluss in einem Slack-Thread. Anthropic positioniert Claude Tag offiziell als stärker teamorientierte Weiterentwicklung von Claude Code.

Ein zentrales Merkmal ist die Fähigkeit, über den aktuellen Chat hinaus zu lernen. Der Agent speichert Informationen aus den Kanälen, in denen er aktiv ist. Mit entsprechender Berechtigung kann das Modell zudem Wissen aus anderen Slack-Kanälen und Datenquellen verknüpfen, wobei private Kanäle ausgenommen bleiben. Dieses übergeordnete, kanalübergreifende Wissen soll dem Modell die nötige Kontexttiefe verleihen, um komplexe Aufgaben konsistent zu bearbeiten.

Proaktiv statt nur reaktiv

Neu ist außerdem ein optionaler proaktiver Modus. Ist dieser aktiviert, hebt Claude relevante Informationen aus verbundenen Kanälen und Tools hervor und weist auf ins Stocken geratene Aufgaben hin. Zudem arbeitet das System asynchron: Nach dem Anstoßen einer Aufgabe kann der Agent diese über Stunden oder Tage hinweg autonom weiterverfolgen, während der Nutzer parallel an anderen Themen arbeitet. Aufgaben lassen sich so effizient delegieren.

Für den Einsatz in Organisationen können Administratoren genau steuern, auf welche Tools und Daten das Modell in welchen Kanälen zugreifen darf. Claude wird dabei als separate Identitäten verwaltet: Ein für den Vertrieb eingerichtetes Modell erhält keinen Zugriff auf Engineering-Daten und umgekehrt. Zur Kostenkontrolle und Nachvollziehbarkeit lassen sich Obergrenzen für den Token-Verbrauch auf Organisations- und Kanalebene festlegen. Zudem protokolliert das System alle Aktivitäten samt Anfragesteller.

Videos by heise

Start in Slack

Claude Tag ersetzt die bisherige Claude-in-Slack-App. Enterprise- und Team-Kunden, die auf das neue System umsteigen möchten, müssen ihren Workspace neu verbinden, die Zugriffsberechtigungen definieren und ein monatliches Budget festlegen. Für die Migration haben Administratoren 30 Tage Zeit, um sich anzumelden. Anthropic empfiehlt, den Testlauf zunächst in einem privaten Channel zu starten. Berechtigte Enterprise- und Team-Organisationen erhalten zudem ein Einführungsguthaben, damit das gesamte Unternehmen Claude Tag ausprobieren kann.

Das System nutzt zum Start Opus 4.8. Anthropic plant, Claude Tag künftig auch außerhalb von Slack anzubieten. Der Anbieter selbst setzt Claude Tag bereits intern ein, etwa für die Codeerstellung, die Auswertung von Produktmetriken oder die Analyse von Support-Tickets. Nach Unternehmensangaben entstehen 65 Prozent des Codes im Produktteam bereits durch die interne Version von Claude Tag.

Lesen Sie auch

Anthropic beschuldigt Alibaba des KI-Modell-Diebstahls

Anthropic darf für die Nutzung von Claude künftig einen Ausweis verlangen

Geheimdienstbündnis warnt vor KI-gestützten Cyberangriffen

Kommentar KI – es wird nicht ohne gehen

EU-Parlament stimmt zu: Verbot für sexualisierte Deepfake-KI

Prime Day 2026: Wir prüfen die besten Deals

Top 10: Der beste Ventilator im Test

Top 8: Die beste Kompressor-Kühlbox im Test

Softwarebranche muss Geschäftsmodelle umbauen

2026-06-24T08:20:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Der Bitkom prognostiziert einen tiefgreifenden Umbau der Softwarebranche. KI-Agenten verschieben den Fokus von Arbeitszeit zu messbaren Ergebnissen.

(Bild: ZenitX / Shutterstock.com)

24.06.2026, 10:20 Uhr

Lesezeit: 4 Min.

iX Magazin

Von

Moritz Förster

Die Softwarebranche muss sich nach Einschätzung des Bitkom auf einen tiefgreifenden Umbau ihrer Geschäftsmodelle einstellen. Künftig werde Software weniger nach Arbeitszeit oder pauschalen Lizenzen verkauft, sondern stärker nach messbaren Ergebnissen abgerechnet, heißt es in der Studie „Softwarewelt 2036“. Auslöser ist vor allem der Einsatz von KI-Agenten, die nicht mehr nur als Werkzeug dienen, sondern selbst Aufgaben übernehmen und Prozesse ausführen.

Der Verband verweist darauf, dass sich damit die Logik vieler bestehender Erlösmodelle verschiebt. Wenn ein KI-Agent die Arbeit mehrerer Menschen erledigen kann, lässt sich Aufwand nach Köpfen oder Stunden immer schwerer rechtfertigen. Unter Druck geraten laut Bitkom vor allem Body Leasing, stundenbasierte IT-Dienstleistungen, FTE-Outsourcing und Offshore-Bodyshopping. Auch klassische Entwicklungs- und Support-Pyramiden, deren Wert stark an menschlicher Arbeitsmenge hängt, verlieren demnach an Tragfähigkeit.

Messbare Ergebnisse statt Arbeitszeit

An die Stelle von Zeit- und Lizenzmodellen treten nach Einschätzung des Bitkom zunehmend ergebnisbezogene Abrechnungen. Kunden zahlen dann nicht mehr primär für Softwarezugang oder Personalstunden, sondern für konkrete Resultate wie gelöste Tickets, behobene Sicherheitslücken, bereitgestellte Features oder bestandene Compliance-Prüfungen. Der Bitkom erwartet, dass Outcome- und Value-based Pricing vor allem im B2B-Geschäft an Bedeutung gewinnt.

Damit verändert sich auch die Rolle von Software. Sie werde künftig weniger als einzelnes Werkzeug verstanden, das Menschen bedienen, sondern als Instanz, die KI-Agenten steuert, Prozesse orchestriert und Ergebnisse liefert. Der Bitkom beschreibt dies als Entwicklung hin zu „Agentic Systems“, in denen KI-Agenten Aufgabenketten abarbeiten. Entscheidend werde die Fähigkeit, Geschäftsergebnisse in solche agentenfähigen Architekturen zu übersetzen.

Mit dieser Entwicklung verändern sich auch die Anforderungen an Beschäftigte. Manuelles Coding, Standardlogik und triviale Tests verlieren an Gewicht. Wichtiger werden Architektur, Review, Evaluation, Orchestrierung und die Bewertung von KI-Ergebnissen. Hinzu kommen Datenkompetenz, Urteilsfähigkeit, Verantwortung und die Fähigkeit, zwischen Fachabteilungen, IT und Regulierung zu vermitteln.

Domänenwissen und Vertrauen als Wettbewerbsvorteil

Für Anbieter sieht der Bitkom vor allem dort Chancen, wo technologische Kompetenz mit Branchenwissen zusammenkommt. Reines Coding werde weniger zum Differenzierungsmerkmal, heißt es in der Studie. Wichtiger würden Domänenwissen, Prozessverständnis und die Fähigkeit, fachliche Anforderungen in KI-gestützte Systeme zu übersetzen. Der Verband spricht in diesem Zusammenhang von Übersetzern zwischen Business, IT, Daten, Regulierung und Menschen.

Gleichzeitig gewinnt Vertrauen an Bedeutung. Anbieter müssen Nachvollziehbarkeit, Auditierbarkeit und europäische Datenhaltung von Anfang an mitdenken, meint der Bitkom. Das könne gerade in regulierten Branchen zu einem Wettbewerbsvorteil werden. Compliance und Datensouveränität würden dann nicht nur als Pflicht, sondern auch als Verkaufsargument wirken.

Videos by heise

Plattformen, Daten und Handlungsfelder

Parallel dazu verschiebt sich der Markt aus Sicht des Bitkom weg von isolierten Einzellösungen hin zu Plattformen und Ökosystemen. Einzeltools ohne Anbindung an größere Prozess- und Datenstrukturen hätten künftig schlechtere Karten. Daten sind dabei die Grundlage, um Wirkung nachzuweisen, Systeme zu verbessern und neue Geschäftsmodelle zu entwickeln. Entscheidend sei nicht nur der Besitz von Daten, sondern ihre Qualität, ihr Kontext, ihre Governance und ihre verantwortungsvolle Nutzung.

Für Unternehmen empfiehlt der Bitkom deshalb, Datenbasis und Systemlandschaften zu bereinigen, KI von Pilotprojekten systematisch zu skalieren und eine einheitliche Daten- und Agentenplattform aufzubauen. Rollenprofile und Karrierepfade müssten an die neuen Anforderungen angepasst werden. Fachkräfte mit Domänenwissen und KI-Orchestrierung seien besonders gefragt.

Auch die Politik muss reagieren, so der Bitkom. Der Verband fordert eine modernisierte Aus- und Weiterbildung, breiter angelegte KI- und Tech-Kompetenzen sowie eine Regulierung, die stärker auf Ergebnisse als auf einzelne Werkzeuge zielt. Gesetze und Vorgaben sollten demnach schneller überprüft und an technologische Entwicklungen angepasst werden. Zudem plädiert der Bitkom für Experimentierräume, schnellere Verfahren und den Ausbau europäischer KI- und Compute-Infrastruktur.

Die Studie „Softwarewelt 2036“ basiert auf Interviews mit Führungskräften und Experten aus der Softwarebranche und angrenzenden Bereichen. Sie ist nicht repräsentativ, soll aber zentrale Muster und Zukunftsbilder sichtbar machen. Für Unternehmen und Politik, so die Schlussfolgerung des Bitkom, bleibe nicht viel Zeit, um sich auf die neuen Bedingungen einzustellen.

Lesen Sie auch

Interview zur „SaaSpocalypse“: Das Zeitalter der Wegwerfsoftware naht

Kommentar: Das Ende der SaaS-Gelddruckmaschine

Prime Day 2026: Wir prüfen die besten Deals

Top 10: Der beste Ventilator im Test

Top 8: Die beste Kompressor-Kühlbox im Test

Warum das Healthtech-Unternehmen Heidi auf den deutschen Markt setzt

2026-06-24T07:49:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Das australische Unternehmen Heidi baut weltweit seine Präsenz aus. Im Interview erklärt Heidis Chief Medical Officer, warum Deutschland so besonders ist.

(Bild: LALAKA / Shutterstock.com)

24.06.2026, 09:49 Uhr

Lesezeit: 13 Min.

Von

Marie-Claire Koch

Administrative Aufgaben gehören weiterhin zu den größten Herausforderungen im deutschen Gesundheitswesen. Eine aktuelle Umfrage des Meinungsforschungsinstituts Civey im Auftrag von Heidi zeigt, dass eine große Mehrheit der Gesundheitsfachkräfte Verwaltungsarbeit als Belastung für die Patientenversorgung empfindet. Rund ein Drittel der Befragten gibt zudem an, mehr als 40 Prozent ihrer Arbeitszeit für Dokumentation und andere administrative Tätigkeiten aufzuwenden.

Gleichzeitig ist die Haltung gegenüber künstlicher Intelligenz (KI) weiterhin gespalten. Der Umfrage zufolge sehen Gesundheitsfachkräfte KI im Patientenkontakt nahezu gleich häufig als Chance, als Risiko oder als beides zugleich. Viele Befragte nannten jedoch Dokumentation, Verwaltungsaufgaben und die Strukturierung medizinischer Informationen als Bereiche, in denen KI sinnvolle Unterstützung leisten könnte.

Lesen Sie auch

Nach OpenAI und Microsoft: Perplexity stellt Gesundheits-KI vor

Microsofts KI-Assistent Dragon Copilot in deutschen Kliniken verfügbar

Digital Health: Recare entwickelt KI-Agenten für Klinik-Verwaltung

Ende vom E-Rezept-Dienst PrescribeIT: Kanada plant Wechsel zu offenem System

Corti AI bringt „Symphony“ für automatisierte medizinische Kodierung

Prime Day 2026: Wir prüfen die besten Deals

Top 10: Der beste Ventilator im Test

Top 8: Die beste Kompressor-Kühlbox im Test

Webentwicklung: Vite 8.1 soll große Anwendungen beschleunigen

2026-06-24T07:47:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Ein experimenteller neuer Modus des Frontend-Build-Tools soll die Performance großer Anwendungen verbessern.

(Bild: H_Ko / Shutterstock.com)

24.06.2026, 09:47 Uhr

Lesezeit: 2 Min.

Developer

Von

Maika Möbus

VoidZero Inc. hat Vite 8.1 veröffentlicht. Das neue Release bringt den experimentellen Bundled Dev Mode, der Performancesteigerungen zum Ziel hat. Darüber hinaus kann das Frontend-Build-Tool Vite nun mit dem Proposal für die WebAssembly/ECMAScript-Module-Integration umgehen und nähert sich der standardmäßigen Nutzung von Lightning CSS.

Bundled Dev Mode

Bisher als Full Bundle Mode bezeichnet, bringt Vite 8.1 experimentellen Support für den Bundled Dev Mode. Dieser Modus soll dazu dienen, die Performance sehr großer Anwendungen mit vielen Modulen zu verbessern.

So hat VoidZero einen Test mit einer App durchgeführt, die 10.000 React-Komponenten geladen hat. Im Vergleich mit dem nicht gebundelten Dev-Server habe der Bundled Dev Mode eine 15-mal schnellere Start-up-Zeit und 10-mal schnellere vollständige Page Reloads verzeichnet – mit unmittelbarem Hot Module Replacement (HMR), unabhängig von der Anwendungsgröße.

Wie das Entwicklungsteam im Blogeintrag zur Vite-8.1-Ankündigung weiter ausführt, sei der Ansatz des Unbundled Dev Server einer der Gründe für Vites Schnelligkeit und Beliebtheit. Bei großen Anwendungen könne er jedoch die Performance beeinträchtigen, weshalb nun die Arbeit am Bundled Dev Mode begonnen hat. Auf GitHub können Interessierte die Roadmap des neuen Features einsehen.

Updates für Wasm und Lightning CSS

Zu den weiteren Neuerungen zählt der Support für das WebAssembly/ECMAScript Module Integration Proposal. Mit diesem Proposal wird WebAssembly wie JavaScript mit einem import-Statement oder per <script type=module>-Tag geladen. Derzeit befindet sich der Vorschlag in Phase 3 des WebAssembly-Prozesses, das heißt, der Implementierungsphase.

In Zusammenarbeit mit dem Team hinter Lightning CSS, einem in Rust geschriebenen CSS-Tool, hat dieses zwei neue Features erhalten. Es könnte schon in der nächsten Vite-Hauptversion das bisher zum CSS Preprocessing genutzte PostCSS ablösen und zum Standard werden, gibt VoidZero einen Ausblick.

VoidZero: Teil von Cloudflare

Erst kürzlich machte VoidZero von sich reden, da das Unternehmen in diesem Monat von Cloudflare gekauft wurde. Im Januar 2026 hatte Cloudflare bereits die Astro Technology Company übernommen, die hinter dem Open-Source-Webframework Astro steht. Sowohl dieses als auch die Open-Source-Technologien von VoidZero – Vite, Vitest, Rolldown, Oxc und Vite+ – sollen laut Angaben von Cloudflare quelloffen bleiben.

(mai)

Prime Day 2026: Wir prüfen die besten Deals

Top 10: Der beste Ventilator im Test

Top 8: Die beste Kompressor-Kühlbox im Test

Ergebnis ohne Erkenntnis: Was uns AlphaGo über GenAI lehrt

2026-06-24T07:00:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Generative KI liefert Ergebnisse, die niemand mehr nachvollzieht. AlphaGo zeigte das Muster 2016. Wann genügt Verlässlichkeit und wann braucht es Verstehen?

(Bild: Manuel Masiero / KI / iX)

24.06.2026, 09:00 Uhr

Lesezeit: 14 Min.

Developer

Von

Golo Roden

Vielleicht kennen Sie das aus der Arbeit mit generativer KI: Etwas funktioniert, und Sie wissen nicht, warum. Ein generiertes Stück Code läuft durch, eine vorgeschlagene Lösung trägt, eine Diagnose stimmt. Das Ergebnis liegt überprüfbar und brauchbar vor Ihnen, nur den Weg dorthin könnten Sie nicht rekonstruieren, nicht einmal grob nacherzählen.

Golo Roden ist Gründer und CTO von the native web GmbH. Er beschäftigt sich mit der Konzeption und Entwicklung von Web- und Cloud-Anwendungen sowie -APIs, mit einem Schwerpunkt auf Event-getriebenen und Service-basierten verteilten Architekturen. Sein Leitsatz lautet, dass Softwareentwicklung kein Selbstzweck ist, sondern immer einer zugrundeliegenden Fachlichkeit folgen muss.

Mir selbst erschien das lange als Nebensächlichkeit, als bloßer Preis der Bequemlichkeit. Inzwischen halte ich es für die eigentlich interessante Frage. Denn was sich hier verschiebt, ist nicht nur die Geschwindigkeit, mit der Lösungen entstehen, sondern das Verhältnis zwischen einem Ergebnis und dem Verständnis, das wir früher mit ihm zusammen erworben haben. Es lohnt sich zu fragen, ob dieser Verlust ein Problem ist – und falls ja, wo genau.

Das funktionierende Ergebnis ohne den Weg dorthin

Wer ein Problem selbst löst, bekommt traditionell zwei Dinge auf einmal: die Lösung und das Verständnis, wie sie zustande kommt. Von beiden ist das Verständnis der haltbarere Teil. Die konkrete Lösung gilt für genau diesen einen Fall, das Verständnis trägt zum nächsten, leicht anderen Fall.

Mit generativer KI fallen diese beiden Dinge auseinander. Ich erhalte die Lösung, ohne das Verständnis gleich mitzubekommen. Ein kniffliger regulärer Ausdruck, eine Build-Konfiguration, die plötzlich durchläuft, ein Fehler, der durch einen akzeptierten Vorschlag verschwindet: Das Resultat steht, der Weg bleibt im Dunkeln.

Videos by heise

Das ist nicht dasselbe wie der Gebrauch einer Bibliothek oder das Vertrauen in einen Compiler. Dort hat jemand verstanden, was geschieht, und die Abstraktion ist dokumentiert, stabil und nachlesbar. Bei einem generierten Ergebnis ist die Herleitung selbst im Prinzip undurchsichtig, und sie fällt bei jeder Anfrage ein wenig anders aus.

Der entscheidende Unterschied liegt in der Übertragbarkeit. Ein Ergebnis ist ein Einzelstück, Verständnis ist wiederverwendbar. Wo mir das Verständnis fehlt, fehlt mir die Fähigkeit, den nächsten Fall aus eigener Kraft zu lösen. Ich bleibe auf das Werkzeug angewiesen, nicht weil es bequemer ist, sondern weil ich es selbst nicht mehr könnte.

Das Tückische ist, dass sich das Übernehmen eines Ergebnisses anfühlt wie Lernen. Schließlich habe ich etwas geschafft, das ich vorher nicht konnte. Aber der Eindruck täuscht: Was zugenommen hat, ist die Zahl der erledigten Aufgaben, nicht die Tiefe dessen, was ich selbst beherrsche. Geliehene Kompetenz fühlt sich an wie eigene, solange das Werkzeug zur Hand ist.

Lange galt die Mühe, ein Problem zu durchdringen, als lästiger Umweg auf dem Weg zur Lösung. Tatsächlich war sie der Weg, auf dem das Verständnis überhaupt erst entstand. Wer sich durch einen Fehler gekämpft hat, kennt danach nicht nur die Lösung, sondern das Terrain darum herum: die Sackgassen, die falschen Fährten, die Stellen, an denen es noch einmal kippen könnte. Genau dieses Nebenwissen entfällt, wenn die fertige Lösung geliefert wird.

Diese Reibung war also kein Mangel, sondern ein Teil des Ertrags. Sie zu beseitigen, klingt nach Fortschritt, kostet aber etwas, das auf der Rechnung zunächst nicht auftaucht.

Ein Zug, den niemand erklären kann

Im März 2016 schlug AlphaGo den Go-Profispieler Lee Sedol in einem Match mit 4:1. Berühmt wurde nicht das Ergebnis, sondern ein einzelner Zug: der 37. Zug in der zweiten Partie, in die Go-Geschichte als „Move 37“ eingegangen. Kein Mensch hätte ihn gespielt; die Wahrscheinlichkeit, dass ein menschlicher Profi ihn wählt, lag bei etwa eins zu zehntausend. Er war fremd, und er war brillant.

Den Gegenpol lieferte Lee Sedol selbst. In der vierten Partie spielte er den 78. Zug, in Korea als „göttlicher Zug“ gefeiert, ebenso unwahrscheinlich und sein einziger Sieg gegen die Maschine. Der Unterschied liegt nicht in der Genialität, sondern dahinter: Hinter Move 78 steht eine Idee, die ein Mensch erklären kann, ein geschickter taktischer Zug, im Go Tesuji genannt. Hinter Move 37 steht eine Wahrscheinlichkeitsverteilung über Millionen selbst gespielter Partien.

Profispielerinnen und -spieler haben AlphaGo studiert und einzelne Züge übernommen; die frühe Invasion am 3-3-Punkt etwa wurde populär, nachdem die Maschine sie bevorzugte. AlphaGo Zero lernte 2017 ganz ohne menschliche Partien, allein aus dem Spiel gegen sich selbst, und übertraf die ursprüngliche Version deutlich.

AlphaGo beruht auf neuronalen Netzen, und alles, was es im Training gelernt hat, steckt in deren Gewichten, den vielen Zahlenwerten, die ein solches Netz ausmachen. Dort liegt das Wissen, das die Maschine überlegen macht, und nirgends sonst. Es liegt in keinem Lehrbuch, in keinem Kommentar, in keinem Kopf. Man kann der Maschine beim Spielen zusehen und die Ergebnisse bestaunen, aber die zugrunde liegende Strategie bleibt eingeschlossen in einer Form, die sich nicht in menschliche Begriffe übersetzen lässt.

Bezeichnend ist, dass nicht einmal die Fachleute hinter AlphaGo den Zug im üblichen Sinn erklären konnten. Sie konnten beschreiben, wie das System trainiert wurde, und sie konnten zeigen, dass es Move 37 einen hohen Wert beimaß. Warum gerade dieser Zug der richtige war, ließ sich daraus nicht ableiten. Die Erklärung endete bei der Mechanik des Lernens, nicht beim Sinn des Ergebnisses.

Doch einen Zug zu übernehmen heißt nicht, ihn zu verstehen. Man imitiert, was sich als stark erweist, ohne das Warum rekonstruieren zu können. Die Maschine spielt übermenschliches Go und hinterlässt keine lehrbare Theorie davon. Genau das ist die Struktur, der ich bei generativer KI wieder begegne: ein Ergebnis auf hohem Niveau, das sich kopieren, aber nicht als Einsicht erben lässt.

Lässt sich die Blackbox wirklich öffnen?

Die naheliegende Hoffnung lautet, man müsse die Modelle eben erklärbar machen. Explainable AI, erklärbare KI, ist ein ernstzunehmendes Forschungsfeld. Aber die gängigen Verfahren erklären im Nachhinein: Sie zeigen, welche Eingaben besonders ins Gewicht fielen oder welche Teile des Netzes ansprachen. Das ergibt plausible Geschichten und Näherungen, aber keine getreue Auskunft darüber, was die Gewichte tatsächlich berechnen.

Schlimmer noch: Eine plausible Erklärung kann in die Irre führen. Sie klingt überzeugend, deckt sich mit unseren Erwartungen und suggeriert ein Verständnis, das gar nicht trägt. Eine Erklärung, die nicht treu wiedergibt, was im Modell geschieht, ist im Zweifel gefährlicher als gar keine, weil sie ein falsches Sicherheitsgefühl erzeugt.

Für die tägliche Arbeit folgt daraus wenig Tröstliches. Eine Hervorhebung, welche Zeilen ein Assistent als relevant betrachtet hat, sagt nichts darüber, ob der erzeugte Code korrekt ist. Die Erklärung beschreibt bestenfalls, woran das Modell sich orientiert hat, nicht, ob das Ergebnis stimmt. Beides zu verwechseln, ist der bequemste und zugleich gefährlichste Fehler im Umgang mit diesen Werkzeugen.

Ein jüngerer Zweig, die mechanistische Interpretierbarkeit, versucht, die innere Rechnung eines Modells regelrecht zurückzuentwickeln. Das ist vielversprechend, steckt aber in den Anfängen. Bei Modellen mit Milliarden von Parametern ist man von einer vollständigen Erklärung weit entfernt.

Verständlich von Grund auf sind nur einfache Modelle. Ein Entscheidungsbaum ist eine lesbare Folge von Wenn-dann-Verzweigungen, die man Schritt für Schritt nachvollziehen kann. Sobald man jedoch die Genauigkeit steigern will und zu Ensembles übergeht, zu Random Forests oder Gradient Boosting, ist die Durchschaubarkeit wieder dahin. Die Informatikerin Cynthia Rudin hat daraus die Forderung abgeleitet, bei folgenreichen Entscheidungen lieber von vornherein interpretierbare Modelle einzusetzen, statt Blackboxes nachträglich zu erklären.

Dahinter steht ein unbequemer Zusammenhang: Die leistungsfähigsten Modelle sind zugleich die am wenigsten durchschaubaren. Erklärbarkeit und Leistungsfähigkeit ziehen in entgegengesetzte Richtungen. Diese Undurchschaubarkeit ist dabei von anderer Art als die prinzipiellen Grenzen, die ich in einem früheren Beitrag beschrieben habe: Dort geht es darum, was Sprachmodelle grundsätzlich nicht leisten können; hier darum, wie wenig wir verstehen, wie sie das leisten, was sie leisten.

Verständnis, das vielleicht nirgends mehr existiert

Nun könnte man einwenden, dass wir uns längst auf vieles verlassen, das wir nicht verstehen. Ich vertraue dem Compiler, der TLS-Bibliothek, den Bremsen meines Autos, ohne ihre Interna zu durchdringen. Das stimmt, und es ist auch gut so. Niemand kann alles selbst verstehen.

Doch es gibt einen Unterschied. Bei diesen Beispielen existiert das Verständnis irgendwo. Es sitzt in den Entwicklerinnen und Entwicklern des Compilers, in der Spezifikation des Protokolls, in der Konstruktionszeichnung der Bremse. Ich kann der Kette im Prinzip folgen, bis ich bei jemandem ankomme, der erklären kann, warum die Sache funktioniert.

Es ist der Unterschied zwischen dem Wissen, dass etwas funktioniert, und dem Wissen, warum es funktioniert. Das erste genügt, um ein Ergebnis zu benutzen. Das zweite ist nötig, um es zu verändern, auf neue Fälle zu übertragen oder im Streitfall dafür einzustehen. Über lange Zeit lagen beide oft eng beieinander, nun lassen sie sich entkoppeln.

Wissenschaft und Technik haben über Jahrhunderte funktioniert, weil Wissen eine übertragbare Form annahm: Sätze, Beweise, Konstruktionspläne, die andere prüfen, lehren und weiterentwickeln konnten. Das Wissen eines großen Modells liegt dagegen in Milliarden von Zahlen, die für sich genommen nichts erklären. Es ist Wissen, das wirkt, ohne sich mitteilen zu lassen. Damit fehlt ihm genau die Eigenschaft, die menschliches Wissen anschlussfähig macht.

Bei der Ausgabe eines großen Sprachmodells kann die Kette ins Leere laufen. Niemand hat Move 37 entworfen, niemand kann auf die Überlegung dahinter zeigen, weil es keine gibt. Das Verständnis liegt nicht woanders, es existiert womöglich gar nicht, in niemandem. Das ist neu, und es ist mehr als ein akademischer Unterschied.

Sichtbar wird das überall dort, wo jemand für ein Ergebnis geradestehen muss. Eine Ärztin, die einer Diagnose folgt, eine Entwicklerin, die eine generierte Komponente ausliefert, ein Team, das ein System betreibt: Sie alle übernehmen Verantwortung für etwas, dessen Zustandekommen sie nicht vollständig durchschauen. Solange alles gutgeht, fällt das nicht auf. Es fällt auf, sobald etwas schiefgeht und die Frage nach dem Warum sich nicht länger aufschieben lässt.

Für Software wird dieser Unterschied konkret. Software ist kein einmaliges Ergebnis, das man entgegennimmt und beiseitelegt. Sie muss gewartet, erweitert, im Fehlerfall durchdrungen und über Jahre verantwortet werden. Dass der eigentliche Engpass der Entwicklung nie das Schreiben von Code war, sondern das Verstehen des Problems, habe ich an anderer Stelle ausgeführt. Ein Ergebnis, das niemand versteht, ist vor diesem Hintergrund keine Ersparnis, sondern eine Hypothek auf jede künftige Änderung.

Verlässlichkeit ersetzt kein Verstehen

Ist der Verlust an Verständnis also ein Problem? Die ehrliche Antwort lautet: Es kommt darauf an, und die Trennlinie verdient es, genau gezogen zu werden. Es gibt Fälle, in denen Verlässlichkeit der völlig richtige Maßstab ist und Verständnis nichts hinzufügt.

Wenn ein Ergebnis ein Einzelfall ist, billig zu überprüfen und ohne große Folgen, dann brauche ich seine Herleitung nicht zu durchschauen. Einen regulären Ausdruck kann ich gegen meine Beispiele testen, ein kleines Wegwerfskript an seinem Resultat messen. Hier auf Verständnis zu bestehen, wäre eine Romantisierung; was zählt, ist, dass das Ergebnis nachweislich stimmt.

Sobald ich aber ein System verantworte und es weiterentwickeln muss, kehrt sich der Maßstab um. Dann ist ein Ergebnis, das ich nicht verstehe, keine Einsparung, sondern eine verschobene Rechnung. Jede spätere Änderung, jeder Fehler, jede Anpassung verlangt genau das Verständnis nach, das ich beim ersten Mal übersprungen habe. Verlässlichkeit allein trägt nicht mehr, wo ich nicht nur ein Resultat brauche, sondern eine Grundlage, auf der ich weiterbauen kann.

Hinzu kommt, dass Verlässlichkeit selbst ein wackliger Maßstab ist, solange das Verständnis fehlt. Prüfen kann ich nur, woran ich gedacht habe. Welche Fälle überhaupt zu testen sind, welche Randbedingungen heikel werden, wo ein Ergebnis kippen könnte: Das verrät kein Test, sondern allein das Verständnis der Sache. Wer nicht versteht, prüft im Zweifel das Falsche und hält das Ergebnis trotzdem für gesichert.

In der Praxis zeigt sich das spätestens, wenn ein generiertes Modul Monate später in Produktion bricht und niemand im Team sagen kann, welche Annahmen ihm zugrunde liegen. Dann beginnt die Arbeit, die beim ersten Mal vermeintlich entfallen ist: die Software zu lesen, zu durchdringen, zu verstehen. Nur geschieht das jetzt unter Zeitdruck und ohne den Kontext, der bei der Entstehung noch greifbar gewesen wäre.

Diese Rechnung lässt sich nicht streichen, nur verlagern. Entweder ich erarbeite das Verständnis am Anfang, wenn der Kontext frisch und der Druck gering ist, oder ich hole es später nach, teurer und unter schlechteren Bedingungen. Verschwinden tut es nie.

Deshalb hebt generative KI den Wert des Verstehens nicht auf. Sie verschiebt nur den Zeitpunkt, zu dem wir dafür bezahlen. Sie verlagert das Problem, sie löst es nicht. Die Fähigkeit, die dadurch wichtiger wird statt unwichtiger, ist das Urteilsvermögen: zu erkennen, in welchem der beiden Fälle ich gerade bin, und zu entscheiden, ob ein Ergebnis Vertrauen verdient, ohne verstanden zu sein.

AlphaGo hat uns ein Jahrzehnt früher gezeigt, wie sich das anfühlt: eine Brillanz, die wir bewundern und kopieren, aber nicht als Einsicht erben können. Ob wir am Ende nur noch bedienen, was wir gebaut haben, oder es weiterhin verstehen, entscheiden nicht die Werkzeuge. Es entscheidet sich daran, wo wir weiterhin auf Verständnis bestehen.

(mro)

Prime Day 2026: Wir prüfen die besten Deals

Top 10: Der beste Ventilator im Test

Top 8: Die beste Kompressor-Kühlbox im Test

GPT-5.5-Cyber schlägt Mythos: Update für Sicherheitsmodell von OpenAI

2026-06-23T11:53:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Mit einer Sicherheitsinitiative geht OpenAI in Konkurrenz zu Anthropics Mythos und bietet zudem einen Sicherheits-Review-Service für Open-Source-Projekte.

(Bild: Wolf Hosbach / KI / iX)

23.06.2026, 13:53 Uhr

Lesezeit: 3 Min.

Developer

Von

Wolf Hosbach

Eine weitreichende Sicherheitsinitiative des KI-Anbieters OpenAI liefert ein Update für GPT-5.5-Cyber, eine Unterstützung von Open-Source-Projekten mit Patch the Planet und ein Security-Plugin für Codex Desktop oder CLI.

Die Initiative unter dem Namen Daybreak zielt nicht nur auf das agentengestützte Auffinden unbekannter Lücken im Code, was zu einer Flut an Issues insbesondere in Open-Source-Kreisen geführt hat. Vielmehr sollen die nun vorgestellten Tools Entwicklerinnen und Entwicklern bei der Behebung der Funde helfen. Open-Source-Maintainer können sich zudem bei Patch the Planet um kombiniertes Patchen durch OpenAI und Trail of Bits bewerben.

GPT-Cyber schlägt Mythos

Das Update für das Modell GPT-5.5-Cyber ist auf das Finden und Patchen von Sicherheitslücken in großen Codebasen spezialisiert. Es soll Probleme identifizieren, den Kontext untersuchen und einen Patch-Zyklus einleiten: entwickeln, in geschützter Umgebung prüfen, testen und für den menschlichen Review vorbereiten.

Im CyberGym-Benchmark schlägt GPT-5.5-Cyber das Top-Modell Mythos von Anthropic.

(Bild: CyberGym)

Im CyberGym-Benchmark erreicht es als Agent 85,6 Prozent, der Vorgänger lag bei 81,8 Prozent. Zudem schlägt es sich besser als Mythos, der Konkurrent von Anthropic (83,1 Prozent). Bei CyberGym müssen die Agenten eine bekannte Sicherheitslücke in einer großen Codebasis finden und in einem Proof of Concept ausnutzen – ein Patchen bewertet der Test nicht. Vor GPT-5.5-Cyber liegen noch ein speziell angepasster und ein Multimodell-Agent.

Videos by heise

Nur für Partner und deren Kunden

Daybreak kommt zu einem für OpenAI günstigen Zeitpunkt, da die Konkurrenzmodelle von Anthropic vorige Woche von der US-Regierung für ausländische Nutzer weitgehend gesperrt wurden. OpenAI betont in der Ankündigung die enge Zusammenarbeit mit der US-Regierung: „Wir stehen in einem kontinuierlichen Austausch mit der US-Regierung über unsere Cyber-Initiative, einschließlich der heutigen Ankündigungen und unseren Vorbereitungen auf die kommenden Modellveröffentlichungen.“

Nur registrierte Partner erhalten Zugang zum neuen Modell. OpenAI hat dreißig US-Firmen genannt wie Checkpoint, Cloudflare, Palantir, Sophos und eine Reihe an Beratungsfirmen. Die deutsche Pressemitteilung spricht auch von Partnerschaften mit Deutschland, UK, der EU und weiteren westlichen Ländern.

Partner dürfen GPT mit Cyber ab jetzt auch nicht nur intern, sondern auch für Kundenprojekte nutzen, den Kunden das Modell selbst aber nicht zur Verfügung stellen.

Patch the Planet: Unterstützung von Open-Source-Projekten

In Partnerschaft mit der Sicherheitsberatung Trail of Bits ruft OpenAI einen besonderen Review-Service für Open-Source-Projekte ins Leben: Patch the Planet. Nach einer Beratungsrunde prüfen die Experten eine Woche lang mit Hilfe von GPT Cyber den Code des Projekts, beheben gefundene Lücken und testen das Ergebnis. Wobei eine menschliche Prüfung am Ende des Prozesses steht.

Die ersten Projekte, die die Untersuchung durchlaufen haben, waren, cURL, NATS, pyca, Sigstore, aiohttp, Go, freenginx, Python, Python.org, urllib3, PyPI, SimpleX, Valkey und RustCrypto. Das Ergebnis waren „hunderte entdeckte Bugs, 64 Pull Requests und 51 Issues“, beispielsweise eine Korrektur der Big-Integer-Bibliothek in RustCrypto oder eine verbesserte Release-Pipeline für Python.org.

Projekte, die an einer Beratung Interesse haben, können sich über die Webseite bewerben.

(who)

Prime Day 2026: Wir prüfen die besten Deals

Top 10: Der beste Ventilator im Test

Top 8: Die beste Kompressor-Kühlbox im Test

KI-Basis entwickeln: Die Architektur smarter Systeme

2026-06-23T07:10:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Eine gute Softwarearchitektur stellt sicher, dass ein KI-System nicht von der Leistungsfähigkeit eines bestimmten Modells abhängt.

(Bild: jamesteohart / Shutterstock.com)

23.06.2026, 09:10 Uhr

Lesezeit: 19 Min.

Developer

Von

Sebastian Springer

Je intelligenter KI-Systeme werden, desto deutlicher wird: Modelle allein skalieren nicht. Viele Anwendungen beginnen mit einem Modell im Zentrum und improvisieren den Rest. Das funktioniert, solange das System nur Fragen beantworten soll. Doch sobald es handeln, Entscheidungen treffen oder mehrere Schritte koordinieren muss, stößt dieser Ansatz an seine Grenzen. Die Architektur bricht nicht spektakulär in sich zusammen, sondern sie zerfasert über die Zeit: in Workarounds, Sonderfälle und unkontrollierbare Abhängigkeiten.

Sebastian Springer weckt als Dozent für JavaScript, Sprecher auf zahlreichen Konferenzen und Autor die Begeisterung für professionelle Entwicklung mit JavaScript.

Die eigentliche Frage beim Systementwurf lautet deshalb nicht, wie man ein Modell verbessert, sondern wie man ein System baut, das intelligenter werden darf, ohne instabil zu werden. Wer versteht, wie ein KI-System aufgebaut ist und wie sich die Rollen seiner Schichten verändern, kann Anwendungen entwickeln, die nicht von der nächsten Modellgeneration überrollt werden, sondern von ihr profitieren und sie nahtlos integrieren.

Moderne KI-Systeme bestehen nicht aus einem Modell mit etwas Logik darum herum, sondern aus klar abgegrenzten Schichten, die jeweils eine eigene Verantwortung tragen und gemeinsam bestimmen, wie intelligent ein System werden kann.

Videos by heise

Die Schichten eines KI-Systems

Die Architektur eines KI-Systems lässt sich in fünf Schichten gliedern: Präsentation, Orchestrierung, Integration, Wissen und Infrastruktur. Jede Schicht erfüllt eine eigene Rolle im Gesamtsystem und hat Auswirkungen darauf, wie es Aufgaben formuliert, Entscheidungen trifft, Informationen nutzt und Aktionen ausführt. Erst im Zusammenwirken entsteht ein System, das nicht nur Antworten liefert, sondern handeln kann, und das auch dann stabil bleibt, wenn sich die Umgebung ändert und Modelle sich weiterentwickeln.

Die Architektur eines KI-Systems in fünf Schichten.

1. Präsentation – die Formulierung von Bedeutung und Rückgabe

Die Präsentationsschicht ist die Stelle, an der ein KI-System erfährt, worum es überhaupt geht. Hier wird eine menschliche Absicht oder ein Ziel so formuliert, dass das System damit arbeiten kann – sei es über eine Benutzeroberfläche, über eine API oder über interne Mechanismen wie Rollen und Systemprompts, die den Rahmen der Interaktion festlegen. Doch die Präsentationsschicht liefert nicht nur die Aufgabenstellung, sondern auch den Kontext, den das System für die Bearbeitung benötigt: Ziele, Einschränkungen, Hintergrundinformationen und Rollen.

Ebenso wichtig wie die Eingabe ist auch die andere Richtung: Die Präsentationsschicht bestimmt, in welcher Form die KI Ergebnisse zurückgibt, ob als natürlichsprachliche Antwort, als strukturierte Daten für andere Systeme oder als visuelle Darstellung. Damit bildet diese Schicht die kommunikative Hülle des Systems: Sie definiert, was das System tun soll und wie es seine Ergebnisse für Menschen oder andere Systeme aufbereitet.

Sobald die Aufgabe klar formuliert ist, übernimmt die nächste Schicht, die Orchestrierung, und kümmert sich um den Lösungsweg.

2. Orchestrierung – die Steuerung des Verhaltens

In der Orchestrierungsschicht entsteht aus einer formulierten Aufgabe ein konkreter Ablauf. Diese Schicht strukturiert die Bearbeitung: Sie zerlegt die Aufgabe in einzelne Schritte, wählt die passenden Komponenten aus und legt fest, in welcher Reihenfolge das System sie abarbeiten soll. Diese Schicht steuert die Ausführung, bewertet Zwischenergebnisse und reagiert auf unerwartete Situationen. Dazu gehört auch, Fehler abzufangen, alternative Wege zu wählen und sicherzustellen, dass das Ergebnis der ursprünglichen Intention entspricht. In dieser Schicht liegen Workflows, Pipelines, Policies, Guards und Routing-Logik – alles, was bestimmt, wie das System arbeitet.

Die Orchestrierung trifft Entscheidungen über Ablauf, Struktur und Kontrolle, nicht aber darüber, womit das System interagiert oder welches Wissen es nutzt. Damit bildet sie das operative Zentrum: Sie sorgt dafür, dass aus einer Aufgabenstellung ein nachvollziehbares, konsistentes Verhalten entsteht.

Sobald klar ist, welche Schritte notwendig sind, greift die nächste Schicht, die Integration, und stellt die Verbindung zur Außenwelt her.

3. Integration – die Verbindung zur Außenwelt

Die Integrationsschicht verbindet die internen Abläufe des Systems mit seiner Umgebung. Während die Orchestrierung festlegt, wie eine Aufgabe ausgeführt wird, stellt die Integration die Mittel bereit, um dafür auf Daten, Dienste und Funktionen außerhalb des Systems zuzugreifen. Mit dieser Schicht erhält das System die Fähigkeit, Informationen abzurufen oder externe Funktionen auszuführen. Damit definiert sie den Handlungsspielraum des Systems: welche Dienste erreichbar sind, welche Datenquellen genutzt werden können und welche Operationen grundsätzlich erlaubt sind. Technisch umfasst diese Schicht Schnittstellen wie APIs, Adapter, Connectors, Tools oder Datenbankzugriffe.

Die Integration stellt Möglichkeiten bereit, trifft aber keine Entscheidungen darüber, wann oder warum das System sie nutzen soll. Diese Verantwortung bleibt bei der Orchestrierung. Sobald klar ist, welche Informationen das System benötigt oder welche Daten bereitstehen müssen, übernimmt die nächste Schicht, die Wissensschicht, und strukturiert das dafür notwendige Wissen.

4. Wissen – das Gedächtnis und die Struktur des Wissens

Die Wissensschicht gleicht eine grundlegende Einschränkung moderner Sprachmodelle aus: Sie bringen zwar umfangreiches Sprach- und Weltwissen mit, doch dieses endet zum Zeitpunkt des Trainings. Informationen, die später entstehen oder organisationsspezifisch sind, müssen außerhalb des Modells vorliegen.

Hier setzt die Wissensschicht an. Sie stellt Wissen unabhängig vom Modell bereit, strukturiert es und hält es aktuell. Dazu gehören nicht nur Fakten und Dokumente, sondern auch Kontext, Historie und domänenspezifische Zusammenhänge. Technisch umfasst sie Datenbanken, Vektor-Stores, Wissensgraphen, Dokumente und Metadaten. Die Wissensschicht legt fest, was das System weiß und welche Informationen für eine Aufgabe relevant sind. Sie entscheidet jedoch nicht, wann dieses Wissen genutzt wird oder wie es in den Ablauf eingebettet wird. Das bleibt die Aufgabe der Orchestrierung.

Sobald das relevante Wissen bereitsteht, übernimmt die nächste Schicht, die Infrastruktur, und stellt die technischen Bedingungen bereit, unter denen das gesamte System zuverlässig läuft.

5. Infrastruktur – die technischen Bedingungen des Betriebs

Die Infrastrukturschicht stellt sicher, dass ein KI-System dauerhaft und unter realen Bedingungen zuverlässig arbeitet. Sie bildet das technische Fundament, auf dem alle anderen Schichten aufbauen, und definiert die Betriebsqualität des Systems: Verfügbarkeit, Sicherheit und Skalierbarkeit. Auf technischer Ebene umfasst sie Aspekte wie Rechenleistung, Speichernetzwerke, Identitäten, Deployment-Mechanismen und das Monitoring des Systemzustands.

Die Schichtenarchitektur zeigt, wie ein KI-System aufgebaut ist und wie seine Intelligenz entsteht. Das Sprachmodell selbst ist darin nicht enthalten, was zur entscheidenden Frage führt: Welche Rolle spielt das Modell wirklich?

Das Modell – ein Baustein, aber nicht der Kern des Systems

Intuitiv könnte man das Modell für den Kern eines KI-Systems halten. Doch in der Systemarchitektur ist es keine eigene Schicht, sondern ein kognitiver Baustein, den die Architektur zum Bereitstellen bestimmter Fähigkeiten nutzt: Sprachverständnis, Mustererkennung, Planung, Extraktion oder Klassifikation. Moderne Systeme verwenden dafür nicht ein einzelnes Modell, sondern eine ganze Reihe spezialisierter Modelle, die je nach Aufgabe eingesetzt werden.

Diese Modelle bilden eine eigene Ebene, die neben den fünf Schichten liegt. Jede Schicht kann auf Modelle zugreifen, nutzt sie jedoch für unterschiedliche Zwecke.

Die Präsentationsschicht verwendet Modelle, um natürliche Sprache zu verstehen und aus offenen Formulierungen strukturierte Aufgaben zu erzeugen. Die Wissensschicht nutzt Embedding-Modelle, um relevante Informationen zu finden oder Dokumente semantisch zu verknüpfen. In der Integrationsschicht können externe Agenten angebunden sein, die wiederum über eigene Modelle verfügen und deren Fähigkeiten in das System einfließen lassen. Selbst die Infrastrukturschicht kann Modelle einsetzen, etwa um Betriebszustände zu analysieren, Anomalien zu erkennen oder Lastverhalten vorherzusagen. Die zentrale Instanz, die entscheidet, welches Modell wann und wofür genutzt wird, ist die Orchestrierung. Sie kombiniert Modellaufrufe, bewertet deren Ergebnisse, bindet sie in Prozesse ein und kontrolliert ihren Einsatz. Die Integration liefert die Daten und ermöglicht Interaktion mit der Umgebung, die Wissensschicht ergänzt, was das Modell nicht wissen kann, die Präsentation bereitet Aufgaben für das Modell auf und die Infrastruktur stellt den Betrieb technisch sicher.

Evolution der Schichten zu einem intelligenten System

Je autonomer ein System wird, desto stärker verlagert sich seine Intelligenz aus den Modellen in die Architektur. Nicht die Modelle legen fest, wie ein System denkt und handelt, sondern die Architektur: Sie strukturiert Ziele, bereitet Entscheidungen vor, ordnet Wissen, ermöglicht Aktionen und setzt Grenzen – und nutzt dafür gezielt unterschiedliche Modelle.

Erst das Zusammenspiel der Schichten macht ein System handlungsfähig. Modelle bleiben wichtige Bausteine, die die kognitiven Fähigkeiten liefern, die jede Schicht für ihre Aufgaben benötigt – doch die Architektur bestimmt, wie weit ein System wachsen kann und wie autonom es tatsächlich agiert.

Prime Day 2026: Wir prüfen die besten Deals

Top 10: Der beste Ventilator im Test

Top 8: Die beste Kompressor-Kühlbox im Test

Secure-Boot: Zertifikatablauf steht an, Microsoft gibt weitere Hilfestellung

2026-06-23T07:06:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Die ersten Secure-Boot-Zertifikate laufen in diesen Tagen ab. Microsoft legt noch mal Handreichungen nach, für Linux auf Azure-VMs.

111

(Bild: peterschreiber.media/Shutterstock.com)

23.06.2026, 09:06 Uhr

Lesezeit: 2 Min.

Security

Von

Dirk Knop

Die Secure-Boot-Zertifikate aus dem Jahr 2011 erreichen ihr Lebensende, sie laufen in diesen Tagen ab. Microsoft müht sich redlich seit einem Jahr, dass die Zertifikate weitreichend ausgetauscht werden, einige blinde Flecken gibt es offenbar aber noch immer. Daher reicht das Unternehmen nun eine Anleitung nach, mit der auch Linux-Systeme in der Microsoft-Cloud, virtuelle Maschinen auf Azure, auf neuen Zertifikatsstand kommen.

Darauf weist Microsoft im Windows-Release-Health-Messagecenter hin. Die Anleitung soll Hilfestellung für Linux auf virtuellen Maschinen in der Azure-Cloud liefern, auch für solche mit „Trusted Launch“ (vertrauenswürdiger Start) und „Confidential VMs“, bei denen Secure Boot aktiviert ist. Dafür stellt das Unternehmen jetzt Updates bereit, mit denen Admins sicherstellen können, weiterhin Zugriff auf Plattform-Updates zu erhalten und die Integrität des vertrauenswürdigen Starts beizubehalten. Microsoft empfiehlt Organisationen, die derartige Systeme einsetzen, jetzt die Planungen für Zertifikatsupdates anzugehen, um mögliche Störungen des Secure-Boot-Prozesses zu vermeiden.

Videos by heise

Kompakte Hilfestellung

Die Anleitung ist kompakt gehalten und liefert knapp die nötigen Schritte, die IT-Verantwortliche nun nachvollziehen müssen. Auch einige Grenzen der Möglichkeiten mit Updates nennen die Autoren dort. Wenn vertrauliche VMs mit Linux vor dem April 2024 erstellt wurden, sollten Admins sie nicht manuell aktualisieren. Werte für die Laufwerksverschlüsselung sind dort im vTPM versiegelt, und es lässt sich offenbar nicht sicherstellen, dass die Full-Disk-Encryption-Keys nach einem Zertifikatsupdate damit neu versiegelt werden. Das führt dazu, dass die vertrauliche VM in den Wiederherstellungsmodus wechselt. Hier sollen Admins die alten vertraulichen VMs schlicht neu erstellen, sodass sie mit neuen Secure-Boot-Zertifikaten ausgestattet sind – ein spürbarer Mehraufwand.

(dmk)

Prime Day 2026: Wir prüfen die besten Deals

Top 10: Der beste Ventilator im Test

Top 8: Die beste Kompressor-Kühlbox im Test

Lore: Epic Games' Git-Alternative für Spieleentwickler

2026-06-22T12:21:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Ein Versionskontrollsystem speziell für Spiele- und Multimedia-Projekte gab es bislang nicht. Diese Lücke schließt Epic Games jetzt mit Lore.

(Bild: Manuel Masiero / KI / iX)

22.06.2026, 14:21 Uhr

Lesezeit: 2 Min.

Developer

Von

Manuel Masiero

Epic Games hat das Open-Source-Versionskontrollsystem (VCS) Lore veröffentlicht. Konzipiert ist es für Projekte, die Code mit großen Binärdateien kombinieren, wie sie typischerweise in der Spielebranche und der Unterhaltungsindustrie vorkommen. Damit schließt Lore eine Lücke, die bislang kein anderes VCS adressiert hat. Im Unreal Editor for Fortnite (UEFN) nutzt Epic Games Lore bereits.

Laut Designdokument eignet sich das in Rust geschriebene und zentralisierte Lore besser als andere VCS für große Spiele- und Unterhaltungsprojekte. Denn es verfügt über beliebige Inhaltstypen, eine Skalierbarkeit entlang mehrerer Achsen, mandantenfähige Sicherheit sowie eine vollständig offene Spezifikation und Lizenz. VCS-Konkurrenten wie Git, Perforce oder Mercurial können die genannten Anforderungen nicht gleichzeitig erfüllen, so Epic Games.

Videos by heise

Gleichbehandlung von Code und Dateien

Das vormals als Unreal Revision Control bekannte Lore besteht aus zwei Systemen: einem inhaltsadressierten Merkle-Baum-Speichersystem mit BLAKE3-Hashes, das sämtlichen Content dedupliziert vorhält und veränderliche Inhalte wie Metadaten separat speichert, und einem darauf aufbauenden VCS. Clients laden nur die benötigten Daten nach. Große Dateien teilt Lore in kleinere Chunks auf, sodass anschließend nur geänderte Abschnitte neu hochgeladen werden müssen.

Auf GitHub stehen neben dem Quellcode und OS-Binaries (unterstützte Systeme sind Windows, macOS und Linux) ein CLI und Server-Binaries für das MIT-lizenzierte Lore bereit. SDKs gibt es für JavaScript, Python, C# und Go.

Für Entwicklerinnen und Entwickler, die mit Lore loslegen wollen, gibt es eine Schnellstartanleitung. Da Lore Version 1.0 noch nicht erreicht hat, können sich Schnittstellen, Formate und APIs noch zwischen Releases ändern. Was genau geplant ist, lässt sich in der Lore-Roadmap nachlesen.

(mro)

Prime Day 2026: Wir prüfen die besten Deals

Top 10: Der beste Ventilator im Test

Top 8: Die beste Kompressor-Kühlbox im Test

Developer-Häppchen fürs Wochenende – kleinere News der Woche

2026-06-20T07:18:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Kleine, aber interessante Meldungshäppchen vom News-Buffet zu GitHub, Qt Creator, Nuitka, ESLint, Eclipse Theia, W3C, scikit-learn, Junie und TypeScript.

(Bild: Natalia Klenova / Shutterstock.com)

20.06.2026, 09:18 Uhr

Lesezeit: 3 Min.

Developer

Von

In unserem leckeren Häppchen-Überblick servieren wir alles, was es zwar nicht in die News geschafft hat, wir aber dennoch für spannend halten:

GitHub Copilot kann jetzt C++‑Projekte auf neue MSVC‑Build‑Tools aktualisieren. Das erledigt der @Modernize‑Agent, der Bestandteil von Visual Studio 2026 Version 18.7 ist. Er unterstützt CMake- und MSBuild-basierte Projekte (.sln, .vcxproj) und behebt Upgrade‑Fehler automatisch. Nutzerinnen und Nutzer berichten von stark verkürzten Migrationszeiten und stabileren Workflows.
Version 20 der C++‑ und Qt‑IDE Qt Creator bringt drei neue Extensions: Agent Client Protocol (ACP) Support, den ablenkungsfreien Zen‑Mode und Unterstützung für das GN‑Buildsystem (Generate Ninja). Dazu kommen zahlreiche kleinere neue Features wie verbessertes Code‑Folding und C++23‑Präprozessor‑Direktiven.
Der Python-Compiler Nuitka liegt im stabilen Release 4.1 vor. Es legt den Schwerpunkt auf bessere Async-Code- und Python-3.14-Kompatibilität, bislang fehlende Generics-Features und eine höhere Skalierbarkeit der Python‑Kompilierung.

(Bild: joeycheung / Adobe Stock)

Die Online-Konferenz Mastering GitOps von iX und dpunkt.verlag am 25. Juni 2026 widmet sich in diesem Jahr praxisnah Schwerpunkten wie dem Einsatz von GitOps im Platform Engineering und dem Rendered-Manifests-Pattern mit OCI-Registries. Tickets sind im Online-Ticketshop verfügbar.

Das Werkzeug zur statischen JavaScript-Codeanalyse ESLint hat Version 10.5 erreicht. In den Regeln max-depth und max-nested-callbacks hat das Entwicklungsteam einige Fehler behoben. Das kann dazu führen, dass für bestehenden Code mehr Fehlermeldungen erscheinen.
Im neuen Release 1.72 der Entwicklungsplattform Eclipse Theia lässt sich alternativ zu webpack nun esbuild als Bundler nutzen. Das betrifft Browser-, Browser-only- und Electron-Anwendungen. Die vollständige Build-Zeit lässt sich dadurch laut Aussage von EclipseSource von etwa 20 auf etwa zwei Sekunden reduzieren. Derzeit ist esbuild per Opt-in verfügbar, soll aber in Zukunft zur Standardoption werden.
Das World Wide Web Consortium (W3C) hat den Diversity Report 2026 veröffentlicht. Seit 2018 berichtet das W3C jährlich über seine Gender- und geografische Diversität. Beispielsweise besteht das W3C Advisory Board laut neuestem Report aus neun Männern und zwei Frauen. Drei der Board-Mitglieder sind aus Nordamerika, vier jeweils aus Europa und der Asia/Pacific-Region.

Lesen Sie auch

Software Testing: Warum deutsche Konzerne handlungsunfähig werden

Prime Day 2026: Wir prüfen die besten Deals

Top 10: Der beste Ventilator im Test

Top 8: Die beste Kompressor-Kühlbox im Test

Kestra: Ops-Automation jenseits von CI/CD

2026-06-20T07:05:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

CI/CD-Pipelines sind für Code-Deployments optimiert. Langlebige Betriebsprozesse und Self-Service-Workflows lassen sich flexibler mit Kestra orchestrieren.

(Bild: Matthias Parbel / KI / iX)

20.06.2026, 09:05 Uhr

Lesezeit: 20 Min.

Developer

Von

Philip Lorenz

Montag, 9 Uhr. Ein Entwickler braucht einen Testserver. Er öffnet das Ticketsystem, trägt Hostname, Betriebssystem und Kostenstelle ein und wartet. Einen Tag, manchmal drei. Irgendwann landet die VM in seiner Inbox, konfiguriert nach dem Stand von vor zwei Wochen, weil niemand das Template seitdem angefasst hat.

Philip Lorenz ist als DevOps- und Cloud-Engineer tätig. Zudem hält er Schulungen zu den Themen PowerShell, Automatisierung und Cloud-Computing.

Der Reflex, dieses Problem mit vorhandenen Werkzeugen zu lösen, ist verständlich. Eine Pipeline in Azure DevOps oder GitHub Actions ist schnell geschrieben. Doch CI/CD-Tools sind für etwas anderes gebaut: Code bauen, testen, deployen. Sie folgen einem Commit, laufen durch und sind fertig. Langlebige Workflows, Retry-Logik und State-Management sind nicht ihr Revier.

Genau diese Lücke füllt Kestra. Das Tool wird seit 2021 von Kestra Technologies entwickelt und ist seit Februar 2022 – im Kern als Open-Source-Projekt unter der Apache-2.0-Lizenz – öffentlich verfügbar. Kommerzielle Enterprise-Funktionen ergänzen den OSS-Kern. Kestra versteht sich als universeller Orchestrator: für Ops-Automatisierung, Data Pipelines, Event-driven Workflows und zunehmend auch für KI-Agenten und -Workflows; alles deklarativ in YAML, alles versionierbar in Git. Dieser Artikel zeigt anhand eines konkreten Beispiels, wie das in der Praxis aussieht: Ein Entwickler oder eine Entwicklerin fordert per Formular eine Hetzner-VM an, Kestra provisioniert sie vollautomatisch per Terraform. Der gesamte Code für Terraform, das Kestra-Setup sowie die Kestra Flows sind im GitHub-Repository des Autors zu finden.

Ab sofort sind Tickets zum Frühbucherpreis verfügbar.

Orchestrierung ist nicht dasselbe wie Automatisierung

Wer zum ersten Mal von Kestra hört, denkt unweigerlich, es handele sich um ein weiteres Tool, das Shell-Skripte in ein hübsches UI verpackt. Das trifft es nicht. Der Unterschied liegt im Konzept: Ein Shell-Skript oder eine CI/CD-Pipeline sind sequenziell: auf Schritt A folgt B, dann C, und am Ende ist der Status entweder fertig oder fehlgeschlagen. Was dazwischen passiert, interessiert das Tool nicht. Kestra hingegen orchestriert: Es kennt den Zustand jedes einzelnen Schritts, kann auf externe Ereignisse warten, Fehler gezielt behandeln, Schritte parallelisieren und einen Workflow nach Stunden oder Tagen an exakt der Stelle fortsetzen, an der er unterbrochen wurde.

Videos by heise

Das ist keine rein akademische Unterscheidung. In der Praxis bedeutet es, dass Kestra Workflows abbilden kann, die mit klassischen Pipeline-Tools nicht darstellbar sind: ein Provisionierungs-Job, der wartet, bis ein externes System bereit ist, eine Daten-Pipeline, die bei einem HTTP-Fehler drei Minuten pausiert und es dann erneut versucht, ein Deployment, das erst nach einer manuellen Freigabe weiterläuft. Was andere Tools „Pipeline“ nennen, ist in Kestra ein Flow.

Das Entwicklungsteam hinter dem Projekt positioniert Kestra bewusst für ein breites Einsatzspektrum. Im Vordergrund stehen dabei:

Ops Automation: Infrastruktur bereitstellen, Cluster provisionieren, wiederkehrende Betriebsaufgaben automatisieren.
Data Pipelines: Kestra tritt hier in direkten Wettbewerb mit Apache Airflow und Prefect
Event-driven Workflows: Flows, die auf Webhooks, Queue-Nachrichten oder Dateiänderungen reagieren.
KI-Workflows: Kestra orchestriert KI-Agenten genauso wie klassische Ops-Tasks.

Die vier Grundbausteine

Kestra kennt vier Konzepte, die Entwickler zunächst verinnerlichen sollten, um den Gesamtansatz des Tools leichter zu verstehen.

Ein Flow ist die oberste Einheit, vergleichbar mit einer Pipeline-Definition, aber mit deutlich mehr Ausdruckskraft. Jeder Flow hat eine ID, einen Namespace zur Strukturierung und eine Liste von Tasks. Er lebt als YAML-Datei in Git und lässt sich darüber versionieren und deployen.

Tasks sind die einzelnen Schritte innerhalb eines Flows. Kestra bringt eine umfassende Bibliothek an eingebauten Task-Typen mit: HTTP-Requests, Dateioperationen, Shell-Kommandos, Container-Ausführung, Schleifen, Bedingungen und Parallelisierung. Tasks können Outputs produzieren, die nachfolgende Tasks als Inputs verwenden. Dadurch entsteht ein nachvollziehbarer Datenfluss zwischen den einzelnen Schritten des Flows.

Trigger definieren, wann ein Flow startet. Zur Auswahl stehen Zeitpläne (Cron), Webhooks, andere Flows als Auslöser oder manuelle Ausführung über das UI. Der manuelle Trigger ist dabei nicht zu unterschätzen: Er öffnet im Kestra-UI automatisch ein Eingabeformular für alle deklarierten Inputs.

Plug-ins erweitern Kestra um externe Integrationen. Das offizielle Plug-in-Ökosystem umfasst unter anderem Terraform, Kubernetes, AWS, Azure, GCP, Slack, dbt und Airbyte. Plug-ins sind versionierte JARs, die Kestra beim Start lädt, ohne separates Dependency-Management oder pip install.

Das folgende Listing zeigt einen minimalen Flow:

id: hello-kestra
namespace: demo

inputs:
  - id: message
    type: STRING
    defaults: "Hallo von Kestra"

tasks:
  - id: log
    type: io.kestra.plugin.core.log.Log
    message: "{{ inputs.message }}"

Dieser Flow zeigt das Wesentliche: Der Namespace demo strukturiert Flows im UI ähnlich wie Ordner. Der Input message erscheint bei der manuellen Ausführung als Textfeld. Der Task referenziert den Input per Pebble-Template-Syntax {{ inputs.message }}. Dieselbe Syntax funktioniert überall im Flow für Secrets, für Outputs vorheriger Tasks sowie für Metadaten der Execution.

Kein Ersatz, sondern Ergänzung

Die Frage kommt verlässlich: Haben wir nicht schon Azure DevOps? Brauchen wir das wirklich? Die Antwort ist ja und nein. Azure DevOps oder GitHub Actions bleiben für das, was sie können, ungeschlagen: Code kompilieren, Tests ausführen, Container bauen, Artefakte deployen. Wer diese Aufgaben ersetzen will, hat das falsche Problem, denn Kestra setzt an einer anderen Stelle an.

CI/CD bleibt die richtige Schicht für alles, was aus dem Repository kommt: bauen, testen, ausliefern. Viele Betriebsprozesse beginnen jedoch mit einer Anfrage statt mit einem Commit: Eine Umgebung soll entstehen, ein Change muss geprüft, eine Ressource freigegeben oder ein externer Dienst eingebunden werden. Genau dort ergänzt Kestra die vorhandene CI/CD-Landschaft.

Ein konkretes Beispiel: Ein Entwickler will einen Kubernetes-Cluster provisionieren. In einer Azure-DevOps-Pipeline lässt sich das technisch abbilden, mit terraform apply als Skript-Task. Was fehlt, ist alles drumherum: Es gibt kein strukturiertes Eingabeformular für Entwickler und keine saubere Retry-Logik, wenn der Cloud-Provider einmal nicht antwortet. Es gibt auch kein Log, das zeigt, wer wann welche Ressource angefordert hat. Vor allem aber behandelt eine Pipeline Terraform im Stil von „fire and forget“: Skript starten, durchlaufen lassen, auf ein Ergebnis hoffen – was dazwischen passiert, ist nicht greifbar. Kestra kapselt dagegen jede Execution vollständig mit ihren Parametern: State, Logs und Retry-Verhalten sind eindeutig einer konkreten Execution zugeordnet und im UI nachvollziehbar. Schlägt ein Schritt fehl, weiß Kestra, an welcher Stelle, mit welchen Eingaben und in welchem Zustand, und kann gezielt darauf reagieren, statt blind von vorne zu beginnen.

Vergleich mit Airflow und Prefect: Der Blickwinkel ist entscheidend

Welche Alternativen zu Kestra infrage kommen, hängt vom Blickwinkel ab, der sich etwa zwischen Data Engineering und Platform Engineering erheblich unterscheidet. Wer aus dem Data-Engineering-Umfeld kommt, denkt meist zuerst an Apache Airflow, heute ein Top-Level-Projekt der Apache Software Foundation, oder an Prefect, das vom gleichnamigen Unternehmen entwickelt wird. Airflow ist der etablierte Standard für DAG-basierte Daten-Pipelines mit Abhängigkeiten, Scheduling und Retry-Logik. Prefect ist eine modernere Alternative, die mit geringerem Betriebsaufwand und einer schlankeren API punktet. Kestra besetzt denselben Raum, ist aber weniger Python-zentrisch: Flows sind in YAML definiert, Tasks sind Plug-in-Aufrufe, Python-Wissen ist nicht erforderlich. Das macht Kestra vor allem für gemischte Teams zugänglicher.

Im Platform Engineering kommen hingegen ganz andere Werkzeuge zum Einsatz. Verbreitet sind unter anderem Argo Workflows als Kubernetes-nativer Orchestrator, die Ansible Automation Platform für Betriebsaufgaben und Configuration Management oder Terraform Cloud für Infrastructure-as-Code-Workflows. All diese Tools lösen echte Probleme, aber jedes ist fest in seinem Paradigma verankert. Terraform Cloud macht Terraform, Argo macht Kubernetes-Workflows, die Ansible Automation Platform macht Ansible. Kestra gibt sich hier bewusst universeller: Ein Flow kann einen Terraform-Container starten, danach ein PowerShell-Skript ausführen, eine HTTP-API aufrufen und das Ergebnis in Slack melden – in einem einzigen YAML-Flow, ohne dass das Tool Rücksicht auf die darunter liegenden Technologien nehmen müsste.

Aus Entwicklersicht bleiben Azure DevOps und GitHub Actions erste Wahl für die CI/CD-Schicht. Airflow oder Prefect können in datengetriebenen Umgebungen weiter ihren Dienst tun. Kestra ergänzt aber dort, wo keines dieser Tools zu Hause ist: als Orchestrierungsschicht, die heterogene Toollandschaften zusammenhält, gleichzeitig aber auch als Ersatz für einzelne Tools dienen kann.

Lokal testen, im Cluster betreiben

Kestra lässt sich lokal per Docker Compose starten. Die vollständige docker-compose.yml liegt im begleitenden GitHub-Repository. Der Befehl docker compose up -d genügt, danach ist das UI unter http://localhost:8080 sofort erreichbar:

Kestra bringt bereits über 1300 Plug-ins mit (Abb. 1).

Für den produktiven Betrieb auf Kubernetes gibt es ein offizielles Helm-Chart. Die Komponenten (Server, Scheduler, Executor und Worker) laufen als separate Deployments und lassen sich unabhängig skalieren. Worker übernehmen die eigentliche Task-Ausführung und sind der primäre Skalierungshebel: Mehr parallele Executions bedeuten mehr Worker-Replicas, der Rest der Infrastruktur bleibt stabil. Wer Kestra-Ressourcen (Flows, Namespaces, Secrets, User und Rollen) ebenfalls als Code verwalten will, greift zum offiziellen Terraform-Provider: Er bildet die gesamte Kestra-Konfiguration als Terraform-Ressourcen ab und lässt sich nahtlos in bestehende Infrastructure-as-Code-Pipelines integrieren.

Prime Day 2026: Wir prüfen die besten Deals

Top 10: Der beste Ventilator im Test

Top 8: Die beste Kompressor-Kühlbox im Test

AMD und Intel spezifizieren KI-Befehlssatz „ACE“ für x86-Prozessorkerne

2026-06-19T14:20:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

CPU-Kerne künftiger x86-Prozessoren von AMD und Intel haben zusätzliche Rechenwerke unter anderem für Matrix-Multiplikationen, die AI Compute Extensions (ACE).

Die ACE-Rechenwerke künftiger x86-CPUs sind eng mit den Advanced Vector Extensions (AVX) gekoppelt.

(Bild: x86 Ecosystem Advisory Group (x86 EAG))

19.06.2026, 16:20 Uhr

Lesezeit: 2 Min.

c't Magazin

Von

Christof Windeck

Seit Herbst 2024 kooperieren AMD und Intel in der x86 Ecosystem Advisory Group, auch um sich gegen Konkurrenten wie ARM und RISC-V zu stärken. Nun ist die gemeinsam erarbeitete Spezifikation für neue x86-Prozessorbefehle erschienen, die die Verarbeitung von KI-Algorithmen beschleunigen sollen: Die AI Compute Extensions, kurz „ACE“.

Bei ACE geht es vor allem um Matrix-Multiplikationen mit KI-Datenformaten für das Inferencing mit quantisierten Gewichten.

Konkurrent ARM hat bereits Scalable Matrix Extensions (SME2) spezifiziert, die auf die Scalable Vector Extensions (SVE2) aufbauen. SME-Rechenwerke lassen sich auf unterschiedliche Art in ARM-SoCs integieren. Apple baut SME2 seit dem M4 ein, Qualcomm ab dem Snapdragon X2.

Videos by heise

Eng mit AVX verknüpft

Die AI Compute Extensions (ACE) Specification steht in Version 1.15 auf der Website der x86 Ecosystem Advisory Group zum Download bereit. Die Spezifikation beschreibt nur die Befehle, nicht die konkrete Implementierung.

Kommende ACE-Rechenwerke sind eng mit den Advanced Vector Extensions (AVX) gekoppelt und nutzen beispielsweise dieselben Register. Konkret nennt die Spezifikation AVX10. Sie erwähnt zudem die bisher nur von Intel in aktuellen Xeon-Serverprozessoren eingebauten Advanced Matrix Extensions (AMX).

Prozessoren mit ACE-v1-Rechenwerken müssen auch einen bestimmten Teil des Befehlsumfangs von AVX10.2 beherrschen.

Lesen Sie auch

Bit-Rauschen: Die CPU-Matrix-Rechenwerke kommen

Intel im Kampf gegen ARM: "Stolz stehen wir an der Seite von AMD"

KI-Hardware-Beschleuniger: So funktionieren Rechenwerke für KI-Algorithmen

Prime Day 2026: Wir prüfen die besten Deals

Top 10: Der beste Ventilator im Test

Top 8: Die beste Kompressor-Kühlbox im Test

Agentic Resource Discovery: Suchmaschine für KI-Agenten

2026-06-19T12:27:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Mit Agentic Resource Discovery (ARD) finden KI-Agenten passende Tools automatisch zur Laufzeit. ARD steckt schon in Googles Gemini Enterprise Agent Platform.

(Bild: Manuel Masiero / KI / iX)

19.06.2026, 14:27 Uhr

Lesezeit: 2 Min.

Developer

Von

Manuel Masiero

Google hat zusammen mit Launch-Partnern wie Cisco, GitHub, Hugging Face, Microsoft, Nvidia und Snowflake die Agentic Resource Discovery (ARD) vorgestellt. Mit der offenen Spezifikation können KI-Agenten während der Ausführung ihrer Aufgabe die passenden agentischen Werkzeuge automatisch im Web finden und einsetzen.

Die ARD spezifiziert dazu öffentlich zugängliche Verzeichnisse, in denen Agenten Tools und Dienste organisationsübergreifend und unabhängig vom dahinterstehenden Framework, Protokoll oder Anbieter finden können. Das versetzt sie in die Lage, drei Kernfragen zu beantworten: Wo finde ich eine passende Fähigkeit, welche genau sollte ich für die anstehende Aufgabe nutzen und ist die ausgewählte Fähigkeit auch sicher?

Bislang kam diese Rolle praktisch zwingend dem Menschen zu. Interoperabilitätsprotokolle wie Model Context Protocol (MCP) und Agent2Agent (A2A) oder einzelne Skills setzen voraus, dass die Entwicklerin oder der Entwickler bereits weiß, welches Werkzeug, welcher Skill oder welcher Agent für die jeweilige Aufgabe benötigt wird. Das wiederum bedeutet, dass die Tools bereits installiert sein müssen.

Videos by heise

Suchmaschine für Agenten

ARD basiert auf zwei Bausteinen: Katalogen und Registries. Um erste zu befüllen, veröffentlichen Anbieter auf ihrer Domain eine ai-catalog.json-Datei, die die Fähigkeiten ihrer KI-Dienste beschreibt, etwa von MCP-Servern, A2A-Agenten oder OpenAPI-Tools. Die Domain bildet gleichzeitig die kryptografische Vertrauensbasis für https://<publisher-domain>/.well-known/ai-catalog.json.

ARD-Funktionsschema: Katalog veröffentlichen, Fähigkeit finden, Identität prüfen und Tool zur Laufzeit ausführen.

(Bild: Google)

Registries übernehmen die Rolle der Suchmaschine für das Agenten-Web. Sie crawlen die Kataloge, indexieren sie und liefern bei Suchanfragen passende Ressourcen inklusive Verifikations-Metadaten. Agenten können die ausgewählte Funktion dynamisch laden, ihr natives Protokoll oder ihre API zum Datenaustausch nutzen und das Ergebnis an Entwicklerinnen oder Entwickler zurückgeben.

Das als v0.9-Entwurf vorliegende Open-Source-Projekt läuft unter der Apache-2.0-Lizenz. Google integriert ARD in Google Cloud als Teil der Gemini Enterprise Agent Platform. Auch einige Launch-Partner wie Hugging Face haben bereits ihre Referenzimplementierungen vorgestellt. Eine vollständige Liste findet sich auf der offiziellen Webseite zu Agentic Resource Discovery, die auch die Spezifikationen enthält.

(mro)

heise developer News

OAuth für alle: Cloudflare öffnet sein Ökosystem

Mehr Kontrolle für Entwickler und Anwender

Aufwendiger Umbau im Hintergrund

Token-Verhalten und Migrationseffekte

Software Testing: Was KI mit Vertrauen und Teamgefüge wirklich anrichtet

Empfohlener redaktioneller Inhalt

Softwarequalität im Gespräch

Mistral OCR 4: Dokumentenanalyse für 170 Sprachen

OCR 4 liefert mehr als reinen Text

Einsatz in Suche, RAG und Agenten

Mehrsprachigkeit und Self-Hosting

Einordnung der Benchmarks

API, Document AI und Preise

Verfügbarkeit

Sichere API-Zugriffe für Agenten mit Postman Passport

Immer mehr API-Aufrufe durch Agenten

KI-Coding-Tools: Geschwindigkeit ohne Kontrolle als Risiko

Governance wichtiger als Geschwindigkeit

Mensch oder Maschine: Wer hat’s geschrieben?

Minimus stellt tausende CVE-freie Container-Images kostenlos bereit

Distrolos, gehärtet und als Drop-in-Ersatz konzipiert

Compliance-Fokus: FIPS, CIS, NIST und STIG

Enterprise Edition mit SLAs und KI-Integrationen

Serverless mit Pausenfunktion: AWS stellt Lambda MicroVMs vor

Start aus Dockerfile, Zugriff per HTTPS

Verfügbarkeit und Preis

Claude mischt sich ein: Der neue proaktive KI-Kollege für Slack

Claude als gemeinsamer Kanal-Agent

Proaktiv statt nur reaktiv

Start in Slack

Softwarebranche muss Geschäftsmodelle umbauen

Messbare Ergebnisse statt Arbeitszeit

Domänenwissen und Vertrauen als Wettbewerbsvorteil

Plattformen, Daten und Handlungsfelder

Warum das Healthtech-Unternehmen Heidi auf den deutschen Markt setzt

Webentwicklung: Vite 8.1 soll große Anwendungen beschleunigen

Bundled Dev Mode

Updates für Wasm und Lightning CSS

VoidZero: Teil von Cloudflare

Ergebnis ohne Erkenntnis: Was uns AlphaGo über GenAI lehrt

Das funktionierende Ergebnis ohne den Weg dorthin

Ein Zug, den niemand erklären kann

Lässt sich die Blackbox wirklich öffnen?

Verständnis, das vielleicht nirgends mehr existiert

Verlässlichkeit ersetzt kein Verstehen

GPT-5.5-Cyber schlägt Mythos: Update für Sicherheitsmodell von OpenAI

GPT-Cyber schlägt Mythos

Nur für Partner und deren Kunden

Patch the Planet: Unterstützung von Open-Source-Projekten

KI-Basis entwickeln: Die Architektur smarter Systeme