Mistral AI hat mit OCR 4 eine neue Version seines Dokumentenerkennungsmodells vorgestellt. Die Software soll nicht mehr nur Text aus PDFs und anderen Dokumenten auslesen, sondern den Inhalt zugleich strukturieren. Neu sind unter anderem Positionsangaben für Textblöcke, eine Klassifizierung der erkannten Elemente und Vertrauenswerte für einzelne Wörter und Seiten. Damit zielt das Modell auf Dokumentenverarbeitung in Unternehmenssuchsystemen, RAG-Pipelines und ähnlichen Workflows.

OCR 4 liefert mehr als reinen Text

Bisherige Systeme für die Optical Character Recognition (OCR) geben vor allem den reinen Text einer Seite aus. OCR 4 geht weiter: Das Modell markiert jedes erkannte Element mit einer Bounding Box, also einem Begrenzungsrahmen auf der Seite. Zusätzlich ordnet es Inhalte bestimmten Blocktypen zu, etwa Überschriften, Tabellen, Gleichungen oder Signaturen. Confidence Scores zeigen an, wie sicher das Modell bei der Erkennung ist.

So sollen sich Dokumente besser weiterverarbeiten lassen. Eine Suchanwendung kann etwa nicht nur den Wortlaut indexieren, sondern auch erkennen, ob ein Textabschnitt eine Überschrift oder ein Tabellenwert ist. Ein Prüfsystem kann die unsicheren Stellen an einen Menschen geben. Und ein Redaktions- oder Compliance-Workflow kann Textpassagen im Originaldokument exakt hervorheben oder schwärzen.

Einsatz in Suche, RAG und Agenten

Mistral sieht OCR 4 als Baustein für Enterprise Search, Retrieval-Augmented Generation und domänenspezifische Suchpipelines vor. Die strukturierte Ausgabe soll dabei helfen, Dokumente in sinnvolle Such- und Antwortbausteine zu zerlegen. Mistral bezeichnet das als semantisches Chunking: Nicht die Seitenlänge entscheidet über die Aufteilung, sondern die Struktur des Dokuments. Eine Tabelle oder ein Absatz bleiben dann eher als Einheit erhalten.

Auch für agentische Workflows plant Mistral den Einsatz – also in KI-Systemen, die nicht nur Informationen lesen, sondern auf Basis davon Aufgaben anstoßen, etwa Formulare ausfüllen, Rechnungen verarbeiten oder Compliance-Prüfungen vorbereiten. Entsprechend hilfreich ist es hierbei, wenn ein OCR-System nicht bloß Text liefert, sondern zugleich die strukturelle Funktion eines Inhaltselements kennt.

Mehrsprachigkeit und Self-Hosting

OCR 4 unterstützt nach Angaben von Mistral 170 Sprachen in zehn Sprachgruppen. Zu den genannten Gruppen zählen Englisch, westeuropäische und osteuropäische Sprachen, chinesische und ostasiatische Sprachen, ferner eine Sonderkategorie für Sprachen wie Hindi, Japanisch, Georgisch, Bengalisch oder Tamil. Das Unternehmen verweist dabei besonders auf bessere Ergebnisse bei Sprachen seiner Sonderkategorie sowie bei weniger verbreiteten Sprachen, bei denen andere Systeme häufiger Schwächen zeigen.

Das Modell lässt sich laut Mistral auf Wunsch in einer eigenen Container-Instanz betreiben, damit OCR 4 auch bei hohen Anforderungen an Datensouveränität, Datenschutz oder Compliance verwendet werden kann. Unterstützt werden gängige Formate wie PDF, DOC, PPT und OpenDocument.

Einordnung der Benchmarks

Mistral verweist bei OCR 4 auf eigene und externe Benchmarks. In einer Blindbewertung durch unabhängige Prüfer soll das Modell im Mittel besser abgeschnitten haben als konkurrierende OCR- und Document-AI-Systeme. Auf dem öffentlichen Benchmark OlmOCRBench erreichte OCR 4 laut Mistrals Ankündigung einen Spitzenwert von 85,20 Punkten. Auf OmniDocBench nennt das Unternehmen 93,07 Punkte.

Mistral weist aber selbst darauf hin, dass Benchmark-Ergebnisse bei mathematischen Formeln, mehrspaltigen Dokumenten oder fehlerhaften Referenzdaten verzerrt sein können. Ein Modell kann also in der Praxis richtig liegen, aber im Test trotzdem als falsch gewertet werden. Für eine belastbare Bewertung empfiehlt das Unternehmen deshalb eigene Dokumente und Workflows.

API, Document AI und Preise

OCR 4 lässt sich per API anbinden. Die Grundfunktion liefert immer extrahierten Inhalt, Bounding Boxes, Blocktypen, Confidence Scores und Markdown-ähnlich strukturierten Text. Wer mehr Struktur braucht, kann zusätzliche Document-AI-Funktionen aktivieren. Dann lässt sich etwa eine JSON-Ausgabe nach einem vorgegebenen Schema erzeugen oder das Modell interpretiert Inhalte mit einem zusätzlichen Prompt.

Mistral trennt damit zwischen reiner Extraktion und strukturierter Weiterverarbeitung. Für Entwickler heißt das: Wer nur den OCR-Output benötigt, bleibt bei der Basiskonfiguration. Wer Rechnungen, Formulare oder andere Dokumente direkt in feste Felder überführen will, ergänzt die Document-AI-Parameter in derselben Anfrage. Nach Angaben von Mistral kostet die OCR-API 4 US-Dollar pro 1000 Seiten, im Batch-Betrieb 2 Dollar pro 1000 Seiten. Document AI liegt bei 5 Dollar pro 1000 Seiten.

Verfügbarkeit

Mistral OCR 4 und die darauf aufsetzenden Document-AI-Funktionen sind laut dem Unternehmen über Mistral Studio, Amazon SageMaker und Microsoft Foundry verfügbar. Zudem hat Mistral OCR 4 in das eigene Search Toolkit eingebunden, das sich derzeit in einer öffentlichen Vorschau befindet.

(fo)

Vielleicht kennen Sie das aus der Arbeit mit generativer KI: Etwas funktioniert, und Sie wissen nicht, warum. Ein generiertes Stück Code läuft durch, eine vorgeschlagene Lösung trägt, eine Diagnose stimmt. Das Ergebnis liegt überprüfbar und brauchbar vor Ihnen, nur den Weg dorthin könnten Sie nicht rekonstruieren, nicht einmal grob nacherzählen.

Mir selbst erschien das lange als Nebensächlichkeit, als bloßer Preis der Bequemlichkeit. Inzwischen halte ich es für die eigentlich interessante Frage. Denn was sich hier verschiebt, ist nicht nur die Geschwindigkeit, mit der Lösungen entstehen, sondern das Verhältnis zwischen einem Ergebnis und dem Verständnis, das wir früher mit ihm zusammen erworben haben. Es lohnt sich zu fragen, ob dieser Verlust ein Problem ist – und falls ja, wo genau.

Das funktionierende Ergebnis ohne den Weg dorthin

Wer ein Problem selbst löst, bekommt traditionell zwei Dinge auf einmal: die Lösung und das Verständnis, wie sie zustande kommt. Von beiden ist das Verständnis der haltbarere Teil. Die konkrete Lösung gilt für genau diesen einen Fall, das Verständnis trägt zum nächsten, leicht anderen Fall.

Mit generativer KI fallen diese beiden Dinge auseinander. Ich erhalte die Lösung, ohne das Verständnis gleich mitzubekommen. Ein kniffliger regulärer Ausdruck, eine Build-Konfiguration, die plötzlich durchläuft, ein Fehler, der durch einen akzeptierten Vorschlag verschwindet: Das Resultat steht, der Weg bleibt im Dunkeln.

Das ist nicht dasselbe wie der Gebrauch einer Bibliothek oder das Vertrauen in einen Compiler. Dort hat jemand verstanden, was geschieht, und die Abstraktion ist dokumentiert, stabil und nachlesbar. Bei einem generierten Ergebnis ist die Herleitung selbst im Prinzip undurchsichtig, und sie fällt bei jeder Anfrage ein wenig anders aus.

Der entscheidende Unterschied liegt in der Übertragbarkeit. Ein Ergebnis ist ein Einzelstück, Verständnis ist wiederverwendbar. Wo mir das Verständnis fehlt, fehlt mir die Fähigkeit, den nächsten Fall aus eigener Kraft zu lösen. Ich bleibe auf das Werkzeug angewiesen, nicht weil es bequemer ist, sondern weil ich es selbst nicht mehr könnte.

Das Tückische ist, dass sich das Übernehmen eines Ergebnisses anfühlt wie Lernen. Schließlich habe ich etwas geschafft, das ich vorher nicht konnte. Aber der Eindruck täuscht: Was zugenommen hat, ist die Zahl der erledigten Aufgaben, nicht die Tiefe dessen, was ich selbst beherrsche. Geliehene Kompetenz fühlt sich an wie eigene, solange das Werkzeug zur Hand ist.

Lange galt die Mühe, ein Problem zu durchdringen, als lästiger Umweg auf dem Weg zur Lösung. Tatsächlich war sie der Weg, auf dem das Verständnis überhaupt erst entstand. Wer sich durch einen Fehler gekämpft hat, kennt danach nicht nur die Lösung, sondern das Terrain darum herum: die Sackgassen, die falschen Fährten, die Stellen, an denen es noch einmal kippen könnte. Genau dieses Nebenwissen entfällt, wenn die fertige Lösung geliefert wird.

Diese Reibung war also kein Mangel, sondern ein Teil des Ertrags. Sie zu beseitigen, klingt nach Fortschritt, kostet aber etwas, das auf der Rechnung zunächst nicht auftaucht.

Ein Zug, den niemand erklären kann

Im März 2016 schlug AlphaGo den Go-Profispieler Lee Sedol in einem Match mit 4:1. Berühmt wurde nicht das Ergebnis, sondern ein einzelner Zug: der 37. Zug in der zweiten Partie, in die Go-Geschichte als „Move 37“ eingegangen. Kein Mensch hätte ihn gespielt; die Wahrscheinlichkeit, dass ein menschlicher Profi ihn wählt, lag bei etwa eins zu zehntausend. Er war fremd, und er war brillant.

Den Gegenpol lieferte Lee Sedol selbst. In der vierten Partie spielte er den 78. Zug, in Korea als „göttlicher Zug“ gefeiert, ebenso unwahrscheinlich und sein einziger Sieg gegen die Maschine. Der Unterschied liegt nicht in der Genialität, sondern dahinter: Hinter Move 78 steht eine Idee, die ein Mensch erklären kann, ein geschickter taktischer Zug, im Go Tesuji genannt. Hinter Move 37 steht eine Wahrscheinlichkeitsverteilung über Millionen selbst gespielter Partien.

Profispielerinnen und -spieler haben AlphaGo studiert und einzelne Züge übernommen; die frühe Invasion am 3-3-Punkt etwa wurde populär, nachdem die Maschine sie bevorzugte. AlphaGo Zero lernte 2017 ganz ohne menschliche Partien, allein aus dem Spiel gegen sich selbst, und übertraf die ursprüngliche Version deutlich.

AlphaGo beruht auf neuronalen Netzen, und alles, was es im Training gelernt hat, steckt in deren Gewichten, den vielen Zahlenwerten, die ein solches Netz ausmachen. Dort liegt das Wissen, das die Maschine überlegen macht, und nirgends sonst. Es liegt in keinem Lehrbuch, in keinem Kommentar, in keinem Kopf. Man kann der Maschine beim Spielen zusehen und die Ergebnisse bestaunen, aber die zugrunde liegende Strategie bleibt eingeschlossen in einer Form, die sich nicht in menschliche Begriffe übersetzen lässt.

Bezeichnend ist, dass nicht einmal die Fachleute hinter AlphaGo den Zug im üblichen Sinn erklären konnten. Sie konnten beschreiben, wie das System trainiert wurde, und sie konnten zeigen, dass es Move 37 einen hohen Wert beimaß. Warum gerade dieser Zug der richtige war, ließ sich daraus nicht ableiten. Die Erklärung endete bei der Mechanik des Lernens, nicht beim Sinn des Ergebnisses.

Doch einen Zug zu übernehmen heißt nicht, ihn zu verstehen. Man imitiert, was sich als stark erweist, ohne das Warum rekonstruieren zu können. Die Maschine spielt übermenschliches Go und hinterlässt keine lehrbare Theorie davon. Genau das ist die Struktur, der ich bei generativer KI wieder begegne: ein Ergebnis auf hohem Niveau, das sich kopieren, aber nicht als Einsicht erben lässt.

Lässt sich die Blackbox wirklich öffnen?

Die naheliegende Hoffnung lautet, man müsse die Modelle eben erklärbar machen. Explainable AI, erklärbare KI, ist ein ernstzunehmendes Forschungsfeld. Aber die gängigen Verfahren erklären im Nachhinein: Sie zeigen, welche Eingaben besonders ins Gewicht fielen oder welche Teile des Netzes ansprachen. Das ergibt plausible Geschichten und Näherungen, aber keine getreue Auskunft darüber, was die Gewichte tatsächlich berechnen.

Schlimmer noch: Eine plausible Erklärung kann in die Irre führen. Sie klingt überzeugend, deckt sich mit unseren Erwartungen und suggeriert ein Verständnis, das gar nicht trägt. Eine Erklärung, die nicht treu wiedergibt, was im Modell geschieht, ist im Zweifel gefährlicher als gar keine, weil sie ein falsches Sicherheitsgefühl erzeugt.

Für die tägliche Arbeit folgt daraus wenig Tröstliches. Eine Hervorhebung, welche Zeilen ein Assistent als relevant betrachtet hat, sagt nichts darüber, ob der erzeugte Code korrekt ist. Die Erklärung beschreibt bestenfalls, woran das Modell sich orientiert hat, nicht, ob das Ergebnis stimmt. Beides zu verwechseln, ist der bequemste und zugleich gefährlichste Fehler im Umgang mit diesen Werkzeugen.

Ein jüngerer Zweig, die mechanistische Interpretierbarkeit, versucht, die innere Rechnung eines Modells regelrecht zurückzuentwickeln. Das ist vielversprechend, steckt aber in den Anfängen. Bei Modellen mit Milliarden von Parametern ist man von einer vollständigen Erklärung weit entfernt.

Verständlich von Grund auf sind nur einfache Modelle. Ein Entscheidungsbaum ist eine lesbare Folge von Wenn-dann-Verzweigungen, die man Schritt für Schritt nachvollziehen kann. Sobald man jedoch die Genauigkeit steigern will und zu Ensembles übergeht, zu Random Forests oder Gradient Boosting, ist die Durchschaubarkeit wieder dahin. Die Informatikerin Cynthia Rudin hat daraus die Forderung abgeleitet, bei folgenreichen Entscheidungen lieber von vornherein interpretierbare Modelle einzusetzen, statt Blackboxes nachträglich zu erklären.

Dahinter steht ein unbequemer Zusammenhang: Die leistungsfähigsten Modelle sind zugleich die am wenigsten durchschaubaren. Erklärbarkeit und Leistungsfähigkeit ziehen in entgegengesetzte Richtungen. Diese Undurchschaubarkeit ist dabei von anderer Art als die prinzipiellen Grenzen, die ich in einem früheren Beitrag beschrieben habe: Dort geht es darum, was Sprachmodelle grundsätzlich nicht leisten können; hier darum, wie wenig wir verstehen, wie sie das leisten, was sie leisten.

Verständnis, das vielleicht nirgends mehr existiert

Nun könnte man einwenden, dass wir uns längst auf vieles verlassen, das wir nicht verstehen. Ich vertraue dem Compiler, der TLS-Bibliothek, den Bremsen meines Autos, ohne ihre Interna zu durchdringen. Das stimmt, und es ist auch gut so. Niemand kann alles selbst verstehen.

Doch es gibt einen Unterschied. Bei diesen Beispielen existiert das Verständnis irgendwo. Es sitzt in den Entwicklerinnen und Entwicklern des Compilers, in der Spezifikation des Protokolls, in der Konstruktionszeichnung der Bremse. Ich kann der Kette im Prinzip folgen, bis ich bei jemandem ankomme, der erklären kann, warum die Sache funktioniert.

Es ist der Unterschied zwischen dem Wissen, dass etwas funktioniert, und dem Wissen, warum es funktioniert. Das erste genügt, um ein Ergebnis zu benutzen. Das zweite ist nötig, um es zu verändern, auf neue Fälle zu übertragen oder im Streitfall dafür einzustehen. Über lange Zeit lagen beide oft eng beieinander, nun lassen sie sich entkoppeln.

Wissenschaft und Technik haben über Jahrhunderte funktioniert, weil Wissen eine übertragbare Form annahm: Sätze, Beweise, Konstruktionspläne, die andere prüfen, lehren und weiterentwickeln konnten. Das Wissen eines großen Modells liegt dagegen in Milliarden von Zahlen, die für sich genommen nichts erklären. Es ist Wissen, das wirkt, ohne sich mitteilen zu lassen. Damit fehlt ihm genau die Eigenschaft, die menschliches Wissen anschlussfähig macht.

Bei der Ausgabe eines großen Sprachmodells kann die Kette ins Leere laufen. Niemand hat Move 37 entworfen, niemand kann auf die Überlegung dahinter zeigen, weil es keine gibt. Das Verständnis liegt nicht woanders, es existiert womöglich gar nicht, in niemandem. Das ist neu, und es ist mehr als ein akademischer Unterschied.

Sichtbar wird das überall dort, wo jemand für ein Ergebnis geradestehen muss. Eine Ärztin, die einer Diagnose folgt, eine Entwicklerin, die eine generierte Komponente ausliefert, ein Team, das ein System betreibt: Sie alle übernehmen Verantwortung für etwas, dessen Zustandekommen sie nicht vollständig durchschauen. Solange alles gutgeht, fällt das nicht auf. Es fällt auf, sobald etwas schiefgeht und die Frage nach dem Warum sich nicht länger aufschieben lässt.

Für Software wird dieser Unterschied konkret. Software ist kein einmaliges Ergebnis, das man entgegennimmt und beiseitelegt. Sie muss gewartet, erweitert, im Fehlerfall durchdrungen und über Jahre verantwortet werden. Dass der eigentliche Engpass der Entwicklung nie das Schreiben von Code war, sondern das Verstehen des Problems, habe ich an anderer Stelle ausgeführt. Ein Ergebnis, das niemand versteht, ist vor diesem Hintergrund keine Ersparnis, sondern eine Hypothek auf jede künftige Änderung.

Verlässlichkeit ersetzt kein Verstehen

Ist der Verlust an Verständnis also ein Problem? Die ehrliche Antwort lautet: Es kommt darauf an, und die Trennlinie verdient es, genau gezogen zu werden. Es gibt Fälle, in denen Verlässlichkeit der völlig richtige Maßstab ist und Verständnis nichts hinzufügt.

Wenn ein Ergebnis ein Einzelfall ist, billig zu überprüfen und ohne große Folgen, dann brauche ich seine Herleitung nicht zu durchschauen. Einen regulären Ausdruck kann ich gegen meine Beispiele testen, ein kleines Wegwerfskript an seinem Resultat messen. Hier auf Verständnis zu bestehen, wäre eine Romantisierung; was zählt, ist, dass das Ergebnis nachweislich stimmt.

Sobald ich aber ein System verantworte und es weiterentwickeln muss, kehrt sich der Maßstab um. Dann ist ein Ergebnis, das ich nicht verstehe, keine Einsparung, sondern eine verschobene Rechnung. Jede spätere Änderung, jeder Fehler, jede Anpassung verlangt genau das Verständnis nach, das ich beim ersten Mal übersprungen habe. Verlässlichkeit allein trägt nicht mehr, wo ich nicht nur ein Resultat brauche, sondern eine Grundlage, auf der ich weiterbauen kann.

Hinzu kommt, dass Verlässlichkeit selbst ein wackliger Maßstab ist, solange das Verständnis fehlt. Prüfen kann ich nur, woran ich gedacht habe. Welche Fälle überhaupt zu testen sind, welche Randbedingungen heikel werden, wo ein Ergebnis kippen könnte: Das verrät kein Test, sondern allein das Verständnis der Sache. Wer nicht versteht, prüft im Zweifel das Falsche und hält das Ergebnis trotzdem für gesichert.

In der Praxis zeigt sich das spätestens, wenn ein generiertes Modul Monate später in Produktion bricht und niemand im Team sagen kann, welche Annahmen ihm zugrunde liegen. Dann beginnt die Arbeit, die beim ersten Mal vermeintlich entfallen ist: die Software zu lesen, zu durchdringen, zu verstehen. Nur geschieht das jetzt unter Zeitdruck und ohne den Kontext, der bei der Entstehung noch greifbar gewesen wäre.

Diese Rechnung lässt sich nicht streichen, nur verlagern. Entweder ich erarbeite das Verständnis am Anfang, wenn der Kontext frisch und der Druck gering ist, oder ich hole es später nach, teurer und unter schlechteren Bedingungen. Verschwinden tut es nie.

Deshalb hebt generative KI den Wert des Verstehens nicht auf. Sie verschiebt nur den Zeitpunkt, zu dem wir dafür bezahlen. Sie verlagert das Problem, sie löst es nicht. Die Fähigkeit, die dadurch wichtiger wird statt unwichtiger, ist das Urteilsvermögen: zu erkennen, in welchem der beiden Fälle ich gerade bin, und zu entscheiden, ob ein Ergebnis Vertrauen verdient, ohne verstanden zu sein.

AlphaGo hat uns ein Jahrzehnt früher gezeigt, wie sich das anfühlt: eine Brillanz, die wir bewundern und kopieren, aber nicht als Einsicht erben können. Ob wir am Ende nur noch bedienen, was wir gebaut haben, oder es weiterhin verstehen, entscheiden nicht die Werkzeuge. Es entscheidet sich daran, wo wir weiterhin auf Verständnis bestehen.

(mro)

Für die meisten Unternehmen zahlt sich der Einsatz von KI‑Coding‑Tools stärker aus als erwartet. Das hohe Tempo agentischer Softwareentwicklung wirft aber die Frage auf, inwieweit Teams noch kontrollieren können, was sie an Code ausliefern. Zu diesen Ergebnissen kommt der AI Accountability Report von GitLab.

Im Unternehmensumfeld ist KI-gestützte Softwareentwicklung längst Standard. Laut dem GitLab-Report haben 91 Prozent der DevSecOps‑Befragten mindestens zwei Coding-Tools im Einsatz, 54 Prozent drei oder mehr. Dabei berichten 60 Prozent von einer höheren Investmentrendite als ursprünglich erwartet, 78 Prozent von schnellerem Code-Output und 73 Prozent sagen, dass sich die Codequalität verbessert habe.

Die Umfrage-Teilnehmerinnen und -Teilnehmer wenden lediglich 16 Prozent ihrer Arbeitszeit dafür auf, neuen Code zu schreiben. Eine deutliche Mehrheit von 85 Prozent sagt, dass sich der Fokus stattdessen auf Review und Validierung von KI-Output verschoben hat. Dort trägt KI allerdings am wenigsten dazu bei, die Geschwindigkeit oder Effizienz zu steigern.

Das KI-Produktivitäts-Paradoxon spüren deshalb 79 Prozent der Befragten: Die individuelle Produktivität hat nach ihrem Empfinden zugenommen, die Geschwindigkeit des Software‑Lieferprozesses als Ganzes hingegen kaum.

Governance wichtiger als Geschwindigkeit

GitLab macht AI Accountability, sinngemäß die Verantwortung eines Unternehmens im Umgang mit KI, an der Fähigkeit fest, drei Fragen beantworten zu können: Woher kommt der KI-generierte Code, wofür war er gedacht und wer ist dafür verantwortlich, sobald er Produktionsstatus erreicht hat?

Laut GitLab haben die meisten Unternehmen keine Antworten darauf. „Die Ereignisse der letzten Monate, die von Lieferketten-Angriffen über Zuverlässigkeitsprobleme bis hin zu strengeren behördlichen Auflagen hinsichtlich Nachverfolgbarkeit und Herkunft von KI reichen, zeigen, dass Geschwindigkeit ohne Kontrolle kein Vorteil, sondern ein Risiko ist“, so Manav Khurana, Chief Product and Marketing Officer von GitLab.

Im Report äußern 73 Prozent der Teilnehmerinnen und Teilnehmer Bedenken hinsichtlich der langfristigen Wartbarkeit von KI-generiertem Code; 80 Prozent meinen, dass ihr Unternehmen die KI-Werkzeuge schneller eingeführt hat, als Richtlinien zu deren Steuerung entwickelt wurden. Zudem birgt KI-generierter Code für 82 Prozent das Risiko, dass neue technische Schulden entstehen, auf die ihr Unternehmen noch nicht vorbereitet ist.

Besserung ist jedoch in Sicht: So wollen 91 Prozent der Teilnehmenden in den nächsten 12 Monaten Tools für KI-Code-Governance anschaffen. Ein Budget dafür haben 98 Prozent entweder bereits vorliegen oder zumindest eingeplant.

Mensch oder Maschine: Wer hat’s geschrieben?

Bereits jetzt sind 87 Prozent der Befragten zuversichtlich, dass sie innerhalb von 24 Stunden feststellen könnten, ob KI-Code ein Produktionsproblem mitverschuldet hat. Allerdings waren 34 Prozent der Unternehmen genau dazu nicht in der Lage, als es zu einem solchen Vorfall kam. Als größte Hürden für Kontrolle und Nachverfolgbarkeit nennen 43 Prozent die Schwierigkeit, KI-generierten Code von manuell geschriebenem Code zu unterscheiden. Auf Platz zwei und drei folgen fragmentierte Toolchains (40 %) und Systeme, die die Code-Herkunft nicht erfassen (39 %).

Für den AI Accountability Report befragte GitLab im Februar 2026 insgesamt 1528 Personen, die sich zu etwa gleichen Anteilen aus sechs Ländern rekrutieren: USA, Deutschland, Großbritannien, Frankreich, Japan und Australien. Davon ordnen sich 43 Prozent dem Bereich IT Operations zu, 37 Prozent zu IT-Security und 20 Prozent zum Bereich Softwareentwicklung. Die vollständige Umfrage steht auf der GitLab-Webseite gegen Registrierung kostenlos zum Download bereit.

(mro)