Kategorie: Erklärer

Stell dir vor, in einem großen Bürogebäude bekommen alle Mitarbeiter denselben Haustürschlüssel. Egal ob Praktikant, Abteilungsleiter oder externer Reinigungsdienst – jeder hat Zugang zu allen Räumen. Verliert eine Person den Schlüssel, ist das gesamte Gebäude gefährdet. Genau dieses Szenario spielt sich derzeit in der Welt der KI-Agenten ab. Die Zahlen sind deutlich.

Eine aktuelle Studie von VentureBeat, basierend auf einer Umfrage unter 107 Unternehmen mit mehr als 100 Mitarbeitern, zeigt: 69% der Unternehmen betreiben ihre KI-Agenten mit gemeinsamen Zugangsdaten. Konkret bedeutet das: Ein einziger API-Key wird für mehrere Agenten verwendet. Wird einer dieser Agenten kompromittiert, profitiert der Angreifer sofort von den kumulierten Berechtigungen aller Workflows, die dieser Key berührt. Die forensische Spur endet auf der Ebene der Zugangsdaten, weil fünf Agenten auf einem Konto keine Aufzeichnung darüber hinterlassen, welcher Agent welche Aktion ausgeführt hat.

Ein Problem, das Milliarden kostet

Diese eine Zahl – 69% – erklärt, warum die größten Sicherheitsfirmen derzeit viel Geld investieren. Palo Alto Networks, CrowdStrike und Cisco haben im vergangenen Jahr zusammen mehr als 22 Milliarden Dollar investiert, um genau diese Sicherheitslücke zu schließen. Palo Alto Networks schloss am 11. Februar die Übernahme von CyberArk ab – für 21,1 Milliarden Dollar, der größte Deal in der Firmengeschichte. CrowdStrike kaufte die Runtime-Autorisierungsplattform SGNL für 740 Millionen Dollar und brachte bereits im Juni das erste Produkt daraus auf den Markt: Continuous Identity for AI Agents. Cisco gab Anfang Mai die Übernahme von Astrix Security bekannt, einem Spezialisten für nicht-menschliche Identitäten, für rund 400 Millionen Dollar.

Für Sicherheitsverantwortliche ist diese Studie keine Trendlinie, sondern eine Frage, die im Vorstand diskutiert werden muss. Denn sie deckt ein Problem auf, das in den Marketing-Broschüren der großen Cloud-Anbieter nicht vorkommt. 54% der befragten Unternehmen hatten bereits einen Sicherheitsvorfall oder einen Beinahe-Vorfall mit KI-Agenten. 18% bestätigten einen tatsächlichen Vorfall, 36% entdeckten eine knappe Verfehlung, bevor es zum Bruch kam. Die Sicherheitsteams stoppen die meisten dieser Ereignisse am letzten Kontrollpunkt – aber die restlichen Daten zeigen, wie dünn diese Grenze ist.

Wie Agenten heute ihre Identität verwalten

Nur 32% der Unternehmen geben jedem KI-Agenten eine eigene, abgegrenzte und verwaltete Identität. 48% berichten, dass einige Agenten abgegrenzte Identitäten haben, viele aber immer noch gemeinsame Zugangsdaten verwenden. Weitere 32% geben an, dass Agenten größtenteils mit gemeinsamen API-Keys oder mit entliehenen menschlichen bzw. Servicekonto-Zugangsdaten laufen. Die Umfrage erlaubte Mehrfachnennungen, und 24 der 107 Befragten wählten mehrere Optionen – daher summieren sich die Kategorien auf 112%. Bereinigt nach Befragten zeigen 74 Organisationen, also 69%, Credential Sharing in mindestens einer Antwort.

Diese eine Zahl erklärt, warum die Übernahmen genau auf diese Ebene zielen. Ein gemeinsamer Zugangsschlüssel verwandelt einen einzelnen kompromittierten Agenten in viele. CyberArks Forschung setzt die Anzahl der Maschinenidentitäten auf 82 pro menschlicher Identität in Unternehmen weltweit, wobei KI-Agenten die am schnellsten wachsende Kategorie sind. Cisco hat die gleiche Diagnose gestellt, als es Astrix kaufte, deren Gründer das Unternehmen um API-Keys, Servicekonten und OAuth-Tokens herum aufbauten. Ciscos Ankündigung nennt diese Zugangsdaten diejenigen, die KI-Agenten heute „nutzen (und missbrauchen)“, um Arbeiten in großem Maßstab auszuführen.

Adam Meyers, Senior Vice President für Counter Adversary Operations bei CrowdStrike, beschrieb den Mechanismus in einem Interview mit VentureBeat direkt: Einige KI-Systeme hätten ihre eigenen Identitäten, in anderen Fällen würden Menschen ihre Identität an die KI verleihen, damit sie in ihrem Namen handeln könne – das mache das Wasser noch trüber und die Lage sehr komplex. Das Trübe sei der Punkt: Wenn die Identität geteilt wird, stirbt mit ihr die Zuordnung.

Exposition wächst mit der Größe – Eindämmung nicht

49% der Unternehmen setzen zur Laufzeit abgegrenzte Berechtigungen durch, und 47% überwachen und protokollieren Agentenaktivitäten – beides Maßnahmen, die Sicherheitsvorfälle reduzieren können. Nur 30% isolieren jedoch ihre risikoreichsten Agenten in einer Sandbox. Das ist die eine Kontrolle, die den Schaden begrenzt, wenn die ersten beiden versagen. Isolation ist das, was einen einzelnen kompromittierten Agenten davon abhält, ein unternehmensweites Ereignis zu werden. Unternehmen haben in Erkennung und Abwehr investiert, aber die Eindämmungsebene existiert kaum.

Der schärfste Befund der Umfrage – und den kein Anbieterbericht zeigt – tritt zutage, wenn man die Ergebnisse nach Unternehmensgröße aufschlüsselt. Die Vorfallrate beträgt 49% für Unternehmen mit 101 bis 1.000 Mitarbeitern, steigt aber auf 63% für Unternehmen mit mehr als 1.000 Mitarbeitern. Die Sandbox-Isolation bewegt sich in die entgegengesetzte Richtung: von 35% auf 20% bei den größeren Unternehmen. Die Lücke zwischen Exposition und Eindämmung wächst von 7 Prozentpunkten bei kleinen Unternehmen auf 60 Prozentpunkte bei den größten. Größere Unternehmen betreiben mehr Agenten über mehr Systeme, was die Vorfälle nach oben treibt, während die Sandbox – das Engineering-Projekt, das sie eindämmen würde – nicht finanziert wird. Die Unternehmen mit den meisten Agenten haben die wenigste Isolation um sie herum.

In der Obhut dessen, der das Modell ausgeliefert hat

Die Modellanbieter selbst sind die Sicherheitsschicht: OpenAIs eingebaute Schutzmaßnahmen führen mit 51%, Google Cloud erreicht 36%, Microsoft Azures Purview und Copilot Studio DLP 35%, und Anthropics verwaltete Agentenkontrollen 29%. 82% der Befragten nennen eine anbietereigene oder Hyperscaler-Kontrolle als ihre einzige primäre Agentensicherheitsschicht. Die zweckgebauten Spezialisten liegen im niedrigen einstelligen Bereich: Palo Alto Networks‘ Prisma AIRS bei 7%, CrowdStrike bei 6%, Okta für KI-Agenten bei 4%. Microsoft Entra Agent ID ist die am weitesten verbreitete identitätsspezifische Kontrolle im Datensatz mit 13%, die einzige von einem Hyperscaler, und liegt dennoch außerhalb der Top-Vier. Nur 5% der Unternehmen betreiben überhaupt keine dedizierte Agenten-Toolbox.

Die gebündelten Kontrollen führen, weil sie kostenlos mitgeliefert und standardmäßig aktiviert sind. Die meisten filtern Prompts und Outputs, aber sie geben einem Agenten keine eigene Identität und isolieren ihn nicht. Hyperscaler verkaufen zwar Produkte auf der Identitätsebene – Entra Agent ID ist mit 13% im Datensatz –, aber die Adoption bleibt niedrig. Die beiden Kontrollen, die die Vorfallszahlen am meisten beeinflussen – abgegrenzte Identität und Isolation – sind die beiden, die der Standard-Stack nicht enthält. Prompt- und Output-Filter bewerten, ob ein Aufruf bösartig aussieht. Das ist ein Absichtsproblem, und Absicht kann nicht auf der Sprachebene gelöst werden.

Crowdstrikes CTO Elia Zaitsev zog die Grenze in einem Interview auf der RSAC 2026: „Das Beobachten tatsächlicher kinetischer Aktionen ist ein strukturiertes, lösbares Problem. Absicht ist es nicht.“ Der Falcon-Sensor von CrowdStrike durchläuft den Prozessbaum auf einem Endpunkt und verfolgt, was Agenten getan haben, nicht, was Agenten zu tun beabsichtigten. Eine abgegrenzte Identität und eine Isolationsgrenze geben diesem Sensor etwas, das er verfolgen kann, während ein gemeinsamer Zugangsschlüssel auf einer gebündelten Schutzmaßnahme dies nicht tut.

Die Cloud-Sicherheit durchlief vor zehn Jahren denselben Zyklus, und Palo Alto Networks, CrowdStrike und Wiz bauen milliardenschwere Geschäfte auf den Lücken auf, die native Cloud-Kontrollen offen ließen. Die Agentensicherheit folgt demselben Pfad schneller. Ein falsch konfigurierter Speicher-Bucket lag offen, bis ein Mensch ihn bemerkte. Ein falsch konfigurierter Agent nutzt seine eigene Überberechtigung bei jedem Durchlauf aus, und kein Mensch sieht zu, wenn er das tut. Merritt Baer, Chief Security Officer bei Enkrypt AI und ehemaliger stellvertretender CISO bei AWS, sagte VentureBeat, dass die Standardebene dünner sei, als Unternehmen annähmen: „Unternehmen glauben, sie hätten KI-Anbieter ‚genehmigt‘, aber in Wirklichkeit haben sie eine Schnittstelle genehmigt, nicht das zugrundeliegende System. Die wahren Abhängigkeiten liegen ein oder zwei Ebenen tiefer, und genau diese versagen unter Belastung.“

Zufrieden, aber nicht überzeugt – und schon auf dem Weg zum Einkauf

Hier ist der Widerspruch, der eine Keynote-Folie wert ist: Unternehmen bewerten ihre Agentensicherheits-Toolbox mit 4,2 von 5 Punkten, das Preis-Leistungs-Verhältnis mit 4,1, die Implementierungsfreundlichkeit mit 3,9. Diese Werte würden die meisten SaaS-Anbieter neidisch machen. Nur 35% glauben, dass ihre KI-gestützten Abwehrmaßnahmen den KI-gestützten Angreifern voraus sind. 32% sehen es als ungefähr ausgeglichen. 21% sagen, die Angreifer seien voraus, und weitere 21% halten es für zu früh, um das zu sagen. Das zeigt: Unternehmen vertrauen ihrer Toolbox mehr als den Ergebnissen, die sie liefert.

Die Budgets bestätigen das: 46% der Unternehmen weisen 6 bis 10% ihres Sicherheitsbudgets für Agentensicherheit aus, ein volles Drittel gibt 5% oder weniger aus. Die Hälfte der Stichprobe hatte bereits einen Vorfall oder Beinahe-Vorfall, aber die Finanzierung entspricht nicht der Exposition. 59% planen, innerhalb von 12 Monaten Agentensicherheits-Toolbox zu übernehmen, zu ergänzen oder auszutauschen – und 29% wollen noch in diesem Quartal handeln. OpenAI führt bei der zukünftigen Nachfrage mit 34%, gefolgt von Google (30%), Anthropic (29%) und Azure (25%). Die spezialisierten Anbieter ziehen mehr Interesse auf sich, als ihr aktueller einstelliger Fußabdruck vermuten lässt. Zufriedene Kunden stellen nicht so schnell um, es sei denn, sie wissen, dass der Stapel, den sie gerade verwenden, nur provisorisch ist.

Drei Schritte für Sicherheitsverantwortliche

Erstens: Noch in diesem Quartal eine Bestandsaufnahme aller Zugangsdaten jedes Agenten durchführen. Kartieren, welche Agenten Zugangsdaten mit anderen Agenten teilen und welche auf entliehenen menschlichen oder Servicekonto-Identitäten laufen. Das Ziel ist nicht ein Zugangsschlüssel pro Agent – Agenten, die mehrere Systeme berühren, brauchen mehrere abgegrenzte Identitäten. Das Ziel ist null gemeinsame Zugangsdaten zwischen Agenten und null entliehene menschliche Identitäten. 13% der befragten Unternehmen nutzen bereits Microsoft Entra Agent ID. Okta für KI-Agenten und die Spezialisten für nicht-menschliche Identitäten bieten Äquivalente. Geteilte und entliehene Zugangsdaten sind das Erste, was eliminiert werden muss.

Zweitens: Die risikoreichsten Agenten zuerst isolieren. Isolation ist die am wenigsten angewandte Kontrolle (30%) und die einzige, die den Schaden begrenzt, wenn die Prävention versagt. Die Agenten nach der Sensibilität dessen, was sie berühren, einordnen und die Spitze der Liste isolieren. Bei Unternehmen mit mehr als 1.000 Mitarbeitern, wo die Isolation auf 20% fällt, ist dies die einzelne Maßnahme mit der höchsten Rendite im Datensatz. Sandboxing erfordert nicht den Austausch des Agenten oder der Plattform. Es erfordert eine politische Entscheidung und eine Isolationsschicht.

Drittens: Das Budget an die Vorfallrate anpassen. Ein Drittel der Unternehmen finanziert die Agentensicherheit mit 5% oder weniger des Sicherheitsbudgets, obwohl mehr als die Hälfte bereits Vorfälle hatte. Die Daten zeigen: Je mehr Agenten ein Unternehmen einsetzt, desto höher die Vorfallrate und desto geringer die Isolation. Die Lösung ist nicht nur Technik, sondern auch Priorisierung im Budget. Die drei Milliardenübernahmen der letzten zwölf Monate zeigen die Richtung an: Wer jetzt investiert, kann die Lücke schließen, bevor sie zum geschäftskritischen Problem wird.

Die Parallele zur Cloud-Sicherheit vor zehn Jahren ist deutlich. Damals wie heute begannen Unternehmen mit den mitgelieferten Standardkontrollen, stellten aber schnell fest, dass diese nicht ausreichen, sobald die Nutzung skaliert. Die Firmen, die früh in dedizierte Identitäts- und Isolationslösungen investierten, hatten am Ende weniger Vorfälle und geringere Schäden. Für KI-Agenten gilt das Gleiche – nur dass die Geschwindigkeit, mit der sich die Bedrohung entwickelt, deutlich höher ist. Jetzt zu handeln vermeidet Altlasten. Wer wartet, riskiert die Zugangsdaten seiner gesamten Agentenflotte.

Quelle: venturebeat.com

Stell dir vor, du hast eine Bibliothek mit tausenden Büchern. Die meisten sind harmlos. Aber einige enthalten Bauanleitungen für eine gefährliche Maschine. Bisher hast du nur einen Wachmann vor die Tür gesetzt, der fragt: „Willst du wirklich etwas Böses damit tun?“ Wenn der Besucher schlau genug ist, kann er trotzdem an die Bücher herankommen. Genau vor diesem Problem stehen KI-Entwickler heute. In ihren Modellen steckt enormes Wissen – manches davon ist zweischneidig. Es kann Gutes bewirken, aber auch Schaden anrichten.

Die Rede ist von Dual-Use-Knowledge. Ein KI-Modell, das auf riesigen Textmengen trainiert wurde, hat gelernt, wie man Computerviren erstellt, biologische Kampfstoffe entwickelt oder Atomwaffen baut. Das gleiche Wissen hilft aber auch, Sicherheitslücken zu schließen, Impfstoffe zu entwickeln oder Energiequellen zu verbessern. Die Herausforderung: Wie behält man die Kontrolle über dieses Wissen, ohne die guten Anwendungen zu behindern? Forscher von Anthropic und AE Studio haben eine neue Methode namens GRAM (Gradient-Routed Auxiliary Modules) vorgestellt. Sie könnte ein entscheidender Schritt sein, um KI-Modelle sicherer zu machen – ohne die Leistungsfähigkeit zu opfern.

Aktuelle Sicherheitsmaßnahmen sind wie Schleusen: Sie prüfen die eingehenden Fragen und die ausgehenden Antworten. Wird nach etwas Gefährlichem gefragt, verweigert das Modell die Antwort. Aber das ändert nichts am gespeicherten Wissen. Ein entschlossener Angreifer kann versuchen, die Sperre zu umgehen – mit Tricks wie Prompt-Injection oder Jailbreaking. Das ist, als ob der Wachmann zwar fragt, aber der Besucher die Bücher trotzdem aus dem Fenster wirft. Das Wissen bleibt im Gebäude. Die einzige echte Lösung wäre, das Wissen gar nicht erst ins Gebäude zu lassen – oder es hinterher sauber entfernen zu können.

Bisher gab es dafür nur eine Möglichkeit: Filtern bestimmter Inhalte aus den Trainingsdaten. Wenn du etwa zwei Versionen eines Modells brauchst – eine mit und eine ohne Virologie –, musst du zwei separate Modelle trainieren. Das ist teuer, besonders bei Frontier-Modellen, die Hunderte Millionen Dollar kosten. Mit GRAM ändert sich das. Die Idee: Ein Modell bekommt zusätzliche, abnehmbare „Module“ pro Wissensbereich. Diese Module lernen nur, wenn sie mit genau diesen Inhalten gefüttert werden. Das restliche Netzwerk bleibt davon unberührt. Nach dem Training kannst du ein Modul einfach löschen – und das entsprechende Wissen verschwindet. Oder du lässt es drin, wenn der Nutzer vertrauenswürdig ist.

Stell dir eine Werkzeugkiste vor. Normalerweise lernt der KI-Assistent aus allen Büchern gleichzeitig – sein gesamtes Wissen ist überall verteilt. GRAM hingegen gibt ihm eine spezielle Schublade nur für Virologie, eine für Cybersecurity, eine für Kernphysik und eine für exotische Programmiersprachen. Wenn der Assistent ein allgemeines Buch liest, darf er sein gesamtes Wissen nutzen. Liest er ein Fachbuch über Viren, dann darf nur die Virologie-Schublade lernen – die anderen werden vorübergehend geschlossen. Am Ende kannst du die Schublade einfach herausnehmen, und das Wissen ist weg. Das Modell behält alle anderen Fähigkeiten, nur die gefährlichen sind deaktiviert.

Die technische Umsetzung ist raffiniert, aber verständlich: GRAM fügt jedem Layer eines Transformers (der Standard-Architektur heutiger Sprachmodelle) zusätzliche Neuronen hinzu. Diese sind in Gruppen aufgeteilt, jede steht für eine Dual-Use-Kategorie. Während des Trainings, wenn das Modell auf allgemeinen Text trifft, läuft der normale Lernprozess. Bei speziellem Text aus einer Kategorie werden die allgemeinen Gewichte eingefroren – nur das zugehörige Modul aktualisiert sich. Das Wissen bleibt isoliert. Nach dem Training kann man das Modul entfernen. Das funktioniert, weil das Netzwerk nie gelernt hat, die Dual-Use-Informationen mit dem Rest zu verweben.

Die ersten Tests sind vielversprechend. Die Forscher simulierten drei Szenarien: ein synthetisches mit Kindergeschichten, ein realistischeres mit Webtexten und wissenschaftlichen Artikeln, und dann skalieren sie bis zu einem Modell mit 5 Milliarden Parametern. In jedem Fall zeigte GRAM, dass das Entfernen eines Moduls fast die gleiche Wirkung hatte, als ob dieses Wissen nie im Training gewesen wäre. Und das ohne Einbußen bei allgemeinen Aufgaben. Im Gegensatz zu „Unlearning“-Techniken, die Wissen nur unterdrücken, lässt sich GRAM kaum rekonstruieren. Selbst wenn Angreifer nachträglich kleine Mengen böser Daten geben, können sie das entfernte Wissen nicht wiederherstellen – zumindest nicht einfacher als bei kompletter Datenfilterung.

Besonders spannend: Mit vier Dual-Use-Kategorien ergab ein Trainingslauf 16 verschiedene Konfigurationen (jede Kategorie an- oder ausgeschaltet). Das entspricht sonst 16 separaten Modelltrainings. Der Rechenaufwand bleibt aber der eines einzigen. Die Kostenersparnis ist enorm, wenn man an Frontier-Modelle denkt. Und das wird mit steigender Modellgröße noch besser: Je größer das Modell, desto schwerer ist es für einen Angreifer, die Module zu umgehen – weil die Module selbst immer spezifischer werden.

Dennoch sind die Ergebnisse vorläufig. GRAM wurde nicht auf ein Produktionsmodell wie Claude angewendet. Die Forscher testeten nur die Vorhersagegenauigkeit für das nächste Wort, nicht die Leistung in realen Aufgaben. Und es gibt ein grundlegendes Problem: Manche Dual-Use-Fähigkeiten sind so eng mit Allgemeinwissen verknüpft, dass sie sich gar nicht sauber trennen lassen. Ein Modell, das grundlegende Biologie versteht, lernt vielleicht automatisch auch die Grundlagen der Virologie. Hier stoßen alle Methoden an Grenzen.

Was bedeutet das konkret? Die Forschung zeigt einen Weg, KI-Modelle sicherer zu machen, ohne sie zu lähmen. Statt nur auf Frage-Antwort-Sperren zu vertrauen, könnten wir Modelle bauen, die von Natur aus kontrollierbares Wissen besitzen. Das wäre eine Revolution für die Sicherheit: Ein Modell für den Laboreinsatz mit medizinischem Wissen, ein anderes für den öffentlichen Chat ohne explizite Gefahrenkenntnisse – und beides aus demselben Training. Unternehmen müssten nicht mehr zehn verschiedene Modelle trainieren. Die Kontrolle wäre feiner, die Angriffsfläche kleiner.

Aber es ist noch früh. Wir müssen abwarten, ob GRAM auf den größten Modellen wirklich funktioniert. Und ob die Trennbarkeit von Wissen in allen Fällen gegeben ist. Die Analogie mit den Schubladen ist verlockend, aber manche Wissensbereiche gleichen eher einem Farbverlauf als einer scharfen Grenze. Dennoch: Die Richtung stimmt. Statt immer härtere Schleusen zu bauen, können wir vielleicht lernen, das gefährliche Wissen gar nicht erst ins Gebäude zu lassen – oder es mit einem Schalter auszuschalten, wenn es nicht gebraucht wird.

Quelle: anthropic.com

Stell dir vor, dein Unternehmen macht die ersten Schritte mit KI. Die Belegschaft ist begeistert, die Führung drückt aufs Tempo, jede Abteilung experimentiert. Die Finanzabteilung steckt vertrauliche Umsatzmodelle in öffentliche KI-Playgrounds. Die Personalabteilung lädt sensible Mitarbeiterdaten in externe Dienste hoch – ohne zu prüfen, wie lange die Daten dort bleiben. Für die Sicherheitsteams wird das zum Albtraum. KI hat die Unternehmenssicherheit härter gemacht – nicht durch neue, exotische Bedrohungen, sondern weil sie vorhandene Schwächen gnadenlos beschleunigt.

Der Autor ist kein KI-Gegner. Er nutzt die Technologie täglich, hält sie für transformativ und unvermeidlich. Aber er ist Pragmatiker. Jeder Technologieschub ändert nur die Gestalt der Probleme und verschiebt sie auf eine andere Architekturebene. Die rasche Demokratisierung von Large Language Models und autonomen Code-Agenten hat die Sicherheit in mehreren Punkten deutlich erschwert. Wir müssen über oberflächliche Verwundbarkeiten hinausblicken und die strukturellen Engpässe analysieren, die Sicherheitsteams zermürben.

Der Autor unterscheidet zwei Unternehmenstypen: solche mit ausgereifter KI-Infrastruktur und solche in der hektischen Experimentierphase. In reifen Unternehmen hat man gelernt, dass Nutzen und Risiken von KI variabel sind. Jede Bereitstellung wird geprüft: Datenherkunft, Modellgrenzen, Ausführungsebenen. Man weiß, ob ein Risiko die operative Reibung wert ist. In hyperoptimistischen Experimentierphasen herrscht eine gefährliche Anspruchshaltung. Die Führung ist überzeugt, dass die Vorteile von KI abstrakte Risiken automatisch überwiegen. Also wird uneingeschränkter Zugang gefordert – nicht nur von Entwicklern, sondern von jeder nicht-technischen Abteilung.

Diese Teams wollen die volle Erfahrung sofort. Jede Sicherheitsgrenze gilt als Bedrohung der Unternehmensgeschwindigkeit. Sie wollen die Schleusen öffnen und jeder internen Anwendung vollen Zugriff geben – ohne zu bedenken, dass der Datenzugriff einer KI abgeschottet werden muss. Granulare Identitäts- und Zugriffskontrollen brauchen Zeit. Optimistische, geschwindigkeitsbesessene Organisationen investieren diese Zeit nicht. Auf der Jagd nach einer reibungslosen Benutzererfahrung türmen sie strukturelle Risiken auf, bevor sie ihr erstes Produktionsfeature ausliefern.

Diese Reibung zeigt eine Asymmetrie des Scheiterns. Der Autor vergleicht die Bewertung eines autonomen Agenten durch ein Engineering-Team mit der Sicht eines CISOs. Ein Entwicklungsteam, dessen interner Agent zu 90 % erfolgreich Repositorys patcht oder Kunden-Tickets löst, feiert das als Triumph. Aus Produktsicht ist eine Fehlerrate von 10 % tolerierbar. Für einen CISO ist diese 10 %-Varianz eine katastrophale strukturelle Verwundbarkeit. Sicherheit verfolgt ein anderes Ziel: absolute Vermeidung von Systemversagen. Ein einziger unentdeckter Fehler oder eine halluzinierte Zugriffsgrenze reicht aus, um eine Datenpanne oder einen Betriebsvorfall auszulösen. Produktorientierte Organisationen können endlos experimentieren, weil sie nur einmal erfolgreich sein müssen. Ironischerweise nutzen Angreifer dasselbe Modell. Ein Gegner kann tausendmal scheitern, aber er muss nur eine lockere Prompt-Konfiguration finden, um zu gewinnen. Sicherheitsteams sitzen in der Zange: Sie müssen eine riesige, nicht-deterministische Angriffsfläche verteidigen und zu 100 % richtig liegen, während Entwicklerteams die Architektur aktiv bewaffnen.

Führungskräfte glauben oft, KI schaffe völlig neue Cyberbedrohungen. Der Autor argumentiert, KI erfindet selten neuartige Verwundbarkeiten. Stattdessen verstärkt sie bestehende schlechte Angewohnheiten, Architekturpraktiken und technische Schulden. Eine KI-Anwendung verhält sich wie ein Taschenrechner: Gibst du die falschen Zahlen ein, liefert sie eine falsche Antwort – um Größenordnungen schneller als ein Mensch. KI wendet diese mechanische Beschleunigung auf die Softwareentwicklung an. Wenn dein Team bereits unordentliche IAM-Konfigurationen oder schlechte Code-Review-Disziplin hat, vervielfacht KI diese Fehler sofort. Ein KI-Agent beurteilt keine Qualität. Er repliziert ein loses Berechtigungsmuster in Sekunden über Hunderte von Microservices. Das deckt latente Infrastrukturfehler auf und erzeugt eine massive Systemausbreitung, bevor ein Sicherheitsingenieur den ersten Commit-Log analysiert.

Angreifer nutzen diese Geschwindigkeitsdynamik. Sie setzen automatisierte Tools ein, um die maschinell erzeugte Ausbreitung zu kartieren und auszunutzen – schneller, als defensive Teams reagieren können. Es ist ein ermüdender Kampf gegen einen automatisierten Taschenrechner, der ständig die falschen Zahlen eingibt.

Weil die Technologie zu schnell für traditionelle defensive Frameworks ist, erleben wir eine schmerzhafte Umstrukturierung der Sicherheitsorganisation. Historisch wurden Sicherheitsteams mit einer Compliance-zuerst-Denkweise aufgebaut. Sie waren administrative Körper, die Kästchen ankreuzen, Audit-Logs sammeln und externe Anforderungen erfüllen. Selbst mit hochtechnischen Sicherheitsingenieuren fraß die Compliance-Maschine das Betriebsbudget. Da KI den Softwareentwicklungslebenszyklus einebnet, werden Engineering-Teams enorm gestärkt. Sicherheit kann Risiken nicht mehr durch administrative Richtlinien managen. Die Kluft zwischen Compliance und Engineering wird zu groß.

Um die Lücke zu schließen, spaltet sich die traditionelle CISO-Rolle in zwei Personas. Der compliance-fokussierte CISO wird zum Chief Compliance Officer, der externe Audit-Zyklen managt. Unternehmen holen echte Engineering-Leader als technische CISOs ins Boot – Menschen, die Plattformarchitektur verstehen. Ein neues Security Engineering Team entsteht als Puffer zwischen beiden Welten. Es übersetzt Compliance-Anforderungen in programmierbare Code-Guardrails, die Engineering verdauen kann. Dieser organisatorische Wandel ist unvermeidlich, macht den Sicherheitsjob kurzfristig chaotisch. Er sorgt für Prozessverwirrungen, stellt Eskalationswege auf den Kopf und lässt compliance-fokussierte Praktiker mit weniger Einfluss und Ressourcen zurück.

Diese Störung eröffnet eine Marktchance für Security-Startups. Die meisten KI-Sicherheitsanbieter leiden unter Tunnelblick. Sie bauen fortschrittliche Orchestrierungstools für Elite-Engineering-Teams. Aber diese Teams sind bereits kompetent und überlastet. Der unbediente Markt gehört dem Anbieter, der Software baut, die dem alten compliance-fokussierten Team hilft, sich mit KI in eine moderne Engineering-Einheit zu verwandeln. Ein schwieriges Produkt, dessen Gewinner-Oberfläche noch unklar ist. Wenn ein Startup unordentliche regulatorische Frameworks aufnehmen und elegante, versionierte Policy-as-Code-Konfigurationen ausgeben kann, die in Entwickler-Pipelines passen, erschließt es eine Elite-Kategorie von Unternehmensausgaben. Snyk schloss die Lücke zwischen Entwicklern und AppSec. Wiz verwandelte komplexe Cloud-Infrastruktur in einen priorisierbaren Risikographen. Der Gründer, der die Übersetzungsmaschine für die Compliance-Kluft baut, prägt das nächste Jahrzehnt der Enterprise-Security-Software.

KI hat die Sicherheit härter gemacht, weil sie die Illusion von Kontrolle zerstört hat. Wir können uns nicht länger hinter statischen Richtlinien oder manuellen Gates verstecken. Die Maschine des Unternehmens bewegt sich mit Runtime-Geschwindigkeit. Wenn unsere defensiven Frameworks nicht skalieren, bewachen wir einen leeren Perimeter. Hört auf, nach neuen, exotischen Bedrohungen zu suchen. Automatisiert eure grundlegenden Hygienepraktiken – das ist der Hebel, den KI zieht.

Quelle: franklyspeaking.substack.com

Suchmaschinen liefern oft Dutzende Ergebnisse, die nicht genau treffen, weil sie nur nach Wortübereinstimmungen suchen. Semantische Suche versteht die Bedeutung. HubSpot hat eine Infrastruktur aufgebaut, die für über zwanzig Milliarden Vektoren semantische Suche ermöglicht. Dieser Artikel beschreibt ihre Entscheidungen und Skalierung, von der Machbarkeitsstudie bis zur automatisierten Großanlage.

Eine Vektordatenbank ordnet jedes Objekt in einem mehrdimensionalen Raum an, sodass ähnliche Inhalte nahe beieinander liegen. Die Suche findet die nächsten Nachbarn zur Anfrage. Qdrant, das HubSpot einsetzt, ist ein zentraler Baustein moderner KI-Anwendungen, von Chatbots über RAG-Systeme bis zur Dubletten-Erkennung von Kontakten.

Warum eine zentrale Vektor-Plattform?

HubSpot begann vor einigen Jahren mit einem Proof of Concept. Damals reichte eine Handvoll Cluster, die mit Helm verwaltet wurden. Mit dem Wachstum der KI-Nutzung – heute nutzen über 38 Teams die semantische Suche – wurde eine zentrale, verwaltete Plattform notwendig. So entstand VaaS – Vector as a Service. Es ist die Schicht zwischen den Anwendungen und der Vektordatenbank. Sie übernimmt Zugriffskontrolle, generiert Embeddings, verwaltet Versionen und sammelt Feedback. Die Anwendungen rufen eine API auf und müssen sich nicht um die Komplexität kümmern. Schreiboperationen laufen asynchron, Leseanfragen synchron.

Warum Qdrant und warum selbst betrieben?

Die Wahl fiel auf Qdrant, eine quelloffene Vektordatenbank, die sich auf eigenen Servern betreiben lässt. Qdrant bietet eine umfangreiche API: benannte Vektoren, Hybridsuche, mehrstufige Abfragen und gewichtetes Ranking. Als ANN-Algorithmus verwendet es HNSW, das geringe Latenzen ermöglicht, aber mehr Arbeitsspeicher benötigt. Die HubSpot-Ingenieure nutzen Optimierungen wie Quantisierung und plattenbasierte Optionen, um Qualität und Kosten auszugleichen. Der Betrieb im eigenen Haus bietet volle Kontrolle über die Daten, Integration in die bestehende Infrastruktur (Tracing, Kostenverfolgung, Rate Limiting, Auto-Scaling) und Nutzung der eigenen AWS-Konditionen. Die Sicherheitsstandards von HubSpot lassen sich direkt anwenden.

Die aktuelle Dimension: Zahlen

VaaS verwaltet heute über 200 Indizes, verteilt auf mehr als 140 Qdrant-Cluster in fünf Rechenzentren und zwei Umgebungen. Insgesamt sind das über 20 Milliarden Vektoren – der größte einzelne Index umfasst 9,5 Milliarden Vektoren, der Durchschnitt liegt bei 95 Millionen. Die Plattform verarbeitet regelmäßig über 5.000 Schreiboperationen pro Sekunde, mit Spitzen bis zu 100.000. Leseanfragen liegen bei über 1.000 RPS. Besonders herausfordernd sind Traffic-Spitzen, wenn große Backfills gleichzeitig mit Live-Traffic laufen. Die Infrastruktur muss skalieren und zuverlässig bleiben. Eine Cluster-Isolation nach Produktteams stellt sicher, dass ein Ausfall nicht die gesamte Plattform lahmlegt.

Vom Helm-Proof-of-Concept zum Kubernetes Operator

2023 startete man mit Helm und einer Handvoll Cluster. Jeder Cluster bekam eine eigene Konfiguration, die manuell per YAML und Skripten angelegt wurde. Für zehn Cluster war das machbar, aber mit dem Wachstum wurde der Aufwand enorm. Jeder neue Cluster brauchte nicht nur die Qdrant-StatefulSets, sondern auch Kafka-Themen, Worker-Pods und Monitoring-Komponenten. Helm kann keine API-Aufrufe tätigen, kein automatisches Scaling basierend auf externen Metriken durchführen und keine komplexen Lebenszyklus-Management-Schritte ausführen. Deshalb entschied man sich für den Umstieg auf ein hauseigenes Kubernetes-Operator-Framework namens „Kube-operators“. Ein Operator überwacht ständig den gewünschten Zustand des Systems und bringt die Realität dorthin – automatisch.

Die Migration brachte eine wichtige Änderung: Statt eines gemeinsamen Namespace für alle Cluster gibt es jetzt einen Namespace pro Cluster. Das erhöht die Isolation, vereinfacht das Kosten-Tracking auf Teamebene und reduziert den Blast Radius bei Fehlern. Die Konfiguration eines neuen Clusters besteht heute aus genau einer Custom Resource (CR). Ein Translator (eine Komponente des Operators) überwacht diese CR und erzeugt oder aktualisiert daraus alle notwendigen Ressourcen: Namespace, StatefulSet für Qdrant, Indexer-Pods, Kafka-Themen und benutzerdefinierte Ressourcen für die Metadaten der Cluster. Die Plattform entdeckt neue Cluster automatisch, indem sie die entsprechenden CRs beobachtet. Ein zusätzlicher Translator kümmert sich um die Qdrant-Knoten selbst, ein dritter um die Indexer – die Arbeiter, die eingehende Schreiblast puffern und in Qdrant indizieren. Das alles läuft in einem 60-Sekunden-Zyklus, so dass Änderungen schnell wirksam werden.

Automatisierte Wartung – Shard-Evakuierung aus einem Guss

Ein besonders kniffliger Vorgang ist das horizontale Herunterskalieren eines Clusters. Früher waren mehrere manuelle Schritte nötig: zuerst einen Job ausführen, der die Shards von den zu entfernenden Knoten transferiert und diese aus dem Konsens entfernt; dann die Helm-Chart aktualisieren, die Pod-Anzahl reduzieren, und schließlich die PVCs der gelöschten Pods manuell löschen. Bei über hundert Clustern ein unhaltbarer Zustand. Mit dem Operator ist das heute ein einziger Schritt: einfach die Replica-Anzahl in der Cluster-CR reduzieren. Der Translator erkennt die Abweichung, startet automatisch die Evakuierung aller Shards von den zu entfernenden Peers, wartet auf erfolgreichen Transfer und entfernt die Peers dann aus dem Konsens – und zwar in einer strikten Reihenfolge, die Datenverlust und Verletzung der Replikationsfaktoren verhindert. Erst wenn alle Shards sicher umgezogen sind, werden die Pods heruntergefahren und die PVCs gelöscht. Diese Automatisierung ist entscheidend, um bei der Größenordnung von 140+ Clustern operativ effizient zu bleiben.

Die Architektur zeigt, wie Unternehmen KI-Infrastruktur als Dienst für interne Teams bereitstellen können. Die Teams müssen sich nicht um die Datenbank kümmern, sondern können sich auf die Geschäftslogik konzentrieren. Der Schlüssel liegt in der Automatisierung: Ein Kubernetes-Operator, der nicht nur Pods startet, sondern auch die Shard-Verwaltung von Qdrant übernimmt. Ein zentraler Dienst besteht aus mehr als nur einer API vor einer Datenbank. Es sind Komponenten wie Namespace-Isolation, dynamische Cluster-Entdeckung und automatisierte Skalierung mit Sicherheitsgarantien, die den Unterschied zwischen einer Labordemo und einer produktiven Umgebung mit Milliarden von Vektoren ausmachen. Die Zukunft der KI-Suche liegt nicht nur in besseren Algorithmen, sondern auch in der robusten, wartbaren Infrastruktur, die sie trägt.

Quelle: product.hubspot.com

Du arbeitest an einer Data Pipeline. Nach einem nächtlichen Lauf stellen die Zahlen, aber nur auf den ersten Blick. Irgendwo hat sich ein Fehler eingeschlichen: eine doppelte Zeile, ein falscher Join, der nicht auffällt, weil das Ergebnis nicht abstürzt. Ein Fehler, der nicht bricht, sondern leise falsche Werte liefert, kann in Berichten und Entscheidungen unbemerkt verheerend wirken. In der Datentechnik geht es nicht nur darum, Code zu produzieren, sondern Code, dem wir vertrauen können.

KI-Agenten sollen dabei helfen. Aber wie viel Vertrauen darf man ihnen schenken? Ein aktueller Artikel beschäftigt sich mit dieser Frage und stellt die Korrektheitsschicht vor – ein Sicherheitsnetz, das die Zuverlässigkeit von KI-generierten Datenpipelines erhöht. Der Artikel untersucht drei Ebenen von KI-Agenten in der Datentechnik, die Rolle deterministischer Validierung und wie sich Token-Kosten kontrollieren lassen. Fazit: Die Struktur eines Projekts und die richtigen Werkzeuge sind wichtiger als das neueste Sprachmodell.

Die drei Ebenen der KI-Agenten in der Datentechnik

Warum Agenten für die Datentechnik einsetzen? Und auf welchen Ebenen können sie produktiv helfen? Sprachmodelle haben, wie Menschen, eine gewisse Fehlertoleranz. Wir brauchen eine Möglichkeit, sicherer zu sein, dass der produzierte Code korrekt ist. Der Artikel unterscheidet drei Stufen.

Erste Ebene: die reine Chat-Phase. Hier prompten wir Claude oder ChatGPT. Das Modell versucht, den Kontext zu verstehen, basierend auf dem, worauf es Zugriff hat. Das verbraucht viele Tokens, weil es alles von Grund auf scannen muss. Das Ergebnis ist brauchbar, aber selten produktionsreif.

Zweite Ebene: der autonome Ansatz. Hier haben Agenten wie Claude Code oder Codex Zugriff auf dieselben Werkzeuge wie ein Mensch – die Kommandozeile. Sie können Postgres mit psql abfragen, mit DuckDB aus S3 oder Parquet lesen und so Daten und Queries direkt verifizieren. Die Qualität der Ergebnisse ist höher, weil der Agent nicht nur rät, sondern überprüft.

Dritte Ebene: dedizierte Agenten für die spezifische Aufgabe. Für die Datentechnik kennen diese Agenten dbt oder können SQL-Code deterministisch transpilieren – nicht aus Trainingsdaten, sondern mit einem Werkzeug, das schneller und zuverlässiger arbeitet. Sie haben eingebaute Prüfungen und Funktionen, die ein allgemeiner Agent nicht bietet. Ideal sind immer dedizierte Werkzeuge – aber es gibt nicht für jede Aufgabe ein solches.

Wo im Datenlebenszyklus jede Ebene wirklich hilft

Die Frage ist nicht nur, ob es dedizierte Agenten gibt, sondern in welchem Teil des Datenlebenszyklus sie den größten Nutzen bringen. Geht es um BI-Dashboards, Datenleitungen, Quell-Ingestionen oder Wartung? Der Lebenszyklus umfasst Extraktion, Transformation und Laden, das Verständnis der Geschäftslogik, die Visualisierung der Ergebnisse und die Fehlerbehebung bei nächtlichen Läufen. Grundsätzlich können Agenten im gesamten Zyklus helfen, aber die Antwort hängt stark von der Rolle und Erfahrung des Anwenders ab. Ohne Vorwissen oder Seniorität ist es gefährlich, von Grund auf etwas zu bauen. Man kann nicht überprüfen, ob der Code korrekt ist. Für Nebenprojekte oder Proof-of-Concepts ist das okay, aber nicht für die Produktion.

Die Ingenieursdisziplin im Umgang mit KI

Es gibt auch einen weniger technischen Teil: die Agenten in die richtige Richtung lenken. Wenn wir KI sicher in großen Projekten oder Organisationen einsetzen wollen, können wir sie nicht ohne Führung laufen lassen. Vier Punkte helfen dabei.

Erstens: eine klare Projektstruktur, in der die Agenten sich entfalten können. Je mehr vorgegeben ist, desto weniger Tokens werden verbraucht, desto einheitlicher wird das Projekt. Ein deterministischer Workflow wie uv init ist optimal, weil er immer gleich abläuft.

Zweitens: baue mit klaren Anweisungen – Agenten-Fähigkeiten oder Superkräfte – wie die Werkzeuge verwendet werden. Das bedeutet, dem Agenten CLI- und API-Dokumentationen bereitzustellen. Das ist der Hauptteil der Arbeit. Es geht um die Datenarchitektur, das Brainstorming mit Kollegen, bevor man etwas baut, damit man keine entscheidende Einsicht verpasst und den Agenten in die falsche Richtung laufen lässt. Ein Prompt wie „sei korrekt“ oder „verwende den neuesten Stand der Technik“ macht den Code nicht korrekter oder moderner, als das Modell trainiert wurde. Bei relativ neuen Architekturen muss man dem Agenten die entsprechenden Links und Hinweise geben.

Drittens: gestalte das Projekt modular, sodass die Agenten nicht das gesamte Projekt zerstören können, wenn sie eine kleine Änderung vornehmen. Kein Abhängigkeits-Chaos, bei dem alles von allem abhängt.

Viertens: verwende einen deklarativen Ansatz mit beschreibender Konfiguration, der das „Was“ und nicht das „Wie“ festlegt. So kannst du mit den Agenten an diesen Konfigurationen zusammenarbeiten, sie versionieren, leicht zurücksetzen oder ändern und die Implementierungslogik von der Geschäftslogik entkoppeln. Das Modell spielt eine geringere Rolle. Struktur und Workflow sind entscheidend. Plane ausgiebig, bevor du eine einzige Zeile schreibst, und korrigiere das Modell, bevor es in die falsche Richtung läuft. Ziel ist Nutzen aus der KI, nicht mehr Arbeit. Früher dachten die meisten Entwickler über das Problem nach. Heute ertrinken viele in Pull-Requests. Bessere KI-Werkzeuge können qualitativ hochwertigeren Code liefern, der weniger Überprüfung und weniger Iterationen erfordert – also weniger PRs und weniger Arbeit.

Die Korrektheitsschicht für Dateningenieure

KI-Agenten sollten den Menschen für Korrektheit unterstützen – oder eine Korrektheitsschicht. Statt mehr Arbeit zu verursachen, um mehr Code zu verifizieren, sollten wir Vertrauen in den Prozess haben und wissen, dass der produzierte Code verifiziert und korrekt ist. Eine deterministische Validierungsarchitektur ist dafür zentral. Der Artikel führt Altimate Code als Beispiel an. Dieses Tool teilt den Agenten in eine probabilistische Schicht oben und eine deterministische Rust/TS-Schicht unten auf, die die eigentlichen SQL-Operationen wie Parsen, Validieren und Äquivalenzprüfungen übernimmt. Der Agent selbst muss bei diesen Fragen nie vertraut werden.

Konkret: Der probabilistische Agent mit dem LLM übernimmt die kreative Arbeit – Intention lesen, Strategie wählen, SQL entwerfen, Ergebnisse zusammenfassen, sich von Fehlern erholen. Unter dieser Grenze liegt das deterministische Geschirr (deterministic harness), eine TypeScript-Schicht, die jeden Werkzeugaufruf abfängt. Ein Dispatcher prüft, ob ein nativer Handler existiert, und leitet den Aufruf entweder an einen nativen, deterministischen Handler oder zurück an das Modell. Diese Handler rufen die Logik nicht selbst auf, sondern ein deterministisches Core-Modul in Rust (altimate-core), das SQL-Operationen als reine Funktionen über ASTs und Schemata bereitstellt. Parsen, Validieren, Transpilieren, Query-Äquivalenz prüfen, Schema-Diffs, Column-Lineage extrahieren, Zeilen-Diffs über Data Warehouses hinweg – all das läuft sub-Millisekunde und liefert bei gleichem Input immer die gleiche Antwort. Wie ein Compiler: Der Agent entscheidet nie, ob zwei Queries äquivalent sind oder eine Spalte upstream existiert. Stattdessen ruft er eine Funktion auf, die es am geparsten AST und Schema beweist – so wie ein Type-Checker beweist, dass ein Programm kompiliert, anstatt zu raten.

Das macht die Ausgabe leichter überprüfbar: Faktische Prüfungen wurden ausgeführt, und die Ausgabe ist entweder korrekt, oder es gibt einen Bug, den der Agent direkt beheben kann. Den Rest kann ein Mensch verifizieren. Das Dilemma: Code wird schneller genehmigt, als geprüft werden kann. Dazu gibt es einen separaten Beitrag. Ein weiterer Faktor: Reiner Agenteneinsatz mag günstig erscheinen – aber nur, bis er falsch liegt. Dann sind die Kosten unbegrenzt.

Verbesserungen für eine bessere Token-Nutzung

Altimate Code oder ähnliche Agenten mit deterministischen Funktionen helfen, Tokens zu sparen und token-effizient zu arbeiten – das Gegenteil von Tokenmaxxing, einem Trend auf Social Media, bei dem möglichst viele Tokens verbraucht werden und Agenten rund um die Uhr laufen. In großen Unternehmen sind Token-Kosten ein echtes Budget-Thema. Ein einfacher Trick: Weist das Modell an, selbst weniger Tokens und Wörter zu verwenden – „Höhlenmensch-Stil“ ist ein Beispiel. Du kannst auch einen einzelnen Prompt in deine CLAUDE.md oder in Codex einfügen, in Kombination mit Altimate Code.

Es gibt einen zweiten, weniger offensichtlichen Kostenpunkt: Der Token selbst ist keine stabile Einheit. Als Anthropic Opus 4.7 auslieferte, kostete derselbe Prompt, der auf 4.6 X Tokens verbrauchte, auf 4.7 plötzlich etwa 1,4X – gleicher Input, gleiche Antwort, mehr Tokens, gleicher Preis pro Token. Der Artikel verweist auf einen Beitrag, der argumentiert, dass „Kosten pro Token“ die falsche Kennzahl sei, denn der Zähler selbst kann sich mit dem nächsten Modell-Update des Anbieters verschieben. Was wir stattdessen verfolgen sollten, sind Kosten pro Aufgabe. Deterministische Funktionsaufrufe umgehen diese Volatilität, indem sie für viele Aufgaben gar kein Modell und keine Tokens benötigen – das macht die Sache günstiger.

Typische Anwendungsfälle

Welche konkreten Einsatzmöglichkeiten gibt es für KI-Agenten in der Datentechnik? Die Liste ist lang. Du kannst sie nutzen, um dich oder dein Team weiterzubilden, produktive Datenpipelines zu bauen, Daten-Apps zu entwickeln und Daten auf innovative Weise zu visualisieren – meistens als HTML-Seiten mit React und anderen JavaScript-Frameworks. Die Anwendungsfälle lassen sich in verschiedene Ansätze gliedern: von der Unterstützung bei der Codeerstellung über die Automatisierung von Tests bis hin zur Generierung von Dokumentation. Der entscheidende Punkt bleibt: Ohne eine Korrektheitsschicht und eine durchdachte Projektstruktur wirst du auf Dauer keine verlässlichen Ergebnisse erzielen. Die Werkzeuge sind da, aber du musst wissen, wie du sie einsetzt.

Was bedeutet das für den Dateningenieuralltag? Vertraue nicht blind, sondern baue eine deterministische Validierung ein. So werden KI-Agenten von einer Blackbox zu einem verlässlichen Partner. Je besser die Werkzeuge, desto unabhängiger wirst du von jedem einzelnen Modell. Der deterministische Rahmen – die Korrektheitsschicht – ermöglicht es, Ergebnisse zu reproduzieren und ihre Herkunft nachzuverfolgen, unabhängig vom Modell. Das gilt besonders bei Wartungsarbeiten oder Erweiterungen, bei denen die Überprüfung die eigentliche Arbeit ist. Die Gefahr liegt nicht im Absturz, sondern in einer falschen Zahl, die nicht auffällt. Es mag eine saubere Query sein, aber sie führt zu doppelten Zeilen. Mit der richtigen Architektur kannst du solche stillen Fehler eliminieren. Hier liegt der Schwerpunkt: menschliche Expertise, Projektstruktur und Korrektheitsschicht machen den Unterschied.

Quelle: ssp.sh