Ich mach´ mir die Welt, wie sie der KI gefällt
Die KI lässt einen an Pippi Langstrumpf denken, die sang: "Ich mach' mir die Welt, Widdewidde wie sie mir gefällt"!
Viele bauen sich heute ihre eigene "Welt" mit KI eigene Anwendungen. Das geht durchaus! Aber neben der Funktion gibt es weitere Aspekte.
Eine Frage ist, ob KI Software schneller oder besser bauen kann. Aber weitere Fragen sind, wer die Verantwortung für ein System übernimmt, das über Jahre laufen, integriert, abgesichert und weiterentwickelt werden muss.
KI beschleunigt aber dabei nicht nur Chancen, sondern auch bestehende Schwächen in Architektur, Qualitätssicherung und Governance.
Architektur und Design
KI-generierter Code kann zwar funktional sein, aber dennoch Wartbarkeits- und Sicherheitsprobleme enthalten. Studien und Praxisberichte verbinden KI-gestützte Entwicklung mit Code-Duplikation, fehlender Dokumentation, architektonischer Inkonsistenz, höherem Nachbesserungsaufwand und wachsendem technischem Debt. Hier einige Aspekte:
Aspekt | Kritische Frage | Risiko bei fehlender Steuerung |
Zielbild | Welches Geschäftsproblem löst die Anwendung wirklich — und ist Eigenbau dafür die richtige Antwort? | KI ermöglicht es, Lösungen für Symptome statt für strukturelle Probleme zu bauen. |
Architekturprinzipien | Gibt es verbindliche Standards für Module, Datenmodelle, APIs, Sicherheit und Skalierung? | Jede KI-Session erzeugt eine andere, möglicherweise widersprüchliche Architektur. |
Domänenwissen | Wer kennt die fachlichen Regeln, Ausnahmen und historischen Prozesse? | KI erzeugt plausibel klingende, aber fachlich unvollständige Logik. |
Modularität | Sind Funktionen klar getrennt und wiederverwendbar? | Schnell generierter Code kann Duplikate und unklare Abhängigkeiten erzeugen. |
Datenmodell | Wer definiert Datenherkunft, Datenqualität, Identifikatoren und Konsistenzregeln? | Fehlerhafte Datenmodelle sind später deutlich teurer zu korrigieren als Code. |
Skalierung | Was passiert bei mehr Nutzern, Daten oder Integrationen? | Ein Prototyp wird ohne Umbau zum produktionskritischen System. |
KI ist hervorragend darin, eine sichtbare Lösung schnell entstehen zu lassen. Sie ist dagegen schwach darin, implizites Organisationswissen, langfristige Architekturentscheidungen und fachliche Verantwortung zu ersetzen. Gerade unklare Anforderungen und fehlender Projektkontext führen zu architektonischen Inkonsistenzen und späteren Umbauten.
Verantwortung und Entscheidungsrechte
Dieser Aspekt mag bürokratisch wirken, aber er ist langfristig betrachtet sehr wichtig.
Produktverantwortung: Wer entscheidet, welche Funktionen gebaut werden, welche Prioritäten gelten und wann eine Lösung „fertig“ ist?
Technische Verantwortung: Wer ist Architekt, Tech Lead, Security Owner und Betreiber der Lösung?
Fachverantwortung: Wer validiert, dass Berechnungen, Freigaben, Berechtigungen oder Geschäftsregeln korrekt sind?
Betriebsverantwortung: Wer überwacht Verfügbarkeit, Fehler, Performance, Backups und Störungen?
Änderungsverantwortung: Wer genehmigt Änderungen am Produktivsystem?
Risikoverantwortung: Wer entscheidet, ob ein Fehler tolerierbar, ein Rollback nötig oder ein Vorfall meldepflichtig ist?
Ohne diese Rollen entsteht eine typische Falle: Viele Personen können KI-Code erzeugen, aber niemand ist eindeutig für das Gesamtsystem verantwortlich. Da US-NIST betont, dass sichere Softwareentwicklung organisatorische Vorbereitung, Schutz der Software, sichere Produktion und Reaktion auf Schwachstellen umfassen muss.
Wartung und Lebenszyklus
Nun ist die Lösung gebaut und alles läuft, was jetzt, was brauchen wir auf Dauer?
Codeverständnis: Versteht das Team den generierten Code wirklich — oder akzeptiert es nur, dass Tests grün sind?
Dokumentation: Sind Architekturentscheidungen, Annahmen, Schnittstellen und Betriebsverfahren dokumentiert?
Abhängigkeiten: Wer überwacht Bibliotheken, Frameworks, Laufzeitumgebungen und KI-Anbieter auf Sicherheitslücken und End-of-Life?
Tests: Gibt es automatisierte Tests, die nicht nur Funktionen, sondern auch Sicherheits-, Berechtigungs- und Fehlerfälle prüfen?
Refactoring: Wird regelmäßig Zeit für Aufräumarbeiten eingeplant — oder wird nur neue Funktionalität produziert?
Wissenssicherung: Was passiert, wenn die Person geht, die die Prompts, Architekturentscheidungen oder Integrationsdetails kannte?
Versionierung: Sind Code, Konfiguration, Infrastruktur, Prompts, Modelle und Datenversionen nachvollziehbar versioniert?
Die scheinbare Einfachheit von „Prompt rein, Anwendung raus“ verdeckt einen Kernunterschied: Software ist kein einmaliges Artefakt, sondern ein lebendes System. KI-generierter Code muss ebenso geprüft, korrigiert und über den gesamten Lebenszyklus gepflegt werden wie menschlich geschriebener Code; andernfalls wird er zu einem Wartungs- und Risikofaktor.
Schnittstellen und Integrationen
Softwaremanagement in einem breiten Bereich ist gefragt, es gibt viele Aspekte:
Schnittstellenverantwortung: Wer besitzt eine API — der erzeugende Fachbereich, die IT oder der externe Systemverantwortliche?
Verträge: Sind Datenformate, Fehlerfälle, Versionen, Rate Limits und Verfügbarkeiten verbindlich definiert?
Rückwärtskompatibilität: Was passiert, wenn ein angebundenes System sich ändert?
Identitäten und Berechtigungen: Wie erfolgt Authentifizierung, Autorisierung und Protokollierung über Systemgrenzen hinweg?
Datenflüsse: Welche Daten verlassen das Unternehmen, welche bleiben intern, welche werden pseudonymisiert oder gelöscht?
Fehlerverhalten: Was geschieht, wenn ein externes System ausfällt, falsche Daten liefert oder langsam antwortet?
Monitoring: Wer erkennt, dass eine Integration still und leise falsche Ergebnisse produziert?
Besonders riskant sind „schwebende“ Integrationen: KI kann eine Schnittstelle schnell anbinden, aber niemand dokumentiert, wer bei einer Änderung des Fremdsystems reagieren muss. NIST empfiehlt, Eingaben und Ausgaben einschließlich Prompts sorgfältig zu validieren, zu protokollieren und auf Sicherheitsrisiken hin zu behandeln.
Sicherheit und Compliance
Gerade die Sicherheit ist oft eine "Nebenanforderung" und es muss berücksichtig werden, wie man die Lösung sicher macht und Sicherheit aufrechterhält.
Threat Modeling: Wurde vor dem Bau geprüft, welche Angriffsflächen und Missbrauchsszenarien bestehen?
Least Privilege: Haben Anwendungen, KI-Agenten und Nutzer nur die minimal erforderlichen Rechte?
Secrets Management: Wo liegen Zugangsdaten, API-Keys und Zertifikate — und wer kann sie einsehen?
Supply Chain: Sind Abhängigkeiten, Container, Bibliotheken und KI-Komponenten auf Herkunft und Schwachstellen geprüft?
Protokollierung: Lassen sich Entscheidungen, Zugriffe, Änderungen und Fehler rekonstruieren?
Daten-Schutz: Werden interne, personenbezogene oder vertrauliche Daten an externe Modelle übermittelt?
Verantwortliche KI-Nutzung: Gibt es Regeln dafür, welche Aufgaben KI übernehmen darf und wo menschliche Freigabe zwingend ist?
KI-Verordnung: Haben wir eine Anwendung, die unter die KI-VO fällt? Haben wir eine Lösung für ggf. anfallende aufgaben des Meldens oder müssen wir Konformität bedenken?
Produkthaftung und CRA: Habe ich alle Daten, um bei Fragen zur Haftung entlastende Nachweise führen zu können und kann ich den Meldepflichten aus dem CRA nachkommen?
Das US-NIST beschreibt spezifische KI-Risiken wie Prompt Injection, Datenvergiftung, unbefugte Informationspreisgabe, Manipulation von Modellen und erweiterte Angriffsflächen. Deshalb dürfen KI-generierte Anwendungen nicht automatisch denselben Vertrauensgrad erhalten wie geprüfte Standardsoftware.
Produktqualität und Betrieb
Und wie stellen wir sicher, daß der Produktivbetrieb stressfrei wird?
Nicht-funktionale Anforderungen: Sind Performance, Verfügbarkeit, Barrierefreiheit, Usability, Skalierbarkeit und Wartbarkeit definiert?
Fehlerbehandlung: Was geschieht bei ungültigen Eingaben, Netzwerkproblemen, Berechtigungsfehlern oder unerwarteten Daten?
Testabdeckung: Werden kritische Pfade, Randfälle, Rollbacks und Berechtigungen getestet?
Observability: Können Betreiber erkennen, ob das System korrekt arbeitet — oder sehen sie nur, dass es „läuft“?
Notfallfähigkeit: Gibt es Backups, Wiederherstellungspläne, Rollbacks und dokumentierte Störfallprozesse?
Nutzerfeedback: Wie werden Fehler, Umgehungslösungen und unerwartete Nutzung durch Beschäftigte erkannt?
KI-Verordnung und Qualität gem. DIN EN 18286: Haben wir ein belastbares Qualitätsmanagement für die Anwendung, das die genannte Norm unterstützt?
KI-generierte Build- und Infrastrukturdateien können etwa fehlende Fehlerbehandlung, harte Pfade, veraltete Abhängigkeiten oder unvorhersehbare Versionsmuster enthalten. Das zeigt: Auch „nur eine kleine interne Lösung“ kann Betriebsrisiken erzeugen.
Kosten und ROI
Kurzfristiger Eindruck | Langfristige Realität |
„Die Anwendung ist in Tagen fertig.“ | Architektur, Sicherheit, Tests, Integration und Betrieb brauchen weiterhin Fachkompetenz. |
„Wir sparen Lizenzkosten.“ | Es entstehen Kosten für Wartung, Fehlerbehebung, Sicherheitsupdates, Dokumentation und Personalknow-how. |
„KI schreibt den Code.“ | Menschen müssen den Code verstehen, prüfen, korrigieren und verantworten. |
„Ein Prototyp genügt.“ | Prototypen werden oft still zu produktionskritischen Systemen, ohne die nötige Absicherung. |
„Jeder kann entwickeln.“ | Bürgerentwicklung braucht umso stärkere Guardrails, Freigabeprozesse und Supportstrukturen. |
KI kann die Entwicklungskosten senken, aber sie verschiebt oft Kosten von der Erstentwicklung in Betrieb, Qualitätssicherung, Sicherheitsprüfung und Wartung. Gartner weist ausdrücklich darauf hin, dass Zeitersparnisse durch Prüfung, Fehlerbehebung, Sicherheitsarbeit und Wartung ganz oder teilweise aufgezehrt werden können.
Organisatorische Leitplanken
Eine sinnvolle Governance sollte nicht KI verbieten, sondern ihre Nutzung einhegen:
Architektur-Board oder Tech-Radar: Verbindliche Standards für Sprachen, Frameworks, Datenmodelle, APIs und Cloud-Dienste.
Definition of Done: Keine Produktivfreigabe ohne Code-Review, Tests, Sicherheitsprüfung, Dokumentation und Betriebsübergabe.
KI-Richtlinie: Welche Aufgaben dürfen KI-Tools übernehmen, welche Daten dürfen verwendet werden, welche Modelle und Anbieter sind zulässig?
Mensch - Human in the loop: Kritische Freigaben, Zugriffsrechte, Finanz- oder Sicherheitsentscheidungen bleiben menschlich kontrolliert.
Sandbox-first: Neue Lösungen starten in einer kontrollierten Umgebung mit begrenzten Daten und Rechten.
Produkt Ownership: Jede Anwendung hat einen klar benannten fachlichen und technischen Owner.
Lebenszyklus-Budget: Wartung, Refactoring, Tests und Sicherheitsupdates werden von Anfang an eingeplant.
Exit-Strategie: Es muss vorab geklärt sein, wie Daten, Code und Betrieb bei Anbieterwechsel oder Projektende überführt werden.
Normen: Es muss geklät werden, wie sich die Lösung mit den managementsystemen verträgt, z. B. ISO 27001 wg. Sicherheit und ISO 42001 wg. KI-Management.
Das US-NIST empfiehlt, KI-spezifische Praktiken in den gesamten Softwareentwicklungszyklus zu integrieren — von Planung über sichere Entwicklung bis zu Schwachstellenreaktion.
Mögliche Diskussionsfragen
Die Dynamik, die dank KI entstanden ist, sollte man nutzen, aber die Diskussionen dazu sind wichtig, hier einige mögliche Themen:
Ist „jeder kann mit KI Software bauen“ ein Demokratisierungsfortschritt — oder eine Verlagerung von IT-Risiken in Fachbereiche ohne ausreichende Kontrolle?
Sollte es eine Schwelle geben, ab der interne KI-Lösungen reguläre Produktentwicklungsstandards erfüllen müssen?
Wer sollte bei KI-generierter Software die technische Gesamtverantwortung tragen: Fachbereich, IT, Security, Datenschutz oder Management?
Reichen Tests aus, um KI-Code freizugeben — oder braucht es zusätzlich Architektur- und Sicherheitsreviews?
Wie verhindert man, dass „schnell gebaute“ Tools zu unkritischen Schatten-IT-Systemen werden?
Ist Eigenbau mit KI langfristig günstiger als der Kauf und die Anpassung einer professionell gewarteten Standardlösung?
Welche Kompetenzen dürfen in einer Organisation nicht an KI delegiert werden?
Und viele mehr......
Fazit
KI-Lösungen existieren nicht im freien Raum. Auch wenn heute - fast - jeder schnell eine Anwendung bauen kann, die eine konkrete Aufgabe gut abdeckt, muss man sich das mit Blick auf die gesamte Organisation gut überlegen. Denn betreiben, absichern, warten und weiterentwickeln kann sie nur eine Organisation, die Architektur, Verantwortung und Lebenszyklus steuert. Ein KI-Managementsystem auf Basis ISO 42001 hilft dabei!
Gerne helfen wir Ihnen bei der Umsetzung, sprechen Sie uns an!
Lesenswert:
Das NIST hat zur KI ein gut verständliches Framework für das Risikomanagement entwickelt.
