Wenn der CISO fragt, ob KI-generierter Code sicher ist: ab heute gibt's eine Antwort

In jedem zweiten Verkaufsgespräch der letzten zwölf Monate fiel irgendwann der eine Satz vom IT-Verantwortlichen: „Aber ist KI-generierter Code überhaupt sicher?"

Bis gestern war unsere Antwort eine Kombination aus drei Argumenten: Der Kunde besitzt den Code, kein Vendor Lock-in. Wir bauen DSGVO-konform und EU-AI-Act-ready. Wir liefern technische Dokumentation. Solide, ja, aber es war unsere Antwort. Keine externe.

Seit heute gibt es eine externe Antwort. Am 13. Mai 2026 hat Lovable gemeinsam mit der AIUC-Foundation den ersten Security-Standard veröffentlicht, der speziell für KI-Coding-Agents entwickelt wurde: AIUC-1. Lovable ist die erste Plattform dieser Kategorie, die das Audit anstrebt, durchgeführt von Schellman, einer Compliance-Firma mit tiefer Security-Expertise. Audit-Termin: Sommer 2026.

Für uns und für jedes Unternehmen, das auf einer AI-First-Plattform aufbaut, verändert das die Diskussion fundamental.

Warum es einen eigenen Standard für Coding-Agents braucht

Bisherige AI-Sicherheitsframeworks waren auf Chatbots ausgelegt. Ein Chatbot produziert Text, den ein Mensch liest und bewertet. Ein Coding-Agent produziert ausführbare Artefakte: Source Code, Datenbank-Schemas, API-Konfigurationen, deployte Applikationen. Der Unterschied ist nicht akademisch.

Drei Zahlen aus dem Whitepaper, die selbst routinierten Security-Teams die Sprache verschlagen:

Konkretes Beispiel aus dem Feld: Ein halluziniertes Package namens huggingface-cli wurde innerhalb von drei Monaten über 30.000 Mal heruntergeladen. Ein halluziniertes npm-Package namens react-codeshift verbreitete sich durch 237 Repositories via KI-generierte Agent-Skill-Dateien. Das ist keine Theorie, sondern die Live-Bedrohungslage.

Im April 2026 zeigte der "Comment and Control"-Angriff, wie versteckte Prompt-Injection-Instruktionen in Code-Kommentaren und Pull-Request-Beschreibungen Claude Code, Gemini CLI und GitHub Copilot dazu bringen konnten, ihre eigenen API-Keys zu exfiltrieren. Diese Angriffsfläche existiert bei einem klassischen Chatbot nicht.

Drei kompoundierende Dimensionen

• Output-Surface ist ausführbar: Eine halluzinierte Tatsache im Chatbot ist eine Unannehmlichkeit. Ein halluziniertes Authentication-Pattern im generierten Code ist eine Vulnerability in Produktion.
• Input-Surface ist riesig und untrusted: Coding-Agents ziehen Kontext aus Dokumentation, MCP-Server-Tool-Descriptions, Third-Party-Dependency-Metadaten. Jede dieser Quellen kann manipuliert werden.
• Action-Surface ist breit und persistent: Ein Agent operiert mit erhöhten Privilegien, Credentials, Production Secrets, Infrastruktur-Configs. Eine Prompt Injection kann Deployment-Skripte ändern oder Backdoors einfügen, die automatische Reviews passieren.

Das ist die Welt, für die AIUC-1 gebaut wurde.

Was im Standard drinsteht

AIUC-1 ist kein PDF mit Best Practices. Es ist ein auditierbarer Compliance-Standard mit klarer Struktur:

• 6 Kern-Prinzipien: Security, Safety, Reliability, Accountability, Society, Data & Privacy
• 51 Requirements über diese sechs Prinzipien
• 1 bis 5 Controls pro Requirement
• 75 coding-agent-spezifische Risiken in 13 thematischen Kategorien, identifiziert mit Input des AIUC-1-CISO-Konsortiums

Die Risiken bündeln sich in sieben prioritäre Domänen. Diese Liste ist genau das, was jeder IT-Leiter sehen will, bevor er eine KI-Plattform freigibt:

Wer schon einmal eine TISAX-, ISO-27001- oder NIS2-Roadmap aufgesetzt hat, erkennt die Struktur. Es ist genau dieselbe Logik, nur auf KI-Agents zugeschnitten.

Die wichtigste Innovation: das Evidence-Modell

Was AIUC-1 von einer Selbstverpflichtung unterscheidet, ist die Vorgabe, wie nachgewiesen werden muss. Jedes Control verlangt vier Kategorien an Evidence:

• Policy Evidence: Terms of Service, Privacy Policies, DPAs, Acceptable-Use-Policies. Dort, wo Commitments wie "wir trainieren nicht auf Kundendaten" verbindlich werden.
• Technical Evidence: Die tatsächliche Implementierung, System-Prompt-Guidance, Filter-Logik, IAM-Configs, Sandbox-Policies, Credential-Detection-Code, Logging. Wo ein Auditor Code prüft, nicht Slides.
• Operational Evidence: Interne Prozesse, Change-Management, Incident-Response, quartalsweise interne Reviews, Vendor-Due-Diligence.
• Third-Party Red-Teaming: Mindestens quartalsweise. Geprüft auf adversarielle Robustheit, harmful output, Halluzinationen, Tool-Call-Safety. Genau dieses Element verhindert Selbstzertifizierung.

Das Audit selbst läuft über einen akkreditierten Drittprüfer. Bei Lovable: Schellman. Im Sommer 2026.

> Demand evidence. Ask for the controls. Ask for the test results. Ask for the audit report.

Das ist die neue Sprache, die in jeder Ausschreibung stehen wird.

Was das konkret für ChangeMy.AI bedeutet

Für uns ändert AIUC-1 vier Dinge auf einen Schlag.

Erstens, die Sicherheitsfrage hat ab sofort eine externe Antwort. Wir können in jedem Pitch sagen: Wir bauen auf einer Plattform, die als erste ihrer Kategorie den Security-Audit nach AIUC-1 durchläuft. Audit durch Schellman, Termin Sommer 2026. Überprüfbar, nicht Marketing.

Zweitens, die 7 Priority Domains sind unser neuer Architektur-Leitfaden. Viele dieser Patterns sind bei uns standardmäßig verankert: Tenant-isolierte Storage, parametrisierte Queries, HttpOnly-Cookies, MCP-Allow-Lists, Audit-Logs. Was jetzt dazukommt, ist ein konsistentes Vokabular gegenüber Compliance-Abteilungen und Auditoren.

Drittens, Code Ownership wird stärker, nicht schwächer. Manche fragen, ob die wachsende Plattformverantwortung von Lovable das Argument der Code-Eigentümerschaft schwächt. Das Gegenteil ist der Fall. Lovable zertifiziert die Generierungs-Pipeline. Der erzeugte Code läuft anschließend in deiner Infrastruktur, in deinem Repository, mit deinen Credentials. Du bekommst eine sicherheitszertifizierte Bauumgebung, das Bauwerk gehört dir.

Viertens, wir können beim Pitch direkt aus dem Whitepaper zitieren. Die drei Risiko-Dimensionen, die 7 Priority Domains und das Evidence-Modell sind Material, das auf jedem CISO-Tisch funktioniert.

Was das konkret für unsere Kunden bedeutet

Für KMU und mittelgroße Unternehmen, die ihre Software-Landschaft mit uns modernisieren, ändert sich nichts an unserer Versprechensstruktur, sie wird belastbarer:

• 40 bis 60 % Kostenersparnis gegenüber Legacy-Software bleibt bestehen.
• 60 bis 120 Tage Deployment bleibt bestehen.
• Code-Eigentümerschaft, kein Vendor Lock-in, keine Lizenzgebühren bleiben bestehen.

Was neu hinzukommt: Ihre IT-Abteilung, ihr Datenschutzbeauftragter, ihr Wirtschaftsprüfer und jeder externe Auditor bekommen ab sofort eine standardisierte Sprache, mit der sie die Sicherheitsarchitektur prüfen können. Statt einer Diskussion über das Risiko "KI" gibt es eine Liste von 51 Requirements, deren Erfüllung wir am konkreten Projekt durchgehen.

Für regulierte Branchen ist das besonders relevant: ein Ziviltechniker mit ZTG-Dokumentationspflicht, ein Industriebetrieb mit TISAX-Anforderung, ein Verband mit DSGVO- und EU-AI-Act-Transparenzpflichten, ein Energieversorger mit NIS2-Abdeckung. AIUC-1 bildet die KI-spezifischen Risiken auf eine prüfbare Struktur ab, die mit den bestehenden Compliance-Anforderungen kompatibel ist.

Ihre AIUC-1-Readiness in 7 Schritten

Was als Nächstes passiert

In den kommenden Wochen passieren bei uns drei Dinge. Wir nehmen den AIUC-1-Status von Lovable in unsere Standard-Pitch-Decks und Angebotsanhänge auf, sobald das Audit-Datum konkretisiert ist. Wir gehen alle aktiven Kundenprojekte gegen die 7 Priority Domains durch und dokumentieren pro Projekt, welche Controls bereits umgesetzt sind. Und wir bauen einen Kunden-Anhang "Sicherheitsarchitektur nach AIUC-1", den wir bei Bedarf als Beilage zu Verträgen mitschicken.

Wer gerade mit uns über ein Projekt verhandelt oder über eines nachdenkt, kann ab sofort danach fragen. Wir haben Antworten.

Die Sicherheitsfrage hat eine neue Welt betreten. Wir sind drinnen.