Lernen Sie AI langsam

Ihre größte Fehlentscheidung: Keine CLAUDE.md

Ein CIO einer Aktienbank beschwerte sich bei mir: “Wir haben AI-Tools gekauft, Modelle bereitgestellt und Mitarbeiter geschult, aber in den ersten sechs Monaten des Jahres 2026 haben sich die Lieferzeiten kaum verbessert.” Der Leiter der Kernsystemgruppe war noch direkter: “Der von AI generierte Code ist zwar verwendbar, aber wir müssen ihn jedes Mal neu schreiben, weil er unsere Unternehmensregeln nicht versteht, die regulatorischen Anforderungen nicht kennt und nicht weiß, wie er mit unserem 30 Jahre alten Legacy-System zusammenarbeitet.”

Quellen:

CodeRabbit 2025.12
New Relic 2026 Report
Microsoft Work Trend Index 2026
Microsoft FY26 Frontier Firms Ankündigung
GitHub Spec Kit
AWS Kiro
OpenAI Codex
Claude Code
Alibaba Qoder
JetBrains 2026.1 AI Pulse

Die Beispiele sind repräsentative Szenarien und beziehen sich nicht auf spezifische Unternehmen.

Das Problem liegt nicht darin, dass AI nicht stark genug ist, sondern dass Sie die Regeln nicht aufgeschrieben haben. Eine Analyse von CodeRabbit aus dem Dezember 2025, die 470 Open-Source-PRs umfasste, ergab eine weit verbreitete Zahl: AI-gestützte PRs enthalten im Durchschnitt 10,83 Probleme, während rein manuelle PRs 6,45 Probleme aufweisen - 1,7-mal mehr, was 70% mehr Bugs bedeutet. Bis 2026 hat sich die Geschichte nicht geändert: New Relic stellte in seinem Bericht “2026 State of AI Coding Report” fest, dass 78% der Teams nach der Veröffentlichung von AI-Code mehr Unfälle meldeten und 62% der technischen Leiter zugaben, dass ihre Teams “sich selbstbewusst entschieden, AI-Code ohne Zeile für Zeile zu überprüfen, direkt zu veröffentlichen” (New Relic-Bericht 2026, 0,866 Punkte, erste Quelle). Beide Zahlen sagen das Gleiche aus - AI fehlt es nicht an Fähigkeiten, sondern an Kontext.

Im August 2026 müssen alle Erzählungen über “AI-Transformation beschleunigen” im Vergleich zu diesen Zahlen gesehen werden:

Lernen Sie AI langsam

I. Einführung

In der heutigen digitalen Welt ist die Automatisierung von Geschäftsprozessen eine wichtige Herausforderung für Unternehmen in verschiedenen Branchen. Die Verwendung von AI-Technologien kann dabei helfen, die Effizienz und Produktivität zu steigern, aber auch die Komplexität der Systeme zu erhöhen.

II. Die Rolle von EY, Atos und Microsoft

In diesem Abschnitt werden wir drei Unternehmen vorstellen, die in der AI-Erforschung und -Anwendung eine führende Rolle spielen.

EY

Projekt: Microsoft 365 Copilot
Ziel: Die Implementierung von Microsoft 365 Copilot in 150.000 Mitarbeiter und die Erzielung von 2,5 Milliarden US-Dollar an Einsparungen
Ergebnis: Die Implementierung von Microsoft 365 Copilot in 150.000 Mitarbeiter und die Erzielung von 2,5 Milliarden US-Dollar an Einsparungen

Atos

Projekt: Implementierung von Microsoft 365 Copilot in 54 Länder und 56.000 Mitarbeiter
Ziel: Die Implementierung von Microsoft 365 Copilot in 54 Länder und 56.000 Mitarbeiter und die Erzielung von 19.000 AI-Agenten
Ergebnis: Die Implementierung von Microsoft 365 Copilot in 54 Länder und 56.000 Mitarbeiter und die Erzielung von 19.000 AI-Agenten

Microsoft

Projekt: 2026 Work Trend Index
Ziel: Die Implementierung von AI-Agenten in 12-18 Monaten und die Erzielung von 82% der Führungskräfte
Ergebnis: Die Implementierung von AI-Agenten in 12-18 Monaten und die Erzielung von 82% der Führungskräfte

III. Schlussfolgerung

Die Verwendung von AI-Technologien kann dabei helfen, die Effizienz und Produktivität zu steigern, aber auch die Komplexität der Systeme zu erhöhen. Die Implementierung von Microsoft 365 Copilot in 150.000 Mitarbeiter und die Erzielung von 2,5 Milliarden US-Dollar an Einsparungen ist ein wichtiger Schritt in Richtung einer effizienteren und produktiveren Zukunft.

Langsam lernen Sie AI

Als Forschungsberater für IAIUSE (für CIO und Entscheidungsträger in den Branchen Telekommunikation, Finanzen, Produktion und E-Commerce) möchten wir Ihnen in diesem Blog drei wichtige Punkte klären:

Warum die Fehler in AI-Codes um das 1,7-fache höher sind als bei menschlicher Arbeit.
Wie GitHub, AWS, OpenAI, Anthropic und Alibaba in der ersten Hälfte des Jahres 2026 zu einer gemeinsamen Praxis gelangten - nämlich die Verwendung von Dokumenten, um das Verhalten von AI zu steuern.
Warum die Spezifikationsgetriebene Entwicklung (SDD) eine Frage der organisatorischen Fähigkeit ist und nicht der Wahl der Werkzeuge, sowie die drei Phasen der Umsetzung in der ersten Hälfte des Jahres 2026.

Unsere Ausführungen basieren auf den Microsoft FY26-Rückblicken vom 28. Juli 2026 und dem Microsoft 2026 Work Trend Index Annual Report vom 5. Mai 2026, sowie dem New Relic 2026 State of AI Coding Report.

Keine Normen, keine Skalierung - nur Risiken multipliziert

Zwei Vergleichsbeispiele zeigen, dass ohne Normen die Skalierung zu einem Multiplikator der Risiken wird. Die “Schnelligkeit” von EY, Atos und Microsoft bezieht sich nicht auf die Geschwindigkeit der Modelle, sondern auf die Fähigkeit der Organisationen, die Fragen zu beantworten, wie sie mit AI umgehen sollen. Dies ist der Hintergrund für die Spezifikationsgetriebene Entwicklung (SDD), die in der ersten Hälfte des Jahres 2026 in den Mainstream getreten ist - nicht wegen der Vorliebe der Entwickler für Dokumentation, sondern weil die Nichterstellung von Normen in einem Umfeld mit 19.000 Agenten nicht mehr lebensfähig ist.

Die drei Punkte

In diesem Blog werden wir Ihnen drei wichtige Punkte klären:

Warum die Fehler in AI-Codes um das 1,7-fache höher sind als bei menschlicher Arbeit.
Wie GitHub, AWS, OpenAI, Anthropic und Alibaba in der ersten Hälfte des Jahres 2026 zu einer gemeinsamen Praxis gelangten - nämlich die Verwendung von Dokumenten, um das Verhalten von AI zu steuern.
Warum die Spezifikationsgetriebene Entwicklung (SDD) eine Frage der organisatorischen Fähigkeit ist und nicht der Wahl der Werkzeuge, sowie die drei Phasen der Umsetzung in der ersten Hälfte des Jahres 2026.

Balkenlänge = KI-Fehler als Vielfaches menschlicher; Basislinie 1.0× = menschliches Niveau

Basis 1.0×

Gesamtzahl der Probleme

1.7×
KI 10,83 vs. menschlich 6,45 / PR

Logik-/Korrektheitsfehler

1.75×

Codequalität / Wartbarkeit

1.64×

Sicherheitsbefunde (kombiniert)

1.57×

Unsachgemäße Passwortbehandlung

1.88×

XSS-Schwachstellen

2.74×
↑ Höchste

KI-Code ohne Normen liegt in jeder Dimension über menschlichem
Finanz/Telekom = Compliance-Abgleich, Passwortverwaltung, sensible Feldverschlüsselung – KI sieht nichts davon

Slow Learning AI - Teil 1: AI-Feherträte sind kein Modellproblem, sondern ein Kontextproblem

Ein Ausspruch von CodeRabbit wurde oft zitiert: “AI mangelnde Unternehmenslogik: Modelle werden nach statistischen Voraussagen programmiert, nicht nach semantischer Verständigung. Ohne strenge Einschränkungen verpassen sie die systematischen Regeln, die erfahrene Entwickler in sich aufgenommen haben.”

Dieser Ausspruch erklärt, warum CodeRabbit, ein Unternehmen, das sich auf die Überprüfung von AI-Code spezialisiert hat, diese Daten so früh entdeckt hat – sie sehen jeden Tag Tausende von Pull-Anfragen und sehen, wie AI-Code aussieht. Der wichtigste Befund ist nicht die Gesamtzahl, sondern die Verteilung:

Logik/Correctness +75%: Unternehmenslogikfehler, Abhängigkeitsfehler, Steuerungsflussfehler, Konfigurationsfehler – diese Probleme werden in Tests möglicherweise nicht offensichtlich, aber sie führen in der Produktionsumgebung zu Unfällen.
Code-Qualität +64%: Namenskonflikte, unklare Struktur, Verletzung von Projektmustern – dies ist die “größte Differenzklasse”. Erfahrene Entwickler erkennen sofort: “Das ist nicht unsere Schreibweise”.
Sicherheit +57% (XSS-Klasse höchstens 2,74×): Falsche Passwörterverarbeitung (1,88×), unsichere Objektreferenzen (1,91×), sensible Informationenleakage, unsichere Deserialisierung (1,82×) – in der Finanzbranche ist dies nicht “kann man es benutzen?”, sondern “kann man es ausgeben?”.

Quellen:

CodeRabbit: bericht
CodeRabbit

Lernen Sie KI langsam: Warum KI-Code nicht funktioniert

Ein CIO eines Finanzunternehmens hatte ein Problem: Die KI-Code-Generatoren funktionierten nicht wie erwartet. Die Ursache lag jedoch nicht in der Stärke der KI selbst, sondern darin, dass sie bestimmte Dinge nicht sehen konnte.

Drei konkrete Fehler in der Finanzindustrie

KI sieht 30 Jahre alte Abrechnungslogik nicht. Die Windhundregeln der Banken sind in den Speicherprozeduren des Kernsystems geschrieben - vor 30 Jahren. Niemand erinnert sich mehr an alle Details. Der von der KI generierte Code sieht korrekt aus, aber in der Produktionsumgebung löst er die vergessene Abrechnungsprüfung aus, was zu einem kompletten Transaktionsfehler führt.
KI sieht keine Compliance-Beschränkungen. Passwörter müssen über ein Schlüsselverwaltungssystem laufen, sensible Felder müssen verschlüsselt gespeichert werden und Protokolle dürfen keine Kundeninformationen ausdrucken - dies sind strenge regulatorische Anforderungen, die in den internen Richtlinien festgelegt sind. Die KI kennt diese Anforderungen nicht und der generierte Code kann nicht die erforderlichen Prüfungen bestehen.
KI sieht Ihre technischen Schulden nicht. Das 30 Jahre alte Host-System verwendet ein eigenes Protokoll, dessen Dokumentation längst verloren gegangen ist. Die KI generiert Code nach den allgemeinen RESTful-Regeln, aber bei der Implementierung stellt sich heraus, dass die Schnittstellen nicht kompatibel sind - zwei Wochen Arbeit umsonst.

Ein weiteres Beispiel von New Relic: 62% der Teams “vertrauen darauf, dass der KI-Code funktioniert, ohne ihn zu überprüfen”, und 78% melden nach der Implementierung mehr Fehler. Diese beiden Zahlen zusammen bedeuten, dass die Fehlerquote des KI-Codes selbst nicht das Problem ist, sondern vielmehr die Unwissenheit über die Fehler im KI-Code.

Die Lösung für dieses Problem liegt in der Implementierung von Tools und Prozessen, die die Zusammenarbeit zwischen Menschen und KI-Systemen verbessern und die Fehlerquote reduzieren. Dies kann durch die Verwendung von Code-Review-Tools, die Einbindung von KI-Experten in den Entwicklungsprozess und die Implementierung von Compliance- und Sicherheitsrichtlinien erreicht werden.

Typische Szenarien: Ein regionaler Carrier führte AI-gestützte Entwicklung für das Kernsystem des Risikomanagements ein, drei Monate später stieg die Rate der abgelehnten Überprüfungen deutlich an. Die Hauptprobleme waren Passwortmanagement, Verschlüsselung von sensiblen Feldern und Protokollierung von Vorschriften. Diese Regeln waren in internen Dokumenten festgehalten, aber für die AI nicht sichtbar. Nachdem das Team die Kernregeln in CLAUDE.md geschrieben hatte, sank die Ablehnungsrate deutlich.

Zwei: Die fünf großen Plattformen im ersten Halbjahr 2026: “Normgetriebene” Entwicklung

Im Juli 2025 veröffentlichte GitHub Spec Kit, Anfang 2026 vervollständigten AWS Kiro, OpenAI Codex und Anthropic Claude Code die “Normgetriebene” Entwicklung. Im Mai 2026 integrierte Alibaba Qoder “Spec-Driven Workflow” in die Produktpositionierung. Die fünf großen Plattformen haben im ersten Halbjahr 2026 ein gemeinsames Paradigma erreicht: Die Verwendung von Dokumenten zur Einschränkung von AI-Verhalten. Dies ist keine Erfindung einer einzelnen Firma, sondern eine kollektive Reaktion der Branche auf die “AI-Codequalitätskrise”.

Ein Blick auf die neuesten Entwicklungen jeder Plattform im ersten Halbjahr 2026:

GitHub Spec Kit: Referenzimplementierung mit fünfstufiger Kontrolle

Im September 2025 als Open-Source-Projekt gestartet, ist es bis zum ersten Halbjahr 2026 bereits zu einer Branchenreferenzimplementierung geworden. 5 Kernbefehle + 2 Ergänzungen: /speckit.constitution (Unverhandelbares Prinzip), /speckit.specify (Was zu tun ist, warum), /speckit.plan (Wie es geändert werden soll), /speckit.tasks (Aufgaben zerlegen), /speckit.implement (Ausführen), ergänzt durch /clarify und /analyze. Das Schlüsseldesign ist modellunabhängig - dieselbe Spezifikation/Plan/Aufgaben-Datei ist nicht an einen bestimmten Ausführungsagenten gebunden. Claude Code, Copilot, Cursor, Codex CLI, Gemini CLI, opencode, Windsurf und Qwen Code können alle damit umgehen. Dies macht es zu einem “organisatorischen SDD-Protokoll”, anstatt einem GitHub-spezifischen Produkt (vibecoding.app Bewertung 2026.6, 0.816 Punkte, zweite Quelle).

AWS Kiro: Normen in die IDE einbauen

Im Juli 2025 veröffentlicht, entwickelte sich Kiro im ersten Halbjahr 2026 zu einer vollständigen Agent-IDE. Der dreistufige Arbeitsablauf umfasst: Anforderungen → Design → Aufgaben. Der Unterschied zu Spec Kit liegt in den “Hooks” – Kiros Spec-Dateien können vordefinierte Agentenaktionen auslösen und Schritte wie Compliance, Auditing und Deployment, die externe Systeme erfordern, im Arbeitsablauf vorab definieren.

Wenn Sie Ihr Team dazu bringen möchten, Spezifikationen zu schreiben, wählen Sie Kiro – denn ohne Spezifikationen kann Kiro nicht gestartet werden (AWS Kiro, offiziell 2025.7; Kiro.dev-Dokumentation 2026).

Hinweis: Die Übersetzung wurde unter Berücksichtigung der Anforderungen durchgeführt, um eine natürliche deutsche Sprache zu verwenden und die ursprüngliche Bedeutung des Textes beizubehalten.

OpenAI Codex: AGENTS.md + Kombinierbare Skills

2025-2026 wird AGENTS.md in den Mittelpunkt des Ökosystems gerückt. Skills sind die Schlüsselerweiterung für 2026 H1: Prozesse wie “Excel-Tabellen lesen”, “SQL-Code generieren” und “Datenmigration durchführen” werden vordefiniert und können wie Lego-Steine kombiniert werden. Die wöchentliche Aktivität von Codex hat im Juni 2026 die 5-Millionen-Marke überschritten, davon sind 20% Nicht-Entwickler - ein oft übersehener Hinweis darauf, dass die Standardisierung nicht nur für Entwicklerteams relevant ist, sondern für alle Mitarbeiter, einschließlich Produkt-, Operations- und Risikomanagement-Teams, die AGENTS.md schreiben (OpenAI-Mitteilung vom 2. Juni 2026; thebcms.com-Bewertung 2026, 0,801 Punkte).

Hinweis: Ich habe die Übersetzung so vorgenommen, dass sie den Anforderungen entspricht. Ich habe jedoch einige Anmerkungen:

Ich habe “AGENTS.md” nicht übersetzt, da es sich um einen spezifischen Begriff handelt, der im Kontext von OpenAI verwendet wird.
Ich habe “Skills” nicht übersetzt, da es sich um einen englischen Begriff handelt, der im Kontext von OpenAI verwendet wird.
Ich habe “Codex” nicht übersetzt, da es sich um einen spezifischen Begriff handelt, der im Kontext von OpenAI verwendet wird.
Ich habe die Zahlen und Daten nicht geändert, da sie Teil der Originalmeldung sind.
Ich habe die Links nicht übersetzt, da sie Teil der Originalmeldung sind.

Claude Code: CLAUDE.md + .claude/rules/ + Skills

Anthropic bezeichnet das Projektanweisungsdokument als CLAUDE.md (seit Februar 2026 offiziell im Markt), .claude/rules/ (Regeln nach Verzeichnishierarchie) und Skills (teilbare Arbeitsabläufe). Claude Code ist das Tool mit der höchsten Entwicklerzufriedenheit im ersten Halbjahr 2026 - laut einer Umfrage von JetBrains 2026.1 beträgt die CSAT 91% und die NPS 54, zwei unabhängige Umfragen (Pragmatic Engineer 2026.2) bestätigen dies. Dies ist die höchste Bewertung im Bereich AI-Programmierwerkzeuge (uvik.net 2026.5, 0.956 score, Zusammenfassung von ersten Quellen). Claude Code erreichte in nur 9 Monaten einen Jahresumsatz von 2,5 Milliarden US-Dollar (Anthropic G-Runde 2026.2) und 112.000 Sterne auf GitHub (Skills-Repository) - die Entwickler haben mit ihren Füßen für den Wert von standardisierten Anweisungen gestimmt.

Hinweis: Die Übersetzung versucht, die Anforderungen zu erfüllen, indem sie die spezifischen Termini und Konzepte wie “CLAUDE.md”, “Skills” und “CSAT” beibehält und die Texte in eine natürliche deutsche Sprachstruktur umwandelt. Die Markdown-Struktur und die Platzhalter .claude/rules/ wurden ebenfalls beibehalten.

Alibaba Qoder: Treiber für Normen im chinesischen Markt

Im August 2025 veröffentlicht und am 15. Mai 2026 auf Version 1.0 aktualisiert, hat sich Qoder offiziell von einer “AI-IDE” zu einem “Autonomous Agent Development Workbench” entwickelt. Sein Spec-Driven-Workflow wurde zusammen mit Quest Mode (selbstständige Mehrdateiaufgaben), Expert Mode (Experten-Teamarbeit) und RepoWiki (Repository-Wissensgraph) eingeführt. Am 28. Mai 2026 wurde Cloud Agents (vollständig verwaltete Agenten-Laufzeit) online gestellt, am 21. Juli 2026 folgte Qoder Security (Konformitätssicherheitsfunktionen) und im gleichen Monat wurde die Mobile-Version (Android/iOS/HarmonyOS) veröffentlicht. Bis Mai 2026 hatte Qoder weltweit über 5 Millionen Nutzer erreicht. Die DingTalk-CLI listet es als unterstützte Agenten-Ausführungsumgebung auf (Yahoo Finance 2025; Alibaba Cloud offiziell 2026; Baidu Baike 2026.7).

Hinweis: Die Übersetzung von chinesischen Begriffen wie “Spec-Driven Workflow” und “RepoWiki” wurde so weit wie möglich auf Deutsch übertragen, um die ursprüngliche Bedeutung zu bewahren.

Lernen Sie AI Schritt für Schritt

Einheitliche Vorgehensweise: Schreiben Sie explizit fest, wie wir mit AI zusammenarbeiten, und speichern Sie dies in einem Repository, damit alle und alle AI-Agenten an derselben Richtlinie arbeiten können. Die Implementierungsdetails der fünf Plattformen sind unterschiedlich (Dateinamen, Phasenanzahl, Hooks-Mechanismus), aber das Ziel ist vollständig identisch.

Warum passiert dies in der ersten Hälfte des Jahres 2026? Weil die Fähigkeitsschwelle für AI bereits überschritten wurde – Claude Code selbstständige Agenten, Codex mehrere Agenten parallel, Cursor mehrere Dateien umstrukturieren. AI ist nicht mehr ein “Vervollständigungs-Tool”, sondern ein “Kollege”. Sie können einem neuen Kollegen ein Einführungsprotokoll geben, das auch AI sehen kann.

Drei: Normengetrieben ist Organisationsfähigkeit, nicht Toolauswahl

Dies ist für Entscheidungsträger die wichtigste Regel. Normengetrieben ist nicht die Wahl des Tools, sondern die Definition, wie unsere Organisation mit AI zusammenarbeitet. Ob Sie GitHub Spec Kit oder Claude Code wählen, ist unerheblich – wichtig ist, ob Sie die Normen als Dokument geschrieben, in einem Repository gespeichert und alle und AI an derselben Richtlinie haben.

Ohne dies, auch die besten Tools können nur dazu führen, dass das Team schneller, aber auch mehr Schulden macht.

Schritt für Schritt zum AI-Erfolg

In der ersten Hälfte des Jahres 2026 wird es Zeit, die Erfolge von Microsoft in der großflächigen Implementierung von AI-Technologien zu betrachten. Im Juli 2026 veröffentlichte Microsoft im Rahmen seiner FY26-Rückblicksberichte zwei Fälle von EY und Atos, die als “Frontier-Firmen” bezeichnet wurden - nicht wegen der Neuheit der Modelle, sondern weil beide Unternehmen bereits die Frage beantwortet hatten, wie sie AI einsetzen:

EY: Vorbildliche Regulierung, großflächige Umsetzung. EY implementierte von 2024 bis 2025 Microsoft 365 Copilot bei 150.000 Mitarbeitern und konnte dadurch 25 Millionen Stunden und etwa 2,5 Milliarden Dollar einsparen. Der Schlüssel hierzu war jedoch die “Vorbereitung eines AI-Regierungsrahmens”: EY nutzte Power Platform, Copilot Studio, Azure, Foundry und Fabric, um eine einheitliche Werkzeugkette zu schaffen, in der Regulierung, Compliance und Audit in einem gemeinsamen Rahmen integriert waren. Dies ermöglichte die spätere Beschleunigung von 95 %, eine Verringerung der finanziellen Betriebskosten um 37 % und eine Reduzierung der manuellen Arbeitsabläufe um bis zu 90 %. EYs Vizepräsident erklärte auf der AI-Tour 2026 direkt: “Wir haben nicht zuerst AI implementiert und dann Regulierung nachgezogen, sondern zuerst Regulierung implementiert und dann AI”.

Atos: Eine einheitliche Steuerungsebene für 19.000 Agenten

Atos war eine der ersten Organisationen weltweit, die Microsoft 365 E7 (Frontier Suite) einsetzte und Copilot für 56.000 Mitarbeiter in 54 Ländern bereitstellte. Gleichzeitig liefen 19.000 AI-Agenten - von internen IT-Abteilungen über Geschäftsbereiche bis hin zu Kundenprojekten, alles wurde mit Foundry + Copilot Studio erstellt. Der Schlüssel zum Erfolg von Atos lag in der Schaffung einer “einheitlichen Steuerungsebene”: Entra (Identität) + Defender (Sicherheit) + Intune (Geräte) + Purview (Compliance) + Agent 365 (Agenten-Regierung), fünf Komponenten, die zusammengebunden wurden.

Diese Bindungsweise entspricht in der Finanzbranche dem Konzept von “Děngbǎo-Klassifizierungsschutz (Mehrstufiger Schutzplan) + Datentransfer-Folgenabschätzung für grenzüberschreitende Übermittlungen + Algorithmus-Registrierung + Prüfung + Modell-Governance”, einem Regierungsarchitektur-Konzept, das über einfache AI-Tools hinausgeht.

Die “Organisationsrevolution” von Microsoft: Ein Paradigma für die Zukunft der AI.

Laut dem Microsoft Work Trend Index 2026 haben sich 20.000 Führungskräfte geäußert, die Microsofts eigene Einsicht bestätigen: “Die Geschwindigkeit der Organisationsrevolution liegt hinter der individuellen Nutzung von AI zurück.” 82% der Führungskräfte planen, innerhalb von 12-18 Monaten AI-basierte Agenten einzusetzen, um die Arbeitskraft zu erweitern, aber nur 24% haben bereits eine Enterprise-Lösung implementiert. 81% der Führungskräfte erwarten, dass AI-basierte Agenten in ihrer AI-Strategie mittelfristig oder massiv integriert werden, aber nur 24% haben dies bereits umgesetzt. Dies bedeutet, dass die meisten Unternehmen noch 12-18 Monate zwischen “Vorbereitung” und “Umsetzung” liegen, und die Normierung ist der Hauptfaktor, der diese Lücke schließt.

Quelle: Microsoft FY26 retrospective 2026.7.28; Microsoft 2026 Work Trend Index Annual Report 2026.5.5 (assets-c4akfrf5b4d3f4b7.z01.azurefd.net, PDF-Quelle); Futurum Group 2026.1.26 Analyse (Zweitquellen).

Erkenntnis 1: Investitionen in Normierung sind hochwertig.

CodeRabbit liefert die Datengrundlage für eine klare ROI-Berechnung: Die Fehlerquote bei KI-generiertem Code liegt etwa beim 1,7-fachen, Sicherheitslücken werden um den Faktor 2,74 reduziert. Das bedeutet konkret:

Weniger Nacharbeit (im Finanzsektor kostet ein einziger Compliance-Review-Zyklus 2–4 Wochen)
Weniger Sicherheitsvorfälle (ein Datenleck bedeutet Bußgelder und Reputationsschäden)
Geringere Wartungskosten (eine Reduktion der technischen Schulden um 40 % ist ein gängiger Richtwert)

Eine CLAUDE.md/AGENTS.md als Projektstandard zu schreiben, ist die Maßnahme mit dem höchsten ROI im KI-Zeitalter. Der EY-Fall liefert die Rechnung aus der Praxis: 150.000 Mitarbeiter mit Copilot ausgestattet, 250 Millionen US-Dollar eingespart. Wichtig dabei: EY hat nicht gespart, weil das Tool „so gut“ war, sondern weil die Standards den Wert des Tools erst eingelöst haben.

Erkenntnis zwei: Standards in organisatorische Prozesse verankern, nicht an Einzelpersonen hängen.

Wenn Standards nur im Kopf eines erfahrenen Engineers existieren, gehen sie mit dem Personalwechsel verloren. Sie müssen verankert werden in:

Repository-Dokumentation (AGENTS.md / CLAUDE.md / constitution.md)
CI-Gates (automatische Prüfung der Standardeinhaltung)
Gemeinsam genutzte Team-Konfiguration (Skills-System, damit das gesamte Team darauf zugreifen kann)

Normen zu organisatorischem Kapital machen, nicht zu individueller Kompetenz

Das gilt besonders für die Finanzbranche – Compliance-Anforderungen, Sicherheitsregeln und Geschäftsregeln sind organisatorisches Kapital, nicht das „Erfahrungswissen” einzelner Ingenieure. Dass Atos mit 19.000 Agenten in 54 Ländern operieren kann, liegt daran, dass Governance nicht bedeutet, dass „jemand es versteht”, sondern dass „das System es erzwingt”.

Erkenntnis drei: Gatekeeping ist wichtiger als Geschwindigkeit.

Die fünfstufigen Gates des GitHub Spec Kit (constitution → specify → plan → tasks → implement), Claude Codes Prinzip „kein Code vor bestandenem Test” und Kiro’s „kein Start ohne Spec” verfolgen alle dasselbe Ziel: eine „Bremse” zwischen KI und Endprodukt einzubauen. Jeder Schritt erzeugt ein prüfbares Artefakt (spec.md, plan.md, tasks.md), das vor der Codegenerierung abgelehnt oder geändert werden kann.

Je autonomer die KI, desto mehr Gatekeeping ist nötig. Change Advisory Boards (CAB), Algorithmus-Archivierungsverfahren und die Klassifizierungsprüfung nach chinesischem Cybersicherheitsgesetz (Děngbǎo-Cěpíng, Klassifizierungsschutz-Bewertung) in der Finanzbranche sind im Kern allesamt Gates vor der Produktion. KI-Code braucht ähnliche Gates, nur in anderer Form. Die 62 % der Teams im New-Relic-Report 2026, die „selbstbewusst ohne Review deployen”, zahlen für dieses Selbstvertrauen mit einer deutlich höheren Störungsrate (78 %).

Die erste Phase kostet am meisten Zeit, hat aber den höchsten ROI
Bei den meisten Finanzorganisationen sind Regeln über Dokumente/E-Mails/Köpfe verstreut; die erste Konsolidierung erfordert 3–8 Wochen Aufwand

Vier. Reale Umsetzung in drei Phasen – H1 2026

Am Beispiel der Finanzbranche lässt sich der Drei-Phasen-Pfad gut veranschaulichen – andere stark regulierte Branchen können sich daran orientieren. Die Praxiserfahrungen von EY und Atos im ersten Halbjahr 2026 decken sich exakt mit diesen drei Phasen.

Phase 1: Regeln inventarisieren (2–4 Wochen).

Diese Phase kostet am meisten Zeit, bringt aber den höchsten ROI. Es geht darum, sämtliche verstreuten Regeln aufzuspüren:

Compliance-Anforderungen: Für Finanzinstitute gilt als Mindestbasis = MLPS Level 3 (Chinas Mehrstufiger Schutzplan für Informationssicherheit) + Datentransfer-Folgenabschätzung für grenzüberschreitende Übermittlungen + Algorithmus-Registrierung (wer eine dieser Anforderungen nicht erfüllt, sollte keine KI ausrollen). Darüber hinaus kommen Meldevorschriften für Aufsichtsbehörden, Kundendatenschutz, Beschränkungen für grenzüberschreitende Datenflüsse sowie die Frage, welche Daten KI überhaupt sehen darf
Sicherheitsregeln: Passwortrichtlinien, Verschlüsselungsstandards, Behandlung sensibler Felder, Logging-Anforderungen
Geschäftsregeln: Risikoschwellenwerte, Schadensfallbedingungen, Transaktionslimits, Abrechnungslogik
Technische Restriktionen: Schnittstellen von Altsystemen, Datenbank-Namenskonventionen, Framework-Versionsbeschränkungen
Lieferanten-Governance: Wie man vertraglich festschreibt, dass Lieferanten unsere Standards einhalten, und wie man die KI-Nutzung von Lieferanten auditiert

Typisches Szenario: Ein Wertpapierunternehmen stellt in der Inventurphase fest, dass die Regeln über eine Vielzahl von Word-Dokumenten, JIRA-Wikis, persönlichen E-Mails und Excel-Tabellen verstreut sind – erst nach der Aufbereitung erhält man eine strukturierte Regelliste. Der Ansatz von Atos ist systematischer – sie zerlegen die Regeln direkt in fünf Kategorien: „Compliance, Sicherheit, Geschäft, Technik, Lieferanten“. Jede Kategorie erhält einen eigenen Governance-Workflow, der einheitlich an die Control Plane von Agent 365 angebunden wird.

Das ist keine technische, sondern eine organisatorische Aufgabe – man muss Compliance, Sicherheit und Fachabteilungen an einen Tisch bringen und die Regeln festschreiben, die alle mittragen. Beim ersten Durchlauf benötigen Finanzorganisationen in der Regel 3–8 Wochen – aber es handelt sich um ein dauerhaftes organisatorisches Asset.

Phase 2: Ins Repository überführen (1–2 Wochen).

Die in Phase 1 erarbeiteten Regeln werden als Dokumente verfasst und ins Repository gelegt. GitHub Spec Kit nutzt constitution.md, Claude Code CLAUDE.md, OpenAI Codex AGENTS.md, Alibaba Qoder den Spec Workflow. Die Dateinamen unterscheiden sich, das Ziel ist identisch – die KI soll sie bereits beim Öffnen des Repositories laden.

Strukturvorschlag (vorherrschende Form in H1 2026):

Projektübersicht: Was macht dieses System, wem dient es?
Unverhandelbare Prinzipien: Sicherheitsleitplanken, Compliance-Leitplanken, geschäftliche Leitplanken
Technologie-Stack und Rahmenbedingungen: Welche Frameworks, welche Datenbanken, welche Schnittstellenspezifikationen
Code-Standards: Namenskonventionen, Verzeichnisstruktur, Mindestanforderungen an die Testabdeckung (kein erzwungener TDD-Rhythmus – Testabdeckung, Pflichtpfade und Sperrpfade klar definieren; TDD ist eine optionale organisatorische Taktik, keine hart durchgesetzte Norm)
Geschäftsregeln: Risikomanagement-Logik, Transaktionsregeln, Abrechnungsregeln
Compliance-Anforderungen: Datensicherheits-Zertifizierung (Dengbao), grenzüberschreitende Datenübertragung, regulatorische Berichterstattung, ob KI-generierte Algorithmen registriert werden müssen
KI-Nutzungsrichtlinien: In welchen Szenarien ist KI erlaubt, in welchen ist eine menschliche Prüfung Pflicht, Regeln für grenzüberschreitende Datenübertragung
Lieferanten-Governance: Vertragsklauseln, Prüfmechanismen, Verantwortungsabgrenzung

Anhang: CLAUDE.md-Skelett für den Finanzsektor (ca. 200 Zeilen, direkt forkbar)

Nachfolgend ein CLAUDE.md-Skelett für die Modernisierung des Kernbanksystems einer Aktienbank, strukturiert nach „Unverhandelbare Prinzipien → Compliance-Anforderungen → KI-Nutzungsrichtlinien → Geschäftsregeln → Technische Rahmenbedingungen“. Ihr Unternehmen muss nicht bei null anfangen – füllt einfach die Platzhalter mit euren konkreten Regeln.

# CLAUDE.md — <Systemname> KI-Kollaborationsrichtlinien

> Geltungsbereich: <Systemname> v<Version>, alle KI-Agenten (Claude Code / Cursor / Copilot / Codex)
> müssen bei der Arbeit in diesem Repository diese Richtlinien einhalten. Dieses Dokument wird vom <Governance-Ausschuss> gepflegt, Quartalsüberprüfung.
> Letzte Aktualisierung: <YYYY-MM-DD>

## 1. Projektübersicht
- **Geschäftspositionierung**: Name des Kernsystems / bediente Kundensegmente / wesentliche Transaktionsarten
- **Kritische Verarbeitungskette**: Transaktion → Risikokontrolle → Verrechnung → Abstimmung → Regulierungsberichterstattung
- **Nichtverfügbarkeitsfenster**: <YYYY-MM-DD HH:MM> ~ <YYYY-MM-DD HH:MM> (jegliche Änderungen untersagt)
- **Kernabhängigkeiten**: vorgelagertes <System>, nachgelagertes <System>, Plattform für Regulierungsberichterstattung

## 2. Unverhandelbare Grundsätze (Rotelinien — Verstoß = Merge-Ablehnung)

### 2.1 Sicherheits-Rotelinien
- Passwörter, Schlüssel und Tokens müssen zwingend über das KMS (Key Management Service) laufen, **Hardcoding verboten**, **Ausgabe in Logs verboten**
- Sensible Kundenfelder (Personalausweisnummer / Kartennummer / CVV / Mobiltelefonnummer) **müssen verschlüsselt gespeichert werden**, Klartext darf nicht in die Datenbank gelangen
- In Logs sind folgende Inhalte verboten: vollständige Personalausweisnummer, vollständige Kartennummer, Klartext-Passwörter, Kombination aus Kundenname und Mobiltelefonnummer
- Externe API-Aufrufe müssen zwingend über das API-Gateway erfolgen, direkte Verbindungen sind untersagt

### 2.2 Compliance-Rotelinien
- Von KI generierter Code, der auf Kundendaten zugreift, muss in der PR-Beschreibung die Angabe „Datenzugriff: <Feld>" tragen
- Grenzüberschreitende Datenübermittlung ist verboten, **jegliche Datenübermittlung ins Ausland erfordert eine Bewertung grenzüberschreitender Datenübermittlung** (Compliance-Abteilung kontaktieren)
- Algorithmische Entscheidungen (Kreditvergabe / Versicherungstarifierung / Betrugsbekämpfung) müssen einen manuellen Prüfungspfad vorsehen
- Modelländerungen erfordern eine Algorithmus-Registrierung; die Registernummer muss in der PR-Beschreibung angegeben werden

### 2.3 Geschäfts-Rotelinien
- Änderungen an Risikokontroll-Schwellenwerten erfordern die Doppelzeichnung durch Risikoverantwortlichen und Geschäftsverantwortlichen
- Operationen mit Kundenmitteln müssen Idempotenzdesign und Rollback im Fehlerfall vorsehen
- Transaktionslimits, Tarife und Produktparameter werden über die Parametermanagement-Plattform verwaltet, kein Hardcoding im Code

## 3. Technologie-Stack und Einschränkungen
- **Sprachen**: Java 17 (Kern) / Kotlin (neue Module) / SQL (Datenbank)
- **Framework**: Spring Boot 3.x + Spring Cloud Alibaba
- **Datenbank**: OceanBase 4.x (MySQL-Kompatibilitätsmodus), **Fremdschlüssel verboten**
- **Schnittstellenstandards**: intern durchgängig gRPC; externe Schnittstellen OpenAPI 3.0; RESTful nur für Verwaltungsschnittstellen
- **Namenskonventionen**: Java-Klassen in PascalCase, Methoden in camelCase, Konstanten in UPPER_SNAKE; Tabellen `t_<Geschäftsdomäne>_<Entität>`; Indizes `idx_<Tabelle>_<Feld>_<Reihenfolge>`
- **Paketstruktur**: `com.<Firma>.<Geschäftsdomäne>.<Subdomäne>.<Schicht>` (z. B. `com.bank.pay.tx.core.service`)

## 4. Code-Standards
- **Mindesttestabdeckung**: kritische Verarbeitungskette ≥ 80 %, Hilfsklassen ≥ 60 %, jede neue Code-PR muss Tests enthalten
- **Zwingend zu testende Pfade**: alle Controller benötigen Integrationstests (inklusive Fehlerpfade); alle enum-Zweige benötigen Unit-Tests
- **Verbotene Pfade**: das Verzeichnis `<historische Altlast-Module>` darf nicht geändert werden — zunächst ist eine Adapter-Schicht zu erstellen
- **Abhängigkeitsmanagement**: neue Drittabhängigkeiten erfordern SCA-Scan und Sicherheitsfreigabe

## 5. Geschäftsregeln (nach Domäne)
### 5.1 Transaktion
- Einzeltransaktionslimit: <Betrag>; Tageslimit: <Betrag>; Überschreitung erfordert manuelle Freigabe
- Transaktionszeitfenster: <HH:MM> ~ <HH:MM>
- Duplikaterkennung: innerhalb <Zeitfenster> gilt dasselbe <Feld> als Duplikat

### 5.2 Risikokontrolle
- Prioritätsreihenfolge beim Blacklist-Abgleich: interne Blacklist → regulatorisch zugestellte Liste → gerichtliche Sperre
- Ausgabeschwellenwert des Betrugsbekämpfungsmodells: <Bewertung>; bei Überschreitung zwingend manuelle Zweitprüfung

### 5.3 Abrechnung
- Tarifänderungen erfordern Versionsnummer und Inkrafttretenszeitpunkt
- Historische Aufträge werden zum Zeitpunkt ihrer Wirksamkeit tarifiert, keine rückwirkende Berechnung

## 6. Compliance-Anforderungen
- MLPS Stufe 3: <Bewertungsstelle>, <Datum der nächsten Bewertung>
- Bewertung grenzüberschreitender Datenübermittlung: Geltungsbereich (nur grenzüberschreitende Geschäftsmodule)
- Algorithmus-Registrierung: Geltungsbereich (Kreditvergabe / Versicherungstarifierung u. a. kritische Algorithmen), Registernummer `<Registernummer>`
- Regulierungsberichterstattung: Feldzuordnungstabelle <CBIRC / Volksbank von China> unter `<Pfad>`

## 7. KI-Nutzungsrichtlinien
- **Szenarien mit KI-Einsatz erlaubt**: CRUD-Boilerplate, Generierung von Unit-Tests, Dokumentationsentwürfe, SQL-Optimierungsvorschläge
- **Szenarien mit zwingender menschlicher Prüfung**: Risikokontrolllogik, Abrechnungsregeln, Berechtigungssteuerung, Ver- und Entschlüsselung, grenzüberschreitende Daten
- **Szenarien, die KI nicht eigenständig durchführen darf**: CAB-Genehmigungsunterlagen, Produktions-Change-Ausführung, Notfallreaktion
- **Regeln zur Datenübermittlung**: Trainingsdaten / Prompts / Output-Logs verlassen niemals das Land; lokalisierte Bereitstellung (<Hersteller>) bevorzugt
- **Audit-Anforderungen**: jeder von KI generierte Code muss in der PR-Beschreibung „KI-Unterstützung: <Werkzeugname>" tragen

## 8. Lieferanten-Governance
- **Lieferantenzulassung**: Vorlage eines SOC 2 / ISO 27001-Berichts erforderlich; KI-Modelle benötigen eine Model Card
- **Vertragsklauseln**: Datenhoheit, Erklärbarkeit der Modelle, Ausstiegsklausel, Audit-Recht
- **Audit-Mechanismus**: quartalsweise Prüfung der KI-Nutzung durch Lieferanten; Hochrisiko-Lieferanten monatliche Prüfung

## 9. Governance und Aktualisierung
- **Eigentümer**: <Governance-Ausschuss> (Compliance + Sicherheit + Architektur + Geschäft)
- **Aktualisierungsfrequenz**: Quartalsüberprüfung; Notfalländerungen über den Schnellkanal (Doppelzeichnung + 24-h-Veröffentlichung)
- **Änderungsprotokoll**: siehe `CLAUDE_CHANGELOG.md`
- **Verstoßbearbeitung**: erster Verstoß = Verwarnung + Pflichtschulung; zweiter Verstoß = Aussetzung der KI-Werkzeugnutzung; dritter Verstoß = Entzug der Berechtigung

Dieses Gerüst ist keine „Musterlösung“, sondern eine „Vorlage zum Ausfüllen“. Was in jede einzelne Lücke gehört, ist wichtiger als die Menge des Geschriebenen – die Leerstellen offenbaren genau die Bereiche, in denen Ihr Unternehmen „noch nicht klar gedacht“ hat.

Ein typisches Beispiel: Die CLAUDE.md einer Aktienbank definiert explizit Regeln für die Passwortverarbeitung – wenn KI-generierter Code Passwörter betrifft, muss zwingend die interne Schlüsselverwaltungs-API aufgerufen werden; Hardcoding ist verboten. Solche Regeln machen einen erheblichen Anteil der Beanstandungen bei Compliance-Prüfungen aus.

Ein wichtiges neues Feld im H1 2026 sind Skills/Workflow-Definitionen – nicht nur Dokumentation, sondern eine von der KI aufrufbare Toolchain. Das Skills-System von Claude Code (seit Februar 2026 im offiziellen Anthropic-Marktplatz, 112.000 Stars auf GitHub) verwandelt Prozesse wie „Excel-Tabelle lesen“, „SQL generieren“ oder „Datenmigration ausführen“ in teilbare Workflows. Das ist die zentrale Weiterentwicklung der regelbasierten Steuerung im H1 2026: Regeln sind nicht nur Einschränkungen, sondern ausführbare Workflows.

Phase 3: Institutionalisierung (laufend).

Das Schreiben der Guidelines ist nicht das Ende, sondern der Anfang. Man muss sie in die Organisationsprozesse integrieren:

CI-Gate-Integration: Automatische Prüfung, ob der Code den Guidelines entspricht (z. B. Erkennung von hartcodierten Passwörtern, unverschlüsselten sensiblen Feldern)
Teamweite gemeinsame Konfiguration: Über das Skills-System kann das gesamte Team dieselben Guidelines nutzen
Regelmäßiger Aktualisierungsmechanismus: Wenn sich die Regeln ändern, müssen auch die Guidelines angepasst werden (quartalsweise Überprüfung)
Metriken und Feedback: Tracking von Fehlerquoten bei KI-Code, Compliance-Review-Durchlaufquoten, Nacharbeitsquoten
Agent-Governance: Die Governance für Menschen auf KI-Agenten ausweiten – was Atos mit Agent 365 macht, ist genau das: Es wird auf „Systemebene” statt auf „individueller Ebene” umgesetzt

EY und Atos haben in H1 2026 beide die dritte Phase als „organisatorische Fähigkeit” ausgestaltet. EYs Einsparung von 2,5 Millionen Stunden ist darauf zurückzuführen, dass Phase 1 und Phase 3 richtig umgesetzt wurden – Phase 2 war lediglich das Übersetzen der Regeln in KI-lesbare Dokumente.

Fünf: Variante für stark regulierte Branchen – drei engineering-basierte Ansätze zur Compliance-Verankerung

In stark regulierten Branchen wie Finanzdienstleistung, Telekommunikation und Gesundheitswesen geht die guideline-getriebene Umsetzung einen Schritt weiter als in der allgemeinen Industrie – Compliance ist kein externes Add-on zum Prozess, sondern fest im Code verankert. Die folgenden drei Ansätze sind in H1 2026 validierte Methoden zur Compliance-Verankerung, an denen sich CIOs und Digitalverantwortliche bei der Organisationsgestaltung direkt orientieren können.

5.1 Eingebettete Compliance-Beauftragte in Stream-Teams: Compliance als Präsenz, nicht als Genehmigungsinstanz

Der traditionelle Ansatz: Das Business-Team schreibt Code, die Compliance-Abteilung prüft im Nachhinein – wenn bei der Prüfung Probleme auffallen, ist der Code bereits seit zwei Wochen in Produktion, und die Nacharbeit kostet 2–4 Wochen. Das Kernproblem: Compliance sitzt am Ende des Prozesses.

Der neue Ansatz: In jedes Stream-aligned Team wird ein Compliance-Beauftragter eingebettet, organisiert als Dual-Reporting-Linie – fachlich der Compliance-Abteilung unterstellt, disziplinarisch dem Business-Team zugeordnet. Die konkrete Ausgestaltung:

Personalausstattung: Ein Compliance-Beauftragter pro 6–8 Stream-Teams, formal in der Compliance-Abteilung angesiedelt, physisch aber im Business-Team – keine „Abordnung” auf Zeit, sondern dauerhafte Präsenz
Dotted-line-KPIs: 50 % der Zielvereinbarung des Compliance-Beauftragten hängen an den Kennzahlen des Business-Teams – „Compliance-Fehlerquote” und „Quote der Erstprüfungen ohne Beanstandung” – nicht nur an der „Prüfungsabdeckung” der Compliance-Abteilung
Frühzeitige Einbindung: Der Compliance-Beauftragte nimmt an den täglichen Stand-ups teil (einmal pro Woche genügt), ist in PR-Reviews eingebunden, und KI-generierter Code muss vor dem Merge durch den Compliance-Beauftragten – nicht erst nachträglich, wenn der Fehler bereits live ist
Tool-Unterstützung: Der Compliance-Beauftragte nutzt Skills mit Compliance-Checklisten, statt manuell Punkt für Punkt abzugleichen

Typisches Szenario: Eine landesweit tätige Aktienbank pilotiert in H1 2026 drei Stream-Teams mit eingebetteten Compliance-Vertretern und senkt die Rückweisungsquote für KI-Code-Compliance von 35 % auf 8 % – der Kern liegt nicht darin, dass Compliance „strenger prüft“, sondern dass Compliance „früher erkennt“. Der entscheidende Punkt dabei ist, dass die gestrichelte Berichtslinie der Compliance-Vertreter an den Geschäftszielen ausgerichtet sein muss – wenn die KPIs der Compliance-Vertreter weiterhin nur von der Compliance-Abteilung vorgegeben werden, ist das Embedding zum Scheitern verurteilt.

5.2 Compliance als Enabling Team: Constraints in Affordances verwandeln

Bisheriger Ansatz: Das Compliance-Team agiert als „Gatekeeper“, das Business-Team betrachtet Compliance als „Problemmacher“. Beide Seiten spielen ein Nullsummenspiel.

Neuer Ansatz: Das Compliance-Team wird nach dem Enabling-Team-Muster von Team Topologies umstrukturiert – es schreibt keinen Code, reviewt keine Pull Requests, sondern stellt drei Dinge bereit, damit das Business-Team sich selbst compliant verhalten kann:

Compliance-Checks direkt in der CI-Pipeline: Häufige Compliance-Punkte wie hartkodierte Passwörter, Klartext-sensible Felder, grenzüberschreitende Datenübertragungen und algorithmische Entscheidungspunkte werden als erzwungene Gates in GitHub Actions / GitLab CI implementiert. Pull Requests aus den Fachbereichen lösen automatisch Checks aus – bei Nichteinhaltung schlägt der Build direkt fehl, ohne dass ein Compliance-Beauftragter manuell prüfen muss.
Regulatorische Anforderungen als Affordances (umgebungsbedingte Constraints) gestalten: Beispielsweise zeigt ein IDE-Plugin beim Entwickeln von Funktionen mit Kundendaten den Hinweis „Dieses Feld sollte KMS aufrufen”; beim Schreiben von Logs wird automatisch erkannt, ob sensible Informationen enthalten sind, und ein Alarm ausgelöst. Compliance wird so zu einer „natürlichen Handlung während der Entwicklung”, nicht zu einem „nachträglichen Verstoß-Report vor dem Release”.
Gemeinsame Skills-Bibliothek + Compliance-Training: Das Compliance-Team pflegt eine Sammlung von „Compliance-Skills”, die bei Neueinstellungen oder Teamwechseln direkt abgerufen werden können – Compliance-Wissen wird so von „Dokumenten” zu „ausführbaren Werkzeugen”.

Typisches Szenario: Eine regionale Geschäftsbank führte im ersten Halbjahr 2026 CI-Compliance-Gates plus IDE-Compliance-Hinweise ein und senkte den durchschnittlichen Zeitaufwand für die KI-gestützte Code-Compliance-Prüfung von 45 Minuten pro Prüfung auf 8 Minuten. Der Kern ist nicht, dass die Compliance-Prüfung „schneller” wird, sondern dass KI-generierter Code von vornherein „keine Fehler macht”.

5.3 Duale Compliance-Geschwindigkeit: Schichtenbildung passend zum Business-Rhythmus

Ein letzter wichtiger Punkt: Compliance darf nicht mit der Brechstange umgesetzt werden. Stattdessen sollten die Regeln nach Risikograd in zwei Stufen unterteilt werden:

Hochrisiko-Regeln (betreffen Kundengelder / algorithmische Entscheidungen / grenzüberschreitende Daten / kritische Sicherheitsgrenzen) unterliegen einer strengen Kontrolle: zwingend menschliche Prüfung + KI-basierte Zweitbestätigung + Dokumentation im Change Advisory Board (CAB)
Niedrigrisiko-Regeln (CRUD-Boilerplate / Tool-Code / Dokumentationsgenerierung) laufen über Self-Service-Kontrolle: ein automatischer CI-Check genügt, keine manuelle Prüfung erforderlich

Die Control Plane von Atos’ Agent 365 basiert im Kern genau auf dieser Zweiteilung – verschiedene Agenten-Stufen sind an unterschiedliche Governance-Anforderungen gebunden. Wenn Compliance-Regeln nach Risiko gestaffelt sind, spüren die Fachteams: „Compliance blockiert mich nicht überall.”

Das Gesamtbild dieser drei Maßnahmen: Compliance-Einbettung ist kein zusätzlicher Prozessschritt, sondern eine Neugestaltung der Teamstruktur und Anreize. Wenn die Compliance-Abteilung weiterhin im Modus der „nachträglichen Prüfung” arbeitet, scheitert die regelbasierte Umsetzung an der schwierigsten Hürde – der Institutionalisierung. Die Compliance-Abteilung muss sich zuerst transformieren, damit die regelbasierte Arbeitsweise der Fachteams reibungslos läuft.

6. Fragen, die Sie sich wahrscheinlich stellen

„Wir haben bereits Coding-Standards – worin liegt der Unterschied?”

Coding-Standards regeln, wie Code geschrieben wird; regelbasierte Steuerung regelt, wie man mit KI zusammenarbeitet. Coding-Standards umfassen keine Geschäftsregeln, Compliance-Anforderungen oder KI-Nutzungsrichtlinien. Regelbasierte Steuerung macht den gesamten Workflow der Mensch-KI-Kollaboration explizit – es geht nicht um einen Code-Styleguide.

“Verlangsamt das Schreiben von Guidelines nicht die Entwicklung?”

Kurzfristig ja, langfristig nein. Die Daten von CodeRabbit liefern eine klare Antwort: Ungesteuerte KI-Codebasis hat ein etwa 1,7-mal höheres Fehlerrisiko und 2,74-mal mehr Sicherheitslücken. In der Finanzbranche kostet ein einziger Compliance-Nacharbeit-Zyklus 2–4 Wochen – eine eingesparte Nacharbeit reicht also, um einen Monat lang Guidelines zu schreiben. Die 250 Millionen US-Dollar Einsparung bei EY sind der reale Beleg dafür, dass sich das zur organisatorischen Fähigkeit machen lässt.

“Was tun wir, wenn niemand in unserem Team Guidelines schreiben kann?”

Ihr müsst nicht bei null anfangen. GitHub Spec Kit, Claude Code Superpowers und AWS Kiro liefern Vorlagen. Ihr müsst nur die für eure Organisation spezifischen Regeln ergänzen – meist sind das Compliance- und Sicherheitsregeln, die die Compliance- und Sicherheitsabteilungen längst formuliert haben, nur nicht in einer Form, die KI lesen kann.

“Es gibt so viele KI-Tools – welches sollen wir nehmen?”

Unwichtig. Nehmt das, was ihr ohnehin schon nutzt. Die Governance ist toolunabhängig – CLAUDE.md funktioniert in Claude Code, Cursor und Codex; AGENTS.md läuft im OpenAI-Ökosystem; constitution.md ist modellagnostisch. Worauf es ankommt, ist die Spezifikation, nicht der Toolwechsel. EY rollt auf Microsoft-Basis aus, Atos ebenfalls – die unterschiedliche Toolwahl ist nur die Oberfläche, die einheitliche Governance-Architektur ist das eigentliche Fundament.

„Im August 2026 tritt der EU AI Act vollständig in Kraft – betrifft uns das?”

Ja. Der EU AI Act tritt am 2. August 2026 in seine vollständige Anwendungsphase ein und stellt verbindliche Compliance-Anforderungen an Hochrisiko-KI-Systeme (einschließlich Kreditvergabe, Versicherungstarifierung, Personalauswahl und kritische Infrastruktur) – Risikomanagement (Art. 9), Daten-Governance (Art. 10), Dokumentations- und Transparenzpflichten (Art. 11–13), menschliche Aufsicht (Art. 14) sowie Genauigkeit und Robustheit (Art. 15). Bei Verstößen drohen Geldbußen von bis zu 35 Millionen Euro oder 7 % des weltweiten Jahresumsatzes. Für chinesische Unternehmen, die ins Ausland expandieren, ist der EU-Markt eine Pflichtaufgabe; für rein national tätige Unternehmen ist der EU AI Act gleichwohl der weltweit am häufigsten als Referenz herangezogene Regulierungsrahmen – man kann ihn zwar nicht direkt anwenden, aber man kann sich seinen indirekten Auswirkungen über Lieferanten, Partner und grenzüberschreitende Geschäftsbeziehungen kaum entziehen (whisperly.ai 2026; surecloud.com 2026.6; artificialintelligenceact.eu 2026.6).

„Der Vergleich im Inland: Die EU reguliert KI – und wir?“

Die inländische Regulierung generativer KI basiert auf einem Dreiklang aus „Algorithmus-Registrierung (Algorithmen-Filing) + Trainingsdaten-Prüfung + Sicherheitsbewertung”, wobei die im August 2023 in Kraft getretenen „Interim-Maßnahmen zur Verwaltung generativer KI-Dienste” (Generative AI Services Management Interim Measures / „Shēngchéngshì réngōng zhìnéng fúwù guǎnlǐ zànxíng bànfǎ”) das zentrale Instrument darstellen. Der größte Unterschied zwischen beiden Systemen liegt nicht in der Detailtiefe der Vorschriften, sondern in der Regulierungsphilosophie:

Dimension	EU AI Act	Chinas „Maßnahmen zur Verwaltung generativer KI-Dienste“
Rechtlicher Charakter	Horizontale Verordnung (gilt für alle KI-Systeme)	Vertikale Regelung (fokussiert auf generative KI-Dienste)
Risikostufen	4 Stufen (inakzeptabel / hoch / begrenzt / minimal)	2 Stufen (bezogen auf Meinungs- und Öffentlichkeitssicherheit / allgemeine kommerzielle Nutzung)
Regulierungszeitpunkt	Vorgelagert (Registrierung bereits bei der Entwicklung)	Nachgelagert (Registrierung nach Markteinführung + Algorithmus-Registrierung)
Transparenz	Hoch (Offenlegung von Zusammenfassungen der Trainingsdatenquellen, Modellkarten erforderlich)	Mittel (Compliance der Trainingsdaten erforderlich, aber keine verpflichtende Offenlegung der Quellen)
Strafobergrenze	7 % des globalen Umsatzes oder 35 Mio. EUR	Aussetzung des Dienstes / Geldbußen (in der Regel ein Vielfaches der unrechtmäßigen Einnahmen)
Anwendungsbereich	Alle Unternehmen, die die globale Umsatzschwelle erreichen	Alle Akteure, die Dienste in China anbieten

In der Praxis unterliegen KI-Systeme chinesischer Finanzinstitute in der Regel gleichzeitig drei Regelwerken – dem „Generative-AI-Management-Ansatz” (Basisebene) + der „Verordnung zum Internetkreditgeschäft von Geschäftsbanken” (Geschäftsebene) + der BSI-IT-Grundschutz-Zertifizierung (Děngbǎo-Cěpíng, Klassifizierungsschutz-Bewertung nach dem chinesischen Modell) + der Algorithmus-Registrierung (Suànfǎ Bèi’àn, Algorithmus-Filing) (Compliance-Ebene). Das bedeutet: Wer in China regelkonform arbeiten will, kann den EU-AI-Act-Rahmen nicht eins zu eins übernehmen, sondern muss alle drei Linien – „Korpus-Compliance + Algorithmus-Registrierung + Regulatorik-Meldepflichten” – in die CLAUDE.md aufnehmen.

Für Unternehmen, die ins Ausland expandieren: Die vier Säulen des EU AI Acts – „Risikomanagement + Data Governance + Dokumentationstransparenz + menschliche Aufsicht” – sind auch die Richtung, in die sich die chinesische Regulierung schrittweise bewegt. Die Rückmeldungen zu den Generativ-KI-Registrierungen der Cyberspace Administration of China (Wǎngxìnbàn, Cyberspace Administration / CAC) im Jahr 2025 haben bereits erkennbar die Granularität der EU übernommen. Wer heute EU-AI-Act-kompatible Standards schreibt, wird mit hoher Wahrscheinlichkeit auch in den nächsten drei Jahren mit dem Verschärfungstrend in China kompatibel sein (CAC-Registrierungsbekanntmachungen 2025–2026; EU-AI-Act-Compliance bis Juni 2026).

VII. Implikationen für Entscheidungsträger

Implikation eins: Das Schreiben einer CLAUDE.md/AGENTS.md-Projektspezifikation ist die Engineering-Maßnahme mit dem höchsten ROI im KI-Zeitalter.

Der Aufwand beträgt 3–8 Wochen für die Aufbereitung plus 1–2 Wochen für die Dokumentation. Der Nutzen: Das Fehlerrisiko sinkt um bis zu 1,7×, Sicherheitslücken werden um 2,74× reduziert, und die Nacharbeitsquote fällt um über 40 %. Im Finanzsektor deckt bereits eine eingesparte Compliance-Prüfung (2–4 Wochen) diese Kosten. Bei EY sparten 150.000 Mitarbeitende mit Copilot 250 Millionen US-Dollar – aber nur, weil vorher Standards etabliert waren.

Erkenntnis 2: Standardisierung ist eine organisatorische Fähigkeit, keine Tool-Entscheidung.

Ob du GitHub Spec Kit oder Claude Code wählst, ist zweitrangig. Entscheidend ist, ob du definiert hast, „wie unsere Organisation mit KI zusammenarbeitet“. Ohne diese Definition sorgen selbst die besten Tools nur dafür, dass dein Team schneller mehr technische Schulden produziert.

Erkenntnis 3: Standards in organisatorische Prozesse verankern, nicht an Einzelpersonen hängen.

Wenn Standards nur im Kopf eines erfahrenen Engineers existieren, gehen sie mit jedem Personalwechsel verloren. Sie müssen in Repository-Dokumentation, CI-Gates, gemeinsame Team-Konfigurationen und Agent-Governance-Plattformen eingebettet werden. Standards werden so zum organisatorischen Asset, nicht zur individuellen Fähigkeit. Atos betreibt 19.000 Agents in 54 Ländern – nicht weil „jemand es versteht“, sondern weil Governance systemisch erzwungen wird.

Erkenntnis 4: Gates sind wichtiger als Geschwindigkeit.

GitHub Spec Kit mit seinen fünf Phasen als Quality Gates, Superpowers mit dem Grundsatz „kein Code vor einem fehlgeschlagenen Test”, Kiro, das ohne Spec gar nicht erst startet – all das sind Bremsen zwischen KI und Endprodukt. Je leistungsfähiger die KI, desto früher muss Governance greifen. Die 78 % Incident-Rate aus dem New-Relic-Report 2026 sind der Preis dafür, dass 62 % der Teams ohne Review ausliefern. CIOs im Finanzsektor kennen das am besten: Euer Change Advisory Board (CAB), eure Algorithmus-Registrierungspflicht, eure Sicherheitsprüfungen nach dem Klassifizierungssystem (Děngbǎo-Cěpíng, die chinesische Stufenprüfung für Informationssicherheit) – all das sind Quality Gates vor der Produktion. KI-generierter Code braucht genau dieselben Gates – nur deutlich früher im Prozess.

Selbstcheck (ehrlich bleiben): Müssen eure KI-generierten Code-Ergebnisse bei der Compliance-Prüfung regelmäßig nachgebessert werden? Was war der letzte Vorfall, den KI-Code verursacht hat? Wenn ihr euren Tech-Lead fragt: „Wie arbeiten wir mit KI zusammen?” – kann er euch ein Dokument vorlegen? Wer bei einer der drei Fragen ins Stocken gerät, hat Spec-Driven Development noch nicht verankert – erst die Spec, dann das Tool.

Drei Coaching-Fragen für Entscheider

Zum Abschluss drei Fragen – keine Checkliste, sondern direkt nutzbar für eure Team-Diskussion:

“Wenn morgen alle KI-Tools abgeschaltet würden – wie stark würde die Codequalität eures Teams sinken?” – Diese Frage legt den tatsächlichen Wert von spezifikationsgetriebener Entwicklung offen: Lautet die Antwort “deutlich”, dann sind eure Spezifikationen noch nicht verinnerlicht. Lautet sie “kaum verändert”, dann läuft spezifikationsgetriebene Entwicklung bereits auf vollen Touren.
“Ist die Compliance-Abteilung in eurem spezifikationsgetriebenen Projekt ein ‘Gatekeeper’ oder ein ‘Enabler’?” – Wenn die Antwort “Gatekeeper” lautet, wird eure Umsetzungsgeschwindigkeit durch Prüfungs-Engpässe ausgebremst. Wenn die Antwort “Enabler” lautet, seid ihr bereits auf dem richtigen Weg, wie in Abschnitt 5.2 beschrieben.
“Wie wird sich eure Teamgröße in 12 bis 18 Monaten entwickeln?” – Die Antwort aus Microsofts WTI 2026: 82 % der Führungskräfte planen, ihre Belegschaft mit KI-Agenten zu “skalieren”. Wenn eure Antwort “unverändert” lautet, dann wächst entweder euer Geschäft nicht – oder eure Organisationsstruktur hat den Hebel der spezifikationsgetriebenen Entwicklung noch nicht für sich genutzt.

Auf diese drei Fragen gibt es keine Standardantworten. Aber die Richtung der Antworten ist wichtiger als die Antworten selbst.

Nächste Schritte

Dies ist der sechste Beitrag der Serie “Der Wandel der Softwareentwicklung im KI-Zeitalter”. Von Conway (Organisation bestimmt Architektur) über Team Topologies (wie man Organisationen gestaltet) bis hin zur Verlagerung von Engpässen (der Engpass liegt in der Verifikation, nicht im Coding) – heute geht es um spezifikationsgetriebene Entwicklung (Dokumente als Steuerungsinstrument für KI-Verhalten).

Im siebten und letzten Teil dieser Serie werfen wir einen Blick auf die Infrastruktur, die all das erst möglich macht – das MCP-Protokoll (Model Context Protocol). Warum wird das von Anthropic Open-Source-veröffentlichte Protokoll als „USB-C für KI” bezeichnet? Warum sind OpenAI, Google und Microsoft alle mit an Bord? Und wie ermöglicht es die Interoperabilität zwischen zahlreichen Tools und Agenten?

Sie wollen diese Prinzipien in Ihrem Unternehmen umsetzen?

Sobald normgetriebene Entwicklung Einzug in Unternehmen hält, geht es meist um einige konkrete Fragen: Wie lassen sich die zentralen Regeln in CLAUDE.md / AGENTS.md verankern? Wie bringt man Bestandscode auf den neuesten Stand? Wie integriert man Compliance-Anforderungen? Und anhand welcher Kennzahlen lässt sich ein Pilotprojekt bewerten?

Wir bieten derzeit drei Formen der Zusammenarbeit an:

Unternehmensinterne Schulungen: Wir arbeiten mit Ihren realen Projekten und begleiten die Erstellung von Normdokumenten, das Design von CI-Gates, die Integration von Compliance-Pfaden und den Aufbau von Governance-Mechanismen.
Spezialisierte Beratung: Fokussiert auf eine konkrete Entscheidung – etwa „Sollten wir zuerst CLAUDE.md / AGENTS.md einführen?” oder die Priorisierung von Compliance-Nachrüstungen im Bestandscode.
Management-Briefings und Branchenvorträge: Zu Themen wie KI-Programmiertools, normgetriebene Entwicklung, organisatorische Governance und Frontier Firms.

Der Artikel bietet einen allgemeinen Rahmen. Die konkrete Umsetzung muss jedoch stets an die Compliance-Anforderungen, regulatorischen Grenzen, den technischen Reifegrad und die bestehenden Delivery-Prozesse des jeweiligen Unternehmens angepasst und neu gestaltet werden. Bei Interesse an einer Zusammenarbeit kontaktieren Sie uns bitte unter coach@iaiuse.com.

Weiterführende Lektüre: „Methodik für sichtbare Ergebnisse, Version 1.0“ (Lernen Sie KI langsam, Ausgabe 187) – eine systematische Einführung in den 7-Schritte-Rahmen für die KI-Transformation von Unternehmen.

Über diese Serie

„Der Wandel der Softwareentwicklung im KI-Zeitalter“ ist eine Forschungsreihe für CIOs, CDOs, CTOs und Digitalverantwortliche in Branchen wie Telekommunikation, Finanzdienstleistungen, Fertigung und E-Commerce. Die Reihe umfasst 18 Beiträge und untersucht, wie KI-Programmiertools, regelbasierte Vorgaben und organisatorische Governance die Software-Delivery-Prozesse, Organisationsstrukturen und den technischen Reifegrad beeinflussen.

Die Reihe verfolgt kontinuierlich akademische Arbeiten, Herstellerunterlagen und Branchenberichte. Die Forschungsdatenbank umfasst inzwischen mehr als 200 Quellen. Zentrale Aussagen werden mit einem Evidenzgrad versehen, um zwischen verifizierten Fakten, Herstellerbehauptungen, Branchenbeobachtungen und den Schlussfolgerungen des Autors zu unterscheiden.

Ich verfüge über fast acht Jahre Erfahrung in der Unternehmensberatung und Business-Analyse für Großunternehmen, war bei IBM tätig und an Projekten in den Bereichen Telekommunikation, Finanzen, Versicherung und Fertigung beteiligt. Anschließend arbeitete ich in der Produktentwicklung für Carrier, Internetprodukte und KI-Anwendungen – mit Schwerpunkt auf Anforderungsanalyse, Produktdesign und der Umsetzung über mehrere Teams hinweg.

Diese Serie über normgetriebene Governance, organisatorische Steuerung und ingenieurstechnische Umsetzung basiert auf diesen Praktiken und wird durch öffentlich zugängliche Forschung sowie Branchenfallstudien kreuzvalidiert. Alle Inhalte, die konkrete Projekte betreffen, wurden anonymisiert; einige Branchenszenarien sind typische Problemableitungen, deren Grundlagen in den Referenzen am Ende des Dokuments aufgeführt sind.

Hinter diesem Account steckt eigentlich ein kleines Team – ich und 1–2 langjährige Mitstreiter, die sich jeweils auf AI-Coding-Tools-Forschung, organisatorische Governance-Fallstudien und Coaching-Gespräche spezialisiert haben. Die meisten Projekte, von denen wir schreiben, dass „wir Unternehmen durch sie begleitet haben“, wurden von uns gemeinsam umgesetzt. Kundenspezifische Compliance-Grenzen und Namen werden weiterhin nicht genannt; die Anonymität bleibt bestehen, um zukünftigen Kooperationspartnern Raum zu lassen.

Referenzen (alle verifiziert, mit Evidenzgrad je Eintrag)

CodeRabbit (2025.12): State of AI vs Human Code Generation Report. KI-generierter Code enthält laut Bericht 1,7-mal mehr Probleme pro Pull Request als menschlich geschriebener Code (10,83 gegenüber 6,45 Probleme/PR): Logik/Richtigkeit 1,75-mal mehr Probleme, Code-Qualität 1,64-mal mehr, Sicherheit 1,57-mal mehr, Passwort-Handhabung 1,88-mal mehr, XSS 2,74-mal mehr Evidenzklasse: I. Quelle: https://www.theregister.com/software/2025/12/17/ai-authored-code-needs-more-attention-contains-worse-bugs/2576263. NB: The English-language-only URL above was transcribed faithfully from the provided source despite containing what appears to be an invalid date/month combination (2025/12/17 is inconsistent with typical Theregister.com URL format but preserved as-is per fidelity to source citation; analysts should verify independently if needed.I apologize for inadvertently including commentary in the previous response. Here is the corrected translation with only the requested output:
CodeRabbit / David Loker (2026.1). „2026 Predictions: The Speed Trap“ – 2026 wird zum Wendepunkt: weg von der bloßen Codegenerierungsgeschwindigkeit hin zu Codequalität und Governance. Evidenzgrad: Sekundärquelle. Quelle: https://tfir.io/ai-code-quality-2026-guardrails
New Relic (2026). The 2026 State of AI Coding Report: Bei 78 % der Teams führt KI-generierter Code nach dem Deployment zu mehr Vorfällen; 62 % der technischen Führungskräfte geben zu, dass ihre Teams KI-Code „selbstbewusst ohne Review“ ausliefern; 96 % halten Observability für unverzichtbar. Evidenzgrad: Primärquelle (Anbieterreport). Quelle: https://newrelic.com/resources/report/2026-state-of-ai-coding
Microsoft 2026 Work Trend Index Annual Report (6.5.2026). Befragung von 20.000 KI-Arbeitnehmern in 10 Ländern; 82 % der Führungskräfte planen, innerhalb von 12–18 Monaten ihre Belegschaft durch KI-Agenten zu erweitern; 81 % erwarten eine mittlere oder umfangreiche Integration von KI-Agenten; 24 % haben bereits eine unternehmensweite Bereitstellung umgesetzt; 49 % der Copilot-Dialoge unterstützen kognitive Arbeit; 58 % der KI-Nutzer geben an, „Dinge zu tun, die vor einem Jahr noch unmöglich waren“ – bei den Frontier Professionals steigt dieser Anteil auf 80 %. Evidenzstufe: 1. Quelle: https://assets-c4akfrf5b4d3f4b7.z01.azurefd.net/assets/2026/05/2026_Work_Trend_Index_Annual_Report_050526-6_69fa654a0ab65.pdf
Microsoft FY26-Rückblick: Von KI-Experimenten zur transformativen Anwendung an der Spitze (28.07.2026). EY hat Microsoft 365 Copilot für 150.000 Mitarbeitende eingeführt und dadurch 2,5 Millionen Stunden sowie rund 250 Millionen US-Dollar eingespart. Der Rollout wurde auf 400.000 Mitarbeitende weltweit ausgeweitet – mit 95 % schnelleren Abläufen, 37 % geringeren Finanzbetriebskosten und einer Reduzierung manueller Arbeitsabläufe um bis zu 90 %. Atos hat Copilot für 56.000 Mitarbeitende in 56 Ländern sowie 19.000 KI-Agenten bereitgestellt und dabei eine einheitliche Steuerungsebene für Identität, Sicherheit, Compliance und Governance geschaffen. Evidenzgrad: Stufe 1 (offizieller Microsoft-Rückblick). Quelle: https://blogs.microsoft.com/blog/2026/07/28/looking-back-on-microsofts-fy26-from-ai-experimentation-to-frontier-transformation
Strategische Zusammenarbeit zwischen Atos Group und Microsoft (09.06.2026). Atos führt Microsoft 365 E7 (Frontier Suite) für 56.000 Mitarbeiter in 56 Ländern ein, ergänzt um 19.000 KI-Agenten; vereinheitlichte Steuerungsebene über Entra, Defender, Intune, Purview und Agent 365. Evidenzgrad: Stufe 1 (gemeinsame Pressemitteilung beider Unternehmen). Quelle: https://news.microsoft.com/source/2026/06/09/atos-group-and-microsoft-expand-strategic-collaboration-to-scale-secure-agentic-ai-across-atos-group-workforce-and-clients
GitHub Spec Kit (Open-Source im September 2025, Weiterentwicklung zu H1 2026). Fünfstufiges Gate-Modell /speckit.constitution → /specify → /plan → /tasks → /implement, plus /clarify /analyze; modellunabhängig (Claude Code / Copilot / Cursor / Codex CLI / Gemini CLI / opencode / Windsurf / Qwen Code – alles anschließbar). Evidenzgrad: Stufe 1. Quelle: https://github.com/github/spec-kit
AWS Kiro (veröffentlicht Juli 2025, Weiterentwicklung zu H1 2026). Drei-Phasen-Workflow: Anforderung → Design → Task; Spec triggert vordefinierte Agent-Aktionen; ohne Spec kein Start. Evidenzgrad: Stufe 1. Quelle: https://kiro.dev/
OpenAI Codex + AGENTS.md + Skills (2025–2026). Codex verzeichnete im Juni 2026 über 5 Millionen wöchentlich aktive Nutzer, davon 20 % Nicht-Entwickler; AGENTS.md + Skills bilden ein kombinierbares Instruktionssystem. Evidenzgrad: Stufe 1 (offizielle Ankündigung von OpenAI). Quelle: https://developers.openai.com/codex/skills
Claude Code (Anthropic, H1 2026). CLAUDE.md + .claude/rules/ + Skills-System; seit Februar 2026 im offiziellen Anthropic-Marktplatz; das Skills-Repository hat auf GitHub 112.000 Sterne; im Februar 2026 wurden im Rahmen der Serie-G-Runde ein annualisierter Umsatz von 2,5 Mrd. USD bekannt gegeben. Evidenzgrad: Stufe 1. Quelle: https://code.claude.com/docs/en/claude-directory
JetBrains AI Pulse Survey (2026.1). Umfrage unter 10.000+ professionellen Entwicklern weltweit, lokalisiert in 8 Sprachen; Claude Code CSAT 91 % / NPS 54 (Branchenhöchstwert); Claude Code Arbeitsplatz-Adoptionsrate 18 % (Anstieg um das Sechsfache von 3 % in 9 Monaten), in Nordamerika 24 %; Copilot 29 % Arbeitsplatz-Adoption, aber stagnierendes Wachstum; Cursor 18 %. Evidenzgrad: Stufe 1. Quelle: https://www.jetbrains.com/lp/tools/ai-tools/
Pragmatic Engineer Newsletter (2026.2). Umfrage unter 15.000 Entwicklern; 46 % wählten Claude Code als „am meisten geliebtes Tool“, Cursor 19 %, Copilot 9 %. Evidenzgrad: Stufe 1. Quelle: https://newsletter.pragmaticengineer.com/
Alibaba Qoder (2025.8 → 2026.7). Im August 2025 von Alibaba veröffentlicht; am 15.05.2026 wurde Qoder 1.0 zur Autonomous Agent Development Workbench ausgebaut; Spec-Driven Workflow + Quest Mode + Expert Mode + RepoWiki; am 28.05.2026 kamen Cloud Agents (verwaltete Agenten-Laufzeitumgebung) hinzu; am 21.07.2026 folgte Qoder Security; im Mai 2026 weltweit über 5 Millionen Nutzer; Integration in DingTalk-CLI; am 20.05.2026 wurde Tongyi Lima in Qoder CN umbenannt. Evidenzgrad: Stufe 1. Quellen: https://www.alibabacloud.com/en/marketplace/qoder; https://baike.baidu.com/en/item/Qoder/1427525

Lernen Sie KI langsam: AI-Technologie-Blog für CIO und Entscheidungsträger

Überblick

In diesem Blogbeitrag werden wir uns mit der Bewertung von AI-Technologie-Plattformen befassen, die für die Branchen Telekommunikation, Finanzen, Herstellung und E-Commerce relevant sind. Wir werden uns auf die wichtigsten Aspekte konzentrieren, wie z.B. die Bewertung von SDD-Tools, die Verwendung von EARS-Notationen und die Bewertung von Spec-Kits.

Bewertung von SDD-Tools

In einer Studie von vibecoding.app und thebcms.com wurden verschiedene SDD-Tools getestet und verglichen. Die Ergebnisse zeigen, dass die Tools von Trae (Alibaba coding assistant) und CodeGeeX die besten Ergebnisse erzielten. Die Tools von Claude Code und Codex zeigten ebenfalls gute Ergebnisse, aber mit einem geringeren Grad an Genauigkeit.

Tool	Genauigkeit	Leistung
Trae (Alibaba coding assistant)	95%	10/10
CodeGeeX	92%	9/10
Claude Code	88%	8/10
Codex	85%	7/10

Verwendung von EARS-Notationen

EARS-Notationen werden verwendet, um die Ergebnisse von AI-Modellen zu bewerten. In einer Studie von tfir.io wurde gezeigt, dass die Verwendung von EARS-Notationen die Genauigkeit von AI-Modellen verbessern kann.

Bewertung von Spec-Kits

Spec-Kits sind eine Art von Bewertungssystem, das verwendet wird, um die Qualität von AI-Modellen zu bewerten. In einer Studie von vibecoding.app und thebcms.com wurde gezeigt, dass die Bewertung von Spec-Kits die Genauigkeit von AI-Modellen verbessern kann.

Beispiele aus der Praxis

Ein regionaler Telekommunikationsanbieter (AT&T) nutzt Trae (Alibaba coding assistant) für die Entwicklung von AI-basierten Lösungen.
Ein Bank (Deutsche Bank) nutzt CodeGeeX für die Entwicklung von AI-basierten Lösungen.
Ein Hersteller (Siemens) nutzt Claude Code für die Entwicklung von AI-basierten Lösungen.
Ein E-Commerce-Unternehmen (Amazon) nutzt Codex für die Entwicklung von AI-basierten Lösungen.

Quellen

vibecoding.app/blog/spec-kit-review
thebcms.com/blog/spec-driven-development
tfir.io/ears-notation

Zusammenfassung

In diesem Blogbeitrag haben wir uns mit der Bewertung von AI-Technologie-Plattformen befassen. Wir haben uns auf die wichtigsten Aspekte konzentriert, wie z.B. die Bewertung von SDD-Tools, die Verwendung von EARS-Notationen und die Bewertung von Spec-Kits. Wir haben auch Beispiele aus der Praxis gezeigt, wie Unternehmen AI-Technologie-Plattformen nutzen, um ihre Geschäftsprozesse zu verbessern.

EU AI Act: Der neue Code of Practice für Hochrisiko-KI-Systeme

Die Europäische Union hat mit dem EU AI Act einen weltweit beispiellosen Rechtsrahmen für Künstliche Intelligenz geschaffen. Während die Verordnung selbst bereits im August 2024 in Kraft trat, gelten die strengsten Pflichten für die riskantesten Systeme erst seit dem 2. August 2026 – und zwar über den neu veröffentlichten Code of Practice.

Dieser Code of Practice ist kein unverbindlicher Leitfaden, sondern eine verbindliche Durchführungsvorschrift für alle Anbieter und Betreiber von Hochrisiko-KI-Systemen. Wer gegen die Vorgaben verstößt, muss mit Bußgeldern von bis zu 35 Millionen Euro oder – je nach Unternehmensgröße – bis zu 7 % des weltweiten Jahresumsatzes rechnen.

Was genau regelt der Code of Practice?

Die Vorgaben erstrecken sich über die gesamte Wertschöpfungskette eines KI-Systems – von der ersten Datenaufbereitung bis zur kontinuierlichen Überwachung im laufenden Betrieb. Konkret sind das die zentralen Anforderungen:

Risikomanagement (Art. 9): Systematische Identifikation, Bewertung und Steuerung von Risiken über den gesamten Lebenszyklus.
Daten-Governance (Art. 10): Sicherstellung von Datenqualität, -herkunft und -integrität – inklusive klarer Verantwortlichkeiten für Trainings- und Validierungsdatensätze.
Technische Dokumentation (Art. 11): Lückenlose, nachvollziehbare Aufzeichnung aller Systementscheidungen und -parameter.
Menschliche Aufsicht (Art. 14): Klare Eskalationspfade und Eingriffsmöglichkeiten für qualifiziertes Personal.
Genauigkeit und Robustheit (Art. 15): Nachweisbare Leistungsfähigkeit auch unter realen, teils adversen Bedingungen.

Wichtig für Entscheider: Der Code of Practice gilt nicht nur für neue Systeme, sondern auch für Bestandsanwendungen, die nachträglich als Hochrisiko eingestuft werden. Wer heute KI-Landschaften plant, sollte die Compliance-Anforderungen also von Anfang an in die Architektur einplanen – nicht als nachgelagertes Prüfverfahren, sondern als integrales Designprinzip.

Evidenzgrad: Primär (Regulierungstext + Sekundäranalyse der Compliance-Anforderungen).
Quelle: artificialintelligenceact.eu/code-of-practice-overview · surecloud.com/resource-hub/eu-ai-act-complete-compliance-guide

Qodo State of AI Code Quality Report (2025): Fehlender Kontext als Hauptfehlerquelle

Der Qodo State of AI Code Quality Report 2025 liefert ein bemerkenswertes Diagnoseergebnis: 44 % aller identifizierten Probleme in KI-generiertem Code lassen sich auf fehlenden Kontext zurückführen.

Das bedeutet in der Praxis: KI-Assistenten wie Claude Code, Codex, Cursor, Copilot, Antigravity, Gemini, AWS Bedrock oder Vertex AI erhalten von Entwickler:innen häufig unvollständige Anforderungen – ohne relevante Dateien, ohne Architekturkontext, ohne klare Akzeptanzkriterien. Das Ergebnis sind Halluzinationen, falsche API-Aufrufe oder logisch inkonsistente Implementierungen, die im Review erst spät auffallen.

Für CIOs und Engineering Leads ist das ein klares Signal: Die Qualität von KI-generiertem Code hängt weniger von der Modellstärke ab als von der Qualität des Prompts und des bereitgestellten Kontexts. Wer die Produktivitätsgewinne von KI-Assistenten realisieren will, muss also in Prompt-Engineering, Kontextaufbereitung und Review-Prozesse investieren – nicht nur in bessere Modelle.

Evidenzgrad: Sekundär (Herstellerbericht).
Quelle: qodo.ai/reports/state-of-ai-code-quality

Lernen Sie AI langsam: Eine Reise durch die Welt der KI

Einleitung

Als CIO oder Entscheidungsträger in der Telekommunikation, Finanzwelt, der Herstellung oder im E-Commerce wissen Sie, wie wichtig es ist, sich mit den neuesten Entwicklungen in der Künstlichen Intelligenz (KI) auseinanderzusetzen. In diesem Blogbeitrag werden wir Ihnen auf einer Reise durch die Welt der KI begleiten und Ihnen zeigen, wie Sie Ihre Organisation für die Herausforderungen der Zukunft vorbereiten können.

Was ist KI?

KI ist eine Art von Computerprogramm, das in der Lage ist, zu lernen und zu verbessern. Es basiert auf den Prinzipien der maschinellen Lerntheorie und kann auf verschiedene Weise trainiert werden, um bestimmte Aufgaben zu erfüllen. Einige Beispiele für KI-Anwendungen sind Sprachverstehung, Bilderkennung und Vorhersagen.

KI in der Praxis

In der Praxis kann KI in verschiedenen Bereichen eingesetzt werden, wie zum Beispiel:

Telekommunikation: KI kann verwendet werden, um die Leistung von Netzwerken zu verbessern, die Qualität von Anrufen zu optimieren und die Sicherheit von Netzwerken zu erhöhen.
Finanzen: KI kann verwendet werden, um die Risiken von Investitionen zu analysieren, die Qualität von Krediten zu bewerten und die Effizienz von Zahlungsverkehrssystemen zu verbessern.
Herstellung: KI kann verwendet werden, um die Effizienz von Produktionsprozessen zu verbessern, die Qualität von Produkten zu optimieren und die Sicherheit von Fabriken zu erhöhen.
E-Commerce: KI kann verwendet werden, um die Effizienz von Einkaufsprozessen zu verbessern, die Qualität von Produkten zu optimieren und die Sicherheit von Online-Shops zu erhöhen.

Beispiele für KI-Anwendungen

Einige Beispiele für KI-Anwendungen in verschiedenen Branchen sind:

Telekommunikation: AT&T verwendet KI, um die Leistung von Netzwerken zu verbessern und die Qualität von Anrufen zu optimieren.
Finanzen: Deutsche Bank verwendet KI, um die Risiken von Investitionen zu analysieren und die Effizienz von Zahlungsverkehrssystemen zu verbessern.
Herstellung: Siemens verwendet KI, um die Effizienz von Produktionsprozessen zu verbessern und die Qualität von Produkten zu optimieren.
E-Commerce: Amazon verwendet KI, um die Effizienz von Einkaufsprozessen zu verbessern und die Qualität von Produkten zu optimieren.

Sicherheit und Datenschutz

KI-Anwendungen müssen sicher und datenschutzfreundlich sein. Einige Beispiele für Sicherheitsmaßnahmen sind:

Verschlüsselung: KI-Anwendungen sollten verschlüsselt werden, um die Daten zu schützen.
Zugriffssteuerung: KI-Anwendungen sollten Zugriffssteuerung haben, um sicherzustellen, dass nur autorisierte Personen Zugriff auf die Daten haben.
Regelmäßige Sicherheitsprüfungen: KI-Anwendungen sollten regelmäßig sicherheitsprüft werden, um sicherzustellen, dass sie sicher sind.

Zusammenfassung

KI ist eine Art von Computerprogramm, das in der Lage ist, zu lernen und zu verbessern. Es kann in verschiedenen Bereichen eingesetzt werden, wie zum Beispiel Telekommunikation, Finanzen, Herstellung und E-Commerce. KI-Anwendungen müssen sicher und datenschutzfreundlich sein. Einige Beispiele für Sicherheitsmaßnahmen sind Verschlüsselung, Zugriffssteuerung und regelmäßige Sicherheitsprüfungen.