CTO sagt, KI braucht ein neues Governance-Modell

Tyrone Grandison hatte in seiner 35-jährigen Karriere im Technologiebereich zahlreiche Führungspositionen auf C-Level inne und ist derzeit CTO der Cornerstone Assurance Corporation. Außerdem ist er der Autor von „The AI Revolution and Culture That Lasts“.

Wir haben mit Tyrone gesprochen, um zu erfahren, wie KI die Governance in Technologieorganisationen verändert. Das hat er uns erzählt.

35 Jahre im Technologiebereich

Ich leite eine schlanke Technologieorganisation, die ein wachsendes Unternehmen für Versicherungen und Finanzdienstleistungen namens Cornerstone Assurance Corporation unterstützt. Besonders interessant an dieser Rolle ist, dass wir einen modernen Technologiestack aufbauen und gleichzeitig in einer Branche mit erheblichen regulatorischen Anforderungen, sensiblen Finanzdaten, komplexen Integrationen mit Versicherungsträgern und sehr geringer Fehlertoleranz tätig sind.

Ich begann meine Karriere als Informatiker, lange bevor KI zum Thema jedes Gesprächs in Vorstandsetagen und jeder Konferenz-Keynote wurde. Im Laufe der Jahre führte mich meine Arbeit von der Entwicklung von Technologie zur Leitung von Organisationen durch die Veränderungen, die Technologie in ihnen bewirkte. Ich war als Chief Artificial Intelligence Officer, Chief Technology Officer, Chief Information Officer und Deputy Chief Data Officer tätig. Ich habe in Behörden, der Wissenschaft, Start-ups, der Beratung, gemeinnützigen Organisationen und Großunternehmen gearbeitet.

Nach 35 Jahren im Technologiebereich hatte ich das Privileg, zu beobachten, wie mehrere Dinge als „die Technologie, die alles verändern wird“ eingeführt wurden. Und einige davon haben es tatsächlich getan.

Jeder große Wandel zwingt Führungskräfte dazu, Entscheidungen zu treffen, bevor sie über perfekte Informationen verfügen. Er stellt Geschäftsmodelle, Betriebsmodelle, Unternehmenskultur, Talente und Governance infrage – und manchmal auch unser Verständnis davon, worin unsere eigenen Aufgaben eigentlich bestehen. KI tut all das gleichzeitig.

Was diesen Moment für mich jedoch besonders faszinierend macht, ist, dass wir darüber hinausgegangen sind, KI lediglich zur Analyse von Informationen einzusetzen. Wir verfügen jetzt über Systeme, die Inhalte generieren, Schlussfolgerungen ziehen, planen, gestalten, Code schreiben, Werkzeuge verwenden und zunehmend auch Maßnahmen ergreifen können. Das verändert das Führungsgespräch grundlegend.

Früher lautete die Frage: „Was kann KI leisten?“

Ich denke, dass dies schnell zur uninteressantesten Frage wird. Sogar zur falschen Frage.

Die weitaus wichtigeren Fragen lauten: Was sollten wir ihr erlauben? Wo bleibt menschliches Urteilsvermögen unverzichtbar? Wie müssen wir Organisationen neu gestalten, wenn Erkenntnisse selbst im Überfluss vorhanden sind? Und wie können wir das außerordentliche Potenzial dieser Technologie nutzen, ohne Risiken zu schaffen, die wir nicht verstehen, oder Systeme, die wir nicht beherrschen können?

Genau dort liegt heute meine Arbeit. Ich arbeite mit Führungskräften und Organisationen zusammen, um ihnen zu helfen, das Wesentliche von der beträchtlichen Menge an Rauschen rund um KI zu trennen, zu verstehen, was sich tatsächlich verändert, und dieses Verständnis in Strategie, Governance, Produkte und messbare Geschäftsergebnisse umzusetzen.

Wie KI Softwareentwicklungszyklen verändert

Eine der größten Veränderungen, die ich bei der Cornerstone Assurance Corporation vorgenommen habe, bestand darin, unseren Softwareentwicklungszyklus auf der Annahme aufzubauen, dass KI einen bedeutenden Anteil unseres Codes schreiben wird.

Vor dieser Änderung folgten wir einem ziemlich traditionellen Entwicklungsablauf. Ein Entwickler übernahm eine Anforderung, entwarf die Lösung, schrieb den Code, erstellte Tests, reichte einen Pull-Request ein, und ein anderer Entwickler überprüfte ihn. Natürlich setzten wir Automatisierung ein, aber den Großteil der kognitiven Arbeit – von der Anforderung bis zur Bereitstellung – erledigten weiterhin Menschen.

KI hat die wirtschaftlichen Grundlagen dieses Modells vollständig verändert.

Deshalb führten wir eine KI-gestützte Entwicklungspipeline ein: GitHub Copilot für Codegenerierung und Refactoring, ChatGPT und Claude für die KI-gestützte architektonische Untersuchung, die Zerlegung von Anforderungen, das Debugging und die Generierung von Testfällen. Unsere üblichen CI/CD- und Sicherheitstools sorgen dabei für die deterministischen Kontrollen rund um die von der KI erzeugten Arbeiten.

Warum von KI generierter Code ein neues Governance-Modell erfordert

Die wichtige Veränderung bestand jedoch nicht darin zu sagen: „Hey zusammen, ihr habt jetzt Copilot.“ Wir änderten das Governance-Modell.

Genehmigungsschranken

Wir behandeln von der KI generierten Code inzwischen fast wie Code, der von einem sehr schnellen Juniorentwickler eingereicht wurde, der niemals schläft, eine absurd große Menge an Dokumentation gelesen hat und gelegentlich mit enormer Überzeugungskraft etwas völlig Falsches sagt.

Das bedeutet, dass AI Code, Unit-Tests, API-Verträge, Dokumentation, Datenbankabfragen, Infrastrukturen und vorgeschlagene Lösungen generieren kann, aber weder die eigene Arbeit freigeben noch einen unkontrollierten Weg in die Produktion haben darf.

Wir haben ausdrückliche menschliche Freigabestufen für sicherheitsrelevante Änderungen, Authentifizierung und Autorisierung, den Umgang mit Kunden- und Finanzdaten, externe Integrationen und die Produktionsinfrastruktur eingeführt.

Automatisierte Tests

Außerdem haben wir die automatisierten Tests und Code-Reviews ausgeweitet, weil sich der Engpass verlagert hat. Wenn AI die Geschwindigkeit, mit der man Code erstellen kann, drastisch erhöht, besteht das Problem nicht mehr in der Codegenerierung. Das Problem besteht darin, nachzuweisen, dass der Code es verdient, ausgeführt zu werden.

Ein einfaches Beispiel ist die Erstellung von Tests. Früher implementierte ein Entwickler möglicherweise ein Feature und schrieb anschließend die naheliegenden Unit-Tests. Jetzt können wir AI auch bitten, Tests für fehlerhafte und ungewöhnliche Szenarien zu generieren. Was geschieht bei fehlerhaften Eingaben? Was geschieht, wenn eine API eine unerwartete Antwort zurückgibt? Was geschieht an einer Berechtigungsgrenze? Was geschieht, wenn ein Kundendatensatz unvollständige Daten enthält?

Dadurch erhält der menschliche Entwickler eine andere Aufgabe. Statt seine gesamte Zeit mit der Erstellung von Artefakten zu verbringen, widmet er mehr Zeit dem Hinterfragen von Annahmen und der Validierung des Codeverhaltens.

AI-Governance

Wir haben auch geändert, wie wir AI selbst steuern. Wir protokollieren AI-gestützte Aktivitäten, wo dies angemessen ist, halten sensible Kundeninformationen aus verbraucherorientierten AI-Tools heraus, kontrollieren, welche Modelle und Dienste auf Unternehmensdaten zugreifen können, und trennen Experimente vom Produktionszugriff. In der Versicherungs- und Finanzdienstleistungsbranche wird „das Modell hielt dies für eine gute Idee“ niemals eine Governance-Strategie darstellen.

Wie AI den Engpass in der Softwareentwicklung verlagert

Das größte Ergebnis, das ich durch die Integration von AI in unsere Entwicklungsabläufe beobachtet habe, ist Geschwindigkeit. Ich füge dieser Antwort jedoch immer ein Sternchen hinzu, denn Geschwindigkeit in die falsche Richtung ist keine Produktivität.

AI hat unseren Entwicklungszyklus drastisch verkürzt. Wir beobachten, dass Aufgaben, für die ein Entwickler früher mehrere Tage benötigte, innerhalb von Stunden von der Anforderung bis zu einer testbaren Implementierung gelangen. Für das Prototyping im Speziellen würde ich schätzen, dass wir die Zykluszeit um etwa 50 bis 70 Prozent reduziert haben.

Und die Dokumentation hat wahrscheinlich den unspektakulärsten, aber unmittelbarsten Effizienzgewinn gebracht. API-Dokumentation, Versionshinweise, Testdokumentation, Code-Erklärungen und erste Entwürfe technischer Spezifikationen müssen nicht mehr mit einem blinkenden Cursor beginnen. AI erstellt die ersten 70 oder 80 Prozent, und mein Team verbringt seine Zeit damit, zu korrigieren und zu verbessern, anstatt alles von Grund auf zu erstellen.

Aber es gibt auch einen Nachteil, über den Technologieführungskräfte meiner Meinung nach häufiger sprechen müssen: AI macht es unglaublich günstig, schnell schlechten Code zu produzieren.

Wir haben festgestellt, dass sich der begrenzende Faktor nachgelagert verschiebt. Wenn ich fünfmal so viel Code generieren kann, Menschen ihn aber weiterhin verstehen, überprüfen, testen, absichern, bereitstellen, überwachen und warten müssen, habe ich den Systemdurchsatz nicht zwangsläufig erhöht. Möglicherweise habe ich lediglich einen Stau beim Code-Review verursacht.

Das war wahrscheinlich die wertvollste Lektion für mich. Ich optimiere meine Entwicklungsorganisation nicht länger in erster Linie dafür, wie schnell wir Software schreiben können. AI macht diesen Teil zunehmend zur Massenware. Ich optimiere dafür, wie schnell wir nachweisen können, dass Software es verdient, in der Produktion ausgeführt zu werden. Das ist eine völlig andere Entwicklungsorganisation.

Wo AI eine Stimme erhält und wo sie mitentscheiden darf

Ich gehe inzwischen ziemlich bewusst damit um, zwei Dinge voneinander zu trennen: Wo KI eine Stimme bekommt und wo KI mitentscheiden darf. In unserer Organisation hat KI mittlerweile in fast jeder Phase unseres Technologie-Lebenszyklus eine Stimme. Sie entscheidet jedoch nicht über jede Entscheidung mit.

Einige Beispiele:

• Architektur: Wir nutzen ChatGPT und Claude als Sparringspartner für Architekturfragen. Wenn wir einen neuen Dienst entwerfen, kann ich dem Modell unsere Anforderungen, Einschränkungen, vorhandenen Schnittstellen, Sicherheitsgrenzen, das erwartete Transaktionsvolumen und Fehlerszenarien geben. Ich lasse es mehrere Architekturen vorschlagen, Kompromisse aufzeigen, unsere Annahmen hinterfragen und sogar gegen seine eigene Empfehlung argumentieren. Was ich nicht tun werde, ist zu fragen: „Welche Architektur sollten wir verwenden?“ und dann einfach das umzusetzen, was zurückkommt. Die endgültige Architekturentscheidung bleibt eine menschliche Entscheidung, weil Architektur einen Kontext umfasst, der weit über technische Optimierung hinausgeht. Ich muss unsere Geschäftsstrategie, regulatorischen Verpflichtungen, operative Reife, Risikotoleranz, Kosten, technische Schulden und das berücksichtigen, was mein Team um 2:00 Uhr morgens tatsächlich unterstützen kann.
• Code: Hier geben wir der KI deutlich mehr Spielraum. Wir verwenden GitHub Copilot zur Codegenerierung, zum Refactoring, für Dokumentation und zur Erstellung von Unit-Tests. Außerdem nutzen wir ChatGPT und Claude zur Fehlerbehebung, zur Untersuchung von Implementierungsansätzen und zur Generierung adversarialer Testfälle. KI kann eine erste Implementierung unglaublich schnell schreiben. Ein menschlicher Ingenieur ist weiterhin für den Pull Request verantwortlich und genehmigt, was letztendlich zusammengeführt wird.
• Tests: Hier hat sich die Zuständigkeit wahrscheinlich am stärksten zugunsten der KI verschoben. Ich arbeite gerne mit KI und frage: „Wie würdest du das kaputtmachen?“ Wir können Fälle finden, die ein Entwickler, der gerade zwei Tage mit der Erstellung der Funktion verbracht hat, unbewusst übersehen könnte. KI wird zu einem sehr kostengünstigen und äußerst beharrlichen Gegenspieler.
• Sicherheit: Hier kehre ich das Verhältnis bewusst um. KI hilft uns, Schwachstellen zu identifizieren, Codemuster zu untersuchen, Bedrohungen zu modellieren und Angriffsszenarien zu generieren, aber wie gesagt behalten Menschen die Entscheidungsbefugnis über die Sicherheitsfreigabe, Identitäts- und Zugriffsentscheidungen, den Umgang mit sensiblen Daten und Ausnahmen. Prompt-Injection und die Offenlegung sensibler Informationen bleiben anerkannte Risiken in Anwendungen mit großen Sprachmodellen, daher erfordert die Anbindung von KI an Unternehmenssysteme mehr und nicht weniger Kontrollen.
• Reaktion auf Vorfälle: Dieser Bereich liegt irgendwo dazwischen. KI kann Protokolle aufnehmen, Ereignisse korrelieren, Tausende Zeilen an Telemetriedaten zusammenfassen, wahrscheinliche Grundursachen vorschlagen und Maßnahmen zur Behebung empfehlen. Das kann die ersten 30 Minuten eines Vorfalls dramatisch verkürzen. Wenn jedoch jemand einen Produktionsdienst deaktivieren, eine kritische Bereitstellung zurücksetzen, eine Sicherheitsrichtlinie ändern oder eine Maßnahme ergreifen möchte, die Kunden betrifft, trifft ein Mensch diese Entscheidung.
• Priorisierung des Aufgabenbestands: Auch hier wende ich dieselbe Regel an. KI kann Supportprobleme, Entwicklungsaufwand, Abhängigkeiten, Produktnutzung und Geschäftsziele analysieren und sagen: „So würde ich diese 40 Dinge priorisieren, und hier ist der Grund dafür.“ Das ist unglaublich nützlich. Aber KI versteht unsere Strategie nicht besser als wir. Die Verantwortlichen für Produkt und Technologie treffen die endgültige Priorisierungsentscheidung.

Meine Regel ist also ziemlich einfach: KI erhält mehr Autonomie, wenn eine Handlung reversibel, beobachtbar, testbar und von geringer Tragweite ist. Die menschliche Entscheidungsbefugnis nimmt zu, je schwieriger eine Handlung rückgängig zu machen ist oder je größere Auswirkungen sie auf Kunden, Finanzen, Sicherheit, Regulierung oder den Ruf hat.

Ein praxisnaher Entwicklungsablauf

Hier ist ein Beispiel für einen Ablauf „von der Anforderung bis zur Produktion mit KI im Prozess“. Nehmen wir an, wir müssen einem Agentenablauf eine neue Fähigkeit hinzufügen, der Kunden- und Richtlinieninformationen abruft, eine Reihe von Geschäftsregeln anwendet und die passende nächste Aktion empfiehlt:

1. Es beginnt mit der Anforderung. Anstatt dass ein Entwickler ein vage formuliertes Ticket erhält und sofort mit dem Programmieren beginnt, verwenden wir ChatGPT oder Claude, um die Anforderung zu hinterfragen. Wir geben dem Modell die Anwendergeschichte, Akzeptanzkriterien, relevanten Geschäftsregeln, API-Verträge und technischen Einschränkungen. Anschließend bitten wir es, Unklarheiten, fehlende Sonderfälle, Abhängigkeiten, Sicherheitsbedenken und Fragen zu identifizieren, die wir beantworten sollten, bevor jemand Code schreibt. Das klingt einfach, verhindert aber frühzeitig überraschend viele kostspielige Missverständnisse.
2. Als Nächstes folgen Architektur und Aufgabenzerlegung. Wir verwenden Claude und ChatGPT, um Implementierungsoptionen zu untersuchen und die Anforderungen in Komponenten aufzuteilen. Das Modell könnte eine API-Änderung, eine Änderung des Datenmodells, eine Integrationsabhängigkeit, Autorisierungsanforderungen, Telemetrie und die erforderlichen Testfälle identifizieren. Außerdem bitten wir es, gegen die vorgeschlagene Architektur zu argumentieren. Ein menschlicher Entwickler trifft die Architekturentscheidung. Die KI liefert Optionen. Wir tragen die Verantwortung für die Konsequenzen.
3. Dann gehen wir zur Implementierung über. Wir verwenden GitHub Copilot innerhalb der Entwicklungsumgebung, um Standardcode zu generieren, klar definierte Funktionen zu implementieren, Code zu überarbeiten, API-Clients zu erstellen, unbekannte Bereiche der Codebasis zu erklären und Dokumentation zu generieren. Der Entwickler wechselt vom Tippen jeder einzelnen Zeile dazu, die Implementierung zu steuern, zu überprüfen und zu verfeinern. Dieser Unterschied ist wichtig. Ich möchte nicht, dass Entwickler zu sehr teuren Autovervollständigungsbedienern werden. Ich möchte, dass sie über das System nachdenken.
4. Dann geben wir ChatGPT oder Claude die Anforderung und die Implementierung und sagen im Grunde: „Großartig. Jetzt mach sie kaputt.“ Die KI hilft dabei, gegnerische Szenarien zu generieren, und Copilot hilft, daraus automatisierte Unit- und Integrationstests zu erstellen.
5. Danach übernimmt die deterministische Maschinerie. Der Pull Request gelangt in unsere CI/CD-Pipeline. Wir führen automatisierte Tests, statische Analysen sowie Abhängigkeits- und Schwachstellenscans durch und passieren unsere normalen Qualitätssicherungen. Ein menschlicher Entwickler überprüft den Pull Request.
6. Danach führen wir die Bereitstellung schrittweise durch. Die Änderung durchläuft Entwicklung und Staging, bevor sie in die Produktion gelangt. Wo es sinnvoll ist, verwenden wir Funktionsflags oder kontrollierte Bereitstellungsmuster, damit wir die Reichweite begrenzen, das Verhalten beobachten und schnell zurücksetzen können.
7. Und auch die Aufgabe der KI ist noch nicht beendet. Sobald die Funktion ausgeführt wird, wird die KI zu einer Assistenz für die Beobachtbarkeit. Wir verwenden sie, um Protokolle zusammenzufassen, Fehlermuster miteinander in Beziehung zu setzen, unerwartetes Verhalten zu analysieren und Entwicklern dabei zu helfen, viel schneller von „etwas stimmt nicht“ zu einer plausiblen Grundursache zu gelangen.

Wie KI das Verhalten von Entwicklern verändert

Ich wünschte, ich hätte früher verstanden, dass es einfach ist, Entwicklern KI-Werkzeuge zur Verfügung zu stellen. Das Verhalten von Entwicklern zu verändern, ist der schwierige Teil.

Als wir anfingen, Werkzeuge wie GitHub Copilot, ChatGPT und Claude zu verwenden, ging ich die Einführung so an, wie es viele Technologieführungskräfte tun. Talentierten Entwicklern leistungsfähige Werkzeuge geben, einige sinnvolle Leitplanken etablieren und darauf warten, dass die Produktivität steigt.

Das tat sie auch, aber nicht einheitlich und nicht immer auf die Weise, die ich erwartet hatte.

Das Erste, was ich gelernt habe, war, dass Zugang nicht gleich Nutzung ist und Nutzung nicht gleich Kompetenz.

Zwei Entwickler können genau dasselbe KI-Werkzeug verwenden und völlig unterschiedliche Ergebnisse erzielen. Der eine behandelt KI wie eine Autovervollständigung und spart ein paar Tastatureingaben. Der andere lernt, wie man Kontext bereitstellt, Probleme zerlegt, Ergebnisse hinterfragt, Tests generiert, Alternativen untersucht und das Modell als technischen Sparringspartner nutzt. Der Produktivitätsunterschied zwischen diesen beiden Personen kann enorm werden.

Ich hätte viel früher in KI-Kompetenz und Arbeitsweisen investiert. Nicht in dem Sinne: „Hier ist ein zweistündiger Kurs zu Prompt-Engineering“, sondern in praktische Beispiele, die auf unserer tatsächlichen Entwicklungsarbeit basieren.

Tyrone-Kommentare

\u003cstrong\u003eIch hätte viel früher in KI-Kompetenz und Arbeitsweisen investiert. Nicht in dem Sinne: „Hier ist ein zweistündiger Kurs zu Prompt-Engineering“, sondern in praktische Beispiele, die auf unserer tatsächlichen Entwicklungsarbeit basieren.\u003c/strong\u003e

Wie KI die technologische Führung verändert

Wir verbringen viel Zeit damit, uns zu fragen, was KI mit Entwicklern, Architekten, Analysten und anderen technischen Rollen machen wird. Ich denke, CTOs müssen diese Frage umkehren und auf sich selbst richten.

Während des größten Teils meiner Karriere wurde Technologieführung dadurch belohnt, Dinge zu wissen, die andere nicht wussten. Erfahrung vermittelte die Fähigkeit, Muster zu erkennen. Technisches Fachwissen verlieh Autorität. Man konnte einen Raum betreten und eine Antwort liefern, deren Suche jemand anderen vielleicht Tage gekostet hätte.

Jetzt kann ich jedem ein unglaublich leistungsfähiges KI-System in die Hände geben. Das verändert Führung.

Ich glaube nicht mehr, dass mein Wert als CTO darin liegt, die Antworten zu haben. Er liegt darin, bessere Fragen zu stellen, Kontext bereitzustellen, Zielkonflikte abzuwägen, Urteilsvermögen einzusetzen und ein Umfeld zu schaffen, in dem Menschen und Maschinen einander besser machen.

Das erfordert Demut. KI wird manchmal einen Ansatz erkennen, den ich nicht bedacht habe. Ein Junior-Ingenieur mit hervorragenden KI-Kenntnissen kann eine Annahme infrage stellen, die jemand mit 25 Jahren Erfahrung für offensichtlich hält. Ich denke, gute Technologieführungskräfte müssen das begrüßen.

Der CTO des KI-Zeitalters kann nicht einfach die technisch klügste Person im Raum sein. Wir müssen zu den Menschen werden, die den Raum gestalten. Wer bekommt eine Stimme? Was darf die KI entscheiden? Wo bleibt menschliches Urteilsvermögen unverzichtbar? Woher wissen wir, wann wir falschliegen?

Das ist die Transformation der Führung.

Warum CTOs bei Effizienzgewinnen vorsichtig sein sollten

Mein wichtigster Rat an CTOs lautet derzeit: Verwechselt schnelles Vorankommen nicht mit Fortschritt.

Auf Technologieführungskräfte wird enormer Druck ausgeübt, „etwas mit KI zu tun“. Die Vorstände fragen danach. Die CEOs fragen danach. Die Mitarbeitenden nutzen sie bereits, unabhängig davon, ob es eine Richtlinie gibt oder nicht. Jeder Anbieter hat plötzlich entdeckt, dass sein Produkt schon immer „KI-gestützt“ war.

Es ist sehr leicht, reaktiv zu werden. Aber ich denke, die Aufgabe des CTO besteht derzeit darin, inmitten dieses Lärms für Klarheit zu sorgen.

• Erstens: Nutzt die Technologie selbst. Und ich meine: Nutzt sie wirklich. Entwickelt eure KI-Strategie nicht vollständig auf Grundlage von Analystenberichten und Produktvorführungen. Ich nutze Tools wie ChatGPT, Claude und GitHub Copilot, weil ich praktische Erfahrungen damit brauche, wo sie außergewöhnlich leistungsfähig sind, wo sie versagen und wie schnell sich diese Grenzen verschieben. Man kann einen technologischen Wandel nicht wirksam führen, wenn man ihn nur über PowerPoint erlebt.
• Zweitens: Beginnt mit geschäftlichen Rahmenbedingungen, nicht mit KI-Fähigkeiten. Ich interessiere mich weit weniger für die Frage „Wo können wir generative KI einsetzen?“ als für die Frage „Wo sind wir langsam, teuer, uneinheitlich oder kapazitätsbeschränkt, oder wo sind Kunden frustriert?“ Danach kann ich bestimmen, ob KI tatsächlich Teil der Lösung sein sollte.
• Drittens: Schafft eine solide Grundlage. KI wird schlechte Daten, schwache APIs, unzureichende Beobachtbarkeit, nicht vorhandene Dokumentation oder dysfunktionale Entwicklungsmethoden nicht retten. Oft wird sie diese Probleme sogar verstärken. KI wirkt als Verstärker der zugrunde liegenden Organisation und des technischen Systems.
• Viertens: Gestaltet die Governance nach den Konsequenzen, nicht nach der Angst. Ich möchte keine 47-seitige KI-Richtlinie, die im Grunde sagt: „Bitte tut nichts Interessantes.“ Ich möchte Kontrollen, die dem Risiko angemessen sind. Lasst die Menschen dort energisch experimentieren, wo Handlungen umkehrbar sind und geringe Konsequenzen haben. Verstärkt die menschliche Aufsicht, sobald Entscheidungen Kundendaten, Geld, Sicherheit, regulatorische Verpflichtungen oder Produktivsysteme betreffen.
• Fünftens – und das ist vielleicht der wichtigste Punkt –: Gestaltet die Arbeit neu, statt die Arbeit einfach nur um KI zu ergänzen. Wenn mein Entwicklungsprozess zwölf Schritte umfasst und KI Schritt vier um 70 Prozent beschleunigt, habe ich die Entwicklung nicht transformiert. Ich habe Schritt vier beschleunigt.
• Und schließlich: Schützt menschliches Urteilsvermögen und beseitigt gleichzeitig konsequent die ermüdende Routinearbeit.

Ich denke, CTOs haben derzeit eine seltene Gelegenheit. Fragt nicht nur, wie KI eure derzeitige Organisation effizienter macht. Fragt, welche Organisation ihr aufbauen würdet, wenn ihr heute beginnen würdet. Das ist die unangenehmere Frage. Es ist auch die Frage, die Unternehmen voneinander unterscheiden wird, die KI lediglich nutzen, und Unternehmen, die sich durch KI tatsächlich transformieren.

Folgen Sie uns

Sie können Tyrone Grandisons Arbeit auf LinkedIn und auf seiner persönlichen Website verfolgen. Sie können sich auch seine Bücher Die KI-Revolution und Kultur, die Bestand hat ansehen.

Weitere Experteninterviews folgen im The CTO Club!