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.

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.

(fo)

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.

Vor diesem Hintergrund baut das australische Healthtech-Unternehmen Heidi seine Präsenz in Europa aus. Das Unternehmen entwickelt KI-basierte Software für Gesundheitsfachkräfte, darunter ein Dokumentationssystem, das aus klinischen Gesprächen automatisch medizinische Notizen erstellt. Nach Angaben von Heidi unterstützt die Plattform mehr als 110 Sprachen und ist in mehreren Ländern im Einsatz.

Dr. Simon Kos, Global Chief Medical Officer von Heidi, war zuvor Global Chief Medical Officer bei Microsoft und in Führungspositionen bei Cerner und Next Practice beschäftigt. In diesem redaktionell bearbeiteten Interview spricht er über die Rolle Deutschlands bei der internationalen Expansion von Heidi, regulatorische Anforderungen und die Zukunft KI-gestützter Arbeitsabläufe im Gesundheitswesen.

Deutschland und die internationale Expansion

Warum hat Heidi beschlossen, ein spezielles Angebot für Deutschland zu entwickeln? Was macht den deutschen Markt so wichtig?

Simon Kos: Bei Heidi entwickeln wir uns derzeit von unseren Wurzeln als Anbieter von Dokumentationslösungen hin zu einem echten „AI Care Partner“. Der deutsche Markt ist für uns sehr wichtig. Wir sind heute in 190 Ländern aktiv und damit in sehr vielen Märkten vertreten. Deutschland betrachten wir jedoch als einen der reifsten Märkte, wenn es um regulatorische Anforderungen und Compliance geht. Wir sind überzeugt: Wenn wir es in Deutschland richtig machen, können wir es überall auf der Welt richtig machen.

Bild 1 von 4

Es gibt zwei Arten von KI-Anwendungen im Gesundheitswesen: solche, die bereit sind, sich regulierten Märkten zu stellen, und solche, die das nicht sind. Wir sind weltweit aktiv und können daher frühzeitig auch in weniger regulierten Märkten ausrollen. Gleichzeitig orientieren wir uns stets an den höchsten Qualitätsanforderungen. Deutschland und die britische Arzneimittel- und Medizinproduktebehörde (MHRA) setzen aus unserer Sicht die höchsten Maßstäbe.

Was meinen Sie damit?

Im Vereinigten Königreich hat die MHRA medizinische Dokumentationsassistenten („Scribes“) als Medizinprodukte der Klasse I eingestuft. Für unsere Produkte gilt wahrscheinlich mindestens die Klasse IIa, vermutlich sogar Klasse IIb. Unabhängig davon, in welchem Land wir tätig sind, müssen wir uns an diesen Maßstäben messen lassen.

Wie verläuft der Markteintritt bislang? Gibt es bestimmte Regionen, die für Heidi besonders wichtig geworden sind?

Da Heidi ein Freemium-Modell verfolgt, wurde die Plattform weltweit übernommen. Ehrlicherweise haben wir nicht für jeden einzelnen Anwendungsfall in jedem Land vollständige Transparenz. Wir sehen jedoch sehr genau, wo sich eine kritische Masse an Nutzern bildet.

Obwohl wir in Australien gestartet sind, bleiben Australien und Neuseeland wichtige Märkte. Nordamerika, insbesondere die USA und Kanada, bildet einen weiteren Schwerpunkt. Europa entwickelt sich ebenfalls zu einem solchen Zentrum. Inzwischen haben wir drei oder vier Kernregionen weltweit.

Stehen Ärztinnen, Ärzte und andere Gesundheitsfachkräfte weltweit vor ähnlichen Herausforderungen?

Es gibt definitiv gemeinsame Muster. Weltweit hat die Digitalisierung dazu geführt, dass Gesundheitsfachkräfte weniger Zeit mit Patientinnen und Patienten und mehr Zeit mit Computern verbringen. Zu viel Arbeitszeit fließt in die Administration und Dokumentation.

Unser gemeinsames Ziel besteht darin, mithilfe von Technologie diese Tätigkeiten mit geringem Mehrwert zu reduzieren und Zeit sowie Aufmerksamkeit wieder der Patientenversorgung zu widmen. Gleichzeitig ist jede Region anders. Wir unterstützen 110 Sprachen, und dabei geht es nicht nur um Übersetzung. Im Deutschen müssen wir beispielsweise geschlechtersensible Sprache berücksichtigen. In Europa spielen zudem Akzente eine wichtige Rolle. Hinzu kommen Situationen, in denen während einer Konsultation mehrere Sprachen gesprochen werden.

Ferner unterscheiden sich die Gesundheitssysteme selbst erheblich. Jedes Land organisiert seine Versorgung anders. Deshalb wird die Integration in lokale Praxisverwaltungssysteme und elektronische Patientenakten so wichtig.

Australien gehörte zu den ersten Märkten, die Ambient AI eingeführt haben. Welche Erfahrungen haben Sie dort gesammelt?

Ambient Scribing hat im Jahr 2024 wirklich Fahrt aufgenommen. Schon heute sehen wir, dass diese Technologie zunehmend als selbstverständlicher Bestandteil moderner Gesundheitsversorgung betrachtet wird. Wir sind überzeugt, dass dies die Zukunft des Gesundheitswesens ist.

Ob in der Primärversorgung oder im Krankenhaus: Das Erfassen gesprochener Gespräche – zwischen medizinischem Personal und Patientinnen und Patienten oder auch zwischen Fachkräften untereinander – wird zunehmend zur Standardmethode der Dokumentation werden.

Interessant ist dabei, dass diese Technologie nicht von einer vollständig digitalisierten Infrastruktur abhängt. Selbst in Umgebungen ohne umfassende elektronische Patientenakten nutzen Menschen die automatisch erzeugten Notizen, drucken sie aus und versenden sie teilweise sogar per Fax. Die Einführung erfolgt unabhängig vom Reifegrad der zugrunde liegenden Systeme.

Wo liegen die größten Unterschiede zwischen den Ländern?

Die Regulierung ist wahrscheinlich der wichtigste Faktor. Deutschland befindet sich hinsichtlich Governance- und Compliance-Anforderungen am oberen Ende der Skala. In vielen Entwicklungs- und Schwellenländern existieren solche Rahmenbedingungen dagegen noch nicht. Die USA sind vergleichsweise liberal, Australien liegt irgendwo dazwischen.

Der zweite Faktor ist die Kultur und die Bereitschaft, neue Technologien anzunehmen. Besonders hohe Akzeptanz beobachten wir in den USA, weil dort erhebliche Dokumentationsanforderungen mit der Abrechnung medizinischer Leistungen verbunden sind. Auch in öffentlich finanzierten Gesundheitssystemen gibt es Verwaltungsaufwand, aber häufig in geringerem Ausmaß.

Hinzu kommen Datenverarbeitung und Datensouveränität. Wir bei Heidi sind der Ansicht, dass Informationen lokal gespeichert und lokal verarbeitet werden sollten. Nicht alle Anbieter verfolgen diesen Ansatz.

Der Markt für Ambient AI ist inzwischen stark umkämpft. Wie sehen Sie die weitere Entwicklung des Wettbewerbs?

Ich habe vor meinem Wechsel zu Heidi 15 Jahre bei Microsoft gearbeitet und kenne diese Welt daher sehr gut. In verschiedenen Märkten treten unterschiedliche Wettbewerber auf, aber es gibt nur wenige wirklich globale Anbieter. Microsofts Dragon Copilot gehört sicherlich dazu. Auch Corti leistet interessante Arbeit.

Was Heidi etwas unterscheidet, ist die Tatsache, dass wir nicht nur ein KI-Dokumentationsassistent sind. Unser Evidence-Produkt ist ebenfalls in Deutschland verfügbar, und unser Hardware-Angebot wird bald folgen.

In manchen Bereichen konkurrieren wir direkt mit anderen Anbietern, in anderen lösen wir andere Probleme. Es ist ein extrem dynamischer Markt. Allein in den vergangenen zwei Jahren hat sich enorm viel verändert. In Australien gibt es beispielsweise inzwischen mehr als ein Dutzend Anbieter von KI-gestützten Dokumentationslösungen.

Wir beobachten häufig dasselbe Muster: Zunächst versuchen Gesundheitssysteme, eigene Lösungen zu entwickeln. In Neuseeland gab es etwa ein Produkt namens TUI, weil die Unterstützung der Māori-Sprache wichtig war. Singapur entwickelte eine eigene Lösung aufgrund der Vielzahl lokaler Dialekte.

Langfristig wenden sich Organisationen jedoch meist von Eigenentwicklungen ab und greifen auf kommerzielle Anbieter zurück. Lokale Nischenanbieter bleiben bestehen, gleichzeitig entstehen zunehmend globale Plattformen.

Datenschutz und Interoperabilität

Datenschutz und Datensouveränität sind in Europa zentrale Themen. Wie geht Heidi damit um?

Wir orientieren uns an den höchsten Standards beim Schutz personenbezogener Daten. Die Datenschutz-Grundverordnung (DSGVO) in Europa und insbesondere in Deutschland setzt sehr hohe regulatorische Maßstäbe.

Wir entwickeln unsere Lösungen mit Blick auf diese Anforderungen und stellen dieselben Funktionen anschließend weltweit bereit – auch in Märkten, in denen lokale Vorschriften weniger streng sind. Datensouveränität ist für uns wichtig. In Australien war das nicht nur eine ideologische Frage, sondern auch eine praktische. Aufgrund unserer geografischen Lage wollten wir Daten möglichst nahe am Nutzungsort hosten. Außerdem wollten wir nicht von benachbarten Rechtsräumen abhängig sein.

Deshalb wurde Heidi von Anfang an nach dem Prinzip der Datensouveränität entwickelt. Wo immer wir tätig sind, stellen wir sicher, dass Daten in räumlicher Nähe zu ihrem Einsatzort gespeichert werden.

Was bedeutet das konkret für Deutschland?

Deutschland hat traditionell eine starke Präferenz für die Speicherung von Daten im eigenen Land. Unsere Rechenzentren für Deutschland befinden sich in Frankfurt. Daten werden lokal erfasst, lokal gespeichert, lokal verarbeitet und verlassen diesen Bereich nicht.

Das ist für Deutschland besonders wichtig. Andere Länder legen weniger Wert darauf, solange die Dienste zuverlässig funktionieren und hohe Sicherheitsstandards gewährleistet sind. Deutschland misst der Datensouveränität jedoch seit jeher eine besondere Bedeutung bei.

Viele europäische Organisationen sorgen sich wegen US-Gesetzen wie dem CLOUD Act. Spielt das für Ihre Positionierung eine Rolle?

Der CLOUD Act ist definitiv Teil der Diskussion. Wenn ein Dienstleister ein US-Unternehmen ist, kann er entsprechenden Anforderungen unterliegen. Wir selbst sind aber kein US-Unternehmen.

Trotzdem bleibt Sicherheit ein zentrales Thema. Wir nutzen die Infrastruktur großer Cloud-Anbieter wie AWS, Microsoft Azure und Google Cloud. Diesen Anbietern vertrauen wir, weil sie enorme Investitionen in Sicherheit tätigen und sehr hohe Standards einhalten.

Interoperabilität bleibt eine große Herausforderung im Gesundheitswesen. Viele Softwareanbieter zögern weiterhin, ihre Systeme zu öffnen. Wie sehen Sie dieses Problem?

Das ist weltweit ein verbreitetes Problem. Das Interessante daran ist, dass es in der Regel kein technisches Problem ist. Es geht um Geschäftsmodelle, wirtschaftliche Interessen und teilweise auch um Ängste. Historisch gesehen kontrollierten diejenigen Organisationen, die die Patientenakte verwalteten, auch die Benutzererfahrung. Heute gewinnen KI-Unternehmen zunehmend die Aufmerksamkeit und Arbeitszeit der Gesundheitsfachkräfte, und dadurch verändern sich die Kräfteverhältnisse.

Viele Anbieter elektronischer Patientenakten entwickeln inzwischen eigene KI-Produkte – Dokumentationsassistenten, Evidenzsysteme, Abrechnungswerkzeuge oder Lösungen zur Workflow-Orchestrierung. Entsprechend besteht häufig der Wunsch, Nutzerinnen und Nutzer im eigenen Ökosystem zu halten, statt fremde Lösungen zu integrieren.

Ist Heidi bereit, sich umfassend zu integrieren?

Absolut. Das ist für uns sehr wichtig. Heidi ist nicht als langfristiges Primärsystem für medizinische Daten konzipiert. Wir begleiten die Konsultation, hören zu, erstellen Transkripte und erzeugen Dokumentationsartefakte wie klinische Notizen, Facharztbriefe oder Patienteninformationen.

Wir möchten diese Informationen jedoch nicht dauerhaft speichern. Sie gehören in die elektronische Patientenakte oder das jeweilige Praxisverwaltungssystem.

Deshalb wollen wir eng mit Anbietern von Praxisverwaltungssystemen und elektronischen Patientenakten zusammenarbeiten. Sie sind für die langfristige Führung der Patientenakte verantwortlich.

Heidi bietet neben kostenpflichtigen Abonnements auch eine kostenlose Version an. Welche Überlegung steckt hinter diesem Modell?

Wir sind überzeugt, dass diejenigen, die dafür bezahlen können, dies auch tun sollten. Gleichzeitig wollen wir die globale Versorgungskapazität im Gesundheitswesen verdoppeln.

Die kostenlose Version bietet einen grundlegenden Funktionsumfang. Dafür setzen wir kostengünstigere Modelle ein, bieten weniger Anpassungsmöglichkeiten und einen eingeschränkten Support.

Die kostenpflichtige Version liefert ein deutlich umfangreicheres Nutzungserlebnis. viele Fachärztinnen und Fachärzte möchten beispielsweise, dass Berichte ihren persönlichen Stil und ihre eigene Ausdrucksweise widerspiegeln. Mit den kostenpflichtigen Angeboten lassen sich Vorlagen und Arbeitsabläufe wesentlich stärker individualisieren.

Monetarisieren Sie die Daten in irgendeiner Form?

Derzeit monetarisieren wir keine Daten. Wir trainieren unsere Modelle nicht mit Patientendaten. Diese Daten gehören der jeweiligen Gesundheitseinrichtung oder der behandelnden Fachkraft. Unser Geschäftsmodell basiert auf Abonnements – sowohl für einzelne Nutzerinnen und Nutzer als auch für Unternehmenskunden.

Welche KI-Modelle kommen bei Heidi zum Einsatz?

Wir verwenden einen Mix verschiedener Modelle. Wir haben mit kommerziellen Modellen begonnen und mehrere davon nutzen wir weiterhin. Gleichzeitig trainieren und verfeinern wir auch eigene Modelle.

Das ist ein bewegliches Ziel, weil sich die Technologie so schnell weiterentwickelt. Wir evaluieren kontinuierlich, welche Modelle sich für bestimmte Anwendungsfälle am besten eignen.

Warum setzen Sie nicht vollständig auf Open Source?

Open-Source-Modelle kommen durchaus zum Einsatz, insbesondere jene, die wir selbst trainiert und angepasst haben. Letztlich hängt die Entscheidung immer von Leistung, Zuverlässigkeit und Wirtschaftlichkeit ab. Unterschiedliche Produkte erfordern unterschiedliche Fähigkeiten. Deshalb wählen wir jeweils das Modell, das für die konkrete Aufgabe am besten geeignet ist.

Wie stellen Sie klinische Qualität und Sicherheit sicher?

Genau dafür haben wir unser Team für medizinisches Wissen, klinische Sicherheit und Inhalte. Viele Mitglieder dieses Teams sind Ärztinnen, Ärzte oder verfügen über einen klinischen Hintergrund.

Sie entwickeln die Leitplanken für die Modelle. Unabhängig davon, ob wir eigene oder kommerzielle Modelle einsetzen, verfügen wir über mehrere Prüf- und Validierungsebenen, um sicherzustellen, dass die Ergebnisse sicher und klinisch angemessen sind.

Abschließend: Was ist Ihre übergeordnete Vision für Heidi?

Unsere Mission besteht darin, die weltweite Versorgungskapazität im Gesundheitswesen zu verdoppeln. Wir sehen im Gesundheitswesen eine enorme Menge unsichtbarer Arbeit, die Zeit und Energie bindet, ohne unmittelbar zur Patientenversorgung beizutragen. Überall dort, wo wir kognitive Belastungen oder administrativen Aufwand erkennen, prüfen wir, ob Technologie helfen kann.

Letztlich ist das Ziel einfach: Zeit und Aufmerksamkeit wieder der Versorgung von Patientinnen und Patienten zu widmen. Daran orientiert sich jedes Produkt, das wir entwickeln.

Das Interview wurde ursprünglich auf Englisch geführt.

(mack)

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.

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.

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.

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 sofort erreichbar:

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.