Salesforce AIforce: CRM stirbt als UI — ohne Skill-Audit bleibt der Beleg weg

Salesforce AIforce bringt CRM-Kontext nach Claude, Slack und Coworker — das System of Record bleibt. Ohne Audit und Revocation für Skill-Scopes ist der Checkout ohne Beleg. Klartext für Teams, die Salesforce und AIforce ernst nehmen.

Max-These, nicht Salesforce-Wortlaut: Das CRM stirbt als UI — nicht als System of Record. Ohne Audit und Revocation für Skill-Scopes ist AIforce ein Checkout ohne Beleg. Interfaces in Claude, Slack und Coworker sind praktisch. Die harte Wahrheit: Wer Skills und Agent-Rechte nicht scoped, geloggt und widerrufbar hält, hat Governance nur in der Pressemitteilung. Fordern Sie eine Scope-Liste, einen Revocation-Pfad und die Antwort, wer den Beleg liest. Punkt.

Das ist die Linie dieses Texts. Die Linie steht so nicht in der Salesforce-Story. Salesforce beschreibt eine Live-Interface-Schicht, Permissions, Zero Data Retention als Claim und Surfaces. Die These, dass das CRM als Oberfläche schrumpft, während das System of Record bleibt, und dass ungeprüfte Skill-Scopes Checkout ohne Beleg sind, stammt von hier. Wer beides in einem Satz vermischt, baut eine Folie, die in der Rückfrage zerbricht.

Am 15.9.2026 hat Salesforce auf der Dreamforce AIforce vorgestellt. Laut der Salesforce-Story ist AIforce eine Live-Interface-Schicht, die Salesforce-Kontext — Daten, Workflows, Geschäftslogik, Semantik, Permissions, Security und Governance — an beliebige KI-Interfaces bringt. Start mit Claudeforce, Slackforce und Agentforce Coworker; weitere Surfaces angekündigt. Die Einzelheiten stehen in der Salesforce-Story zu AIforce vom 15.9.2026.

Hand aufs Herz: Viele Lenkungskreise hören bei so einer Meldung nur „Salesforce kommt zu uns“. Claude. Slack. Lightning. Genau dort fängt der Fehler an. Wer den Beleg für Skill-Scopes nicht liest, hat keinen Beleg. Herzlichen Glückwunsch.

Salesforce AIforce: CRM bleibt SoR, die UI wandert

Der Mythos klingt bequem. Das CRM-Fenster sei tot, also sei das CRM tot. Falsch. Was stirbt, ist die Erwartung, dass Arbeit nur noch in festen Layouts und Feldlisten stattfindet. Was bleibt, ist das System of Record: Datensätze, Regeln, Permissions, Semantik. Salesforce formuliert AIforce so: Menschen müssen nicht mehr zu Salesforce kommen, um Arbeit zu erledigen — Salesforce kommt zu ihnen, in Claude, Slack, Lightning oder wo sie arbeiten wollen. Das ist Salesforce-Framing. Keine Arbeitsplatzstudie, die wir in Auftrag gegeben hätten. Eine Richtung, kein Messwert für Ihre Org.

Die harte Wahrheit sitzt daneben. Wenn Agenten und Menschen Datensätze lesen, aktualisieren und Workflows anstoßen, ohne dass jemand später sagen kann, welcher Skill welche Aktion mit welchem Scope ausgeführt hat, dann ist das kein Fortschritt. Das ist ein Checkout ohne Beleg. Meine Einschätzung: Wer AIforce nur als Komfortfeature verkauft und Scope, Log und Widerruf auf später verschiebt, baut Schulden in der Governance. Schulden, die in der Revision teurer werden als jedes fehlende Dashboard.

Würden Sie eine Bestellung freigeben, bei der niemand den Kassenzettel speichert und niemand weiß, wer die Karte sperren darf?

Genau. Dann lassen Sie Skills nicht ungescoped. Lassen Sie Revocation nicht „irgendwann“. Und lassen Sie den Beleg nicht bei der Person, die ihn nie öffnet.

AIforce und CRM-Kontext: was Salesforce claimt

Laut Salesforce macht AIforce Interfaces intelligent und dynamisch; sicher und governed über bestehende Permissions — der Agent sehe nur, was die anfragende Person sehen darf, Aktionen liefen über Salesforce zurück; komponierbar; mit Zero Data Retention beim Modell-Anbieter; und sie arbeiteten mit dem, was schon da ist — kein neues Permissions-Modell, keine Migration, Admins verbinden einmal. Zero Data Retention ist in diesem Text ein Salesforce-Claim, kein von uns nachgemessener Betriebsbefund. Permissions-Routing ist ebenfalls Salesforce-Beschreibung. Ob Ihre Org das in der Praxis so sieht, hängt von Konfiguration, Skill-Katalog und Audit ab — nicht von der Folie.

Die Architektur-Schicht nennt Salesforce kurz so: Data 360 für vereinheitlichten Kontext; Customer 360 für Anwendung und Semantik; Agentforce als digitale Workforce; und nun AIforce, das diese Grundlage an beliebige KI-Interfaces bringt. Stack-Namen sind Produktlabels. Sie ersetzen keine Scope-Liste.

Marc Benioff, Chair und CEO von Salesforce, wird in der Story so zitiert:

AI is creating an interface revolution… combining model intelligence with all the context… securely governed, built with Zero Data Retention, designed to work with the core systems that already run your business.

Marc Benioff, Chair and CEO, Salesforce

Sinngemäß, vorsichtig paraphrasiert, keine Erweiterung: KI erzeuge eine Interface-Revolution. Man kombiniere Modell-Intelligenz mit dem Kontext, den Kundschaft in Salesforce aufgebaut habe, zu einem intelligenten, dynamischen, komponierbaren System — sicher governed, gebaut mit Zero Data Retention, ausgelegt auf die Kernsysteme, die das Geschäft schon tragen. Zero Data Retention bleibt Claim der Quelle. „Sicher governed“ bleibt Claim der Quelle. Beides ist kein Ersatz für Ihren Skill-Audit.

Seien wir ehrlich: Eine Pressemitteilung kann Permissions und ZDR hervorragend beschreiben. Sie kann nicht für Sie prüfen, welche der 37 Sales-Skills in Claude welche Schreibrechte tragen und wer sie morgen widerruft.

Claudeforce: 37 Sales-Skills und der fehlende Beleg

Claudeforce erweitert laut Salesforce die Partnerschaft mit Anthropic. Salesforce in Claude kommt über einen vorgebauten MCP-Server, ohne manuelles Setup, komplexe Authentifizierung und Custom-Skill-Mapping, wie es solche Integrationen sonst oft verlangen — so die Salesforce-Beschreibung. Darin: 37 vorgebaute Sales-Skills, von Prospecting bis Pipeline-Hygiene. In naher Zukunft Tableau-Analytics sowie Skills für Service, Marketing, Commerce und Industries. Für Buildende: Salesforce Development Plug-in für Claude Code mit mehr als 40 Skills, Zugriff auf die Skills-Bibliothek auf GitHub und dynamisch geladene Sub-Plug-ins. Salesforce in Claude sei bei Deloitte, GitLab und Legora pilothaft gelaufen und stehe Kundschaft in der Beta offen. Alle Zahlen und Namen: Salesforce-Claims bzw. Salesforce-Nennungen. Keine unabhängige dm-Messung der Skill-Wirkung.

37 Skills klingen nach Tempo. Tempo ohne Scope-Liste ist Tempo ohne Bremse. Was Teams auditen müssen: Welche Skills lesen, welche schreiben? Welche Felder? Welche Objekte? Gibt es einen Revocation-Pfad pro Skill, pro Rolle, pro Surface? Wer liest den Beleg — Security, Admin, Audit, oder niemand?

Meine zweite Einschätzung: Wer in Claude Salesforce-Kontext freischaltet und den Skill-Katalog wie eine Feature-Liste behandelt, verwechselt Produktivität mit Mandat. Ein Skill, der Pipeline-Hygiene „macht“, braucht denselben Respekt wie ein Button, der Datensätze massenhaft ändert — nur dass der Button früher wenigstens in der UI sichtbar war.

Wir bei digital-magazin.de sortieren Agententhemen nach Mandat, Handoff und Freigabe, nicht nach Modellnamen. Dasselbe Muster — wann ein Agent ein Mandat hat und wann die Grenze gezogen wird — liegt im Text zu Agentforce-Workflows und Ticket-Handoff. Das ist eine Parallel zur Governance, nicht das Thema dieser Zeilen. Hier zählt der Skill-Scope in AIforce-Surfaces, nicht der allgemeine Ticket-Katalog.

Slackforce: Surfaces, Slackbot, CRM im Chat

Slackforce bringt laut Salesforce den Kontext von Salesforce in Gespräche, Workflows und Erlebnisse in Slack. Slackforce Surfaces: Live-Interfaces aus relevantem Kontext und Daten aus Salesforce, Slack und anderen Werkzeugen — filterbar, kommentierbar, gemeinsam nutzbar. Slackbot mit Salesforce-Kontext: Salesforce nennt als Beispiel, dass Slackbot ruhige Accounts surfacing könne, Support-Fälle und Slack-Threads lese, Ownership neu zuweisen, Tasks anlegen und eine Win-back-Mail entwerfen könne — alles aus Slack. Das ist ein Salesforce-Beispiel, kein von uns verifiziertes Reporting aus einer Kundenorg. Slack CRM: per Prompt Account anlegen, Notizen loggen, Datensätze aktualisieren, ohne separates CRM-Fenster. Slack Code: Multiplayer-Coding in Slack, Arbeit offen, Output als Code, Prototypen, Dokumente.

Praktisch? Ja. Ungefährlich ohne Beleg? Nein. Wenn ein Prompt in Slack einen Account anlegt oder Ownership verschiebt, ist das eine schreibende Aktion im System of Record. Die UI ist weg. Die Verantwortung bleibt. Wer den Chat als „nur Kommunikation“ liest, liest falsch.

Optional und klar als Salesforce-veröffentlichte Kundenstimme: Elia Wallen, Founder und CEO von Engine, wird in der Story sinngemäß so wiedergegeben: Engine bearbeite über 800.000 Kundenanfragen pro Jahr; schneller Kontext sei entscheidend; Slackforce mache möglich, dass Teams beschreiben, was sie brauchen, und eine arbeitende Interface-Oberfläche aus vorhandenen Daten zurückbekommen — ohne die Konversation zu verlassen. Die 800.000 sind Salesforce-publizierter Kundenclaim, keine dm-Zählung.

Agentforce Coworker in Lightning: 100.000 in 35 Tagen als Claim

Agentforce Coworker sitzt laut Salesforce in der Lightning-Oberfläche: Begründung über Accounts, Aktivität und Historie, Insights und Aktionen dort, wo Kundschaft schon arbeitet. Läuft innerhalb bestehender Permissions und Business Rules; nichts werde außerhalb der Trust Boundary behalten — so Salesforce. Coworker rufe spezialisierte Agentforce-Agenten auf, die Teams schon gebaut und deployed haben. Aktivierung per Knopf; keine Migration, kein neues Permissions-Modell. Salesforce claimt: 100.000 Nutzerinnen und Nutzer hätten Coworker in den ersten 35 Tagen aktiviert. Das ist ein Salesforce-Claim. Keine unabhängige Messung. Keine Aussage über Qualität der Nutzung, nur über Aktivierung.

Optional und klar als Salesforce-veröffentlichte Kundenstimme: Brandon Bernard, Senior Vice President/Sales Technology Strategist bei Fulton Bank, wird in der Story zitiert — sinngemäß: von null auf mehr als 20 Use Cases in Produktion in wenigen Wochen, rund 3.000 Nutzende organisationweit, spürbare tägliche Nutzung. Wieder: Salesforce-publizierter Kundenclaim, kein dm-Audit der Bank.

Coworker im bekannten Lightning-Fenster ändert die Governance-Frage nicht. Bestehende Permissions sind ein Start. Sie sind kein Skill-Audit für Agents, die Coworker aufruft. Wer Agentforce schon betreibt, kennt das Muster aus dem Text zu Agentforce bei Salesforce Operations: Fakten und Freigaben trennen, Claims kennzeichnen. Hier gilt dasselbe für Skills hinter der neuen Surface.

Surface, Claim, Audit: was Teams prüfen müssen

Drei Spalten. Keine Folie zum Abnicken.

Die Tabelle ist Arbeitsmittel. Sie ersetzt keine Security-Review. Sie macht sichtbar, dass Claim und Audit nicht dieselbe Spalte sind.

Headless Toolkit und Partner: komponierbar heißt prüfbar

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptClose documentary photo of an adult hand resting on a printed checklist beside a laptop with out-of-focus interface panels, audit workspace mood, no logos, no readable words, no brand names, 16:9

AIforce werde laut Salesforce vom Headless Toolkit getragen: offene Architektur mit MCPs, APIs, Plug-ins, Skills und Entwicklerwerkzeugen. AgentExchange als Partnernetzwerk und Marketplace — Salesforce nennt unter anderem Anthropic, Amazon Web Services, Google, Microsoft sowie Builder wie Lovable und Vercel und weitere wie Docusign. Kurz halten. Keine Partner-Pitches ausrollen. Komponierbar klingt nach Freiheit. Freiheit ohne Scope-Liste ist Freiheit für den Angriffspfad und für den ehrlichen Fehler gleichermaßen.

Parallel zur Governance in anderen Stacks: Wenn ERP-Agenten und Gateways Workflows anstoßen, zählt ebenfalls, wer freigibt und was protokolliert wird — siehe ERP-Agent-Gateways und Copilot-/Joule-Workflows. Die Parallel bleibt knapp. Hier geht es um Salesforce AIforce und CRM als SoR.

Scope-Liste, Revocation, Beleg: drei Forderungen ohne Marketing

Erstens: Scope-Liste. Jeder Skill, jedes Plug-in, jeder MCP-Endpunkt mit Lesen/Schreiben, Objekten, Feldern, Surfaces. Nicht „Sales-Skills“. Konkret. Versioniert. Verantwortlich benannt.

Zweitens: Revocation-Pfad. Wer sperrt einen Skill in Claude, ohne die ganze Verbindung zu kappen? Wer entzieht Slackbot Schreibrechte für Ownership-Wechsel? Wer stoppt einen Coworker-Aufruf auf einen Agenten, der zu weit greift? Wenn die Antwort „Ticket an den Admin, irgendwann“ lautet, haben Sie keinen Pfad. Sie haben Hoffnung.

Drittens: Wer liest den Beleg? Security? Compliance? Die Fachrolle? Ein leeres Log, das niemand öffnet, ist Dekoration. Ein Log, das nur die Person liest, die den Skill freigeschaltet hat, ist Interessenkonflikt mit nettem Dateinamen.

Klartext: Interfaces in Claude, Slack und Coworker sind praktisch. Praxis ohne diese drei Punkte ist Checkout ohne Beleg. Die Pressemitteilung darf Permissions und ZDR feiern. Ihr Lenkungskreis darf trotzdem nach der Scope-Liste fragen, bevor die nächste Surface live geht.

Wer Use-Cases für KI-Agenten im Unternehmen sortiert, findet bei digital-magazin.de denselben Fokus auf Mandat und Grenze — etwa unter KI-Agenten in Unternehmen und Use-Cases. Die Parallele bleibt Governance. Das Produkt hier heißt AIforce.

Was AIforce nicht ersetzt: das System of Record

Noch einmal die Reihenfolge, weil sie in Briefings verrutscht. Die UI kann wandern. Das SoR bleibt. Datensätze, Regeln, Semantik, Permissions — dort landet die Wahrheit, die später jemand prüfen muss. AIforce, so Salesforce, bringe diesen Kontext an Interfaces. Das ändert nicht, dass ein falsch gescopter Skill denselben Schaden anrichten kann wie ein falsch berechtigte Person — nur schneller und in mehr Surfaces gleichzeitig.

Nein.

„Work with what you have“ heißt nicht „prüfen Sie nichts Neues“. Es heißt laut Salesforce: kein neues Permissions-Modell, keine Migration, Admins verbinden einmal. Das kann Integrationsaufwand senken. Es entbindet Sie nicht davon, Skills und Agent-Rechte zu scopen, zu loggen und widerrufbar zu halten. Wer „einmal verbinden“ mit „fertig governed“ verwechselt, hat die Pressemitteilung gelesen und die Revision noch nicht.

Falsch wäre auch, Zero Data Retention beim Modell-Anbieter mit vollständigem Betriebs-Audit zu verwechseln. ZDR, so der Salesforce-Claim, bedeute: Geschäftsdaten würden für die aktuelle Frage genutzt und nicht beim Modell-Anbieter behalten. Das adressiert Retention beim Provider. Es adressiert nicht die Frage, welcher Skill in Ihrer Org welche Aktion ausgeführt hat und wer sie widerrufen kann. Zwei Ebenen. Nicht vermischen.

Walkthrough ohne erfundenen Kunden: Prompt, Skill, Beleg

Ein Walkthrough, kein Kunde. Dienstag, Vertriebskanal in Slack, parallel Claude mit Salesforce-Kontext. Kein erfundener Firmenname, keine erfundene Uhrzeit. Nur die Prüffrage der Max-These, in eine Szene gelegt.

Jemand fragt in Slack nach ruhigen Accounts. Slackbot — so das Salesforce-Beispiel — surface Daten, liest Cases und Threads, schlägt Reassign und Task vor, entwirft eine Win-back-Mail. Bis hierhin: Lesen und Vorschlagen. Dann der kritische Schritt: Ownership wechseln oder Datensatz aktualisieren. Ohne Scope-Grenze und ohne Log ist das derselbe Moment wie ein Button „Speichern“ ohne Protokoll. Die UI ist der Chat. Das SoR ist Salesforce. Der Beleg fehlt, wenn niemand ihn speichert und niemand ihn liest.

Parallel in Claude: Ein Sales-Skill zur Pipeline-Hygiene läuft. 37 vorgebaute Skills heißen Tempo. Tempo ohne Liste heißt: Sie wissen nicht, welcher Skill welche Felder berührt. Ein Development-Plug-in mit mehr als 40 Skills und dynamischen Sub-Plug-ins erweitert den Radius. Dynamisch geladen klingt effizient. Dynamisch ohne Inventar klingt nach Shadow-IT mit offiziellem Logo.

Genau so, und nicht mit der Pressemitteilung als Freibrief, sieht Checkout mit Beleg aus: Scope vorher, Aktion danach, Revocation jederzeit, Beleg-Lesende benannt. Fehlt eines, ist der Walkthrough Blindflug mit freundlichem Chat.

Permissions reichen nicht als Skill-Audit

Salesforce betont bestehende Permissions: Der Agent sehe nur, was die anfragende Person sehen darf; Aktionen liefen über Salesforce zurück. Das ist ein starkes Framing. Es beantwortet die Leserechte der Person. Es beantwortet nicht automatisch, welche Skills einer Rolle gebündelt zur Verfügung stehen, welche davon schreiben dürfen und wie man einen einzelnen Skill widerruft, ohne die ganze Verbindung zu kappen.

Aber Moment mal: „Kein neues Permissions-Modell“ ist Integrationsversprechen. Audit ist Betriebspflicht. Beides kann gleichzeitig wahr sein — und trotzdem auseinanderfallen. Wer nur die Org-Permissions prüft und den Skill-Katalog ignoriert, prüft die Tür und lässt die Fenster offen.

In der Praxis heißt das für Admins und Security: Inventar der Surfaces (Claude, Slack, Coworker, später weitere). Inventar der Skills und MCPs. Mapping Rolle → Skill → Aktion. Test des Revocation-Pfads, nicht nur der Freischaltung. Stichprobe: Wer liest den Beleg in der ersten Woche nach Go-live? Wenn die Antwort ausbleibt, ist Governance Pressemitteilung.

Dieselbe Linie: Claims kennzeichnen, Mandat fordern, Beleg verlangen. AIforce ändert die Produktsprache. Es ändert nicht die Prüffrage.

Ehrlich gesagt halte ich „Admins verbinden einmal“ für den Satz, der in Lenkungskreisen am gefährlichsten wirkt. Er klingt nach Abschluss. Er ist ein Start. Die Verbindung steht. Die Scope-Arbeit beginnt.

Preis und Verfügbarkeit: Disclaimer der Quelle

Laut Salesforce-Seite: Pricing und Packaging können sich ändern. Verfügbarkeit kann regional variieren und unterliegt Kundenvereinbarungen. Kaufentscheidungen sollen auf aktuell verfügbaren Produkten und Services beruhen. Kurz. Kein Preisschild erfunden. Keine Region erfunden.

Wer AIforce evaluiert, evaluiert Surfaces und Claims getrennt von Scope, Log und Revocation. Die Dreamforce-Story vom 15.9.2026 liefert die Produktsprache. Die Max-These liefert die Prüffrage: CRM stirbt als UI — nicht als SoR. Ohne Skill-Audit bleibt der Beleg weg. Fordern Sie die Scope-Liste. Fordern Sie den Revocation-Pfad. Fordern Sie die Person, die den Beleg liest — bevor der nächste Prompt in Claude oder Slack ins System of Record schreibt.