Der globale Leiter für Lösungsarchitektur bei AWS teilt sein KI-gestütztes Modernisierungsmodell
Saurabh Shrivastava erklärt, wie CTOs KI-Experimente durch eine Neugestaltung der Entwicklung rund um Governance, menschliche Validierung und geschäftlichen Nutzen in produktionsreife Systeme verwandeln können.
Saurabh Shrivastava
Globaler Leiter für Lösungsarchitektur
Industrialisierung: Eine erfolgreiche Einführung von KI erfordert Betriebsmodelle, Governance, Architektur, Fachkräfte und Produktdisziplin – keine isolierten Experimente.
Bereitstellung vor Ort: Die direkt vor Ort eingesetzte Entwicklung bringt die Modernisierung durch agentenbasierte KI in reale Umgebungen und berücksichtigt frühzeitig Einschränkungen bei Daten, Code und Sicherheit.
Vertrauensmodell: Nutzen Sie deterministische Ermittlung, KI-gestützte Implementierung und menschliche Validierung, um schneller zu modernisieren, ohne Genauigkeit, Sicherheit oder Verantwortlichkeit zu beeinträchtigen.
Kostenkontrolle: Die Wirtschaftlichkeit der Inferenz ist entscheidend: Modellrouting, Caching, Stapelverarbeitung, Quantisierung und optimierte Bereitstellung können Kosten senken und die Zuverlässigkeit verbessern.
KI-Entwicklungslebenszyklus: Der KI-Entwicklungslebenszyklus (AI-DLC) gestaltet die Bereitstellung rund um Initiierung, Konstruktion und Betrieb neu und integriert Agenten, Sicherheitsschleusen, Evaluierung, Beobachtbarkeit und kontinuierliche Verbesserung.
Saurabh Shrivastava ist globaler Leiter für Lösungsarchitektur und vor Ort eingesetztes Engineering bei Amazon Web Services, wo er sich auf agentenbasierte KI und die Modernisierung von Unternehmen konzentriert.
Wir haben uns mit Saurabh zusammengesetzt, um mehr über die neuen Engineering-Modelle zu erfahren, die er bei AWS einsetzt. Das hat er uns berichtet.
KI verantwortungsvoll industrialisieren
Ich bin eine Führungskraft für Technologie- und KI-Transformation mit mehr als 20 Jahren Erfahrung darin, Unternehmen dabei zu helfen, komplexe technologische Veränderungen in skalierbare Geschäftsergebnisse umzuwandeln. Mein beruflicher Weg führte mich durch Engineering, Unternehmensarchitektur, produktorientiertes Field Engineering, Cloud-Transformation und nun agentenbasierte KI sowie Softwarefabrik-Modelle bei AWS.
Möchten Sie mehr vom The CTO Club?
Erstellen Sie ein kostenloses Konto, um diesen Beitrag fertigzulesen und einer Community von CTOs und Technikleitern beizutreten, die praxisnahe Frameworks, Tools und Einblicke für die Entwicklung, Einführung und Skalierung KI-gesteuerter Technologien teilen.
Have an account? Log In
Zu Beginn meiner Karriere habe ich groß angelegte Unternehmensplattformen in den Bereichen Telekommunikation, Einzelhandel, Lieferketten, Fintech und Forschung und Entwicklung aufgebaut und geleitet. Dadurch entwickelte ich ein starkes Verständnis für systemisches Denken, Zuverlässigkeit, Integrationskomplexität und die Realität des Betriebs von Technologien im Unternehmensmaßstab.
Bei AWS entwickelte sich meine Rolle von der Unterstützung von Kunden bei der Modernisierung ihrer Infrastruktur und Anwendungen hin zur Leitung globaler Initiativen für Lösungsarchitektur und vor Ort eingesetztes Engineering mit Schwerpunkt auf KI, Modernisierung und agentenbasierten Plattformen. Ich habe mit Führungskräften aus Unternehmen, Partnern, Produktteams und Engineering-Teams zusammengearbeitet, um von Strategie und Experimenten zu kontrollierten, produktionsreifen Plattformen überzugehen.
KI ist nicht mehr nur eine weitere technologische Welle. Sie verändert, wie Unternehmen Software entwickeln, wie Mitarbeitende arbeiten, wie Kunden interagieren und wie Technologieorganisationen agieren müssen. Die eigentliche Führungsherausforderung besteht nicht nur darin, Modelle oder Tools auszuwählen. Es geht darum, das Betriebsmodell, die Architektur, die Governance, die Kompetenzen und die Produktdisziplin zu schaffen, um KI verantwortungsvoll zu industrialisieren.
Leitung der AWS-Lösungsarchitektur
Als globaler Leiter für Lösungsarchitektur und FDE leite ich die globale AWS-Organisation für Lösungsarchitektur und vor Ort eingesetztes Engineering mit Schwerpunkt auf agentenbasierten KI-Plattformen, der Modernisierung von Unternehmen und der Cloud-Transformation im Produktionsmaßstab.
Die Organisation arbeitet im Unternehmensmaßstab und kooperiert mit großen globalen Kunden, strategischen Partnern, Produktteams, spezialisierten Engineering-Teams und regionalen Field-Organisationen. Der Architekturbereich ist breit gefächert: KI-/ML-Plattformen, agentenbasierte Workflows, Grundlagen für Daten und Analysen, Anwendungsmodernisierung, cloudnative Infrastruktur, Sicherheit, Governance und in Partnerlösungen integrierte Lösungen.
Ich leite, befähige und beeinflusse weltweit mehr als 200 Spezialisten, Partneringenieure und technische Führungskräfte im Field-Bereich. Die Arbeit ist äußerst komplex, da wir keine isolierten Demos entwickeln. Wir helfen Unternehmen dabei, von frühen KI-Ideen und Geschäftsszenarien für die Modernisierung zu wiederholbaren, sicheren und produktionsreifen Plattformen überzugehen, die über Geschäftsbereiche, Märkte und Kundenumgebungen hinweg skaliert werden können.
Unser Bereitstellungsmodell kombiniert vor Ort eingesetztes Engineering, globale Plattformmechanismen, partnergestützte Umsetzung und Feedbackschleifen zwischen Produkt- und Field-Teams. Mein Team entwickelt wiederverwendbare Blaupausen, Referenzarchitekturen, Demos für Führungskräfte, technische Leitfäden, Governance-Muster und kombinierbare Lösungsmodelle, die die Einführung beschleunigen und gleichzeitig Qualität, Sicherheit und operative Disziplin gewährleisten.
Warum ein Modell für vor Ort eingesetztes Engineering bei KI unverzichtbar ist
Im vergangenen Jahr habe ich ein Modell für vor Ort eingesetztes Engineering für die KI-gestützte Modernisierung eingeführt.
Im Cloud-Zeitalter verfügten wir über wiederverwendbare Referenzarchitekturen, Lösungsblaupausen, Bereitstellungsmuster und Governance-Kontrollpunkte. Diese waren notwendig, reichten im Zusammenhang mit KI jedoch nicht aus. Kunden hatten weiterhin Schwierigkeiten, vom Machbarkeitsnachweis zur Produktion zu gelangen, da die schwierigste Arbeit in ihrer tatsächlichen Umgebung stattfand: bei Daten, Anwendungslandschaft, Codekomplexität, Sicherheitsanforderungen und Betriebsmodell.
Deshalb führte ich einen FDE-Mechanismus ein, der Ingenieure deutlich näher an die tatsächlichen Workloads des Kunden heranbringt. Statt von außen zu beraten, arbeitet das FDE-Team mit den Daten, dem Code, der Architektur und den Bereitstellungsteams des Kunden zusammen, um Modernisierungskandidaten zu identifizieren, nutzbare Ressourcen zu entwickeln und den ersten Workload in die Produktion zu überführen.
Außerdem führte ich ein einfaches 3-3-3-Modell ein: 3 Tage für die Erkundung, 3 Wochen für die Bewertung und 3 Monate, um den ersten Workload in die Produktion zu überführen. Dadurch erhielten Führungskräfte einen klaren Weg von der KI-Ambition zu messbarem Nutzen.
Die Auswirkungen waren erheblich. Kunden konnten ihre Modernisierungsreise um das 2- bis 4-Fache beschleunigen, die Kosten um bis zu die Hälfte senken und über Demos hinaus einen tatsächlich realisierten ROI erzielen. Noch wichtiger war, dass sich dadurch das Gespräch mit Führungskräften veränderte. KI war kein Nebenexperiment mehr, sondern wurde zu einem praktischen Mechanismus, um reale Workloads zu modernisieren, die Produktivität im Engineering zu steigern und messbaren Geschäftswert zu schaffen.
Schneller modernisieren, ohne Vertrauen zu verspielen
\u003cstrong\u003eKI wird bei der Arbeit am zukünftigen Zielbild leistungsfähiger: Es generiert Modernisierungsoptionen, schlägt neue Architekturen vor, definiert Servicegrenzen, entwickelt Migrationsmuster, schreibt Code, generiert Tests und beschleunigt die Umsetzung. Dieser Teil kann stärker probabilistisch sein, weil KI Optionen erkunden und die Geschwindigkeit der Entwicklung verbessern kann. Aber auch dort \u003cem\u003ebleibt die endgültige Entscheidung\u003c/em\u003e beim Menschen.\u003c/strong\u003e
Ich nutze KI intensiv, um mein technisches Verständnis, die Mustererkennung und den Entwicklungsdurchsatz zu steigern, delegiere aber die Verantwortung nicht an KI.
In komplexen Unternehmen basiert das Geschäft häufig auf jahrzehntelangem Code, technischen Schulden, nicht dokumentierten Abhängigkeiten und eingebetteten Geschäftsregeln. In diesem Umfeld benötigen wir sowohl deterministische als auch probabilistische Ansätze. Wenn es darum geht, geschäftskritische Systeme zu verstehen, kann man sich nicht ausschließlich auf die probabilistische Erkennung durch KI verlassen.
Bei der Codeerkennung, der Extraktion von Geschäftsregeln, der Abhängigkeitsanalyse, der Zuordnung von Funktionen und der Bewertung des Ist-Zustands bevorzuge ich einen stärker deterministischen Ansatz. Wir benötigen Nachvollziehbarkeit, Wiederholbarkeit, Belege und Vertrauen in das tatsächliche Verhalten des Systems. KI kann durch Zusammenfassungen, Clusterbildung und die Beschleunigung der Analyse unterstützen, aber die Grundlage müssen überprüfbare Fakten aus Code, Protokollen, Datenflüssen, Laufzeitverhalten und Architekturbelegen bilden.
KI wird bei der Arbeit am zukünftigen Zielbild leistungsfähiger: Sie generiert Modernisierungsoptionen, schlägt neue Architekturen vor, definiert Servicegrenzen, entwickelt Migrationsmuster, schreibt Code, generiert Tests und beschleunigt die Umsetzung. Dieser Teil kann stärker probabilistisch sein, weil KI Optionen erkunden und die Geschwindigkeit der Entwicklung verbessern kann.
Aber auch dort bleibt die endgültige Entscheidung beim Menschen. Verantwortliche Entwickler und Führungskräfte müssen Architekturentscheidungen, die Sicherheitslage, die Produktionsreife, Compliance-Risiken, Auswirkungen auf Kunden und die Abwägung von Investitionen überprüfen.
Mein Modell lautet daher: deterministische Erkennung, durch KI beschleunigtes Design und Implementierung sowie eine vom Menschen gesteuerte Validierung. Diese Kombination ermöglicht es uns, schneller zu modernisieren, ohne Vertrauen, Kontrolle oder die unternehmerische Verantwortung zu verlieren.
Die Nachteile von KI in Entwicklungsabläufen
Das wichtigste positive Ergebnis war, dass KI den Weg von der Erkennung bis zur Produktion erheblich verkürzte, wenn sie in einen disziplinierten Entwicklungsablauf eingebettet wurde.
KI beschleunigte außerdem das Verständnis von Code, die Extraktion von Geschäftsregeln, die Abhängigkeitsanalyse, die Testgenerierung, die Dokumentation und die Modernisierungsplanung. Sie reduzierte den Zeitaufwand für manuelle Analysen und half Entwicklungsteams, sich stärker auf Architekturentscheidungen, Validierung und Produktionsreife zu konzentrieren.
KI kann jedoch sehr schnell sehr teuer werden, wenn Teams nicht auf die Wirtschaftlichkeit der Inferenz achten. In großen Unternehmen mit Millionen von Nutzern können sich die Tokenkosten von Spitzenmodellen auf Millionen von Dollar summieren, wenn jede Interaktion ohne Optimierung von externen Drittanbieter-Grundlagenmodellen abhängt.
Eine Erkenntnis lautet, dass die KI-Architektur auch eine Kostenarchitektur umfassen muss. Für bestimmte Arbeitslasten sollten Unternehmen selbst gehostete oder in der Cloud gehostete Inferenz mit GPUs oder Beschleunigern prüfen, einschließlich Optionen wie vLLM auf einer Cloud-Infrastruktur. Dies bietet mehr Kontrolle über Kosten, Latenz, Datengrenzen und die Strategie für die Bereitstellung von Modellen. Techniken wie KV-Caching, kontinuierliche Stapelverarbeitung, Quantisierung und Kernel-Optimierung können die GPU-Auslastung deutlich verbessern und die Inferenzkosten senken.
Kosten sind nicht der einzige Nachteil. KI kann auch ein falsches Sicherheitsgefühl erzeugen, wenn Teams sie ohne Governance einsetzen. Zu den Risiken gehören ein unvollständiges Verständnis des Codes, halluzinierte Abhängigkeiten, eine unzureichende Testabdeckung, Sicherheitslücken und dass Teams zu schnell vom Prototyp zur Produktion übergehen.
Warum KI bei der durchgängigen Modernisierung von Altsystemen Schwierigkeiten hat
Am meisten hatte KI Schwierigkeiten, wenn Teams sie aufforderten, technische Entscheidungen ohne ausreichenden Systemkontext zu treffen.
Ein häufiges Beispiel ist die Modernisierung von Altsystemen. KI kann Code zusammenfassen, Migrationsideen entwickeln und sogar schnell neuen Code erzeugen. In großen Unternehmen geht die tatsächliche Komplexität jedoch über den Code hinaus. Sie umfasst jahrzehntelang gewachsene Geschäftsregeln, nicht dokumentierte Integrationen, Stapelverarbeitungsaufträge, Datenabhängigkeiten, betriebliche Ausnahmen, Sicherheitsanforderungen und organisatorische Zuständigkeiten. Wenn Sie die KI auffordern, diese Umgebung mit nur einem unvollständigen Überblick zu modernisieren, kann sie selbstbewusste, aber unvollständige Antworten liefern.
Die Produktionsreife ist ein weiterer Bereich, in dem sie Schwierigkeiten hat. KI kann sehr schnell Prototypen erstellen, aber viele Prototypen werden nicht automatisch zu sicheren, beobachtbaren, resilienten und kosteneffizienten Produktionssystemen. Teams unterschätzen mitunter den erforderlichen Aufwand für Tests, Governance, Reaktion auf Vorfälle, Überwachung, Modellbewertung, Datenqualität und Lebenszyklusverwaltung.
Wie Ingenieurteams Produkte verbessern und dabei Inferenzkosten und Zuverlässigkeit kontrollieren können
Hier ist ein Beispiel aus einer großen Plattform zur Erstellung von Medien- und Marketinginhalten, auf der KI Nutzer dabei unterstützt, ihre Absicht im Unternehmensmaßstab in fertige digitale Inhalte umzuwandeln.
Der Arbeitsablauf beginnt, wenn ein Nutzer beschreibt, was er erstellen möchte: eine Kampagne zur Produkteinführung, ein Motiv für soziale Medien, eine Verkaufspräsentation, einen Videoclip oder ein lokalisiertes Marketingmaterial. Die KI interpretiert die Absicht des Nutzers, einschließlich Zielgruppe, Format, Tonalität, Markenrichtlinien, erforderlicher Ressourcen, Kanalanforderungen und Compliance-Vorgaben.
Von dort aus verwendet die Plattform einen agentenbasierten Arbeitsablauf. Ein Agent ruft von der Marke freigegebene Vorlagen, Logos, Schriftarten, Farben und Kampagnenressourcen ab. Ein anderer erstellt Texte und kreative Varianten. Ein weiterer schlägt Layouts vor. Ein anderer prüft die Markenkonformität, Barrierefreiheit, Richtlinien und Inhaltssicherheit. Eine abschließende Orchestrierungsebene setzt die Ausgabe zu bearbeitbaren Inhalten zusammen und leitet sie durch Freigabe- oder Veröffentlichungsabläufe.
In diesem Maßstab stand das Ingenieurwesen nicht nur vor Herausforderungen hinsichtlich der Modellqualität, sondern auch hinsichtlich Inferenzökonomie, Latenz, Zuverlässigkeit und Governance. Das Team optimierte eine sehr große Inferenzumgebung, die etwa 10.000 Rechenknoten und rund 80.000 GPUs unterstützte. Die Architektur kombinierte GPU-Kapazitäten mehrerer Cloud-Anbieter und zugelassener Drittanbieter und verband diese Umgebungen über eine hybride Netzwerkschicht. Dadurch konnte die Plattform Workloads flexibel anhand von Kosten, Latenz, Verfügbarkeit und Datenlokalität platzieren.
Menschen behielten an den entscheidenden Beurteilungspunkten die Kontrolle. Die KI erzeugte Optionen, empfahl Layouts, verfasste Texte und beschleunigte die Produktion, aber der Nutzer oder Markeninhaber genehmigte das endgültige Ergebnis.
Das Team führte außerdem eine diszipliniertere Strategie für die Modellbereitstellung ein. Statt jede Anfrage an das teuerste Spitzenmodell zu senden, leitete die Plattform Anfragen an Modelle weiter, die für den jeweiligen Zweck geeignet waren, darunter offene Modelle wie Kimi und Qwen, die über optimierte Laufzeitumgebungen wie vLLM und Muster nach dem Vorbild von Ollama bereitgestellt wurden. Das Team setzte außerdem Techniken zur Inferenzoptimierung ein, darunter KV-Caching, kontinuierliche Stapelverarbeitung, Quantisierung, Speicheroptimierung und Optimierung auf Kernel-Ebene, um die GPU-Auslastung zu verbessern und Kosten zu senken.
Menschen behielten an den entscheidenden Beurteilungspunkten die Kontrolle. Die KI erzeugte Optionen, empfahl Layouts, verfasste Texte und beschleunigte die Produktion, aber der Nutzer oder Markeninhaber genehmigte das endgültige Ergebnis. Die Ingenieurteams waren für die Schutzmaßnahmen zuständig: Sicherheit, Datenzugriff, Modellauswahl, Beobachtbarkeit, Latenz, Kostenkontrollen, Sicherheitsprüfungen und Rückkopplungsschleifen.
Das Ergebnis war ein KI-Arbeitsablauf, der Teil des Produkterlebnisses wurde und nicht nur ein internes Produktivitätswerkzeug blieb. Er verkürzte die Zeit von der Idee bis zum fertigen Inhalt, verbesserte die Personalisierung, erhöhte die Wiederverwendung freigegebener Markenkomponenten und schuf eine Rückkopplungsschleife, in der Nutzeränderungen und Interaktionsdaten künftige Empfehlungen verbesserten. Gleichzeitig gab die Architektur dem Unternehmen deutlich mehr Kontrolle über Inferenzkosten, Zuverlässigkeit und Governance.
Warum die Einführung von KI eine Produktsichtweise erfordert
Bei der Einführung von KI-Werkzeugen geht es weniger um die Nutzung von Werkzeugen als um eine Veränderung des Betriebsmodells im Ingenieurwesen.
Anfangs denken viele Organisationen, die Herausforderung bestehe darin, Ingenieurteams Zugang zu Copiloten, Programmierassistenten, Modell-APIs oder internen KI-Plattformen zu geben. Das ist hilfreich, reicht aber nicht aus. Ohne klare Vorgehensmuster nutzen Teams KI uneinheitlich. Einige verwenden sie nur zur Codegenerierung. Andere nutzen sie für Dokumentation. Manche vertrauen ihr zu stark. Wieder andere vermeiden sie, weil sie sich über Sicherheits-, IP- oder Qualitätsrisiken unsicher sind.
Wenn ich noch einmal von vorn beginnen könnte, würde ich den KI-gestützten Ingenieurarbeitsablauf noch früher definieren: wo KI eingesetzt werden sollte und wo nicht, welche Nachweise erforderlich sind, was Menschen prüfen müssen und wie die Ausgabe getestet, abgesichert und in die Produktion überführt wird.
Dies hätte einige Probleme vermieden. Erstens hätten wir die uneinheitliche Nutzung in den Teams reduzieren können. Zweitens hätten wir ein unangebrachtes Vertrauen in KI-generierten Code oder Analysen vermeiden können, die zwar korrekt aussahen, aber nicht genügend Kontext enthielten. Drittens hätten wir die Kosten früher kontrollieren können, indem wir von Anfang an Modell-Routing, Token-Budgetierung, Caching und Inferenz-Governance implementiert hätten. Viertens hätten wir bessere wiederverwendbare Muster schaffen können, anstatt jedes Team seinen eigenen Ansatz entwickeln zu lassen.
Die wichtigste Erkenntnis ist, dass die Einführung von KI eine Produkt- und Plattformmentalität erfordert. Es braucht Befähigung, Leitplanken, Beobachtbarkeit, Kostenkontrollen, Sicherheitsprüfungen, wiederverwendbare Prompts und Agenten, Evaluierungsmuster sowie eine klare menschliche Verantwortlichkeit. Andernfalls erhöht KI die Aktivität, ohne zwangsläufig die Qualität der Entwicklung oder den geschäftlichen Nutzen zu steigern.
Warum der SDLC zum AI-DLC werden muss
CTOs sollten den Lebenszyklus der Softwarebereitstellung selbst aktiv neu gestalten. Ich betrachte dies als den Übergang vom traditionellen SDLC zum AI-DLC, einem durch KI erweiterten Bereitstellungslebenszyklus für das Zeitalter agentischer KI.
Im traditionellen SDLC folgen wir häufig linearen Phasen: Anforderungsanalyse, Design, Entwicklung, Bereitstellung und Unterstützung. Das funktionierte einigermaßen gut, als das Hauptziel darin bestand, deterministische Software durch strukturierte Übergaben zu entwickeln. Mit KI, insbesondere mit agentischer KI, wird der Lebenszyklus jedoch iterativer und komprimierter.
Ich unterteile den AI-DLC vereinfacht in drei wesentliche Phasen: Initiierung, Konstruktion und Betrieb.
- In der Initiierungsphase unterstützt KI die Erkundung, das Verständnis des Codes, die Extraktion von Geschäftsregeln, die Abhängigkeitsanalyse, die Klärung von Anforderungen, die Risikoidentifizierung und die Planung des Zielzustands.
- In der Konstruktionsphase unterstützt KI bei Architekturvarianten, der Zerlegung von Diensten, der Generierung von Code und Tests, der Dokumentation, Sicherheitsprüfungen, Infrastrukturmustern und der Durchführung der Modernisierung.
- Im Betrieb unterstützt KI die Beobachtbarkeit, die Erstbewertung von Vorfällen, Rückkopplungsschleifen, die Modellevaluierung, die Kostenoptimierung, Governance und kontinuierliche Verbesserung.
Der entscheidende Punkt ist, dass der AI-DLC nicht einfach der SDLC mit einem hinzugefügten Programmierassistenten ist. Er ist ein neu gestaltetes Betriebsmodell für die Entwicklung. Er integriert KI-Agenten, deterministische Erkundung, menschliche Validierung, Sicherheitsschleusen, Produktionsreife und Kosten-Governance in einen einzigen Arbeitsablauf.
Wie sich Entwicklungsteams durch KI verändern
KI hat Entwicklungsteams von einer rollenbasierten, sequenziellen Arbeitsweise hin zu stärker integrierten, ergebnisorientierten Einheiten verändert.
Früher organisierten wir uns entlang klar abgegrenzter Rollen: Architekten, Anwendungsentwickler, Dateningenieure, DevOps, Sicherheit, Qualitätssicherung und Betrieb. Diese Rollen sind weiterhin wichtig, aber KI komprimiert den Lebenszyklus und verringert den Wert langer Übergaben. Die leistungsstärksten Teams sind funktionsübergreifender aufgestellt und näher am Geschäftsproblem.
Für KI-gestützte Modernisierung und Produktentwicklung suche ich inzwischen Teams, die mehrere Fähigkeiten vereinen: solide Grundlagen in der Softwareentwicklung, Cloud- und Plattformtechnik, Daten- und KI-Kompetenz, Sicherheitsbewusstsein, Produktdenken und operatives Urteilsvermögen. Außerdem schätze ich Entwickler, die in unklaren Umgebungen arbeiten, aus ersten Prinzipien heraus denken und KI-Ergebnisse validieren, anstatt sie blind zu akzeptieren.
Das Modell der direkt beim Kunden eingesetzten Entwicklungsteams ist ein gutes Beispiel. Statt Architektur, KI-Entwicklung, DevOps und Sicherheit in getrennten, sequenziellen Bahnen zu halten, bringen wir diese Fähigkeiten näher an die Kunden- oder Geschäftsumgebung. Das Team arbeitet mit echtem Code, echten Daten, realen Einschränkungen und konkreten Erfolgskennzahlen.
Auch die Personalgewinnung hat sich verändert. Technische Tiefe ist mir weiterhin sehr wichtig, aber ich suche auch Systemdenker: Menschen, die Architektur verstehen, KI verantwortungsvoll einsetzen, mit Geschäftspartnern kommunizieren und Verantwortung für Ergebnisse im Produktionsbetrieb übernehmen. Im Zeitalter der KI sind die besten Entwickler nicht nur Codeproduzenten. Sie sind Problembeschreiber, Validierer und Erbauer wiederholbarer Systeme.
Wie sich die Wirksamkeit von KI messen lässt
CTOs sollten KI nicht nur anhand der Anzahl eingesetzter Pilotprojekte oder Copiloten oder der isolierten Modellgenauigkeit messen. Dies sind nützliche Signale, beweisen aber keine Transformation … CTOs müssen KI-Aktivitäten in wiederholbare Fähigkeiten umwandeln.
Eine Frage, die meiner Meinung nach häufiger gestellt werden sollte, lautet: Wie sollten CTOs messen, ob KI einen nachhaltigen Unternehmenswert schafft?
CTOs sollten KI nicht nur anhand der Anzahl eingesetzter Pilotprojekte oder Copiloten oder der isolierten Modellgenauigkeit messen. Dies sind nützliche Signale, beweisen aber keine Transformation.
CTOs sollten KI anhand von vier Dimensionen messen:
- Produktivität in der Entwicklung: Verkürzt KI die Durchlaufzeit, verbessert sie die Codequalität, erhöht sie die Testabdeckung, beschleunigt sie die Modernisierung und reduziert sie technische Schulden?
- Geschäftliche Auswirkungen: Verbessert KI das Kundenerlebnis, die Produktivität der Mitarbeitenden, die Umsatzkonversion, die Kosteneffizienz oder die Geschwindigkeit der Markteinführung?
- Produktionsreife: Sind KI-Systeme sicher, beobachtbar, zuverlässig, angemessen gesteuert und kostenkontrolliert? Gibt es eine klare menschliche Verantwortlichkeit und eindeutige Freigabekriterien für die Produktionsreife?
- Wiederverwendbarkeit und Skalierbarkeit: Entwickeln Teams wiederverwendbare KI-Dienste, Agenten, Prompts, Muster, Datenprodukte und Plattformfähigkeiten, oder erstellen sie isolierte Demos?
Das ist wichtig, weil KI eine große Menge sichtbarer Aktivitäten erzeugen kann, ohne nachhaltigen Wert zu schaffen. CTOs müssen KI-Aktivitäten in wiederholbare Fähigkeiten umwandeln. Das bedeutet, Strategie, Architektur, Betriebsmodell, Governance und Wirtschaftlichkeit miteinander zu verbinden.
Warum CTOs Experimente von der Industrialisierung trennen müssen
Hier ist mein Rat.
Erstens: Behandeln Sie KI nicht als Nebenexperiment. Betrachten Sie sie als eine neue Betriebsebene für das Unternehmen. KI wird beeinflussen, wie Software entwickelt wird, wie Mitarbeitende arbeiten, wie Kunden interagieren und wie Entscheidungen getroffen werden. Die Aufgabe des CTO besteht darin, die Organisation von verstreuten Pilotprojekten zu einer gesteuerten, skalierbaren KI-Plattformstrategie zu führen.
Zweitens: Trennen Sie Experimente von der Industrialisierung. Es ist sinnvoll, schnell zu experimentieren, aber KI für den Produktionseinsatz benötigt Architektur, Sicherheit, Daten-Governance, Evaluierung, Beobachtbarkeit, Kostenkontrollen und eine klare menschliche Verantwortlichkeit. Viele Unternehmen stecken fest, weil sie zahlreiche Demos, aber keinen wiederholbaren Weg in die Produktion haben. CTOs müssen diesen Weg schaffen.
Drittens: Konzentrieren Sie sich auf den geschäftlichen Wert, nicht auf die Neuartigkeit des Modells. Die erfolgreichen Organisationen werden nicht diejenigen sein, die einfach das neueste Modell verwenden. Es werden diejenigen sein, die KI in reale Arbeitsabläufe integrieren, ihre technologische Grundlage modernisieren, die Produktivität in der Entwicklung verbessern und Ergebnisse wie Durchlaufzeit, Kosteneffizienz, Kundenerlebnis, Umsatzauswirkungen und Risikoreduzierung messen.
Und viertens lautet mein praktischer Rat, gleichzeitig ein KI-Plattformmodell und ein Modell für kundennah eingesetzte Entwicklungsteams zu schaffen. Die Plattform ermöglicht Wiederverwendung, Governance und Skalierung. Das FDE-Modell bringt KI in reale Kunden- und Unternehmensarbeitslasten und nutzt dabei reale Daten, realen Code und reale Einschränkungen. So können CTOs von KI-Ambitionen zu einem tatsächlich erzielten ROI gelangen.
Auf dem Laufenden bleiben
Verfolgen Sie die Arbeit von Saurabh Shrivastava auf LinkedIn und auf seiner Amazon-Autorenseite.
Weitere Experteninterviews folgen im The CTO Club!
