Leistungsfähige KI unabhängig prüfen, statt sich allein auf Sicherheitsangaben der Entwickler zu verlassen: Dafür schlagen TÜV-Verband und TÜV AI.Lab eine neue Prüf- und Aufsichtsstruktur vor. Sie soll Modellbewertungen mit Branchenkompetenz verbinden und Deutschland sowie Europa eine eigenständige Risikobeurteilung ermöglichen. Für IT-Entscheider stellt das Konzept die Frage in den Mittelpunkt, welche Sicherheitsnachweise vorliegen müssen, bevor KI-Agenten Zugang zu Unternehmensdaten, Geschäftsprozessen oder technischen Anlagen erhalten. Der Vorschlag ist eine politische Forderung, keine bereits eingeführte allgemeine Prüfpflicht. [1]

Management Summary

Souveränität durch eigene Bewertung: TÜV-Verband und TÜV AI.Lab fordern unabhängige Kompetenzen zur Sicherheitsprüfung leistungsfähiger KI – auch dann, wenn die Modelle außerhalb Europas entwickelt werden. [1]
Prüfung über den Lebenszyklus: Das Konzept sieht Evaluationen während der Entwicklung und vor der Bereitstellung sowie eine begleitende Bewertung im Betrieb vor. Modellfähigkeiten, Schutzmaßnahmen und reale Einsatzbedingungen sollen gemeinsam betrachtet werden. [1]
Branchenwissen einbinden: Bei KI in Industrieanlagen, Mobilität oder Energieversorgung sollen unabhängige Prüforganisationen ihre domänenspezifische Sicherheitskompetenz einbringen. Eine reine Modellprüfung ist nicht der gesamte vorgeschlagene Ansatz. [1]
Forderung und Rechtslage unterscheiden: Der TÜV-Vorschlag geht über bestehende Strukturen hinaus. Für Anbieter von KI-Modellen mit allgemeinem Verwendungszweck gelten bereits Vorgaben des AI Act; bei Modellen mit systemischem Risiko kommen zusätzliche Pflichten hinzu. [1][2][3]
Handlungsbedarf im Unternehmen: In der KI-Sicherheitsstudie 2026 testen 52 Prozent der KI-nutzenden Unternehmen ihre Anwendungen vor dem Einsatz beispielsweise auf Sicherheit; 40 Prozent protokollieren oder überwachen die Nutzung. Nur 11 Prozent der Unternehmen mit bestehender oder geplanter KI-Nutzung haben spezielle Prozesse für KI-bezogene Sicherheitsvorfälle. Die unterschiedlichen Bezugsgruppen sind zu beachten. [4]

Illustration Absmeier foto ki designer

KI-generierte Symbolillustration: Unabhängige Modellbewertungen und die Prüfung des Einsatzkontexts stehen im Mittelpunkt der vorgeschlagenen Sicherheitsarchitektur. Die Darstellung zeigt keine reale Prüfanlage und kein Zertifikat.

TÜV-Verband und TÜV AI.Lab legen Konzept zur Prüfung von Frontier-KI vor

Leistungsfähige KI-Modelle vor der Markteinführung eigenständig bewerten und digitale Souveränität sichern. Zum Digital-Gipfel legen TÜV AI.Lab und TÜV-Verband einen Vorschlag für den Aufbau einer unabhängigen Sicherheitsinfrastruktur für Frontier-KI vor.

Zum Digital-Gipfel der Bundesregierung legen TÜV-Verband und TÜV AI.Lab einen Vorschlag für den Aufbau einer unabhängigen Prüf- und Aufsichtsstruktur für Frontier-KI und autonome KI-Agenten vor. Deutschland und Europa müssen in der Lage sein, die Sicherheit dieser KI-Systeme eigenständig zu bewerten, unabhängig davon, wo diese entwickelt wurden. Nach Ansicht der TÜV-Organisationen sollten die KI-Modelle vor ihrer Markteinführung geprüft werden. Eine zentrale Rolle sollte künftig das deutsche KI-Sicherheitsinstitut (AISI) in Zusammenarbeit mit unabhängigen Prüforganisationen übernehmen. Ihren Vorschlag erläutern TÜV-Verband und TÜV AI.Lab in einem gemeinsamen Whitepaper.

»Europa muss natürlich den Anspruch haben, eigene leistungsfähige KI-Modelle zu entwickeln. Aber wir müssen uns darauf einstellen, dass auch künftig ein erheblicher Teil der bei uns eingesetzten KI aus den USA und anderen Weltregionen kommen wird«, sagt Dr. Joachim Bühler, Geschäftsführer des TÜV-Verbands. »Und bei deren Sicherheitsbewertung dürfen wir nicht allein auf die Angaben der Hersteller vertrauen, besonders wenn kritische Infrastrukturen und die nationale Sicherheit betroffen sind. Wir müssen selbst beurteilen können, welche Risiken mit ihrem Einsatz verbunden und welche Schutzmaßnahmen nötig sind. Digitale Souveränität bedeutet also nicht nur, eigene Technologien zu entwickeln, sondern auch, fremde Technologien unabhängig prüfen und beherrschen zu können.«

Bewährte Prüfstrukturen auch für KI schaffen

Für Technologien, die Menschen oder Umwelt gefährden können, sind unabhängige Prüfstrukturen in Europa seit Langem etabliert – etwa bei Fahrzeugen, Industrieanlagen und Medizinprodukten. TÜV AI.Lab und TÜV-Verband fordern, nach diesem Vorbild auch für Frontier-KI unabhängige Prüfstrukturen aufzubauen. Denn KI wird leistungsfähiger und zunehmend in digitale und physische Systeme integriert. Die Prüfungen sollen bereits während der Entwicklung beginnen und den gesamten Lebenszyklus eines Modells begleiten. Untersucht werden sollen seine Fähigkeiten, die Wirksamkeit seiner Schutzmechanismen und sein Verhalten unter realistischen Einsatzbedingungen. Dafür benötigen unabhängige Prüfer Zugang zu den Modellen, ihren Trainingsprozessen und sicherheitsrelevanten Informationen zum Entwicklungsprozess. Hinzu kommen verbindliche Anforderungen an Prüfmethoden, Qualifikation und Unabhängigkeit der beteiligten Stellen.

»Unabhängige Prüfer müssen den Sicherheitsversprechen der Entwickler auf den Grund gehen können«, sagt Franziska Weindauer, Geschäftsführerin des TÜV AI.Lab. »Dafür brauchen sie Zugang zu den Modellen und Einblick in Training und Schutzmaßnahmen. Sie müssen unabhängig bewerten können, ob bestehende Risiken ausreichend mitigiert wurden. Und wenn KI eine Maschine steuert, müssen Fachleute für Maschinensicherheit mitprüfen. Sie können beurteilen, welchen Einfluss KI auf bestehende Sicherheitsmechanismen hat.«

Staatliche Verantwortung und unabhängige Prüfung verbinden

Das AISI sollte nach dem Vorschlag schrittweise zu einer eigenständigen Institution mit klarem Mandat und ausreichenden Ressourcen ausgebaut werden. Es sollte eigene Kompetenzen für die Sicherheitsbewertung von Frontier-KI aufbauen und zugleich unabhängige Prüforganisationen mit Fachwissen aus Industrie, Mobilität und Energieversorgung einbinden. So könnte das Institut schnell handlungsfähig werden.

Das Institut könnte die Entwicklung geeigneter Prüfmethoden unterstützen, den notwendigen Modellzugang gewährleisten und Ergebnisse für Entscheidungen der Bundesregierung und zuständiger Behörden aufbereiten. Qualifizierte unabhängige Prüforganisationen könnten die technischen Evaluationen übernehmen und insbesondere prüfen, ob die Sicherheitsnachweise für den Einsatz von KI in technischen Systemen belastbar sind. Die staatliche Verantwortung und Aufsicht bleiben erhalten.

Internationale Zusammenarbeit mit verbindlichen Regeln

Die nationale Sicherheitsinfrastruktur muss aus Sicht der TÜV-Organisationen in einen europäischen und internationalen Rahmen eingebunden sein. Auf EU-Ebene fordern sie einheitliche Sicherheitsanforderungen und den Ausbau unabhängiger Prüfkapazitäten. Gemeinsam mit Partnerstaaten wie Großbritannien, Kanada und Japan sollten Deutschland und die EU Prüfverfahren abstimmen und gegenüber den Entwicklern gemeinsam über den Zugang zu Modellen und sicherheitsrelevanten Informationen verhandeln.

Langfristiges Ziel ist ein verbindliches internationales Abkommen mit Prüfungen während der Entwicklung und vor der Bereitstellung sowie klaren Grenzen für nicht beherrschbare Risiken. Werden vereinbarte Risikoschwellen überschritten oder zentrale Sicherheitsanforderungen nicht hinreichend nachgewiesen, sollen Entwicklung oder Bereitstellung ausgesetzt werden. Eine internationale Aufsichtsstruktur soll die Einhaltung überwachen. Ein weltweites Meldesystem für schwerwiegende KI-Sicherheitsvorfälle soll den Austausch über neue Gefahren ermöglichen.

Das gemeinsame Whitepaper »Frontier-KI-Sicherheit: Wirksame Governance-Strukturen etablieren, internationalen Prüfrahmen aufbauen« ist online verfügbar.
https://www.tuev-verband.de/fileadmin/user_upload/Content_local/Veroeffentlichungen/2026_TUEV-Verband_und_TUEV.AI.Lab_Whitepaper_Frontier-KI-Sicherheit.pdf

Executive Summary

Neuartige Risiken von Frontier-KI:
Die Entwicklung von immer fortschrittlicheren KI-Modellen bietet beträchtliche sozioökonomische Chancen, birgt jedoch auch völlig neuartige Risiken. Vorfälle in Test- und Ein satz-Umgebungen zeigen, dass fortgeschrittene agentische KI-Systeme zu komplexen Verhaltensweisen fähig sind, welche schwer antizipierbar sind und kritische Sicherheitsrisiken bergen. Angesichts der spezifischen Kombination von hochautonomen Verhaltensweisen und neuesten Fähigkeiten von Frontier-Modellen kommen bisherige KI-Governance-Ansätze an ihre Grenzen. Freiwillige Selbstverpflichtungen der Hersteller reichen nicht aus. Die neuen Risiken sind eine Gefahr für die nationale Sicherheit und werden bisher weder in Deutschland noch weltweit angemessen rechtlich und institutionell adressiert.

AISI Deutschland zum Kompetenzzentrum für Frontier-KI und nationale KI-bezogene Sicherheit ausbauen:
Deutschland muss systemische KI-Risiken eigenständig bewerten und begrenzen können. Das ist auch eine Frage der digitalen Souveränität. Eine robuste KI-Sicherheitsarchitektur sollte dafür zwei Komponenten vereinen:

1) Kompetenz zur lebenszyklusbegleitenden, unabhängigen Evaluation und Prüfung von Frontier-Modellen.

2) Sicherheits-, domänen- und prüfspezifische Kompetenz, sobald Frontier-KI auf kritische Infrastrukturen, Industrieanlagen, Fahrzeuge oder andere Systeme der physischen Welt trifft.

Isolierte KI-Kompetenz reicht hier nicht aus. Der Aufbau des AISI sollte deshalb von Beginn an gemeinsam mit unabhängigen Prüforganisationen erfolgen und deren über Jahrzehnte aufgebaute Sicherheits-, Domänen- und Prüfkompetenz systematisch einbinden.

Mehrstufige Governance – nationalen und internationalen Sicherheitsrahmen schaffen:
Weltweit gibt es derzeit ganz unterschiedliche Regulierungsansätze von freiwilliger Selbstregulierung bis hin zu verbindlichen gesetzlichen Vorgaben (wie etwa EU AI Act oder auf US-Bundesstaaten-Ebene), und entstehen vielerorts nationale KI-Sicherheitsinstitute. Was fehlt ist ein international verbindlicher Rahmen – ver gleichbar mit nuklearer Sicherheit – für Frontier-KI-Sicherheit. Es braucht Maßnahmen auf deutscher, europäischer, EU+- und globaler Ebene und diese müssen ineinandergreifen – von nationalen Prüf- und Aufsichtsstrukturen über einen kohärenten und konsequent umgesetzten EU-Regulierungsrahmen sowie EU-Zusammenarbeit mit gleichgesinnten »Middle Powers« bis hin zu international abgestimmten Sicherheitskriterien, Prüfmechanismen und Melde- sowie Aufsichtsstrukturen. So entsteht ein mehrstufiger Sicherheitsrahmen, der die globalen und lokalen Auswirkungen der mächtigsten K-Modelle und KI-Systeme adäquater adressiert.

Tipps für Unternehmen: KI-Sicherheit praktisch organisieren

Die folgenden Handlungsempfehlungen sind eine redaktionelle Checkliste auf Grundlage der recherchierten Quellen, keine individuelle Rechtsberatung oder Zertifizierung. [2–6]

KI-generierte Infografik der acht Tipps. Die Bezugszeichen beziehen sich auf den bestehenden Quellenblock.

Ausführliche Tipps mit Praxisbeispielen

Die folgenden Umsetzungsvorschläge vertiefen die vorhandene Checkliste. Alle Praxisbeispiele sind hypothetische, redaktionell entwickelte Szenarien, keine dokumentierten Unternehmensfälle oder nachgewiesenen Ergebnisse. Zuständigkeiten, Freigabekriterien und Prüfintervalle sind an den jeweiligen Betrieb anzupassen. Die Quellenbezugszeichen der ursprünglichen Tipps bleiben dort erhalten; die Beispiele sind keine Aussagen dieser Quellen. Die Empfehlungen ersetzen keine individuelle Rechtsberatung oder Prüfung sicherheitskritischer Anlagen.

1. KI-Inventar anlegen: Vom Werkzeugverzeichnis zum Betriebssteckbrief

Umsetzungsempfehlung: Erfassen Sie nicht nur separat beschaffte KI-Anwendungen, sondern auch zuschaltbare Funktionen in Bürosoftware, CRM, Serviceportalen und Entwicklungswerkzeugen. Verwenden Sie für jeden Anwendungsfall einen einheitlichen Steckbrief: geschäftlicher Zweck, fachlich verantwortliche Stelle, technischer Ansprechpartner, Anbieter, verfügbare Modell- oder Versionsangaben, Datenarten, Speicherorte, angebundene Systeme und erlaubte Aktionen. Kennzeichnen Sie fehlende Anbieterinformationen ausdrücklich als unbekannt, statt Angaben zu ergänzen.

Unterscheiden Sie geplante, getestete, freigegebene und stillgelegte Anwendungen. Verknüpfen Sie den Eintrag mit Verträgen, Freigaben und Testprotokollen. Legen Sie fest, wer den Steckbrief bei einer Änderung aktualisiert und wie neue KI-Funktionen vor ihrer Aktivierung gemeldet werden sollen.

Hypothetisches Praxisbeispiel: Ein mittelständischer Maschinenbauer möchte einen internen Wissensassistenten nutzen. Im Inventar wird festgehalten, dass er ausschließlich freigegebene Wartungsanleitungen durchsuchen darf und keine Verbindung zur Maschinensteuerung erhält. Eine zusätzlich in der CRM-Software angebotene KI-Funktion wird als eigener Anwendungsfall aufgenommen, weil sie mit anderen Daten und Berechtigungen arbeitet.

Konkretes Arbeitsergebnis: Ein gepflegter Steckbrief pro Anwendungsfall mit Verantwortlichem, Freigabestatus und Datum der letzten Überprüfung. Als interne Kontrollgröße bietet sich der Anteil der erfassten Anwendungen mit vollständig ausgefüllten Pflichtfeldern an; einen Zielwert sollte das Unternehmen selbst festlegen.

2. Den Anwendungsfall bewerten: Auswirkungen vor Funktionen betrachten

Umsetzungsempfehlung: Beschreiben Sie zunächst, welche Aufgabe die KI übernehmen soll und was ausdrücklich außerhalb ihres Auftrags liegt. Prüfen Sie anschließend, welche Folgen falsche Ergebnisse, die Offenlegung von Informationen oder unbeabsichtigte Aktionen im konkreten Prozess hätten. Berücksichtigen Sie Datenvertraulichkeit, betroffene Personen, Rücknehmbarkeit von Aktionen und mögliche Auswirkungen auf technische Systeme.

Trennen Sie unterstützende Vorschläge von verbindlichen Entscheidungen und automatisierter Ausführung. Leiten Sie daraus die notwendigen Freigaben, Testfälle und Zugriffsbeschränkungen ab. Eine unternehmensinterne Risikoeinstufung dient der Steuerung des Projekts; sie ersetzt nicht die gesonderte rechtliche Einordnung.

Hypothetisches Praxisbeispiel: Ein Serviceunternehmen plant drei Funktionen: Zusammenfassungen interner Handbücher, Antwortentwürfe für Kunden und automatische Änderungen von Vertragsdaten. Für die erste Funktion sieht das Projektteam eine Quellenprüfung durch Nutzer vor. Antwortentwürfe benötigen vor dem Versand eine Freigabe. Vertragsänderungen bleiben außerhalb des Pilotumfangs, bis Zuständigkeiten, Prüfungen und Rücknahmemöglichkeiten geklärt sind.

Konkretes Arbeitsergebnis: Eine dokumentierte Entscheidung über den zulässigen Einsatzumfang mit Begründung, Restrisiken, Kontrollmaßnahmen und Freigabeverantwortlichem. Halten Sie auch fest, unter welchen Bedingungen die Entscheidung neu bewertet werden muss.

3. Nachweise einfordern: Beschaffung mit konkreten Prüffragen verbinden

Umsetzungsempfehlung: Übersetzen Sie allgemeine Sicherheitsversprechen in überprüfbare Fragen. Welche Anwendung und Version wurden getestet? Welche Zugriffsrechte und Datenquellen waren Teil der Prüfung? Welche Fehler wurden festgestellt, welche Grenzen dokumentiert? Wer hat geprüft und welche Informationen stehen Ihrem Unternehmen für die Integration zur Verfügung? Fragen Sie außerdem nach der Behandlung von Eingaben, Aufbewahrung, Unterauftragnehmern und Änderungsmitteilungen.

Bewerten Sie Nachweise nach ihrem Geltungsbereich. Ein Dokument über die Infrastruktur des Anbieters sollte nicht ohne Prüfung als Beleg für die Qualität Ihrer konkreten KI-Anwendung behandelt werden. Halten Sie offene Fragen und daraus abgeleitete Beschaffungsbedingungen fest. Vereinbaren Sie, soweit möglich, nachvollziehbare Informationen über relevante Änderungen und einen erreichbaren Ansprechpartner für Sicherheitsvorfälle.

Hypothetisches Praxisbeispiel: Ein Unternehmen beschafft einen Assistenten für seine Dokumentenablage. Der Anbieter legt einen allgemeinen Testbericht vor. Die Beschaffung fragt ergänzend, ob darin die Suche über mehrere getrennte Kundenbereiche und die verbindliche Durchsetzung der jeweiligen Zugriffsrechte geprüft wurden. Bis diese Fragen beantwortet und intern getestet sind, bleibt die Freigabe auf einen abgegrenzten Testdatenbestand beschränkt.

Konkretes Arbeitsergebnis: Eine Nachweismatrix mit Anforderung, vorgelegtem Beleg, Geltungsbereich, offener Frage und Freigabeentscheidung. Fehlende Nachweise werden als Lücken dokumentiert, nicht als bestandene Prüfung gewertet.

4. Agentenrechte begrenzen: Lesen, Vorschlagen und Ausführen trennen

Umsetzungsempfehlung: Erstellen Sie eine Berechtigungsmatrix für jeden Agenten. Unterscheiden Sie lesenden Zugriff, das Erstellen von Entwürfen und Änderungen an produktiven Daten. Geben Sie nur die für den freigegebenen Auftrag benötigten Werkzeuge und Datenbereiche frei. Verwenden Sie, soweit technisch verfügbar, eine eigene technische Identität statt eines persönlichen Kontos mit weitreichenden Rechten.

Legen Sie sensible Aktionen fest, die eine menschliche Freigabe benötigen. Die prüfende Person sollte vor der Zustimmung Empfänger, betroffene Datensätze und geplante Änderungen sehen können. Planen Sie zeitliche und mengenmäßige Grenzen sowie einen dokumentierten Entzug der Zugriffe ein. Prüfen Sie die Berechtigungen in der technischen Anbindung, nicht allein anhand der formulierten Arbeitsanweisung.

Hypothetisches Praxisbeispiel: Ein Vertriebsassistent darf freigegebene Produktinformationen lesen und einen Angebotsentwurf erstellen. Er erhält keine Berechtigung, Preise zu ändern, Kundendaten zu exportieren oder das Angebot selbst zu versenden. Vor dem Versand kontrolliert ein zuständiger Mitarbeiter den Entwurf, die Empfänger und eventuelle Anhänge.

Konkretes Arbeitsergebnis: Eine freigegebene Rechte- und Aktionsmatrix mit technischen Konten, erlaubten Datenbereichen und Freigabeschritten. Ein dokumentierter Test sollte zeigen, ob eine nicht erlaubte Aktion tatsächlich abgewiesen wird.

5. Vor der Freigabe testen: Einen nachvollziehbaren Prüfplan aufstellen

Umsetzungsempfehlung: Entwickeln Sie Testfälle aus den tatsächlichen Aufgaben und den zuvor bewerteten Risiken. Berücksichtigen Sie korrekte und unvollständige Eingaben, widersprüchliche Dokumente, fehlende Quellen, nicht erlaubte Datenzugriffe und Anfragen außerhalb des Einsatzumfangs. Nutzen Sie für erste Tests synthetische oder ausdrücklich freigegebene Daten in einer abgegrenzten Umgebung.

Beschreiben Sie vorab das erwartete Verhalten und die Kriterien für Freigabe, Nachbesserung oder Abbruch. Dokumentieren Sie Anwendungsversion, Einstellungen, Datenbestand, Werkzeuge und Ergebnisse. Wiederholen Sie wichtige Fälle und halten Sie unterschiedliche Ergebnisse fest. Eine Freigabe sollte sich auf den getesteten Einsatzumfang beziehen, nicht auf beliebige künftige Anwendungen.

Hypothetisches Praxisbeispiel: Für einen internen Handbuchassistenten enthält der Prüfplan Fragen mit eindeutiger Antwort, Fragen zu veralteten Dokumenten und Fragen, für die keine freigegebene Quelle vorhanden ist. Das Team legt fest, dass unbelegte technische Anweisungen nicht als verlässliche Antwort ausgegeben werden dürfen. Zusätzlich wird geprüft, ob ein Nutzer auf einen für ihn gesperrten Dokumentenbereich zugreifen kann. Ein unzulässiger Zugriff gilt als Abbruchkriterium des Piloten.

Konkretes Arbeitsergebnis: Ein Testprotokoll mit Sollverhalten, beobachtetem Ergebnis, offenen Fehlern und begründeter Freigabeentscheidung. Dokumentieren Sie bekannte Grenzen sichtbar für die späteren Nutzer.

6. Änderungen erneut bewerten: Freigaben an eine konkrete Konfiguration binden

Umsetzungsempfehlung: Definieren Sie, welche Änderungen eine erneute fachliche oder technische Prüfung auslösen: ein anderes Modell, neue Datenquellen, geänderte Arbeitsanweisungen, zusätzliche Werkzeuge, umfassendere Rechte oder ein neuer Einsatzbereich. Halten Sie eine freigegebene Ausgangskonfiguration fest. Kann der Anbieter bestimmte Versionsangaben nicht bereitstellen, dokumentieren Sie diese Einschränkung und klären Sie mögliche Änderungsmitteilungen.

Prüfen Sie Änderungen zunächst außerhalb des produktiven Betriebs. Wiederholen Sie die betroffenen Testfälle und die besonders wichtigen Zugriffskontrollen. Planen Sie einen Rückfall auf eine verfügbare frühere Konfiguration oder einen manuellen Prozess, falls ein Rücksetzen technisch nicht möglich ist. Legen Sie fest, wer die erneute Freigabe erteilt.

Hypothetisches Praxisbeispiel: Ein Dokumentenassistent soll künftig nicht nur Handbücher durchsuchen, sondern zusätzliche Informationen aus dem CRM abrufen. Das Projekt behandelt dies als Erweiterung des Einsatzumfangs. Vor der Aktivierung werden Datenberechtigungen, neue Testfälle und Zuständigkeiten geprüft. Bis zur Freigabe bleibt die bisherige Funktion ohne CRM-Anbindung in Betrieb.

Konkretes Arbeitsergebnis: Ein Änderungsprotokoll mit Anlass, betroffenen Risiken, Tests, Freigabe und Rückfalloption. Als Kontrollfrage eignet sich: Ist jede aktuell aktive Erweiterung durch eine nachvollziehbare Entscheidung abgedeckt?

7. Vorfallprozesse vorbereiten: Zuständigkeiten vor dem Ernstfall festlegen

Umsetzungsempfehlung: Ergänzen Sie bestehende Sicherheitsprozesse um konkrete KI-Szenarien: auffällige Ergebnisse, Zugriff auf nicht freigegebene Daten, unerlaubte Aktionen oder Hinweise auf eine Offenlegung vertraulicher Informationen. Definieren Sie einen leicht erreichbaren Meldeweg und benennen Sie die Stelle, die den Vorfall bewertet und den Einsatz gegebenenfalls unterbricht.

Führen Sie in einem Ablaufplan auf, wer technische Zugriffe entziehen, relevante Protokolle sichern und den Anbieter kontaktieren darf. Berücksichtigen Sie beim Umgang mit Protokollen Datenschutz, Vertraulichkeit und interne Aufbewahrungsregeln. Lassen Sie mögliche gesetzliche Meldepflichten von den zuständigen Fachstellen beurteilen, statt für jeden KI-Vorfall pauschal dieselbe Frist anzunehmen. Prüfen Sie Wiederanlaufbedingungen und einen verfügbaren Ersatzprozess.

Hypothetisches Praxisbeispiel: In einem internen Supportassistenten erscheint eine Antwort mit Informationen aus einem nicht freigegebenen Bereich. Der Nutzer meldet den Vorgang über den festgelegten Kanal. Das zuständige Team unterbricht die betroffene Anbindung, sichert die erforderlichen Informationen und prüft Umfang und Ursache. Der Fachbereich arbeitet vorübergehend mit der bisherigen manuellen Wissenssuche weiter. Die erneute Aktivierung benötigt eine dokumentierte Freigabe.

Konkretes Arbeitsergebnis: Ein abgestimmter Vorfallablauf mit Kontakten, Entscheidungsbefugnissen und Wiederanlaufkriterien. Eine Übung mit einem hypothetischen Vorfall kann zeigen, welche Zuständigkeiten noch ungeklärt sind.

8. Verantwortlichkeiten klären: Eine gemeinsame Freigabe statt Zuständigkeitslücken

Umsetzungsempfehlung: Benennen Sie für jeden Anwendungsfall eine fachlich verantwortliche Stelle und einen technischen Betriebsverantwortlichen. Legen Sie fest, welche Entscheidungen Beschaffung, Informationssicherheit, Datenschutz, Rechtsabteilung und Fachbereich treffen oder prüfen sollen. Unterscheiden Sie Bereitstellung, fachliche Nutzung, Überwachung, Änderungen und Außerbetriebnahme.

Lassen Sie die konkrete rechtliche Rolle und die anwendbaren Pflichten anhand der tatsächlichen Bereitstellung und Nutzung prüfen. Übernehmen Sie eine Einordnung nicht allein aus dem Produktnamen oder einer Anbieterpräsentation. Halten Sie Freigabebedingungen, Schulungsbedarf und Eskalationswege fest. Die Leitung sollte eine begründete Entscheidung über Einsatzumfang und verbleibende offene Punkte erhalten, keine bloße Übersicht technischer Funktionen.

Hypothetisches Praxisbeispiel: Eine Handelsorganisation plant einen Assistenten für Kundenanfragen. Der Fachbereich verantwortet Antwortregeln und Qualitätsprüfung, die IT den Betrieb und die Zugriffe, die Informationssicherheit die Sicherheitskontrollen und die zuständigen Datenschutz- und Rechtsstellen ihre jeweiligen Prüfungen. Die Beschaffung dokumentiert Anbietervereinbarungen. Vor dem Start werden Zuständigkeiten und Freigabebedingungen in einem gemeinsamen Entscheidungsprotokoll festgehalten.

Konkretes Arbeitsergebnis: Eine Verantwortlichkeitsmatrix und eine verbindliche Freigabecheckliste mit Namen oder Funktionen, Entscheidungen und offenen Aufgaben. Änderungen am Einsatzumfang sollen an die zuständigen Stellen zurückgeführt werden.

FAQ: Zehn Fragen zu Frontier-KI und unabhängigen Prüfungen

1. Was meint der Text mit Frontier-KI?

Der vorliegende TÜV-Text verwendet den Begriff für besonders fortschrittliche, leistungsfähige KI-Modelle und behandelt insbesondere ihre Verbindung mit hochautonomen agentischen Systemen. Für die rechtliche Einordnung verwendet der AI Act eigene Kategorien: KI-Modelle mit allgemeinem Verwendungszweck und darunter Modelle mit systemischem Risiko. Der redaktionelle Begriff Frontier-KI sollte deshalb nicht ungeprüft mit einer Rechtskategorie gleichgesetzt werden. [1][2][3]

2. Was schlagen TÜV-Verband und TÜV AI.Lab konkret vor?

Sie fordern unabhängige Prüfungen während der Entwicklung und vor der Markteinführung sowie eine lebenszyklusbegleitende Bewertung. Eine zentrale Rolle soll nach ihrem Vorschlag ein deutsches KI-Sicherheitsinstitut in Zusammenarbeit mit qualifizierten unabhängigen Prüforganisationen übernehmen. Hinzu kommen europäische Abstimmung und langfristig ein verbindlicher internationaler Prüfrahmen. Das sind Forderungen der Organisationen. [1]

3. Gibt es bereits eine allgemeine TÜV-Prüfpflicht für Frontier-KI?

Die recherchierte Veröffentlichung beschreibt einen Vorschlag, nicht die Einführung einer solchen allgemeinen Pflicht. Davon zu unterscheiden sind bestehende gesetzliche Vorgaben des AI Act für Anbieter von KI-Modellen mit allgemeinem Verwendungszweck und zusätzliche Pflichten für Modelle mit systemischem Risiko. Eine allgemeine Pflicht zur Prüfung jedes Frontier-Modells durch eine TÜV-Organisation ergibt sich aus den hier herangezogenen Quellen nicht. [1][2][3]

4. Welche Termine gelten für Anbieter von GPAI-Modellen?

Nach den veröffentlichten Kommissionsleitlinien gelten die Anbieterpflichten seit dem 2. August 2025 für neu auf den Markt gebrachte Modelle. Die entsprechenden Durchsetzungsbefugnisse der Kommission gelten seit dem 2. August 2026. Für Modelle, die bereits vor dem 2. August 2025 auf dem Markt waren, nennen die Leitlinien den 2. August 2027 als Termin zur Erfüllung der Pflichten. Diese Fristen betreffen die beschriebenen GPAI-Anbieterpflichten, nicht pauschal jede KI-Anwendung. [2]

5. Welche zusätzlichen Pflichten betreffen Modelle mit systemischem Risiko?

Die Kommission nennt zusätzliche Sicherheitsanforderungen für die leistungsfähigsten beziehungsweise besonders wirkungsmächtigen GPAI-Modelle. Anbieter müssen systemische Risiken bewerten und mindern; die Leitlinien verweisen außerdem auf die Pflicht, entsprechende Modelle dem AI Office zu melden. Das Kapitel »Safety and Security« des GPAI-Verhaltenskodex unterstützt die praktische Umsetzung. [2][3]

6. Ist der GPAI-Verhaltenskodex selbst ein Gesetz?

Nein. Die Kommission beschreibt ihn als freiwilliges Instrument zur Unterstützung der Erfüllung von AI-Act-Pflichten. Die gesetzlichen Pflichten und die freiwillige Nutzung dieses Umsetzungsinstruments sind getrennt zu betrachten. Auch die Kommissionsleitlinien sind nach eigener Darstellung nicht rechtsverbindlich, sondern erläutern die Auslegung der Kommission. [2][3]

7. Warum müssen Unternehmen KI-Agenten gesondert betrachten?

Das BSI beschreibt KI-Agenten als Systeme, die nicht nur Antworten liefern, sondern in mehreren Schritten Aktionen ausführen und dafür auf Programme, Onlinedienste oder Dateien zugreifen. Die entscheidende praktische Frage lautet daher, welche Rechte ein Agent erhält und welche Aktionen eine menschliche Freigabe benötigen. Das BSI weist auch auf die Manipulierbarkeit von Ergebnissen in KI-Browsern hin. [5]

8. Reicht ein leistungsfähiges Modell als Sicherheitsnachweis für die Anwendung?

Der TÜV-Vorschlag verlangt ausdrücklich die Betrachtung realistischer Einsatzbedingungen und domänenspezifischer Sicherheitskompetenz. Das NIST-Rahmenwerk bezieht die Bewertung von KI-Produkten, Diensten und Systemen über Entwicklung und Nutzung hinweg ein. Für die betriebliche Prüfung sollten deshalb auch Datenquellen, Schnittstellen, Zugriffsrechte und die betroffenen Geschäftsprozesse dokumentiert werden; das ist eine redaktionelle Handlungsempfehlung aus diesen Ansätzen. [1][6]

9. Wo zeigt die KI-Sicherheitsstudie 2026 Lücken in Unternehmen?

Nach der gemeinsamen Befragung von BSI und TÜV-Verband testen 52 Prozent der bereits KI-nutzenden Unternehmen ihre KI-Anwendungen vor dem Einsatz, beispielsweise auf Sicherheit; 40 Prozent protokollieren oder überwachen die Nutzung. Unter Unternehmen, die KI nutzen oder ihren Einsatz planen, verfügen 11 Prozent über spezielle Prozesse für KI-bezogene Sicherheitsvorfälle. Die Zahlen beziehen sich auf unterschiedliche Gruppen und sind nicht unmittelbar als einheitliche Grundgesamtheit zu vergleichen. [4]

10. Was sollten CIOs vor einem produktiven KI-Einsatz verlangen?

Als redaktionelle Checkliste empfehlen sich ein dokumentierter Anwendungsfall, eine verantwortliche Stelle, nachvollziehbare Tests, begrenzte Agentenrechte, Regeln für Änderungen und ein Vorfallprozess. Als freiwillige Orientierung für strukturiertes Risikomanagement stehen das NIST AI RMF und sein Profil für generative KI zur Verfügung; für die rechtliche Einordnung sind die einschlägigen AI-Act-Vorgaben gesondert zu prüfen. [2][5][6]

Quellen und weiterführende Informationen

Recherche: 2. November 2026. Die Bezugszeichen im ergänzten Text verweisen auf die folgenden URLs. Die im Original enthaltenen Aussagen bleiben unverändert; die Ergänzungen unterscheiden Verbandsforderungen, Behördeninformationen und redaktionelle Empfehlungen.

[1] TÜV-Verband und TÜV AI.Lab: »Frontier-KI-Sicherheit: Wirksame Governance-Strukturen etablieren, internationalen Prüfrahmen aufbauen«. Im Ausgangsdokument verlinktes Whitepaper: https://www.tuev-verband.de/fileadmin/user_upload/Content_local/Veroeffentlichungen/2026_TUEV-Verband_und_TUEV.AI.Lab_Whitepaper_Frontier-KI-Sicherheit.pdf

[2] Europäische Kommission: Guidelines for providers of general-purpose AI models. https://digital-strategy.ec.europa.eu/en/policies/guidelines-gpai-providers

[3] Europäische Kommission: General-Purpose AI Code of Practice now available, 10. Juli 2025. https://ec.europa.eu/commission/presscorner/api/files/document/print/en/ip_25_1787/IP_25_1787_EN.pdf

[4] TÜV-Verband: KI-Sicherheitsstudie 2026, gemeinsame Unternehmensbefragung mit dem BSI, 7. Oktober 2026. https://www.tuev-verband.de/studien/ki-sicherheitsstudie-2026

[5] BSI: KI-Agenten – Wenn Künstliche Intelligenz selbstständig handelt. https://www.bsi.bund.de/DE/Themen/Verbraucherinnen-und-Verbraucher/Informationen-und-Empfehlungen/Technologien_sicher_gestalten/Kuenstliche-Intelligenz/KI-Agenten/ki-agenten_node.html

[6] NIST: Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, Juli 2024. https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

6984 Artikel zu „KI Sicherheit Tipp“

Business Process Management | IT-Security | Künstliche Intelligenz | News | Tipps

KI-Coding-Agenten: Autonomie braucht klare Zugriffsregeln

2. November 2026

KI-Coding-Agenten machen Berechtigungen zu einer Managementfrage: Entscheidend ist nicht allein, welche Aufgabe erteilt wird, sondern welche Werkzeuge, Daten und Systeme dafür erreichbar sind. Sicherheitsleitfäden empfehlen begrenzte Rechte, überprüfbare Aktionen und menschliche Freigaben für besonders folgenreiche Schritte. Der Beitrag ordnet diese Anforderungen ein. [1][2] Die Telemetriezahlen und der beschriebene Kontrollansatz stammen aus einer Anbieter-Pressemitteilung vom 21.…