Executive Briefing: Kauft keine Agenten, die ihr nicht betreiben könnt

AI-Agenten sind keine normale Softwarebeschaffung. Sie greifen in Daten, Rechte und Workflows ein. Deshalb muss der Betrieb vor dem Kauf geklärt sein. Der eigentliche Preis liegt nicht in der Lizenz, sondern in Datenzugang, Rechten, Audit, Aufsicht und Exit.

Warum dieses Briefing?

Kürzlich sind mehrere Enterprise-AI-Meldungen aufgelaufen, die auf den ersten Blick nach getrennten Nachrichten aussehen.

Anthropic baut mit Blackstone, Hellman & Friedman und Goldman Sachs eine neue Enterprise-AI-Services-Firma. OpenAI sammelt laut Bloomberg mehr als vier Milliarden Dollar für eine ähnliche Deployment Company ein. SAP kauft Dremio und Prior Labs, also Dateninfrastruktur und Modelle für strukturierte Unternehmensdaten. Pinecone bringt Nexus als Knowledge Engine für Agenten. ServiceNow öffnet seine Workflow-Schicht über Action Fabric für externe Agenten. Und CodeWall zeigt am Fall McKinsey Lilli, wie schnell eine interne AI-Plattform technisch offenstehen kann, wenn APIs, Rechte und Prompts nicht sauber betrieben werden.

Das sind keine sechs getrennten Meldungen.

Das ist eine gemeinsame Verschiebung:

Der unternehmerische Wert wandert vom Modell in die Betriebsschicht.

Nicht das Modell ist der Engpass. Der Engpass ist alles, was ein Agent braucht, um in einer echten Organisation sinnvoll und begrenzt zu arbeiten: Daten, Rechte, Kontext, Workflows, Audit, Kostenkontrolle, Freigaben und Verantwortlichkeit.

Genau deshalb reicht die bisherige, oft pilotprojektbasierte Einkaufslogik nicht mehr.

Der Satz für euer nächstes Vendor-Meeting

Kauft keine Agenten, die ihr nicht betreiben könnt.

Das klingt banal. Ist es nicht.

Viele Organisationen behandeln Agenten gerade wie normale Software: Anbietertermin, Demo, Roadmap, Sicherheitsfragebogen, Pilot, Lizenz, Rollout. Danach merkt man, dass die eigentlichen Fragen nicht beantwortet sind.

Welche Arbeit soll der Agent übernehmen?
Welche Daten darf er sehen?
Welche Aktionen darf er ausführen?
Wer merkt, wenn er falsch liegt?
Wer stoppt ihn, wenn ein Modellupdate sein Verhalten verändert?
Wie kommt ihr wieder heraus, wenn sich der Anbieter, das Preismodell oder eure Strategie ändert?

Bei klassischer SaaS waren diese Fragen wichtig. Bei Agenten sind sie grundlegend. Denn ein Agent zeigt nicht nur Informationen an. Er liest, kombiniert, priorisiert, schreibt, entscheidet vor, ruft Tools auf und kann im nächsten Schritt Arbeit auslösen.

Ein Agent ist kein neues Dashboard.

Ein Agent ist ein Akteur mit Systemzugang. Fragt euch lieber: Welche Informationen, Zielvorgaben und Rechte müsste ein sehr fähiger neuer Mitarbeiter bekommen, um sicher arbeiten zu können, und welche davon darf ein Agent ausdrücklich nicht bekommen?

Die alte Kaufreihenfolge ist falsch herum

Die typische Reihenfolge sieht ungefähr so aus:

Demo ansehen.
Roadmap glauben.
Pilot starten.
Lizenzmodell klären.
Fachbereich begeistern.
Datenschutz, Security, Betriebsrat und Betrieb nachziehen.

Das ist bequem, weil es mit dem Sichtbaren beginnt. Die Demo sieht gut aus. Die Roadmap klingt plausibel. Der Pilot ist klein genug, um niemandem weh zu tun.

Nur ist genau das die Falle.

Agenten werden nicht dadurch riskant, dass sie in einer Demo gut aussehen. Sie werden riskant, wenn sie an echte Daten, echte Rechte und echte Abläufe kommen. Also genau dann, wenn der Pilot von der Bühne in den Maschinenraum wandert.

Die richtige Reihenfolge müsste umgekehrt sein:

Arbeit klären.
Datenfläche begrenzen.
Rechte und Aktionen definieren.
Audit, Evaluation und Aufsicht festlegen.
Exit und Ownership klären.
Dann erst Vendor und Roadmap bewerten.

Das ist weniger glamourös. Aber belastbarer.

Denn bei Agenten ist der Kauf nicht die Entscheidung für ein Tool. Er ist die Entscheidung, ein Stück Arbeit an eine neue Betriebsschicht zu hängen.

Was „betreiben“ hier wirklich heißt

Betreiben heißt nicht nur: Läuft der Dienst stabil?

Das ist die alte IT-Frage.

Bei Agenten heißt betreiben:

Ihr wisst, welche Arbeit delegiert wird.
Ihr wisst, welche Daten dafür nötig sind.
Ihr könnt Zugriffsrechte pro Aufgabe begrenzen.
Ihr habt Logs, die nicht nur hübsch aussehen, sondern forensisch nützlich sind.
Ihr könnt Qualität gegen echte Aufgaben testen.
Ihr kennt die Stelle, an der ein Mensch entscheiden muss.
Ihr habt einen Incident-Prozess, wenn der Agent falsch handelt.
Ihr könnt Agentenlogik, Prompts, Workflows, Evaluationen und relevante Kontexte exportieren oder abschalten.

Das ist Betrieb.

Nicht: Ein Admin kann sich einloggen.

Nicht: Der Anbieter hat SOC 2.

Nicht: Im Vertrag steht „human in the loop“.

Betrieb heißt, dass eure Organisation den Agenten begrenzen, prüfen, verbessern und notfalls wieder loswerden kann.

Wenn ihr das nicht könnt, betreibt ihr ihn nicht. Dann hofft ihr, dass er sich benimmt.

Das ist keine Strategie. Das ist Wetter.

Warum die Milliarden gerade in Deployment fließen

OpenAI und Anthropic investieren nicht zufällig in Deployment-Strukturen, Forward-Deployed-Engineering und Enterprise-Services.

Das ist ein Eingeständnis.

Die Modellanbieter wissen, dass ihre Modelle allein nicht tief genug in Organisationen wirken. Der wirtschaftliche Wert entsteht erst, wenn ein Agent an operative Kontexte kommt: CRM, ERP, Dokumente, Mails, Tickets, Datenbanken, Freigaben, Rollen, Regeln, Prozessausnahmen und implizites Wissen.

Das kann man nicht aus einem Benchmark heraus verkaufen.

Man muss es bauen.

Deshalb entstehen neue Services-Firmen, Partnernetzwerke und Deployment Companies. Nicht, weil alle plötzlich Beratung romantisch finden. Sondern weil die harte Arbeit dort liegt, wo ein Modell auf eine gewachsene Organisation trifft.

Das ist auch der Grund, warum SAP Dremio kauft. Die Pressemitteilung sagt es ziemlich direkt: Enterprise AI scheitert nicht, weil die Modelle zu schwach sind, sondern weil Daten fragmentiert, proprietär eingeschlossen und aus ihrem Geschäftskontext gerissen sind.

Pinecone argumentiert ähnlich, nur auf der Wissensebene. Agenten verschwenden zu viel Laufzeit damit, Kontext immer wieder neu zu suchen, zu lesen und zu sortieren. Nexus soll Wissen vorher in task-spezifische Artefakte verdichten.

Auch das ist dieselbe Botschaft:

Kontext ist nicht Beiwerk. Kontext ist Infrastruktur.

Und wer Kontext zur Infrastruktur macht, muss ihn betreiben.

Der McKinsey-Lilli-Fall ist kein reiner Security-Case

CodeWall beschrieb im März 2026, wie ein autonomer Agent nach eigener Darstellung McKinseys interne AI-Plattform Lilli in unter zwei Stunden kompromittierte. Laut CodeWall fand der Agent öffentlich dokumentierte APIs, 22 unauthentifizierte Endpunkte und eine SQL-Injection über JSON-Feldnamen. Die Plattform enthielt Millionen Chatnachrichten, Dateien, RAG-Chunks, Workspaces, Assistants und System-Prompts.

Die naheliegende Lesart lautet: Security-Fail.

Stimmt. Aber sie greift zu kurz.

Die tiefere Lesart lautet: Betriebsversagen.

Eine Plattform dieser Art ist nicht nur eine Anwendung. Sie ist ein Sammelbecken für strategische Fragen, Kundendaten, interne Recherche, Methoden, Dokumente und Prompt-Logik. Wenn so ein System APIs offenstehen lässt und Prompts in einer beschreibbaren Datenbank liegen, ist das nicht bloß ein Bug.

Dann waren im entscheidenden Moment nicht die richtigen Fragen im Raum.

Welche Endpunkte sind öffentlich?
Welche Aktionen sind unauthentifiziert?
Wo liegen Prompts?
Wer darf sie ändern?
Wie wird Prompt-Integrität überwacht?
Welche Daten liegen im Klartext?
Welche Logs zeigen, was ein Agent wirklich getan hat?

Das sind keine Fragen für nach dem Rollout. Das sind Fragen vor dem Kauf, vor dem Pilot und vor jeder ernsthaften Integration.

Europa macht diese Fragen nicht kleiner

In Europa wird dieser Einkauf nicht einfacher. Er wird härter. Zu Recht.

Sobald ein Agent personenbezogene Daten verarbeitet, Entscheidungen vorbereitet, Arbeit strukturiert oder individuelle Nutzung sichtbar macht, ist er nicht nur Produktivitätswerkzeug. Er wird Governance-Objekt.

Dann hängen plötzlich mehrere Ebenen zusammen:

Datenschutz: Welche Daten werden verarbeitet, gespeichert, ausgewertet oder an Unterauftragsverarbeiter weitergegeben?
AI Act: Wer ist Provider, wer ist Deployer, wer verändert das System wesentlich, welche AI-Literacy-Pflichten entstehen?
Mitbestimmung: Können Verhalten oder Leistung von Beschäftigten beobachtet oder ausgewertet werden?
IT-Sicherheit: Welche Tools darf der Agent aufrufen, welche Daten kann er exfiltrieren, wie werden Prompt Injection und Memory Poisoning getestet?
Betrieb: Wer überwacht Qualität, Fehler, Drift, Kosten und Modellwechsel?

Das ist nicht die deutsche Freude am Verkomplizieren.

Das ist die organisatorische Wahrheit hinter Agenten.

Ein Agent, der tief genug integriert ist, um nützlich zu sein, ist tief genug integriert, um regulierungsrelevant, sicherheitsrelevant und mitbestimmungsrelevant zu werden.

Wer das erst nach dem Pilot klärt, hat den Pilot falsch designt.

Fünf Fragen vor jeder Agentenbeschaffung

Wenn ihr nur eine Handreichung aus diesem Briefing mitnehmt, dann diese:

Vor jeder Agentenbeschaffung müssen fünf Fragen schriftlich beantwortet sein.

1. Welche Arbeit delegieren wir?

Nicht: „Wir wollen Agenten nutzen.“

Sondern: Welche wiederkehrende Arbeit soll besser werden?

Recherche? Briefing? Kundensupport? Kampagnenplanung? CRM-Pflege? Reporting? Angebotsvorbereitung? Code-Änderungen? Rechnungsprüfung?

Wenn die Arbeit nicht benannt ist, kann der Agent nicht sinnvoll begrenzt werden. Dann wird alles zum potenziellen Use Case und nichts zum belastbaren Betrieb.

2. Welche Daten braucht der Agent wirklich?

Nicht: „Der Agent bekommt Zugriff auf den Workspace.“

Sondern: Welche Datenquellen braucht er für diesen konkreten Job?

Mail, Kalender, CRM, DAM, ERP, Website, Analytics, Ticketsystem, Dokumentenablage, Slack, Teams, SharePoint, Google Drive?

Und genauso wichtig: Welche Daten braucht er ausdrücklich nicht?

Ein Agent, der alles sieht, wirkt in der Demo stark. In der Organisation ist er oft nur ein sehr effizienter Verstoß gegen Least Privilege.

3. Welche Rechte und Aktionen sind erlaubt?

Lesen ist etwas anderes als schreiben.

Schreiben ist etwas anderes als senden.

Senden ist etwas anderes als buchen, löschen, veröffentlichen, bestellen oder Kundendaten ändern.

Ihr braucht keine abstrakte Autonomie-Debatte. Ihr braucht eine Aktionsmatrix.

Was darf der Agent allein?

Was darf er nur vorschlagen?

Was braucht Freigabe?

Was darf er nie?

Wenn diese Grenzen nur in einer PowerPoint stehen, existieren sie nicht. Sie müssen technisch durchgesetzt werden.

4. Wer prüft Qualität, Fehler und Drift?

Ein Agent kann heute gut funktionieren und nach einem Modellwechsel anders.

Er kann in einem Team hilfreich sein und in einem anderen gefährlich.

Er kann in Standardfällen sauber arbeiten und in Randfällen systematisch halluzinieren.

Deshalb braucht ihr Evaluationen auf echten Aufgaben, Golden Tasks, Review-Prozesse, Fehlerklassen, Monitoring und einen Ort, an dem Entscheidungen über Weiterbetrieb getroffen werden.

Die Frage ist nicht: Hat der Anbieter Benchmarks?

Die Frage ist: Habt ihr eigene Prüfaufgaben für eure Arbeit?

5. Wie kommen wir wieder heraus?

Exit ist bei Agenten mehr als Datenexport.

Ihr müsst fragen:

Können wir Agentendefinitionen exportieren?

Prompts?

Workflows?

Skills?

Logs?

Evaluationen?

Freigabelogik?

Memory?

Brand Guidelines als ausführbare Arbeitslogik?

Wenn ihr nach zwölf Monaten nur Rohdaten bekommt, aber die gelernte Arbeitsweise im Vendor-System bleibt, ist der Exit formal vorhanden und praktisch schwach.

Der neue Lock-in sitzt nicht nur in der Datei. Er sitzt in der Arbeitsweise.

Was das für euren nächsten Kaufprozess bedeutet

Der Einkauf muss früher in den Maschinenraum.

Nicht, weil Procurement plötzlich Architektur machen soll. Sondern weil die Kaufentscheidung ohne Betriebsbild blind ist.

Ein guter Agentenprozess beginnt nicht mit der Anbieter-Shortlist. Er beginnt mit einem kleinen, gemischten Raum:

Fachbereich, weil dort die Arbeit liegt.
IT und Architektur, weil dort Systeme, Schnittstellen und Betrieb liegen.
Security, weil Agenten neue Angriffsflächen öffnen.
Datenschutz, weil Kontext fast immer personenbezogen werden kann.
Legal und Compliance, weil Rollen, Pflichten und Verträge nicht später vom Himmel fallen.
Betriebsrat, wenn Arbeit, Leistung oder Verhalten berührt werden.
Einkauf, weil genau diese Grenzen in Vertrag, SLA, Exit und Preismodell übersetzt werden müssen.

Das ist nicht langsam. Das verhindert Scheinbeschleunigung.

Schnell ist nicht, wenn ihr in vier Wochen einen Agenten pilotiert und danach sechs Monate Rechte, Logs und Betriebsvereinbarung nachzieht.

Schnell ist, wenn ihr vor dem Kauf wisst, was ihr wirklich kaufen dürft.

Der Test für Anbieter

Ein Anbieter, der Agenten verkaufen will, sollte nicht nur eine Demo zeigen können.

Er sollte diese Fragen beantworten können:

Welche konkreten Arbeitsklassen funktionieren heute produktiv?
Wie werden Daten pro Use Case minimiert?
Wie werden Rechte technisch begrenzt?
Welche Logs bekommt der Kunde?
Welche Aktionen sind freigabepflichtig?
Wie werden Prompt Injection, Tool Misuse und Memory Poisoning getestet?
Was passiert bei Modellwechseln?
Können Kunden eigene Evaluationen fahren?
Welche Artefakte sind exportierbar?
Was wird bei Vertragsende gelöscht, und wie wird das nachgewiesen?

Wenn darauf nur Marketingantworten kommen, wisst ihr genug.

Dann ist das Produkt vielleicht demo-fähig. Aber noch nicht betreibbar.

Schluss

Die nächsten Gewinner im Enterprise-AI-Markt werden nicht nur die besten Modelle haben. Sie werden die besten Wege finden, Modelle an reale Organisationen anzuschließen: an Daten, Rechte, Workflows, Audit und Betrieb.

Für Anbieter ist das die neue Wachstumszone.

Für euch ist es die neue Prüfzone.

Die zentrale Frage lautet nicht mehr: Welcher Agent kann am meisten?

Sie lautet: Welchen Agenten können wir verantworten, begrenzen, prüfen und wieder abschalten?