Öffentliche Hand ist keine eigene Risikoklasse
Dass Bund, Land, Gemeinde, Hochschule oder öffentliches Unternehmen ein KI-System einsetzt, macht es nicht automatisch hochriskant. Die Einordnung folgt Artikel 6, Anhang I und den konkreten Verwendungszwecken des Anhangs III. Relevant können etwa Zugang zu wesentlichen öffentlichen Leistungen, Strafverfolgung, Migration, Justiz und bestimmte biometrische Anwendungen sein. Interne Wissenssuche, Aktenzusammenfassung, Übersetzung oder Terminorganisation fällt nicht allein wegen des behördlichen Umfelds in diese Kategorie.
Die Bewertung muss jede Funktion separat erfassen. Ein Portal kann eine allgemeine Chatfunktion, ein Modul zur Dokumentenklassifikation und eine Entscheidungshilfe für Leistungen enthalten. Nur eine Gesamtbezeichnung wie Verwaltungsassistent verschleiert den tatsächlichen Einfluss. Zu dokumentieren sind Zweck, betroffene Personen, Daten, Entscheidungsschritt, menschliche Kontrolle und mögliche Nachteile. Auch bei nicht hochriskanten Funktionen bleiben Verbote, Transparenzpflichten, Datenschutz, gesetzliche Verschwiegenheits- und Geheimhaltungspflichten, Informationsfreiheitsrecht, Barrierefreiheit und Verfahrensrecht relevant.
- Funktionen statt Gesamtplattformen klassifizieren.
- Entscheidungseinfluss und betroffene Rechte erfassen.
- Nicht hochriskante Anwendungen fachrechtlich weiterprüfen.
Rollen folgen der tatsächlichen Bereitstellung
Bei eingekaufter Standardsoftware ist die Behörde regelmäßig Betreiberin. Entwickelt sie ein System selbst oder lässt es unter ihrem Namen bereitstellen, kann sie Anbieterin werden. Zweckänderung oder wesentliche Änderung kann ebenfalls einen Rollenwechsel auslösen. GovTech-Anbieter, Integrator und öffentlicher Auftraggeber dürfen diese Einordnung nicht allein durch Vertragsklauseln festlegen. Entscheidend sind tatsächliche Entwicklung, Bereitstellung, Name, Zweck und Änderungen im Lebenszyklus.
Vor dem Vergabeverfahren sollte ein Rollen- und Verantwortungsmodell feststehen. Es muss Verantwortliche für Fachzweck, Daten, technische Integration, Sicherheit, Recht, Betrieb und menschliche Entscheidungen benennen. Verträge sollten Informationen und Mitwirkung für Klassifikation, Registrierung, Prüfung und Vorfälle sichern. Bleiben Modellanbieter oder Unterauftragnehmer intransparent, kann die Behörde ihre eigenen Pflichten schwer erfüllen. Anbieterangaben sind daher zu plausibilisieren und dürfen nicht ohne Nachweise zur alleinigen Grundlage einer Freigabe werden.
- Rolle je Projektphase und Version bestimmen.
- Zweckänderung und wesentliche Änderung genehmigungspflichtig machen.
- Unterauftragnehmer und Modelllieferanten transparent regeln.
Grundrechte-Folgenabschätzung vor dem Einsatz
Artikel 27 verpflichtet Betreiber, die Einrichtungen des öffentlichen Rechts sind, vor dem erstmaligen Einsatz eines Hochrisikosystems grundsätzlich zu einer Grundrechte-Folgenabschätzung; erfasst sind außerdem private Einrichtungen, die öffentliche Dienste erbringen, sowie Betreiber der in Anhang III Nummer 5 Buchstaben b und c genannten Systeme. Die Bewertung soll unter anderem Einsatzprozess, Dauer, betroffene Personengruppen, spezifische Schadensrisiken, menschliche Aufsicht und Abhilfemaßnahmen erfassen. Sie ist kein bloßes Formular, sondern muss die konkrete Verwaltungspraxis und tatsächliche Wirkung des Systems abbilden.
Eine Datenschutz-Folgenabschätzung nach der DSGVO kann auf denselben Fakten aufbauen, ist aber nicht identisch. Datenschutzrisiken sind nur ein Teil möglicher Grundrechtsfolgen. Zusätzlich können Gleichbehandlung, soziale Rechte, wirksamer Rechtsschutz, Barrierefreiheit und Verfahrensgarantien betroffen sein. Doppelarbeit lässt sich durch einen gemeinsamen Sachverhaltsteil und abgestimmte Maßnahmen reduzieren. Ergebnis, Zuständigkeit und gesetzliche Schlussfolgerungen sollten dennoch getrennt erkennbar bleiben und bei wesentlichen Änderungen aktualisiert werden.
- Folgenabschätzung vor erstmaligem Einsatz terminieren.
- Betroffene Gruppen und konkrete Nachteile einbeziehen.
- DSGVO- und Grundrechteprüfung koordiniert dokumentieren.
Verwaltungsentscheidung bleibt menschlich verantwortet
Ein Modelloutput darf die rechtlich verantwortete Verwaltungsentscheidung nicht ersetzen, wenn das einschlägige Verfahrensrecht eine behördliche Ermittlung, Würdigung, Begründung oder Anhörung verlangt. Die zuständige Person muss Zweck, Grenzen und relevante Eingaben verstehen, das Ergebnis prüfen und bei Bedarf abweichen können. Eine formale Bestätigung per Klick genügt nicht, wenn Zeit, Information oder Befugnis für echte Kontrolle fehlen. Automatisierungsbias und massenhafte Standardisierung sind als Betriebsrisiken einzuplanen.
Nach österreichischem Verwaltungsverfahrensrecht sind je nach Verfahren insbesondere Ermittlungsgrundsatz, Parteiengehör, Begründung, Akteneinsicht und Rechtsmittel zu beachten. Das Systemdesign sollte daher Quellen, Entscheidungsschritte, Korrekturen und menschliche Verantwortlichkeit nachvollziehbar machen, soweit dies rechtlich zulässig und erforderlich ist. Betroffene brauchen verständliche Kontakt- und Anfechtungswege. Der AI Act verdrängt diese Garantien nicht; seine Pflichten treten zu bestehenden Verfahrens- und Datenschutzanforderungen hinzu.
- Human Override mit Zeit, Information und Befugnis ausstatten.
- Begründung und Akteneinsicht technisch ermöglichen.
- Korrektur- und Rechtsmittelwege verständlich gestalten.
Vergabeunterlagen müssen den Use Case steuern
Leistungsbeschreibungen sollten den zulässigen Zweck, ausgeschlossene Nutzungen und Systemgrenzen präzise festlegen. Erforderlich sind Angaben zu Datenherkunft, Genauigkeitsgrenzen, Robustheit, Protokollen, Barrierefreiheit, menschlicher Aufsicht, Sicherheitsupdates, Modellversionen und bekannten Fehlermodi. Audit-, Mitwirkungs- und Exit-Rechte müssen praktisch nutzbar sein. Eine allgemeine Zusicherung des Lieferanten ersetzt keine konkreten Nachweise und keine eigene Bewertung des öffentlichen Auftraggebers.
Änderungsmanagement gehört bereits in den Vertrag. Der Anbieter sollte Modellwechsel, neue Datenquellen, geänderte Unterauftragnehmer, Funktionsausweitungen und wesentliche Sicherheitsereignisse rechtzeitig melden. Die Behörde braucht das Recht, Tests zu verlangen, Funktionen auszusetzen und Daten in einem verwendbaren Format zu exportieren. Abnahmekriterien sollten repräsentative Gruppen, Barrierefreiheit und fehlerkritische Fälle erfassen. Vergaberechtliche Gleichbehandlung und Transparenz sind dabei ebenso zu beachten wie Schutz vertraulicher technischer Informationen.
- Zweck und verbotene Nutzungen verbindlich definieren.
- Audit, Änderung, Suspendierung und Exit vertraglich regeln.
- Abnahme mit realistischen und grundrechtssensiblen Fällen testen.
Übergangsfristen und Behördenlage offen ausweisen
Rechtsstand 16. September 2026: Allgemeine Regeln wie Artikel 4 und einschlägige Transparenzpflichten sind anwendbar. Für Hochrisikosysteme nach Artikel 6 Absatz 2 und Anhang III gelten die Anforderungen aus Kapitel III Abschnitte 1 bis 3 ab 2. Dezember 2027. Für bestimmte bestehende Hochrisikosysteme öffentlicher Stellen nennt Artikel 111 Absatz 2 eine Frist bis 2. August 2030. Ob ein konkretes Altsystem darunter fällt, ist anhand Inverkehrbringen, Inbetriebnahme und Änderungen gesondert zu prüfen.
Die RTR-GmbH ist gesetzlich als KI-Servicestelle mit Informations-, Beratungs- und Koordinierungsaufgaben eingerichtet. Daraus allein folgt keine allgemeine Marktüberwachungs-, Notifizierungs-, Beschwerde- oder Bußgeldzuständigkeit. Welche österreichische oder unionsrechtliche Stelle im Einzelfall zuständig ist, muss anhand aktueller Durchführungsvorschriften, Kommissionslisten und sektorspezifischer Regeln geprüft werden. Beschaffungsroadmaps sollten diese Zuständigkeitsprüfung sichtbar führen, statt vorschnell eine Universalbehörde festzuschreiben.
- 2. Dezember 2027 und mögliche Altfrist 2030 trennen.
- Bestehende Systeme auf Übergangsbedingungen prüfen.
- Österreichische Zuständigkeiten vor jedem Vollzugsschritt neu verifizieren.
Entscheidungsbox: Verwaltungs-KI beschaffen?
- Welcher konkrete Verwaltungszweck und Entscheidungsschritt ist betroffen?
- Ist die Behörde Betreiberin oder übernimmt sie durch Entwicklung und Änderung Anbieterpflichten?
- Sind Grundrechte- und Datenschutz-Folgenabschätzung erforderlich?
- Bleiben Parteiengehör, Begründung, Akteneinsicht und Rechtsmittel praktisch wirksam?
- Sichert der Vertrag Nachweise, Änderungen, Audit und Exit?
Häufige Fragen
Ist jede KI einer Behörde hochriskant?
Nein. Die öffentliche Trägerschaft ist keine eigene Risikoklasse. Entscheidend sind Artikel 6, Anhang I und konkrete Zwecke des Anhangs III. Eine interne Zusammenfassung kann anders einzuordnen sein als ein System, das Zugang zu wesentlichen öffentlichen Leistungen oder gerichtliche Entscheidungen beeinflusst.
Muss jede Behörde eine Grundrechte-Folgenabschätzung erstellen?
Nicht für jedes KI-System. Betreibt eine Einrichtung des öffentlichen Rechts jedoch ein Hochrisikosystem, verlangt Artikel 27 vor dem erstmaligen Einsatz grundsätzlich eine Grundrechte-Folgenabschätzung. Anwendungsbereich, mögliche Sonderregeln, Zeitpunkt und Inhalt sind für den konkreten Use Case zu prüfen.
Ist die RTR die allgemeine österreichische Aufsichtsbehörde?
Die RTR KI-Servicestelle hat gesetzliche Informations-, Beratungs- und Koordinierungsaufgaben. Daraus folgt nicht automatisch die Stellung als allgemeine Marktüberwachungs-, notifizierende oder Bußgeldbehörde. Die aktuelle nationale Zuweisung, sektorspezifische Zuständigkeiten und mögliche Zuständigkeiten des AI Office sind für den konkreten Fall zu prüfen.
Primärquellen
- AI Act, konsolidierte Fassung vom 27. Juli 2026
- Verordnung (EU) 2026/1744, Digital Omnibus
- Kommission: Leitlinien zu Hochrisikosystemen
- Datenschutz-Grundverordnung
- Allgemeines Verwaltungsverfahrensgesetz 1991
- RIS: § 194a TKG 2021 – Aufgaben der KI-Servicestelle
Rechtsstand: 16. September 2026. Vor Veröffentlichung sind finale Hochrisikoleitlinien, Übergangsregeln für konkrete Altsysteme, österreichisches Verwaltungs- und Vergaberecht sowie die aktuelle Behörden-, Beschwerde- und Sanktionszuweisung erneut zu prüfen.