Sicherheitspflichten, die für Sie als unabhängigen Entwickler bereits gelten

Unter unabhängigen Entwicklern hält sich eine beharrliche Vorstellung, dass Sicherheits- und Datenschutzregulierung etwas ist, das Unternehmen betrifft – dass Pflichten erst beginnen, wenn man eine Gesellschaft gründet, einen Datenschutzbeauftragten einstellt oder einen Enterprise-Vertrag unterschreibt. Das stimmt nicht, und es stimmt schon seit Jahren nicht. Wenn Sie als Freelancer oder Indie-Entwickler Kundendaten verarbeiten, gelten schon heute mehrere Pflichten für Sie persönlich, bei Ihrer aktuellen Größe. Dieser Artikel geht durch, welche das sind, benennt die Regelungen, aus denen sie stammen, und endet mit der praktischen Frage, die wirklich zählt: Was genau ist gerade auf Ihren Accounts exponiert?

Eines wird dieser Artikel nicht tun: Ihnen sagen, dass irgendein Gesetz vorschreibt, ein Sicherheitstool zu kaufen. Kein Gesetz tut das. Was das Gesetz verlangt, ist, dass Sie wissen, was Sie mit den Daten tun, die Sie verarbeiten, und diese angemessen sichern – und der ehrliche Ausgangspunkt dafür ist zu wissen, welcher Zugriff auf den Accounts besteht, in denen Ihre Kundenarbeit lebt.

Unter der DSGVO ist ein Freelancer, der Kundendaten verarbeitet, ein Verarbeiter – mit direkten Pflichten

Wenn ein Kunde in der EU (oder ein Kunde, dessen Nutzer in der EU sind) Ihnen personenbezogene Daten übergibt – eine zu migrierende Nutzerdatenbank, ein zu debuggendes Produktivsystem, einen zu analysierenden Export – handeln Sie fast immer als Auftragsverarbeiter nach der DSGVO, und in manchen Engagements (wenn Sie entscheiden, was erhoben wird und warum) als Verantwortlicher. Keiner dieser Status setzt ein Unternehmen voraus. Die Definitionen der DSGVO in Artikel 4 knüpfen an „eine natürliche oder juristische Person" an – eine Person mit einem Laptop qualifiziert sich.

Dieser Status bringt direkte, persönliche Pflichten mit sich:

• Artikel 28 verlangt, dass Ihre Verarbeitung für einen Kunden durch einen Vertrag geregelt wird – die Datenverarbeitungsvereinbarung, die Ihre Enterprise-Kunden Ihnen immer wieder zusenden, ist kein bürokratisches Theater; sie ist eine gesetzliche Verpflichtung für Sie beide und bindet Sie an konkrete Sicherheitszusagen.
• Artikel 32 verlangt von Ihnen, „geeignete technische und organisatorische Maßnahmen" umzusetzen, um die personenbezogenen Daten, die Sie verarbeiten, zu sichern – angemessen zum Risiko, was auch die Kontrolle darüber einschließt, wer und was darauf zugreifen kann.
• Artikel 33 verlangt von einem Auftragsverarbeiter, den Verantwortlichen „unverzüglich" zu benachrichtigen, nachdem er von einer Verletzung des Schutzes personenbezogener Daten Kenntnis erlangt hat – was voraussetzt, dass Sie überhaupt in der Lage sind, davon Kenntnis zu erlangen.
• Artikel 82 gibt betroffenen Personen das Recht auf Schadenersatz von Verarbeitern für Schäden, die durch eine Verarbeitung verursacht wurden, die gegen die Verordnung verstößt, und Artikel 83 untermauert das gesamte Regelwerk mit Bußgeldern, die bei den schwersten Verstößen bis zu zwanzig Millionen Euro oder vier Prozent des weltweiten Jahresumsatzes erreichen können, je nachdem, welcher Betrag höher ist.

Niemand behauptet, dass der erste Schritt einer Aufsichtsbehörde gegen einen Freelancer der gesetzliche Höchstbetrag wäre. Der Punkt ist einfacher: Die Pflichten sind real, sie treffen Sie direkt, und „ich bin doch nur eine Person" ist nirgendwo im Text der Verordnung als Ausnahme anerkannt.

Der EU AI Act fügt Pflichten für Betreiber von KI-Systemen hinzu

Wenn Ihre Kundenarbeit inzwischen auch das Einbinden von KI in Produkte umfasst – ein Assistent in der App eines Kunden, ein KI-Agent, der einen Arbeitsablauf automatisiert, ein Modell, das Entscheidungen trifft, die Menschen betreffen –, ist der EU AI Act für Sie relevant. Das Gesetz reguliert nicht nur die Unternehmen, die Modelle trainieren; es legt auch Betreibern Pflichten auf – jenen, die KI-Systeme in eigener Verantwortung in einem beruflichen Kontext einsetzen.

Artikel 26 legt die Betreiberpflichten für Hochrisiko-KI-Systeme fest, darunter die Nutzung der Systeme entsprechend ihrer Gebrauchsanweisungen, die Sicherstellung angemessener menschlicher Aufsicht und die Überwachung des Betriebs. Artikel 4 verlangt sowohl von Anbietern als auch von Betreibern, ein ausreichendes Niveau an KI-Kompetenz bei den Personen sicherzustellen, die diese Systeme in ihrem Auftrag bedienen. Und Artikel 99 untermauert das Regelwerk mit Bußgeldern bei Nichteinhaltung. Welche Pflichten für ein konkretes Engagement gelten, hängt davon ab, was das System tut und in welche Risikokategorie es fällt – aber „ich habe es nur integriert, nicht selbst gebaut" ist genau die Rolle, für die die Kategorie des Betreibers geschaffen wurde.

Hier liegt eine praktische Ironie, die wir bei der Governance von KI-Agenten ständig sehen: Unabhängige Entwickler sind die intensivsten Anwender von KI-Coding-Agenten und Automatisierungs-Bots – und am wenigsten wahrscheinlich haben sie ein Inventar davon, worauf diese Agenten Zugriff haben. Wenn ein KI-Agent auf jedes Repository, das Sie besitzen, pushen kann, ist das eine Tatsache über Ihre Sicherheitslage, unabhängig davon, ob je eine Aufsichtsbehörde danach fragt.

Ihre Enterprise-Kunden sind bereits reguliert – und ihre Pflichten fließen zu Ihnen durch

Selbst wenn Sie nie mit EU-personenbezogenen Daten in Kontakt kommen und niemals ein KI-System einsetzen, gibt es eine dritte Quelle von Sicherheitspflichten, die für fast jeden Freelancer gilt, der mit Unternehmen jeder Größe zusammenarbeitet: Verträge. Enterprise-Kunden operieren unter SOC 2-Berichten, ISO 27001-Zertifizierungen, DSGVO-Artikel-28-Anforderungen an Auftragsverarbeiter und Vendor-Management-Programmen, die ihre Auditoren tatsächlich prüfen. Diese Programme unterscheiden nicht zwischen einem Anbieter mit 500 Mitarbeitern und einem Ein-Personen-Anbieter. Ein Anbieter ist ein Anbieter.

Deshalb trifft der Sicherheitsfragebogen immer wieder ein, bevor der Vertrag da ist. Ihr Kunde ist verpflichtet – durch sein Framework, seinen Auditor oder seine eigenen Kunden –, Sicherheitsnachweise von den Personen einzuholen, denen er Daten übergibt. Einschließlich Ihnen. Die Freelancer, die glaubwürdig antworten können („hier ist, was Zugriff auf meine Entwicklungsumgebung hat, so kontrolliere ich das, hier sind die Nachweise"), schließen diese Deals schneller ab als die, die improvisieren. Wir haben über die unternehmensseitige Version dieser Dynamik geschrieben in was Auditoren 2026 für KI-Governance verlangen; die anbieterseitige Version landet als Fragebogen auf Ihrem Schreibtisch.

Was ein Sicherheitsvorfall einen unabhängigen Entwickler tatsächlich kostet

Risikoeinordnung, denn das ist die ehrliche Einordnung: Ein Sicherheitsvorfall in einem Kundenprojekt kann eine direkte finanzielle Haftung nach der Freistellungsklausel Ihres Vertrags bedeuten, kann eine Auftragsverarbeiter-Haftung nach DSGVO-Artikel 82 bedeuten, wenn personenbezogene Daten betroffen waren, und – am konkretesten für einen Freelancer – kann das Ende der Kundenbeziehung und der damit verbundenen Referenz bedeuten. Für eine Ein-Personen-Beratung ist der Reputationswert das Geschäft. Nichts davon ist hypothetische Exotik; es ist die gewöhnliche Kausalkette an Konsequenzen, wenn ein kompromittiertes Zugangsdatum oder eine überberechtigte Integration zu einem Vorfall mit Kundendaten wird.

Was ist also gerade tatsächlich auf Ihrem Account exponiert?

Hier ist die unbequeme, konkrete Version der Frage. Ihre Kundenarbeit liegt fast sicher auf einem persönlichen GitHub-Account. Dieser Account hat sich über Jahre von Projekten hinweg angesammelt:

• Installierte GitHub Apps – Deployment-Bots, CI-Tools, KI-Assistenten – jede mit einer Berechtigungsvergabe, die Sie einmal genehmigt und wahrscheinlich nie wieder überprüft haben. Manche davon haben Schreib- oder Admin-Rechte auf alles, was Sie besitzen. Manche gehören zu Projekten, die 2024 endeten.
• Deploy Keys – unbeaufsichtigte SSH-Zugangsdaten, die auf Servern liegen, einige mit Schreibzugriff auf das Repository, das sie eigentlich nur lesen sollten. Wenn dieser Server kompromittiert wird, ist ein Lese-Schreib-Deploy-Key ein Weg zur Code-Injektion in das Produkt Ihres Kunden.
• Collaborators – Personen, die Sie während einer inzwischen beendeten Zusammenarbeit hinzugefügt haben und die immer noch Schreibzugriff besitzen, auch auf Repositories, die öffentlich sind.
• Repository-Exposition – welche Ihrer Repositories öffentlich sind und was darin steht, ist selbst eine Inventarfrage, die die meisten Entwickler nicht aus dem Gedächtnis beantworten können.

Jedes einzelne davon ist über die eigene API von GitHub maschinenlesbar, was bedeutet, dass jedes einzelne überprüfbar ist – nicht, indem man seinem Gedächtnis vertraut, sondern indem man erfasst, was heute tatsächlich Zugriff hat. Genau dieses Inventar erstellt der GitHub-Connector von 8200.dev jetzt auch für persönliche Accounts, nicht nur für Organisationen: Verbinden Sie Ihren eigenen GitHub-Login, und der Scan listet die installierten Apps und ihre Berechtigungsvergaben auf, die Deploy Keys und ob jeder davon nur lesend ist, die Collaborators je Repository und die Befunde, die sich aus diesem Graphen ergeben – den vergessenen Bot mit Admin-Rechten, den schreibfähigen Deploy Key, die veraltete App, die seit einem Jahr niemand mehr angefasst hat.

Die kostenlose persönliche Stufe führt den vollständigen Scan durch und zeigt Ihnen die schwersten Befunde; die kostenpflichtige persönliche Stufe – bepreist wie ein Abonnement für Code-Vervollständigung, nicht wie Enterprise-Software – schaltet die vollständige Liste mit kontinuierlicher Überwachung und Alarmen frei. Und wenn Sie zu einer Agentur mit Organisations-Account heranwachsen, skaliert derselbe Scan, dieselben Regeln und dieselbe Nachweiskette mit Ihnen mit – das ist die Organisationsseite des Produkts, und es ist derselbe Connector.

Die oben genannten Pflichten gelten für Sie, egal ob Sie jemals einen Scan durchführen. Was der Scan ändert, ist, ob Sie die Fragen beantworten können, die diese Pflichten implizieren – was Zugriff hat, warum, und was Sie mit dem Zugriff getan haben, den niemand rechtfertigen konnte. Beginnen Sie mit der kostenlosen Stufe, sehen Sie, was sich still auf Ihrem Account angesammelt hat, und entscheiden Sie von dort aus – die Preisgestaltung ist öffentlich, Self-Service, und startet bei null.

*Dieser Artikel ist allgemeine Information über Regelungen, die üblicherweise für unabhängige Entwickler gelten; er stellt keine Rechtsberatung dar, und wie jede Regelung auf Ihre konkrete Situation zutrifft, hängt von Tatsachen ab, die ein Scanner nicht kennen kann. Wenden Sie sich dafür an einen Anwalt.*