Angemessene Informationsgrundlage für KI Entscheidungen der Unternehmensleitung

Den Entscheidungsgegenstand präzise abgrenzen

Eine Entscheidung über ein Produkt ist noch keine hinreichend bestimmte Entscheidung über dessen Nutzung. Dasselbe System kann Texte zusammenfassen, Kundentermine priorisieren oder Bewerbungen bewerten. Die Unternehmensleitung muss deshalb den konkreten Zweck, Nutzerkreis, betroffenen Prozess, Automatisierungsgrad und Entscheidungseinfluss festlegen. Ebenso wichtig sind Anbieter, Modellversion, Schnittstellen, Einsatzort und die Frage, ob Ergebnisse unmittelbar nach außen wirken oder zunächst intern geprüft werden.

Ohne klare Abgrenzung laufen rechtliche und technische Prüfungen ins Leere. Ein Gutachten für eine interne Testumgebung trägt nicht automatisch den späteren Produktivbetrieb mit personenbezogenen Daten. Die Vorlage sollte daher ausdrücklich benennen, was freigegeben werden soll und was nicht Gegenstand des Beschlusses ist. Änderungen des Zwecks, des Modells, der Datenquellen oder des Nutzerkreises sind als mögliche Auslöser einer neuen Entscheidung zu definieren.

• Geschäftszweck und betroffener Prozess
• Nutzer, Betroffene und Entscheidungseinfluss
• Anbieter, System, Modellversion und Schnittstellen
• Explizite Grenzen des beantragten Einsatzes

Quellen: [1] [2]

Rolle, Rechtskategorie und Anwendungsdatum klären

Die Vorlage sollte die Rolle des Unternehmens nach dem AI Act für den konkreten Einsatz bestimmen. Ein Unternehmen kann Betreiber eines fremden Systems sein. Bei Hochrisiko-KI-Systemen können insbesondere das Anbringen des eigenen Namens oder der eigenen Handelsmarke, eine wesentliche Veränderung oder eine so geänderte Zweckbestimmung, dass das System zum Hochrisiko-KI-System wird, nach Art. 25 Anbieterpflichten auslösen. Bei Konzernlösungen ist die Rolle je Gesellschaft zu prüfen. Parallel ist festzustellen, ob eine verbotene Praxis, eine Transparenzpflicht oder eine mögliche Hochrisikoeinstufung nach Art. 6 und Anhang I oder III relevant ist.

Die zeitliche Dimension gehört ausdrücklich in die Informationsgrundlage. Rechtsstand 16. September 2026 gelten die ursprünglichen Verbote bereits, Art. 50 ist grundsätzlich seit 2. August 2026 anwendbar, während die zentralen Hochrisikopflichten für Anhang III grundsätzlich ab 2. Dezember 2027 und für Anhang I ab 2. August 2028 gelten. Eine künftige Spezialpflicht beseitigt weder heutige Anforderungen aus dem AI Act noch aus Datenschutz, Arbeits- oder Produktrecht.

• Wirtschaftsrolle je Einsatz und Gesellschaft
• Verbotsprüfung vor jeder Nutzenabwägung
• Transparenz- und Hochrisikoeinordnung
• Anwendungsdaten und Übergangsregeln getrennt dokumentieren

Quellen: [3] [4]

Daten, Technik und Fehlerfolgen sichtbar machen

Für die technische Sicht reichen Marketingbezeichnungen nicht aus. Erforderlich sind Informationen über Eingaben, Ausgaben, Datenherkunft, Speicherorte, Protokollierung, Zugriffsmöglichkeiten, Modellaktualisierungen und relevante Leistungsgrenzen. Tests sollten den tatsächlichen österreichischen Einsatzkontext abbilden, einschließlich Sprache, Nutzergruppen und möglicher Randfälle. Durchschnittswerte können gravierende Fehler bei kleinen oder besonders schutzbedürftigen Gruppen verdecken und müssen deshalb sinnvoll aufgeschlüsselt werden.

Die Leitung benötigt keine vollständige technische Dokumentation jedes Bauteils, wohl aber ein verständliches Bild der Fehlerfolgen. Kann ein falscher Output vor Veröffentlichung korrigiert werden? Führt er zu einer nachteiligen Personalentscheidung, einem Sicherheitsereignis oder einer diskriminierenden Behandlung? Lassen sich Eingaben oder Ergebnisse nachträglich rekonstruieren? Diese Fragen bestimmen, ob menschliche Kontrolle, Stichproben, Nutzungsbegrenzung oder ein Verzicht erforderlich sind.

• Datenquellen, Speicherorte und Zugriffsrechte
• Leistungsgrenzen und Tests im Einsatzkontext
• Auswirkungen typischer und seltener Fehler
• Protokollierung, Korrektur und technische Abschaltbarkeit

Quellen: [3] [5]

Rechtliche und wirtschaftliche Risiken gemeinsam bewerten

Eine reine Rechtsprüfung beantwortet nicht, ob ein Projekt wirtschaftlich tragfähig ist; eine reine Business-Case-Rechnung erfasst keine Grundrechts- oder Compliance-Risiken. Die Entscheidungsvorlage sollte Nutzenannahmen, Gesamtkosten, Anbieterabhängigkeit, Ausfallrisiken und Integrationsaufwand mit Datenschutz, Geheimnisschutz, Gleichbehandlung, Urheberrecht, Cybersicherheit und sektorspezifischen Anforderungen verbinden. Wechselwirkungen sind entscheidend: Eine kostengünstige Cloudlösung kann durch fehlende Kontroll- oder Exportmöglichkeiten erhebliche Folgekosten verursachen.

Risiken sollten nicht nur abstrakt als niedrig, mittel oder hoch bezeichnet werden. Benötigt werden Szenarien, mögliche Betroffene, Schadensausmaß, Eintrittsbedingungen und vorhandene Kontrollen. Ebenso ist festzuhalten, wer das Restrisiko trägt und welche Annahmen den Business Case stützen. Sind wesentliche Vertragsbedingungen, technische Nachweise oder Behördenauslegungen offen, muss diese Unsicherheit die Entscheidung beeinflussen, statt in einem Anhang zu verschwinden.

• Rechtsgebiete und technische Risiken verknüpfen
• Gesamtkosten einschließlich Kontrolle und Exit bewerten
• Szenarien statt pauschaler Risikofarben beschreiben
• Annahmen und Unsicherheiten dem Organ deutlich vorlegen

Quellen: [1] [2] [5]

Anbieterangaben prüfen und Informationslücken behandeln

Produktblätter, Zertifikate und Vertragszusagen sind wichtige Quellen, dürfen aber nicht ungeprüft als Tatsachen übernommen werden. Zu fragen ist, welcher Systemstand geprüft wurde, für welchen Zweck Aussagen gelten, wer den Test durchgeführt hat und welche Einschränkungen bestehen. Eine allgemeine Erklärung des Anbieters sagt wenig über die konkrete Integration, eigene Datenflüsse oder die tatsächliche Verwendung durch Beschäftigte aus. Kritische Angaben sollten vertraglich abgesichert und praktisch getestet werden.

Fehlende Information ist selbst ein Entscheidungsfaktor. Die Vorlage sollte unterscheiden zwischen Daten, die noch beschafft werden können, Nachweisen, die der Anbieter verweigert, und Unsicherheiten, die technisch nicht vollständig auflösbar sind. Daraus folgen unterschiedliche Maßnahmen: Nachforderung, unabhängige Prüfung, enger Pilot, zusätzliche Kontrolle oder Ablehnung. Eine Lücke wird nicht dadurch unbedeutend, dass ein Projektteam den Starttermin bereits kommuniziert hat.

• Geltungsbereich und Aktualität von Nachweisen prüfen
• Vertragliche Zusagen mit technischen Tests verbinden
• Informationslücken nach Ursache und Bedeutung ordnen
• Startentscheidung an klare Nachlieferungen knüpfen

Quellen: [3] [1]

Alternativen, Verhältnismäßigkeit und Dokumentation

Eine angemessene Grundlage zeigt nicht nur das bevorzugte Projekt, sondern realistische Alternativen. Dazu können manuelle Bearbeitung, ein weniger autonomes System, ein kleinerer Nutzerkreis, Datenminimierung, zusätzliche menschliche Prüfung, ein anderer Lieferant oder ein zeitlich begrenzter Pilot gehören. Die Auswahl sollte Nutzen, Kosten, Rechtmäßigkeit, Kontrollierbarkeit und Reversibilität vergleichen. So wird sichtbar, ob ein vertretbarer Weg mit geringerem Risiko verfügbar ist.

Die Ergebnisse müssen so verdichtet werden, dass das Organ entscheiden kann, ohne kritische Details zu verlieren. Executive Summary, klare Empfehlung, Gegenargumente, offene Punkte und verlinkte Evidenz sind zweckmäßiger als hunderte ungeordnete Seiten. Die zeitnahe Ablage sollte erkennen lassen, welche Versionen tatsächlich vorlagen. Dokumentation verbessert Nachvollziehbarkeit, ersetzt aber weder die inhaltliche Prüfung noch die laufende Überwachung nach einer Freigabe.

• Mindestens eine realistische Alternative vergleichen
• Restrisiko und Bedingungen der Empfehlung offenlegen
• Entscheidungsrelevante Evidenz versioniert verknüpfen
• Neubewertung bei Änderung und Vorfall vorsehen

Quellen: [1] [2]

Häufige Fragen