Ein KI-Coding-Tool ist kein gewöhnlicher SaaS-Einkauf. Es liest Ihren Quellcode, läuft häufig direkt in Ihrer Entwicklungsumgebung und gibt Daten an einen externen Modellanbieter weiter, alles bewusst so gebaut. Diese Kombination aus tiefem Zugriff und Datenabfluss nach außen macht es zu einem der vertrauensintensivsten Tools, die Sie Ihren Entwicklern in die Hand geben. Es verdient eine Sicherheitsprüfung, die zu dem passt, was es tatsächlich tut.
Wir begleiten Entwicklungsorganisationen bei genau solchen Prüfungen, und der häufigste Fehler ist immer derselbe: ein generischer SaaS-Fragebogen. Der stellt durchaus sinnvolle allgemeine Fragen. Aber genau die, die für ein Tool zählen, das Ihren Code aufnimmt und durch ein KI-Modell schickt, fehlen darin. Im Folgenden die Prüfung, die wir durchführen, geordnet nach den Fragen, die die Entscheidung wirklich kippen.
Zuerst den Datenfluss nachzeichnen
Bevor Sie irgendeinen Fragebogen aufschlagen, beantworten Sie eine Frage konkret: Wohin wandert Ihr Code, sobald eine Entwicklerin das Tool benutzt?
- Was geht an den Anbieter, was bleibt lokal? Ganze Dateien, der umliegende Kontext, das komplette Repository, oder nur die markierte Stelle?
- Läuft alles über einen Modellanbieter hinter dem Anbieter (etwa eine Foundation-Model-API), und zu welchen Bedingungen?
- Wo werden die Daten geografisch verarbeitet und gespeichert? Davon hängt ab, welches Compliance-Regime überhaupt greift.
- Was wird protokolliert und aufbewahrt, beim Anbieter und bei jedem Subprozessor, und wie lange?
Ein Risiko, das Sie nie nachgezeichnet haben, können Sie auch nicht bewerten. Die meisten wirklich relevanten Erkenntnisse fallen ab, wenn Sie diesen Fluss ehrlich aufzeichnen, noch bevor irgendjemand ein Formular ausfüllt.
Die Fragen, auf die es wirklich ankommt
Eine Handvoll Fragen trennt ein Tool, dem Sie vertrauen können, von einem, dem Sie es nicht können. Lassen Sie sich darauf klare, schriftliche Antworten geben.
| Frage | Warum sie zählt | So klingt eine gute Antwort |
|---|---|---|
| Wird unser Code zum Training von Modellen verwendet? | Training mit Ihrem Code kann firmeneigene Logik in die Ausgaben für andere Kunden durchsickern lassen. | „Nein, in Ihrem Tarif nicht, vertraglich zugesichert“, nicht „Sie können das in den Einstellungen abschalten“. |
| Was wird aufbewahrt, und wie lange? | Die Aufbewahrung bestimmt, wie groß Ihr Schaden ist, falls der Anbieter gehackt wird. | Kurze, konfigurierbare Aufbewahrung mit klarem Weg zur Löschung. |
| Wer kann intern auf unsere Daten zugreifen? | Zugriffe durch Anbieter-Mitarbeiter sind eine echte Angriffsfläche. | Zugriff nach dem Least-Privilege-Prinzip, protokolliert, ohne routinemäßiges Mitlesen von Kundencode durch Menschen. |
| Wo werden Daten verarbeitet und gespeichert? | Entscheidet über DSGVO-Pflichten und Datenresidenz. | Benannte Regionen zur Auswahl, mit EU-Optionen, falls Sie sie brauchen. |
| Welche Subprozessoren und Modellanbieter sind beteiligt? | Ihre Daten sind nur so sicher wie das schwächste Glied in der Kette. | Eine aktuelle Subprozessor-Liste samt deren Bedingungen, nicht „verschiedene Partner“. |
| Welche Zertifizierungen haben Sie? | Unabhängiger Nachweis, dass die Kontrollen tatsächlich existieren. | Aktuelles SOC 2 Type II oder ISO 27001, Bericht unter NDA verfügbar. |
Das verräterische Muster: Anbieter, die Fragen zu Training und Aufbewahrung mit einem Verweis auf einen Schalter in den Einstellungen abtun. Eine Einstellung lässt sich ändern, Voreinstellungen können kippen, und ein Schalter ist keine vertragliche Zusicherung. Bei einem Tool mit so viel Zugriff gehört der Schutz in den Vertrag, nicht in ein Einstellungsmenü.
Die Prüftiefe an das Deployment anpassen
Nicht jedes Tool braucht dieselbe Gründlichkeit. Wie tief Sie prüfen müssen, hängt davon ab, wie weit das Tool reichen kann.
| Deployment | Zugriffsumfang | Prüftiefe |
|---|---|---|
| Vorschläge im Editor | Liest den aktiven Kontext, schlägt inline vor | Standardprüfung: Datenverarbeitung, Training, Aufbewahrung |
| Repository-bewusster Assistent | Liest ganze Repositories als Kontext | Tiefere Prüfung: vollständige Datenfluss-Karte, Subprozessor-Kette, Datenresidenz |
| Autonomer Agent mit Ausführungsrechten | Führt Befehle aus, greift in die CI ein, kommt bis in die Produktion | Maximale Prüfung: alles Obige plus Umfang der Zugangsdaten, Audit-Logging, Not-Aus und durchdachte menschliche Freigaben |
Je tiefer ein Tool in Ihre Systeme hineinreicht, desto mehr ähnelt seine Sicherheitsprüfung der Frage, wie Sie jeden privilegierten Akteur steuern würden: eng gefasster Zugriff, minimale Rechte, lückenloses Audit-Logging und ein erprobter Weg, das Ganze zu stoppen. Ein Tool, das nur Text im Editor vorschlägt, ist ein deutlich kleineres Risiko als eines, das Pull Requests öffnen und mergen kann. Ihr Prüfaufwand sollte das abbilden.
Die Compliance-Ebene nicht überspringen
Für die meisten europäischen Teams sind Sicherheits- und Compliance-Prüfung ein und dasselbe Gespräch. Lassen Sie die zweite weg, reißen Sie eine Lücke, die spätestens im Audit auffällt.
- DSGVO. Können Ihr Code oder Kontext personenbezogene Daten enthalten, ist der Anbieter Auftragsverarbeiter, und Sie brauchen einen DPA, eine Rechtsgrundlage und dokumentierte Datenresidenz. Eine Sicherheitsprüfung, die das ausklammert, ist unvollständig.
- EU AI Act. Sobald das Tool Teil eines risikoreicheren Workflows wird, knüpfen Pflichten zu menschlicher Aufsicht und Dokumentation an die Art Ihres Einsatzes, nicht nur an den Anbieter.
- Ihre eigenen vertraglichen Zusagen. Vertraulichkeitsklauseln, die Sie mit Ihren Kunden vereinbart haben, können es schlicht verbieten, deren Daten überhaupt an einen Dritten zu geben. Der Datenfluss des Tools muss an diesen Versprechen gemessen werden.
Es geht nicht darum, Bürokratie aufzutürmen. Es geht darum, dass ein Tool, das Ihren Code liest, an Pflichten rührt, die Sie Regulierern und Kunden längst gegeben haben. Die Prüfung ist der Moment, in dem Sie bestätigen, dass diese Versprechen weiter tragen.
Daraus ein wiederholbares Gate machen
Eine einmalige Prüfung für ein einzelnes Tool skaliert nicht in einer Organisation, in der Teams laufend neue Tools entdecken. Machen Sie daraus ein standardisiertes, schlankes Gate.
- Ein kurzer Standardfragebogen, eigens für KI-Tools gebaut, nicht der generische SaaS-Fragebogen, den jedes Team vor einer Einführung durchlaufen kann.
- Eine klare Messlatte: was ein Tool erfüllen muss, um freigegeben zu werden, und was ein klares Nein bedeutet.
- Eine verantwortliche Stelle: eine benannte Person oder ein Team, das die Freigabe zeichnet, damit die Entscheidung greifbar verantwortet wird statt im Diffusen zu verschwimmen.
- Ein Register freigegebener Tools, damit Teams zu etwas bereits Geprüftem greifen, statt heimlich einzusetzen, was sie irgendwo gefunden haben. Die Alternative heißt Shadow AI, und die bekommen Sie im Nachhinein nur sehr schwer in den Griff.
Es ist derselbe Hebel, der in der KI-Governance auch sonst funktioniert: den sicheren Weg zum einfachsten Weg machen, damit niemand außen herum geht.
Unsere Sicht
Ein KI-Coding-Tool verdient eine gründlichere Sicherheitsprüfung als gewöhnliche Software, weil es tieferen Zugriff hat. Es liest Ihren Code, läuft in Ihrer Umgebung und schickt Daten bewusst nach außen. Der generische SaaS-Fragebogen wurde dafür nie geschrieben, und er verfehlt die entscheidenden Fragen: Wird unser Code zum Training genutzt, was wird aufbewahrt, wer kann ihn einsehen, wo liegt er, und wer steckt in der Kette hinter dem Anbieter?
Zeichnen Sie zuerst den Datenfluss nach. Lassen Sie sich zu Training und Aufbewahrung vertragliche Antworten geben, keine Einstellungsschalter. Passen Sie die Prüftiefe daran an, wie weit das Tool reichen kann. Beziehen Sie die Compliance-Pflichten ein, die Sie ohnehin tragen. Und gießen Sie das Ganze in ein wiederholbares Gate, damit es über das erste Tool hinaus skaliert.
Richtig gemacht, ist das kein Bremsklotz für die Einführung. Es ist genau das, was Sie schnell und mit gutem Gewissen Ja sagen lässt, weil Sie genau wissen, was Sie dem Tool anvertrauen und wo Sie die Grenze gezogen haben.
Quellen
- ISO/IEC 27001, Anforderungen an Managementsysteme für Informationssicherheit, abgerufen am 2026-06-11
- NIST,
AI Risk Management Framework (AI RMF 1.0), zu Drittanbieter- und Datenrisiken, abgerufen am 2026-06-11 - EUR-Lex, Verordnung (EU) 2016/679 (DSGVO), zu Auftrags- und Unterauftragsverarbeitern, abgerufen am 2026-06-11
- Cloud Security Alliance,
Consensus Assessments Initiative Questionnaire (CAIQ), abgerufen am 2026-06-11
</content> </invoke>
Häufige Fragen
- Wie prüft man ein KI-Coding-Tool sicherheitstechnisch?
- Beginnen Sie damit, den Datenfluss konkret zu kartieren – was an den Anbieter geht, was lokal bleibt, welcher Modellanbieter dahintersteckt, wo Daten gespeichert und was aufbewahrt wird. Holen Sie sich dann schriftliche Antworten zu Training, Aufbewahrung, internem Zugriff, Residenz, Unterauftragsverarbeitern und Zertifizierungen, und passen Sie die Prüftiefe daran an, wie weit das Tool in Ihre Systeme reichen kann.
- Was sollte man einen KI-Coding-Tool-Anbieter zu Daten fragen?
- Ob Ihr Code zum Training von Modellen genutzt wird, was wie lange aufbewahrt wird, wer intern darauf zugreifen kann, wo er verarbeitet und gespeichert wird, welche Unterauftragsverarbeiter und Modellanbieter in der Kette stecken und welche unabhängigen Zertifizierungen vorliegen. Bestehen Sie bei Training und Aufbewahrung auf vertraglichen Antworten, nicht auf einem Schalter, der sich ändern lässt.
- Reicht ein Standard-SaaS-Sicherheitsfragebogen für KI-Coding-Tools?
- Nein. Ein generischer Fragebogen stellt gute allgemeine Fragen, verfehlt aber die spezifischen für ein Tool, das Ihren Quellcode liest und durch ein KI-Modell leitet – Trainingsnutzung, Aufbewahrung, Modellanbieter als Unterauftragsverarbeiter und Datenresidenz. Nutzen Sie einen Fragebogen, der für KI-Tools gebaut ist, mit Tiefe, die zum Zugriff des Tools passt.
- Brauchen KI-Coding-Tools eine DSGVO-Prüfung?
- Für die meisten europäischen Teams ja. Können Ihr Code oder Kontext personenbezogene Daten enthalten, ist der Anbieter ein Auftragsverarbeiter, und Sie brauchen einen Auftragsverarbeitungsvertrag, eine Rechtsgrundlage und dokumentierte Residenz. Die Sicherheits- und die Compliance-Prüfung sind praktisch dasselbe Gespräch, und die zweite zu überspringen hinterlässt eine Lücke, die in einem Audit auftaucht.
