Open-Source-KI in der öffentlichen Verwaltung — Bürgerdienste und Datenschutz

Open-Source-KI ist für Behörden vor allem dann sinnvoll, wenn Datensouveränität, Nachvollziehbarkeit und kontrollierter Betrieb wichtiger sind als die schnellste SaaS-Einführung. Für die öffentliche Verwaltung entscheidet nicht das Schlagwort "open", sondern der konkrete Einsatzfall nach der EU-VO 2024/1689.

Letzte Aktualisierung: 23. März 2026

Für Kommunen, Landesbehörden und Bundesstellen ist die Reihenfolge klar: zuerst Use Case klassifizieren, dann Betriebsmodell festlegen, dann Beschaffung und Schulung aufsetzen. Wenn Sie die Grundlagen für Teams sortieren wollen, lesen Sie ergänzend unseren Beitrag zur KI-Schulung im öffentlichen Dienst, die Einordnung zu Artikel 4 und die häufigsten Praxisfragen in der FAQ.

Sozialleistungen sind Hochrisiko

KI in Sozialleistungen ist nach Anhang III Nr. 5 Buchst. a regelmäßig Hochrisiko, wenn eine Behörde damit Anspruch, Bewilligung, Kürzung, Rückforderung oder Priorisierung wesentlicher öffentlicher Leistungen bewertet. Das betrifft nicht nur Vollautomatisierung, sondern auch Entscheidungsvorbereitung mit erkennbarem Einfluss auf Bürgerrechte.

Typische Fälle sind Systeme für Bürgergeld, Wohngeld, BAföG, Sozialhilfe, Pflegeunterstützung oder kommunale Unterstützungsleistungen. Maßgeblich ist, ob der Output den Zugang zu einer wesentlichen öffentlichen Leistung beeinflusst oder ob Sachbearbeiter faktisch auf Scores, Warnhinweise oder Risikoklassen vertrauen.

| Verwaltungsvorgang | AI-Act-Einordnung | Warum kritisch | | --- | --- | --- | | Prüfung von Bürgergeld-Ansprüchen | Hochrisiko | Zugang zu wesentlicher öffentlicher Leistung | | Priorisierung von Wohngeldfällen | Hochrisiko | Einfluss auf Reihenfolge und Leistungszugang | | Risikobewertung bei Missbrauchsverdacht | Hochrisiko oder verboten, je nach Logik | Profiling und Grundrechtseingriff | | FAQ-Chatbot ohne Einzelfallentscheidung | Meist nicht Hochrisiko | Kein direkter Eingriff in Leistungsbewilligung |

Für Behörden folgt daraus eine einfache Prüfreihenfolge:

1. Dokumentieren Sie, welche Systeme Bürgerdaten verarbeiten oder Leistungsentscheidungen vorbereiten.
2. Prüfen Sie, ob der Use Case unter Anhang III fällt oder sogar in den Bereich verbotener Praktiken rutscht.
3. Trennen Sie Assistenzfunktion, Empfehlung und Entscheidung sauber in der Verfahrensbeschreibung.
4. Legen Sie fest, welche Beschäftigten nach Art. 4 geschult werden müssen.

Wer Sozialleistungsfälle mit Open-Source-KI unterstützen will, darf die Modelloffenheit nicht mit einer regulatorischen Erleichterung verwechseln. Die Open-Source-Ausnahme aus Art. 2 Abs. 12 greift gerade nicht, wenn das System als Hochrisiko-KI in Betrieb genommen wird.

Social Scoring ist verboten

Social Scoring ist nach Art. 5 Abs. 1 Buchst. c verboten, wenn Personen über einen Zeitraum anhand ihres Sozialverhaltens oder abgeleiteter Merkmale bewertet werden und der Score zu sachfremder oder unverhältnismäßiger Benachteiligung führt. Für Behörden ist das besonders relevant, weil Verwaltungsdaten leicht zu umfassenden Verhaltensprofilen zusammengeführt werden können.

Ein verbotener Fall liegt nicht erst bei einem formalen "Bürgerpunktesystem" vor. Problematisch wird es schon, wenn eine Behörde aus Zahlungsverhalten, Kontakten mit Ämtern, Wohnumfeld oder statistischen Gruppenmerkmalen eine Risikoklasse bildet und diese anschließend in anderen Lebensbereichen gegen die betroffene Person verwendet.

Verboten sind insbesondere diese Muster:

1. Ein Sozialamt nutzt frühere Mahnungen, Familienstatus und Wohnviertel, um einen allgemeinen Vertrauensscore zu berechnen.
2. Ein Bürgerportal priorisiert Anträge schlechter, weil eine Person in anderen Verwaltungsverfahren als "auffällig" markiert wurde.
3. Mehrere Fachämter teilen einen Verhaltensscore, der ursprünglich in einem anderen Kontext erzeugt wurde.
4. Ein System benachteiligt Betroffene stärker, als es der konkrete Anlass rechtfertigt.

| Frage | Zulässig? | Begründung | | --- | --- | --- | | Einzelfallprüfung von Anspruchsvoraussetzungen im konkreten Verfahren | Eher ja, wenn rechtskonform und transparent | Kontextbezogene Sachbearbeitung | | Genereller Vertrauensscore für Bürger über mehrere Verfahren | Nein | Social Scoring nach Art. 5 | | Nutzung eines Missbrauchsscores aus Verfahren A für Verfahren B | Regelmäßig nein | Sachfremde Benachteiligung | | KI-gestützte Sortierung rein nach Vollständigkeit von Unterlagen | Möglich, aber prüfbedürftig | Keine Bewertung der Person, sondern des Vorgangs |

Die Bußgeldstufe für verbotene Praktiken liegt nach Art. 99 bei bis zu 35 Mio. EUR oder 7 Prozent des weltweiten Jahresumsatzes. Für öffentliche Stellen ist zusätzlich das politische Risiko hoch, weil Social Scoring unmittelbar Grundrechte, Gleichbehandlung und Verwaltungsvertrauen berührt.

Übergangsfrist bis 2030

Für Behörden gilt eine echte Übergangsfrist nur für bestimmte bereits vor dem 2. August 2026 eingesetzte Hochrisiko-Systeme, und diese Frist endet am 2. August 2030. Neue Hochrisiko-Systeme, die nach dem 2. August 2026 eingeführt werden, müssen grundsätzlich ab Inbetriebnahme compliant sein.

Die oft verkürzt genannte "Frist bis 2030" ist deshalb nur halb richtig. Art. 111 unterscheidet zwischen Bestandsfällen öffentlicher Stellen und neuen Systemen sowie zusätzlich zwischen öffentlichen Hochrisiko-Anwendungen und bestimmten großskaligen EU-IT-Systemen, für die teils der 31. Dezember 2030 genannt wird.

| Stichtag | Was gilt | Für Behörden wichtig | | --- | --- | --- | | 2. Februar 2025 | Art. 4 und Art. 5 gelten | Schulungspflicht und Verbote laufen bereits | | 2. August 2026 | Annex-III-Hochrisiko-Regeln gelten allgemein | Neue Hochrisiko-Systeme müssen ab dann compliant sein | | 2. August 2030 | Übergangsende für bestimmte Bestands-Hochrisiko-Systeme öffentlicher Stellen | Altverfahren brauchen spätestens dann volle Anpassung | | 31. Dezember 2030 | Frist für bestimmte große EU-IT-Systeme nach Anhang X | Nur für spezielle unionsrechtliche Großsysteme relevant |

Behörden sollten die Übergangsfrist nicht als Aufschub für Planung missverstehen. Beschaffung, Datenschutz-Folgenabschätzung, Grundrechte-Folgenabschätzung, Betriebsvereinbarungen, Dokumentation und Schulung brauchen oft 6 bis 18 Monate Vorlauf.

Die praktische Priorisierung sieht so aus:

1. Bestehende KI-Verfahren inventarisieren und nach Inbetriebnahmedatum trennen.
2. Für Altverfahren prüfen, ob sie vor dem 2. August 2026 produktiv waren.
3. Für neue Vorhaben ab 2026 volle AI-Act-Compliance in die Vergabeunterlagen aufnehmen.
4. Budget und Schulung nicht auf 2030 verschieben, sondern in den nächsten Haushaltszyklus ziehen.

Self-Hosting schafft Datensouveränität

Self-Hosting ist für Behörden meist das stärkste Betriebsmodell, wenn personenbezogene Daten, Verwaltungsgeheimnisse oder sensible Fachverfahren verarbeitet werden. Der Vorteil liegt nicht nur in der DSGVO, sondern in vollständiger Kontrolle über Infrastruktur, Logging, Aufbewahrung, Netzsegmentierung und Zugriff.

Open-Source- oder Open-Weight-Modelle können in einer kommunalen Private Cloud, im Landesrechenzentrum oder on-premises betrieben werden. Dadurch bleiben Prompts, RAG-Datenbanken, Protokolle und Ausgaben im eigenen Verantwortungsbereich, statt in externen US- oder Drittanbieter-Plattformen zu landen.

| Betriebsmodell | Datensouveränität | Beschaffungsaufwand | Typischer Behörden-Fit | | --- | --- | --- | --- | | Öffentliche API eines Fremdanbieters | Niedrig bis mittel | Niedrig | Nur für unkritische Inhalte vertretbar | | EU-Hosting beim Anbieter | Mittel | Mittel | Für moderate Schutzbedarfe möglich | | Private Cloud im öffentlichen Rechenzentrum | Hoch | Mittel bis hoch | Sehr gut für Fachverfahren | | On-Premises / Self-Hosting | Sehr hoch | Hoch | Ideal für sensible Daten und strenge Governance |

Self-Hosting löst allerdings nicht jedes Problem automatisch. Behörden müssen zusätzlich Betriebssicherheit, Patch-Management, Rollenrechte, Protokollierung, Missbrauchsschutz und Fachverfahrensgrenzen definieren.

Für die Architekturentscheidung sind vier Fragen zentral:

1. Dürfen Bürgerdaten oder interne Vermerke das eigene Netz überhaupt verlassen?
2. Reicht ein EU-Cloud-Betrieb aus, oder verlangt der Schutzbedarf vollständige Eigenkontrolle?
3. Welche Stelle verantwortet Logging, Löschung und Zugriffsrechte?
4. Wie werden Fachbereiche geschult, damit sensible Inhalte nicht in unzulässige Testumgebungen wandern?

Wenn Sie diese Punkte intern vereinheitlichen wollen, ist eine gemeinsame Mindestlinie für Nutzung und Freigabe wichtiger als der Modellname. Genau dafür lohnt sich eine klare Schulungs- und Richtlinienlogik nach Artikel 4.

EU-Modelle bevorzugen: Mistral und Aleph Alpha

Für Behörden sind europäische Modelle oft die bessere Ausgangsbasis, weil Souveränität, europäische Infrastruktur und öffentliche Beschaffbarkeit leichter vermittelbar sind. Das bedeutet nicht automatisch höhere Rechtskonformität, aber meist weniger geopolitische und datenschutzrechtliche Reibung.

Mistral veröffentlicht laut eigener Dokumentation mehrere Modelle unter Apache 2.0 und bietet Self-Hosting sowie EU-gehostete Optionen an. Aleph Alpha positioniert seine Lösungen ausdrücklich für souveräne Einsätze in öffentlichem Sektor und kritischen Umgebungen auf europäischer Infrastruktur.

| Modellanbieter | Vorteil für Behörden | Prüffrage vor Beschaffung | | --- | --- | --- | | Mistral | Offene Modelle, Self-Hosting, EU-Serveroptionen | Welche Lizenz gilt für das konkrete Modell? | | Aleph Alpha | Deutscher Anbieterfokus, souveräne Infrastruktur, Public-Sector-Narrativ | Passt das Modell zu Fachsprache und Verwaltungsvorgängen? | | US-SaaS-Anbieter | Schneller Start, oft starke Produktreife | Reichen DPA, Datenlokation und Kontrolltiefe aus? |

Die Modellwahl sollte nach diesen Kriterien erfolgen:

1. Lizenz und tatsächliche Nutzungsrechte für Behördenbetrieb prüfen.
2. Deployment-Optionen für Rechenzentrum, Private Cloud oder abgeschirmte Umgebung vergleichen.
3. Deutschsprachige Verwaltungsfälle, Aktenstil und Formularsprache testen.
4. Sicherheits- und Audit-Anforderungen mit Datenschutz und IT abstimmen.

Eine sachgerechte Inferenz aus den verfügbaren Herstellerinformationen lautet: Mistral ist für offene, selbst gehostete Verwaltungsarchitekturen besonders interessant, während Aleph Alpha dort stark ist, wo souveräne europäische Infrastruktur und enger Public-Sector-Fit im Vordergrund stehen. Beide Optionen sind für Behörden meist näher an Datensouveränität als ein rein US-zentriertes Standard-SaaS.

Beschaffungsleitfaden für Behörden

Behörden sollten Open-Source-KI nicht als Experiment beschaffen, sondern als reguliertes Digitalvorhaben mit Vergabe-, Datenschutz- und Fachverfahrenslogik. Der schnellste Fehler ist, zuerst einen Piloten zu starten und erst später zu prüfen, ob Hochrisiko, Social Scoring, Datenschutz oder Betriebsrat betroffen sind.

Ein belastbarer Beschaffungsleitfaden beginnt mit der Klassifizierung des Use Cases und endet erst mit dokumentiertem Betrieb. Gerade bei Bürgerdiensten muss jede Vergabeakte zeigen, warum das gewählte Betriebsmodell fachlich, datenschutzrechtlich und organisatorisch tragfähig ist.

Empfohlene Reihenfolge für die Praxis:

1. Use Case beschreiben: Was soll das System entscheiden, vorbereiten oder automatisieren?
2. Rechtslage prüfen: Fällt der Fall unter Art. 5, Anhang III, Art. 26 oder Art. 27?
3. Betriebsmodell festlegen: API, EU-Hosting, Rechenzentrum oder Self-Hosting.
4. Beschaffungsunterlagen ergänzen: AV-Vertrag, TOMs, Logging, Exit-Szenario, Support, Audit-Rechte.
5. Pilot nur mit klaren Schutzgrenzen starten: keine Echtfälle ohne Freigabe- und Eskalationskonzept.
6. Mitarbeitende schulen und Nachweis ablegen: Rollenbezogen, dokumentiert und mit intern verwertbarem Zertifikat.

| Beschaffungsschritt | Mindestanforderung | Typischer Fehler | | --- | --- | --- | | Bedarfserhebung | Fachverfahren und Rechtsgrundlage benennen | "Wir testen erst einmal irgendwas mit KI" | | Risikoklassifizierung | Art. 5, Anhang III, Art. 26, Art. 27 prüfen | Nur Datenschutz prüfen, AI Act vergessen | | Vergabe | Leistungsbeschreibung mit Compliance-Kriterien | Nur Preis und Funktion bewerten | | Pilotbetrieb | Schutzgrenzen, Logs, Freigaben, Rollback | Produktivdaten ohne Governance nutzen | | Rollout | Schulung, Verantwortlichkeiten, Nachweise | Tool live schalten ohne Teamkompetenz |

Wenn Sie die KI-Kompetenzpflicht nach Artikel 4 für Ihre Behörde oder Organisation strukturiert umsetzen wollen, finden Sie im EU AI Act Online-Kurs einen kompakten Einstieg mit Schulungszertifikat.

Der operative Schluss ist klar: Open-Source-KI passt zur Verwaltung, wenn Beschaffung und Governance gemeinsam gedacht werden. Wenn Ihre Behörde zuerst eine belastbare Baseline für Schulung, Rollen und Nachweise braucht, ist unser Beitrag zur KI-Schulung im öffentlichen Dienst der beste Einstieg; für die allgemeine Pflichtlogik helfen Artikel 4 und die FAQ.