Connect with us

Künstliche Intelligenz

Warum die Digitalisierung des Öffentlichen Gesundheitsdienstes kaum vorankommt


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

Der Digitalisierungspakt für den Öffentlichen Gesundheitsdienst (ÖGD) läuft bald aus. Man kann also fragen: Was ist in der Zeit (und mit dem Geld) für den ÖGD passiert? Als Informatiker im ÖGD habe ich den Pakt mehrere Jahre begleitet. Dabei sind mir einige Punkte begegnet, die sinnbildlich für die stockende Verwaltungsdigitalisierung in Deutschland stehen.

Weiterlesen nach der Anzeige

Was der ÖGD macht, ist je nach Bundesland unterschiedlich, aber beispielhaft: Schuleingangsuntersuchungen, Gesundheitszeugnisse für Tätigkeiten mit Lebensmitteln, Untersuchungen von Beamtenanwärtern, Trink- und Badewasserüberwachung, Aufbewahrung von Totenscheinen – und im Pandemiefall spielt er eine zentrale Rolle. Gesundheitsämter organisieren Kontaktnachverfolgung und Quarantäneanordnungen. In der Pandemie lief das nur bedingt gut: Prozesse blieben unverändert, Kapazitäten fehlten, also wurde Personal aufgestockt, teils mit Unterstützung der Bundeswehr.

Parallel entstanden privatwirtschaftliche Lösungen wie die Luca-App. Es ging weiter – aber nicht strukturell besser. Der Digitalisierungspakt sollte die Ämter widerstandsfähiger machen: digitaler, effizienter, souveräner. Ambitionierte und notwendige Ziele. Doch der Zustand der Verwaltungsdigitalisierung ist bekannt.

Im Rahmen des Onlinezugangsgesetzes sollen Verwaltungsleistungen digital verfügbar sein, etwa die Infektionsschutzbelehrung. Dafür existiert theoretisch eine EfA-Leistung („Einer für Alle“), entwickelt in Niedersachsen. Ziel: einheitliche, nachnutzbare Lösungen. Eine Leistungsbeschreibung ist öffentlich einsehbar. In der Praxis setzen viele Kommunen jedoch auf private Anbieter wie das Technologiezentrum Glehn, das nach eigener Darstellung einen erheblichen Marktanteil hat. Die Belehrung wird dort vollständig abgewickelt, Kostenpunkt meist rund zehn Euro pro Vorgang. Das entspricht in manchen Bundesländern einem erheblichen Teil der Gebühr.

Die Identifizierung erfolgt je nach Anbieter über Video-Ident-ähnliche Verfahren oder KI-gestützte Bilderkennung – also biometriebasiert. Die bundeseinheitliche BundID ist als Authentifizierungslösung vorgesehen, wird aber nicht durchgängig genutzt. Die niedersächsische EfA-Lösung wurde zunächst beschafft, später jedoch ohne große Ankündigung eingestellt. Kommunen konnten sie nicht eigenständig weiterführen, da nur vom Land bestimmte Stellen EfA-Leistungen beantragen dürfen. Da die Belehrung OZG-pflichtig ist, blieb vielerorts nur der Weg über private Anbieter.

Weiterlesen nach der Anzeige

Ursachen sind komplexe föderale Strukturen, bürokratische Verfahren, fehlende IT-Fachkräfte und politische Prioritätenwechsel. Ergebnis: Eine öffentliche, einheitliche Lösung existiert – setzt sich aber nicht durch. Beschaffungswege sind unübersichtlich, Entscheidungen auf Landesebene können alle Kommunen ausschließen. So entsteht keine nachhaltige digitale Souveränität.

Auf Landesebene gab es Bestrebungen zur Vereinheitlichung von Fachanwendungen, etwa durch ÖG-Digital und später GA-Lotse. Während ÖG-Digital wenig überzeugte, wirkte GA-Lotse als offene, moderne und technisch durchdachte Lösung vielversprechend.

In einem landesweiten Austausch zur Präferenz wurde die Diskussion aus meiner Sicht stark moderiert. Pro- und Contra-Listen zeichneten ein verzerrtes Bild. Am Ende blieb alles beim Alten: Die Ämter nutzen weiter ihre bestehenden Systeme. Hinzu kommt das Timing: Die Initiative startete faktisch erst im letzten Förderjahr. Zuvor waren bestehende Systeme mit Fördermitteln ausgebaut worden. Ein sofortiger Wechsel hätte diese Investitionen entwertet – intern wie gegenüber Steuerzahlern schwer vermittelbar.

Unser Amt nutzt OctoWareTN. Ich war offen für GA-Lotse, auch aus Gründen digitaler Souveränität. Doch die Vorteile offener Lösungen wurden kaum vermittelt. Stattdessen stand oft das Interesse an standardisierter Datenlieferung im Vordergrund. Die Umstellungsarbeit hätten die Ämter getragen – ohne klaren Mehrwert.

Unabhängig vom System zeigt sich ein Grundproblem: Fachanwendungen werden häufig nur als Datenbank genutzt, wie eine komplexe Excel-Tabelle. Funktionen wie automatisierte Dokumentenerstellung bleiben ungenutzt oder unbekannt. Prozessänderungen stoßen auf Widerstand, ein Dokumentenmanagementsystem gilt als Zumutung. Oft fehlen Zeit und Know-how, sodass Systeme stagnieren und als „digitale Papierakte“ dienen.

Strukturiertes Projektmanagement war in vielen Ämtern historisch nicht nötig. Kleinere IT-Projekte konnten improvisiert werden. Mit Fördermitteln in sechsstelliger Höhe funktioniert das nicht mehr. Es fehlt an langfristiger Planung, klaren Meilensteinen und Erfolgsmessung. Prioritäten wechseln nach Dringlichkeit, am Ende hat alles Priorität.

Die Projektverantwortlichen haben meist weitere Aufgaben, spezialisierte IT-Fachkräfte sind rar. Neue IT-Stellen – etwa nach E9c – bleiben oft unbesetzt. Die Betreuung der Fachanwendungen landet bei Personen, die „halt Computer können“. Zeit und Expertise für echte Weiterentwicklung fehlen.

Kurz: Es mangelt an Personal und Know-how, um Projekte dieser Größenordnung wirksam umzusetzen. Zusätzliche Abstimmungsebenen erhöhen die Trägheit.

Verwaltungshandeln braucht Rechtsgrundlagen, meist auf Landesebene. Das führt zu einem Flickenteppich. Beim Totenschein werden die Stammdaten beispielsweise zunächst im Standesamt erfasst, später im Gesundheitsamt erneut – inklusive fehleranfälliger Übertragungen. Technisch wäre eine digitale Schnittstelle möglich. In manchen Bundesländern existiert die Rechtsgrundlage dafür, in anderen nicht. Sinnvolle Arbeitserleichterungen scheitern so an fehlender Gesetzesgrundlage. Änderungen sind nicht absehbar.

Der Projekterfolg wird über ein Reifegradmodell gemessen, mit Kriterien wie Bürgerzentrierung, Interoperabilität und IT-Sicherheit. Es gibt mehrere Stufen, Mindestziele wurden definiert. Die Ämter melden regelmäßig ihren Stand. Da bei Nichterreichen Rückzahlungen drohen, entsteht ein Anreiz zur wohlwollenden Auslegung. Klare, einheitliche Kriterien fehlen, Interpretationen unterscheiden sich. Nicht jedes Amt wird vertieft geprüft. Das schwächt die Aussagekraft der Metrik erheblich.

Nach mehreren Jahren Digitalisierungspakt bleibt der Eindruck: Die Prozesse sind vielerorts wie zuvor – nur mit besserer Hardware. Das Digitalisierungsvorhaben ist mit den aktuellen Strukturen im Öffentlichen Gesundheitsdienst einfach nicht machbar. Es gibt viele Problemgebiete, bei welchen der ÖGD teilweise nicht selbst aktiv werden kann, deren Ursprung auf Ebene der föderalen Verwaltung liegen. In vielen verschiedenen Strukturen wird zu viel Manpower hineingesteckt, ohne echte Ergebnisse.

Und das ist tragisch: Noch ist die Corona-Pandemie in Erinnerung, doch sobald weitere Jahre vergehen, gerät auch der Öffentliche Gesundheitsdienst wieder in Vergessenheit. Der beste Zeitpunkt für umfangreiche Reformen und Modernisierungen wäre jetzt gewesen, denn die nächste Pandemie wird irgendwann kommen. Es wäre schön, darauf vorbereitet zu sein. Stattdessen wird es offenbar wieder Lösungen wie die Luca-App geben. Hach, wie schön das damals mit der Luca-App war.


(mack)



Source link

Künstliche Intelligenz

Claude Code geleakt: Milliarden für KI-Sicherheit, null für Softwarehygiene


Es klingt nach dem nächsten großen Skandal: Über 500.000 Zeilen Quellcode von Anthropics CLI-Tool Claude Code tauchen öffentlich auf. Die Security-Community horcht auf, Wettbewerber reiben sich die Hände, Kommentatoren wittern den nächsten Beweis, dass KI eh an allem schuld ist. Doch wer genauer hinschaut, findet keine ausgeklügelte Attacke, keinen Zero-Day-Exploit, nicht einmal Social Engineering. Sondern schlicht eine Source Map im npm-Paket, die da nicht hingehörte. Also bloß ein vergessener Schalter in der Build-Pipeline. System scheint hier nur die Schludrigkeit zu haben.

Weiterlesen nach der Anzeige


Ein Kommentar von Moritz Förster

Ein Kommentar von Moritz Förster

Moritz Förster schreibt seit 2012 für die iX und heise online. Er betreut neben dem iX-Channel den Bereich Arbeitsplatz.

Source Maps sind nützliche Helfer in der Entwicklung. Sie bilden kompilierten Code zurück auf den lesbaren Quelltext – unverzichtbar beim Debuggen, fatal in der Produktion. Dass sie im fertigen Paket landen, passiert nicht durch einen raffinierten Angriff oder eine ausgerastete KI. Es passiert, weil niemand den Build-Prozess sauber konfiguriert hat. Oder weil die Konfiguration irgendwann still und leise überschrieben wurde. Oder weil schlicht niemand nachgeschaut hat.

Entwickler kennen das Muster. Es ist die vergessene .env-Datei im Git-Repository. Das Docker-Image mit eingebetteten Credentials. Die Debug-API, die seit Monaten offensteht, weil sie ja „nur intern“ ist. Genau das ist Prozessversagen.

Moderne Build-Pipelines sind überaus komplex. Bundler, Transpiler, Minifier, Packager – jeder Schritt erzeugt Artefakte, jeder Schritt kann Dinge durchreichen, die nicht nach draußen gehören. Die Verantwortung dafür verteilt sich auf ein Tohuwabohu an Tools, Konfigurationsdateien und Teams. Am Ende fühlt sich niemand zuständig. „Die Pipeline macht das schon“ ist aktuell einer der gefährlichsten Sätze in der Softwareentwicklung.

Weiterlesen nach der Anzeige

Bei klassischen Projekten geht das meistens noch gut. Die Artefakte sind langweilig, der Schaden überschaubar. Bei einem KI-Tool wie Claude Code sieht das anders aus. Hier stecken im Code nicht nur Implementierungsdetails, sondern Architekturentscheidungen, Feature-Flags für unveröffentlichte Funktionen und die komplette Orchestrierungslogik eines agentischen Systems. Wer das lesen kann – und das kann jeder mit npm und etwas Geduld –, bekommt eine Blaupause frei Haus.

KI-Unternehmen stehen unter enormem Innovationsdruck. Releases folgen in kurzen Zyklen, Features müssen raus, bevor der Wettbewerber sie zeigt. In diesem Tempo bleiben Sicherheits-Gates auf der Strecke. Nicht aus Schlampigkeit oder gar Böswilligkeit, sondern aus Pragmatismus. Die nächste Demo zählt mehr als das nächste Audit.

Das Ergebnis: Tools, die tief in lokale Entwicklungsumgebungen eingreifen, Code lesen, schreiben und ausführen, werden mit derselben Release-Disziplin behandelt wie ein Frontend-Widget. Dass das schiefgeht, ist keine Überraschung. Es ist nur eine Frage der Zeit.

Der aktuelle Vorfall wirkt nicht wie ein völlig isolierter Ausrutscher: Medienberichten zufolge ist es bereits die zweite unbeabsichtigte Offenlegung rund um Claude Code in etwas mehr als einem Jahr. Ganz allgemein kennt die Branche das Problem schon lange. OWASP listet „Cryptographic Failures“ (vormals Sensitive Data Exposure) seit Ewigkeiten in den Top Ten. Trotzdem passiert es immer wieder – nur dass die Konsequenzen wachsen.

Denn ein geleakter Quellcode ist hier mehr als ein PR-Problem. Er zeigt Wettbewerbern, wie Anthropic agentische Workflows orchestriert. Er zeigt Angreifern, wo die Logik Annahmen macht, die man ausnutzen kann. Er zeigt der Öffentlichkeit, dass ein Unternehmen, das Milliarden für KI-Sicherheit einwirbt, bei grundlegender Softwarehygiene patzt.

Der Reflex nach solchen Vorfällen ist vorhersehbar: mehr Security-Tools, mehr Monitoring, mehr Abwehr nach außen. Aber gegen was genau? Hier gab es keinen Angreifer, den man hätte aufhalten können. Keine Firewall der Welt schützt vor einem falsch konfigurierten Build-Skript.

Was helfen würde, ist weniger spektakulär: automatisierte Prüfungen, die vor jedem Release den Paketinhalt scannen. Klare Verantwortlichkeiten im Build-Prozess. Vier-Augen-Prinzip bei Releases sensibler Tools. Alles Dinge, die in der klassischen Softwareentwicklung längst Standard sein sollten – und die offenbar auch bei einem der bestfinanzierten KI-Unternehmen der Welt nicht zuverlässig greifen.

Und genau weil der eigentlich etablierte Prozess das Problem ist, sollte dieser Vorfall mehr beunruhigen als ein aufsehenerregender KI-Hack. Gegen die in der IT-Branche an vielen Stellen vorherrschende Nachlässigkeit hilft nur Disziplin – und die lässt sich bekanntlich schlecht skalieren.


(fo)



Source link

Weiterlesen

Künstliche Intelligenz

Last Call: OpenAI Codex – Coding-Agenten in VS Code, Terminal und CI/CD


OpenAI bietet mit Codex ein eigenes KI-Coding-Tool an. Die Agenten-Plattform unterstützt Entwicklerinnen und Entwickler dabei, ihre Entwicklungsprozesse zu beschleunigen und zu automatisieren. Unser KI-Coding-Experte Rainer Stropek zeigt, wie man Codex in VS Code, im Terminal, im Web, über SDKs und in der OpenAI Agent Platform produktiv nutzt. Unser Classroom OpenAI Codex für Entwickler – Coding-Agenten in VS Code, Terminal und CI/CD geht dabei auf die neuesten Entwicklungen ein. Erst kürzlich veröffentlichte OpenAI die Version 5.3, die wieder zahlreiche Neuerungen bringt und die unser Experte detailliert behandelt.

Weiterlesen nach der Anzeige

Zunächst steht der Unterschied zwischen ChatGPT und Codex im Vordergrund sowie welches Modell sich für welche Aufgabe am besten eignet. Darauf aufbauend lernen Teilnehmende typische Pair-Programming-Workflows und Spec-driven Development mit TypeScript-Projekten kennen. Anschließend geht es ins Terminal mit Slash-Commands, Terminal User Interface (TUI) vs. Headless-Modus, Konfiguration, AGENTS.md und Best Practices für sichere Änderungen an der Codebasis.

Danach steht Codex im Web im Fokus. Teilnehmende delegieren Aufgaben an Codex Cloud, integrieren Codex in GitHub-Workflows und nutzen Codex für Code Reviews. Darüber hinaus bauen sie anhand eines praktischen Beispiels in TypeScript ein Multi-Agentensystem mit dem Open Source OpenAI Agent SDK und vertiefen ihr Wissen über die Programmierschnittstellen Codex SDK und Model Context Protocol (MCP). Rainer Stropek zeigt, wie man Entwicklungsprozesse automatisiert und Codex mit MCP-Servern sowie -Clients verbindet.

Abschließend ordnet unser Experte Codex in die OpenAI Agent Platform ein: AgentKit, ChatKit, Agents SDK und Apps SDK. Er zeigt, wie man aus einem Codex-basierten Coding-Agenten eine Multi-Agenten-Lösung macht, auf die man über Web-UIs (ChatKit) und ChatGPT-Apps zugreift. Alle Sessions bieten zahlreiche Beispiele, praxisnahe Workflows und setzen einen Fokus auf Teams, die Codex oft über ihre ChatGPT-Subscription zur Verfügung haben. Die Termine sind:

  • 22.04.26: Programmieren mit OpenAI Codex in Visual Studio Code
  • 29.04.26: Codex im Terminal – Codex CLI in der Praxis
  • 06.05.26: Codex Cloud und GitHub-Integration – Aufbau von Multi-Agentensystemen
  • 13.05.26: Codex SDK und Model Context Protocol – Automatisierung von Entwicklungsprozessen
  • 20.05.26: Codex in der OpenAI Agent Platform – KI-Agenten mit Web-UI und ChatGPT-Integration erstellen




Bereits ab dem zweiten Classroom oder einem Classroom und drei Videokursen rechnet sich unser Professional Pass mit Zugriff auf den gesamten heise academy Campus!

Jetzt entdecken

Weiterlesen nach der Anzeige

Die Sessions haben eine Laufzeit von jeweils vier Stunden und finden von 9 bis 13 Uhr statt. Alle Teilnehmenden können sich nicht nur auf viel Praxis und Interaktion freuen, sondern haben auch die Möglichkeit, das Gelernte mit allen Aufzeichnungen und Materialien im Nachgang zu wiederholen und zu vertiefen. Fragen werden direkt im Live-Chat beantwortet und Teilnehmende können sich ebenfalls untereinander zum Thema austauschen. Der nachträgliche Zugang zu den Videos und Übungsmaterialien ist inklusive.

Weitere Informationen und Tickets finden Interessierte auf der Website des Classrooms.

E-Mail-Adresse

Ausführliche Informationen zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten erhalten Sie in unserer Datenschutzerklärung.


(cbo)



Source link

Weiterlesen

Künstliche Intelligenz

Multi-Agenten-Systeme: Wie dezentrale KI komplexe Aufgaben löst


Die Natur macht es vor: Ein Schwarm aus tausenden Vögeln ändert gleichzeitig die Richtung, um Räuber zu verwirren – ohne Anführer, ohne sichtbares Kommando. Und wo eine einzelne Termite nichts ausrichten kann, errichten Millionen von ihnen ohne Bauplan und ohne zentrale Steuerung meterhohe Bauwerke aus Erde und Speichel. Die einzelnen Vögel und Termiten folgen nur einfachen lokalen Regeln. Im Zusammenspiel entstehen aber koordinierte Bewegungen und kollektive Entscheidungen. Was die Natur vormacht, wird nun zum Vorbild technischer Systeme.

Immer größere KI-Modelle stoßen an Grenzen bei Kosten, Robustheit und Anpassungsfähigkeit. Statt komplexe Aufgaben in Unteraufgaben zu zerlegen und diese linear abzuarbeiten, denken Programmierer immer häufiger in Netzwerken aus autonomen Akteuren – sogenannten Agenten. Jeder Agent verfolgt eigene Ziele, reagiert auf seine Umgebung und trifft Entscheidungen. Erst aus ihrem Zusammenspiel entsteht die Lösung eines Problems.

  • Dezentrale KI-Architekturen organisieren Aufgaben nicht mehr zentral, sondern über viele autonome Agenten mit eigenen Rollen und Zielen.
  • Der Artikel zeigt anhand von Sozialsimulationen, LLM-Systemen und Robotik, wie solche Systeme aufgebaut und eingesetzt werden.
  • Daraus wird sichtbar, in welchen Szenarien Kooperation Vorteile bringt – und wo Koordination zur eigentlichen Herausforderung wird.

Die dezentrale Herangehensweise hat mehrere Vorteile. Systeme werden robuster, weil der Ausfall einzelner Komponenten nicht gleich das gesamte System lahmlegt. Sie werden anpassungsfähiger, weil Agenten auf Veränderungen reagieren und ihr Verhalten in Echtzeit korrigieren können. Und sie lassen sich leicht skalieren: Wird ein Problem komplexer, können mehr Agenten hinzugefügt werden, ohne eine zentrale Steuerung zu überfordern. Welche dieser Vorteile in der Praxis tragen und wo neue Probleme entstehen, zeigt ein Blick auf konkrete Anwendungen.


Das war die Leseprobe unseres heise-Plus-Artikels „Multi-Agenten-Systeme: Wie dezentrale KI komplexe Aufgaben löst“.
Mit einem heise-Plus-Abo können Sie den ganzen Artikel lesen.



Source link

Weiterlesen

Beliebt