Wir programmieren jeden Tag mit KI. Unser eigenes Abrechnungs- und Betriebssystem InvoAIM hätten wir zu zweit sonst nicht gebaut — und es hat keinen Sinn, so zu tun, als ginge es ohne sie. Genau deshalb wissen wir aber, wo es hakt. Und es hakt nicht dort, wo man es erwartet.
Was KI im Code wirklich kaputt macht
Man erwartet, dass KI Tippfehler und Unsinn produziert. Genau das tut sie aber nicht. Der Code, den sie schreibt, kompiliert, die Tests laufen durch und die Demo funktioniert. Die Fehler, die sie macht, sind anderer Art:
- Fehlende Berechtigungsprüfung. Eine Funktion gibt eine Bestellung anhand der ID zurück. Dass es die Bestellung des angemeldeten Nutzers sein soll, hat niemand hingeschrieben — und die KI ergänzt es nicht von sich aus.
- Offene Schnittstellen. Ein Admin-Endpoint entstand beim Debuggen und blieb ohne Anmeldung erreichbar.
- Schlüssel im Repository. Ein API-Token wurde beim Ausprobieren fest in eine Datei geschrieben. Später wanderte er in eine Umgebungsvariable, aber in der Commit-Historie blieb er stehen.
- Veraltete Abhängigkeiten. Das Modell schlägt eine Bibliothek vor, die es aus den Trainingsdaten kennt — also eine, die vor zwei Jahren populär war.
Das alles sind Dinge, die man beim Überfliegen im Modus „sieht gut aus” nicht erkennt. Man muss gezielt danach suchen.
Zahlen statt Eindrücke
Es geht nicht um das Gefühl, dass „KI-Code schlechter ist”. Messungen aus dem Jahr 2025 sagen Folgendes:
- In 45 % der Aufgaben enthielt der KI-generierte Code eine Sicherheitslücke. Getestet wurden über 100 Modelle an 80 Aufgaben — Veracode.
- Repositories, die mit KI-Unterstützung geschrieben wurden, weisen bis zu zehnmal mehr Sicherheitsbefunde auf als andere — Apiiro.
Die zweite Hälfte der Gleichung ist das Volumen. Google und Microsoft geben öffentlich an, dass KI heute rund ein Viertel bis ein Drittel des neuen Codes erzeugt, bei einem Teil der jungen Unternehmen ist es die Mehrheit. Rechnen Sie sich das aus.
Bemerkenswert ist, dass sich die Fehlerquote pro Aufgabe gegenüber früheren Modellen nicht wesentlich verbessert hat. Die Modelle können mehr, sie schreiben besser lesbaren Code — aber Sicherheitsprüfungen ergänzen sie nur dann, wenn man sie ausdrücklich verlangt. Bessere Fähigkeiten lösen dieses Problem nicht von allein.
Warum Tests das nicht finden
Tests prüfen, ob die Anwendung tut, was sie soll. Bei Sicherheit geht es um das Gegenteil — was passiert, wenn jemand sie anders benutzt, als Sie es vorgesehen haben:
| Was wir testen | Was wir nicht testen |
|---|---|
| Nutzer sieht seine eigene Bestellung | Nutzer sieht eine fremde Bestellung |
| angemeldeter Admin öffnet die Administration | die Administration öffnet ein nicht angemeldeter Nutzer |
| ein Bild wird hochgeladen | ein in ein Bild umbenanntes Skript wird hochgeladen |
| das Formular speichert einen Namen | das Formular speichert ein Stück SQL-Abfrage |
Grüne Tests und eine offene Administration existieren völlig problemlos nebeneinander. Das eine sagt nichts über das andere aus.
Ab dem 11. September 2026 ändert sich das auch auf dem Papier
Bislang war die Prüfung von Code freiwillige Sorgfalt. Der Cyber Resilience Act macht daraus eine Pflicht mit Frist.
Die EU-Verordnung 2024/2847 gilt für Produkte mit digitalen Elementen, die auf dem EU-Markt bereitgestellt werden. Entscheidend ist, ob Sie Software weitergeben, nicht wie groß Sie sind:
- 11. 9. 2026 — die Meldepflichten beginnen. Eine aktiv ausgenutzte Schwachstelle oder einen schwerwiegenden Vorfall müssen Sie melden: erste Frühwarnung innerhalb von 24 Stunden, vollständige Meldung innerhalb von 72 Stunden, Abschlussbericht innerhalb eines Monats.
- 11. 12. 2027 — der Rest gilt: Sicherheit über den gesamten Lebenszyklus, technische Dokumentation, Konformitätsbewertung und CE-Kennzeichnung.
Damit eine Schwachstelle innerhalb von 24 Stunden gemeldet werden kann, muss jemand sie finden und beschreiben können. Das ist nichts, was Sie erst in dem Moment lösen, in dem es passiert.
Dazu kommt NIS2, die in Tschechien als Gesetz Nr. 264/2025 Sb. (tschechische Gesetzessammlung) gilt und rund sechstausend Unternehmen betrifft. Sie setzt die Lieferkette unter Druck — wenn Sie Software an ein reguliertes Unternehmen liefern, kommt die Kontrolle von dort, ganz gleich, ob die Vorschrift Sie direkt betrifft oder nicht.
Was Sie praktisch tun können
Wenn Sie nichts einkaufen wollen: Das hier schaffen Sie selbst, und es hat das beste Verhältnis von Nutzen zu Zeitaufwand:
- Gehen Sie die Commit-Historie nach Schlüsseln und Passwörtern durch. Nicht nur den aktuellen Stand — die Historie. Ein gefundenes Token muss ungültig gemacht werden, nicht gelöscht.
- Listen Sie alle Endpoints auf und beantworten Sie bei jedem: Wer kommt ohne Anmeldung daran?
- Prüfen Sie bei jedem Lesezugriff auf die Datenbank, dass nach dem angemeldeten Nutzer gefiltert wird, nicht nur nach der ID aus dem Request.
- Aktualisieren Sie die Abhängigkeiten und gehen Sie die bekannten Schwachstellen durch.
- Schalten Sie Debug aus — und ebenso Fehlermeldungen, die das Innenleben der Anwendung ausgeben.
Wenn Sie damit fertig sind, bleibt die zweite Hälfte: es belegen. Eine Notiz im Kopf ist keine Grundlage für den Auftraggeber und auch nicht für die Dokumentation nach dem CRA.
Wann Sie jemanden von außen holen sollten
Eigenen Code liest man schlecht — Sie wissen, wie er funktionieren sollte, und lesen das, was Sie beabsichtigt haben, nicht das, was dort steht. Ein externer Blick lohnt sich vor allem dann, wenn die Anwendung mit personenbezogenen Daten oder Zahlungen arbeitet, wenn Sie sie an den Auftraggeber übergeben, oder wenn jemand von Ihnen einen Nachweis verlangt, dass sie geprüft wurde.
Wir bieten eine Anwendungsprüfung vor dem Start an: maschineller Scan, manuelle Verifikation der Befunde und ein schriftliches Protokoll mit Verdikt. Den Code verarbeiten wir lokal in Tschechien, nicht in der Cloud eines Dritten — bei Quellcode ist das meist eine Bedingung, keine Laune.
Häufige Fragen
Heißt das, man sollte nicht mit KI programmieren?
Nein. Wir programmieren selbst täglich damit und hätten unser eigenes System ohne sie in diesem Tempo nicht gebaut. Das Problem ist nicht das Werkzeug, sondern das Verhältnis zwischen der Menge an Code, die entsteht, und der Menge, die jemand liest. Früher hielt die Schreibgeschwindigkeit dieses Verhältnis im Gleichgewicht. Heute hält es nichts mehr — es muss bewusst hergestellt werden.
Finden das die Tests nicht?
Meistens nicht. Tests prüfen, ob die Anwendung tut, was sie soll, wenn ein wohlmeinender Nutzer sie bedient. Bei Sicherheitslücken geht es darum, was passiert, wenn jemand sie anders benutzt: einen fremden Endpoint aufruft, eine andere ID schickt, eine Datei anderen Typs hochzuladen versucht. Grüne Tests und eine offene Administration existieren problemlos nebeneinander.
Gilt der Cyber Resilience Act auch für kleine Unternehmen?
Entscheidend ist, ob Sie ein Produkt mit Software auf den EU-Markt bringen, nicht wie groß Sie sind. Die Meldepflichten bei aktiv ausgenutzten Schwachstellen und schwerwiegenden Vorfällen gelten ab dem 11. September 2026, der Rest ab dem 11. Dezember 2027. Die Meldefristen betragen 24 Stunden für die erste Frühwarnung und 72 Stunden für die vollständige Meldung.