Trainingsdaten -Trainingsdaten – warum unsere Privatsphäre durch KI bedroht ist

Bei den Diensten, die heute als „KI“ bezeichnet werden, handelt es sich um mit großen Datenmengen trainierte neuronale Netze. Am bekanntesten sind die sogenannten „Large Language Models“ (LLMs) und Bildgeneratoren, die jeweils mit großen Textmengen oder sehr vielen Bilddaten trainiert wurden. Beide Varianten gehören in der Einordnung zur „schwachen KI“, wie z.B. Spracherkennung und Sprachsynthese. Mit „starker KI“ werden kognitive Systeme bezeichnet, die Aufgaben von Menschen „auf Augenhöhe“ übernehmen können. Bei den aktuellen LLMs wie ChatGPT und Co. scheint das zwar für viele unbefangene Nutzer*innen schon der Fall zu sein, aber ein Large Language Modell stellt immer noch einen sogenannten „stochastischen Papagei“ dar. Ein LLM versteht nicht den Inhalt von Texten, sondern gruppiert Wörter nach Wahrscheinlichkeiten. Daher kann man prinzipbedingt niemals ausschließen, dass die KI halluziniert. Also kann man den Ausgaben niemals vollständig vertrauen. Dazu der Energieaufwand und den daraus resultierenden CO2-Footprint bei Training und Benutzung der Systeme, der uns alle treffen wird.

Auch das Training der Modelle basiert auf einer großen Ungerechtigkeit:

Unabhängige Forschende haben im Gegensatz zu großen Konzernen gar nicht die Chance in ausreichender Menge an Trainingsdaten zu kommen.
Die Wikipedia-Autoren (auch ich bin einer) wurden niemals gefragt, ob diese Inhalte zum Training einer kommerziellen KI benutzt werden dürfen. Auch die Inhalte aus Social Media (Meta, facebook, whatsapp) wurden von Meta zum Training von LLMs verwendet (Daten sind das Öl der 21. Jahrhunderts). Google sichert sich z.B. das exklusive Recht auf die User-generierten Inhalte auf Reddit, um diese zum Training seiner KIs zu verwenden. (Web-)Bots ignorieren die robot.txt Einstellungen von Webseiten. Google und Amazon digitalisieren seit Jahren (seit mehr als einem Jahrzehnt, siehe auch Amazons „search inside“) Inhalte von Büchern und nutzen diese sicherlich auch zum Training von KIs.

Die Textausgaben von LLM selber wieder zum Training von neuen KIs zu nutzen, hat sich als Irrweg herausgestellt. Dadurch degeneriert der Inhalt immer weiter. Also sind die Konzerne zum Training auf den Input von kreativen, echten Intelligenzen angewiesen, die sich durch das Prompting vor den Karren der Hersteller spannen lassen. Auch die Prompts können für ein erneutes Training verwendet werden oder schlimmer, bei nicht lokal betriebenen LLMs, geleakt werden, wie gerade bei Deepseek geschehen. Aber wird das nicht zu einer gegenteiligen Entwicklung führen? Warum sollen wir alle gratis zum Training von kommerziellen LLMs beitragen? Das kann das Ende von frei zugänglichen Inhalten im Web bedeuten.

Was ist aber, wenn die Betreiber von LLMs dazu übergehen z.B. Mailinhalte für das Training von KI-Modellen zu verwenden? Google hat sich in gmail schon immer das Recht herausgenommen Mailinhalte für automatisierte Einblendungen von Werbung zu scannen. Der nächste logische Schritt wäre sehr einfach. Das „neue Outlook“ von Microsoft verschafft sich durch hijacking der IMAP-Zugangsdaten den Zugriff auf die Postfächer der Nutzer und kann so auf Unmengen von Trainingsdaten zugreifen. Das passiert wohl nun auch bei Business-Konten. Wenn die Konten eh schon in der O365 Cloud liegen, wäre es ein Leichtes sie zum Training von LLMs einzusetzen. Es wäre naiv zu glauben, dass würde nicht passieren. Auch die Dateiinhalte aller Office-Dokumente in der MS-Cloud können zum Training verwendet werden. Geschäftsgeheimnisse werden dann als Trainingsdaten im Copilot landen und damit möglicherweise auch in den Antworten dieses LLMs. So naiv kann doch kein Unternehmer sein, dieses Risiko auf sich zu nehmen.

Hier noch ein Link zu einem schönen KI-Artikel der digitalen Gesellschaft der Schweiz:
https://www.digitale-gesellschaft.ch/2023/12/06/wenn-dem-zauberlehrling-der-papagei-entwischt-ungeahnte-moeglichkeiten-durch-ki-oder-das-ende-der-welt/

Gefahren von Security Dashboards in der Cloud – hier beispielhaft die Cisco Endpoint Console

In der iX läuft derzeit eine Artikelserie zu Wazuh, eine Open Source SIEM Software, die ich im Rahmen meiner Tätigkeit an der TU Dortmund selber auch einsetze und mit der ich gute Erfahrungen gemacht habe:

Wazuh: Unternehmenssicherheit mit Open Source

Freie Sicherheitsplattform Wazuh im Einsatz

Aktuell ist auch ein kritischer Beitrag zu Security Software hinzugekommen, die sich tief im System verankert, also auf allen Clients (auch auf Servern) mit Root-Rechten läuft.
Sicherheit von Drittanbietersoftware aus Sicht eines Angreifers

Das ist immer ein Problem beim Einsatz solcher Software (SIEM/Antivir/Security), beispielsweise auch bei Cisco Endpoint Security, ein Produkt, welches derzeit an vielen Hochschulen in NRW als Cloud-Variante eingesetzt wird. Leider wird an der TU Dortmund nicht die on Premise Variante von Cisco Endpoint Security verwendet, deren Bezug nicht über den NRW-Rahmenvertrag abgedeckt ist. Der lokale Betrieb würde also extra Kosten verursachen, die viele Hochschulen scheuen.

Der wesentliche Unterschied zu einer Software wie z.B. dem lokal an der TU betriebenen Wazuh-Server ist natürlich, dass dieser nicht aus dem Internet erreichbar ist. Die Cisco Endpoint Console ist aber weltweit erreichbar. Der Zugang ist zwar über Cisco DUO mit zwei Faktoren abgesichert, aber wir teilen uns als Nutzer der Cisco EU Cloud (die Nutzung der EU-Cloud ist eine Forderung aus der DSGVO) diese mit tausenden anderen Nutzern. Aber bei Cisco DUO hat es schon Sicherheitslücken gegeben.

Die Server der Cisco Endpoint Security liegen in der Amazon EU Cloud, die von Millionen Nutzern verwendet wird. Daraus ergeben sich neben Angriffen von Innen folgende potentielle externe Angriffsvektoren: Cisco-Mitarbeiter/Binnentäter, Amazon-Mitarbeiter/Binnentäter und, sehr viel schlimmer und leider auch viel wahrscheinlicher, alle potentiellen Sicherheitslücken im Cisco-Backend, alle potentiellen Sicherheitslücken in der AWS-Infrastruktur. Wenn dort ein Angreifer durchkommt ist er/sie Root plattformübergreifend auf all unseren Maschinen (und allen Maschinen andere Cisco-Kunden)! Im Kontext von Supply Chain Attacken ist dass leider speziell auch bei aktuellen Webtechnologien ein Fass ohne Boden.

Da ich in meiner vorherigen Tätigkeit an der Universität Duisburg Essen schon einmal von einem als unwahrscheinlich geltenden Angriffsszenario (Angriff direkt auf die Virtualisierungsinfrastruktur) gewarnt (unten im verlinkten Blogartikel) hatte, dass dann doch eingetreten ist, möchte ich hier vor solch einem Angriff auf ein Cloud Security Dashbord warnen, damit ich bei Eintritt wieder Fefes „told you so“ Spruch loswerden kann.

Security by Design“ verträgt sich nicht mit Weboberflächen in der Cloud, da diese unnötig die „Attac Surface“ erhöhen. Das betrifft selbstverständlich auch andere Hersteller und auch den Betrieb von Open Source Software, wie z.B. Wazuh, in der Cloud. Der Einsatz von Security Appliances in der Cloud verbietet sich aus solchen Erwägungen für jeden verantwortungsbewusst und im Sinne der IT-Sicherheit handelnden IT-Strategen.

„Schuld“ bei einem Sicherheitsvorfall ist natürlich immer der Angreifer, und IT-Verantwortliche können dann mit der Schulter zucken und die Verantwortung auf den betroffenen Cloud-Betreiber abwälzen (die lokale IT kann ja nichts dafür). Das ist aber eine gefährliche Verantwortungsdiffusion, die scheinbar bei vielen IT-Entscheidern um sich greift: „Alle machen jetzt Cloud“. Diese Fehlentwicklung wird möglicherweise noch einigen Unternehmen und Behörden viel Geld oder vielleicht gar die Existenz kosten.

KI Stimmen für das Pediaphon

Das Pediaphon ist ein Webdienst von mir, der seit 2006 Wikipedia-Artikel in Sprache umwandelt. Dort werden diverse Open Source TTS Generatoren und Stimmen eingesetzt. Ursprünglich basierte das Pediaphon auf einem EU-projekt namens MBROLA, später kamen TTS-Systeme wie espeak, Milena und SVOX-Pico (2010) hinzu. Moderne Text-to-Speech- (TTS) Verfahren basieren heute auf Neuronalen Netzen (landläufig als KI bezeichnet, bei künstlicher Sprachausgabe handelt es sich aber um sogenannte „schwache KI“), die mit Sprachsamples trainiert werden. Alle der bekannten, in Windows, Android und IOS integrierten kommerziellen TTS-Stimmen nutzen heute solche Techniken. Seit einiger Zeit sind auch Open Source Stimmen entwickelt worden, die auf diesen Techniken beruhen. Meist werden die Sprachmodelle in Python trainiert und auch ausgeführt. Da ich im Pediaphon ganze und teilweise sehr große Wikipedia-Artikel in einem Stück und nicht als Stream in Sprache umwandle, bin ich auf sehr schnelle Algorithmen angewiesen. Weiterlesen