Ein Marktplatzeintrag ist kein Vertrauensbeweis.

Der Markt für KI-Agenten entwickelt sich rasant.

Agenten werden zu Produkten. Anbieter bündeln spezialisierte Fähigkeiten. Plattformen erleichtern es, Agenten zu finden, anzubinden und einzusetzen. Protokolle wie A2A und MCP verringern Integrationshürden bei Mehragentensystemen und beim Zugriff auf Werkzeuge.

Quellenkontext: MCP · authorization specification · 2026-07-28 ↗ · Agent2Agent · v1.0 specification ↗

Das ist gut für den Markt.

Es schafft aber auch einen gefährlichen Kurzschluss:

Ist ein Agent gelistet, käuflich oder beliebt, könnten Käufer annehmen, dass er bereits geprüft wurde.

Die Präsenz auf einem Marktplatz schafft kein Vertrauen.

Ein seriöser KI-Marktplatz muss mehrere Dinge unterscheiden, die in App-Stores für Verbraucher oft ineinander übergehen:

ENTITÄT Wer oder was ist dieser Agent, dieses System oder dieser Anbieter?

ANGEBOT Was genau wird verkauft oder bereitgestellt, und zu welchen Bedingungen?

BESTELLUNG Welchem Kauf oder welcher Anfrage hat der Kunde zugestimmt?

TRANSAKTION Welcher Zahlungs- oder Abwicklungsvorgang hat stattgefunden?

NUTZUNGSBERECHTIGUNG Welche Zugangs- oder Nutzungsrechte sind entstanden?

EVIDENZ Was stützt wesentliche Aussagen über den Agenten?

ASSURANCE / VERIFICATION Was wurde gegebenenfalls unabhängig beurteilt?

VERTRAUEN Welche Schlussfolgerung ist für diesen konkreten Kontext gerechtfertigt?

Das sind unterschiedliche Objekte.

Eine Zahlung darf niemals Tatsachen darüber schaffen, wie vertrauenswürdig etwas ist.

Stellen Sie sich einen Agenten namens „Procurement Analyst Pro“ vor.

Die kanonische Entität könnte den Anbieter, die Identität des Agenten, seine Versionshistorie und seine technischen Fähigkeiten bezeichnen.

Ein kommerzielles Angebot könnte davon getrennt Folgendes festlegen:

• Preis;
• Abonnement- oder Nutzungsmodell;
• geografischer Geltungsbereich;
• Service Level;
• enthaltene Werkzeuge und Konnektoren;
• Lizenzbedingungen;
• Umgang mit Daten;
• Support;
• Kapazität;
• Verfügbarkeit;
• Bedingungen für Zugangs- und Nutzungsrechte.

Das Angebot kann sich ändern, ohne dass sich die zugrunde liegende Entität ändert.

Die Entität kann eine neue Version erhalten, ohne dass sich dadurch automatisch eine unterzeichnete kommerzielle Bestellung ändert.

Diese Objekte getrennt zu halten, ist entscheidend für die Nachvollziehbarkeit.

Die meisten Marktplätze beginnen mit Produkten.

Bei KI ist das oft die falsche Reihenfolge.

Ein geschäftlicher Käufer wacht nicht mit dem Wunsch nach „Agent X“ auf.

Er möchte die Kosten im Kundenservice senken, einen administrativen Ablauf automatisieren, die Informationsbasis für den Vertrieb verbessern, Forschung auswerten, Risiken beobachten oder eine neue KI-gestützte Dienstleistung aufbauen.

Ein besserer Weg beginnt so:

MISSION / BEDARF → ANFORDERUNGEN AN DIE FÄHIGKEITEN → KANDIDATEN → VERGLEICHEN → EVIDENZ PRÜFEN → KOMMERZIELLES ANGEBOT → ANFRAGEN / KAUFEN / ANBINDEN → PROJEKT → BETREIBEN / BEOBACHTEN.

Das macht aus einem Marktplatz mehr als einen Katalog: eine Umgebung für Entscheidungen.

Ein Vergleich von KI-Agenten sollte sich nicht allein auf Folgendes beschränken:

Funktionen Preis Bewertungen Beliebtheit.

Für Entscheidungen relevante Dimensionen können sein:

FÄHIGKEITEN Welche Aufgaben kann der Agent tatsächlich ausführen?

KONTEXT Mit welchen Daten, Systemen und Arbeitsabläufen kann er arbeiten?

BEFUGNISSE Welche Handlungen kann er ausführen, und wie lassen sich Berechtigungen begrenzen?

EVIDENZ Welche Dokumentationen, Evaluationen, Sicherheitsnachweise, System Cards oder unabhängigen Quellen gibt es?

DATEN Welche Daten liest er, welche speichert er, und welche verwendet er für das Training?

SICHERHEIT Wie werden Identität, Geheimnisse, Werkzeuge und Mandantengrenzen behandelt?

INTEROPERABILITÄT Welche Protokolle, APIs und Werkzeugökosysteme unterstützt er?

WIRTSCHAFTLICHKEIT Wie hoch sind die Gesamtkosten einschließlich aller relevanten Bestandteile – und nicht nur der ausgewiesene Preis?

VERÄNDERUNG Wie werden neue Versionen, Modell- oder Anbieterwechsel und Vorfälle kommuniziert?

AUSSTIEG Kann der Kunde wechseln, ohne das gesamte Betriebssystem neu aufzubauen?

Das Ergebnis sollte nicht lauten: „Agent A ist zu 87 % vertrauenswürdig.“

Es sollte dem Käufer helfen, Zielkonflikte und offene Fragen zu verstehen.

Ein Marktplatz kann einen Agenten verkaufen.

Er kann eine Assurance-Dienstleistung verkaufen.

Er kann Unterstützung bei der Implementierung verkaufen.

Er kann Monitoring verkaufen.

Aber eine Geschäftsbeziehung darf nicht stillschweigend zu einer günstigen Vertrauensbewertung führen.

Deshalb hält die Architektur von ETHORITY kommerzielle Tatsachen und Tatsachen über Vertrauen und Evidenz getrennt.

Ein Anbieter kann Angaben zu seinem Angebot machen. Bis sie angemessen belegt sind, bleiben diese Angaben Aussagen einer Quelle.

Ein Kunde kann einen Agenten kaufen. Die Zahlung belegt eine Transaktion, nicht die Eignung.

ETHORITY kann Evidenz bewerten. Verification bleibt dort, wo sie angeboten wird, ein gesonderter Prozess mit eigener Zuständigkeit.

Der Kauf eines leistungsfähigen Agenten bedeutet nicht, dass die Organisation ihn mit maximalen Berechtigungen einsetzen sollte.

Auch nach dem Kauf muss die Organisation entscheiden:

Welche Mission unterstützt er? Auf welche Daten darf er zugreifen? Welche Werkzeuge darf er aufrufen? Welche Handlungen darf er vorbereiten? Welche Handlungen darf er ausführen? Welche Grenzen gelten? Welche Handlungen erfordern eine menschliche Freigabe? Was geschieht, wenn Befugnisse ablaufen oder widerrufen werden?

Die Beschaffung über einen Marktplatz ist deshalb der Beginn von Governance – nicht ihr Ende.

Bevor ein allgemeiner Marktplatz mit mehreren Parteien in Betrieb ist, kann ein Produktteam die Kundenreise dennoch mit eindeutig gekennzeichneten synthetischen kommerziellen Daten demonstrieren.

Northstar, eine synthetische Organisation, könnte beispielsweise die Mission haben, die Kosten im Kundenservice zu senken.

ETHORITY könnte Folgendes zeigen:

Anforderung aus der Mission → mögliche Agenten- und Systemansätze → Vergleich → Evidenzlücken → synthetische Angebotsbedingungen → Kandidaten zum Projekt hinzufügen → Informationen beim Anbieter anfragen.

Die synthetischen Bestandteile müssen unmissverständlich gekennzeichnet sein.

Erfinden Sie weder den Preis noch ein SLA, eine Empfehlung oder die Verfügbarkeit eines realen Anbieters.

So lässt sich die Marktplatzerfahrung testen, ohne vorzugeben, dass die Transaktionswirtschaft bereits in Betrieb ist.

Der Kauf eines Abonnements begründet eine Geschäftsbeziehung. Er erlaubt dem Produkt nicht automatisch, sämtliche Unterlagen zu lesen oder für alle Beschäftigten zu handeln. Einkauf und Einsatz sind verbundene Entscheidungen mit unterschiedlichen Verantwortlichen. Der Einkauf klärt Produkt, Bedingungen und Lieferant. Die Prozessverantwortlichen bestimmen den betrieblichen Handlungsspielraum. Sicherheit, Datenschutz und Recht bringen ihre jeweilige fachliche Zuständigkeit ein.

Beginnen Sie die Anbieteranfrage mit der Aufgabe statt mit dem Begriff „KI-Agent“. Beschreiben Sie Eingangsdaten, benötigtes Ergebnis, Empfänger und Handlungen, die beim Menschen bleiben. Ein verlässlicher Entwurfsassistent kann besser passen als ein Produkt mit größerer Autonomie. Vielleicht reicht eine feste Regel oder eine Funktion vorhandener Software. Die Anfrage sollte solche Antworten zulassen, statt vor der Problembetrachtung einen neuen Agenten vorauszusetzen.

Trennen Sie Systemidentität und kaufmännisches Paket. Ein Lieferant kann mehrere Produkte verkaufen; ein Produkt kann über unterschiedliche Plattformen und Verträge bereitgestellt werden. Der Unternehmensname allein belegt weder Hosting noch Aufbewahrung oder den Umfang einer Zertifizierung. Eine stabile Produktidentität macht den Vergleich nützlich. Erst die gewählte Bereitstellung macht die Angaben für den konkreten Einsatz anwendbar.

„Ist Ihr Agent vertrauenswürdig?“ lädt zu einer allgemeinen Zusicherung ein. „Erlaubt unser ausgewählter Tarif die Verarbeitung von Kundendaten ausschließlich in der genannten Region, und welche Bedingungen belegen das?“ verlangt eine konkrete Antwort. Fragen Sie nach Punkten, die über den geplanten Ablauf entscheiden. Interessante Funktionen ohne Einfluss auf diese Entscheidung können in einer getrennten Liste bleiben.

Für einen Serviceprozess sind etwa Datennutzung, Aufbewahrung und Löschung, Anmeldung, menschliche Prüfung und vollständige Abrechnungsgrundlage relevant. Klären Sie, ob eine Aussage standardmäßig gilt, konfiguriert werden muss oder eine zusätzliche Vereinbarung benötigt. Eine innerhalb der Produktfamilie verfügbare Fähigkeit ist nicht zwingend Bestandteil des betrachteten Angebots.

Erhalten Sie wesentliche Widersprüche. Beschreiben Produktseite und Vertrag scheinbar unterschiedliche Bedingungen, zeigen Sie beide Quellen und bitten um Klärung. Ein Käufer sollte diese Frage aus einem öffentlichen Profil in den Vergleich und anschließend in die Anfrage mitnehmen können. Eine übersichtliche Oberfläche macht die Frage leichter bearbeitbar. Sie entfernt sie nicht, damit der Anbieter einfacher wirkt.

Vereinbaren Sie auch, wer eine Antwort prüft und was als ausreichend gilt. Ein Vertriebsversprechen kann einen Gesprächsbedarf klären, ersetzt aber nicht in jedem Fall die maßgebliche vertragliche Bestätigung. Umgekehrt muss nicht jede nebensächliche Funktion einen juristischen Prüfprozess auslösen. Die Tiefe folgt der Bedeutung für Daten, Handlung und Geschäftsentscheidung.

Leiten Sie Fälle aus der wichtigen Arbeit ab. Dazu gehören Standardanfrage, Mehrdeutigkeit, fehlende Informationen, widersprüchliche Quellen, eine unerlaubte Handlung und eine Anfrage außerhalb des vorgesehenen Zwecks. Legen Sie je Fall das gute Ergebnis fest. Manchmal ist eine Eskalation oder eine verweigerte Handlung richtig. Eine Erfolgsdefinition, die immer eine flüssige Erledigung verlangt, setzt den falschen Anreiz.

Bei einem hypothetischen Rückgabeassistenten kann ein schwieriger Fall einen gültigen Kauf und widersprüchliche Liefernachweise enthalten. Der Assistent sollte die Abweichung finden und eine Prüfung vorbereiten, statt selbst einen Erstattungsanspruch abzuleiten. Ein anderer Test untersucht versteckte Anweisungen in Lieferantendokumenten. Ein weiterer prüft, ob eine wiederholte Anfrage eine doppelte Transaktion erzeugt. Diese Fälle betreffen unterschiedliche Eigenschaften und bleiben getrennt nachvollziehbar.

Dokumentieren Sie Konfiguration, Modellfassung, Datenquellen und menschlichen Prüfaufwand. Eine vom Anbieter geführte Vorführung und ein eigener Test können beide hilfreich sein. Sie sind jedoch keine gleichwertigen Nachweise. Die Bedingungen gehören zum Ergebnis. Synthetische Daten erlauben Verhaltensprüfungen, ohne damit die Qualität sämtlicher Produktionsverbindungen zu belegen.

Bestimmen Sie das Arbeitsvolumen und die Kosten akzeptierter Arbeit. Dazu zählen Abonnement, Nutzung, Einführung, weitere Systeme, menschliche Prüfung und Ausnahmebearbeitung. Wird pro gelöstem Fall abgerechnet, prüfen Sie die vertragliche Definition der Lösung. Bei Nutzerpreisen muss klar sein, welche Beschäftigten und Administratoren eine Lizenz benötigen. Eine Jahresbindung ist von einem monatlich kündbaren Preis zu unterscheiden.

Rechnen Sie mit niedriger, erwarteter und hoher Auslastung. Ein attraktiver Pilotpreis kann auf Kontingenten beruhen, die später nicht gelten. Ein höherer Festpreis kann bei großer stabiler Nachfrage wirtschaftlicher sein. Ziel ist nicht die billigste angezeigte Zahl, sondern dieselbe Arbeit unter sichtbaren Bedingungen. Die Wirtschaftlichkeitswerkzeuge prüfen Annahmen und versprechen keine Einsparung.

Fragen Sie auch nach dem Ausstieg. Lassen sich Quelldokumente, Entscheidungsunterlagen und Konfiguration exportieren? Wer bearbeitet offene Handlungen nach dem Zugangsende? Übertragbarkeit ist keine unbestimmte Zukunftsfrage. Sie entscheidet mit darüber, wie viel gelerntes Organisationswissen bei Anbieterwechsel oder Projektende nutzbar bleibt.

Ein realistischer Vergleich betrachtet außerdem den Übergang. Eine neue Lösung kann zeitweise neben der bisherigen betrieben werden müssen. Datenprüfung, Schulung und parallele Unterstützung verursachen Aufwand. Diese Kosten sollten mit Zeitraum und Annahme in der Rechnung stehen. Sie werden weder pauschal als Dauerlast behandelt noch aus der Betrachtung entfernt, weil sie nur einmal auftreten.

Ein Anbieter kann für Profilpflege, Forschungsarbeit oder einen anderen kommerziellen Liefergegenstand bezahlen. Er kauft damit weder redaktionelle Aufnahme noch eine günstige Bewertung, unabhängige Verifizierung oder Rang. Dieselbe Trennung schützt Käufer: Beratung kann eine Entscheidung strukturieren, macht das betrachtete Produkt aber nicht allgemein vertrauenswürdig. Maßgeblich sind Liefergegenstand und Nachweisgrundlage, nicht die Zahlung an sich.

Das Good AI Prisma dient Recherche und Vergleich. Öffentliche Profile enthalten belegte Angaben und wesentliche Rückfragen. Sie sind keine Einsatzfreigaben. Eine fiktive Workspace-Demonstration zeigt zusammenhängende Unterlagen und Abläufe. Ihr ausgewiesener Umfang ist weder ein Nachweis einer produktiven Kundeninstallation noch einer erfolgreich erfüllten Bestellung.

Lassen Sie vor der Unterschrift die künftige Betriebsverantwortung die erste Nutzungswoche durchgehen. Welche Konten werden angelegt, welche Unterlagen verbunden und welche Handlungen bleiben gesperrt? Bestimmen Sie das erste akzeptable Ergebnis und die Person, die es bestätigt. So werden Lücken zwischen der kaufmännischen Anbieterleistung und den eigenen Einführungsaufgaben sichtbar.

Betrachten Sie anschließend den ersten Fehler. Für eine fehlende Quelle, eine falsche Antwort oder eine ausgefallene Schnittstelle braucht es einen praktischen Unterstützungsweg. Klären Sie Empfänger und benötigte Nachweise. Ein Supportvertrag übernimmt nicht automatisch die Verantwortung für interne Berechtigungen oder Geschäftsentscheidungen. Der Kauf ist besser vorbereitet, wenn beide Seiten die Grenze konkret erklären können. Ein allgemeines Serviceversprechen ersetzt diese Zuordnung nicht. Halten Sie sie so fest, dass sie auch nach einem Wechsel im Projektteam noch nutzbar bleibt.

Für einen begrenzten Vergleich können Sie den AI Decision Brief prüfen. Soll die Grundlage eines ausgewählten Systems geordnet werden, ist der AI Trust Record relevant. Eine kontrollierte Erprobung wird gesondert im AI Trust Pilot vereinbart. Halten Sie diese Zwecke auseinander. Nicht jede Anfrage muss ein großes Transformationsprogramm beginnen.

Eine gute Anfrage nennt Geschäftsfrage, ausgewählte Produkte, Annahmen und die Information, die die Entscheidung verändern würde. Eine vorbereitete E-Mail ist nicht versandt; eine Umfangsanfrage ist kein bezahlter Auftrag. Das sinnvolle Einkaufsergebnis ist eine begründete Wahl mit Bedingungen, verantwortlicher Person und einem Anlass zur erneuten Prüfung bei veränderten Tatsachen.

Die langfristige Chance liegt nicht in einem weiteren App-Store.

Sie liegt in einem lebendigen Entscheidungsnetzwerk.

Ein Kandidat im Marketplace kann mit Folgendem verbunden werden:

Prism und Navigator unterstützen die Markterkundung. Profiles und Compare bewahren den Quellenkontext. Enterprise Services und Transformation bearbeiten eine vereinbarte geschäftliche Frage. AI Estate verbindet das Inventar der Organisation, Verantwortliche, Evidenz und betriebliche Entscheidungen. Trust Infrastructure beschreibt einen gesonderten Architektur- und Forschungsumfang. Verfügbarkeit und Verantwortung werden für jedes Engagement vereinbart.

Dann kann der Marktplatz eine deutlich bessere Frage beantworten als:

„Welche Agenten gibt es?“

Er kann helfen, diese Frage zu beantworten:

„Welche KI-Fähigkeit passt zu dieser Mission, unter welchen kommerziellen Bedingungen und mit welchen Befugnissen, auf Grundlage welcher Belege – und was sollten wir nach der Auswahl beobachten?“

An diesem Punkt wird ein KI-Marktplatz zur Infrastruktur für die KI-Wirtschaft.