KI im Vertrieb: CRM-Rechte und Übergaben

KI im Vertrieb braucht einen klaren Zugriff auf die tatsächlich benötigten CRM-Daten und eine Freigabe für Änderungen oder Nachrichten. Eine Zusammenfassung eines vorhandenen Vorgangs ist eine andere Aufgabe als das Anlegen eines Datensatzes oder der Versand an einen Kontakt. Der Unterschied muss sowohl im Auftrag als auch in den Berechtigungen des angeschlossenen Dienstes sichtbar sein. Ein Modell kann aus einem lesenden Zugang keine technische Schreibberechtigung ableiten.

Scopes legen Datenzugriffe am Endpunkt fest#

HubSpot beschreibt Scopes (Stand 3. Oktober 2026) als Berechtigungen für bestimmte API-Endpunkte und die damit verbundenen Kontodaten. Welche Scopes ein konkreter Aufruf verlangt, steht laut Dokumentation am jeweiligen Endpunkt unter Required Scopes oder im entsprechenden Abschnitt des API-Guides. Für einen vorhandenen Account müssen außerdem die verfügbaren Produktfunktionen berücksichtigt werden. Ein Scope und der gebuchte Tarif sind unterschiedliche Voraussetzungen.

Bei einer App-Konfiguration unterscheidet die Dokumentation drei Arten. Erforderliche Scopes müssen für die Installation autorisiert und in der Installationsadresse enthalten sein. Bedingt erforderliche Scopes sind nur nötig, wenn sie in dieser Adresse stehen. Optionale Scopes werden gesondert angeboten und sind für eine erfolgreiche Installation nicht verpflichtend. Bedingte und optionale Scopes werden für OAuth-Apps beschrieben; Apps mit statischer Authentifizierung können nur erforderliche Scopes definieren.

Die Dokumentation nennt crm.objects.custom.read als Beispiel für einen optionalen Zugriff auf benutzerdefinierte Objekte. Sie verweist dabei auf deren Verfügbarkeit in Enterprise-Konten. Daraus lässt sich kein allgemeiner Pflichtscope für jede Vertriebsaufgabe ableiten. Die passende Berechtigung wird für den ausgewählten Datentyp und den konkreten Endpunkt bestimmt.

Ordne die Aufgabe vor der Einrichtung einem API-Aufruf zu: Welches Objekt wird gelesen, welche Daten werden zurückgegeben und welcher Scope ist dafür vorgesehen? Die Beschreibung „Zugriff auf das CRM“ ist dafür zu grob. Sie lässt offen, ob der Agent einen einzelnen Vorgang zusammenfasst oder weitreichende Bestände abrufen kann. Das MCP-Verzeichnis hilft bei der Auswahl einer Verbindung; der konkrete Endpunkt und seine Rechte bleiben separat zu prüfen.

Die Objektschnittstelle kann Felder gezielt zurückgeben#

Die HubSpot-Anleitung zu Objekt-APIs (Stand 3. Oktober 2026) unterscheidet einzelne Datensätze, Listen und Stapelabfragen. Ein einzelner Datensatz wird über GET /crm/v3/objects/{objectTypeId}/{recordId} abgerufen. Die Platzhalter stehen für Objekttyp und Datensatz. Das ist ein Leseaufruf und keine Anweisung zum Ändern des Vorgangs.

Der Parameter properties bestimmt, welche Eigenschaften zurückkommen. propertiesWithHistory kann aktuelle und historische Werte anfordern. Hat ein Datensatz für eine angeforderte Eigenschaft keinen Wert, erscheint diese Eigenschaft laut Dokumentation nicht in der Antwort. Für eine Zusammenfassung darf daher ein fehlendes Feld nicht automatisch als bestätigtes Nein oder als Nullbetrag behandelt werden.

Die Anleitung zeigt außerdem associations zum Abruf zugeordneter Datensatz-IDs. Dieser Parameter wird beim Batch-Leseendpunkt nicht unterstützt. Eine einzelne Anfrage und eine Stapelabfrage liefern somit nicht zwangsläufig dieselben Verknüpfungen. Wer einen Kundenkontakt und den zugehörigen Vorgang gemeinsam darstellen möchte, muss diesen Unterschied im Datenabruf berücksichtigen.

Ein eigener Entwurf für eine Vorbereitung auf ein Gespräch könnte zunächst nur die benötigten Eigenschaften eines freigegebenen Vorgangs verwenden. Die Abnahme prüft dann, ob die Zusammenfassung vorhandene Werte richtig wiedergibt und Lücken erkennbar lässt. Werden später historische Werte ergänzt, kommt eine weitere Frage hinzu: Bezieht sich die Aussage auf den aktuellen Stand oder auf eine frühere Änderung? Eine gut klingende Zusammenfassung kann sonst unterschiedliche Zeitpunkte vermischen.

Ein Entwurf benötigt andere Rechte als eine Änderung#

Die Objekt-API beschreibt neben dem Lesen auch das Erstellen und Aktualisieren von Datensätzen. Für die Auswahl eines Anschlusses ist daher die konkrete Funktion wichtig. Ein Tool, das eine Zusammenfassung ausgibt, hat eine andere Außenwirkung als ein Tool, das einen Deal verändert. Dokumentiere zum Aufgabennamen die tatsächlich verwendete API-Methode.

Lege die Zugriffsrechte für jede Teilaufgabe getrennt fest. Den konkreten Scope entnimmst du der Dokumentation des tatsächlich verwendeten Endpunkts; Lesen und Schreiben können verschiedene Rechte benötigen.

Für die erste Aufgabe ist ein schreibendes Werkzeug nicht nötig. Bei der dritten Aufgabe muss die Prüfung hingegen genau den Datensatz und den neuen Wert sehen können. Ein vorher freigegebener Text ersetzt diese Prüfung nicht. Ebenso muss ein Fehler im Datenabruf erkennbar bleiben: Aus einer fehlgeschlagenen Abfrage darf keine bestätigte Aussage über einen Kunden entstehen.

Bei der Übertragung an einen Modelldienst kommen dessen Vertrags- und Datenbedingungen hinzu. Der Datenschutzvergleich unterscheidet Trainingsnutzung, Aufbewahrung und regionale Verarbeitung. Ein korrekter HubSpot-Scope beantwortet diese Fragen beim nachgelagerten Dienst nicht.

Das Webhook-Journal ist kein vollständiges eigenes Protokoll#

Das HubSpot Webhooks Journal ist in der Originaldokumentation als Beta beschrieben. Es bietet historische Ereignisdaten für Änderungen an bestehenden Abonnements aus den vergangenen drei Tagen. Die Daten werden chronologisch über ein Offset-System abgefragt. Ein solches Journal hilft beim Nachverfolgen von Änderungen, ist aber kein unbegrenzt zurückreichendes Archiv aller CRM-Aktionen.

Für das Lesen nennt die Dokumentation developer.webhooks_journal.read. Der früheste Eintrag wird unter /webhooks-journal/journal/v4/earliest abgefragt, der nächste Eintrag anhand des vorherigen Offsets. Zusätzlich werden Scopes für die Objekttypen benötigt, deren Ereignisse abonniert werden. Die Journal-Seite nennt für Kontaktänderungen ihr konkretes Scope-Beispiel; dieses darf nicht ohne Prüfung als allgemeine Berechtigungsformel für andere Endpunkte verwendet werden.

Die Antwort enthält unter anderem eine Adresse für die Journaldatei und deren Ablaufzeit. Für einen eigenen Nachweis genügt deshalb nicht, nur eine kurzlebige Adresse in einem Protokoll zu speichern. Ebenso bleibt offen, welcher Mensch einen Werkzeugaufruf freigegeben hat, wenn diese Information nicht Teil des erfassten Ereignisses ist. Der eigene Freigabenachweis und das Journal dokumentieren verschiedene Vorgänge.

Die Beta-Dokumentation nennt außerdem getrennte Ratenlimits und eine Antwort mit Status 429 sowie Retry-After, wenn diese Grenzen überschritten werden. Die Grenzen können sich laut Seite während der Beta ändern. Eine Abfrage muss Fehler und Wiederholungen deshalb behandeln können; eine fehlende Journalantwort ist nicht gleichbedeutend mit dem Ausbleiben einer Änderung.

Was muss vor einer Aktion sichtbar sein?#

Die n8n-Anleitung zur Werkzeugfreigabe beschreibt eine menschliche Prüfung vor dem Aufruf eines ausgewählten Werkzeugs. Die prüfende Person sieht, welches Werkzeug verwendet werden soll und mit welchen Parametern. Zustimmung führt den Aufruf mit diesen Angaben aus. Ablehnung bricht die Aktion ab und informiert den Agenten. Ein Versandkanal und ein Freigabekanal können dabei verschieden sein.

Für eine Vertriebsnachricht zählen vor der Freigabe der Empfänger, der Inhalt und gegebenenfalls eine konkrete Zusage. Ein allgemeines „Antwort passt“ ist weniger aussagekräftig als die Prüfung des angeforderten Aufrufs. Wird nach einer Ablehnung ein neuer Entwurf erstellt, entsteht auch ein neuer Versandauftrag. Der Ablauf sollte ihn nicht stillschweigend mit der vorherigen Entscheidung gleichsetzen. Der n8n-Ratgeber führt diese Trennung am Lernbeispiel aus.

OWASP LLM01:2025 beschreibt zudem, wie fremde Eingaben oder Dokumente das Verhalten eines Modells umlenken können. Ein CRM-Eintrag mit fremdem Nachrichtentext ist daher eine Datenquelle, keine Berechtigung, neue Aktionen auszuführen. Ein begrenzter Datenzugriff und eine Prüfung vor der Außenwirkung können Folgen einschränken; sie garantieren keine vollständige Erkennung jeder Eingabemanipulation. Die technische Verbindung sollte die geplante Aufgabe unterstützen, ohne ihr vorsorglich weitergehende Handlungen zu eröffnen.