Agentic AI im Data Engineering: Warum Architektur entscheidend ist

In einem früheren Artikel haben wir gezeigt, wie wir in Databricks einen KI-Agenten entwickelten, der Ihre Daten auswertet, Schlussfolgerungen daraus zieht und Ihnen Empfehlungen liefert, auf deren Grundlage Sie handeln können. In jenem Artikel ging es darum, wie man einen solchen Agenten aufbaut. In diesem Artikel geht es um die Frage, die sich für viele dann am nächsten Morgen stellt: Wo findet ein solcher Agent tatsächlich seinen Platz im Data-Engineering-Workflow, und was entscheidet darüber, ob er tatsächlich hilfreich ist oder nur noch schneller Chaos verursacht?

Stellen Sie sich den zweiten Fall vor: Ein Agent eröffnet über Nacht einen Pull-Request. Er hat eine Daten-Transformation umgestaltet und einen erfolgreichen Test hinzugefügt, und die Beschreibung liest sich gut. Außerdem hat er eine Spalte in einem Modell in „customer_id“ umbenannt, obwohl alle benachbarten Tabellen diese Spalte seit drei Jahren „cust_key“ heißen. Niemand hat dem Agenten mitgeteilt, dass diese Konvention existiert. Im Diff (Änderungsreport) ist nichts fehlerhaft. Dennoch gehört dies nicht in Ihre Plattform und ein Reviewer muss dies nun bemerken, bevor der Pull-Request gemergt wird. Multipliziert man das mit einer Woche mit von Agenten generierten Änderungen, wird das Ausmaß des Problems deutlich.

Was ist agentische KI-Automatisierung? Über die Autovervollständigung hinaus

Die sinnvolle Grenze verläuft zwischen einem einzelnen Modellaufruf und einem Agenten. Ein einzelner Aufruf nimmt eine Eingabe entgegen, gibt Text zurück (eine Vervollständigung, eine Zusammenfassung, eine Antwort in einem Chat-Fenster) und wartet dann auf dich. Ein Agent führt stattdessen eine Schleife aus. Er kann ein Schema lesen, eine Änderung vorschlagen, den Test für diese Änderung durchführen und den zurückgemeldeten Fehler nutzen, um einen anderen Ansatz zu versuchen, wobei er Tools aufruft und systemübergreifend agiert, bis er etwas erreicht, das er als abgeschlossen betrachtet.

Genau diese Schleife macht Agenten für die Datenarbeit so nützlich. Es bedeutet aber auch, dass ein unbegrenzter Agent irgendwann an einer Stelle agieren wird, an der Sie es nicht wollten; daher ist die Version, die sich in der produktiven Umgebung bewährt, eine begrenzte: Der Agent führt die mehrstufigen Arbeitsschritte innerhalb der von Ihnen festgelegten Grenzen durch, und ein Mensch gibt an den entscheidenden Punkten die Freigabe.

Top-Anwendungsfälle für AI-Engineering-Agenten in der Softwareentwicklung

In einem typischen Data-Engineering-Workflow sind Agenten bereits bei einer Reihe von Aufgaben sehr leistungsfähig:

• Dokumentation. Datenwörterbücher (data dictionaries), Spaltenbeschreibungen, Herkunftsübersichten und Runbook-Entwürfe, die nah am Code bleiben, anstatt in einem Wiki in Vergessenheit zu geraten.

• Test- und Qualitätsgerüst. Die Umsetzung von Erwartungen in einen ersten Entwurf von Testfällen, Anomalieprüfungen und Validierungsregeln: ein Ausgangspunkt, den ein Entwickler verfeinert, noch nicht das letzte Wort.

• Programmierung und Refactoring. Generierung von Transformationslogik, Übersetzung zwischen SQL-Dialekten und automatische Refactorings über viele Dateien hinweg gleichzeitig.

• Review. Ein erster Durchlauf eines Diffs, der Anti-Patterns, Stilabweichungen und offensichtliche Performance- oder Governance-Probleme kennzeichnet, bevor sich ein menschlicher Reviewer damit befasst.

• Debugging und Triage. Auswerten von Protokollen, Zurückverfolgen eines Fehlers bis zu seiner Ursache und Vorschlagen einer Korrektur, die von einer Person genehmigt oder freigegeben werden muss.

• Modellierung. Profiling einer Datenquelle und Vorschlag eines Schemas, einer Normalisierungsentscheidung oder eines ersten Entwurfs für ein Dimensionsdesign. 

   

Diese Tasks sind jedoch nicht gleichwertig. Dokumentation und Test - Gerüste lassen sich kostengünstig überprüfen und sind schwer zu korrumoieren; wenn ein Wörterbucheintrag falsch ist, korrigiert ihn jemand und sonst passiert kaum etwas. Eine Schemaänderung oder eine Korrektur in der Produktion birgt echte Nachteile: Der Arbeitsaufwand, den sie erspart, ist hoch, aber eine fehlerhafte Änderung breitet sich aus, bevor es jemand bemerkt. Wo eine Aufgabe auf diesem Spektrum angesiedelt ist und nicht, wie beeindruckend der Agent dabei wirkt, sollte darüber entscheiden, wie viel Spielraum man ihr einräumt.

Sehen Sie sich die Aufzeichnung unseres Webinars an: "Bridging Business and Analytics: The Plug-and-Play Future of Data Platforms"

Warum Kontext und Systemarchitektur die Leistung von KI-Agenten bestimmen

Ein Agent ist nur so gut wie der Kontext, mit dem er arbeitet und auf einer Datenplattform besteht dieser Kontext größtenteils aus der Architektur. Namenskonventionen, Modellierungsstandards, ein semantischer Layer, der festlegt, was „Umsatz“ tatsächlich bedeutet, ein Verantwortlicher für jeden Bereich: Das sind die Faktoren, die es einem Agenten ermöglichen, etwas zu produzieren, das zum Rest der Plattform passt, anstatt nur für sich genommen korrekt zu sein. Nimmt man diese Struktur weg, produziert der Agent dennoch etwas. Er liefert selbstbewusste Ergebnisse, die für sich genommen gut lesbar sind, aber stillschweigend im Widerspruch zu allem um ihn herum stehen: die umbenannte Spalte, die Metrik, die auf eine vierte, andere Art berechnet wurde, die Tabelle, die in einem Modell normalisiert wurde, während drei andere sie absichtlich denormalisiert haben. Jede Änderung sieht für sich genommen vernünftig aus. Zusammen sind sie technische Schulden, die schneller entstehen, als ein Team von Menschen sie hätte schreiben können. Deshalb ist die Aussage „Ein Agent wird unsere chaotische Plattform aufräumen“ in ihrem Kausalzusammenhang verkehrt: Ein Agent verbraucht Struktur, er kann sie nicht erzeugen. Gibt man ihm eine gut modellierte, gut gesteuerte Plattform, verstärkt er gute Ingenieursarbeit. Gibt man ihm einen inkonsistenten Ausgangspunkt, erhält man diese Inkonsistenz in großem Maßstab zurück, was später mehr kostet, als es gekostet hätte, die Grundlage von vornherein richtig gestaltet zu haben.

Governance ist das, was Delegation möglich macht

Man kann nur eine Task delegieren, die man überprüfen, eindämmen und rückgängig machen kann - und genau deshalb ist Governance, die so oft als Bremse für Agenten betrachtet wird, das, was es einem tatsächlich ermöglicht, ihnen echte Arbeit zu übertragen. Zugriffskontrollen begrenzen, worauf ein Agent zugreifen kann. Datenverträge liefern ihm stabile Definitionen, auf deren Grundlage er arbeiten kann. Überprüfungsschritte stoppen plausible, aber falsche Ergebnisse, bevor sie veröffentlicht werden. Und wenn doch einmal etwas durchrutscht, zeigen ein Prüfpfad und klare Zuständigkeiten, was sich geändert hat und wer dafür verantwortlich ist. Ein Team, das diesen Grenzen vertraut, kann mehr an Agenten delegieren, gerade weil es weiß, wo die Grenzen liegen. Das ist auch der Grund, warum eine sinnvolle Einführung dem „Blast Radius“ folgt. Beginnen Sie dort, wo der Aufwand hoch und das Risiko gering ist (Dokumentation, Testgerüst, Erstprüfung), und lassen Sie die Agenten mit nur geringer menschlicher Einmischung arbeiten. Halten Sie die Mitarbeiter bei der Modellierung und allem, was in die produktive Umgebung gelangt, stets auf dem Laufenden. Messen Sie die Auswirkungen, anstatt sie anzunehmen und erweitern Sie dann die Autonomie eines Agenten, sobald Ihre Leitplanken und Ihr Vertrauen in ihn reifer werden. Wenn Sie die Ausgabe eines Agenten bei einer bestimmten Task noch nicht schnell und zuverlässig überprüfen können, ist dieser Task noch nicht bereit für die Übergabe; in den meisten Fällen ist das Hindernis eine Lücke in den Grundlagen und nicht eine Grenze des Agenten.

Auf dem Weg zur agentischen Governance: Unser Fazit

Agentische KI entwickelt sich zu einer echten Ebene oberhalb der modernen Datenplattform, und die Produktivitätsgewinne sind keineswegs hypothetisch. Sie wirkt jedoch wie ein Multiplikator, und ein Multiplikator spiegelt immer nur das wider, was man ihm vorgibt: gute Technik auf einer gut gesteuerten Plattform und jede bestehende Inkonsistenz auf einer instabilen Plattform - beides in vergrößertem Maßstab. Die Teams, die am meisten davon profitieren, sind nicht unbedingt die Early Adopters, sondern diejenigen, die zuerst die unscheinbare Arbeit geleistet haben (die Architektur, die Standards, die Governance) und dann den Agenten ermöglichen, darauf aufbauend schneller voranzukommen.  Agenten verändern das Tempo, nicht die Verantwortlichkeit: Die Definition von Qualität bleibt immer Aufgabe der Teams, nicht der KI.

Wenn Sie eine professionelle Einschätzung darüber wünschen, ob Ihre Datenplattform so aufgestellt ist, dass Sie Aufgaben sicher an Agenten delegieren können, besprechen wir das gerne mit Ihnen.