Wie plane ich eine App-Modernisierung?

Warum wir das alles machen

Eine alte App kann über Jahre erstaunlich zuverlässig wirken. Ihre Benutzer kennen die Umwege, die Fachabteilung kennt die Ausnahmen und der Betrieb kennt die Stellen, die besser nicht angefasst werden. Bei einer Modernisierung wird ein Teil dieses eingespielten Gleichgewichts aufgebrochen. Auch bei guter Vorbereitung werden neue Fehler auftauchen.

Das ist kein Argument gegen Modernisierung. Es ist ein Argument für einen klaren Gegenwert. Die App sollte nach dem Umbau nicht nur auf einer neueren Plattform laufen. Sie sollte eine lästige Grenze beseitigen, einen wichtigen Ablauf vereinfachen, auf weiteren Geräten funktionieren, verständlicher werden oder eine neue Fähigkeit erhalten, die vorher nicht wirtschaftlich umsetzbar war.

Wir bei APLICONUS vermeiden Modernisierungsprojekte, deren Nutzen nur in einer Liste aktualisierter Technologien besteht. Technik ist ein Mittel. Die erste Managementfrage lautet: Was können unsere Benutzer nachher besser als vorher?

Das eigentliche Ziel heißt permanente Modernisierung

Früher konnte man eine große Migration planen, mehrere Jahre daran arbeiten und anschließend hoffen, wieder eine Weile Ruhe zu haben. Diese Ruhe wird es nicht mehr geben. Betriebssysteme, Frameworks, Sicherheitsanforderungen und Endgeräte verändern sich weiter. Durch KI-Agenten ist nun zusätzlich die Geschwindigkeit der Softwareentwicklung selbst in Bewegung geraten.

Allein die Unterschiede zwischen GPT‑5.1, GPT‑5.5 und GPT‑5.6 haben unsere Arbeitsweise innerhalb kurzer Zeit verändert. Was bei der einen Modellgeneration noch in kleine, streng geführte Aufgaben zerlegt werden musste, kann die nächste Generation über längere Zeit planen, ausführen und prüfen. Gleichzeitig entstehen neue Kosten, neue Abhängigkeiten und neue Möglichkeiten für Fehler. OpenAI empfiehlt im Juli 2026 für komplexe, offene Aufgaben GPT‑5.6 Sol, für die tägliche Arbeit Terra und für klar beschriebene Wiederholungsaufgaben Luna.¹

Eine Modernisierungsstrategie ist deshalb kein Dokument, das fünf Jahre unverändert bleibt. Sie braucht einen stabilen Kern und einen beweglichen Rand. Stabil bleiben sollten fachliche Begriffe, Datenhoheit, Verantwortungsgrenzen, Qualitätsmaßstäbe und die Frage, welcher Benutzernutzen erreicht werden soll. Modelle, Werkzeuge und die beste Art ihrer Zusammenarbeit müssen dagegen regelmäßig neu bewertet werden.

Die Entscheidungen vor dem ersten Umbau

Die erste Entscheidung betrifft das Team. Heute gehören dazu Menschen und GPTs. Wie diese Mannschaft sinnvoll zusammengestellt wird, beschreiben wir ausführlich im Leitfaden Zielgerichtete Team-Zusammenstellung statt Scrum für Softwareentwicklung mit Agenten. Für die Modernisierung ist vor allem wichtig, dass fachliche Entscheidung, Architektur, Gestaltung, Fehlersuche, Betrieb und rechtliche Verantwortung tatsächlich abgedeckt sind. Ein Agentensystem kann diese Perspektiven unterstützen. Es kann sie nicht verantworten.

Die zweite Entscheidung betrifft Modell und Reasoning-Stufe. Dafür gibt es keine dauerhaft richtige Matrix. Unsere derzeitige APLICONUS-Zuordnung ist einfach: Sol mit hoher oder sehr hoher Reasoning-Stufe übernimmt unklare Ausgangslagen, Architekturentscheidungen, schwierige Fehler und besonders wertvolle Änderungen. Terra mit mittlerer Stufe ist das Arbeitspferd für die tägliche Umsetzung. Luna mit niedriger oder mittlerer Stufe eignet sich für Extraktion, Klassifikation und andere gut beschriebene Wiederholungsarbeit. Max ist für sehr schwierige Einzelprobleme gedacht; Ultra lohnt sich, wenn sich eine Aufgabe wirklich in unabhängige Teile zerlegen lässt. Das stärkste Modell mit der höchsten Stufe für jede Tätigkeit einzusetzen, wäre keine Qualitätsstrategie, sondern nur eine teure Gewohnheit.¹

Die dritte Entscheidung betrifft die Arbeitsumgebung. Azure Virtual Desktop hat sich für uns bewährt, weil sich dort eine kontrollierte Windows-Umgebung mit den benötigten Werkzeugen, Zugängen und Testmöglichkeiten dauerhaft bereitstellen lässt. Das ist gerade dann wichtig, wenn ein Agent über Stunden arbeitet und nicht bei jedem Lauf wieder auf einem halbfertigen Rechner beginnt. Microsoft beschreibt sowohl persönliche, persistente Desktops als auch zentral verwaltete, skalierbare Umgebungen.² Entscheidend ist allerdings nicht das Produkt. Entscheidend ist, dass die Umgebung reproduzierbar, beobachtbar und gegen ungewollte Zugriffe abgegrenzt ist.

Die vierte Entscheidung betrifft das geistige Eigentum. Vor dem ersten großen Agentenlauf muss geklärt sein, welche Quelltexte, Daten, Protokolle und Korrekturen welchen Dienst verlassen dürfen, wer Ergebnisse und Lernspuren besitzt und wie lange sie gespeichert werden. Dabei darf man nicht pauschal unterstellen, jeder Anbieter trainiere mit Unternehmensdaten. OpenAI erklärt beispielsweise, Ein- und Ausgaben seiner Business-, Enterprise- und API-Angebote standardmäßig nicht zum Training zu verwenden.³ Trotzdem bleibt die weitergehende Frage: Gehören auch unsere Bewertungen, Testfälle, Korrekturen und die daraus entstehende Lernkurve weiterhin uns?

Die initiale Analyse soll eine Arbeitskarte erzeugen

Eine Analyse ist nicht abgeschlossen, wenn eine Präsentation mit roten, gelben und grünen Kästchen vorliegt. Am Ende muss eine Arbeitskarte existieren, mit der Menschen und Agenten Entscheidungen treffen können.

Zuerst werden nicht mehr unterstützte Technologien und echte Betriebsrisiken identifiziert. Danach suchen wir nach veralteten Mustern, die sich mehrfach wiederholen. Für jedes wichtige Muster sollte eine Standardlösung beschrieben werden. Das ist wesentlich wirksamer, als dieselbe Grundsatzdiskussion bei hundert ähnlichen Fundstellen erneut zu führen.

Ebenso wichtig ist unbenutzter Code. Jede Funktion, jedes Modul und jede Variante, die nachweislich entfallen kann, muss nicht portiert, getestet und später gewartet werden. Gerade bei alten Anwendungen ist Weglassen häufig der größte einzelne Produktivitätsgewinn. Die Entscheidung darf allerdings nicht allein aus fehlenden Aufrufen im Quelltext abgeleitet werden. Selten genutzte Monats-, Jahres- oder Ausnahmeprozesse können fachlich wichtiger sein als häufig geklickte Komfortfunktionen.

Die Analyse sollte außerdem zeigen, welche Module voneinander abhängen, welche Benutzerwege geschäftskritisch sind und wo heute schon mehrere Derivate auseinanderlaufen. Damit entsteht keine perfekte Dokumentation des Bestands. Es entsteht eine verlässliche Karte für die nächsten Entscheidungen.

Struktur und Fachlichkeit für GPTs lesbar machen

Ein großer Quellcodebestand ist kein guter Projektauftrag. GPTs arbeiten wesentlich verlässlicher, wenn die wichtigsten Strukturen ausdrücklich beschrieben sind. Wir extrahieren deshalb Strukturinformationen in ein maschinenlesbares Schema, in der Regel als JSON-Schema mit projektspezifischen Erweiterungen. Darin werden Fachobjekte, Beziehungen, Regeln und besondere Eigenschaften sichtbar, ohne dass jeder Agent sie erneut aus tausenden Dateien erraten muss.

Stamm- und Konfigurationsdaten werden möglichst als Codelisten herausgelöst. Was bisher als fest eingebaute Auswahl, Sonderfall oder Länderregel im Programm steckt, kann dann unabhängig vom eigentlichen Anwendungscode gepflegt werden. Dadurch sinkt der Portierungsumfang. Gleichzeitig wird deutlicher, was fachliche Entscheidung und was technische Implementierung ist.

Auch die Aufteilung in Architekturschichten dient nicht der Schönheit eines Diagramms. Sie schafft Änderungsräume. Fachlogik, Anwendungsabläufe, technische Infrastruktur und Bedienoberfläche sollten so getrennt sein, dass ein Agent an einem Bereich arbeiten kann, ohne unbemerkt das ganze System umzuschreiben. Die Namen der Schichten sind weniger wichtig als ihre Grenzen.

Erst kompilierfähig, dann schön

Die erste Portierung sollte so früh wie möglich kompilierfähig sein. Sie darf intern noch unvollständig und optisch unfertig sein. Sie muss aber einen echten Rückkopplungskanal eröffnen: Build, Start, Navigation und erste Tests dürfen nicht bis zum Ende des Projekts theoretisch bleiben.

Diese Fassung wird nicht veröffentlicht. Sie ist das Gerüst, an dem sichtbar wird, welche Annahmen falsch waren, welche Abhängigkeiten fehlen und welche Teile des Bestands sich nicht so sauber trennen lassen wie gedacht. Ein früher, ehrlicher Build ist wertvoller als ein weit fortgeschrittener Portierungsbericht.

Speicher- und Datenbankformate zunächst stabil halten

Eine Grenze ziehen wir bewusst beim gespeicherten Zustand. Speicher- und Datenbankformate sollten in der ersten Modernisierung nicht geändert werden. Bestehende Daten sind das Gedächtnis der Anwendung. Wenn gleichzeitig Code, Technologie und persistierte Daten ihre Form wechseln, wird bei einem Fehler unnötig schwer erkennbar, auf welcher Seite er entstanden ist. Außerdem wird die Rückkehr zur vorherigen Version riskanter.

Anders als bei früheren Migrationsprojekten müssen wir daraus aber nicht mehr ableiten, immer nur eine technische Schicht verändern zu dürfen. Ein leistungsfähiges GPT kann neue Technologien einführen und den zugehörigen Quelltext im selben Arbeitsgang konsistent anpassen. Das ist sogar häufig sinnvoller, als erst eine künstliche Zwischenarchitektur zu bauen, die kurz darauf wieder verschwindet. Stabil bleiben Datenformate, fachliches Verhalten und überprüfbare Benutzerwege. Technologie und Quelltext dürfen sich gemeinsam bewegen.

Eigene Komponenten werden zu Leitplanken

Sobald das Gerüst steht, identifizieren wir wiederkehrende Funktionen, die auf gemeinsame Framework-Komponenten umgestellt werden sollten. Das bedeutet nicht, jede Standardbibliothek selbst zu bauen. Es bedeutet, die eigenen wiederkehrenden Fach- und Bedienmuster an einer Stelle zu definieren.

Die Microsoft .NET-Komponenten von APLICONUS bündeln dafür unter anderem Fachmodelle, Codelisten, Formularbeschreibungen und kontrollierte Bedienaktionen. Für GPTs entsteht dadurch eine befestigte Straße: Sie müssen nicht bei jeder Maske eine neue Lösung erfinden, sondern können vorhandene Bausteine und Regeln anwenden. Genau diese Leitplanken machen hohe Geschwindigkeit auf Dauer erst beherrschbar.

Danach wird featureweise modernisiert

Ab diesem Punkt sollte nicht mehr ein technischer Ordner nach dem anderen portiert werden. Ein einzelnes Feature wird zum Ziel. Der zugehörige Benutzerweg wird geöffnet, ein konkreter Fehler oder eine Grenze wird behoben und dabei das veraltete Muster durch die festgelegte Standardlösung ersetzt. Anschließend wird genau dieser Weg automatisiert geprüft.

Dieses Vorgehen haben wir in den vergangenen Tagen bei APLICONUS infield immer wieder bestätigt. Eine große Plattformmigration war nicht automatisch die beste nächste Entscheidung. Häufig erzeugten eine stabile gemeinsame Grundlage, die Beseitigung eines alten Musters und die Prüfung des wirklichen Bedienwegs schneller einen belastbaren Nutzen. Wichtig war dabei, nicht an einem theoretischen Codepfad stehenzubleiben. Erst wenn die richtige Seite geöffnet, das Bedienelement tatsächlich erreicht und der Ablauf im realen Zustand geprüft war, galt die Änderung als verstanden.

Der Unterschied ist für Entscheider wichtig: Featurefokus ist keine kleinteilige Reparaturtaktik. Er verbindet Nutzen, Risiko, Modernisierung und Nachweis in einem überschaubaren Arbeitsstück.

Pläne und Ziele in Codex richtig einsetzen

Codex unterscheidet inzwischen sinnvoll zwischen Plan und Ziel. Wenn das Ergebnis noch unklar ist, wird zuerst geplant: Der Bestand wird untersucht, Entscheidungen und Grenzen werden herausgearbeitet und messbare Erfolgskriterien festgelegt. Anschließend wird aus diesem Plan ein Ziel. Ein gutes Ziel beschreibt das gewünschte Ergebnis, die Grenzen und den Nachweis, dass die Arbeit fertig ist.⁴

Für einen Entscheider könnte ein Ziel etwa so lauten:

Modernisiere die Reisekostenerfassung so, dass der bestehende Benutzerweg erhalten bleibt, die neue Berechnungsfunktion einen sichtbaren Mehrwert bietet und der Ablauf in heller und dunkler Darstellung automatisiert geprüft ist. Verändere keine anderen Module.

Das ist wesentlich wirksamer als „Portiere die Reisekostenansicht“. Der Agent kennt nun Nutzen, Grenze und Fertigkriterium. Ein Ziel kann über längere Zeit verfolgt und vom Menschen nachgesteuert werden. Es erweitert aber keine Berechtigungen und nimmt dem Menschen keine Freigabeentscheidung ab.⁴

Tests sind eine neue Fähigkeit des Modernisierungssystems

Automatisierte Tests gehören nicht ans Ende der Modernisierung. Sie sind die Bedingung dafür, dass sie überhaupt dauerhaft weitergehen kann. Fachregeln benötigen wiederholbare Prüfungen. Builds müssen zeigen, ob alle Derivate noch entstehen. UI-Tests müssen den tatsächlichen Bedienweg nachvollziehen.

Gerade bei Oberflächen hat sich viel verändert. Codex kann eine App starten, Bedienelemente suchen, scrollen, Zustände vergleichen, Screenshots beurteilen und einen Ablauf so lange verfolgen, bis ein Ziel erreicht oder ein echter Blocker belegt ist. Das verbindet Tests mit Ausdauer. Es ersetzt keine menschliche Abnahme, kann aber viele Fehler finden, die ein isolierter Komponententest nie sieht.

Besonders faszinierend ist, wie ein GPT die Bedienung einer ihm vollkommen unbekannten, komplexen Fachanwendung erlernen kann. Es orientiert sich an sichtbaren Beschriftungen, Navigation, Zuständen und Rückmeldungen. Erscheint an der Oberfläche ein Fehler, kann es diesen reproduzieren, den betroffenen Ablauf eingrenzen, Protokolle und Bindungen untersuchen und schließlich auf die verursachende Codepassage schließen. Die Benutzeroberfläche wird damit nicht nur zum Testobjekt, sondern zu einer zusätzlichen Sprache, in der die Anwendung dem Agenten erklärt, was nicht stimmt.

Diese Fähigkeit ist noch kaum bekannt. Selbst viele erfahrene Entwickler verbinden Coding-Agenten vor allem mit Codegenerierung, Reviews und klassischen Tests. OpenAI hat die Computerbedienung im Hintergrund erst im April 2026 als neue Codex-Fähigkeit vorgestellt und beschreibt seit Mai ausdrücklich den Weg vom Reproduzieren eines Fehlers im Browser über Tests bis zur Korrektur.⁵ Die einzelnen Bausteine werden also bereits gezeigt. Wie mächtig ihre Verbindung bei einer unbekannten, gewachsenen Business-Anwendung ist, wird außerhalb praktischer Modernisierungsarbeit bisher selten sichtbar.

Wir haben dabei auch gelernt, dass ein Test nicht dadurch richtig wird, dass er grün ist. Wenn der Test ein Element über eine Abkürzung anspricht, die ein Benutzer nie nehmen kann, prüft er die falsche Wirklichkeit. Gute UI-Automatisierung folgt dem Produkt, nicht umgekehrt.

Was von der Migrationsfabrik übrig bleibt

Kollegen bei APLICONUS haben in früheren Anstellungen zweieinhalb Jahre lang eine Migrationsfabrik mit 80 Mitarbeiterinnen und Mitarbeitern geleitet. Das war kein APLICONUS-Projekt, ist aber unser persönlicher Vergleichsmaßstab ‒ und gemessen daran übersteigen die heutigen Möglichkeiten von Codex deren damaligen Output bei weitem.

Das klingt zunächst nach einer Bedrohung für Arbeitsplätze. Tatsächlich werden damit aber nicht 80 Menschen ersetzt. Es verschwindet eine Form der Arbeit, die für die Beschäftigten selten besonders angenehm war. Migrationsfabriken leben von Wiederholung, Arbeitsteilung und vielen Übergaben. Einzelne Mitarbeiter sehen häufig nur einen kleinen Ausschnitt, während das Ziel über Monate oder Jahre in Bewegung bleibt.

Auch für den Auftraggeber ist eine solche Fabrik ein erhebliches unternehmerisches Risiko. Er bindet viele Menschen und viel Kapital, lagert einen großen Teil des Wissens über seine Anwendung aus und weiß trotzdem lange nicht, ob am Ende eine funktionierende, akzeptierte und dann noch aktuelle Lösung entsteht. Manche Migration war bei ihrem Abschluss technisch bereits wieder veraltet.

Der neue Ansatz verändert deshalb nicht nur die Geschwindigkeit. Er verändert, welche Vorhaben überhaupt vertretbar werden. Eine 10, 20 oder 40 Jahre alte Anwendung kann mit begrenztem Risiko modernisiert und anschließend weiterentwickelt werden. Nicht als jahrelanger Big Bang, sondern entlang konkreter Features, mit stabilen Datenformaten und immer wieder überprüften Benutzerwegen. Menschen werden dabei weiterhin für Fachwissen, Entscheidungen, Gestaltung und Verantwortung gebraucht. Sie müssen ihre Zeit nur nicht mehr in einer Migrationsfabrik verbringen.

Codex kann Bestandsaufnahme, die Übersetzung wiederkehrender technischer Muster, Implementierung und Prüfung über lange Zeiträume zusammenhalten. Damit wird nicht nur eine bestehende Fabrik schneller. Ihr bisheriges Organisationsmodell verliert seine Grundlage.

Sechs Milliarden Token sind kein KPI

In die Arbeit an APLICONUS infield sind inzwischen rund sechs Milliarden Token geflossen. Diese Zahl ist eindrucksvoll, aber als Leistungskennzahl ungeeignet. Viele Token können für tiefe Analyse, zahlreiche Builds und hartnäckige Fehlersuche stehen. Sie können ebenso gut durch schlechte Ziele, zu breite Suchen oder wiederholte Irrwege entstehen.

Wir können heute nicht einmal belastbar erklären, wie genau diese sechs Milliarden Token zusammengekommen sind. Welcher Anteil hat eine schwierige Aufgabe gelöst, welcher hat eine Sackgasse untersucht und welcher ist nur durch lange Kontexte und wiederholte Versuche entstanden? Eine verbrauchsabhängige Rechnung, die sich nicht Zielen und überprüften Ergebnissen zuordnen lässt, ist für einen Auftraggeber kaum steuerbar.

Hier liegt das eigentliche neue unternehmerische Risiko. Der AI-Anbieter verdient zunächst am Verbrauch, der Kunde aber nur am Ergebnis. Diese Interessen sind nicht automatisch deckungsgleich. Alex Karp hat die Unzufriedenheit von Unternehmen drastisch zusammengefasst: „I am paying for tokens that create no value.“⁶ Man muss seine Polemik nicht teilen, um die Frage ernst zu nehmen.

Zu einer Modernisierungsstrategie gehören deshalb auch Kostenobergrenzen, eine Zuordnung des Verbrauchs zu Zielen und die Freiheit, Modelle oder Anbieter zu wechseln. Tokenkosten dürfen nicht erst auf der Gesamtrechnung sichtbar werden. Sie müssen während der Arbeit gegen den entstehenden Nutzen geprüft werden können.

Die eigentliche Erkenntnis ist eine andere: Große Modernisierungsvorhaben werden nicht durch einen genialen Prompt erledigt. Sie benötigen Geduld, viele überprüfbare Zwischenschritte und die Bereitschaft, nach einem scheinbaren Erfolg noch einmal in die reale Anwendung zu gehen. Modelle werden besser. Ausdauer bleibt trotzdem ein Wettbewerbsvorteil.

Gemessen werden sollten deshalb der Weg von einer Entscheidung bis zu einer verifizierten Funktion, die Zahl der Fehler nach einer Freigabe, der tatsächlich entfernte Altcode, der Anteil automatisiert prüfbarer Benutzerwege und der sichtbare Nutzen der neuen Version. Tokenkosten gehören in diese Rechnung, aber sie sind weder Erfolg noch Misserfolg.

Derivate werden nicht einfach zusammengeschoben

Mehrere gewachsene App-Derivate lassen sich nicht sinnvoll zusammenführen, indem man das größte zum neuen Standard erklärt und die anderen hinein kopiert. Zuerst muss unterschieden werden, was gemeinsamer fachlicher Kern, was Konfiguration und was wirklich produktspezifisch ist.

Danach wird ein repräsentatives Derivat vollständig durch einen Modernisierungsschritt geführt. Die dabei bewährten Muster, Komponenten und Tests werden auf die anderen Varianten übertragen. Unterschiede bleiben so lange ausdrücklich sichtbar, bis fachlich entschieden wurde, ob sie entfallen dürfen. Zusammengeführt werden Bedeutungen und Verantwortungen, nicht bloß Dateien.

Das Ziel ist ein gemeinsamer Kern mit nachvollziehbaren Varianten. Eine einzige Anwendung voller unsichtbarer Sonderfälle wäre nur eine neue Form des Altbestands.

Skills: von Anbietern, aus dem Projekt und von Menschen

Das Wort Skill wird inzwischen für sehr unterschiedliche Dinge verwendet. Für Codex ist ein Skill ein wiederverwendbarer Arbeitsablauf mit Anweisungen, Beispielen, Vorlagen und gegebenenfalls Werkzeugen. Er sorgt dafür, dass eine bewährte Vorgehensweise nicht in jedem Gespräch neu erklärt werden muss.⁷

Vordefinierte Skills von Technologieanbietern sind ein guter Ausgangspunkt. Sie kennen typische Migrationswege, Werkzeuge und aktuelle Produktregeln. Projektspezifische Skills sind für die Modernisierung aber mindestens genauso wichtig. Sie enthalten die echten Build-Wege, Architekturgrenzen, Fachbegriffe, Testabläufe und die Erfahrungen aus bereits gelösten Fehlern. Damit wird das im Projekt erarbeitete Wissen wiederverwendbar.

Und dann gibt es die menschlichen Skills. Geduld und Hartnäckigkeit sind wichtig, weil eine Modernisierung selten auf gerader Strecke verläuft. Sprachliche Ausdrucksfähigkeit ist wichtig, weil Ziele, Grenzen und Kritik präzise formuliert werden müssen. Wer einem Agenten nicht sagen kann, was falsch, wichtig oder noch nicht fertig ist, bekommt nur schneller mehr vom Falschen.

Unser Fazit im Juli 2026

Für Microsoft wird es schwer, den Wettbewerb bei der Softwaremodernisierung allein mit Plattformen, Assessment-Werkzeugen und klassischen Migrationsangeboten zu bestehen. AI-Anbieter verfolgen einen umfassenderen Ansatz. Sie können nicht nur Technik ersetzen, sondern Codebestände lesen, fachliche Muster erkennen, Entscheidungen nachvollziehen, Tests erzeugen und die Arbeit über lange Ziele hinweg fortsetzen.

Genau darin liegt auch das strategische Risiko. Wer die Modernisierung begleitet, erhält einen sehr tiefen Blick in das geistige Eigentum eines Unternehmens. Satya Nadella nennt dies das „Reverse Information Paradox“: Unternehmen bezahlen für Intelligenz und müssen zugleich eigenes Wissen offenlegen, damit diese Intelligenz nützlich wird. Seine knappe Konsequenz lautet: „In consuming intelligence, you are creating intelligence.“⁸ Alex Karp fordert entsprechend, dass Unternehmen die Kontrolle über Rechenleistung, Modelle, Daten und ihren eigenen Wettbewerbsvorsprung behalten.⁶

Diese Warnungen sind richtig, aber nicht für ein Argument gegen AI-gestützte Modernisierung. Sie sind ein Argument dafür, sich auf den eigenen Know-how-Aufbau zu konzentrieren. Modelle dürfen austauschbar sein. Fachmodelle, Codelisten, Tests, Korrekturen, Skills und die Definition dessen, was für das Unternehmen „gut“ bedeutet, müssen beim Unternehmen bleiben.

Permanente Modernisierung heißt deshalb nicht, permanent einem Anbieter hinterherzulaufen. Sie heißt, das eigene System so aufzubauen, dass neue Modelle genutzt werden können, ohne mit jedem Modellwechsel die Kontrolle über Produkt, Wissen und Richtung abzugeben.