Vorbereitung auf Dataiku Agent Management: Wie erfassen Unternehmen AI-Agenten? Checkliste 2026

Am 24.09.2026 kündigte Dataiku Agent Management als eigenständiges Produkt an und plant die allgemeine Verfügbarkeit für Oktober 2026; ein konkreter Starttermin ist noch nicht bestätigt (offizielle Ankündigung). Der richtige Schritt ist deshalb, jetzt mit einer eigenen plattformübergreifenden Agentenliste, klaren Verantwortlichen und einer begründeten Risikoeinstufung zu beginnen. Warten Sie nicht auf das Produkt: Überwachungseinträge belegen weder sichere Ausführungsrechte noch eine isolierte Umgebung.

Für Plattformingenieure: Sie müssen verteilte und selbst betriebene Agenten auffindbar machen und die Liste aktuell halten.
Für Sicherheits- und AI-Governance-Verantwortliche: Sie müssen Agenten mit sensiblen Daten, Kundenkontakt oder Handlungsrechten priorisieren.
Für Entwicklungs- und Geschäftsverantwortliche: Sie müssen Zweck, Eigentümer und Kriterien für Weiterbetrieb oder Pause dokumentieren.

Zuletzt aktualisiert am 26.09.2026. Geprüft anhand der Dataiku-Ankündigung und des Dataiku-Produktblogs. Geplante Verfügbarkeit und Funktionsumfang können sich durch spätere offizielle Angaben ändern.

Welche Agenteninformationen sollten Sie vor dem Start erfassen?

Beginnen Sie mit der Bestandsaufnahme, nicht mit der Frage, ob jeder Agent bereits in einem zentralen Produkt sichtbar ist. Eine Inventarliste ist nur dann belastbar, wenn sie auch Agenten aus Eigenentwicklungen, Fachbereichsprojekten und abweichenden Laufzeitumgebungen erfasst. Dataiku beschreibt die Erkennung über mehrere Plattformen und die Unterstützung benutzerdefinierter Umgebungen mit OpenTelemetry; das ist eine Herstellerangabe, keine unabhängige Bestätigung, dass jede Plattform automatisch angeschlossen oder vollständig erfasst wird. Die Dataiku-Beschreibung der Agentenübersicht und Überwachungsfunktionen sollten Sie deshalb als angekündigten Produktumfang lesen, nicht als Ersatz für Ihre eigene Erhebung.

Erfassen Sie für jeden Eintrag mindestens:

• eine stabile Agentenkennung und einen Link zum Repository, Dienst oder Bereitstellungsdatensatz;
• Laufzeitplattform und konkrete Bereitstellungsumgebung, einschließlich selbst verwalteter Komponenten;
• verantwortliches Team, fachlichen Zweck und vorgesehene Nutzergruppe;
• verwendete Modelle, Datenquellen, Datenverbindungen und aufrufbare Werkzeuge;
• mögliche Nebenwirkungen, etwa Schreibzugriffe, externe Aktionen oder Transaktionen;
• vorhandene Protokolle, Metriken und Traces sowie deren jeweilige Quelle;
• Änderungsstand oder Konfigurationsversion, Datum der letzten Prüfung und prüfende Person;
• den Status „bestätigt“, „noch zu verifizieren“ oder „unbekannt“.

Halten Sie außerdem fest, woher jeder Eintrag stammt. Ein selbst gemeldeter Agent, ein gefundener Dienst und eine automatisch erzeugte Telemetriebeobachtung sind nicht gleichwertige Nachweise. Eine leere Erfassung darf nicht als Beleg dafür gelten, dass in der betreffenden Umgebung kein Agent läuft.

OpenTelemetry beschreibt Instrumentierung als Verfahren, mit dem eine Anwendung Telemetriedaten für die Beobachtung erzeugt. Das hilft bei der technischen Erfassung, aber nur, wenn die Anwendung oder ihre Laufzeit passend instrumentiert ist. Prüfen Sie die OpenTelemetry-Grundlagen zur Instrumentierung und notieren Sie für jede Umgebung, ob Daten aktiv übertragen, nur lokal gespeichert oder gar nicht erzeugt werden.

Wie lassen sich Verantwortliche und Zwecke plattformübergreifend zuordnen?

Eine Plattformkennung beantwortet nicht automatisch, wer fachlich für einen Agenten einsteht. Das Konto, unter dem ein Agent erstellt wurde, kann einem inzwischen ausgeschiedenen Mitarbeitenden, einem zentralen Automationsteam oder einem technischen Dienstkonto gehören. Trennen Sie deshalb die ursprüngliche Entwicklung von der laufenden Betriebsverantwortung.

Plattformengineering: Erfassung und Aktualisierung

Das Plattformteam legt ein verbindliches Schema fest und führt die Quellen zusammen. Für jede Integrationsquelle sollte klar sein, wer Daten liefert, wie Änderungen erkannt werden und wer Lücken nachverfolgt. Kennzeichnen Sie selbst betriebene oder nicht automatisch erfasste Umgebungen ausdrücklich. OpenTelemetry kann hier Instrumentierung und Telemetrie vereinheitlichen; es ist aber kein universeller Agenten-Scanner. Auch eine Instrumentierung beweist nicht, dass sämtliche Werkzeuge und Berechtigungen eines Agenten korrekt abgebildet sind.

Entwicklung und Fachbereich: Eigentümer und Verwendungszweck

Lassen Sie das erstellende Team den ursprünglichen Zweck, die Zielgruppe und die erwartete Wirkung dokumentieren. Lassen Sie zusätzlich eine Betriebsverantwortung benennen, die auch nach einem Teamwechsel erreichbar ist. So verhindern Sie, dass eine technische Eigentümerschaft als fachliche Freigabe missverstanden wird.

Stellen Sie den tatsächlichen Einsatz dem genehmigten Zweck gegenüber. Ein Agent, der ursprünglich interne Dokumente zusammenfasste, kann später mit Kundenkommunikation oder zusätzlichen Datenquellen verbunden worden sein. Wenn Zweck oder Zielgruppe abweichen, markieren Sie den Datensatz als prüfpflichtig. Fehlt ein verantwortliches Team, erhält der Agent keinen stillschweigenden Freibrief: Legen Sie fest, wer die Zuständigkeit klärt und welche Aktionen bis dahin eingeschränkt werden.

Hinweis: Ein Eintrag mit „Eigentümer unbekannt“ ist kein Verwaltungsfehler, den Sie bis zum nächsten Audit liegen lassen sollten. Bei schreibenden oder extern erreichbaren Agenten ist er ein Anlass, Reichweite und Rechte vorläufig zu begrenzen.

Welche Agenten verdienen zuerst Risikoprüfung und Freigabe?

Priorisieren Sie nach tatsächlicher Wirkung, nicht nach einer vom Hersteller vergebenen Risikokategorie. Ein Agent mit Zugriff auf sensible Daten, direktem Kundenkontakt oder der Möglichkeit, Buchungen, Änderungen und andere externe Aktionen auszulösen, braucht mehr Aufmerksamkeit als ein rein lesender interner Prototyp. Entscheidend sind Datenzugriff, Werkzeuge, Reichweite, Nebenwirkungen und menschliche Freigabepunkte.

Das NIST-Risikomanagement-Framework für generative AI und das NIST-AI-RMF-Playbook können Ihre Governance-Arbeit strukturieren. Verwenden Sie sie als Orientierung für den eigenen Prüfprozess, nicht als automatische Zertifizierung eines konkreten Agenten. Ergänzend beschreibt die OWASP-Sicherheits-Checkliste für AI-Agenten Sicherheitsaspekte rund um Agenten und ihre Werkzeuge. Auch daraus folgt nicht, dass ein bloßer Listenabgleich einen Agenten für den produktiven Betrieb freigibt.

Sicherheits- und Governance-Team: Wirkung statt Etikett

Für jeden priorisierten Agenten dokumentieren Sie, welche Daten er lesen und verändern kann, welche externen Werkzeuge er aufrufen darf und ob Aktionen sofort wirksam werden. Halten Sie fest, an welcher Stelle ein Mensch freigeben muss und welche Aktivitäten ohne Freigabe grundsätzlich blockiert sind. Prüfen Sie außerdem, ob Zugangsdaten nach dem Prinzip der geringsten erforderlichen Rechte vergeben sind und ob unterschiedliche Aufgaben getrennte Ausführungskontexte erhalten.

Legen Sie die Stufen Ihrer Risikobewertung selbst fest. Eine einfache betriebliche Staffelung kann beispielsweise zwischen geringem Einfluss, begrenzten Nebenwirkungen und hohem Einfluss unterscheiden. Die Einstufung muss sich auf interne Regeln und nachvollziehbare Belege stützen. Verwenden Sie sie nicht als Sicherheitszertifikat und kopieren Sie nicht unbesehen eine Produktkennzeichnung in Ihre Freigabeentscheidung.

Betrieb und Qualität: Überwachung ist nicht Abnahme

Vereinbaren Sie, welche Daten Gesundheit, Nutzung, Kosten, Qualität und Verhaltensänderungen jeweils belegen. OpenTelemetry beschreibt Signale wie Traces, Metriken und Logs; die Dokumentation zu OpenTelemetry-Signalen hilft, diese Datenarten auseinanderzuhalten. Ein Trace kann Aufrufpfade sichtbar machen, eine Metrik einen erfassten Messwert und ein Log ein protokolliertes Ereignis. Keines davon beweist für sich, dass ein fachliches Ergebnis richtig ist.

Definieren Sie für fehlende oder unvollständige Überwachung einen manuellen Ablauf: Wer prüft den Dienst? Wer informiert den verantwortlichen Fachbereich? Welche Aktionen werden bis zur Klärung ausgesetzt? Wenn ein Signal ausfällt, darf ein grüner Status aus einem anderen System nicht automatisch als Entwarnung dienen.

Können Monitoringdaten Ausführungsrechte oder Isolation ersetzen?

Nein. Monitoring kann beobachtbare Veränderungen sichtbar machen. Es entzieht aber keine Rechte, verhindert keinen unerlaubten Werkzeugaufruf und isoliert keine Laufzeit. Diese Kontrollen müssen in der tatsächlichen Ausführungsumgebung liegen: etwa in Berechtigungen, getrennten Konten, Netzwerkregeln, Geheimnisverwaltung, Freigabeschritten und Grenzen für Datenzugriff oder schreibende Aktionen.

Trennen Sie in Ihrer Prüfung deshalb drei Nachweisarten:

• Sichtbarkeit: Welche Ereignisse und Zustände kann das Team beobachten?
• Steuerung: Welche Aktionen kann der Agent technisch ausführen oder nicht ausführen?
• Lieferfreigabe: Welche Tests und fachlichen Prüfungen belegen, dass die konkrete Version für den vorgesehenen Zweck geeignet ist?

Eine gute Überwachung ersetzt weder Tests noch Ergebnisprüfung. Sie bestätigt auch nicht, dass ein Agent eine Codeänderung sicher ausgeliefert hat. Verknüpfen Sie den Prüfstatus daher mit einer konkreten Agentenkennung und einer Version oder Konfiguration. Wird diese Konfiguration geändert, muss erkennbar sein, ob die bisherige Bewertung weiterhin gilt oder erneut geprüft werden muss.

Audit und Sicherheit: belastbare Freigabeunterlagen

Für jeden Agenten mit erheblicher Wirkung benötigen Sie eine nachvollziehbare Akte. Sie sollte Risikobegründung, Testnachweise, offene Punkte, Freigabeentscheidung, verantwortliche Person und nächsten Prüfanlass enthalten. Achten Sie darauf, dass diese Unterlagen einer Version oder Konfiguration zugeordnet sind. Ohne diese Verbindung kann eine Freigabe für einen früheren Stand fälschlich als Beleg für den aktuellen Betrieb erscheinen.

Wenn die Nachweise nicht ausreichen, entscheiden Sie vorab, was passiert: hohe Auswirkungen vorübergehend sperren, Reichweite und Rechte einschränken oder gezielte Tests nachholen. „Noch nicht geprüft“ darf in der Inventarliste nicht ununterscheidbar neben „geprüft und freigegeben“ stehen.

Checkliste für die erste Bestandsaufnahme

Nutzen Sie die Liste in einem gemeinsamen Arbeitsdurchgang mit Plattform, Betrieb, Fachbereich und Sicherheitsverantwortlichen. Ein nicht erfüllter Punkt ist eine konkrete offene Aufgabe, kein Anlass, den Agenten automatisch als unbedenklich einzuordnen.

• [ ] Alle bekannten Plattformen, Repositories, Laufzeitumgebungen und selbst betriebenen Installationen sind als Erfassungsquellen benannt.
• [ ] Jeder gefundene Agent hat eine stabile Kennung und einen nachvollziehbaren Eintrag zur Umgebung.
• [ ] Datenquellen, Modelle, Werkzeuge und externe Verbindungen sind dokumentiert oder als ungeklärt markiert.
• [ ] Fachlicher Zweck und vorgesehene Nutzergruppe entsprechen dem aktuellen Einsatz.
• [ ] Entwicklungsteam und laufende Betriebsverantwortung sind getrennt und beide benannt.
• [ ] Agenten mit sensiblen Daten, Kundenkontakt oder schreibenden beziehungsweise transaktionsbezogenen Aktionen sind priorisiert.
• [ ] Risikostufen beruhen auf internen Kriterien und konkreten Zugriffs- und Wirkungsnachweisen.
• [ ] Monitoringquellen sind nach Logs, Metriken, Traces und tatsächlichen Lücken beschrieben.
• [ ] Für fehlende Telemetrie gibt es einen verantwortlichen manuellen Prüf- und Eskalationsweg.
• [ ] Rechte, Freigabepunkte und Isolationsgrenzen sind separat von Überwachungsdaten belegt.
• [ ] Tests und Freigabe sind mit der geprüften Version oder Konfiguration verknüpft.
• [ ] Für ungeklärte Zuständigkeit oder unzureichende Belege ist eine konkrete Einschränkung, Nachprüfung oder Pausierung beschlossen.

Governance-Reihenfolge für Budget und Betrieb

Legen Sie die Reihenfolge nicht allein anhand erwarteter Einsparungen oder einer Produktbeschreibung fest. Stellen Sie Agentennutzung, nachvollziehbare Kosten, Geschäftswert und Risiko in derselben Überprüfung gegenüber. Wenn Kosten nicht zugeordnet werden können, ergänzen Sie zunächst die fehlende Nutzungs- oder Abrechnungsquelle. Erfinden Sie keine Prognose zur Kapazität oder zum Einsparpotenzial aus einer allgemeinen Funktionsbeschreibung.

Die Dataiku-Ankündigung nennt eine geplante allgemeine Verfügbarkeit im Oktober 2026 und beschreibt Plattformzugänge sowie eine Abrechnung beziehungsweise Messung durch den Anbieter. Behandeln Sie das nicht als bestätigte Preisangabe oder als Beleg, dass der Umfang zu Ihren internen Plattformen passt. Prüfen Sie die aktuellen offiziellen Angaben, sobald sie vorliegen, und vergleichen Sie sie mit Ihrem Inventar. Bis dahin können Sie priorisieren: zuerst Agenten ohne Verantwortliche, dann Agenten mit hoher möglicher Wirkung und unzureichenden Prüfbelegen, danach Anwendungen, deren Kosten oder Nutzung sich nicht erklären lassen.

Für die Überprüfung reichen Sie nicht nur einen Gesamtkostenwert ein. Zeigen Sie, welche Aufgaben der Agent erfüllt, welche Aufrufe und Datenverbindungen tatsächlich anfallen und welche Folgen eine Einschränkung hätte. So bleibt die Entscheidung zwischen Weiterbetrieb, zusätzlicher Prüfung oder Pause an beobachtbare betriebliche Fakten gebunden.

Wenn für einzelne Aufgaben eine echte macOS-Werkzeugkette erforderlich ist, nehmen Sie deren Ausführungsumgebung separat in die Abnahme auf. Ein allgemeiner Entwicklungsrechner oder eine nicht passende Cloud-Umgebung kann bei macOS-spezifischen Builds, Berechtigungen und reproduzierbaren Tests an Grenzen stoßen. Ein gemieteter Mac über vmzig kann dann eine passendere Testumgebung sein, sofern der konkrete Auftrag macOS erfordert. Für reine Inventarisierung, Agenten-Governance oder langfristige Dauerlast ist eine Mac-Miete nicht automatisch sinnvoll. Prüfen Sie zuerst, ob die Umgebung, Rechte und Übergabewege zu Ihren Anforderungen passen. So schließen Sie eine Lücke im Ausführungsnachweis, statt Monitoring mit tatsächlicher Kontrolle zu verwechseln.