Immer mehr Menschen betreiben KI-Modelle auf eigener Hardware. Das ist praktisch, spart Kosten und bringt Unabhängigkeit von großen Plattformen. Problematisch wird es allerdings, wenn solche Systeme ohne Schutzmechanismen direkt aus dem Internet erreichbar sind. Eine aktuelle Untersuchung zeigt: Weltweit sind sehr viele selbst gehostete KI-Instanzen öffentlich zugänglich – teils mit Funktionen, die weit über „nur Text generieren“ hinausgehen. Das kann erhebliche Folgen für Datenschutz, Missbrauch und Governance haben.

Studie: Über 175.000 öffentlich erreichbare Ollama-Instanzen

Ein Forschungsbericht von SentinelLABS in Zusammenarbeit mit dem Cybersicherheitsunternehmen Censys beleuchtet die Größenordnung offener KI-Infrastrukturen. Demnach sind weltweit mehr als 175.000 Instanzen des Open-Source-Frameworks Ollama über das Internet erreichbar – häufig ohne Zugangsbeschränkungen und ohne erkennbares Sicherheits-Monitoring.

Damit entstehen KI-Systeme, die außerhalb der üblichen Schutzmechanismen zentraler Plattformen betrieben werden. In der Summe ergibt sich eine neue, schwer regulierbare Schicht verteilter KI-Rechenleistung, die im Zweifel von Dritten mitgenutzt oder missbraucht werden kann.

Große Angriffsfläche durch Dauerbetrieb und Tool-Calling

Die Forscher haben über knapp zehn Monate hinweg öffentlich erreichbare Ollama-Hosts untersucht und dabei mehr als 7,2 Millionen Beobachtungen in 130 Ländern dokumentiert. Dabei zeigt sich ein typisches Muster: Viele Instanzen sind nur kurzzeitig online, gleichzeitig gibt es jedoch einen stabilen Kern von rund 23.000 dauerhaft erreichbaren Systemen, der einen Großteil der Aktivität ausmacht.

Gerade diese ständig verfügbaren Instanzen sind aus Sicherheitssicht besonders kritisch. Laut Bericht bieten viele von ihnen Funktionen wie „Tool Calling“ – also die Fähigkeit, externe Tools oder Dienste anzusprechen und in bestimmten Setups sogar Code auszuführen. Das erweitert die Einsatzmöglichkeiten, vergrößert aber auch die potenzielle Angriffsfläche erheblich.

Technisch homogen – und dadurch attraktiver für gezielte Angriffe

Obwohl die Infrastruktur weltweit verteilt ist, wirkt sie technisch überraschend einheitlich. Ein großer Teil der Systeme setzt auf dieselben Modellfamilien und identische Quantisierungsformate, besonders häufig auf das verbreitete Format „Q4_K_M“.

Diese Standardisierung ist einerseits praktisch, weil sie die Nutzung auf handelsüblicher Hardware erleichtert. Andererseits kann sie das Ökosystem anfälliger machen: Wenn Angreifer eine typische Schwachstelle oder einen häufigen Fehlkonfigurations-Blueprint identifizieren, lässt sich so etwas leichter in die Breite ausnutzen.

Viele Systeme laufen in Heimnetzen statt in Rechenzentren

Ein weiterer Aspekt: Ein erheblicher Anteil der untersuchten Instanzen steht offenbar nicht in großen Cloud- oder Enterprise-Umgebungen, sondern in Heimnetzen oder bei kleineren Hosting-Anbietern. Das erschwert die Zuordnung und die Kontaktaufnahme, wenn es zu Missbrauch kommt.

Zugleich werden dadurch gängige Sicherheits- und Governance-Mechanismen umgangen, die man von Plattformanbietern kennt – etwa strukturierte Abuse-Prozesse, standardisierte Sperrmechanismen oder zentral durchgesetzte Sicherheitsvorgaben.

Welche Risiken entstehen – und was Verantwortliche jetzt beachten sollten

Die Studie warnt vor einer wachsenden Bedrohung durch ungeschützte, automatisierungsfähige KI-Endpunkte. Denkbare Szenarien reichen von Prompt-Injection und Identitätsverschleierung bis hin zur Zweckentfremdung der Rechenleistung, etwa für Spam- oder Desinformationskampagnen. Der entscheidende Punkt: Solche Aktivitäten müssten künftig nicht mehr über wenige zentrale Plattformen laufen, sondern könnten dezentral über viele Einzelinstanzen stattfinden – deutlich schwerer zu erkennen und nachzuverfolgen.

Die klare Empfehlung daraus: Wer lokale KI-Systeme betreibt, sollte sie sicherheitstechnisch wie klassische Server behandeln. Dazu gehören unter anderem Zugriffskontrollen, Monitoring, saubere Exponierung (oder besser gar keine direkte Internetfreigabe) sowie klar definierte Zuständigkeiten für Betrieb und Incident Response.