Yuri Gubin, CTO bei DataArt – Interview-Reihe

Yuri Gubin, CTO bei DataArt ist ein erfahrener Technologie‑Executive und Software‑Architekt, der mehr als 18 Jahre bei DataArt verbracht hat und dabei Rollen von Software‑Architektur über Lösungsarchitektur, Cloud‑Technologie, Innovation bis hin zu Führungspositionen durchlief, bevor er im März 2026 zum Chief Technology Officer aufstieg. Seine Arbeit konzentrierte sich auf die Lösung komplexer technischer Herausforderungen in Branchen wie Finanzdienstleistungen, Gesundheitswesen, Reisen und IoT, mit besonderer Expertise in Cloud‑Computing, KI, Datenplattformen und Unternehmens‑Software‑Architektur. Vor seiner Ernennung zum CTO war Gubin über fünf Jahre als Chief Innovation Officer bei DataArt tätig und ist seit 2021 Mitglied des Board of Partners des Unternehmens. Er ist außerdem professionelles Mitglied des Forbes Technology Council, nimmt an den Fachgruppen KI und Cloud‑Computing teil und wirkt als Technologie‑Berater für Girls Who Code, wo er zu Architektur, Datenschutz, Plattform‑Governance und Technologie‑Politik berät. DataArt führt ihn derzeit als Chief Technology Officer mit Sitz in New York auf.

DataArt ist ein globales Unternehmen für Software‑Engineering sowie Daten‑ und KI‑Transformation, das 1997 in New York gegründet wurde. Das Unternehmen ist auf mehr als 6.000 Technologie‑Fachkräfte in über 20 Ländern angewachsen und arbeitet mit über 400 Kunden zusammen, wobei es Dienstleistungen in Bereichen wie künstliche Intelligenz und Machine Learning, Daten und Analytik, Cloud‑Transformation, kundenspezifisches Software‑Engineering, Cybersicherheit und Modernisierung von Altsystemen anbietet. DataArt ist in Sektoren wie Finanzdienstleistungen, Gesundheits‑ und Life‑Sciences, Reisen, Medien und Unterhaltung sowie Einzelhandel tätig und unterhält Technologie‑Partnerschaften mit Plattformen wie AWS, Google Cloud, Microsoft Azure, Snowflake und Databricks. Im Jahr 2025 kündigte das Unternehmen eine dreijährige Investition von $100 Millionen in seine Daten‑ und KI‑Fähigkeiten an, gefolgt von der Einführung von Artisyn im Jahr 2026, einem KI‑gestützten Betriebsmodell, das KI‑Agenten, wiederverwendbare Beschleuniger, Governance, Sicherheit und Compliance in die Unternehmens‑Software‑Entwicklung integrieren soll.

Sie haben fast zwei Jahrzehnte bei DataArt verbracht, vom Software‑Architekten und Lösungsarchitekten über den Chief Innovation Officer bis hin zum CTO. Wie hat diese Reise Ihre Fähigkeit geprägt, wirklich transformative Technologien von Hype‑Zyklen zu unterscheiden, und wie beeinflusst sie Ihr „skeptischer Optimismus“ gegenüber KI heute?

Wir haben im Laufe der Jahre viele verschiedene Wellen erlebt, darunter den Aufstieg von Cloud und Mobile, unterschiedliche Generationen von KI, Automatisierung, DevOps und SRE, und ich habe in dieser Zeit für unsere Kunden programmiert, architektonisch gestaltet und beraten. Was mir klar wurde, ist, dass man mit Technologie fast alles tun kann und sie sehr mächtig ist, aber der Teufel steckt im Detail, und man muss wissen, was man tut, damit sie sinnvoll funktioniert.

Ich habe gesehen, wie Cloud‑Umgebungen immer teurer werden, KI‑Modelle, die nicht die erwartete Leistung erbringen, und schlecht umgesetzte Versuche, Release‑Zyklen zu automatisieren. Ich habe die Auswirkungen sowohl guter als auch schlechter Entscheidungen erlebt, sodass ich, wenn etwas Neues auftaucht und man all die Ankündigungen, Versprechen und den Hype liest, stets zu derselben Grundannahme zurückkehre: Fast alles ist mit Technologie möglich, aber man musst wissen, was man tut.

Man bekommt ein gutes Verständnis einer Technologie durch R&D und, vor allem, durch reale Projekte, denn so lernt man, was möglich ist, was nicht und wo Dinge schiefgehen können. Man zieht diese Lehren aus jedem Projekt, spricht mit Kollegen, anderen Architekten und Analysten und versucht zu erkennen, ob Muster existieren und ob man ein System darum herum aufbauen kann. Schließlich wird das zur Leitlinie, und dann prüft man, ob die als gut eingeschätzten Entscheidungen tatsächlich gute Ergebnisse liefern.

Hierher kommt der skeptische Optimismus. Unabhängig davon, was Technologie verspricht, muss man immer noch wissen, was man tut, und dieses Wissen stammt aus Erfahrung, Zusammenarbeit und einem kontinuierlichen Bestreben, zu lernen, sich zu verbessern und ein System hinter dem Hype zu schaffen.

Enterprise AI scheint von einer Phase der Ermutigung zu Experimenten in die Phase überzugehen, in der entschieden wird, welche Experimente tatsächlich skaliert werden sollten. Welche Signale zeigen Ihnen, dass ein KI‑Anwendungsfall bereit für eine breitere Einführung ist, und welche Warnzeichen deuten darauf hin, dass ein Unternehmen zu früh skaliert?

Ich verwende zwei Methoden, um zu beurteilen, ob wir etwas skalieren können oder etwas anderes tun sollten: die Adoptionskurve und die Lernkurve.

Um zu verstehen, ob ein KI‑Anwendungsfall funktioniert, muss man ihm etwas Zeit geben und den Mehrwert sowie den Nutzer‑Journey erfassen, denn dann kann man die Auf‑ und Abschwünge sehen und nicht nur den unmittelbaren „Wow“-Effekt in einem bestimmten Team oder Workflow. Man muss beobachten, was denselben Personen ein paar Wochen später passiert. Nutzen sie ihn weiterhin? Sind sie weiterhin zufrieden mit diesem Anwendungsfall, dieser Automatisierung oder dieser KI‑Fähigkeit, die sie entwickelt haben, oder war es nur ein kurzer Höhepunkt, der wirklich nicht skaliert werden sollte?

Einige dieser Dinge können nur im Laufe der Zeit validiert werden. Es wird immer die ersten Pioniere geben, meist die technisch versiertesten Personen und die sehr Neugierigen, und danach muss man es mit anderen Segmenten versuchen, mit denen, die den frühen Anwendern folgen, und dann der frühen Mehrheit. Sobald es sich dort bewährt hat, ja, kann man damit beginnen, es zu skalieren und diesen Anwendungsfall auf andere Abteilungen auszuweiten.

Jede größere Modellveröffentlichung kann innerhalb einer Organisation Druck erzeugen, den Mitarbeitenden sofort Zugang zu den neuesten Fähigkeiten zu geben. Wie sollten Technologieführende beurteilen, ob ein neues Modell eine bedeutende Verbesserung darstellt und nicht lediglich eine weitere Welle von Experimenten und Kosten erzeugt?

Hier ist erneut mein skeptischer Optimismus. Nehmen Sie an, Sie haben bereits ein Modell im Einsatz und mehrere tausend Menschen nutzen täglich KI, wobei verschiedene Modelle und Werkzeuge bereits verfügbar sind. Wenn ein neues Modell erscheint, können Sie aufgrund des Hypes und der natürlichen Neugier erwarten, dass jeder damit experimentieren möchte, was gut ist, aber diese Experimente sind möglicherweise nicht gezielt oder auf bestimmte Ergebnisse ausgerichtet, und manchmal können Sie den Unterschied nicht einmal messen.

Im großen Maßstab ist das wichtig. Es sind nicht nur ein oder zwei Personen, die herumprobieren, um zu sehen, wie das neue Modell im Vergleich zum alten abschneidet. Es können tausende Menschen sein, die Zeit mit Experimenten verbringen, obwohl das Ergebnis für einen konkreten Anwendungsfall möglicherweise nicht besonders bedeutend ist. Gleichzeitig kann es sein, dass, wenn etwas wirklich gut funktioniert, das Wissen darüber, was in Ihrer Organisation funktioniert, nicht klar erklärt oder für alle sichtbar ist.

Deshalb sollte die erste Gruppe, die ein neues Modell bewertet, nicht die gesamte Organisation sein. Es sollte ein R&D‑Team sein, das eng mit den relevanten Teams sowie mit Recht und Sicherheit zusammenarbeitet. Wir bewerten das Modell umfassend, führen eine schnelle Einschätzung durch und stellen es dann einem breiteren Publikum mit Kommentaren und Leitlinien zu Sicherheit, Compliance und Technologie vor. Da ständig neue Modelle und größere Updates erscheinen, müssen Sie dieses Modell und diese Denkweise etabliert haben. Es ist wirklich keine einmalige oder einmalige Übung.

DataArt hat ein funktionsübergreifendes „AI SWAT“ geschaffen, das Technologie, Recht, Compliance, InfoSec und weitere Teams einbezieht. Wie arbeitet diese Gruppe in der Praxis, und welche Arten von Risiken oder Fragen müssen geklärt werden, bevor ein neues KI‑Tool für eine breitere Nutzung freigegeben wird?

Seit ihrer Gründung, denke ich, setzen wir für diese Gruppe etwa alle vier bis fünf Monate unterschiedliche Ziele. Wir ändern die Priorität, das Ziel und manchmal die Mission, und viele dieser Ziele drehen sich um KI. Das kann die Qualifizierung der Mitarbeitenden, Markteinführungen und neue Fähigkeiten, Partnerschaften oder die breitere Ermöglichung von KI innerhalb der Organisation und über den ADLC hinweg sein.

Die konkreten Themen entwickeln sich im Laufe der Zeit, und ich halte das für gesund, weil man ständig die eigene Strategie überprüfen, Annahmen validieren und verstehen muss, ob ein Kurswechsel nötig ist und welches das nächste Thema für das Team sein sollte.

Die Gruppe umfasst Vertreter verschiedener Abteilungen, und ein Zweck besteht einfach darin, alle informiert zu halten. Wann immer es eine neue Ankündigung, Frage oder Gelegenheit gibt, kann jemand das Thema in eines unserer regelmäßigen Treffen einbringen. Selbst wenn es wie eine rein technologische Frage für ein enges Team wirkt, können solche Themen heute Auswirkungen auf viele Bereiche der Organisation haben.

Deshalb diskutieren wir bei der Bewertung einer neuen Partnerschaft, eines Tools oder Accelerators offen, damit jeder versteht, wohin die Dinge gehen, und die Möglichkeit hat, Fragen zu stellen oder Aufsicht zu geben. Bei einem neuen KI‑Tool kann die Technologie es nicht isoliert bewerten. Sicherheit, Recht und Compliance müssen ebenfalls verstehen, wie es Unternehmens‑ oder Kundendaten verarbeitet, welche Einschränkungen gelten und ob es sicher im großen Maßstab eingesetzt werden kann.

Manchmal arbeitet das AI SWAT‑Team auch an konkreten Programmen, wie zum Beispiel Qualifizierungsmaßnahmen, bei denen wir Ziele festlegen, Roadmaps erstellen und entscheiden, wie verschiedene Gruppen eingebunden werden. So funktioniert es wirklich: Menschen informieren, gemeinsam an spezifischen Programmen arbeiten und dem Vorstand Transparenz darüber geben, was im Unternehmen mit KI geschieht.

Sie beobachten sehr unterschiedliche Einstellungen zur KI‑unterstützten Softwareentwicklung, wobei einige Organisationen die agentische Entwicklung aktiv skalieren, während andere KI‑generierten Code noch verbieten. Was erklärt diese Spaltung und was muss sich ändern, bevor risikobewusste Unternehmen KI eine größere Rolle im Software‑Engineering zulassen?

Wahrscheinlich wird der Unterschied zwischen denjenigen, die Nein sagen, und denen, die Ja sagen, von ihrer Risikobereitschaft und ihrer Haltung gegenüber Mehrdeutigkeit und Unsicherheit getrieben. Was beiden Organisationstypen hilft, ist kontinuierliche Schulung, Experimentieren und Bewertung. Auch bei vielen Unternehmen, mit denen wir zusammenarbeiten und die KI überall einsetzen, gibt es nach wie vor Herausforderungen bei der Messung von Ergebnis und Wirkung. Ehrlich gesagt taucht die Frage, wie man die Auswirkung von KI misst und die Leistung eines Teams bewertet, manchmal fast aus dem Nichts auf, als hätte darüber bisher niemand wirklich nachgedacht.

Sobald Sie eine KI-Initiative umfassender bewerten, beginnen Sie, die Auswirkungen und den tatsächlichen Mehrwert zu verstehen, was zu besseren Entscheidungen darüber führt, wo die Technologie sinnvoll ist. Für Unternehmen, die KI ablehnen, muss dennoch ein kontinuierlicher Prozess zur Überprüfung dessen bestehen, was die Technologie leisten kann und wo sie derzeit steht. Sie möchten nicht, dass eine vor drei Jahren getroffene Entscheidung weiterhin Unternehmenspolitik bleibt, nur weil niemand die zugrunde liegenden Annahmen erneut geprüft hat.

Agentische KI macht es für einzelne Teams immer einfacher, eigene Agenten zu erstellen, was möglicherweise dazu führt, dass mehrere Agenten nahezu identische Aufgaben ausführen. An welchem Punkt wird Experimentieren zu einer Agentenflut, und welche Art von Governance‑Ebene ist erforderlich, um Eigentum, Berechtigungen, Duplikate und das Lebenszyklus‑Management zu steuern?

Wenn wir ein typisches Szenario sehen, in dem jeder Entwickler eine KI-Lizenz erhält und das Experimentieren unkontrolliert wird, beginnen alle, ihre eigenen Dinge zu erstellen und auf ihre eigene Weise zu arbeiten. In der Regel führt das zu leistungsschwachen Teams, verfehlten Erwartungen, nachlassender Qualität und steigenden Kosten. Das Fazit ist, dass es nicht das leistet, was alle erwarten, die Qualität schlecht ist und es teuer wird. Um dem entgegenzuwirken, muss es eine Team‑Anstrengung sein, die Teil einer breiteren Abteilungs‑ oder Organisationsinitiative ist, und genau hier kommt die Governance ins Spiel.

Auf Projektebene können Sie sich auf die Wissensbasis und den Kontext sowie die Anwendungsfälle einigen, in denen Sie KI einsetzen. Anschließend erstellen Sie Fähigkeiten und Agenten, die Teil des Entwicklungs‑Workflows sind und von allen wiederverwendet werden können, sodass Sie Wissen und Best Practices ansammeln, anstatt sie jedes Mal neu zu erstellen. Diese projektbezogene Anstrengung sollte dann von einer Enterprise‑Architecture‑Board, einer Technologiegruppe, dem CTO oder einem Team, das für die KI‑Einführung verantwortlich ist, koordiniert werden. Sie möchten Agenten wiederverwenden, die gut funktionieren, den Prozess solide gestalten und dafür sorgen, dass er in der gesamten Organisation funktioniert, anstatt in Chaos und Lärm zu enden.

Ich denke also, es muss eine abgestimmte Anstrengung auf Projektebene sein, möglicherweise auch auf Programmebene, und dann ebenfalls auf Abteilungs‑ und Organisationsebene.

Der Token‑Verbrauch und die Inferenzkosten können während eines Piloten relativ gering erscheinen, werden jedoch bedeutend, wenn KI‑Systeme bei Tausenden von Mitarbeitenden oder autonomen Agenten eingesetzt werden. Wie sollten Unternehmen das KI‑Kostenmanagement betrachten, und erwarten Sie, dass etwas Ähnliches wie FinOps speziell für KI‑Workloads entsteht?

Ich beginne damit zu sagen, dass ein nahezu ideales Szenario eintritt, wenn KI‑Kosten zunächst steigen, ein Plateau erreichen und dann im Laufe der Zeit leicht sinken. Das zeigt, dass Sie die Kosten prognostizieren, kontrollieren, verstehen können, wofür Sie tatsächlich für KI ausgeben, und die Ergebnisse Ihrer Entscheidungen sehen. Schlechte Situationen entstehen, wenn die Kosten ständig schwanken, weil das in der Regel bedeutet, dass etwas nicht nachhaltig ist, oder wenn die Kosten steigen und dann völlig fallen, weil die Einführung möglicherweise nicht erfolgt, etwas nicht funktioniert oder die Menschen etwas anderes nutzen und Sie es einfach nicht sehen.

FinOps ist also ein Konzept, und AI‑FinOps ist ebenfalls ein Konzept. Einige Techniken sind sehr technisch, während andere recht einfach sind. Es kann so grundlegend sein, das bevorzugte Modell zu wählen, damit Sie nicht immer auf das teuerste zurückgreifen, und Schritt für Schritt führen diese Entscheidungen zu Einsparungen. Gleichzeitig ist das Wissen, wie man Kosten spart und kontrolliert, nur die Hälfte der Gleichung. FinOps ist, wie ich es sehe, eine Disziplin und Methodik, die auch Produkt‑ und Geschäftsleiter einbezieht, weil Sie definieren müssen, was Sie messen, wenn Sie KI‑Initiativen bewerten.

Ja, ich denke, AI‑FinOps ist ein gutes Thema für das Äquivalent eines AI‑SWAT‑Teams, das diskutiert werden sollte: wie viel Sie ausgeben, wie viel Sie zurückbekommen, wie Sie es kontrollieren und wo die Chancen liegen.

Viele Unternehmen werden aufgefordert, den ROI von KI nachzuweisen, obwohl sie nie eine verlässliche Basislinie dafür etabliert haben, wie produktiv ihre Teams vor der Einführung von KI waren. Was sollten Organisationen tatsächlich messen, wenn sie bestimmen wollen, ob KI einen bedeutenden geschäftlichen Mehrwert schafft?

Unabhängig von Ihrer Haltung gegenüber KI oder Ihrem aktuellen Stand, vielleicht nutzen Sie bereits Agenten im Überfluss oder denken darüber nach, im nächsten Jahr mit KI zu beginnen – die Etablierung einer Basislinie ist heutzutage absolut unverzichtbar.

Es gibt verschiedene Klassen von Kennzahlen. Einige sind subjektiv und können einfach das Feedback Ihrer Entwickler oder Mitarbeitenden sein, weil Sie mit Menschen arbeiten und es wichtig ist zu verstehen, wie sie den Wert von KI wahrnehmen. Objektivere Messungen können mit mechanischen oder synthetischen Kennzahlen beginnen, wobei ich jedoch empfehle, sich nicht zu stark daran zu binden. Ich meine Dinge wie Code‑Commits oder Story‑Points. Diese Kennzahlen zeigen, dass Arbeit geleistet wurde, vermitteln jedoch nicht wirklich den Wert oder die Wirkung.

Was den größten Unterschied ausmacht, sind Kennzahlen, die erklären, wie schnell oder wie gut die Arbeit geliefert wurde. Denken Sie an DORA‑Kennzahlen wie Lead Time oder MTTR, daran, wie schnell Sie sich von einem Ausfall erholen, wie schnell Sie einen Bug in der Produktion beheben können, oder wie sich diese Messwerte im Laufe der Zeit verändern. Eine einzelne Zahl sagt nichts über den Verlauf aus. Einer unserer Architekten erwähnte kürzlich, dass im Bereich Softwareentwicklung eine gute Kennzahl auch sein könnte, wie zuverlässig Schätzungen sind, wenn die KI‑Einführung wächst, weil das etwas über die Nachhaltigkeit dieser Bemühungen und die tatsächliche Produktivität der Teams aussagt. Sie müssen zudem die Kosten im Blick behalten, denn wenn Sie nur über Vorteile sprechen, ohne zu verstehen, was es kostet, sie zu erreichen, haben Sie kein vollständiges Bild.

Außerhalb der Softwareentwicklung betrachte ich das auf ähnliche Weise. In jedem Workflow oder Prozess gibt es eine Arbeitseinheit und eine Definition von „Fertig“. Egal, ob Sie Ansprüche bearbeiten, Unterlagen prüfen oder Kundenanfragen bearbeiten, definieren Sie, was Sie liefern, und messen Sie dann, wie lange es vor KI gedauert hat, wie schnell und wie gut Sie es jetzt tun können und welche Kosten entstehen. Das liefert Ihnen einen guten Ausgangspunkt sowohl für die Basislinie als auch für das Rahmenwerk der Kennzahlen.

DataArt hat KI im gesamten Software‑Lieferzyklus durch Initiativen wie Artisyn integriert. Da KI immer mehr Implementierungs-, Test‑ und Workflow‑Aufgaben übernimmt, welche Teile des Software‑Engineerings werden für Menschen wertvoller und welche Fähigkeiten laufen Gefahr, weniger wichtig zu werden?

Sie können KI in der Entwicklung nur effektiv einsetzen, wenn Sie sich noch an die Definition von gut erinnern. Sie benötigen diese Expertise, um Ihre Agenten zu steuern, das Ergebnis zu prüfen, Beschränkungen zu setzen und die Regeln zu definieren. Sie müssen verstehen, was Best Practices sind und wie eine gute Architektur aussehen sollte, denn ohne das könnten Sie nicht wissen, was entwickelt wird, und der Wert dieser Art von Expertise steigt sehr, sehr stark.

Das Verständnis von Architekturmustern ist wichtig, ebenso wie das Verständnis dessen, was in einer bestimmten Branche, Anwendung oder Lösungsart angemessen ist. Sie müssen wissen, welche Art von Architektur derzeit gut ist und welche auch dann noch gut sein wird, wenn die Lösung skaliert, denn manchmal funktioniert dieselbe Architektur nicht über die gesamte Lebensdauer einer Lösung oder Plattform hinweg.

Dieses Gleichgewicht dessen, was für eine bestimmte Lösung angemessen ist, ist der menschliche Aspekt. Es ist das Gespür, die Handwerkskunst hinter Services und der Softwareentwicklung. Sie müssen wissen, was Sie tun, und das entsteht ebenfalls aus dem Verständnis des Kunden und der Branche.

Welche Fähigkeiten sind weniger wichtig? Das ist für mich wirklich schwer zu beurteilen, vielleicht wie schnell Sie Code tippen können. Ich scherze nur, aber Code kann jetzt viel, viel schneller erstellt werden, und spezifisches Wissen über eine bestimmte Bibliothek oder Sprache lässt sich mit KI ebenfalls deutlich schneller erlernen.

Ich habe gesehen, dass .NET‑Entwickler sehr schnell zu Java‑Entwicklern umgeschult wurden, und vor fünf oder zehn Jahren hätte ich gesagt, dass das in großem Umfang fast unmöglich sei. Heutzutage ist das möglich. Ein erfahrener Senior‑Entwickler kann zunehmend zwischen Sprachen wechseln, weil wirklich entscheidend ihr Verständnis von Technologie, Architektur, Best Practices für Lösungen, SDLC und ADLC ist.

Wenn Unternehmen von Dutzenden KI‑Pilotprojekten zu Produktionssystemen übergehen, die eigenständig Aktionen ausführen können, wo sollte die Verantwortung letztlich liegen, wenn ein KI‑Agent einen kostspieligen Fehler macht: beim Entwickler, beim Geschäftsinhaber, beim Modellanbieter, beim Governance‑Team oder in einer Kombination davon?

Mir gefällt die Idee einer schuldlosen Zusammenarbeit und geteilten Verantwortung, weil jeder in der Organisation zu Best Practices, architektonischen Rahmenwerken und Lösungen beiträgt. Selbst wenn ein Entwickler Code mit oder ohne KI erstellt, prüft ein anderer Entwickler ihn, Team‑Leads geben Orientierung, Architekten liefern die Architektur und Einschränkungen, und das Governance‑Team wirkt bei Entscheidungen zu Budgets, Zeitplänen und Releases mit. Jeder ist auf irgendeine Weise beteiligt.

Sehr oft, wenn etwas schiefgeht, ist es der Prozess, der nicht funktioniert, sodass die Verantwortung in diesem Sinne über verschiedene Rollen hinweg geteilt ist. Aber wenn man einfach sagt, die Verantwortung sei geteilt und damit schuldlos, reicht das nicht. Sie muss weiterhin in konkrete Zuständigkeiten aufgeteilt werden.

Entwickler sind für den Code verantwortlich, den sie als Pull‑Request einreichen, und sie müssen verstehen, was dort geschieht. Architekten sind für die von ihnen getroffenen Entscheidungen und für die architektonischen Vorgaben, die Agenten und Entwicklern bereitgestellt werden, verantwortlich. Das Plattform‑Team ist für die Zuverlässigkeit der Lösung verantwortlich, unabhängig davon, wer oder was eine bestimmte Code‑Zeile erstellt hat.

Die Verantwortung ist also vorhanden, aber Sie müssen sie granular nach Team, Rolle und Abteilung definieren. Was Sie nicht tun können, ist die Analyse bei „KI hat das getan“ zu beenden. Sie müssen fragen, welche Kontrollen, Tests oder Aufsichten diesen Fehler bis zur Produktion gelangen ließen.

Wenn ein Mangel an Unit‑Tests dazu führte, dass fehlerhafter Code in die Produktion gelangte, oder ein Mangel an Aufsicht und Review dies ermöglichte, können Sie diese Verantwortung nicht an die KI abgeben. Sie können auch nicht einfach den Modellanbieter oder Cloud‑Anbieter für jeden Bug oder Ausfall verantwortlich machen.

Vielen Dank für das großartige Interview, Leser, die mehr erfahren möchten, sollten DataArt besuchen.