# architect Gut strukturiertes Framework (well-architected) - Full Documentation # Agentische Zuverlässigkeitsmuster Weitere Informationen zu Well-Architected [Reliability](/docs/architect/de-de/well-architected/guide/reliability.html) → [Agentic Enterprise Reliability](/docs/architect/de-de/well-architected/guide/agentic-enterprise-reliability.html) (Wohlüberlegte Zuverlässigkeit) ## Erkennung des Agentenfehlermodus **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Plattform \| Plattform-Cache | ✅ Implementieren Sie Leistungsschalter, die den LLM-Serviceintegritätsstatus im Plattform-Cache für Echtzeitlesungen mit geringer Latenz verfolgen, unterstützt durch benutzerdefinierte Metadatentypen für Schwellenwerte und Konfiguration. Da der Plattform-Cache die beste Leistung bietet, sollten Sie den offenen/ausgelösten Status in einem dauerhaften Speicher (z. B. einem benutzerdefinierten Objekt) beibehalten und nicht nur im Cache. Öffnen des Schaltkreises für einen abgestimmten Fehlerschwellenwert (beispielsweise fünf aufeinanderfolgende Rückschlussfehler) und Weiterleiten zu Ausweichmustern | | Plattform \| Plattform-Cache | ✅ Speichern validierter Antwortschemas im Plattform-Cache für eine schnelle Validierung von Agentenantworten anhand der erwarteten Struktur | | Agentforce \| Aufforderungsvorlage | ✅ Wenn die Antwortvalidierung fehlschlägt, versuchen Sie es mit verfeinerten Eingabeaufforderungen, einschließlich des Validierungsfehlers und eines Beispiels der richtigen Struktur (maximal 3-5 Wiederholungen) | | Agentforce \| Sitzungsverfolgung | ✅ Verwenden von Agentforce Session Tracing-Erklärungsverfolgungen, um den Pfad der Agentenerläuterung zu überprüfen und Halluzinationen in ihren Ausgaben zu erkennen | | Data 360 \| Vektorsuche | ✅ Agenten auffordern, Data 360-Vektorsuchquellen zu zitieren, damit Ansprüche vor der Ausführung der Aktion auf abgerufene Quellen verwiesen werden können | | Plattform \| Proactive Monitoring | ✅ Bei Accounts mit dem Anspruch "Signature Success" (Signaturerfolg) sollten Sie sich auf Proactive Monitoring verlassen, bei dem Salesforce-Mitarbeiter die Organisation auf neu auftretende Probleme überwachen. Es handelt sich nicht um eine Self-Service-konfigurierbare Benachrichtigung. | | Plattform \| Skalierungscenter | ✅ Verwenden Sie das Skalierungscenter, um bestimmte Agentenvorgänge zu identifizieren, die sich den Obergrenzen nähern | | Agentforce \| Aktion | ✅ Implementieren der Paginierung in Agentenaktionen zum Abrufen großer Datensatzsammlungen | | Agentforce \| Aktion | ✅ Entwerfen von Agentenaktionen mit harten Obergrenzen (maximal 200 untergeordnete Elemente pro übergeordnetem Element) und Implementieren von Stichprobenstrategien bei Überschreitung der Obergrenzen | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Plattform \| Benutzerdefinierte Metadatentypen | ⚠️ Zulassen unbegrenzter Wiederholungen von Rückschlüssen ohne Leistungsschalter, Erstellen unbegrenzter Wiederholungsschleifen, wenn der LLM-Service beeinträchtigt wird | | Agentforce \| Aufforderungsvorlage | ⚠️ Wiederholen fehlgeschlagener Agentenantworten ohne Einbeziehung des Validierungsfehlers und der erwarteten Struktur in die Aufforderung zur Wiederholung | | Agentforce \| Aktion | ⚠️ Ermöglichen, dass Agenten unbegrenzten Kontext (z. B. "gesamter Verlauf") anfordern können, ohne dass strenge Obergrenzen für untergeordnete Elemente pro übergeordnetem Datensatz gelten | | Agentforce \| Aktion | ⚠️ Entwerfen von Agentenaktionen, die große Datensatzsammlungen ohne Paginierung abrufen und zu Spitzen bei Obergrenzen führen | | Einstein \| Trust Layer | ⚠️ Antworten von vertrauenswürdigen Agenten ohne Querverweise auf Ansprüche in Bezug auf Datenquellen mit Kontextbildung, sodass Halluzinationen die Ausführung von Aktionen erreichen | | Plattform \| Organisation | ⚠️ Behandeln der LLM-Serviceverfügbarkeit als identisch mit der Salesforce Platform-Verfügbarkeit, statt sie als separate Abhängigkeit zu überwachen | ## Graceful Degradation (Anmutige Erniedrigung) **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Agentforce \| Agentenkonfiguration | ✅ Design mehrstufige Ausweichketten: Vollkontextagent → Agent mit reduziertem Kontext → deterministisches Regelmodul → menschliche Übergabe über Omnikanal | | Agentforce \| Agentenkonfiguration | ✅ Konfigurieren eines sekundären Agenten mit komprimiertem Kontext (letzte 30 Tage im Vergleich zum gesamten Verlauf, die besten 5 Vektorsuchergebnisse im Vergleich zu den besten 20), um die Fehlerwahrscheinlichkeit zu reduzieren | | Plattform \| Flow | ✅ Implementieren von Ausweichlogik in Orchestrierungs-Flows oder Apex, die durch Plattformereignisse ausgelöst werden, und Protokollieren der erfolgreichen Klasse für die Sichtbarkeit von Fehlermustern | | Plattform \| Flow | ✅ Erstellen einer deterministischen Flow- oder Apex-Logik, die häufige Szenarien als Ausweichlösung verarbeitet, wenn die Agentenüberlegungen fehlschlagen (z. B. Standardvalidierungsregeln, regelbasierte Bewertungsberechnung) | | Agentforce \| Omnikanal | ✅ Konfigurieren der fertigkeitsbasierten Weiterleitung für die menschliche Übergabe, um sicherzustellen, dass Eskalationen die entsprechende Expertise erreichen | | Agentforce \| Omnikanal | ✅ Übergeben des vollständigen Unterhaltungskontexts an die menschliche Warteschlange, einschließlich versuchter Strategien, Agentenkonfidenzbewertungen und Fehlerursachen | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Agentforce \| Agentenkonfiguration | ⚠️ Entwerfen von Agenten mit einem einzelnen Ausführungspfad, der vollständig fehlschlägt, wenn eine Komponente beeinträchtigt wird | | Agentforce \| Agentenkonfiguration | ⚠️ Verwenden derselben Vollkontextagentenkonfiguration für Ausweichversuche statt schrittweisen Vereinfachen des Kontexts | | Agentforce \| Omnikanal | ⚠️ Weiterleitung an eine menschliche Übergabe ohne Weitergabe von Unterhaltungskontext, versuchten Strategien oder Fehlerursachen, wodurch der Agent gezwungen wird, von Grund auf neu zu beginnen | | Plattform \| Flow | ⚠️ Nicht protokolliert, welche Ausweichstufe erfolgreich war, wodurch der Einblick in Fehlermuster und die Effektivität des Ausweichvorgangs verloren geht | ## Plattformereignisresilienz **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Plattform \| Plattformereignisse | ✅ Veröffentlichen von Prüfpunktereignissen nach jedem erfolgreichen Schritt in mehrstufigen Agenten-Workflows, Speichern der Korrelations-ID, der abgeschlossenen Schritte und des für die Fortsetzung erforderlichen Status in der Ereignisnutzlast | | Plattform \| Plattformereignisse | ✅ Entwerfen von Agenten-Workflows als lose gekoppelte Ereignisketten, bei denen jeder Agent fehlschlagen und es unabhängig wiederholen kann, ohne den gesamten Workflow zu blockieren | | Plattform \| Plattformereignisse | ✅ Implementieren von Wiederholungswarteschlangen mit exponentiellen Backoff-Verzögerungen (30 Sekunden, 2 Minuten, 8 Minuten, 30 Minuten) mithilfe von Plattformereignissen mit Wiederholungsanzahl in der Nutzlast | | Plattform \| Plattformereignisse | ✅ Weiterleiten an Warteschlange mit toten Briefen und Warnungen nach maximalen Wiederholungen (in der Regel 5) | | Plattform \| Plattformereignisse | ✅ Korrelations-ID in alle zugehörigen Ereignisse einschließen; Verwenden der API für die Plattformereigniswiedergabe zum Rekonstruieren des vollständigen Workflow-Verlaufs für das Debuggen | | Plattform \| Plattformereignisse | ✅ Nutzen Sie das 72-Stunden-Aufbewahrungsfenster für Plattformereignisse mit hohem Volumen (Ereignisse mit Standardvolumen werden 24 Stunden lang beibehalten), um Warteschlangen für Wiederholungen durch Organisationswartungszeitfenster oder Bereitstellungsausfallzeiten beizubehalten | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Plattform \| Plattformereignisse | ⚠️ Erstellen von Agenten-Workflows mit mehreren Schritten ohne Prüfpunkt, die eine vollständige erneute Ausführung erfordern, wenn ein Zwischenschritt fehlschlägt | | Plattform \| Plattformereignisse | ⚠️ Wiederholen fehlgeschlagener Agentenanforderungen ohne exponentielles Backoff, was zu donnernden Herdeneffekten bei der Wiederherstellung von Services führt | | Plattform \| Plattformereignisse | ⚠️ Entwerfen eng gekoppelter sequenzieller Workflows, bei denen ein einzelner Agent die gesamte nachgelagerte Verarbeitung blockiert | | Plattform \| Plattformereignisse | ⚠️ Auslassen von Korrelations-IDs aus Ereignissen, wodurch die vollständige Workflow-Ausführung nicht verfolgt und debuggt werden kann | | Plattform \| Plattformereignisse | ⚠️ Unbegrenzte Wiederholung ohne maximale Anzahl von Wiederholungen oder Warteschlange mit totem Brief, Nutzung von Plattformressourcen bei dauerhaft fehlgeschlagenen Vorgängen | ## Asynchrone Verarbeitung **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Plattform \| Apex | ✅ Verwenden Sie Batch Apex für Agentenvorgänge, die mehr als 1.000 Datensätze analysieren, und nutzen Sie dabei asynchrone Obergrenzen (200 SOQL-Abfragen, 150 DML-Vorgänge, 60s CPU pro Ausführung). | | Plattform \| Apex | ✅ Verwenden von warteschlangenfähigen Apex-Ketten für Agenten-Workflows mit mehreren Schritten, die mehrere externe API-Aufrufe oder eine längere Verarbeitungszeit erfordern; Verfolgen des Fortschritts in benutzerdefinierten Objekten zum Aktivieren der Fortsetzung bei Fehlern | | Plattform \| Apex | ✅ Verwenden Sie @future-Methoden für einfache Vorgänge von Agenten, bei denen Fehler tolerierbar sind (Benachrichtigungen, externe Protokollierung, nicht dringende Aktualisierungen). | | Plattform \| Apex Jobs | ✅ Überwachen der asynchronen Verarbeitungskapazität über die Seite "Apex Aufträge" (Setup → Apex Aufträge) und die flexible Apex Warteschlange: maximale Anzahl von 5 gleichzeitigen Batchaufträgen (zusätzliche Aufträge in der Warteschlange "Flexibel", bis zu 100 im Status "Halten") und die organisationsweite tägliche Obergrenze für asynchrone Apex-Ausführungen (DailyAsyncApexExecutions) – die 250.000- oder 200-fache Anzahl an Benutzerlizenzen pro 24 Stunden –, die in Batch, Queueable, Future und Scheduled Apex freigegeben werden | | Plattform \| Organisation | ✅ Benachrichtigung, wenn sich die Obergrenzen für den asynchronen Verbrauch nähern und eine proaktive Kapazitätsverwaltung ermöglicht wird, bevor die Agentenverarbeitung blockiert wird | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Plattform \| Apex | ⚠️ Verarbeiten von mehr als 1.000 Datensätzen in synchronen Agententransaktionen anstelle von Batch Apex, wobei die Obergrenze von 100 SOQL-Abfragen bereits nach wenigen Datensätzen erreicht wird | | Plattform \| Apex | ⚠️ Verwenden von Queueable-Ketten ohne Verfolgung des Fortschritts in benutzerdefinierten Objekten, wodurch verhindert wird, dass die Funktion "Fortsetzung bei Fehler" fortgesetzt wird | | Plattform \| Organisation | ⚠️ Keine Überwachung der Obergrenze von 5 gleichzeitigen Batchaufträgen oder der Obergrenze für die gemeinsame tägliche asynchrone Apex-Ausführung (DailyAsyncApexExecutions – die größere der 250.000 oder 200 × Benutzerlizenzen pro 24 Stunden in Batch, Queueable, Future und Scheduled Apex), was dazu führt, dass die Agentenverarbeitung stillschweigend in die Warteschlange gestellt wird oder fehlschlägt | ## Agentenzuverlässigkeitstests **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Plattform \| Organisation | ✅ Laden Sie die Leistung von Testagenten in der Full Copy Sandbox mit Datenvolumen im Produktionsmaßstab; simulieren Sie gleichzeitige Unterhaltungen entsprechend der Spitzenanforderung | | Plattform \| Organisation | ✅ Messen Sie die Latenz von p95 und p99 unter Last, um die Leistungsverschlechterung unter Stress zu identifizieren. Validieren Sie, dass der Verbrauch der Reglerobergrenze unter den Schwellenwerten bei Spitzenlast bleibt | | Agentforce \| Agentenkonfiguration | ✅ Fehlerinjektion durchführen: Simulieren von LLM-Rückschlussfehlern in der Serviceebene, die Ihr Leistungsschalter überwacht, Einschleusen von SOQL-Ausnahmen beim Testen von Fehlern, Beschädigen von Antworten beim Testen von Validierungslogik | | Agentforce \| Agentenkonfiguration | ✅ Einführung einer Datenverzerrung (Accounts mit mehr als 10.000 untergeordneten Elementen) während des Tests zur Validierung der Paginierungslogik bei der Verarbeitung von Worst-Case-Szenarien | | Plattform \| Plattformereignisse | ✅ Chaos Engineering durchführen: Zufallsprinzip zum Deaktivieren von Plattformereignis-Abonnenten, die die Wiederherstellung der erneuten Wiedergabe testen, Beenden asynchroner Aufträge während der Ausführung Testpunkt Neustart | | Plattform \| Organisation | ✅ Planen regelmäßiger Chaostage in Staging-Umgebungen, um die Resilienz bei der Weiterentwicklung von Agenten aufrechtzuerhalten | | Plattform \| Organisation | ✅ Führen Sie langfristige Stabilitätstests (72+ Stunden) für zeitabhängige Fehler aus: Anhäufen von Fehlern und allmähliche Verschlechterung der Leistung | | Plattform \| Organisation | ✅ Verfolgen von CPU-Zeittrends und Heap-Verbrauch über längere Zeiträume und Erkennen einer allmählichen Verschlechterung der Kontextverwaltung | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Plattform \| Organisation | ⚠️ Lasttests in der Teilkopie-Sandbox mit reduziertem Datenvolumen bieten irreführende Sicherheit, da sich das Datenvolumen direkt auf die Agentenleistung auswirkt | | Agentforce \| Agentenkonfiguration | ⚠️ Testen Sie nur glückliche Pfade, ohne bewusst Fehler bei der Validierung von Leistungsschaltern, Wiederholungslogik und Zeitüberschreitungsverarbeitung einzuführen | | Plattform \| Organisation | ⚠️ Nur Kurzzeittests ausführen, fehlende zeitabhängige Fehler (akkumulierte Fehler, allmähliche Verschlechterung), die nur bei anhaltendem Betrieb von mehr als 72 Stunden auftreten | | Plattform \| Plattformereignisse | ⚠️ Testen Sie niemals die Wiederherstellung oder den Neustart von Prüfpunkten für Plattformereignisse, sodass Resilienzmechanismen unvalidiert bleiben | ## Agenten-SLI-Überwachung **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Unternehmen \| Dokumentation | ✅ Einrichten von SLOs vor dem Erstellen von Agenten, nicht nach Produktionsfehlern; Definieren von Zielen für die Unterhaltungserfolgsrate (in der Regel 95-99 %) pro Agententyp | | Plattform \| Organisation | ✅ Verfolgen Sie die Unterhaltungserfolgsrate als Kennzahl für die primäre Agentenzuverlässigkeit: Prozentsatz der Unterhaltungen, die ohne Fehler oder Zeitüberschreitungen abgeschlossen werden. Zählen Sie eine anmutige Übergabe an einen Menschen als Erfolg, da die Eskalation die geplante letzte Ausweichstufe ist. Zählen Sie nur fehlgeschlagene oder unbeabsichtigte Eskalationen auf die Kennzahl an. | | Plattform \| Organisation | ✅ Verfolgen Sie die Erfolgsrate getrennt nach Agententyp und Anwendungsfall, da sich die Erfolgskriterien zwischen Agentenzwecken unterscheiden | | Plattform \| Organisation | ✅ Berechnen der mittleren Zeit zwischen Ausfällen (MTBF) pro Agententyp, um die am wenigsten zuverlässigen Agenten zu identifizieren, die Optimierungsinvestitionen erfordern | | Plattform \| Organisation | ✅ Mean Time to Recovery (MTTR) messen; Automatisieren der Wiederherstellung über Plattformereigniswiedergabe und Leistungsschalter für eine viel schnellere, weniger fehleranfällige Wiederherstellung als manuelle Intervention | | Einstein \| Trust Layer | ✅ Beispiel für zufällige Agentenantworten zur Validierung von Ansprüchen in Bezug auf Data 360-Quellen zur Messung der Grounding-Genauigkeit; Untersuchen, wann die Genauigkeit unter 95 % fällt | | Plattform \| Plattformereignisse | ✅ Überwachen von Plattformereignis-Wiedergabelücken (übersehene oder nicht zugestellte Ereignisse) über ein abonnentenseitiges Protokollierungsmuster, das die ReplayId und die Korrelations-ID jedes Ereignisses in einem benutzerdefinierten Objekt aufzeichnet | | Plattform \| Organisation | ✅ Benachrichtigen von Vorgängen, wenn ein SLI unter den definierten SLO-Schwellenwert fällt | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Unternehmen \| Dokumentation | ⚠️ Erstellen von Agenten, ohne zuerst SLOs zu definieren, und Einrichten von Zuverlässigkeitszielen erst nach Produktionsausfällen | | Plattform \| Organisation | ⚠️ Verwenden einer einzelnen aggregierten Erfolgsrate über alle Agententypen hinweg statt einer separaten Verfolgung nach Agententyp und Anwendungsfall | | Plattform \| Organisation | ⚠️ Verlassen Sie sich ausschließlich auf die traditionelle Salesforce-Überwachung (Trust.salesforce.com), ohne agentenspezifische SLIs wie Unterhaltungserfolgsrate, MTBF, MTTR und Grounding-Genauigkeit zu verfolgen | | Plattform \| Organisation | ⚠️ Erfordernis eines manuellen Eingreifens bei allen Agentenfehlern anstelle der automatisierten Wiederherstellung mit Plattformereigniswiedergabe und Leistungsschaltern | | Einstein \| Trust Layer | ⚠️ Niemals Probennahme von Agentenantworten zur Validierung der Erdungsgenauigkeit, wodurch Halluzinationen in der Produktion unentdeckt bleiben | ## Zuverlässiges Agentendesign **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Agentforce \| Agentenkonfiguration | ✅ Entwerfen von Wiederholungsmustern, Ausweichketten und Eskalationsschwellenwerten in Agenten-Workflows vom ursprünglichen Entwurf an und nicht als nachträgliche Überlegungen | | Agentforce \| Aktion | ✅ Bulkify context preparation and paginate large record collections in agent actions (Kontextvorbereitung per Massenvorgang vereinfachen und große Datensatzsammlungen in Agentenaktionen paginieren) | | Plattform \| Plattform-Cache | ✅ Cache häufig aufgerufener Referenzdaten im Plattform-Cache reduziert redundante Abfragen während der Agentenkontextvorbereitung | | Plattform \| Skalierungscenter | ✅ Verwenden Sie das Skalierungscenter, um ressourcenintensive Agentenvorgänge zu identifizieren, die optimiert werden müssen | | Plattform \| Plattformereignisse | ✅ Entwerfen von sich selbst wiederherstellenden Workflows mithilfe von Plattformereignissen als dauerhafte Wiederholungswarteschlangen mit Leistungsschaltern zum Schutz externer Abhängigkeiten | | Agentforce \| Agentenkonfiguration | ✅ Nehmen Sie immer die menschliche Übergabe als endgültigen Ausweg in die Abbaukette jedes Agenten auf | | Plattform \| Organisation | ✅ Agenten-SLIs kontinuierlich überwachen, wenn Kennzahlen unter SLOs fallen | | Agentforce \| Agentenkonfiguration | ✅ Abwägen autonomer Funktionen mit der entsprechenden Aufsicht: Aktivieren der Selbstwiederherstellung nach vorübergehenden Fehlern bei gleichzeitiger Eskalation, wenn die Konfidenz sinkt oder Kundenvorgänge auftreten | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Agentforce \| Agentenkonfiguration | ⚠️ Hinzufügen von Zuverlässigkeitsmechanismen (Wiederholung, Ausweichmanöver, Eskalation) als Nachgedanken, statt sie von Anfang an zu entwerfen | | Agentforce \| Aktion | ⚠️ Keine Massenvorbereitung des Kontexts, was zu Fehlern bei der Obergrenze unter realen Abfragemustern führt | | Plattform \| Organisation | ⚠️ API-Verbrauch und Plattformereigniszuteilung nicht proaktiv überwachen und Obergrenzen nur erkennen, wenn Agenten fehlschlagen | | Agentforce \| Agentenkonfiguration | ⚠️ Entwerfen von Agentenketten ohne menschliche Übergabe als endgültiges Ausweichmanöver, sodass kein Wiederherstellungspfad verbleibt, wenn alle automatisierten Optionen erschöpft sind | | Agentforce \| Agentenkonfiguration | ⚠️ Gewähren eines vollständig autonomen Betriebs für Agenten ohne Eskalationsschwellenwerte für Situationen mit niedrigem Vertrauen oder Randfälle | # AI Fairness and Bias Detection (AI-Fairness und Verzerrungserkennung – Agentenmuster) Weitere Informationen zu Well-Architected [Fairness](/docs/architect/de-de/well-architected/guide/fairness.html) → [Agentic Enterprise Fairness](/docs/architect/de-de/well-architected/guide/agentic-enterprise-fairness.html) (Wohlarchitektonische Fairness) ## Verzerrungserkennung und -minderung **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Agentforce \| Agentenkonfiguration | ✅ Testen Sie Agenten systematisch auf demografische Verzerrungen mithilfe verschiedener Personas, die geschützte Gruppen darstellen. Generieren Sie identische Anforderungen, die nur demografische Signale wie Namen, Standorte oder Kommunikationsstile variieren | | Data 360 \| Datensegmente | ✅ Bevor Sie Salesforce-Daten für die Agentenschulung oder RAG-Kontextbildung verwenden, sollten Sie die demografische Darstellung prüfen und unterrepräsentierte Gruppen identifizieren. | | Data 360 \| Knowledge Base | ✅ Überprüfen Sie Knowledge Bases und Abrufquellen für die demografische Balance. Stellen Sie sicher, dass Qualität, Vollständigkeit und Genauigkeit der Dokumentation in allen Kundensegmenten vergleichbar sind | | Agentforce \| Agentenüberwachung | ✅ Überwachen von Agenteninteraktionen über demografische Gruppen hinweg auf Verhaltenskonsistenz; Analysieren von Antwortlänge, Detailebene, Höflichkeitsmarkierungen und Lösungsqualität stratifiziert nach Benutzereigenschaften | | Agentforce \| Agentenüberwachung | ✅ Erkennen von Feedback-Schleifen durch Überwachen von Änderungen bei der Entscheidungsverteilung im Laufe der Zeit; Durchbrechen von Schleifen durch die menschliche Überprüfung von Edge-Kundenvorgängen und regelmäßiges Neuabstimmen | | Data 360 \| Trainingsdaten | ✅ Überstichprobe unterrepräsentierter demografischer Gruppen in Trainingsdaten, um eine ausgewogene Darstellung zu gewährleisten; Synthese zusätzlicher Daten mit Techniken wie SMOTE, wenn reale Daten nicht ausreichen | | Agentforce \| Aufforderungsvorlage | ✅ Beschränken Sie das Agentenverhalten durch Systemaufforderungen: "Behandeln Sie alle Kundendemografien mit der gleichen Professionalität und Detailgenauigkeit. Stellen Sie Erklärungen von vergleichbarer Länge und Qualität bereit, unabhängig vom Kommunikationsstil oder Hintergrund des Kunden." | | Einstein \| Prognosemodell | ✅ Berechnen von Korrelationskoeffizienten zwischen allen Modellfunktionen und geschützten Merkmalen; Bewerten, ob legitimer Prognosewert die Einbeziehung hochkorrelierter Funktionen rechtfertigt | | Einstein \| Prognosemodell | ✅ Identifizieren und Entfernen von Proxy-Funktionen, die mit geschützten Merkmalen korrelieren (Postleitzahlen-Proxys für Rasse, Namensmuster-Proxy für Geschlecht/Ethnie, Kommunikationszeit-Proxys für Religion/Pflege, Gerätetyp-Proxys für Einkommen, Regionszuweisungs-Proxys für demografische Zusammensetzung) | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Data 360 \| Trainingsdaten | ⚠️ Verwenden von historischen CRM-Daten für die Agentenschulung ohne Prüfung der demografischen Darstellung, wodurch algorithmische Verzerrungen menschlicher Verzerrungen verstärken können | | Agentforce \| Agentenkonfiguration | ⚠️ Bereitstellen von Agenten ohne systematische demografische Verzerrungstests in verschiedenen Personas, die geschützte Gruppen darstellen | | Data 360 \| Knowledge Base | ⚠️ Bereitstellen detaillierter Knowledge-Artikel für Unternehmenskunden, jedoch nur allgemeiner Antworten für Kleinunternehmenskunden, wodurch die Unterschiede bei der Servicequalität beibehalten werden | | Agentforce \| Agentenüberwachung | ⚠️ Ermöglichen der Anpassung des Verhaltens von Agenten anhand von Unterhaltungshinweisen, die mit geschützten Merkmalen (Kommunikationsstil, Sprachkomplexität, Zeiteinteilungsmuster) korrelieren, ohne Überwachung | | Einstein \| Prognosemodell | ⚠️ Einbeziehung von Proxy-Funktionen (Postleitzahl, Namensmuster, Gerätetyp) in Folgeentscheidungsmodelle ohne Auswertung der Korrelation mit geschützten Merkmalen | | Agentforce \| Agentenkonfiguration | ⚠️ Zulassen von Feedbackschleifen, wenn Agentenentscheidungen zu Ungleichheiten führen, die künftige negative Entscheidungen rechtfertigen (z. B. Weiterleitung von Agenten, die Opportunities auf bestimmte Regionen reduzieren, weniger Erfolgsdaten generieren, prognostizierter Erfolg weiter reduzieren) | | Data 360 \| Datensegmente | ⚠️ Standardmäßige Verweise auf die Mehrheitskultur in Inhaltsbeispielen, die unterrepräsentierte Benutzer verfremden | ## Multi-Agent-Orchestrierung **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Agentforce \| Agentenüberwachung | ✅ Protokollieren vollständiger Eingaben und Ausgaben für jeden Agenten in einer Orchestrierungskette, damit Verzerrungen in einem endgültigen Ergebnis rückwärts bis zur Phase verfolgt werden können, in der sie eingeführt wurden und in der die Verstärkung erfolgte | | Plattform \| CRM Analytics | ✅ Erstellen von Dashboards mit Entscheidungsverteilungen in jeder Orchestrierungsphase, aufgeschlüsselt nach demografischen Daten, um festzustellen, wo in der Kette Unterschiede auftreten oder sich erweitern | | Plattform \| CRM Analytics | ✅ Berechnen der demografischen Parität, der Chancengleichheit und der ungleichen Auswirkungen in jeder Phase der Kette, nicht nur auf das Endergebnis; phasenweise Kennzahlen erfassen die Compoundierung, die in jeder einzelnen Phase akzeptabel aussieht, sich jedoch in der gesamten Kette verschlechtert | | Agentforce \| Modellkonfiguration | ✅ Maximieren Sie die Vielfalt zwischen Agenten in Konsensmustern, um korrelierte Fehler zu reduzieren: unterschiedliche Grundlagenmodelle, sofern durchführbar (z. B. durch Bring Your Own LLM-Konfigurationen), unterschiedliche Abrufquellen, unterschiedliche Aufforderungsansätze und unterschiedliche Konfidenzschwellenkalibrierungen | | Agentforce \| Agentenkonfiguration | ✅ Einfügen einer menschlichen Überprüfung an Orchestrierungswendepunkten, an denen eine Phase die nachgelagerten Optionen erheblich einschränkt, selbst wenn die Konfidenz einzelner Agenten hoch ist, da die Orchestrierung auftauchende Effekte erzeugt, die die Konfidenzbewertungen pro Agent nicht erfassen | | Agentforce \| Agentenkonfiguration | ✅ Konfigurieren von Orchestrierungs-Leistungsschaltern, die angehalten und für einen Menschen eskaliert werden, wenn das Vertrauen eines Agenten unter den Schwellenwert fällt, sich die Ausgabeverteilung erheblich zwischen den Phasen verschiebt, die Kette auf Daten stößt, die im Training oder in der Validierung nicht dargestellt sind, oder der Benutzer eine Zwischenentscheidung anficht | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Agentforce \| Agentenüberwachung | ⚠️ Orchestrierungsketten ausführen, ohne die Eingaben und Ausgaben der einzelnen Agenten zu protokollieren, wodurch es unmöglich wird, nachzuvollziehen, welche Phase zu einer Verzerrung geführt hat, wenn ein diskriminierendes Ergebnis angezeigt wird | | Agentforce \| Modellkonfiguration | ⚠️ Behandeln des Konsenses mehrerer Agenten als Korrektur von Verzerrungen, wenn alle Agenten dasselbe Grundlagenmodell oder dieselben Trainingsdaten verwenden, sodass die Vereinbarung nur die gemeinsame Verzerrung validiert, statt sie zu korrigieren | | Plattform \| CRM Analytics | ⚠️ Messung der Fairness nur im Hinblick auf das endgültige Orchestrierungsergebnis, fehlende phasenweise Compoundierung, wobei jede Phase isoliert akzeptabel erscheint, die Kette jedoch zu einer inakzeptablen Disparität führt | | Agentforce \| Agentenkonfiguration | ⚠️ Vertrauen auf einzelne Agentenkonfidenzbewertungen, um eine Orchestrierungskette zu durchlaufen, ohne menschliche Überprüfung an Wendepunkten einzufügen, an denen eine Phase die nachgelagerten Optionen eingrenzt | | Agentforce \| Agentenkonfiguration | ⚠️ Zulassen, dass eine Orchestrierungskette ohne Leistungsschalter fortgesetzt wird, wenn ein vorgelagerter Agent eine geringe Konfidenz aufweist, sich Verteilungen zwischen Phasen verschieben oder die Kette auf Daten außerhalb ihrer Trainings- und Validierungssätze stößt | ## Fairness-Kennzahlen **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Business \| Deployment Gate (Unternehmen \| Bereitstellungstor) | ✅ Legen Sie die Fairnessbewertung als obligatorisches Bereitstellungs-Gate fest, das der Sicherheitsüberprüfung entspricht, bevor Sie Agenten bereitstellen, die Folgeentscheidungen treffen | | Einstein \| Prognosemodell | ✅ Berechnen Sie die demografische Parität, indem Sie die Population in demografische Segmente unterteilen, positive Ergebnisraten pro Segment messen und Raten segmentübergreifend vergleichen. | | Einstein \| Prognosemodell | ✅ Stellen Sie die Chancengleichheit sicher, indem Sie sicherstellen, dass Agenten qualifizierte Einzelpersonen unabhängig von demografischen Merkmalen gleich gut identifizieren. Überprüfen Sie, ob die tatsächlich positiven Raten gruppenübergreifend vergleichbar sind | | Einstein \| Prognosemodell | ✅ Wenden Sie die Vier-Fünftel-Regel an: Wenn eine Gruppe positive Ergebnisse mit weniger als 80 % der Rate der Gruppe mit der höchsten Leistung erhält, auf Verzerrung untersuchen | | Einstein \| Prognosemodell | ✅ Berechnen ungleicher Auswirkungsquoten für alle Folgeentscheidungen von Agenten und Dokumentuntersuchungsergebnisse, wenn die Quoten unter 80 % fallen | | Unternehmen \| Dokumentation | ✅ Dokument, wenn Verstöße gegen die demografische Parität legitime Geschäftsfaktoren und keine Diskriminierung widerspiegeln | | Wirtschaft \| Rechtliche Überprüfung | ✅ Wenden Sie sich an einen Rechtsbeistand, wenn Sie gruppenspezifische Schwellenwerte für ausgeglichene Quoten anwenden. Beachten Sie, dass in den USA die Anpassung von Bewertungen oder Cutoffs nach geschützter Klasse für beschäftigungsbezogene Entscheidungen gemäß Titel VII (Civil Rights Act von 1991) verboten ist und dass andere Rechtsordnungen ihre eigenen Einschränkungen auferlegen. | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Business \| Deployment Gate (Unternehmen \| Bereitstellungstor) | ⚠️ Bereitstellen von Agenten, die konsequente Entscheidungen treffen, ohne Fairnesskennzahlen für demografische Gruppen zu berechnen | | Einstein \| Prognosemodell | ⚠️ Systematisch fehlende qualifizierte Kandidaten aus unterrepräsentierten Gruppen durch Festlegen höherer Nachweisschwellenwerte für diese Gruppen als für Mehrheitsgruppen | | Einstein \| Prognosemodell | ⚠️ Einführung gruppenspezifischer Schwellenwerte ohne rechtliche Begründung oder Validierung, die die Fairness erhöhen, ohne andere diskriminierende Auswirkungen zu haben, oder – in den Vereinigten Staaten – Umsetzung dieser Schwellenwerte für beschäftigungsbezogene Entscheidungen überhaupt, wenn Titel VII die Anpassung von Bewertungen oder Grenzwerten nach geschützter Klasse verbietet | | Unternehmen \| Dokumentation | ⚠️ Nichtdokumentierung, wenn Verstöße gegen Fairnesskennzahlen berechtigte Geschäftsunterschiede und Diskriminierung widerspiegeln | ## Verzerrungserkennung **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Einstein \| Trust Layer | ✅ Verwenden von Trust Layer-Aktivierungsdaten zum Analysieren von Antwortverteilungen zwischen demografischen Gruppen; Erstellen von CRM Analytics-Dashboards zum Vergleichen von Genehmigungsraten, Empfehlungsmustern und Risikobewertungen nach Kundensegment | | Einstein \| Trust Layer | ✅ Regelmäßige Protokollierung der Query Trust Layer: alle Prognosen mit hohem Wert gruppiert nach Kundenbranche, Region und Accountgröße anzeigen, um sicherzustellen, dass die Prognoseverteilungen segmentübergreifend konsistent sind | | Agentforce \| Sitzungsverfolgung | ✅ Stichprobe von 100 nach demografischer Gruppe stratifizierten Agentenentscheidungen, in denen Überprüfer mithilfe von Agentforce Session Tracing-Überlegungen beurteilen können, ob die Argumentationsqualität gruppenübergreifend vergleichbar ist | | Plattform \| CRM Analytics | ✅ Konfigurieren von Benachrichtigungen, wenn Agentenentscheidungsmuster erheblich vom Basiswert abweichen (z. B. sinken die Genehmigungsraten für ein bestimmtes Segment um 20 % im Wochenvergleich) | | Plattform \| CRM Analytics | ✅ Erstellen einer benutzerdefinierten Überwachung zur Warnung bei Fairness-Signalen: "Benachrichtigung, wenn die durchschnittliche Unterhaltungsdauer für ein Kundensegment das 1,5-fache des Gesamtdurchschnitts an drei aufeinanderfolgenden Tagen überschreitet" | | Plattform \| CRM Analytics | ✅ Erstellen Sie wiederverwendbare CRM Analytics-Dashboard-Vorlagen, die Fairness-Kennzahlen für allgemeine Agentenanwendungsfälle verfolgen, einschließlich demografischer Parität, Chancengleichheit, ungleicher Auswirkungsverhältnisse und Trenddiagrammen | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Agentforce \| Sitzungsverfolgung | ⚠️ Ignorieren der Argumentationsspuren für das Agentforce Session Tracing und des Trust Layer-Aktivierungsprotokolls, wenn Benutzer Verzerrungen melden und nicht wissen, welche Argumentationsschritte, Datenquellen oder Abrufmuster die Verzerrung verursacht haben | | Plattform \| CRM Analytics | ⚠️ Fehlende Konfiguration von Warnungen zur Anomalieerkennung für Fairnesssignale, wodurch plötzliche Verteilungsverschiebungen unentdeckt bleiben | | Plattform \| CRM Analytics | ⚠️ Erstellen von Fairness-Dashboards ad-hoc pro Team anstelle der Freigabe wiederverwendbarer Vorlagen zur Standardisierung der Fairness-Überwachung | ## Menschliche Aufsicht **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Agentforce \| Agentenkonfiguration | ✅ Entwerfen von Agenten für Entscheidungen mit hohem Einsatz (Beschäftigung, Kredit, Gesundheitswesen, Recht, Wohnungswesen) zum Analysieren, Empfehlen und Vorbereiten von Entscheidungen, während sie vor der Ausführung die Genehmigung durch den Menschen benötigen | | Plattform \| Genehmigungsprozess | ✅ Konfigurieren Sie Agentforce so, dass Empfehlungen mit unterstützenden Nachweisen generiert werden, Entscheidungen über einen Schwellenwert per Genehmigungsprozess an menschliche Überprüfer weitergeleitet werden und Agentengründe auf der Genehmigungsoberfläche angezeigt werden | | Agentforce \| Agentenkonfiguration | ✅ Konfidenzbasierte Eskalation implementieren: Hohes Vertrauen (>90 %) verläuft autonom, mäßig (70-90 %) erfordert eine menschliche Überprüfung, niedrig (<70 %) wird vollständig auf menschlich mit Kontextzusammenfassung zurückgestellt | | Agentforce \| Agentenkonfiguration | ✅ Kalibrieren von Konfidenzschwellenwerten mithilfe von Produktionsdaten; Stichprobenentnahme von Agentenentscheidungen in jedem Konfidenzband und Berechnung der tatsächlichen Erfolgsraten zum Validieren der Kalibrierung | | Agentforce \| Agentenkonfiguration | ✅ Legen Sie zeitlich begrenzte Eskalationsauslöser fest: nach 5-7 Runden ohne Auflösung, nach 10 Minuten, wenn der Benutzer Frust ausdrückt oder wenn der Agent dieselbe Antwort wiederholt | | Plattform \| Omnikanal | ✅ Konfigurieren Sie Omnikanal, um eskalierte Kundenvorgänge an die entsprechenden fertigkeitsbasierten Warteschlangen mit vollständigem Unterhaltungskontext weiterzuleiten; trainieren Sie menschliche Agenten im Umgang mit Eskalationen, ohne dass Benutzer Informationen wiederholen müssen | | Agentforce \| UX | ✅ Option “Mit menschlichem Agenten verbinden” jederzeit auf Agenten-Chat-Oberflächen bereitstellen und nicht hinter einer Mindestanzahl fehlgeschlagener Interaktionen zurückbleiben | | Agentforce \| Agentenkonfiguration | ✅ Ermöglichen Sie es autorisierten Personen, Agentenentscheidungen jederzeit mit dokumentierten Gründen zu überschreiben; fügen Sie allen Agentenentscheidungsoberflächen, die eine mehrzeilige Texterklärung erfordern, die Schaltfläche "Agent überschreiben" hinzu. | | Plattform \| Benutzerdefiniertes Objekt | ✅ Protokollieren von Überschreibungen im benutzerdefinierten Objekt mit Entscheidungs-ID, Überschreibungszeitstempel, Begründung und Überschreibung; Erstellen von CRM Analytics-Dashboards zur Verfolgung von Überschreibungsmustern nach Agent, Entscheidungstyp und Kundendemografie | | Unternehmen \| Dokumentation | ✅ Dokumentierte Gründe für Genehmigungen oder Ablehnungen anfordern, die von der Agentenempfehlung abweichen; Überschreibungsmuster verfolgen, um systematische Agentenmängel zu identifizieren | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Agentforce \| Agentenkonfiguration | ⚠️ Bereitstellen von Agenten als autonome Entscheidungsträger für Entscheidungen mit hohem Einsatz (Beschäftigung, Kredit, Gesundheitswesen, Recht, Wohnungswesen) ohne menschliche Genehmigungstore | | Agentforce \| Agentenkonfiguration | ⚠️ Verwendung falsch kalibrierter Konfidenzbewertungen, bei denen Entscheidungen mit hoher Konfidenz nur 75 % der Fälle erfolgreich sind, was Trust in Eskalationsmechanismen untergräbt | | Agentforce \| Agentenkonfiguration | ⚠️ Einklemmen von Kunden in nicht hilfreiche automatisierte Schleifen ohne zeit- oder rundengebundene Eskalation für Menschen | | Plattform \| Omnikanal | ⚠️ Weiterleiten eskalierter Kundenvorgänge ohne vollständigen Unterhaltungskontext, wodurch Benutzer gezwungen werden, die dem Agenten bereits bereitgestellten Informationen zu wiederholen | | Unternehmen \| Unternehmensführung | ⚠️ Zulassen der Verteilung von Verantwortung, wenn alle davon ausgehen, dass die AI verantwortlich ist und niemand die Verantwortung für Entscheidungen übernimmt | | Unternehmen \| Unternehmensführung | ⚠️ Zuweisen der Rechenschaftspflicht nach Vorfällen und nicht vor der Bereitstellung mit benannten Einzelpersonen, die in Architekturentscheidungsdatensätzen dokumentiert sind | ## Zuweisung zur Rechenschaftspflicht **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Unternehmen \| Dokumentation | ✅ Weisen Sie die Rechenschaftspflicht vor der Bereitstellung zu: Modellinhaber (Fairness/Genauigkeit), Entscheidungsinhaber (Anwendungsfall/Auswirkung), Beschwerdebehörde (Fairness-Beschwerde), Prüfbehörde (regelmäßige Prüfungen) | | Unternehmen \| Dokumentation | ✅ Dokumentieren Sie alle Verantwortlichkeitsrollen mit Namen und nicht nur mit Titeln, um sicherzustellen, dass die Verantwortlichkeit durch organisatorische Änderungen erhalten bleibt | | Unternehmen \| Unternehmensführung | ✅ Ermöglichen Sie es der Beschwerdebehörde (Ethiküberprüfungskommission oder benanntes Team), Beschwerden von Benutzern zu bearbeiten, die glauben, dass Agentenentscheidungen unfair waren, mit zugänglichen, zeitnahen Prozessen, die Agentenentscheidungen rückgängig machen können | | Unternehmen \| Unternehmensführung | ✅ Autorisieren der Prüfbehörde (Compliance-Team) zur Durchführung regelmäßiger Prüfungen und Aussetzen von Agenten, die gegen Fairnessstandards verstoßen, bis die Korrektur aussteht | | Unternehmen \| Unternehmensführung | ✅ Planen einer monatlichen Überprüfung von Überschreibungsmustern mit hoher Häufigkeit mit dem Agentenentwicklungsteam | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Unternehmen \| Unternehmensführung | ⚠️ Dokumentieren von Verantwortlichkeitsrollen nur mit Titeln (z. B. "Data Science Lead") ohne benannte Einzelpersonen, wodurch die Verantwortlichkeit bei Organisationsänderungen entfällt | | Unternehmen \| Unternehmensführung | ⚠️ Ermöglichen, dass Entscheidungsinhaber die Rechenschaftspflicht an AI-Systeme delegieren können, statt die persönliche Rechenschaftspflicht für reale Auswirkungen beizubehalten | | Unternehmen \| Unternehmensführung | ⚠️ Unzugängliche, nicht rechtzeitige oder fehlende Befugnis zum Rückgängigmachen von Agentenentscheidungen | ## Transparenz und Erklärbarkeit **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Agentforce \| Agentenkonfiguration | ✅ Architekt mehrere Erklärungsebenen: Benutzerorientiert (einfache Sprache), geschäftlich (wichtige Entscheidungsfaktoren), technisch (Modelldetails/Funktionsgewichtungen) und auditiert (vollständige Entscheidungsverfolgung) | | Agentforce \| Agentenkonfiguration | ✅ Anzeigen von Zusammenfassungsansätzen in Echtzeit beim Treffen von Entscheidungen: "Ich habe Produkt A basierend auf Ihrem Kaufverlauf (3 ähnliche Käufe), dem aktuellen Sonderangebot (20 % Rabatt) und der Inventarverfügbarkeit empfohlen" | | Agentforce \| Agentenkonfiguration | ✅ Geben Sie "Warum haben Sie dies empfohlen?" Link, über den Benutzer die vollständige Überlegung anzeigen können, einschließlich aller abgerufenen Knowledge-Artikel, der abgerufenen Datensätze und der Entscheidungslogik | | Agentforce \| Sitzungsverfolgung | ✅ Abrufen von Argumentationsspuren aus dem Agentforce Session Tracing zur historischen Rekonstruktion, wenn Benutzer vergangene Entscheidungen Wochen oder Monate später anfechten | | Agentforce \| Sitzungsverfolgung | ✅ Beispiel einer nach demografischen Gruppen stratifizierten Agentforce Session Tracing-Erklärung, um zu analysieren, ob die Entscheidungsqualität konsistent ist; Überprüfen von 100 Verfolgungen aus jedem Kundensegment | | Agentforce \| Agentenkonfiguration | ✅ Kommunizieren Sie Vertrauen in benutzergerechte Begriffe: "Hohe Konfidenz" / "Moderate Konfidenz" / "Geringe Konfidenz" mit Kontext der Zuverlässigkeit in reiner Sprache anstelle von Rohwahrscheinlichkeitsbewertungen | | Agentforce \| Agentenkonfiguration | ✅ Erklären Sie bei Entscheidungen mit moderatem oder niedrigem Konfidenzniveau, welche zusätzliche Überprüfung und welcher erwartete Zeitplan erfolgen wird | | Agentforce \| Agentenkonfiguration | ✅ Geben Sie kontrafaktische Erklärungen an, die Benutzern zeigen, was das Ergebnis ändern würde: "Ihre Leadbewertung würde mit überprüften Beschäftigungsinformationen steigen (+8 Punkte)" | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Agentforce \| Agentenkonfiguration | ⚠️ Anzeige von Rohwahrscheinlichkeitsbewertungen (z. B. "73 % Konfidenz"), die Benutzer falsch interpretieren, anstelle der für den Benutzer geeigneten Konfidenzsprache | | Agentforce \| Agentenkonfiguration | ⚠️ Bereitstellen von Kontrafakten, die das Spielen des Systems fördern oder versehentlich geschützte Merkmale als Entscheidungsfaktoren anzeigen (z. B. "Ihre Anwendung würde eine höhere Bewertung erzielen, wenn Sie 10 Jahre jünger wären") | | Agentforce \| Agentenkonfiguration | ⚠️ Angabe nur einer Erklärungsebene, die weder den Endbenutzern (zu technisch) noch den Prüfern (zu vereinfacht) dient | | Agentforce \| Agentenkonfiguration | ⚠️ Fehler beim Speichern historischer Argumentationsspuren, was es unmöglich macht, vergangene Entscheidungen bei Anfechtung zu erklären | ## AI-Offenlegung **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Agentforce \| Agentenkonfiguration | ✅ Geben Sie deutlich an, wann Benutzer mit Agentforce Agenten interagieren, indem Sie eine deutlich sichtbare, kontinuierliche Offenlegung machen (nicht in Bezug auf den Service begraben oder nur einmal zu Beginn der Interaktion angezeigt) | | Agentforce \| Agentenkonfiguration | ✅ Anzeigen persistenter visueller Indikatoren: Agentenavatar mit der Markierung "AI-Assistent", Kopfzeile mit "Sie chatten mit einem Agentforce Serviceagenten" und sichtbarer Option 'Mit menschlichem Agenten verbinden' während der Unterhaltung | | Agentforce \| Agentenkonfiguration | ✅ Sicherstellen, dass Benutzer, die menschliche Interaktion bevorzugen, ohne Reibung oder Servicequalitätseinbußen wechseln können | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Agentforce \| Agentenkonfiguration | ⚠️ AI-Offenlegung in Bezug auf den Service begraben oder nur einmal beim Interaktionsstart anzeigen, statt persistente visuelle Indikatoren beizubehalten | | Agentforce \| Agentenkonfiguration | ⚠️ Bestrafen von Benutzern, die sich für eine menschliche Interaktion entscheiden, mit beeinträchtigtem Service oder erhöhten Wartezeiten | | Agentforce \| Agentenkonfiguration | ⚠️ Ausblenden der Option "Mit menschlichem Agenten verbinden" oder Verlangen, dass Benutzer Agenteninteraktionen abschließen, bevor sie auf menschlichen Support zugreifen | ## Algorithmic Accountability and Audit (Algorithmische Rechenschaftspflicht und Überprüfung) **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Plattform \| Ereignisüberwachung | ✅ Konfigurieren der Ereignisüberwachung zum Verfolgen von: API-Ereignisprotokolle mit Agentensysteminteraktionen, Anmeldeereignissen für Agentenservice-Accounts und Berichtexporten, wenn Agenten auf Massendaten zugreifen | | Plattform \| Ereignisüberwachung | ✅ Streamen von Ereignisüberwachungsprotokollen an externe SIEM-Systeme für die langfristige Aufbewahrung und Manipulationsnachweise, die die gesetzlichen Anforderungen erfüllen | | Plattform \| Feld-Aktivierungsprotokoll | ✅ Aktivieren des Feld-Aktivierungsprotokolls (unbestimmte Aufbewahrung des archivierten Verlaufs) für Objekte, die Agentenentscheidungen speichern oder von ihnen beeinflusst werden, wobei aus den unterstützten Standardobjekten sowie benutzerdefinierten Objekten mit aktivierter Feldverlaufsverfolgung ausgewählt wird; wichtig für Anwendungsfälle mit Krediten, Beschäftigung und anderen hohen Beteiligungen | | Plattform \| Shield | ✅ Verwenden Sie die Shield-Ereignisüberwachung für Agentenentscheidungen mit dem höchsten Anteil, bei denen die Integrität des Prüfpfads entscheidend ist (erweiterte Funktionen, strukturierte Ereignisfelder, Integration von Compliance-Berichten) | | Plattform \| Benutzerdefiniertes Objekt | ✅ Erstellen eines benutzerdefinierten Objekts vom Typ "AgentDecision__c", in dem Folgendes gespeichert wird: Decision_ID, Zeitstempel, Agent_Type, Model_Version, Confidence_Score, Outcome, User_ID, Record_ID; mit dem Verknüpfungsobjekt DecisionInput__c, das Entscheidungen mit Snapshots der Eingabefunktion verknüpft | | Plattform \| Benutzerdefiniertes Objekt | ✅ Speichern genauer Eingabefunktionswerte zum Zeitpunkt der Entscheidung (keine aktuellen Werte, die sich ändern können), um zu testen, ob Entscheidungen mit aktualisierten Daten abweichen würden | | Unternehmen \| Dokumentation | ✅ Datensatzmodellversion, Konfigurationsstatus (Schwellenwerte, Geschäftsregeln, Parameter) und Umgebungskontext (Benutzeridentität, Zeitstempel, Unterhaltungsverlauf) für jede Folgeentscheidung | | Plattform \| LWC | ✅ Erstellen der LWC-Komponenteneinbettung in Datensätze zum Anzeigen des Entscheidungsverlaufs mit Links vom Typ "Überlegungen anzeigen" | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Plattform \| Feld-Aktivierungsprotokoll | ⚠️ Verlassen auf die Standardfeldhistorie (18-monatige Aufbewahrung) für Entscheidungen mit hohem Beteiligungsgrad, die eine mehrjährige behördliche Aufbewahrung erfordern | | Plattform \| Benutzerdefiniertes Objekt | ⚠️ Speichern von nur aktuellen Datensatzwerten anstelle von Snapshots für die Eingabe von Entscheidungszeitpunkten, wodurch historische Entscheidungen nicht genau rekonstruiert werden können | | Unternehmen \| Dokumentation | ⚠️ Fehler bei der Datensatzmodellversion und dem Konfigurationsstatus, die zum Zeitpunkt der Entscheidung aktiv waren, was die Ursachenanalyse unmöglich macht, wenn eine Verzerrung erkannt wird | | Plattform \| Ereignisüberwachung | ⚠️ Führen von Überwachungsprotokollen nur innerhalb von Salesforce ohne externes SIEM-Streaming, da keine Manipulationsnachweise für die Einhaltung gesetzlicher Vorschriften vorliegen | ## Kontinuierliche Fairnessüberwachung **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Plattform \| CRM Analytics | ✅ Erstellen von Dashboards mit folgenden Elementen: Entscheidungsverteilung nach demografischem Segment (Balkendiagramme), Fairness-Kennzahlen im Zeitverlauf (Trendlinien mit Warnschwellenwerten), ungleiches Auswirkungsverhältnis mit Vier-Fünftel-Regelindikator, wichtigste Prädiktoren, die zu Entscheidungen beitragen, Überschreibungsrate nach demografischer Gruppe | | Plattform \| CRM Analytics | ✅ Warnung, wenn sich Eingabeverteilungen erheblich von den demografischen Daten für Trainingsdaten ändern; Überwachung auf Verteilungsverschiebung mit Hinweis auf eine potenzielle Verschlechterung der Fairness | | Agentforce \| Agentenkonfiguration | ✅ Option “Berichtanliegen” zur Agentforce Chat-Oberfläche hinzufügen; Berichte mit vollständigem Unterhaltungskontext an Ethikprüfungsgremium weiterleiten; benutzerdefiniertes Objekt mit erforderlichem Untersuchungs-Workflow verfolgen | | Unternehmen \| Unternehmensführung | ✅ Fairness-Dashboards wöchentlich überwachen, Schwellenwertverletzungen innerhalb von 24 Stunden untersuchen, monatliche Überschreibungsmusteranalysen durchführen, vierteljährlich umfassende Fairness-Audits durchführen | | Unternehmen \| Unternehmensführung | ✅ Ermöglichen Sie es Benutzern, wahrgenommene Verzerrungen über zugängliche Mechanismen zu melden; Benutzerberichte zeigen qualitative Probleme auf, die bei quantitativen Kennzahlen nicht auftreten | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Unternehmen \| Unternehmensführung | ⚠️ Behandlung der Verzerrungserkennung als einmalige Validierung vor der Bereitstellung und nicht als kontinuierliche Überwachung, wenn Agenten sich durch Aufforderungsaktualisierungen, Änderungen an der Modellversion und verschobene Datenverteilungen weiterentwickeln | | Plattform \| CRM Analytics | ⚠️ Fehlende Konfiguration von Benachrichtigungen, wenn Fairness-Kennzahlen definierte Schwellenwerte überschreiten, wodurch eine allmähliche Abweichung unentdeckt bleibt | | Agentforce \| Agentenkonfiguration | ⚠️ Keine Bereitstellung zugänglicher Mechanismen für Benutzer zum Melden wahrgenommener Verzerrungen, fehlende qualitative Probleme, die bei quantitativen Kennzahlen nicht auftreten können | ## Unterstützung externer Prüfungen **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Plattform \| Integration | ✅ Erstellen von Exportfunktionen, mit denen Compliance-Teams vollständige Entscheidungsdatensets mit demografischer Schichtung zur Überprüfung durch externe Prüfer extrahieren können, unter Beachtung der Datenschutzbestimmungen | | Unternehmen \| Dokumentation | ✅ Pflegen Sie die aktuelle Dokumentation zu: Agentenzweck und beabsichtigte Anwendungsfälle, demografische Daten und bekannte Einschränkungen, Fairnesskennzahlen (vor der Bereitstellung und Produktion), Strategien zur Verzerrungsminderung, Konfigurationen der menschlichen Aufsicht, Überwachungsansatz und Zuweisungen zur Rechenschaftspflicht | | Unternehmen \| Unternehmensführung | ✅ Führen Sie vor dem Bereitstellen von Agenten, die Folgeentscheidungen treffen, algorithmische Folgenabschätzungen durch, um potenzielle positive und negative Auswirkungen auf alle Beteiligtengruppen zu bewerten | | Unternehmen \| Unternehmensführung | ✅ halbjährliche externe Fairness-Überprüfungen durch Drittanbieter planen; Regulierungshorizont-Scans beibehalten und an EU-AI-Gesetze, Landesgesetze und Sektorvorschriften angepasst | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Plattform \| Integration | ⚠️ Entwerfen von Agentenarchitekturen ohne Vorwegnahme externer Prüfungen durch Regulierungsbehörden, Bürgerrechtsorganisationen oder Kunden; Fehlende Exportmöglichkeiten für die Überprüfung durch Prüfer | | Unternehmen \| Dokumentation | ⚠️ Zulassen, dass die Dokumentation veraltet wird, während Agenten sich durch sofortige Aktualisierungen oder Modelländerungen weiterentwickeln, ohne Fairnesskennzahlen und Strategien zur Eindämmung zu aktualisieren | | Unternehmen \| Unternehmensführung | ⚠️ Bereitstellen von Agenten, die Folgeentscheidungen treffen, ohne Folgenabschätzungen zur Bewertung der Auswirkungen auf alle Beteiligtengruppen durchzuführen | ## Benutzeragentur und Einwilligung **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Agentforce \| Agentenkonfiguration | ✅ Explizite Anmeldung für Folgeagenten anfordern (Kreditentscheidung, Beschäftigungsprüfung, Serviceanspruch) statt standardmäßige Aktivierung | | Plattform \| Benutzerdefiniertes Objekt | ✅ Erstellen Sie AI_Consent__c mit Feldern: User_ID, Use_Case, Grant_Date, Grant_Method, Withdrawal_Date, Status; Feld-Aktivierungsprotokoll für die langfristige Aufbewahrung von Einwilligungsdatensätzen aktivieren | | Agentforce \| Agentenkonfiguration | ✅ Einwilligungsprüfung zur Agentenaufruflogik hinzufügen: AI_Consent__c vor der Verarbeitung nach aktiver Einwilligung abfragen; Einwilligung auf Anwendungsfallebene unterstützen (Serviceagent vs. Vertriebsagent) | | Plattform \| Community/Erfahrungs-Site | ✅ Erstellen einer Self-Service-Einwilligungsverwaltungsoberfläche, auf die über das Benutzerprofil zugegriffen werden kann; Planen von Erinnerungen zur Verlängerung der Einwilligung alle 12 Monate | | Agentforce \| Agentenkonfiguration | ✅ Wenn Sie neue Funktionen bereitstellen, die sich auf bestehende Benutzer auswirken, suchen Sie proaktiv nach einer Einwilligung für neue Anwendungsfälle, statt sich auf die ursprüngliche Einwilligung zu verlassen, die bestimmte Anwendungen nicht berücksichtigt | | Agentforce \| Agentenkonfiguration | ✅ Aktivieren Sie den Widerruf der Einwilligung jederzeit mit sofortiger Einstellung der Agentenverarbeitung. Vereinfachen Sie den Widerruf so einfach wie die Erteilung, ohne dass Supportkontakte erforderlich sind | | Agentforce \| Agentenkonfiguration | ✅ Aktivieren der Benutzervoreinstellungsverwaltung: Kommunikationsstil (prägnant im Vergleich zu detailliert), Proaktivitätsebene, Eskalationsvoreinstellung; Speichern in benutzerdefinierten Benutzerdatensatzfeldern und Verweisen in Agentensystemaufforderungen | | Plattform \| Omnikanal | ✅ Beibehaltende Option “Mit menschlichem Agenten verbinden” während der Interaktionen bereitstellen; bei Auswahl dieser Option Weiterleiten an Omnikanal mit vollständigem Unterhaltungskontext und Prioritätskennzeichnung ohne beeinträchtigte Service- oder Wartezeitstrafen | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Agentforce \| Agentenkonfiguration | ⚠️ Standardmäßiges Aktivieren von Folgeagenten ohne explizite Benutzeranmeldung, um zu verstehen, wie sich Agenten auf sie auswirken | | Agentforce \| Agentenkonfiguration | ⚠️ Anforderung einer allgemeinen AI-Einwilligung anstelle der Aktivierung einer detaillierten Einwilligung auf Anwendungsfallebene (ein Kunde kann Serviceagenten zustimmen, während Vertriebsagenten abgelehnt werden) | | Agentforce \| Agentenkonfiguration | ⚠️ Für den Widerruf der Einwilligung sind Supportkontakte oder bürokratische Prozesse anstelle von Self-Service mit sofortiger Wirkung erforderlich | | Agentforce \| Agentenkonfiguration | ⚠️ Bei der Bereitstellung wesentlich neuer Agentenfunktionen, die in der ursprünglichen Einwilligung nicht vorgesehen waren, auf die ursprüngliche Einwilligung zurückgreifen | | Agentforce \| Agentenkonfiguration | ⚠️ Verpflichtung von Benutzern, Agenteninteraktionen abzuschließen oder ihre Präferenz zu erläutern, bevor sie eine Verbindung mit einem menschlichen Agenten herstellen | ## Nichtdiskriminierung im Agentendesign **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Agentforce \| Agentenkonfiguration | ✅ Überprüfen Sie alle Datenquellen, die in der Agentenüberlegungen verwendet werden, auf geschützte charakteristische Inhalte. Entfernen oder maskieren Sie geschützte Merkmale aus Agenteneingaben, wenn dies für den Entscheidungstyp rechtlich nicht gerechtfertigt ist | | Agentforce \| Aufforderungsvorlage | ✅ Fügen Sie explizite Anweisungen für Nichtdiskriminierung in Systemaufforderungen ein: "Behandeln Sie alle Kunden unabhängig von Name, Standort, Kommunikationsstil oder anderen Merkmalen mit der gleichen Professionalität. Treffen Sie niemals Annahmen über Kunden anhand demografischer Merkmale." | | Agentforce \| Agentenkonfiguration | ✅ Test mit verschiedenen Personas vor der Produktion: Erstellen identischer Anforderungen, die nur demografische Signale variieren (Namen, die unterschiedliche Ethnien, Standorte, Kommunikationsstile angeben); Vergleichen von Antworten auf Qualität, Länge, Professionalität und Ergebnisse | | Agentforce \| Agentenüberwachung | ✅ Berechnen der Lösungsraten für Erstkontakte stratifiziert nach Kundensegment; Untersuchen, ob erhebliche Unterschiede zwischen Segmenten bestehen | | Agentforce \| Agentenüberwachung | ✅ Beispielhafte Agentenunterhaltungen über Segmente hinweg und Überprüfer können die Antwortqualität anhand konsistenter Dimensionen (Genauigkeit, Vollständigkeit, Professionalität, Hilfsbereitschaft) mit Inter-Rateer-Zuverlässigkeitstests bewerten | | Agentforce \| Agentenüberwachung | ✅ Verfolgen von Eskalationsraten, stratifiziert nach Kundendemografie; höhere Raten für bestimmte Segmente zeigen, dass Agenten für diese Benutzer weniger effektiv sind | | Unternehmen \| Umfragen | ✅ Befragen Sie Benutzer aus allen demografischen Gruppen und vergleichen Sie Zufriedenheitsbewertungen. Eine insgesamt hohe Zufriedenheit kann schlechte Erfahrungen für Minderheitengruppen maskieren | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Agentforce \| Agentenkonfiguration | ⚠️ Aufnahme geschützter Merkmalsdaten (Behinderungsstatus, Religion, nationale Herkunft) in Agenteneingaben für Entscheidungen, bei denen diese Merkmale rechtlich nicht gerechtfertigt sind | | Agentforce \| Aufforderungsvorlage | ⚠️ Bereitstellen von Agenten ohne explizite Nichtdiskriminierungsanweisungen in Systemaufforderungen, die sich allein auf das Verhalten des Grundlagenmodells verlassen | | Agentforce \| Agentenkonfiguration | ⚠️ Testen von Agenten nur mit Personas mit Mehrheitsdemografie, fehlende Verzerrung gegenüber unterrepräsentierten Gruppen | | Unternehmen \| Umfragen | ⚠️ Vertrauen auf Gesamtzufriedenheitsbewertungen, die schlechte Erfahrungen für Minderheitengruppen übertönen, die von der Mehrheitszufriedenheit übertönt werden | ## Barrierefreiheit in Agentenerfahrungen **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Plattform \| LWC | ✅ Stellen Sie für benutzerdefinierte Chat-Implementierungen Folgendes sicher: semantische HTML-Struktur mit richtigen Landmarken, ARIA-Live-Regionen, in denen neue Nachrichten angekündigt werden, Tastaturnavigation durch den Nachrichtenverlauf, klare Fokusindikatoren für interaktive Elemente | | Plattform \| LWC | ✅ Testen mit JAWS, NVDA und VoiceOver während der gesamten Entwicklung, nicht nur beim automatisierten Scannen | | Agentforce \| Agentenkonfiguration | ✅ Konfigurieren Sie Agentenantworten so, dass sie für allgemeine Zielgruppen unformatiert sind; vermeiden Sie Jargon und stellen Sie Glossare für unvermeidbare Fachbegriffe bereit; strukturieren Sie lange Antworten mit Überschriften und Aufzählungslisten | | Agentforce \| Agentenkonfiguration | ✅ Die Validierungsantwortqualität ist sprachübergreifend durch die Auswertung von Muttersprachlern vergleichbar, nicht nur durch automatisierte Kennzahlen, die kulturelle Nuancen übersehen | | Agentforce \| Agentenkonfiguration | ✅ Konfigurieren Sie für geschäftskritische Anwendungsfälle, die verschiedene Sprachpopulationen bedienen, die sprachspezifische Handhabung (Sprachvariablen, lokalisierte Eingabeaufforderungen, Knowledge nach Sprache) und validieren Sie die Qualität pro Sprache, statt sich ausschließlich auf die sprachübergreifende Übertragung des Grundlagenmodells zu verlassen | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Plattform \| LWC | ⚠️ Erstellen von benutzerdefinierten Chat-Implementierungen ohne manuelle Tests für den barrierefreien Zugriff (basierend nur auf automatisiertem Scannen) | | Agentforce \| Agentenkonfiguration | ⚠️ Verwenden von Jargon und komplexer Sprache ohne Glossare zur Schaffung kognitiver Barrieren für Benutzer | | Agentforce \| Agentenkonfiguration | ⚠️ Ausschließliche Nutzung der sprachübergreifenden Übertragung von Grundlagenmodellen für Sprachen mit geringeren Ressourcen, wodurch Benutzer von Sprachen ohne Mehrheitssprachen eine schlechtere Qualität erhalten | | Agentforce \| Agentenkonfiguration | ⚠️ Validieren der mehrsprachigen Antwortqualität nur durch automatisierte Kennzahlen, die kulturelle Nuancen vermissen | ## Fairness-Governance und Bereitstellungstore **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Unternehmen \| Unternehmensführung | ✅ Richten Sie ein Ethiküberprüfungsgremium mit der Durchsetzungsbehörde ein, bevor Sie Produktionsagenten bereitstellen | | Unternehmen \| Unternehmensführung | ✅ Definieren Sie obligatorische Bereitstellungs-Gates: Datenüberprüfung, Berechnung von Fairness-Kennzahlen und algorithmische Folgenabschätzung | | Plattform \| CRM Analytics | ✅ Erstellen von Dashboards zur Überwachung der Fairness vor der ersten Agentenbereitstellung in CRM Analytics | | Plattform \| Ereignisüberwachung | ✅ Aktivieren der Einstein Trust Layer-Aktivierungserfassung und Konfigurieren der Ereignisüberwachung für Agentenaktionen als Grundlage vor der Produktion | | Unternehmen \| Unternehmensführung | ✅ Implementieren automatisierter Fairness-Regressionstests in CI/CD-Pipelines für die Skalierung | | Unternehmen \| Unternehmensführung | ✅ Standardisieren von Einwilligungsverwaltungsmustern für alle neuen Agenten bei der Skalierung von Bereitstellungen | | Plattform \| Integration | ✅ Erstellen von Tools zur Rekonstruktion von Agentenentscheidungen, die Self-Service für Compliance-Teams ermöglichen | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Unternehmen \| Unternehmensführung | ⚠️ Bereitstellen von Produktionsagenten vor der Einrichtung eines Ethik-Überprüfungsgremiums mit der Durchsetzungsbehörde | | Unternehmen \| Unternehmensführung | ⚠️ Fairness als nachträglicher Gedanke behandeln und nicht als obligatorisches Bereitstellungstor, das einer Sicherheitsüberprüfung entspricht | | Unternehmen \| Unternehmensführung | ⚠️ Überspringen algorithmischer Folgenabschätzungen vor dem Bereitstellen von Agenten, die Folgeentscheidungen treffen | | Plattform \| CRM Analytics | ⚠️ Bereitstellen des ersten Produktionsagenten ohne vorhandene Dashboards zur Überwachung der Fairness | # AI-Ethik und -Governance – Muster Erfahren Sie mehr über “Gute [Fairness](/docs/architect/de-de/well-architected/guide/fairness.html) – ethische AI-Governance [praktizieren”](/docs/architect/de-de/well-architected/guide/fairness.html#practice-ethical-ai-governance) ## Verzerrungserkennung und Fairnessvalidierung **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Einstein \| Trainingsdaten | ✅ Salesforce CRM-Daten werden vor dem Training von Prognosemodellen auf demografische Darstellungslücken und Messinkonsistenzen überprüft | | Einstein \| Trainingsdaten | ✅ Historische Konvertierungsdaten werden anhand von Kundendemografien analysiert, um unterrepräsentierte Segmente zu identifizieren, die eine Überabtastung oder zusätzliche Datenerfassung erfordern | | Einstein \| Bereitstellung | ✅ Die Fairnessbewertung wird als obligatorisches Gate behandelt, das einer Sicherheitsüberprüfung entspricht, bevor Prognosemodelle die Produktion erreichen | | Einstein \| Bereitstellung | ✅ Demografische Parität, Chancengleichheit und ungleiche Auswirkungsverhältnisse werden vor der Bereitstellung über geschützte Gruppen hinweg berechnet | | Einstein \| Bereitstellung | ✅ Fairness-Kennzahlen werden vor der Modellbereitstellung für alle Kundensegmente als Screening-Auslöser – nicht als legale Pass/Fehlschlag-Linie – anhand der Vier-Fünftel-Regel (80 %-Schwellenwert) ausgewertet | | Einstein Discovery \| Instrumentierung | ✅ Prognosemodellentscheidungsdaten – Prognoseeingaben, -ausgaben und -modellversionen – werden über Einstein Discovery und benutzerdefinierte Instrumentierung erfasst, die die Verzerrungserkennung ermöglichen | | CRM Analytics \| Überwachung | ✅ CRM Analytics-Dashboards analysieren erfasste Prognosemodell-Entscheidungsdaten für Entscheidungsmuster über demografische Gruppen hinweg im Laufe der Zeit | | CRM Analytics \| Überwachung | ✅ CRM Analytics-Benachrichtigungen werden ausgelöst, wenn die Kennzahlen für demografische Parität oder Chancengleichheit über akzeptable Schwellenwerte hinausgehen | | Einstein \| Funktionsentwicklung | ✅ Alle Prognosemodellfunktionen werden mit statistischen Methoden auf Korrelation mit geschützten Merkmalen analysiert | | Einstein \| Funktionsentwicklung | ✅ Proxy-Funktionen (Region, Postleitzahl, Accountnamenmuster, Aktivitätszeiteinteilung, Gerätetyp) werden identifiziert und auf demografische Korrelation hin ausgewertet | | Einstein \| Funktionsentwicklung | ✅ Proxy-Funktionen werden entfernt oder umgewandelt, nachdem ausgewertet wurde, ob der Prognosewert die Aufnahme trotz Proxy-Effekten rechtfertigt | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Einstein \| Trainingsdaten | ⚠️ Die Leadbewertung wird anhand von historischen Daten aus 10 Jahren trainiert, ohne die demografische Darstellung oder Servicequalitätsunterschiede zu untersuchen. | | Einstein \| Trainingsdaten | ⚠️ Historische Konvertierungsdaten werden direkt verwendet, ohne zu prüfen, ob unterschiedliche demografische Daten unterschiedlich behandelt wurden | | Einstein \| Bereitstellung | ⚠️ Einstein Funktionen werden ausschließlich anhand von allgemeinen Genauigkeitskennzahlen ohne Fairnessbewertung bereitgestellt. | | Einstein \| Bereitstellung | ⚠️ Demografische Parität oder ungleiche Auswirkungsverhältnisse werden vor der Produktionsbereitstellung nicht berechnet | | Einstein \| Trust Layer | ⚠️ Agentforce Interaktionen werden bereitgestellt, ohne die Trust Layer-Aktivierungserfassung für die Verzerrungserkennung zu aktivieren | | CRM Analytics \| Überwachung | ⚠️ Entscheidungsmuster werden im Laufe der Zeit nicht von demografischen Gruppen verfolgt; Verzerrungsabweichungen werden nicht erkannt | | Einstein \| Funktionsentwicklung | ⚠️ Geschützte Eigenschaften werden aus Trainingsdaten entfernt, vorausgesetzt, dies beseitigt automatisch Verzerrungen. | | Einstein \| Funktionsentwicklung | ⚠️ Regions-, Postleitzahlen- und Accountnamensmuster werden als Funktionen ohne Proxy-Korrelationsanalyse verwendet | | Einstein \| Funktionsentwicklung | ⚠️ Proxy-Funktionen, die als perfekte demografische Proxys dienen, werden beibehalten, ohne Alternativen zu bewerten | ## Kontinuierliche Fairnessüberwachung **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Agentforce \| Analytics | ✅ CRM Analytics-Dashboards verfolgen Agentforce-Entscheidungsergebnisse anhand von Kundendemografien mithilfe von Einstein Trust Layer-Aktivierungsdaten | | Agentforce \| Analytics | ✅ Genehmigungsraten, Serviceantwortzeiten, Eskalationsraten und Zufriedenheitsbewertungen werden stratifiziert nach demografischer Gruppe überwacht | | Agentforce \| Analytics | ✅ CRM Analytics-Benachrichtigungen werden so konfiguriert, dass sie ausgelöst werden, wenn Fairness-Kennzahlen definierte Schwellenwerte überschreiten, die untersucht werden müssen | | Agentforce \| Ereignisüberwachung | ✅ Ereignisüberwachungsprotokolle werden zur langfristigen Aufbewahrung an externes SIEM weitergeleitet, das die nativen Aufbewahrungsobergrenzen überschreitet | | Agentforce \| Ereignisüberwachung | ✅ SIEM-Abfragen identifizieren anomale Konzentrationen negativer Ergebnisse für bestimmte Benutzerpopulationen | | Agentforce \| Feld-Aktivierungsprotokoll | ✅ Das Feld-Aktivierungsprotokoll ist für benutzerdefinierte Objekte aktiviert, in denen Agentforce-Entscheidungsdaten gespeichert werden, wobei der archivierte Verlauf unbegrenzt bis zum Löschen beibehalten wird | | Agentforce \| Feld-Aktivierungsprotokoll | ✅ Field Audit Trail unterstützt langfristige Fairness-Überprüfungen und behördliche Untersuchungen, die eine Rekonstruktion historischer AI-Entscheidungen erfordern | | CRM Analytics \| Überwachung | ✅ CRM Analytics-Dashboards verfolgen Fairness-Signale: Plötzliche Änderungen in Entscheidungsverteilungen, Spitzen in verzerrten Kundenvorgängen, Leistungseinbußen für bestimmte Populationen | | CRM Analytics \| Überwachung | ✅ Warnungen werden ausgelöst, wenn die Genehmigungsraten für ein Kundensegment im Wochenvergleich um mehr als 15 % sinken, was eine Fairness-Untersuchung erfordert | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Agentforce \| Analytics | ⚠️ Entscheidungsergebnisse werden nicht anhand der demografischen Daten verfolgt; Verzerrungsabweichungen bleiben unentdeckt, wenn sich Datenverteilungen verschieben | | Agentforce \| Analytics | ⚠️ Servicequalitätskennzahlen werden nicht nach demografischer Gruppe stratifiziert; ungleiche Ergebnisse bleiben unsichtbar | | Agentforce \| Ereignisüberwachung | ⚠️ Ereignisüberwachungsprotokolle basieren auf nativen Aufbewahrungsobergrenzen ohne externes SIEM für langfristige Fairness-Audits | | Agentforce \| Ereignisüberwachung | ⚠️ Entscheidungsmuster werden nicht über große Volumen von Interaktionen hinweg analysiert; anomale Konzentrationen werden übersehen | | Agentforce \| Feld-Aktivierungsprotokoll | ⚠️ Das Feld-Aktivierungsprotokoll ist nicht aktiviert. Entscheidungen mit historischer AI können für behördliche Untersuchungen nicht rekonstruiert werden | | CRM Analytics \| Überwachung | ⚠️ Fairnesssignale werden nicht überwacht; plötzliche Änderungen in Entscheidungsverteilungen bleiben unbemerkt | ## Strategie zur Verzerrungsminderung **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Einstein \| Trainingsdaten | ✅ Salesforce CRM-Daten werden vor dem Training durch Überabtastung unterrepräsentierter Segmente oder Unterabtastung überrepräsentierter Segmente neu ausgeglichen | | Data 360 \| Architektur | ✅ Data 360 aggregiert Daten über mehrere Organisationen hinweg und stellt so verschiedene Trainingssets für Prognosemodelle sicher | | Einstein \| Trainingsdaten | ✅ Synthetische Datengenerierung ergänzt spärliche Segmente und schützt gleichzeitig die Privatsphäre durch differenzielle Datenschutztechniken | | Einstein \| Funktionsentwicklung | ✅ Proxy-Funktionen werden durch alternative Funktionen ersetzt, die Prognoseleistung ohne demografische Korrelation bieten | | Einstein \| Funktionsentwicklung | ✅ Branchenklassifizierung oder Unternehmensgröße werden anstelle der Region verwendet, wenn die Region als demografischer Proxy dient | | Einstein \| Funktionsentwicklung | ✅ Firmenspezifische Attribute werden anstelle von Accountnamenmustern verwendet, wenn Namen mit demografischen Daten korrelieren | | Agentforce \| Nachbearbeitung | ✅ Entscheidungsschwellenwerte werden pro demografischem Segment angepasst, um die Ergebnisraten nach dem Modelltraining anzugleichen, mit dem Unterschied, dass in den Vereinigten Staaten gemäß Titel VII (Civil Rights Act von 1991) keine Anpassung der Bewertungen oder Cutoffs nach geschützter Klasse für beschäftigungsbezogene Entscheidungen möglich ist und andere Rechtsordnungen ihre eigenen Einschränkungen auferlegen | | Agentforce \| Nachbearbeitung | ✅ Unterschiedliche Konfidenzschwellenwerte werden für unterschiedliche Kontexte verwendet, um gleiche Genehmigungsraten zu erzielen, während dasselbe zugrunde liegende Prognosemodell verwendet wird | | Agentforce \| Nachbearbeitung | ✅ Schwellenwertanpassungen werden mit einer geschäftlichen Begründung für eine unterschiedliche Behandlung dokumentiert, wobei anerkannt wird, dass in den Vereinigten Staaten keine Dokumentation für beschäftigungsbezogene Entscheidungen gemäß Titel VII die Bewertung pro Gruppe oder die Anpassung der Obergrenze als rechtmäßig ansieht | | Einstein \| Modellumschulung | ✅ Ein vierteljährlicher oder ereignisgesteuerter Umschulungsplan wird erstellt, um auftretende Verzerrungsmuster zu erfassen und die Abweichung von den ursprünglichen Fairness-Basiswerten zu korrigieren | | Einstein \| Modellumschulung | ✅ Fairness-Kennzahlen werden für jede Modellversion vor der Produktionsbereitstellung neu validiert, um sicherzustellen, dass die erneute Schulung keine neuen Verzerrungen verursacht hat | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Einstein \| Trainingsdaten | ⚠️ Trainingsdaten werden direkt verwendet, ohne unter- oder überrepräsentierte Segmente neu auszugleichen | | Einstein \| Trainingsdaten | ⚠️ Demografische Segmente werden nicht durch synthetische Daten oder organisationsübergreifende Aggregation ergänzt | | Einstein \| Funktionsentwicklung | ⚠️ Proxy-Funktionen werden beibehalten, ohne alternative Funktionen auszuwerten, die Prognosekraft ohne demografische Korrelation bieten | | Agentforce \| Nachbearbeitung | ⚠️ Für alle demografischen Segmente gelten dieselben Konfidenzschwellenwerte, ohne die Ergebnisraten zu entzerren | | Agentforce \| Nachbearbeitung | ⚠️ Eine unterschiedliche Behandlung durch Schwellenwertanpassungen ist nicht dokumentiert oder wird in den USA überhaupt auf beschäftigungsbezogene Entscheidungen angewendet, wenn Titel VII die Anpassung von Bewertungen oder Cutoffs nach geschützter Klasse unabhängig von der Dokumentation verbietet. | | Einstein \| Modellumschulung | ⚠️ Modelle werden bereitgestellt und nie neu trainiert; neu auftretende Verzerrungsmuster und Drift werden nicht korrigiert | | Einstein \| Modellumschulung | ⚠️ Umschulung erfolgt ohne erneute Validierung von Fairnesskennzahlen; neue Verzerrung wird stillschweigend eingeführt | ## Erklärbarkeit und Transparenz von AI **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Einstein Discovery \| UX | ✅ Einstein Discovery-Erläuterungen, die Prognosefaktoren zeigen, werden in Lightning-Komponenten am Entscheidungspunkt angezeigt | | Einstein Discovery \| UX | ✅ Erläuterungen zeigen, welche Variablen bestimmte Prognosen am stärksten beeinflusst haben, mit richtungsbezogenen Auswirkungen für Benutzer an Entscheidungspunkten | | Einstein Discovery \| UX | ✅ Erklärungen sind für verschiedene Zielgruppen mehrschichtig: Geschäftsbenutzer, technische Benutzer, Kunden und Prüfer | | Einstein Discovery \| UX | ✅ Geschäftsbenutzern wird "Dieser Lead wurde hoch bewertet, da der Jahresumsatz über 1 Mio. EUR liegt und die Engagementbewertung unter den besten 10 % liegt" angezeigt | | Einstein Discovery \| UX | ✅ Technische Benutzer sehen Modellkarten mit Funktionsgewichtungen, Trainingsdateneigenschaften und Validierungskennzahlen | | Einstein Discovery \| UX | ✅ Kunden wird angezeigt "Diese Empfehlung basiert auf Ihren letzten Käufen und Kunden mit ähnlichen Voreinstellungen" | | Einstein Discovery \| UX | ✅ Prüfern wird die vollständige Entscheidungslinie von Einstein Discovery und dem Modell-Manager mit Modellversion, Eingabewerten und den Faktoren angezeigt, die die Prognose ausgelöst haben | | Einstein Discovery \| UX | ✅ Die Prognosekonfidenz wird benutzergerecht als Kategorien (Hohe Konfidenz, Mäßige Konfidenz, Überprüfung erforderlich) mit Erläuterungen angezeigt | | Einstein Discovery \| UX | ✅ Konfidenzkategorien erläutern, was Konfidenzniveau für die Zuverlässigkeit von Entscheidungen bedeutet und welche zusätzliche Überprüfung erfolgen wird | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Einstein Discovery \| UX | ⚠️ Erläuterungen werden nach der Bereitstellung auf opake Systeme umgerüstet, statt die Erklärbarkeit von Anfang an in die Architektur einzubauen | | Einstein Discovery \| UX | ⚠️ Prognoseerklärungen erfordern die Navigation zum Trennen von CRM Analytics-Dashboards, statt sie an Entscheidungspunkten anzuzeigen | | Einstein Discovery \| UX | ⚠️ Benutzern werden abstrakte Modellleistungskennzahlen anstelle transparenter Erklärungen angezeigt, wenn sie von Entscheidungen betroffen sind | | Einstein Discovery \| UX | ⚠️ Erläuterungen variieren nicht je nach Zielgruppe. Technische Modellkarten werden Kunden oder Geschäftsbenutzern angezeigt | | Einstein Discovery \| UX | ⚠️ Rohprognosebewertungen (0,73) werden ohne Erklärung angezeigt, was die Zahl bedeutet oder welche Faktoren die Prognose angetrieben haben | | Einstein Discovery \| UX | ⚠️ Konfidenz wird als Wahrscheinlichkeitsprozentsatz angezeigt, den Benutzer ohne Kontext hinsichtlich Zuverlässigkeit oder Überprüfung falsch interpretieren | ## Audit Trail und Compliance **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Einstein \| Trust Layer | ✅ Einstein Trust Layer protokolliert Eingabeaufforderungen, Antworten, Erdungsquellen und Trust Signale automatisch ohne benutzerdefinierte Instrumentierung | | Einstein \| Trust Layer | ✅ Datenaufbewahrungsrichtlinien werden so konzipiert, dass sie die gesetzlichen Anforderungen erfüllen, die je nach Branche und Gerichtsbarkeit variieren (beispielsweise legt FINRA-Regel 4511(b) einen standardmäßigen Aufbewahrungszeitraum von sechs Jahren fest und HIPAA schreibt für die Konformitätsdokumentation mindestens sechs Jahre vor). | | CRM Analytics \| Überwachung | ✅ CRM Analytics-Dashboards analysieren erfasste Prognosemodell-Entscheidungsdaten auf Entscheidungsmuster, Fairness-Kennzahlen und die Modellleistung im Zeitverlauf | | CRM Analytics \| Überwachung | ✅ CRM Analytics-Linsen zeigen Prognoseverteilungen nach Konfidenzstufe, demografischem Segment und Ergebnistyp an | | CRM Analytics \| Überwachung | ✅ Einstein Discovery Artikel identifizieren anormale Muster, die untersucht werden müssen | | Plattform \| Feld-Aktivierungsprotokoll | ✅ Das Feld-Aktivierungsprotokoll ist für benutzerdefinierte Objekte aktiviert, in denen AI-Entscheidungsdaten gespeichert werden, wobei der archivierte Verlauf für Einwilligungsdatensätze, Überschreibungsentscheidungen und Verzerrungsberichte unbegrenzt beibehalten wird | | Plattform \| Ereignisüberwachung | ✅ Die Ereignisüberwachung erfasst Agentforce-Unterhaltungsabschriften, Toolaufrufe und Entscheidungspunkte | | Plattform \| Ereignisüberwachung | ✅ Ereignisüberwachungsprotokolle werden über Plattformereignisse zur manipulationssicheren Speicherung an externes SIEM weitergeleitet | | Plattform \| Ereignisüberwachung | ✅ SIEM-Abfragen erkennen Verzerrungsmuster in großen Volumen von Agentforce Interaktionen | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Einstein \| Trust Layer | ⚠️ Agentforce-Interaktionen werden bereitgestellt, ohne die Trust Layer-Aktivierungserfassung zu aktivieren oder Aufbewahrungsrichtlinien zu definieren | | Einstein \| Trust Layer | ⚠️ Aufbewahrungsrichtlinien berücksichtigen keine branchenspezifischen regulatorischen Anforderungen (Finanzdienstleistungen, Gesundheitswesen) | | CRM Analytics \| Überwachung | ⚠️ Die erfassten Entscheidungsdaten des Prognosemodells werden nicht analysiert. Entscheidungsmuster und Fairness-Kennzahlen werden im Laufe der Zeit nicht verfolgt | | Plattform \| Feld-Aktivierungsprotokoll | ⚠️ Standardmäßiger 18-monatiger Feldverlauf für AI-Entscheidungs-Aktivierungsprotokolle ohne Berücksichtigung gesetzlicher Aufbewahrungsanforderungen | | Plattform \| Feld-Aktivierungsprotokoll | ⚠️ Das Feld-Aktivierungsprotokoll ist für Objekte mit Einwilligungsdatensätzen, Überschreibungsentscheidungen und Verzerrungsberichten nicht aktiviert | | Plattform \| Ereignisüberwachung | ⚠️ Ereignisüberwachungsprotokolle basieren auf nativen Aufbewahrungsobergrenzen ohne externes SIEM für manipulationssichere Langzeitspeicherung | | Plattform \| Ereignisüberwachung | ⚠️ Agentforce-Interaktionsprotokolle werden nicht auf Verzerrungsmuster in großen Volumen analysiert | ## Positionierung zur Einhaltung gesetzlicher Vorschriften **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Governance \| EU AI Act | ✅ AI-Systeme mit hohem Risiko werden mit Transparenzdokumentation, technischer Dokumentation, menschlichen Aufsichtsfunktionen und Genauigkeits-/Fairnesskennzahlen dokumentiert | | Governance \| EU AI Act | ✅ Einstein Trust Layer-Aktivierungsprotokolle und Discovery-Modellkarten bieten Grundlagen für die Transparenzanforderungen des EU-AI-Gesetzes | | Governance \| EU AI Act | ✅ Modelltrainingsdatendemografien, Validierungsansätze und bekannte Einschränkungen werden in Architekturentscheidungsdatensätzen dokumentiert | | Unternehmensführung \| DSGVO | ✅ Systeme generieren kohärente Erklärungen für jede historische Entscheidung auf Anforderung innerhalb des Zeitrahmens für die Zugriffsanforderung der betroffenen Person (der je nach Zuständigkeit zwischen 15 und 45 Tagen variiert) | | Unternehmensführung \| DSGVO | ✅ Erfasste Prognosemodell-Entscheidungsdaten und Einstein Discovery Erklärungsfaktoren werden mit ausreichender Aufbewahrung gespeichert, um die Erklärungsrekonstruktion für das Recht auf Erklärung der DSGVO zu ermöglichen | | Governance \| Algorithmische Verantwortlichkeit | ✅ Algorithmische Folgenabschätzungen werden durchgeführt, bevor konsequente AI als proaktive Compliance und nicht als reaktive Reaktion bereitgestellt wird | | Governance \| Algorithmische Verantwortlichkeit | ✅ Erfasste Prognosemodell-Entscheidungsdaten und CRM Analytics-Dashboards zur Fairness-Überwachung bieten Datengrundlagen für Berichte zur algorithmischen Verantwortlichkeit | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Governance \| EU AI Act | ⚠️ AI-Systeme mit hohem Risiko werden ohne Transparenzdokumentation, menschliche Aufsichtsfunktionen oder Fairnesskennzahlen bereitgestellt | | Governance \| EU AI Act | ⚠️ Demografische Daten zum Modelltraining und bekannte Einschränkungen sind in Architekturentscheidungsdatensätzen nicht dokumentiert | | Unternehmensführung \| DSGVO | ⚠️ Systeme können keine kohärenten Erklärungen für historische Entscheidungen innerhalb des Zeitrahmens der DSGVO-Anforderungen für den Zugriff betroffener Personen generieren | | Unternehmensführung \| DSGVO | ⚠️ Die Datenaufbewahrung im Prognosemodell für Entscheidungen reicht nicht aus, um die Erklärungsrekonstruktion für vergangene Entscheidungen zu unterstützen | | Governance \| Algorithmische Verantwortlichkeit | ⚠️ Algorithmische Folgenabschätzungen werden nicht vor der Bereitstellung von konsequenter AI durchgeführt; die Compliance ist nach behördlicher Untersuchung reaktiv | ## Datenzugriff und Nichtdiskriminierung **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Plattform \| OWD | ✅ Private organisationsweite Standardeinstellungen werden für Objekte festgelegt, die vertrauliche Kundendaten enthalten, deren Zugriff über Rollenhierarchie und Freigaberegeln erteilt wird | | Plattform \| OWD | ✅ Private OWDs mit expliziten Freigabegewährungen erstellen überprüfbare Zugriffsmuster zur Unterstützung der Nichtdiskriminierungs-Compliance | | Plattform \| Feldebenensicherheit | ✅ Vertrauliche Felder mit geschützten Merkmalen (Ethnie, Religion, Behinderungsstatus) werden über FLS für Benutzer ohne legitimen Geschäftsbedarf ausgeblendet | | Plattform \| Feldebenensicherheit | ✅ Der Lesezugriff auf sensible Felder wird für die meisten Profile über FLS entfernt. Der Zugriff wird nur minimal über Berechtigungssätze mit dokumentierter Begründung gewährt. | | Plattform \| Zuweisung und Weiterleitung | ✅ Zuweisungsregeln, Warteschlangen und die Omnikanal-Weiterleitung verteilen Arbeit gleichmäßig auf Regionen, Teams und Serviceagenten basierend auf objektiven Kriterien | | Plattform \| Freigaberegeln | ✅ Automatische Freigaberegeln basieren auf objektiven Kriterien (Branche, geografische Daten, Produktlinie) und nicht auf dem Ermessen des subjektiven Managers | | Plattform \| Berechtigungssätze | ✅ Der temporäre Zugriff auf sensible Daten wird über Berechtigungssätze mit dokumentiertem Ablauf statt über dauerhafte Profiländerungen gewährt | | Plattform \| Berechtigungssätze | ✅ Geplanter Flow widerruft Berechtigungssätze automatisch nach definierten Zeiträumen, wenn für bestimmte Projekte Zugriff auf demografische Daten erforderlich ist | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Plattform \| OWD | ⚠️ Öffentliche Lese-/Schreibzugriffsberechtigungen machen das Einschränken des Zugriffs später störend (eine strengere Standardeinstellung löst eine Freigabeneuberechnung aus); überprüfbare Zugriffsmuster sind nicht vorhanden | | Plattform \| OWD | ⚠️ Account-OWD ist auf "Öffentlicher Lese-/Schreibzugriff" festgelegt, wobei ungeschützte demografische Felder für alle Benutzer sichtbar sind und eine subjektive Verzerrung aktiviert ist | | Plattform \| Feldebenensicherheit | ⚠️ Vertrauliche demografische Felder sind für alle Profile ohne FLS-Einschränkungen sichtbar; diskriminierende Datennutzung wird nicht verhindert | | Plattform \| Freigaberegeln | ⚠️ Die manuelle Freigabe konzentriert hochwertige Opportunities auf bestimmte Benutzergruppen ohne dokumentierte geschäftliche Begründung | | Plattform \| Freigaberegeln | ⚠️ Freigaberegeln basieren auf dem Ermessen des subjektiven Managers und nicht auf objektiven Kriterien, die eine Verzerrung ermöglichen | | Plattform \| Berechtigungssätze | ⚠️ Profile werden dauerhaft für alle Benutzer geändert, statt temporären Zugriff über Berechtigungssätze zu gewähren | | Plattform \| Berechtigungssätze | ⚠️ Berechtigungssätze, die Zugriff auf sensible Daten gewähren, laufen nicht automatisch ab. Der Zugriff bleibt nach Abschluss des Projekts unbegrenzt | ## Zugriffsmusterüberwachung **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Shield \| Ereignisüberwachung | ✅ Die Shield-Ereignisüberwachung verfolgt den Zugriff auf Felder mit geschützten Merkmalen oder sensiblen Attributen | | Shield \| Ereignisüberwachung | ✅ Ereignisüberwachungsabfragen verfolgen, wer wann und in welchem Kontext auf demografische Felder zugreift und anormale Muster erkennt | | Shield \| Ereignisüberwachung | ✅ Anomale Zugriffsmuster (plötzliche Spitzen, Zugriff durch unerwartete Benutzer) lösen Untersuchung auf potenziellen Missbrauch aus | | Plattform \| Berichte | ✅ In Berichten wird analysiert, wie Freigaberegeln Datensätze auf Benutzer, Teams und Regionen verteilen, um Verteilungsstatistiken nach Kundendemografien zu berechnen. | | Plattform \| Berichte | ✅ Berichte identifizieren Konzentrationen, in denen bestimmte Benutzergruppen unverhältnismäßigen Zugriff auf wertvolle Datensätze ohne dokumentierte Begründung erhalten | | Plattform \| Setup-Aktivierungsprotokoll | ✅ Setup-Aktivierungsprotokoll wird auf Änderungen an OWD-Einstellungen, Freigaberegeln, FLS-Konfigurationen und Berechtigungssätzen überprüft, die nicht autorisierte Änderungen erkennen | | Plattform \| Transaktionssicherheit | ✅ Transaktionssicherheitsrichtlinien reagieren auf Ereignisse der Echtzeit-Ereignisüberwachung mit hohem Risiko (anomale API-Aktivität, verdächtige Anmeldungen, großer Export vertraulicher Daten); FLS- und Freigabeänderungen basieren auf dem Setup-Aktivierungsprotokoll und dokumentierten Genehmigungen für die Änderungsverwaltung | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Shield \| Ereignisüberwachung | ⚠️ Der Zugriff auf sensible demografische Felder wird nicht überwacht; potenzieller Missbrauch wird nicht erkannt | | Shield \| Ereignisüberwachung | ⚠️ Anomale Zugriffsmuster (Spikes, unerwartete Benutzer) werden nicht verfolgt oder untersucht | | Plattform \| Berichte | ⚠️ Verteilungen von Freigaberegeln werden nicht analysiert; unverhältnismäßiger Zugriff auf wertvolle Datensätze bleibt unsichtbar | | Plattform \| Berichte | ⚠️ Bei Konzentrationen von Accounts mit hohem Wert und bestimmten Benutzergruppen fehlt eine dokumentierte geschäftliche Begründung | | Plattform \| Setup-Aktivierungsprotokoll | ⚠️ Das Setup-Aktivierungsprotokoll wird nicht überprüft. Nicht autorisierte Änderungen an Datenzugriffssteuerungen, die den Zugriff auf sensible Daten ermöglichen, werden nicht erkannt | | Plattform \| Transaktionssicherheit | ⚠️ Ereignisse der Echtzeit-Ereignisüberwachung mit hohem Risiko (anomale API-Aktivität, großer Export vertraulicher Daten) werden nicht mit Transaktionssicherheitsrichtlinien verarbeitet | ## Benutzereinwilligungsverwaltung **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Plattform \| Benutzerdefinierte Objekte | ✅ Die granulare Einwilligung pro AI-Anwendungsfall wird durch den benutzerdefinierten Zweck der Einwilligungsobjektverfolgung, das Datum/die Methode der Erteilung, das Widerrufsdatum und die zugehörige Benutzer-/Kontakt-ID aktiviert | | Plattform \| Benutzerdefinierte Objekte | ✅ Kunden stimmen Einstein Produktempfehlungen zu, während sie AI-gestützte Kreditentscheidungen über separate Einwilligungsdatensätze pro Anwendungsfall ablehnen | | Plattform \| Feld-Aktivierungsprotokoll | ✅ Das Feld-Aktivierungsprotokoll ist für das Einwilligungsobjekt für die langfristige Aufbewahrung aktiviert, die den gesetzlichen Anforderungen entspricht | | Data 360 \| Einwilligung | ✅ Die Data 360-Einwilligungsverwaltung wird für Funktionen der Einstein-Personalisierung verwendet. Dabei werden Einwilligungsvoreinstellungen über Konnektoren aufgenommen und gespeichert, die dem Datenmodell für den Datenschutz zugeordnet sind. | | Data 360 \| Einwilligung | ✅ Einwilligungskategorien werden bestimmten AI-Anwendungsfällen zugeordnet, sodass Benutzer sich von der Personalisierung abmelden und gleichzeitig den Kernservice aufrechterhalten können | | Marketing Cloud \| Einwilligung | ✅ Marketing Cloud-Einwilligung kann in Einstein Messaging Insights und Agentforce Marketing Agenten integriert werden, die den Abonnementstatus berücksichtigen | | Marketing Cloud \| Einwilligung | ✅ Marketing Cloud-Einwilligungsstatus wird abgefragt, bevor Agentforce die automatisierte Kontaktaufnahme initiiert und unerwünschten Kontakt mit Benutzern verhindert, die sich abgemeldet haben | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Plattform \| Benutzerdefinierte Objekte | ⚠️ Die AI-Einwilligung wird in Tabellenblättern verfolgt oder basiert auf der Anmeldung als implizite allgemeine Einwilligung ohne explizite Datensätze | | Plattform \| Benutzerdefinierte Objekte | ⚠️ Die Einwilligung mit leerer AI wird anstelle einer detaillierten Einwilligung pro Anwendungsfall verwendet. Benutzer können sich nicht von bestimmten AI-Funktionen abmelden | | Plattform \| Feld-Aktivierungsprotokoll | ⚠️ Das Feld-Aktivierungsprotokoll ist für das Einwilligungsobjekt nicht aktiviert. Die langfristige Aufbewahrung, die den gesetzlichen Anforderungen entspricht, wird nicht beibehalten | | Data 360 \| Einwilligung | ⚠️ Data 360-Einwilligungen werden nicht zur Einstein-Personalisierung verwendet. Einwilligungskategorien werden keinen bestimmten Anwendungsfällen zugeordnet | | Marketing Cloud \| Einwilligung | ⚠️ Marketing Cloud-Einwilligung ist nicht in Einstein oder Agentforce integriert. Der Abonnementstatus wird bei der automatisierten Kontaktaufnahme nicht berücksichtigt | ## Abmelden und Benutzerpräferenz **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Experience Cloud \| Profileinstellungen | ✅ Benutzer können Agentforce-Interaktionen über das barrierefreie Voreinstellungssteuerfeld in den Experience Cloud-Profileinstellungen oder "Meine Einstellungen" mit klaren Beschreibungen deaktivieren | | Plattform \| Benutzer-/Kontaktdatensätze | ✅ AI-Voreinstellungen werden in Benutzer- oder Kontaktdatensätzen gespeichert, die eine Abfrage in der Entscheidungslogik von Flow und Agentforce ermöglichen | | Agentforce \| Omnikanal | ✅ Benutzer, die sich von Agentforce abmelden, werden über Omnikanal an menschliche Agenten weitergeleitet, statt einen beeinträchtigten Service zu erhalten | | Agentforce \| Flow | ✅ Flow überprüft Einwilligungs- und Voreinstellungsfelder vor dem Agentforce Engagement. Wenn sich der Benutzer abgemeldet hat, wird ein Arbeitsdatensatz erstellt und an die menschliche Warteschlange weitergeleitet | | Agentforce \| Omnikanal | ✅ Human Queue Staffing bietet Benutzern, die sich abgemeldet haben, vergleichbare Wartezeiten wie automatisierte Services | | Plattform \| Benutzer-/Kontaktdatensätze | ✅ AI-Voreinstellungen werden in Benutzer- oder Kontaktdatensätzen gespeichert, um die Konsistenz zwischen Kanälen (Web, Mobiltelefon, Telefon, E-Mail) zu gewährleisten | | Plattform \| Flow | ✅ Die Voreinstellung wird in allen Interaktions-Flows konsistent abgefragt und verhindert, dass Benutzer Voreinstellungen in jedem Kanal wiederholt bestätigen müssen | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Experience Cloud \| Profileinstellungen | ⚠️ Die Abmeldung ist nur per E-Mail an das Supportteam verfügbar. Steuerelemente für barrierefreie Voreinstellungen sind nicht vorhanden | | Plattform \| Benutzer-/Kontaktdatensätze | ⚠️ AI-Voreinstellungen werden nicht in Benutzer- oder Kontaktdatensätzen gespeichert. Voreinstellungen können nicht in der Flow- oder Agentforce-Logik abgefragt werden | | Agentforce \| Omnikanal | ⚠️ Benutzer, die sich abmelden, erhalten einen beeinträchtigten Service als impliziten Druck, KI zu akzeptieren, statt sie an menschliche Agenten weiterzuleiten | | Agentforce \| Flow | ⚠️ Der Flow überprüft weder Einwilligungs- noch Voreinstellungsfelder vor dem Agentforce Engagement. | | Plattform \| Benutzer-/Kontaktdatensätze | ⚠️ Die Voreinstellungen sind nicht kanalübergreifend konsistent. Benutzer müssen die Abmeldung in Web, Mobiltelefon, Telefon und E-Mail separat erneut geltend machen | ## Dokumentation zur AI-Governance **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Governance \| Dokumentation | ✅ Jedes Produktionsprognosemodell wird mit Trainingsdatendemografien, Fairnesskennzahlen, vorgesehenen Anwendungsfällen, Strategien zur Verzerrungsminderung und Überwachungsansätzen dokumentiert | | Governance \| Dokumentation | ✅ Die Modelldokumentation enthält den Fairness-Monitoring-Ansatz, Warnschwellenwerte, Anforderungen an die menschliche Aufsicht, Überprüfungszeitplan und behördliche Überlegungen | | Plattform \| Benutzerdefinierte Objekte | ✅ Die Modelldokumentation wird in Salesforce mithilfe des benutzerdefinierten Modellobjekts oder der an Projekte angehängten Salesforce Files gespeichert, wodurch die Durchsuchbarkeit und Versionskontrolle ermöglicht wird | | Governance \| Bereitstellungstore | ✅ Fairness-Gates vor der Bereitstellung erfordern die Überprüfung von Trainingsdaten, die Berechnung von Fairness-Kennzahlen, die Folgenabschätzung, das Design der menschlichen Aufsicht und die Transparenzprüfung vor der Produktion | | Governance \| Bereitstellungstore | ✅ Trainingsdatendarstellungslücken werden analysiert und als obligatorisches Bereitstellungs-Gate dokumentiert | | Governance \| Bereitstellungstore | ✅ Demografische Parität, Chancengleichheit und ungleiche Auswirkungen sind berechnete Schwellenwerte für die Einhaltung als obligatorisches Gate | | Governance \| Bereitstellungstore | ✅ Folgenabschätzung wertet potenzielle Schäden in betroffenen Bevölkerungsgruppen als obligatorisches Tor aus | | Governance \| Bereitstellungstore | ✅ Das Design der menschlichen Aufsicht, einschließlich Eskalationsmustern, Genehmigungsworkflows und Überschreibungsmechanismen, wurde als obligatorisches Gate konzipiert und getestet | | Governance \| Bereitstellungstore | ✅ Erklärungsfunktionen werden für alle Entscheidungstypen als obligatorisches Gate validiert | | Governance \| Bereitstellungstore | ✅ Fairness-Gates werden mit der gleichen Strenge behandelt wie Sicherheits-Gates mit der Berechtigung, Bereitstellungen zu blockieren, bei denen ein Gate fehlschlägt | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Governance \| Dokumentation | ⚠️ Einstein Funktionen werden bereitgestellt, ohne Trainingsdaten, Fairnesskennzahlen, Verzerrungsminderung oder Überwachungsansätze zu dokumentieren | | Governance \| Dokumentation | ⚠️ Die Modelldokumentation enthält weder den Fairness-Monitoring-Ansatz noch die Anforderungen an die menschliche Aufsicht oder behördliche Überlegungen. | | Plattform \| Benutzerdefinierte Objekte | ⚠️ Die Modelldokumentation wird in Tabellenblättern oder Wikis ohne Durchsuchbarkeit oder Versionskontrolle gespeichert | | Governance \| Bereitstellungstore | ⚠️ Einstein-Funktionen werden ohne Fairness-Gate in die Produktion übernommen. Die Bereitstellung basiert ausschließlich auf den allgemeinen Genauigkeitskennzahlen. | | Governance \| Bereitstellungstore | ⚠️ Die Überprüfung von Trainingsdaten, die Berechnung von Fairness-Kennzahlen oder die Folgenabschätzung werden vor der Produktionsbereitstellung übersprungen | | Governance \| Bereitstellungstore | ⚠️ Human Oversight Design, Transparenzüberprüfung oder Erklärungsvalidierung werden nicht vor der Produktion durchgeführt | | Governance \| Bereitstellungstore | ⚠️ Fairness-Gates sind nur für Empfehlungen vorgesehen und nicht berechtigt, Bereitstellungen zu blockieren. Modelle werden trotz fehlender Fairness-Kriterien fortgesetzt | ## AI Ethics Review Board (Überprüfungsausschuss für AI-Ethik) **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Governance \| Überprüfungsausschuss | ✅ Der Überprüfungsausschuss besteht aus technischen Experten (Architekten, Datenwissenschaftlern), Wirtschaftsbeteiligten, Rechtsanwälten, Datenschutzexperten und Vertretern betroffener Communities | | Governance \| Überprüfungsausschuss | ✅ Diverse Perspektiven zeigen Fairnessprobleme auf, die homogene Gruppen bei der Ethiküberprüfung vermissen | | Governance \| Auslöser überprüfen | ✅ Überprüfungsauslöser sind definiert: Entscheidungen über Beschäftigung/Kredit/Wohnen/Gesundheitswesen/Rechtsansprüche, Systeme, die jährlich mehr als 10.000 Benutzer betreffen, neue Anwendungsfälle, erhebliches Schadensrisiko | | Governance \| Auslöser überprüfen | ✅ AI-Anwendungen, die sensible personenbezogene Daten (gesundheitliche, finanzielle, demografische) verwenden, müssen vor der Bereitstellung ethisch überprüft werden | | Governance \| Überprüfungsstelle | ✅ Ethik-Überprüfungsgremium ist berechtigt, Änderungen zu verlangen, Überwachungsbedingungen aufzuerlegen oder Bereitstellungen zu blockieren, die gegen ethische Standards verstoßen | | Plattform \| Benutzerdefinierte Objekte | ✅ Alle Überprüfungen sind im Namen des benutzerdefinierten Salesforce-Objekts zur Verfolgung von Anwendungen, im Überprüfungsdatum, in den vorgebrachten Bedenken, in den Anforderungen zur Eindämmung und in den Genehmigungsbedingungen dokumentiert. | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Governance \| Überprüfungsausschuss | ⚠️ Dem Überprüfungsausschuss fehlt es an Vielfalt (nur technische Experten); homogene Gruppen vermissen Fairnessprobleme, die sich auf unterschiedliche Populationen auswirken | | Governance \| Überprüfungsausschuss | ⚠️ Vertreter aus betroffenen Communities werden nicht einbezogen; blinde Flecken in Fairness-Überlegungen resultieren | | Governance \| Auslöser überprüfen | ⚠️ Überprüfungsauslöser werden nicht definiert. Anwendungen mit AI mit hohem Risiko werden vor der Bereitstellung ohne Ethiküberprüfung ausgeführt | | Governance \| Überprüfungsstelle | ⚠️ Ethiküberprüfung ist nur beratend ohne Durchsetzung; Bereitstellungen erfolgen trotz mangelhafter ethischer Standards (Rechenschaftspflichttheater) | | Plattform \| Benutzerdefinierte Objekte | ⚠️ Überprüfungen werden nicht systematisch dokumentiert. Entscheidungen, Bedenken und Minderungen bei historischen Überprüfungen werden nicht verfolgt | ## Kontinuierliche Fairness-Governance **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | CRM Analytics \| Überwachung | ✅ CRM Analytics-Dashboards verfolgen Fairness-Kennzahlen für Einstein und Agentforce aus erfassten Entscheidungsdaten und Trust Layer-Aktivierungsdaten in einem geplanten Rhythmus | | CRM Analytics \| Überwachung | ✅ Demografische Parität, Chancengleichheit, ungleiche Auswirkungsverhältnisse und Servicequalitätskennzahlen werden nach Kundensegment überwacht | | CRM Analytics \| Überwachung | ✅ CRM Analytics-Benachrichtigungen werden so konfiguriert, dass sie ausgelöst werden, wenn Fairness-Kennzahlen definierte Schwellenwerte überschreiten, die untersucht werden müssen | | CRM Analytics \| Überwachung | ✅ CRM Analytics-Dashboards verfolgen Fairness-Signale: Plötzliche Änderungen in Entscheidungsverteilungen, Spitzen in verzerrten Kundenvorgängen, Leistungseinbußen für bestimmte Populationen | | CRM Analytics \| Überwachung | ✅ Benachrichtigungen werden für Einstein Opportunity-Bewertungen ausgelöst, wenn die Genehmigungsraten für ein Segment im Wochenvergleich um mehr als 15 % sinken. | | Governance \| Geplante Prüfungen | ✅ Umfassende Fairness-Prüfungen werden vierteljährlich für AI mit hohem Anteil (Kredit, Beschäftigung, Gesundheitswesen) oder halbjährlich für Systeme mit niedrigem Anteil durchgeführt | | Governance \| Geplante Prüfungen | ✅ Audits untersuchen aktuelle Fairness-Kennzahlen, überprüfen Überschreibungsmuster, analysieren Benutzerfeedback und Verzerrungsberichte und validieren, dass die Governance-Kontrollen wirksam bleiben | | Governance \| Vorfallsreaktion | ✅ Klare Reaktion auf Vorfälle werden in Salesforce Knowledge dokumentiert, um bei erkannter Verzerrung zu reagieren | | Governance \| Vorfallsreaktion | ✅ Sofortige Schweregradbewertung durch Abfragen von Prognosemodell-Entscheidungsdaten in CRM Analytics; starke Verzerrung setzt automatisierte Entscheidungsfindung ausstehender Untersuchungen aus | | Governance \| Vorfallsreaktion | ✅ Temporäre Abhilfe implementiert eine verbesserte menschliche Aufsicht durch angepasste Konfidenzschwellenwerte, Funktionsdeaktivierung oder vollständige Agentenaussetzung | | Governance \| Vorfallsreaktion | ✅ Die Ursachenanalyse identifiziert, wie Verzerrungen eingetreten sind oder sich weiterentwickelt haben. Trainingsdaten, Modellversionen und Konfigurationsänderungen werden über den Field Audit Trail analysiert | | Governance \| Vorfallsreaktion | ✅ Die dauerhafte Korrektur implementiert Datenkorrekturen, Modellumschulungen oder Prozessänderungen mit entsprechender Kommunikation an betroffene Benutzer | | Governance \| Vorfallsreaktion | ✅ Präventionsmaßnahmen werden in Runbooks dokumentiert, um ein erneutes Auftreten von Verzerrungen zu verhindern | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | CRM Analytics \| Überwachung | ⚠️ Fairness-Kennzahlen werden in keinem geplanten Rhythmus aus erfassten Entscheidungsdaten oder Trust Layer-Aktivierungsdaten verfolgt. Verzerrungen bleiben unerkannt, wenn sich Datenverteilungen ändern | | CRM Analytics \| Überwachung | ⚠️ CRM Analytics-Benachrichtigungen sind nicht konfiguriert. Verstöße gegen Fairness-Kennzahlen, die untersucht werden müssen, werden nicht ausgelöst | | CRM Analytics \| Überwachung | ⚠️ Fairnesssignale werden nicht überwacht; plötzliche Änderungen in Entscheidungsverteilungen werden nicht erkannt | | Governance \| Geplante Prüfungen | ⚠️ Umfassende Fairness-Audits werden nicht nach einem Zeitplan durchgeführt; Governance-Kontrollen weichen ab und werden ineffektiv | | Governance \| Geplante Prüfungen | ⚠️ Überschreibungsmuster, Benutzerfeedback und Verzerrungsberichte werden während der Prüfungen nicht systematisch analysiert | | Governance \| Vorfallsreaktion | ⚠️ Eindeutige Reaktion auf Vorfälle sind nicht dokumentiert; die Verzerrungserkennung führt zu Ad-hoc-Antworten ohne systematischen Ansatz | | Governance \| Vorfallsreaktion | ⚠️ Temporäre Abhilfe oder dauerhafte Behebung werden nicht systematisch implementiert; Verzerrungen wirken sich weiterhin auf Benutzer aus | | Governance \| Vorfallsreaktion | ⚠️ Eine Ursachenanalyse wird nicht durchgeführt. Wie eine Verzerrung eingetreten ist oder sich entwickelt hat, bleibt unbekannt | | Governance \| Vorfallsreaktion | ⚠️ Präventionsmaßnahmen werden nicht dokumentiert; Wiederholungen werden nicht verhindert | ## Datenqualität und Darstellungsgerechtigkeit **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Plattform \| Pflichtfelder | ✅ Jedes Pflichtfeld enthält eine dokumentierte geschäftliche Begründung dafür, warum die Daten obligatorisch und nicht optional sind. Felder, ohne die ein Prozess funktionieren kann, werden als optional mit nachgelagerter Verarbeitung für fehlende Werte festgelegt | | Plattform \| Pflichtfelder | ✅ E-Mail ist optional mit alternativen Kommunikationsmethoden (SMS, Telefon, Post), sodass Benutzer ohne zuverlässiges Internet oder persönliche E-Mails nicht von der Accounterstellung ausgeschlossen werden | | Plattform \| Namensfelder | ✅ Die Namensarchitektur verwendet ein einzelnes vollständiges Namensfeld oder eine flexible mehrteilige Struktur, die Mononyme, patronymische Systeme und mehrere Vor- oder Nachnamen aufnimmt, ohne Reihenfolge oder Übernahme anzunehmen | | Plattform \| Namensfelder | ✅ Namensfelder werden mit verschiedenen internationalen Namen getestet und akzeptieren Einzelwortnamen, Langnamen, Diakritika, Apostrophe, Bindestriche und nicht-lateinische Schriften (Arabisch, Chinesisch, Kyrillisch, Devanagari) | | Plattform \| Adressvalidierung | ✅ Die Validierung zulässiger Adressen akzeptiert die Freiformeingabe, wenn die strukturierte Validierung fehlschlägt, und speichert Adressen, während Benutzer sie eingeben, statt ungültige Korrekturen zu erzwingen | | Plattform \| Adressvalidierung | ✅ Die Adressüberprüfung ist in Abwicklungsprozesse integriert, bei denen es auf Genauigkeit ankommt, statt die Datenerfassung im Voraus zu blockieren | | Plattform \| Kommunikationsvoreinstellungen | ✅ Bevorzugte Kommunikationsmethoden werden in Kontaktdatensätzen gespeichert und in allen ausgehenden Systemen einheitlich berücksichtigt, sodass Omnikanal-Alternativen anstelle von Einzelkanalannahmen angeboten werden | | Benutzerdefiniertes Objekt \| Demografische Daten | ✅ Freiwillige demografische Daten werden über eine separate Umfrage mit der Option "Nicht antworten" erfasst, in einem benutzerdefinierten Objekt mit privatem Einmalkennwort gespeichert, durch das Einmalkennwort eingeschränkt und nur für Analysen der aggregierten Fairness verwendet | | Shield \| Ereignisüberwachung | ✅ Die Shield-Ereignisüberwachung protokolliert Zugriffsereignisse (Berichtexporte, API-Objektabfragen) für demografische Daten, um Zugriffsmuster zu überprüfen | | Plattform \| Drittanbieteranreicherung | ✅ Anreicherungsdrittanbieter werden vor der Implementierung auf Fairnesstests, demografische Abdeckung und Genauigkeit, Rückschlussmethodik und Einschränkungen der vertraglichen Datennutzung überprüft | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Plattform \| Pflichtfelder | ⚠️ E-Mails sind für die Accounterstellung ohne Alternative erforderlich und die Telefon- oder Adressvalidierung lehnt Formate außerhalb der USA, Postfächer und ländliche Routen ab, ausgenommen Benutzer, die die Daten nicht bereitstellen können | | Plattform \| Pflichtfelder | ⚠️ Felder werden als Pflichtfelder markiert, ohne zu dokumentieren, ob der Prozess ohne die Daten funktionieren könnte, wodurch unsichtbare Populationen aus abgelehnten unvollständigen Datensätzen erstellt werden | | Plattform \| Namensfelder | ⚠️ Namensfelder erzwingen westliche Vor-/Nachnamenskonventionen und lehnen Mononyme, Diakritika oder nicht-lateinische Skripts ab, wodurch Benutzer aufgrund ihrer kulturellen Identität vom System abgelehnt werden | | Plattform \| Adressvalidierung | ⚠️ Die Adressvalidierung erfordert ein US-Postformat und erkennt keine internationalen Adressen, Postfächer, Militäradressen (APO/FPÖ) oder Stammesanschriften, wodurch die Accounterstellung und die Servicebereitstellung blockiert werden | | Plattform \| Kommunikationsvoreinstellungen | ⚠️ Es wird davon ausgegangen, dass ein einziger Kommunikationskanal universell ist (nur E-Mail oder Telefon), ohne dass Benutzer ohne Internet, ohne Telefonzugriff oder taub oder schwerhörig sind. | | Benutzerdefiniertes Objekt \| Demografische Daten | ⚠️ Demografische Daten werden aus Namen oder Standorten ohne Benutzer Knowledge abgeleitet, in standardmäßigen Kontaktfeldern gespeichert, die für alle Benutzer sichtbar sind, und ohne Offenlegung in Leadbewertungen oder Prognosen verwendet. | | Plattform \| Drittanbieteranreicherung | ⚠️ Drittanbieterdaten werden angehängt, ohne die Fairnesspraktiken der Anbieter oder die demografische Abdeckung zu überprüfen, wodurch Verzerrungen durch Anbieter in Organisationsentscheidungen importiert werden | ## Fairness in der Salesforce-Automatisierung **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Plattform \| Zuweisung und Weiterleitung | ✅ Zuweisungs- und Weiterleitungsregeln verwenden objektive Kriterien (Produktlinien, SLAs, Sprachanforderungen) und Zuweisungsverteilungen werden vierteljährlich überprüft, stratifiziert nach Kundendemografien, um sicherzustellen, dass keine Konzentrationsmuster auftreten | | Plattform \| Omnikanal | ✅ Die durchschnittliche Bearbeitungszeit, die Lösung beim ersten Kontakt und die Kundenzufriedenheit werden über die Weiterleitungspfade hinweg überwacht, um festzustellen, ob Kundensegmente systematisch weniger erfahrene Agenten empfangen | | Plattform \| Flow | ✅ Flows, die Folgeentscheidungen treffen, werden auf Kriterien überprüft, die mit geschützten Merkmalen korrelieren (Accountdauer, Kanalvoreinstellung, Kaufverlauf, Geschäftszeiten) und ihre Entscheidungslogik wird in Architekturentscheidungsdatensätzen dokumentiert | | Plattform \| Flow | ✅ Flows mit hohem Einsatz, die sich auf den Zugang zu Beschäftigung, Krediten oder Dienstleistungen auswirken, unterliegen demselben Ethiküberprüfungsprozess wie AI-Systeme | | Plattform \| Validierungsregeln | ✅ Validierungsregeln werden mit verschiedenen Daten getestet (internationale Adressen, nicht westliche Namen, alternative Telefonformate) und erweitert, sobald sie legitime Daten ablehnen. Namensfelder akzeptieren Unicode und alle Skripts | | Plattform \| Regionsdesign | ✅ Kundendemografien werden über vorgeschlagene Regionsgrenzen hinweg zugeordnet, bevor Designs fertiggestellt werden. Wenn sich Konzentrationen abzeichnen, wird die Ressourcenzuteilung auf Gleichberechtigung hin ausgewertet und die Geschäftsberechtigung dokumentiert und überwacht. | | Plattform \| Auditierung | ✅ Die Automatisierungslogik (Geschäftsregeln, Zuweisungskriterien, Flow-Entscheidungen) wird in Salesforce Knowledge oder ADRs dokumentiert und die Ergebnisse werden vierteljährlich nach demografischen Daten stratifiziert überprüft. | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Plattform \| Zuweisung und Weiterleitung | ⚠️ Zuweisungsregeln priorisieren Leads von bestimmten Postleitzahlen zu "Besten" basierend auf historischen Gewinnraten, ohne zu untersuchen, ob dieser Erfolg Fertigkeiten oder demografische Vorteile widerspiegelt | | Plattform \| Omnikanal | ⚠️ Kennzahlen zur Weiterleitungsqualität werden nicht kundensegmentübergreifend überwacht, sodass Unterschiede in der Agentenerfahrung oder -lösung nicht erkannt werden | | Plattform \| Flow | ⚠️ Flow-Entscheidungskriterien korrelieren mit geschützten Merkmalen (Dauer, Kanal, Kaufvolumen, Zeitzone) und werden als objektiv behandelt, da sich deterministische Logik neutral anfühlt | | Plattform \| Flow | ⚠️ Flows mit hohem Einsatz treffen folgenreiche Entscheidungen ohne Ethiküberprüfung, AS-Dokumentation oder Handhabung für Benutzer außerhalb des typischen Kundenprofils | | Plattform \| Validierungsregeln | ⚠️ Die Namensvalidierung ist auf A–Z beschränkt und lehnt diakritische oder nicht-lateinische Skripts ab. Für die Adressvalidierung ist das US-Postformat erforderlich. legitime Daten werden abgelehnt und Benutzer verlassen Anfragen, die nicht gemeldet wurden | | Plattform \| Regionsdesign | ⚠️ Die Regionsgrenzen folgen der geografischen Lage, die mit der demografischen Entwicklung korreliert, wobei die Vergütung oder die Personalausstattung zwischen den Regionen unterschiedlich ist und keine Analyse der demografischen Konzentration erfolgt | | Plattform \| Auditierung | ⚠️ Die Automatisierungslogik ist undokumentiert und die Ergebnisse werden nie überprüft, sodass diskriminierende Muster bei Zuweisungen, Genehmigungen, Validierungen oder Regionszuteilungen unsichtbar bleiben | # Alte Framework-Zuordnung
Das veraltete "Well-Architected Framework" (Wohlüberlegtes Framework) war nach drei Funktionen organisiert: **Vertrauenswürdig**, **Einfach** und **Anpassbar** – jede mit eigenen Untersäulen. Das aktuelle Framework ordnet diese Anleitung in fünf Säulen um. Auf dieser Seite wird jede ältere Untersäule der einzelnen Datei zugeordnet, in der die Anleitung nun am **direktsten angesprochen** wird. Auf diese Weise können Sie direkt von einem vorhandenen Konzept zur aktuellen Startseite wechseln. Jedes Ziel ist mit einer Live-Seite verknüpft. Das neue Framework teilt mehrere Untersäulen auf mehrere Säule auf. Daher wird das primäre (am häufigsten adressierte) Haus verknüpft und alle sekundären Häuser in den Notizen hervorgehoben.
## Vertrauenswürdig
UntersäuleJetzt am meisten adressiert inNotizen
SicherTrustOrganisations-, Sitzungs- und Datensicherheit. Erweitert um Agentforce-Authentifizierung und Datenoffenlegung.
ZuverlässigZuverlässigkeitVerfügbarkeit, Leistung und Skalierbarkeit; fügt das Skalierungscenter und ApexGuru hinzu. Aspekte des Datenlebenszyklus werden auch in der Ressourcen- und Kostenoptimierung angezeigt.
KonformFairnessEthische Standards, AI-Fairness, Barrierefreiheit und Datenschutzrechte. Die Rechtstreue und die Datenresidenz bleiben in Trust.
## Einfach
UntersäuleJetzt am meisten adressiert inNotizen
AbsichtlichOperational ExcellenceStrategie, Priorisierung und Governance. Wartungsfreundlichkeit und Lesbarkeit sind in der Ressourcen- und Kostenoptimierung enthalten.
AutomatisiertOperational ExcellenceProzessdesign und Datenintegrität. Die Mechaniken für Massenvorgänge/Abfragen und Geschäftswerte/ROI wechseln zur Ressourcen- und Kostenoptimierung.
InteragierenFairnessDie gleichheitsrelevante Benutzerfreundlichkeit (Formfaktor/Geräteäquivalenz, Formen der kognitiven Belastung, bewusste Hilfestellung in der Anwendung) liegt in Fairness.
## Anpassbar
UntersäuleJetzt am meisten adressiert inNotizen
ElastischOperational ExcellenceAnwendungslebenszyklus-Verwaltung, Reaktion auf operative Vorfälle. Notfallwiederherstellung/-kontinuität wird zu Zuverlässigkeit; Reaktion auf Sicherheitsvorfälle zu Trust.
ZusammensetzbarRessourcen- und KostenoptimierungTrennung von Bedenken und Architektureffizienz. Messaging/Abend- und API-Verwaltung live in Integrationsmustern; Paketerstellung in Operational Excellence.
--- ## Lesen dieser Karte - **"Jetzt am meisten adressiert"** ist die einzige Datei, in der sich jetzt der Großteil der Hilfestellung dieser Untersäule befindet – der beste erste Klick. Dies ist nicht der einzige Ort, an dem das Thema angezeigt wird. - **Aufteilungen** werden in "Notizen" hervorgehoben, wenn eine untergeordnete Säule absichtlich säulenübergreifend unterteilt wurde (z. B. "Rechtliche Einhaltung: Infrastruktur/Sicherheit in Trust, Persönlichkeitsrechte in Fairness). - **Engagement (optimiert und hilfreich)** trägt mit seiner gerechtigkeitsrelevanten Anleitung zur Fairness bei (Äquivalenz von Reaktionsfähigkeit/Formfaktor, Formen der kognitiven Belastung und bewusste Hilfestellung in der Anwendung). # Änderungsprotokoll [Anzeigen Sie das Framework](/docs/architect/de-de/well-architected/guide/framework.html), um das gut durchdachte Framework für Salesforce zu erkunden. Auf dieser Seite werden alle Aktualisierungen am Architektur-Center-Inhalt verfolgt. Schauen Sie regelmäßig vorbei, um mit den neuesten Anleitungen auf dem Laufenden zu bleiben. ## 9\. September 2026 **Rahmen**
VeröffentlichtGut durchdachtes Framework: Salesforce basiert auf fünf Säulen (Trust, Zuverlässigkeit, Operational Excellence, Ressourcen- und Kostenoptimierung und Fairness), die für traditionelle und agentenbasierte Lösungen gelten.
VeröffentlichtTrust: Entwerfen Sie sichere und konforme Lösungen mithilfe des Modells für die gemeinsame Verantwortung. Deckt Identität und Zugriff, Datenschutz, Compliance, sichere Entwicklung und Reaktion auf Vorfälle ab.
VeröffentlichtZuverlässigkeit: Entwerfen Sie verfügbare, widerstandsfähige Lösungen, die innerhalb der Obergrenzen skaliert werden und sich von Unterbrechungen erholen. Deckt skalierbare Datenmodelle, fehlertolerante Transaktionen, Verfügbarkeitsüberwachung und Notfallwiederherstellung ab.
VeröffentlichtOperational Excellence: Erstellen Sie beobachtbare Lösungen, die durch definierte Verfahren, Automatisierung und kontinuierliche Verbesserungen verwaltet werden. Deckt Beobachtbarkeit, Bereitstellungssicherheit, DevOps und Vorfallsbereitschaft ab.
VeröffentlichtRessourcen- und Kostenoptimierung: Entwerfen Sie Lösungen, die durch effiziente Nutzung der Plattformkapazität und gezielte Investitionen in das, was Sie kaufen, einen maximalen Wert pro Kosten erzielen. Deckt die TCO-Analyse, die richtige Größe, Obergrenzen und die Lizenzdisziplin ab.
VeröffentlichtFairness: Stellen Sie sicher, dass Lösungen zugänglich, diskriminierungsfrei und transparent sind, indem Sie die Kontrolle über automatisierte Entscheidungen haben. Deckt WCAG 2.2 AA-Zugänglichkeit, Verzerrungserkennung, transparente Entscheidungen und ethische Unternehmensführung ab.
VeröffentlichtDas Agentenunternehmen: Begleitet das gut durchdachte Framework, in dem erläutert wird, was sich ändert, wenn Lösungen als Agenten gelten. Behandelt die Zusammenarbeit von Menschen, Agenten und Plattformen in verwalteten Geschäftssystemen und verweist auf die säulenweise Anleitung.
VeröffentlichtTrust for Agentic Enterprise: Legen Sie fest, was Agenten tun dürfen, und überprüfen Sie, was sie getan haben. Deckt die Agentenidentität, Berechtigungen mit Umfang und umfassende Überwachungsprotokolle für autonome Aktionen ab.
VeröffentlichtZuverlässigkeit für Agentic Enterprise: Entwerfen Sie zuverlässige Agentforce-Lösungen, die nicht deterministische Fehler antizipieren. Deckt mehrstufige Ausweichketten, anmutige Verschlechterung und automatische Wiederherstellung nach Unterbrechungen ab.
VeröffentlichtOperational Excellence für Agentic Enterprise: Beobachten Sie probabilistische Agentensysteme und verwalten Sie sie über den Lebenszyklus der Agentenentwicklung. Deckt die Beobachtbarkeit von Agenten, die Bewertung über Qualitätsdimensionen hinweg und die Lebenszyklus-Governance ab.
VeröffentlichtRessourcen- und Kostenoptimierung für Agentenunternehmen: Halten Sie den Agentenverbrauch effizient und die Ausgaben wertorientiert. Deckt Massenaktionen, disziplinierte Kontextfenster, verbrauchsbasierte Preismodelle und die TCO-Modellierung für variable Agentenarbeitslasten ab.
VeröffentlichtFairness für Agentensysteme: Stellen Sie sicher, dass agentengesteuerte Erfahrungen erklärbar, anfechtbar und gerecht sind. Behandelt die Verzerrungserkennung für Folgeentscheidungen von Agenten, die grundlegende menschliche Aufsicht und die Einstein Trust Layer.
VeröffentlichtÄnderungsprotokoll: Verfolgt alle Aktualisierungen am Architektur-Center-Inhalt und zeigt, was neu ist, was geändert wurde und was entfernt wurde.
**Grundlagen**
ErweitertAsynchrone Verarbeitung auf der Lightning Platform: Aktualisierte Verweise auf das "Well-Architected Framework" (Wohlarchitektonisches Framework) aus dem alten Modell "Vertrauenswürdig/Einfach/Anpassbar" auf die aktuelle Fünf-Säulen-Taxonomie.
ErweitertPlattformfreigabearchitektur: Aktualisierte Verweise auf das "Well-Architected Framework" (Wohlarchitektonisches Framework) aus dem alten Modell "Vertrauenswürdig/Einfach/Anpassbar" auf die aktuelle Fünf-Säulen-Taxonomie.
ErweitertSalesforce-Datensynchronisierung: Aktualisierte Verweise auf das "Well-Architected Framework" (Wohlarchitektonisches Framework) aus dem alten Modell "Vertrauenswürdig/Einfach/Anpassbar" auf die aktuelle Fünf-Säulen-Taxonomie.
ErweitertSalesforce-Datenvirtualisierung: Aktualisierte Verweise auf das "Well-Architected Framework" (Wohlarchitektonisches Framework) aus dem alten Modell "Vertrauenswürdig/Einfach/Anpassbar" auf die aktuelle Fünf-Säulen-Taxonomie.
ErweitertData 360-Dokument-AI: Aktualisierte Verweise auf das "Well-Architected Framework" (Wohlarchitektonisches Framework) aus dem alten Modell "Vertrauenswürdig/Einfach/Anpassbar" auf die aktuelle Fünf-Säulen-Taxonomie.
**Entscheidungsleitfäden**
ErweitertErstellungsformulare: Aktualisierte Verweise auf das "Well-Architected Framework" (Wohlarchitektonisches Framework) aus dem alten Modell "Vertrauenswürdig/Einfach/Anpassbar" auf die aktuelle Fünf-Säulen-Taxonomie.
ErweitertDatenintegration: Aktualisierte Verweise auf das "Well-Architected Framework" (Wohlarchitektonisches Framework) aus dem alten Modell "Vertrauenswürdig/Einfach/Anpassbar" auf die aktuelle Fünf-Säulen-Taxonomie.
ErweitertEreignisgesteuerte Architektur: Aktualisierte Verweise auf das "Well-Architected Framework" (Wohlarchitektonisches Framework) aus dem alten Modell "Vertrauenswürdig/Einfach/Anpassbar" auf die aktuelle Fünf-Säulen-Taxonomie.
## 26\. Juli 2026 **Grundlagen**
VeröffentlichtData 360-Dokument-AI: Extrahieren von strukturierten Daten aus unstrukturierten Dokumenten und Erstellen von Grundlagen in Data 360, wodurch Dokumentinhalte in Analytics, Automatisierung und Agentforce verfügbar werden.
VeröffentlichtArchitekturmuster für Field Service: Optimieren der Freigabe und Sichtbarkeit von Vertragsnehmern in großem Umfang: Vergleicht regionsbasierte und accountbasierte Freigabemuster für die Steuerung externer Vertragsnehmernetzwerke in Field Service. Hier erfahren Sie, wie Sie die Plattformsicherheit mit der Planungsleistung in Einklang bringen und die Datengrundlage für die AI-gesteuerte Planung mit Agentforce erstellen können.
**Entscheidungsleitfäden**
ErweitertData 360-Interoperabilität: Aktualisiert auf das neue Entscheidungsleitfadenformat: Aufteilen des Zero Copy-Verbunds in drei verschiedene Muster (Live-Abfrage, Zwischenspeicherung für beschleunigte Abfragen und Dateiverbund) mit Anleitungen zur Verwendung der einzelnen Elemente auf der Grundlage von Abfragehäufigkeit, Latenz und Kosten.
## 23\. Juli 2026 **Grundlagen**
VeröffentlichtAgentische Integrationsmuster: Die architektonische Blaupause für die Integrationsmuster, von denen Agenten abhängen. Behandelt, wie Integrationen entworfen werden, die Mehrdeutigkeiten verarbeiten, sichere Wiederholungen unterstützen und fehlerbehaftet sind, und wie die Salesforce Platform jedes Muster bereitstellt.
## 10\. Juni 2026 **Referenzarchitekturen**
ErweitertReferenzdiagramme: Vollständige Aktualisierung aller Diagramme zur Verbesserung des barrierefreien Zugriffs und der Lesbarkeit. Aktualisierte Produktnamen. Weitere Verbesserungen.
## 29\. Mai 2026 **Grundlagen**
ErweitertIntegrationsmuster: Alte Tools wurden zugunsten von Flow- und Plattformereignissen ersetzt. GraphQL und die Pub/Sub-API ersetzen SOAP. OAuth 2.0 ist nun Standard. Data Cloud wurde um Data 360- und Zero Copy-Muster erweitert. Die Ereignisweiterleitung verbindet Salesforce mit AWS EventBridge.
VeröffentlichtSalesforce-Datensynchronisierung: Umfassende Anleitung zu Datensynchronisierungsmustern in Salesforce. Deckt Strategien für die Batchsynchronisierung, Echtzeitsynchronisierung, bidirektionale Synchronisierung und Konfliktlösung ab, um Daten systemübergreifend konsistent zu halten.
VeröffentlichtSalesforce-Datenvirtualisierung: Leitfaden für den Echtzeitzugriff auf externe Daten, ohne sie in Salesforce kopieren zu müssen. Deckt Salesforce Connect, externe Objekte und Zero-Copy-Integrationsmuster mit Data Cloud ab.
## 06\. Mai 2026 **Grundlagen**
VeröffentlichtHybride Argumentation mit dem neuen Agentforce-Generator und Agentenskript: Leitfaden zur Kombination von LLM-Überlegungen mit deterministischer Logik in Agentforce. Zeigt an, wann die visuellen Tools des Generators im Vergleich zum Agentenskript für komplexe Workflows verwendet werden sollen, die sowohl AI-Flexibilität als auch Genauigkeit von Geschäftsregeln erfordern.
## 01\. Mai 2026 **Entscheidungsleitfäden**
VeröffentlichtBestimmen der Agenten- und traditionellen Workflowautomatisierung: Entscheidungsleitfaden zur Auswahl zwischen autonomen Agenten und traditioneller Automatisierung. Vergleicht Agentforce, Flow, Apex und andere Automatisierungstools anhand von Anwendungsfalleigenschaften wie Variabilität, menschlicher Übersicht und Integrationskomplexität.
## 10\. April 2026 **Grundlagen**
VeröffentlichtVerwendung von MuleSoft und Informatica: Besser zusammen: MuleSoft für Anwendungskonnektivität und APIs; Informatica für Datenintegration, Qualität und MDM. So koppeln Sie sie für vertrauenswürdige Skalierungs- und Agenten-Workflows.
**Entscheidungsleitfäden**
ErweitertData 360 Provisioning Decision Guides: Aktualisiert auf das neue Entscheidungsleitfadenformat.
## 08\. April 2026 **Entscheidungsleitfäden**
ErweitertData 360-Bereitstellung: Aktualisiert auf das neue Entscheidungsleitfadenformat.
## 02\. April 2026 **Entscheidungsleitfäden**
ErweitertErstellungsformulare: Aktualisiert auf das neue Entscheidungsleitfadenformat.
ErweitertEntscheidungsleitfaden für Bauformulare: Aktualisiert auf das neue Entscheidungsleitfadenformat; Aktualisierungen für die Produkt-/Funktionswährung.
## 01\. April 2026 **Grundlagen**
VeröffentlichtEndbenutzeridentitätsübernahme in Agenten: Beibehalten des Identitätskontexts für Endbenutzer, wenn Agenten API-Aufrufe an externe Systeme senden. Deckt den Austausch von OAuth-Token, Anmeldeinformationen mit Namen und Muster ab, um sicherzustellen, dass Agenten mit den entsprechenden Benutzerberechtigungen und nicht mit Service-Accountberechtigungen handeln.
## 23\. März 2026 **Entscheidungsleitfäden**
ErweitertAsynchrone Verarbeitung: Aktualisiert auf das neue Entscheidungsleitfadenformat.
## 19\. März 2026 **Grundlagen**
VeröffentlichtData 360 Reinräume: Leitfaden zur Zusammenarbeit bei der Wahrung der Privatsphäre mit Data Cloud-Reinräumen. Ermöglicht die sichere Datenfreigabe und -analyse über Organisationsgrenzen hinweg, ohne Kundenrohdaten offenzulegen.
**Entscheidungsleitfäden**
ErweitertEreignisgesteuerte Architektur: Aktualisiert auf das neue Entscheidungsleitfadenformat.
ErweitertData 360-Interoperabilität: Aktualisiert auf das neue Entscheidungsleitfadenformat.
ErweitertData 360 Interoperability Decision Guides (Entscheidungsleitfaden zur Data 360-Interoperabilität): Aktualisiert auf das neue Entscheidungsleitfadenformat.
**Referenzarchitekturen**
VeröffentlichtIntegrationsarchitektur für Nullkopiedaten zwischen Salesforce Data 360 und Databricks: Referenzarchitektur für die Verbindung von Data Cloud mit Databricks Lakehouse ohne Datenverschiebung. Nutzen Sie die Zero-Copy-Verbundfunktion für Echtzeitanalysen und ML-Modellschulungen für zusammengeführte Kundendaten.
VeröffentlichtData 360-Batch-Aktivierung und ereignisgesteuerte Aktionsarchitektur: Referenzarchitektur mit geplanten Batchaktivierungen und ereignisgesteuerten Aktionen in Echtzeit aus Data Cloud. Demonstriert, wie Batch-Segmente und Streaming-Aktivierungen für nachgelagerte Systeme orchestriert werden.
## 12\. März 2026 **Grundlagen**
VeröffentlichtInhalt: Hochverfügbarkeit und Notfallwiederherstellung: MuleSoft: Leitfaden zum Entwerfen belastbarer MuleSoft-Integrationen. Deckt Laufzeitredundanz, CloudHub-Verfügbarkeitszonen, Notfallwiederherstellungsstrategien und Failover-Muster für geschäftskritische Integrations-Flows ab.
**Entscheidungsleitfäden**
ErweitertDatenintegration: Aktualisiert auf das neue Entscheidungsleitfadenformat.
ErweitertDurch Datensätze ausgelöste Automatisierung: Aktualisiert auf das neue Entscheidungsleitfadenformat.
## 09\. März 2026 **Entscheidungsleitfäden**
ErweitertEntscheidungsleitfaden für ereignisgesteuerte Architektur: Aktualisiert auf das neue Entscheidungsleitfadenformat.
## 26\. Februar 2026 **Entscheidungsleitfäden**
ErweitertDatenintegration: Data 360 und Data Cloud One wurden als Optionen für Datenintegrationen hinzugefügt.
**Referenzarchitekturen**
VeröffentlichtReferenzarchitektur der Customer Zero Data-Plattform: Referenzarchitektur, die zeigt, wie Salesforce Data Cloud intern verwendet (Customer Zero). Demonstriert reale Implementierungsmuster für die Vereinheitlichung von Daten im Unternehmensmaßstab, die Identitätsbestimmung und Analysen.
VeröffentlichtZero-Copy-Datenintegrationsarchitektur zwischen Salesforce Data 360 und AWS: Referenzarchitektur zum Verknüpfen von Data Cloud mit AWS-Data-Lakes (S3, Redshift) ohne Kopieren von Daten. Aktiviert zusammengeführte Abfragen in Salesforce und AWS mithilfe von Zero-Copy-Konnektoren und Data Cloud-Abfrageverbund.
VeröffentlichtIntegrationsarchitektur für Nullkopiedaten zwischen Salesforce Data 360 und Snowflake: Referenzarchitektur für die Verbindung von Data Cloud mit Snowflake Data Cloud ohne Datenduplizierung. Nutzen Sie die Zero-Copy-Verbundfunktion für einheitliche Customer 360-Ansichten auf beiden Plattformen.
VeröffentlichtIntegrationsarchitektur für Nullkopiedaten zwischen Salesforce Data 360 und GCP: Referenzarchitektur zum Verknüpfen von Data Cloud mit Google Cloud Platform (BigQuery, Cloud Storage). Demonstriert Zero-Copy-Integrationsmuster für Analysen und ML-Arbeitslasten in Salesforce und GCP.
## 22\. Februar 2026 **Grundlagen**
VeröffentlichtData 360-Sicherheitsarchitektur: Umfassender Leitfaden zum Schützen von Data Cloud-Implementierungen. Beinhaltet die Datenklassifizierung, die Verschlüsselung im Leerlauf und während der Übertragung, Zugriffssteuerungen, die Überprüfungsprotokollierung und Überlegungen zur Compliance für vereinheitlichte Kundendatenplattformen.
VeröffentlichtData 360-Integrationsmuster: Musterkatalog zum Integrieren von Data Cloud in Salesforce Clouds und externe Systeme. Behandelt Aufnahmemuster, Aktivierungsmuster, Verbundmuster und bewährte Vorgehensweisen zum Erstellen einer einheitlichen Kundendatenarchitektur.
## 22\. Dezember 2025 **Grundlagen**
VeröffentlichtMuleSoft Agent Fabric - Deep Dive: Erfahren Sie mehr über die MuleSoft Agent Fabric-Architektur. Stellt das Agentennetzwerkkonzept vor und stellt Muster zum Erstellen intelligenter, ereignisgesteuerter Integrations-Flows vor, die traditionelle APIs mit Funktionen für autonome Agenten kombinieren.
ErweitertArchitektur des Agentenunternehmens mit Mulesoft: Abschnitt 'Integrationsintelligenz' hinzugefügt.
## 02\. Dezember 2025 **Grundlagen**
VeröffentlichtSchrittbasiertes asynchrones Framework: Framework zum Ausführen modularer, skalierbarer asynchroner Aufträge in Salesforce. Bietet Muster für die Aufteilung langfristiger Prozesse in Schritte mit integrierter Beobachtbarkeit, Fehlerbehandlung und Fortsetzungsfunktionen für sich ändernde Unternehmensanforderungen.
## 11\. November 2025 **Grundlagen**
VeröffentlichtArchitektur des Agentenunternehmens mit Mulesoft: Standpunkt für die Architektur des intelligenten Unternehmens mit MuleSoft. Hier erfahren Sie, wie Sie traditionelle Integrationsmuster mit autonomen Agenten und AI-gestützten Workflows für die Geschäftsautomatisierung der nächsten Generation kombinieren können.
# Architekturmuster
Erfahren Sie mehr über die gut durchdachte [Ressourcen- und Kostenoptimierung](/docs/architect/de-de/well-architected/guide/resource-and-cost-optimization.html) → [Ihre Optimierungsverantwortungen](/docs/architect/de-de/well-architected/guide/resource-and-cost-optimization.html#your-optimization-responsibilities) Auf dieser Seite finden Sie eine umfassende Musteranleitung für architektonische Belange, einschließlich Funktionseinheiten, Trennung von Belangen, Statusverwaltung, API-Verwaltung und Messaging. Diese Muster prägen den langfristigen Lösungserfolg durch bewusste Designentscheidungen zu Servicegrenzen, Datenzugriffsmustern und Komponentenverantwortungen. ## Funktionseinheiten und Komponentendesign **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | **Apex Klassen** | ✅ Serviceklassen folgen dem Prinzip der Einzelverantwortung, wobei die Namen den Zweck eindeutig angeben (AccountService, OrderProcessor, InventoryManager). Jede Serviceklasse konzentriert sich auf eine Domäne oder Geschäftsfunktion. Methoden in Serviceklassen weisen einzelne, fokussierte Verantwortlichkeiten in 20 Zeilen auf. | | **Auslöser** | ✅ Auslöser werden an Handler-Klassen delegiert, statt direkt Geschäftslogik zu enthalten. Das Auslöser-Handler-Muster wird einheitlich mit eindeutigen Methodennamen nach Kontext verwendet (handleBeforeInsert, handleAfterUpdate). Handler-Klassen organisieren Logik nach Auslöserereignis mit einzelnen Verantwortlichkeiten pro Methode. | | **Lightning Web Components** | ✅ Komponenten folgen dem Prinzip der Einzelverantwortung mit klaren Requisitenoberflächen für die Konfiguration. Jedes LWC konzentriert sich auf ein Benutzeroberflächenanliegen (Datenanzeige, Benutzereingabe, Navigation). Komponenten, die für die Zusammensetzung konzipiert sind, nicht für monolithische Implementierungen. | | **Serviceebene** | ✅ Serviceklassen kapseln Geschäftslogik unabhängig vom Eintrittspunkt (Auslöser, API, Flow, Batch). Dieselbe Serviceklasse verarbeitet mehrere Aufrufkontexte ohne Duplikate. Serviceebene trennt Geschäftsregeln von Darstellungs- und Datenzugriffsproblemen. | | **Wiederverwendbare Komponenten** | ✅ Komponenten, die für die Wiederverwendung in mehreren Projekten und Teams konzipiert wurden. Konfigurationsgesteuertes Verhalten bei Verwendung benutzerdefinierter Metadatentypen ermöglicht Verhaltensänderungen ohne Codebereitstellung. Aufrufbare Aktionen stellen Apex Logik als deklarative Bausteine bereit, die über Flow und externe Orchestrierung verwendet werden können. | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | **Gottesklasse** | ⚠️ Vermeiden Sie übermäßige Verantwortung in einer einzelnen Klasse. Teilen Sie große Klassen (> 500 Zeilen) in fokussierte Klassen mit einzelnen Verantwortlichkeiten auf. Ordnen Sie Klassen neu an, wenn sie mehrere nicht verwandte Anliegen verarbeiten (OrderProcessor sollte nicht auch das Senden von E-Mails und Berichte verarbeiten). | | **Gemischte Bedenken** | ⚠️ Vermeiden Sie das Mischen von Auslöserlogik, Geschäftsregeln und Datenzugriff in einzelnen Klassen. Trennen Sie Präsentationslogik von Geschäftslogik in Steuerfeldern. Halten Sie Integrationsanliegen von der Kerndomänenlogik getrennt. | | **Auslöserlogik in Auslösern** | ⚠️ Vermeiden Sie es, Geschäftslogik direkt in Auslöserdateien einzubetten. Verwenden Sie niemals mehr als 300 Zeilenauslöser mit verschachtelten Bedingungen. Legen Sie die Delegierung immer an Handler-Klassen mit klarer Methodenorganisation nach Auslöserkontext fest. | ## Trennung von Bedenken **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | **Geschäftslogik** | ✅ Geschäftsregeln zentralisiert in Serviceklassen, nicht verstreut über Auslöser, Steuerfelder und Batchklassen. Domänenklassen kapseln das Verhalten auf Datensatzebene (Validierung, Standardwerte, abgeleitete Werte) einheitlich, unabhängig davon, wie Datensätze in das System gelangen. Logik, die über die Serviceebene wiederverwendet wird, statt sie über Eintrittspunkte hinweg zu duplizieren. | | **Datenzugriff** | ✅ Datenzugriff, der hinter Repository- oder Auswahlmusterklassen abstrahiert wird. SOQL-Abfragen, die in Auswahlklassen (AccountSelector, OpportunitySelector) zentralisiert sind, um konsistente Feldlisten und WHERE-Klauseln zu gewährleisten. Das Repository-Muster ermöglicht Tests mit simulierten Datenquellen, ohne die Geschäftslogik zu ändern. | | **Schnittstellenverträge** | ✅ Komponenten kommunizieren über explizite Schnittstellen und nicht über Implementierungsdetails. Apex Schnittstellen definieren Verträge zwischen Ebenen. Benutzerdefinierte Metadatenkonfiguration definiert Verhaltensgrenzen. Plattformereignisse stellen Messaging-Verträge zwischen Produzenten und Verbrauchern bereit. | | **Modulgrenzen** | ✅ Begrenzte Kontexte definieren klare Inhaberschaftsgrenzen für Datenmodelle und Geschäftsregeln. Jedes Modul besitzt seine Daten, Automatisierung und Geschäftslogik. Module interagieren über definierte APIs, statt Datenbankobjekte direkt freizugeben. In der Dokumentation wird eindeutig angegeben, welches Team Inhaber welcher Objekte und Services ist. | | **Abhängigkeits-Flow** | ✅ Abhängigkeiten fließen in eine Richtung (Darstellung → Geschäft → Daten). Die Kerngeschäftslogik hängt von nichts Externem ab, was eine unabhängige Entwicklung ermöglicht. Infrastrukturbelange (Protokollierung, Zwischenspeicherung, externe APIs) hängen von der Geschäftslogik über Schnittstellen ab, nicht umgekehrt. | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | **Logische Duplizierung** | ⚠️ Vermeiden Sie doppelte Geschäftslogik über Auslöser, API-Endpunkte und Batchklassen hinweg. Zentralisieren Sie die Funktion in der Serviceebene und verwenden Sie sie punktübergreifend wieder. Sobald dieselbe Geschäftsregel in mehreren Klassen angezeigt wird, können Sie sie in den freigegebenen Service extrahieren. | | **Datenzugriff gestreut** | ⚠️ Vermeiden Sie SOQL-Abfragen, die über Auslöser-, Steuerfeld- und Batchklassen mit inkonsistenten Feldlisten und WHERE-Klauseln verstreut sind. Zentralisieren Sie Abfragen in Auswahlklassen, um konsistente Muster zu gewährleisten und die LDV-Optimierung an einem Ort zu aktivieren. | | **Geschäftslogik in Auslösern** | ⚠️ Vermeiden Sie Validierungsregeln, Feldberechnungen und Workflow-Orchestrierung, die direkt in Auslösercode eingebettet sind. Wechseln Sie zu Serviceklassen oder Domänenklassen. Halten Sie Auslöser dünn und konzentrieren Sie sich nur auf die Delegierung an die entsprechenden Handler. | | **Geschäftslogik in Steuerfeldern** | ⚠️ Vermeiden Sie komplexe Berechnungen, Validierungen oder Datenmanipulationen in Aura/LWC-Steuerfeldmethoden. Steuerfelder sollten Aufrufe an die Serviceebene orchestrieren und keine Geschäftsregeln direkt implementieren. | | **Kreisabhängigkeiten** | ⚠️ Vermeiden Sie Pakete oder Klassen mit kreisförmigen Abhängigkeiten, bei denen A von B und B von A abhängt. Lösen Sie diese Lösung, indem Sie gemeinsame Anliegen in ein separates Modul extrahieren, die Abhängigkeitsrichtung umkehren oder die ereignisgesteuerte Kommunikation verwenden, um die Kopplung zu unterbrechen. | ## Bundesstaatsverwaltung **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | **Plattform-Cache (Organisationspartition)** | ✅ Häufig aufgerufene Referenzdaten, die in der Organisationspartition zwischengespeichert werden, einschließlich benutzerdefinierter Metadaten-Nachschlagevorgänge, Auswahllistenwerte, Konfigurationseinstellungen und berechneter Ergebnisse teurer Vorgänge. Standardmäßige TTL, die anhand der Datenvolatilität konfiguriert wird (Stunden für monatlich wechselnde Referenzdaten, Minuten für häufig aktualisierte Konfigurationen). Die Cache-Schlüsselstrategie verhindert Kollisionen zwischen verschiedenen Datentypen. | | **Plattform-Cache (Sitzungspartition)** | ✅ Benutzerspezifische Voreinstellungen, berechnete Personalisierungsdaten und der im Sitzungs-Cache gespeicherte Status in Sitzungsform. Sitzungs-Cache, der nicht für Daten verwendet wird, die für Benutzer freigegeben werden sollten. Die Cache-Entwertungsstrategie verarbeitet Benutzervoreinstellungsaktualisierungen entsprechend. | | **Lightning Data Services** | ✅ LDS bietet automatische clientseitige Zwischenspeicherung von Datensätzen für Lightning Webkomponenten. Standardmäßige CRUD-Vorgänge verwenden LDS anstelle von benutzerdefinierten Apex-Steuerfeldern. LDS eliminiert redundante Serverrundfahrten und bietet optimistische Benutzeroberflächenaktualisierungen. Komponenten nutzen den freigegebenen LDS-Cache seitenübergreifend. | | **Benutzerdefinierte Metadatentypen** | ✅ Konfigurations- und Verhaltensregeln, die in benutzerdefinierten Metadatentypen gespeichert und nicht in Klassen hartcodiert sind. Benutzerdefinierte Metadaten, die über Änderungssets oder quellgesteuerte Entwicklung umgebungsübergreifend bereitgestellt werden können. Änderungen an benutzerdefinierten Metadaten erfordern keinen vollständigen Bereitstellungszyklus. Zwischenspeichern von benutzerdefinierten Metadatenabfragen im Plattform-Cache für die Leistung. | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | **Abfrage in Schleife** | ⚠️ Vermeiden Sie die Ausführung von SOQL in Iterationsschleifen. Fragen Sie alle erforderlichen Datensätze in einer einzelnen SOQL-Anweisung außerhalb von Schleifen ab. Organisieren Sie Ergebnisse in Maps nach übergeordneter ID, um sie während der Iteration nachzuschlagen. Dies ist das häufigste Salesforce-Antimuster. | | **Wiederkehrende Abfragen** | ⚠️ Vermeiden Sie es, dieselben benutzerdefinierten Metadaten, benutzerdefinierten Einstellungen oder Referenzdaten mehrmals pro Transaktion abzufragen. Einmal abfragen, im Plattform-Cache oder in der statischen Transaktionsvariablen zwischenspeichern, transaktionsübergreifend wiederverwenden. | | **Fehlende Cache-Strategie** | ⚠️ Vermeiden Sie es, häufig aufgerufene Referenzdaten ohne Zwischenspeicherung wiederholt abzufragen. Implementieren Sie den Plattform-Cache für benutzerdefinierte Metadaten, Konfigurationen und berechnete Ergebnisse. Definieren Sie die geeignete TTL anhand der Datenvolatilität. | | **Cache ohne Ungültigkeit** | ⚠️ Vermeiden Sie das Zwischenspeichern von Daten, ohne die Invalidierungsstrategie in Betracht zu ziehen. Definieren Sie die für die Aktualisierungshäufigkeit geeignete Cache-TL. Implementieren Sie die manuelle Cache-Löschung, wenn sich die Quelldaten ändern, wenn TTL allein nicht ausreicht. | | **Nicht verwalteter Sitzungsstatus** | ⚠️ Vermeiden Sie es, anzunehmen, dass der Sitzungsstatus über die Seitennavigationen hinweg unverändert bleibt. Lightning-Komponenten sollten die Statusaktualisierung beim Laden von Seiten verarbeiten. Verwenden Sie Lightning Data Service für die automatische Statussynchronisierung. | ## Architekturstrategie und -planung **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | **Lösungsarchitekturplanung** | ✅ Die Architekturplanung erfolgt vor bedeutenden Investitionen in den Bau, einschließlich der Anforderungsanalyse (funktional und nicht funktional), der Analyse der Obergrenzen für erwartete Datenvolumen, der an die Anforderungen angepassten Musterauswahl und des Komponentendesigns, das wichtige Komponenten und Schnittstellen definiert. | | **Auswahl des Designmusters** | ✅ Bewährte Salesforce-Designmuster werden einheitlich angewendet: Service Layer Pattern für die Wiederverwendung von Geschäftslogik, Repository/Selector Pattern für die Datenzugriffsabstraktion, Strategy Pattern für austauschbare Algorithmen, Domain Pattern für das Verhalten auf Datensatzebene, Trigger Handler Pattern für die konsistente Auslöserorganisation. | | **Architekturentscheidungsdatensätze** | ✅ Wichtige Architekturentscheidungen, die in in der Versionskontrolle gespeicherten ADRs dokumentiert sind. AS erfassen Kontext (Geschäftsfaktoren, technische Einschränkungen), Entscheidung (was ausgewählt wurde), berücksichtigte Alternativen (warum andere abgelehnt wurden) und Konsequenzen (Kontexte, technische Schulden, Auslöser für erneute Besuche). | | **Build vs Buy Evaluation (Erstellung vs. Kaufbewertung)** | ✅ Die AppExchange-Bewertung geht benutzerdefinierten Entwicklungsentscheidungen mit der Analyse der Gesamtbetriebskosten voraus. Zu den Bewertungskriterien zählen der strategische Wert (Wettbewerbsdifferenzierer im Vergleich zur Ware), der TCO-Vergleich (Erstellungsaufwand, Wartung, Upgrade-Kosten), die Integrationskomplexität und die Ausstiegskosten, wenn sich die Lösung als unzureichend erweist. | | **Analyse der Obergrenze für Gouverneure** | ✅ Die Architekturplanung identifiziert, welcher Regler das Design der meisten Einschränkungen bei erwarteten Datenvolumen und Transaktionsmustern einschränkt. Transaktionen, die so konzipiert sind, dass sie unter Spitzenbedingungen weniger als 80 % der einzelnen Obergrenzen ausschöpfen. Marge für Wachstum, künftige Funktionen und unerwartete Nutzungsmuster. | | **Risikobewertung** | ✅ Technische Risiken für architektonische Ansätze, die Plattformgrenzen überschreiten. Für jedes signifikante Risiko definierte Strategien zur Eindämmung. Bei Prototypen- oder Proof-of-Concept-Arbeiten werden Annahmen für technische Ansätze mit hohem Risiko vor dem vollständigen Build-Engagement validiert. | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | **Keine Planung** | ⚠️ Vermeiden Sie es, mit der Erstellung zu beginnen, ohne Datenvolumen, Auswirkungen auf die Obergrenze oder Musterauswahl zu analysieren. Der Architekturplanungsworkshop sollte wichtige Einschränkungen identifizieren, Muster auswählen und anhand von Obergrenzen validieren, bevor mit der Erstellung begonnen wird. | | **Nicht dokumentierte Entscheidungen** | ⚠️ Vermeiden Sie architektonische Entscheidungen, die in Besprechungen getroffen werden, ohne Kontext, Gründe, Alternativen und Konsequenzen zu erfassen. Verwenden Sie in der Versionskontrolle gespeicherte Architekturentscheidungsdatensätze, um den Entscheidungskontext für künftige Teammitglieder beizubehalten. | | **Keine Build- vs-Buy-Analyse** | ⚠️ Vermeiden Sie die Erstellung benutzerdefinierter Lösungen ohne AppExchange-Bewertung. Bewerten Sie die wichtigsten 3-5 relevanten Pakete vor der benutzerdefinierten Entwicklung. Vergleichen Sie die TCO einschließlich Implementierungsaufwand, Wartung, Upgrade-Kosten und Beendigungskosten. | | **Unteringenieurwesen** | ⚠️ Vermeiden Sie es, nur für aktuelle Datenvolumen ohne Wachstumsprognose zu entwerfen. Prognostizieren Sie ein Datenwachstum von 2-3 Jahren. Entwerfen Sie Abfragemuster mit einer Selektivität, die für 5-10x aktuelle Volumen validiert wurde. Bauen Sie architektonische Spielräume für Wachstum. | ## Paketerstellung und Modularität **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | **Verwaltete Pakete der zweiten Generation (2GP)** | ✅ 2GP für neue verwaltete Pakete, die Namespace-Isolation, AppExchange-Verteilung und Schutz des geistigen Eigentums erfordern. Quellgesteuerter Entwicklungs-Workflow mit modularer Anwendungsentwicklung. Paketabhängigkeiten, die explizit verwaltet werden. Versionen, die mit semantischer Versionierung veröffentlicht wurden. | | **Entsperrte Pakete** | ✅ Entsperrte Pakete, die für interne Unternehmensanwendungen verwendet werden, die Modularität ohne Namespace-Einschränkungen erfordern. Unabhängige Bereitstellung von Paketen ohne organisationsabhängige Artefakte. Paketabhängigkeiten werden für die ordnungsgemäße Bereitstellungsreihenfolge verfolgt. Versionierungsstrategie, die für interne Pakete definiert ist. | | **Modulgrenzen** | ✅ Klare Inhaberschaftsgrenzen, die für jedes Paket definiert sind. Jedes Paket besitzt sein Datenmodell, seine Geschäftsregeln und seine Automatisierung. Pakete interagieren über definierte Schnittstellen und nicht über direkten Objektzugriff. In der Dokumentation werden die Paketinhaberschaft und Verträge zwischen Paketen angegeben. | # Barrierefreiheit und inklusives Design – Muster
Weitere Informationen zu [Fairness](/docs/architect/de-de/well-architected/guide/fairness.html) → [Zugänglichkeit mit Lightning](/docs/architect/de-de/well-architected/guide/fairness.html#accessibility-with-lightning-and-experience-cloud) und Experience Cloud ## WCAG 2.2 AA-Konformität **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Plattform \| Designstandards | ✅ WCAG 2.2 Level AA ist die minimale Barrierefreiheitsleiste für benutzerdefinierte Arbeiten (Experience Cloud, LWCs, benutzerdefinierte Themen), die vom Bauteam überprüft wird | | Plattform \| Designstandards | ✅ Wahrnehmbares Prinzip: Für Bilder und Symbole gibt es Textalternativen. Untertitel begleiten Videos | | Plattform \| Designstandards | ✅ Funktionsprinzip: Alle Funktionen sind über die Tastatur allein bedienbar, ohne Maus oder Berührung – Sprachsteuerung und Technologien für den Umschaltzugriff basieren auf demselben Tastatur-/Fokusmodell | | Plattform \| LWC | ✅ Standardmäßige Lightning Webkomponenten werden wie vorgesehen verwendet und bieten automatischen Basiszugriff | | Plattform \| LWC | ✅ Benutzerdefinierte Komponenten implementieren expliziten barrierefreien Zugriff, der durch Tests mit Bildschirmleseprogrammen validiert wurde | | Plattform \| Testpläne | ✅ Barrierefreiheitstests sind in allen Testphasen enthalten (nicht ad hoc oder optional) | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Plattform \| Designstandards | ⚠️ WCAG 2.2 Level AA wird als optional oder "nice to have" und nicht als Mindestanforderung behandelt | | Plattform \| Designstandards | ⚠️ Bilder und Symbole ohne Textalternativen; Videos ohne Titel | | Plattform \| Designstandards | ⚠️ Funktionen erfordern Maus- oder Touchinteraktion ohne Tastaturalternative | | Plattform \| LWC | ⚠️ Benutzerdefinierte Komponenten werden ohne Implementierung oder Validierung des barrierefreien Zugriffs erstellt | | Plattform \| LWC | ⚠️ Benutzerdefinierte Eingabekomponenten verwenden Div-Elemente und CSS-Stil ohne semantische Bedeutung oder Tastaturzugriff | | Plattform \| Testpläne | ⚠️ Barrierefreiheitstests sind ad hoc, optional oder werden nur vor der Markteinführung durchgeführt (nicht während der gesamten Entwicklung) | ## Screenreader-Architektur **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Plattform \| LWC | ✅ In benutzerdefinierten Lightning Webkomponenten werden semantische HTML-Elemente (Kopfzeile, Navigation, Haupt-, Neben-, Fußzeile, Artikel, Abschnitt) verwendet | | Plattform \| LWC | ✅ ARIA-Landmarken, -Rollen und -Eigenschaften werden dort angewendet, wo semantische HTML allein kein Oberflächenverhalten vermitteln kann | | Plattform \| LWC | ✅ Dynamische Inhaltsaktualisierungen verwenden Arien-Live-Bereiche, in denen Änderungen für Bildschirmleseprogramm-Benutzer angekündigt werden | | Plattform \| LWC | ✅ Benutzerdefinierte interaktive Komponenten weisen explizite Rollendefinitionen auf, die ihrem Verhalten entsprechen | | Plattform \| LWC | ✅ Formularbezeichnungen werden explizit mit allen Formulareingaben verknüpft, indem richtige Bezeichnungselemente oder Attribute vom Typ aria-labelledby verwendet werden | | Plattform \| LWC | ✅ Lightning-Eingabekomponenten werden mit erforderlichen Bezeichnungsattributen konfiguriert, die eine integrierte Bezeichnungszuordnung bieten | | Plattform \| Testpläne | ✅ Die Tests werden mit tatsächlichen Bildschirmleseprogrammen durchgeführt: JAWS und NVDA unter Windows, VoiceOver unter macOS und iOS, TalkBack unter Android | | Plattform \| Testpläne | ✅ Manuelle Tests mit echter Hilfstechnologie werden von Personen durchgeführt, die verstehen, wie Bildschirmleseprogramm-Benutzer navigieren | | Plattform \| Designstandards | ✅ Platzhaltertext wird niemals als einzige Bezeichnung verwendet, da Platzhalter nicht im Fokus stehen und Bildschirmleseprogrammen nicht genügend Kontext zur Verfügung steht | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Plattform \| LWC | ⚠️ Div-lastige Markup-Streifen, was bedeutet, dass Benutzer von Bildschirmleseprogrammen in der Inhaltshierarchie gezwungen werden, linear zu navigieren | | Plattform \| LWC | ⚠️ ARIA wird nicht verwendet, wenn semantische HTML allein kein Oberflächenverhalten vermitteln kann | | Plattform \| LWC | ⚠️ Dynamische Inhaltsaktualisierungen verwenden keine aria-live-Bereiche. Bildschirmleseprogramm-Benutzer verpassen wichtige Änderungen | | Plattform \| LWC | ⚠️ Benutzerdefinierte interaktive Komponenten enthalten keine expliziten Rollendefinitionen; Bildschirmleseprogramme kündigen sie falsch an | | Plattform \| LWC | ⚠️ Formulareingaben weisen keine explizite Bezeichnungszuordnung auf; Platzhaltertext wird als einzige Bezeichnung verwendet | | Plattform \| Testpläne | ⚠️ Es werden ausschließlich automatisierte Tools für den barrierefreien Zugriff verwendet. Manuelle Bildschirmleseprogramme werden nicht getestet | | Plattform \| Testpläne | ⚠️ Die Tests werden von sehbehinderten Benutzern durchgeführt, die mit der tatsächlichen Navigation von Bildschirmleseprogramm-Benutzern nicht vertraut sind | ## Tastaturnavigation **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Plattform \| Designstandards | ✅ Die vollständige Funktion ist über die Tastatur zugänglich, ohne dass eine Maus- oder Touchinteraktion an einem beliebigen Punkt der Benutzer-Journeys erforderlich ist | | Plattform \| LWC | ✅ Die logische Fokusreihenfolge folgt dem visuellen Layout und dem Interaktions-Flow | | Plattform \| LWC | ✅ Wenn dynamische Inhalte geladen oder Modalfenster geöffnet werden, wird der Fokus programmgesteuert verwaltet, um Tastaturbenutzer zu neuen Inhalten zu führen | | Plattform \| LWC | ✅ Modal- und Popover-Komponenten verschieben den Fokus auf den Modaltitel oder das erste interaktive Element beim Öffnen; Schaltfläche zum Zurückgeben des Fokus auf Auslöser beim Schließen | | Plattform \| Designstandards | ✅ Sichtbare Fokusindikatoren zeigen jederzeit deutlich an, welches Element den Tastaturfokus aufweist | | Plattform \| Designstandards | ✅ Fokusindikatoren erfüllen die 3:1-Kontrastanforderung gegenüber umgebenden Inhalten | | Plattform \| LWC | ✅ Benutzer können in und aus allen Komponenten navigieren, ohne in die Falle zu geraten | | Plattform \| LWC | ✅ Modale Dialoge fangen den Fokus im Modalfenster ein, während es geöffnet ist (verhindert den Zugriff auf verdeckte Inhalte), veröffentlichen jedoch den Fokus auf "Schließen" | | Plattform \| Designstandards | ✅ Tastenkombinationen für häufige Aktionen vermeiden Konflikte mit Bildschirmleseprogramm-Verknüpfungen und Browser-Verknüpfungen | | Plattform \| Designstandards | ✅ Tastenkombinationen mit einem Buchstaben werden nur aktiviert, wenn bestimmte Komponenten im Fokus stehen (nicht global), um Konflikte mit Bildschirmleseprogramm-Navigationsbefehlen zu vermeiden | | Plattform \| Dokumentation | ✅ Alle benutzerdefinierten Tastenkombinationen werden in den barrierefreien Hilfeinhalten dokumentiert | | Plattform \| Testpläne | ✅ Testschritte beinhalten die reine Tastaturnavigation durch alle Benutzer-Journeys ohne Maus oder Touch | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Plattform \| Designstandards | ⚠️ Für die Funktion ist eine Maus- oder Touchinteraktion erforderlich. Benutzer mit ausschließlicher Tastatur können keine wichtigen Aufgaben ausführen | | Plattform \| LWC | ⚠️ Die Fokusreihenfolge folgt nicht dem logischen visuellen Layout; Benutzer tippen in unerwarteter Reihenfolge durch Elemente | | Plattform \| LWC | ⚠️ Modale werden ohne Fokusverwaltung geöffnet; Tastaturbenutzer sind auf der nun ausgeblendeten Auslöserschaltfläche gestrandet | | Plattform \| LWC | ⚠️ Beim Schließen des Modalfensters wird der Fokus nicht auf die Auslöserschaltfläche zurückgegeben. Benutzer müssen nach ihrer Position auf der Seite suchen | | Plattform \| Designstandards | ⚠️ Fokusindikatoren werden aus ästhetischen Gründen unterdrückt. Benutzer können nicht sehen, welches Element den Fokus aufweist | | Plattform \| Designstandards | ⚠️ Fokusindikatoren weisen unzureichenden Kontrast auf (<3:1) | | Plattform \| LWC | ⚠️ Benutzer werden in Schnittstellenbereichen ohne Escape-Mechanismus (Tastaturfallen) gefangen | | Plattform \| LWC | ⚠️ Eingebetteter Inhalt (iframes, Drittanbieter-Widgets) erfasst dauerhaft den Tastaturfokus | | Plattform \| Designstandards | ⚠️ Tastenkombinationen mit einem einzelnen Buchstaben werden global aktiviert, was mit Navigationsbefehlen mit einem einzelnen Buchstaben im Bildschirmleseprogramm in Konflikt steht | | Plattform \| Dokumentation | ⚠️ Benutzerdefinierte Tastenkombinationen sind undokumentiert; Benutzer können sie nicht entdecken | ## Visuelles Design und Kontrast **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Plattform \| Designstandards | ✅ Mindestens 4,5:1 Kontrastverhältnis für normalen Text unter 18pt oder 14pt fett | | Plattform \| Designstandards | ✅ Minimales Kontrastverhältnis von 3:1 für großen Text und für aussagekräftige Benutzeroberflächenkomponenten und Grafiken (Formrahmen, Informationssymbole); rein dekorative und deaktivierte Elemente sind ausgenommen | | Plattform \| Experience Cloud | ✅ Benutzerdefinierte Themen und Experience Cloud-Sites mit Branding enthalten eine explizite Kontrastvalidierung mit Browser-Entwicklertools oder automatisierten Überprüfungen | | Plattform \| Designstandards | ✅ Die Textgröße auf 200 % wird ohne Verlust von Inhalt oder Funktionalität unterstützt (WCAG-Anforderung) | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Plattform \| Designstandards | ⚠️ Textkontrastverhältnisse fallen unter 4,5:1 (normaler Text) oder 3:1 (großer Text und Benutzeroberflächenkomponenten) | | Plattform \| Experience Cloud | ⚠️ Benutzerdefinierte Themen werden ohne Kontrastvalidierung bereitgestellt. Benutzer mit eingeschränktem Sehvermögen können Inhalte nicht lesen | | Plattform \| Designstandards | ⚠️ Textgrößenänderungen über 200 % brechen Layouts ein, wodurch Inhalte oder Funktionen verloren gehen | ## Tests und Validierungen für den barrierefreien Zugriff **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Plattform \| CI/CD | ✅ Der Axe-Core- oder Lighthouse-Scan für den barrierefreien Zugriff ist in CI/CD-Pipelines integriert, um strukturelle Probleme bei jeder Bereitstellung zu erfassen | | Plattform \| CI/CD | ✅ Builds schlagen fehl, wenn wichtige Probleme beim barrierefreien Zugriff erkannt werden | | Plattform \| Testpläne | ✅ Manuelle Tests mit Bildschirmleseprogrammen, reiner Tastaturnavigation und Browserzoom auf 200 % werden während der Entwicklung regelmäßig durchgeführt | | Plattform \| Testpläne | ✅ Testen zeigt Interaktionsprobleme auf, einschließlich verwirrender Ankündigungsreihenfolge, Fehlern bei der Fokusverwaltung und Tastaturfallen | | Plattform \| Unternehmen | ✅ Benutzer mit Behinderungen werden während des gesamten Designprozesses in Benutzerfreundlichkeitstests einbezogen | | Plattform \| Unternehmen | ✅ Usability-Tests zeigen praktische Barrieren auf, die bei automatisierten und manuellen Expertentests fehlen | | Plattform \| Testpläne | ✅ Automatisierte Tests (ca. 57 % der Volumenprobleme), manuelle Tests (Interaktionsprobleme) und Benutzertests (reale Barrieren) werden durchgeführt | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Plattform \| CI/CD | ⚠️ Der barrierefreie Scan ist nicht in CI/CD-Pipelines integriert | | Plattform \| CI/CD | ⚠️ Builds werden trotz kritischer Probleme mit dem barrierefreien Zugriff fortgesetzt | | Plattform \| Testpläne | ⚠️ Manuelle Tests mit Hilfstechnologie werden nicht durchgeführt, es wird nur automatisiertes Scannen verwendet | | Plattform \| Unternehmen | ⚠️ Benutzer mit Behinderungen werden nicht in Benutzerfreundlichkeitstests einbezogen | | Plattform \| Testpläne | ⚠️ Der automatische Scanner für den barrierefreien Zugriff wird einmal vor dem Start ausgeführt und die Barrierefreiheitsprüfung gilt als abgeschlossen | # Beobachtbarkeit und Überwachung – Muster Weitere Informationen zu Well-Architected [Operational Excellence](/docs/architect/de-de/well-architected/guide/operational-excellence.html) → [Observability and Monitoring (Beobachtbarkeit und Überwachung](/docs/architect/de-de/well-architected/guide/operational-excellence.html#observability-and-monitoring)) ## Beobachtbarkeits-Framework **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Plattform \| Ereignisüberwachung | ✅ Die Ereignisüberwachung wurde für die anfängliche Architektur entwickelt, die Korrelations-IDs erfasst, die Anforderungen über asynchrone Verarbeitungsketten und externe Integrationen verfolgen | | Plattform \| Ereignisüberwachung | ✅ Die Infrastruktur für die Beobachtbarkeit wird aus dem anfänglichen Sprint einbezogen und nicht nachgerüstet, nachdem sich Produktionsvorfälle als unmöglich erwiesen haben | | Plattform \| Integration | ✅ Integrations-Checkpoints werden bewusst platziert, um die Anforderungsverfolgung über Systemgrenzen hinweg zu ermöglichen | | Plattform \| Plattformereignisse | ✅ Plattformereignisnutzlasten sind für die betriebliche Sichtbarkeit mit Transaktionsmarkierungen und Kontext strukturiert | | Plattform \| Benutzerdefinierte Protokollierung | ✅ Das benutzerdefinierte Protokollierungs-Framework erfasst diskrete Ereignisse mit vollständigen Kontextinformationen, einschließlich Benutzeridentität, Zeitstempel, Dauer und Ergebnis | | Plattform \| Kennzahlen | ✅ Kennzahlen aggregieren numerische Messwerte im Laufe der Zeit und zeigen Trends wie API-Verbrauchsraten, Apex CPU-Zeitverteilungen und Erfolgsraten bei Batchaufträgen | | Plattform \| Distributed Tracing | ✅ Verfolgt die Verbindung von synchronen API-Aufrufen mit asynchronen Verarbeitungsketten, Plattformereignissen mit Abonnentenausführungen und Integrationsanforderungen mit externen Systemantworten | | Plattform \| Beobachtbarkeit | ✅ Mit der Beobachtbarkeit können Bediener beliebige Fragen zum Systemverhalten beantworten, ohne für jede Untersuchung neue Instrumente bereitzustellen | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Plattform \| Ereignisüberwachung | ⚠️ Die Lösung wird ohne benutzerdefinierte Protokollierung gestartet, was sechs Monate später eine umfassende Refaktorierung erfordert, wenn sich Produktionsvorfälle als unmöglich erweisen, nur mit Plattformprotokollen zu diagnostizieren | | Plattform \| Ereignisüberwachung | ⚠️ Die Beobachtbarkeit wird in eine bestehende Lösung nachgerüstet, die Instrumentierungsänderungen erfordert, die die meisten Komponenten berühren, und Fehlerrisiken während der operativen Verbesserungsarbeiten | | Plattform \| Integration | ⚠️ Integrationsfehler treten auf, Anforderungspfade können jedoch ohne umfassende Telemetrie nicht über Systemgrenzen hinweg verfolgt werden | | Plattform \| Plattformereignisse | ⚠️ Plattformereignisnutzlasten fehlt der betriebliche Kontext, wodurch die Vorfallsuntersuchung von der Suche nach mehreren Systemen abhängig gemacht wird | | Plattform \| Benutzerdefinierte Protokollierung | ⚠️ Protokolle erfassen unzureichenden Kontext. Untersuchungen erfordern Probleme bei der Wiedergabe, um zusätzliche Informationen zu erfassen | | Plattform \| Beobachtbarkeit | ⚠️ Vordefinierte Dashboards können unerwartete Fragen zum Systemverhalten in der Produktion nicht beantworten | ## Plattformintegritätsüberwachung **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Plattform \| Ereignisüberwachung | ✅ Die Ereignisüberwachung ist für Produktionsumgebungen aktiviert, die API-Nutzung, Anmeldeaktivität, Apex Ausführung, SOQL-Abfragen, Visualforce Seiten, Lightning Seiten und Berichtausführungen erfassen | | Plattform \| Ereignisüberwachung | ✅ Ereignisprotokolldateien werden stündlich in eine zentralisierte Protokollplattform exportiert, wodurch Verlaufsanalysen über die native Plattformaufbewahrung hinaus möglich sind | | Plattform \| Ereignisüberwachung | ✅ Externe Protokollaggregation ermöglicht Korrelation mit Unternehmenstelemetrie aus anderen Systemen für die durchgängige Transaktionsverfolgung | | Plattform \| Ereignisüberwachung | ✅ Ereignisprotokolldateien werden entsprechend den gesetzlichen Anforderungen für Compliance-Berichte und langfristige Trendanalysen beibehalten | | Plattform \| Proactive Monitoring | ✅ Proactive Monitoring-Schwellenwerte werden bewusst auf der Grundlage des organisationsspezifischen normalen Betriebsbereichs abgestimmt, statt Standardeinstellungen zu akzeptieren | | Plattform \| Proactive Monitoring | ✅ Warnungen vom Typ "Proactive Monitoring" erkennen API-Obergrenzenspitzen, gleichzeitige Apex-Fehler, SOQL-Zeilenbegrenzungsansätze und Zeilensperrkonflikte vor für Benutzer sichtbaren Vorfällen | | Plattform \| Proactive Monitoring | ✅ Abgestimmte Schwellenwerte generieren handlungsrelevante Signale, denen Teams Trust schenken und auf die Schaffung von zyklischen Verbesserungen reagieren | | Plattform \| Skalierungscenter | ✅ Skalierungscenter-Basiswerte werden während der Lösungsstabilisierung festgelegt und nach jeder Hauptversion erneut aufgerufen | | Plattform \| Skalierungscenter | ✅ Das Skalierungscenter zeigt, welche Vorgänge die meisten Ressourcen verbrauchen, welche Transaktionen sich den Zeitüberschreitungsschwellenwerten nähern und wo Optimierungsinvestitionen den größten Einfluss haben | | Plattform \| Skalierungscenter | ✅ Die Transaktionszeit erhöht sich im Vergleich zur Basisuntersuchung der Eingabeaufforderungen und zeigt unbeabsichtigte N+1-Abfragemuster, die in der letzten Bereitstellung eingeführt wurden | | Plattform \| Setup-Aktivierungsprotokoll | ✅ Setup-Aktivierungsprotokoll verfolgt Konfigurationsänderungen, einschließlich Berechtigungsänderungen, Metadatenbereitstellungen und Sicherheitseinstellungsaktualisierungen mit Aufbewahrung bis zu 180 Tagen | | Plattform \| Setup-Aktivierungsprotokoll | ✅ Setup-Aktivierungsprotokoll-Einträge werden zur Aufbewahrung über 180 Tage hinaus exportiert, wenn Compliance- oder Vertragsanforderungen längere historische Zeitfenster erfordern | | Plattform \| Shield | ✅ Feld-Aktivierungsprotokoll wird selektiv für Felder aktiviert, die sensible Daten, regulierte Daten, die einen Änderungsverlauf erfordern, oder wichtige Geschäftsdaten enthalten | | Plattform \| Shield | ✅ Das Feld-Aktivierungsprotokoll bietet eine Aufbewahrung von bis zu 10 Jahren für Felder, in denen das Verständnis historischer Werte Vorgänge und Compliance-Berichte erleichtert | | Plattform \| Integritätsprüfung | ✅ Integritätsprüfungen werden vierteljährlich geplant, wobei die Ergebnisse anhand der Risikopriorität für die Umwelt korrigiert werden | | Plattform \| Integritätsprüfung | ✅ Ergebnisse der Integritätsprüfung werden bewusst überprüft und nicht passiv akzeptiert. Kompensationskontrollen oder unterschiedliche Risikotoleranzen werden dokumentiert | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Plattform \| Ereignisüberwachung | ⚠️ Die Ereignisüberwachung ist aktiviert, Protokolle werden jedoch nie exportiert, wodurch Untersuchungen auf das native Aufbewahrungsfenster beschränkt werden und die Analyse historischer Trends verhindert wird | | Plattform \| Ereignisüberwachung | ⚠️ Ereignisprotokolldateien verbleiben im Plattformspeicher; die externe Aggregation wird nicht implementiert, was die langfristige Kapazitätsplanung verhindert | | Plattform \| Proactive Monitoring | ⚠️ Proactive Monitoring verwendet Standardschwellenwerte, die zu sensibel oder zu lasch sind, was zu lauten Benachrichtigungen führt, die Teams ignorieren sollten | | Plattform \| Proactive Monitoring | ⚠️ Benachrichtigungsrauschen zerstört Trust in das Überwachungssystem; Teams reagieren nicht mehr auf gültige Signale | | Plattform \| Skalierungscenter | ⚠️ Das Skalierungscenter ist aktiviert, wird jedoch nie proaktiv überprüft. Die Leistung verschlechtert sich langsam, bis sich Benutzer nach Monaten der inkrementellen Verschlechterung beschweren | | Plattform \| Skalierungscenter | ⚠️ Leistungskennzahlen ohne Basiskontext; unklar, ob 3-Sekunden-Transaktionszeiten typisch sind, sich verbessern oder verschlechtern | | Plattform \| Setup-Aktivierungsprotokoll | ⚠️ Das Setup-Aktivierungsprotokoll wird nicht exportiert. Aufbewahrungseinschränkungen verhindern Sicherheitsuntersuchungen oder die Validierung von Compliance-Vorschriften nach 180 Tagen | | Plattform \| Shield | ⚠️ Das Feld-Aktivierungsprotokoll ist für alle Felder aktiviert und nicht selektiv. Dadurch entstehen Speicherkosten ohne entsprechenden Compliance-Wert. | | Plattform \| Integritätsprüfung | ⚠️ Die Ergebnisse der Integritätsprüfung werden nie überprüft. Die Sicherheitskonfiguration weicht von den Basisempfehlungen ab, ohne bewusst akzeptiert zu werden. | ## Anwendungs- und Integrationsüberwachung **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Plattform \| Benutzer-Flows | ✅ Wichtige Benutzer-Flows werden anhand der Geschäftsauswirkungen definiert und durchgängig auf Erfolgsraten, Abschlusszeit, Verlassenspunkte und Fehlerraten überwacht | | Plattform \| Benutzer-Flows | ✅ Wichtige Flows umfassen umsatzgenerierende Aktivitäten (Auftragserteilung, Vertragsausführung, Opportunity-Schluss), Aktivitäten mit hohem Volumen (Anmeldung, Suche, Datensatzerstellung) und konformitätsrelevante Aktivitäten (Einwilligungserfassung, Erfüllung der Rechte betroffener Personen) | | Plattform \| Benutzer-Flows | ✅ Flows werden mit Transaktionsmarkierungen instrumentiert, die Start, Abschluss, Verlassen und Fehler bei jedem wichtigen Schritt anzeigen | | Plattform \| Benutzer-Flows | ✅ Flow für die Auftragseinreichung mit Plattformereignissen in jeder Phase (Einkaufswagenvalidierung, Inventarprüfung, Zahlungsabwicklung, Abwicklungsauslöser) mit Erfolgsrate nach Phase | | Plattform \| Benutzer-Flows | ✅ Die Überwachung auf Flussebene zeigt Probleme auf, die bei der Überwachung auf Komponentenebene nicht sichtbar sind, da an jedem Übergangspunkt Fehler auftreten können | | Plattform \| Benutzer-Flows | ✅ Warnungen werden ausgelöst, wenn Flow-Erfolgsraten unter akzeptable Schwellenwerte fallen oder die Dauer Latenzziele überschreitet | | Plattform \| Integration | ✅ Die Integrationsintegritätsüberwachung erkennt externe Systemfehler, Netzwerkprobleme, Authentifizierungsprobleme und Ansätze zur Ratenbegrenzung, bevor sie zu benutzerseitigen Fehlern führt | | Plattform \| Integration | ✅ Warnungen zur Erfolgsratenüberwachung bei Unterschreiten von 99 % für wichtige synchrone Integrationen | | Plattform \| Integration | ✅ Warnungen bei der Fehlerverteilungsüberwachung, wenn neue Fehlertypen angezeigt werden, die in der Basisversion nicht vorhanden waren | | Plattform \| Integration | ✅ Warnungen bei Latenzperzentilüberwachung (p95) bei mehr als 3 Sekunden für synchrone Benutzeranrufe | | Plattform \| Integration | ✅ Warnungen zur Durchsatzüberwachung bei mehr als 80 % der bekannten Ratenobergrenze oder des SLA-Schwellenwerts | | Plattform \| Integration | ✅ Warnungen zur Statusüberwachung des Leistungsschalters, wenn ein Stromkreis geöffnet wird, was auf eine Verschlechterung des externen Systems hinweist | | Plattform \| Integration | ✅ Warnungen zur Wiederholungsratenüberwachung, wenn die Wiederholungsrate 5 % überschreitet, was auf Zuverlässigkeitsprobleme hindeutet | | Plattform \| Integration | ✅ Integrationstelemetrie leitet an zentralisierte Überwachungsplattformen weiter, um Korrelation über Systemgrenzen hinweg zu ermöglichen | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Plattform \| Benutzer-Flows | ⚠️ Komponenten werden unabhängig voneinander überwacht und zeigen einen gesunden Betrieb an, während 12 % der Benutzer kritische Flows ohne Einblick in die Gründe verlassen | | Plattform \| Benutzer-Flows | ⚠️ Komponentenintegritäts-Dashboards werden grün angezeigt, während Benutzer wichtige Workflows nicht abschließen können, bei denen Fehler bei der Überwachungsarchitektur festgestellt werden | | Plattform \| Benutzer-Flows | ⚠️ Benutzer-Journey, die mehrere Apex-Klassen, Flows, Plattformereignisse und externe Integrationen berührt, ist nicht vollständig sichtbar | | Plattform \| Benutzer-Flows | ⚠️ Kritische Geschäfts-Journeys sind nicht instrumentiert; Erfolgsraten und Verwerfenspunkte sind unbekannt | | Plattform \| Integration | ⚠️ Integrationsfehler werden erst nach der Kaskade in benutzerseitige Fehler erkannt und nicht proaktiv. | | Plattform \| Integration | ⚠️ Integrationstelemetrie bleibt in einzelnen Systemen isoliert und verhindert Korrelation und Ursachenanalyse über Grenzen hinweg | | Plattform \| Integration | ⚠️ Überwachen von Warnungen zu nachgelagerten Symptomen nach der Schädigung, statt Ursachen frühzeitig zu erkennen | ## Service Level Indicators and Objectives (Servicestufenindikatoren und -ziele) **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Plattform \| SLIs | ✅ Verfügbarkeits-SLIs messen den Prozentsatz der erfolgreichen Ausführung wichtiger Flows aus Benutzerperspektive (erhält erwartetes Ergebnis, nicht nur 200 Statuscodes) | | Plattform \| SLIs | ✅ Latenz-SLIs messen die Zeit bis zum Abschluss von Vorgängen bei p50 (Median), p90 (90\. Perzentil ohne Ausreißer), p95 (95\. Perzentil ohne schlimmste Ausreißer) und p99 (99\. Perzentil mit Erfahrung im schlimmsten Fall) | | Plattform \| SLIs | ✅ Latenzziele variieren je nach Vorgangskritischität und Benutzererwartung (500 ms Suche fühlt sich sofort an, gleiche Latenz für Eingaben fühlt sich träge an) | | Plattform \| SLIs | ✅ Durchsatz-SLIs messen das Volumen erfolgreicher Vorgänge pro Zeiteinheit und zeigen Kapazitätsauslastung und Wachstumstrends an | | Plattform \| SLIs | ✅ Der Durchsatz in Kombination mit der Latenz zeigt an, ob das System die Leistung bei zunehmender Last beibehält oder bei wachsendem Volumen nachlässt | | Plattform \| SLIs | ✅ Fehlerraten-SLIs unterscheiden zwischen Fehlertypen (Benutzerfehler wie Validierungsfehler und Systemfehler wie Ausnahmen bei Obergrenzen) | | Plattform \| SLOs | ✅ Service Level Objectives (Servicestufenziele) werden festgelegt und definieren akzeptable SLI-Schwellenwerte basierend auf Geschäftsanforderungen, bevor Architekturmuster ausgewählt werden | | Plattform \| SLOs | ✅ Geschäftsanforderung "Vertriebsmitarbeitern müssen Opportunity-Aktualisierungen innerhalb von 5 Sekunden angezeigt werden" steuert SLO "Opportunity-Detailseite wird innerhalb von 3 Sekunden bei p95 abgeschlossen", was Architekturentscheidungen steuert | | Plattform \| SLOs | ✅ SLOs entstehen aus Geschäftsanforderungen und steuern architektonische Entscheidungen, statt basierend darauf definiert zu werden, was das System derzeit erreicht | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Plattform \| SLIs | ⚠️ Die Verfügbarkeit wird aus technischer Perspektive (200-Statuscode) und nicht aus Benutzerperspektive (erwartetes Ergebnis) gemessen | | Plattform \| SLIs | ⚠️ Die Latenz wird nur im Median gemessen, ohne die Benutzererfahrung im schlimmsten Fall bei p95- oder p99-Perzentilen zu verstehen | | Plattform \| SLIs | ⚠️ Fehlerraten-SLIs unterscheiden nicht zwischen Benutzerfehlern und Systemfehlern, wodurch verschiedene Probleme maskiert werden, die unterschiedliche Lösungen erfordern | | Plattform \| SLOs | ⚠️ Die Architektur wird zuerst erstellt, dann wird SLO als "was immer wir derzeit erreichen" definiert, was zur Akzeptanz von Seitenladevorgängen von 12 Sekunden führt, da beim Systemdesign nie Benutzeranforderungen berücksichtigt wurden | | Plattform \| SLOs | ⚠️ SLOs sind eher von der Architektur als von Unternehmen gesteuert und legen Ziele fest, die darauf basieren, was das System erreicht und was Benutzer benötigen. | ## Warnungsarchitektur **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Plattform \| Warnung | ✅ Schweregradklassifizierung leitet wichtige Vorfälle (Produktion nicht verfügbar, Datenbeschädigungsrisiko, Sicherheitskompromittierung) sofort an Techniker auf der Seite für Bereitschaft weiter | | Plattform \| Warnung | ✅ Vorfälle mit hohem Schweregrad (Leistungseinbußen, Teilausfälle) generieren Benachrichtigungen für eine sofortige Untersuchung innerhalb der Geschäftszeiten | | Plattform \| Warnung | ✅ Warnungen (näher rückende Schwellenwerte, Konfigurationsabweichung) generieren tägliche Auszugsbenachrichtigungen für die proaktive Sanierung | | Plattform \| Warnung | ✅ Der Benachrichtigungskontext umfasst die Anzahl der betroffenen Benutzer, Fehlermeldungen, Stapelverfolgungen, aktuelle Bereitstellungen, zugehörige Benachrichtigungen und Links zu relevanten Dashboards. | | Plattform \| Warnung | ✅ Reichhaltiger Kontext reduziert die mittlere Zeit bis zur Bestätigung, indem sofortige Schweregradbewertung und -untersuchung ohne Erfassung grundlegender Informationen ermöglicht werden | | Plattform \| Warnung | ✅ Benachrichtigungsgruppierung verhindert Warnungsstürme, bei denen Hunderte zugehöriger Warnungen für einzelne zugrunde liegende Probleme ausgelöst werden | | Plattform \| Warnung | ✅ Integrationsfehler löst eine Benachrichtigung aus, die nach Integrationsendpunkt gruppiert 156 fehlgeschlagene Anforderungen in den letzten 5 Minuten mit Latenzdiagramm, Fehlerverteilung und Dashboard-Link anzeigt | | Plattform \| Warnung | ✅ Die Unterdrückung von Benachrichtigungen verhindert, dass bekannte vorübergehende Bedingungen während erwarteter Wartungszeiträume oder automatischer Korrekturzeiträume Warnungen generieren | | Plattform \| Warnung | ✅ Benachrichtigungen werden während der geplanten Wartung, während der ersten Minuten nach der Bereitstellung bei warmen Caches und bei kurzzeitigen vorübergehenden Fehlern mit erfolgreicher Wiederholungslogik unterdrückt | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Plattform \| Warnung | ⚠️ Alle Warnungen werden ohne Schweregradklassifizierung an denselben Kanal weitergeleitet. Wichtige Vorfälle werden nicht von Routinewarnungen unterschieden | | Plattform \| Warnung | ⚠️ Warnungen fehlt der Diagnosekontext. Bereitschaftsingenieure müssen grundlegende Informationen über separate Abfragen erfassen, bevor sie den Schweregrad beurteilen können | | Plattform \| Warnung | ⚠️ Integrationsfehler generiert 156 einzelne Benachrichtigungen in 5 Minuten, die das Telefon des Technikers auf Abruf überfordern, wobei jede Benachrichtigung mit Ausnahme des Zeitstempels identisch ist | | Plattform \| Warnung | ⚠️ Warnstürme verhindern, dass Responder einzelne zugrunde liegende Probleme von Hunderten verwandter Symptome unterscheiden | | Plattform \| Warnung | ⚠️ Warnungen werden während bekannter Wartungszeitfenster und vorübergehender Bedingungen ausgelöst und verursachen Geräusche, die Trust in die Überwachung untergraben | | Plattform \| Warnung | ⚠️ Die Benachrichtigungsmüdigkeit aufgrund von verrauschten falsch positiven Ergebnissen führt dazu, dass Teams Benachrichtigungen ignorieren, was die Effektivität der Antwort reduziert | # Code-Qualitätsmuster
Erfahren Sie mehr über die gut durchdachte [Ressourcen- und Kostenoptimierung](/docs/architect/de-de/well-architected/guide/resource-and-cost-optimization.html) → [Codeorganisation](/docs/architect/de-de/well-architected/guide/resource-and-cost-optimization.html#code-organization) Auf dieser Seite mit konsolidierten Mustern werden die Vorgehensweisen zur Code-Qualität und Wartbarkeit für die Ressourcenoptimierung beschrieben. Sie enthält Anleitungen zu Entscheidungen im Vergleich zu benutzerdefiniertem Code, technischer Schuldenverwaltung, Designstandards, Dokumentationspraktiken und Governance. Diese Muster tragen dazu bei, die Entwicklungsgeschwindigkeit aufrechtzuerhalten, Fehlerraten zu reduzieren und die Nachhaltigkeit langfristiger Lösungen zu ermöglichen. ## Standard- vs. benutzerdefinierte Code-Strategie **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Leistung im Maßstab | ✅ Durch Tests wird überprüft, ob deklarative Lösungen die Leistungsanforderungen bei prognostizierten Datenmengen erfüllen. Laden Sie Tests in der Full Copy Sandbox mit realistischen Daten, um die Skalierbarkeit vor der Produktionsbereitstellung zu bestätigen. | | Wartungsanalyse | ✅ Die TCO-Analyse vergleicht die langfristige Wartungslast deklarativer und benutzerdefinierter Ansätze, einschließlich Upgrade-Aufwand, Testanforderungen und Fertigkeitsanforderungen für künftige Teams. | | Architektur mit gemischtem Ansatz | ✅ Lösungen kombinieren deklarative und programmgesteuerte Ansätze, wo dies angemessen ist. Flow orchestriert Logik auf höchster Ebene, während Apex komplexe Berechnungen verarbeitet. Formelfelder berechnen einfache Ableitungen, während Apex Massenvorgänge verarbeitet. | | AppExchange-Auswertung | ✅ Bevor Sie benutzerdefinierten Code erstellen, sollten Sie vorhandene AppExchange-Pakete mit ähnlichen Funktionen auswerten. Dokumentauswertungsergebnisse, einschließlich überprüfter Pakete, Funktionslücken und TCO-Vergleich. | ## Technische Schuldenverwaltung **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Rückstandssichtbarkeit | ✅ Technische Schuldenposten, die im Rückstand verfolgt werden, mit eindeutigen Bezeichnungen, Kontext, in dem erläutert wird, warum Code verbessert werden muss, Geschäftsauswirkungen, wenn er nicht bearbeitet wird, und geschätzter Sanierungsaufwand. Unsichtbare Schulden können nicht priorisiert oder verwaltet werden. | | Inkrementelle Verbesserung | ✅ Pfadfinderregel, die während der Funktionsentwicklung angewendet wurde: Code besser lassen als gefunden. Teams beheben Schulden während der Arbeit an zugehörigen Funktionen inkrementell, statt dass große dedizierte Refaktoring-Projekte erforderlich sind. Codeüberprüfungen bestätigen inkrementelle Verbesserungen. | | Prävention vor Sanierung | ✅ Qualitäts-Gate in CI/CD erzwingen Standards, bevor Code die Produktion erreicht. Code-Scanner, ApexGuru und Komplexitätskennzahlen, die in die Validierung von Pull-Anforderungen integriert sind. Blockierungsprobleme verhindern die Zusammenführung, bis sie gelöst sind. | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Rückstandsverwaltung | ⚠️ Technische Schulden wurden mündlich bestätigt, aber nie im Rückstand verfolgt. Kein Einblick in die Schuldenanhäufung. Die Schuldensanierung wurde immer zugunsten der Funktion zurückgestellt. Velocity nimmt allmählich ab, Teams können nicht erklären, warum. | | Qualitätstorumgehung | ⚠️ CI/CD-Qualitäts-Gatter werden häufig unter Plandruck umgangen, um sie später zu reparieren. "Später" passiert nie. Code Scanner-Fehler wurden als bekannte Probleme markiert und ignoriert. Angehobene Komplexitätsschwellenwerte für schlechte Implementierungen. | | Keine Sanierungskapazität | ⚠️ 100 % der Sprint-Kapazität für Funktionsarbeiten mit null Kapazität für die technische Schuldensanierung. Schulden häufen sich unbegrenzt an. Große Refaktorisierungsprojekte, die alle 18-24 Monate erforderlich sind und ganze Quartale in Anspruch nehmen. | | Konfigurationsschulden | ⚠️ Benutzerdefinierte Metadatentypen und benutzerdefinierte Einstellungen werden ohne Bereinigung kumuliert. Die nicht verwendete Konfiguration wird unbegrenzt beibehalten. Die Produktion verfügt über 50 Metadatensätze, von denen nur 12 tatsächlich verwendet werden. Keine Dokumentation, in der der Zweck von Konfigurationswerten erläutert wird. | ## Designstandards und -muster **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Auslöserarchitektur | ✅ Auslöser-Handler-Muster einheitlich angewendet: dünne Auslöser werden an Handler-Klassen delegiert, Handler-Klassen organisieren Logik nach Auslöserkontext (vor dem Einfügen, nach der Aktualisierung), eindeutige Methodennamen verraten den Zweck. Keine Geschäftslogik in Auslöserdateien selbst. | | Implementierung der Serviceebene | ✅ Geschäftslogik, die in Serviceklassen gekapselt ist, die von Steuerfeldern, Auslösern und Batch-Eingangspunkten getrennt sind. Serviceklassen können ohne Duplikate über mehrere Eintrittspunkte hinweg wiederverwendet werden. Konvention zur eindeutigen Benennung (AccountService, OrderProcessor). | | Auswahlmuster | ✅ SOQL-Abfragen zentralisiert in Auswahlklassen pro Objekt (AccountSelector, OpportunitySelector). Auswahlmethoden geben konsistente Feldsets zurück. LDV-Optimierungsänderungen, die einmal angewendet wurden und sich auf alle Abfragen auswirken. | | Repository-Muster | ✅ Datenzugriff, der hinter Schnittstellen abstrahiert wird und Tests mit simulierten Datenquellen ermöglicht. Repository-Implementierungen umfassen Strategien zur Erstellung, Zwischenspeicherung und Optimierung von Abfragen. Geschäftslogik hängt von Repository-Schnittstellen ab, nicht von konkreten Implementierungen. | | Komponentendesignstandards | ✅ Lightning-Webkomponenten folgen dem Prinzip der Einzelverantwortung, legen Eigenschaften für die Konfiguration offen und geben Ereignisse für die übergeordnete Kommunikation aus, die für die Zusammensetzung und Wiederverwendung vorgesehen sind. Komponentenbibliothek mit Nutzungsbeispielen dokumentiert. | | Codeorganisation | ✅ Logische Paketstruktur gruppiert verwandte Klassen. Klare Trennung zwischen Domänenlogik, Datenzugriff, API-Endpunkten und Integrationsadaptern. Paketabhängigkeiten fließen in eine Richtung. | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Auslöser | ⚠️ Alle Geschäftslogiken, die direkt in Auslöserdateien mit tief verschachtelten Bedingungen eingebettet sind, ohne Trennung von Bedenken und ohne Handler-Klassen. Über 300 Zeilenauslöserdateien, die Validierungs-, Geschäftslogik- und Integrationsaufrufe mischen. Effektive Tests nicht möglich. | | Abfrage in Schleife | ⚠️ SOQL-Abfragen, die in Iterationsschleifen ausgeführt werden. Funktioniert mit kleinen Datenvolumen, verstößt jedoch bei der Verarbeitung von Massenvorgängen gegen die Obergrenze von 100 SOQL-Abfragen. Wird nur entdeckt, wenn Auslöser Massendaten in der Produktion laden. | | DML in Schleife | ⚠️ DML-Anweisungen (Einfügen, Aktualisieren, Löschen), die in Iterationsschleifen ausgeführt werden. Verstößt bei Massenvorgängen gegen die Obergrenze von 150 DML-Anweisungen. Jeder Datensatz wird in einer separaten Datenbanktransaktion verarbeitet und nicht in einer effizienten Massenverarbeitung. | ## Dokumentationspraktiken **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Architekturentscheidungsdatensätze | ✅ Wichtige Architekturentscheidungen, die in in der Versionskontrolle gespeicherten ADRs dokumentiert sind. AS erfassen Kontext (Geschäftsfaktoren, technische Einschränkungen), Entscheidung (was ausgewählt wurde), berücksichtigte Alternativen (Warum sie abgelehnt wurden) und Konsequenzen (Kontexte, Bedingungen für eine erneute Prüfung). | # Das Agentenunternehmen ## Übersicht Das Agentenunternehmen stellt eine grundlegende Veränderung in der Art und Weise dar, wie Unternehmen KI verwenden. Es geht von passiven Tools, die eine konstante menschliche Richtung erfordern, zu autonomen Agenten, die eigenständig sensibilisieren, argumentieren und handeln, während sie mit dem menschlichen Intent im Einklang bleiben. Es handelt sich um eine Organisation, in der Menschen, Agenten und Plattformen in verwalteten Geschäftssystemen zusammenarbeiten, um Ergebnisse zu erzielen, die allein nicht erreicht werden könnten. Dieses Dokument ist eine Ergänzung zum [Well-Architected Framework](/docs/architect/de-de/well-architected/guide/framework.html). Die fünf Säulen des Frameworks – Trust, Reliability, Operational Excellence, Ressourcen- und Kostenoptimierung sowie Fairness – bilden die grundlegende Orientierung, die für *alle* Salesforce-Lösungen gilt. In dieser Übersicht wird erläutert, was sich ändert, wenn Lösungen zu Agenten werden, und Sie werden auf die einzelnen Details hingewiesen. Agentische Systeme kombinieren große Sprachmodelle, durch Abrufe erweiterte Generierung, Funktionsaufrufe und Orchestrierungsmuster, um Funktionen zu erstellen, die sich an den Kontext anpassen, statt starren programmierten Pfaden zu folgen. Agenten kombinieren probabilistische Argumentation (LLM Inference) mit deterministischer Ausführung (Workflows und Orchestrierung), um Anpassungsfähigkeit und Governance zu ermöglichen. Für Architekten werden durch dieses Verhalten Überlegungen zum Design über alle Säulen hinweg angestellt. Agenten arbeiten mit nicht deterministischem Verhalten in ihrer Argumentationsebene, was neue Muster für Zuverlässigkeit, Überwachung und Kontrolle erfordert. Die Agentenautonomie erfordert erweiterte Sicherheitsgrenzen und die Überwachung durch den Menschen. Die Koordination von mehreren Agenten führt zu entstehender Komplexität, die eine bewusste Orchestrierung erfordert. Das Agentic Enterprise fügt vorhandenen Architekturen nicht einfach AI-Funktionen hinzu, sondern gestaltet die Konzeption, Bereitstellung und Verwaltung von Systemen neu. Gut gemacht, diese Kombination schafft echten Geschäftswert: Agenten bearbeiten komplexe Workflows aus mehreren Schritten, die zuvor menschliche Eingriffe erforderten, synthetisieren Informationen quellenübergreifend und skalieren Fachwissen in der gesamten Organisation. Außerdem werden Herausforderungen eingeführt, die ein bewusstes Design erfordern. Nichtdeterministisches Verhalten erschwert Tests, Überwachung und Fehlerbehandlung. Die Autonomie wirft Fragen der Kontrolle, Verantwortlichkeit und Sicherheit auf. Kostenstrukturen verschieben sich von der festen Infrastruktur zum variablen Rückschlussverbrauch. Architekten müssen Autonomie gegen Risiko, Innovation gegen Kontrolle und Fähigkeit gegen Kosten abwägen. > ### Vorlagen vs. Handlungen > > Eine grundlegende Unterscheidung in der Agentenarchitektur besteht darin, ob ein Agent einen Menschen *unterstützt* (Copilot-Muster: Vorschlag, Empfehlung, Entwurf) oder *handelt* autonom (Agentenmuster: "decise", "execute", "complete"). Copilots erfordern die Genehmigung durch eine Person für zustandsmodifizierende Aktionen. Agenten arbeiten unabhängig innerhalb der Berechtigungsgrenzen. Diese Unterscheidung bestimmt Trust-Anforderungen, Beobachtbarkeitsanforderungen und Aufsichtsmuster. Der Wechsel von Assists zu Acts ist eine architektonische Verschiebung und keine Konfigurationsänderung – es muss jede Säule durch die Linse des autonomen Betriebs neu bewertet werden. ## Das zusammengeführte System: Menschen + Agenten + Plattformen Das Unternehmen "Agentic Enterprise" ist eine Organisation, in der Menschen, Agenten und Plattformen in verwalteten Geschäftssystemen zusammenarbeiten, um Ergebnisse zu erzielen, die allein nicht erreicht werden könnten. Dieses dreiteilige Modell prägt jede architektonische Entscheidung: - **Menschen** bieten Übersicht, Urteilsvermögen und Interventionen, wenn die Agentenkapazitäten nicht ausreichen oder wenn der Einsatz menschliche Rechenschaft erfordert. Mithilfe der Zusammenarbeit zwischen Menschen und Agenten können sich Mitarbeiter auf Urteile mit hohem Wert konzentrieren, während Agenten die routinemäßige Ausführung und Informationssynthese übernehmen. Der Mensch behält die Kontrolle auf Systemebene: Sie definieren die Grenzen und Agenten entscheiden und handeln innerhalb dieser Grenzen. - **Agenten** bieten intelligente Automatisierung, natürliche Sprachschnittstellen und adaptive Entscheidungsfindung. Agenten sind keine eigenständigen Funktionen, sondern integrierte Teilnehmer an Geschäfts-Workflows. Sie erfassen Kontext aus verwalteten Daten, begründen geeignete Aktionen mithilfe probabilistischer und deterministischer Techniken und agieren über Geschäfts-Workflows und externe Integrationen. - **Plattformen** bieten die gesteuerte Infrastruktur, die die Arbeit mit Agenten ermöglicht – angesammelte Geschäftslogik, vereinheitlichte Daten, Orchestrierung und Infrastruktur für die Zusammenarbeit. Die Plattform unterscheidet Agentensysteme auf Unternehmensebene von nicht verwalteten AI-Experimenten: Sie erzwingt Berechtigungen, verwaltet Überwachungsprotokolle, wendet Compliance-Regeln an und sorgt dafür, dass Agenten weiterhin innerhalb der Organisationsführung arbeiten. Entfernen Sie Menschen und verlieren Sie die Rechenschaftspflicht, entfernen Sie Agenten und verlieren Sie Intelligenz, entfernen Sie Plattformen und verlieren Sie die Unternehmensführung. Für das Agentic Enterprise sind alle drei als einheitliches System erforderlich. ## Die von Agenten benötigten Funktionen Jede agentische Architektur – für jeden Technologiestapel – muss einen gemeinsamen Satz an Funktionen bereitstellen. Ein Agent benötigt vertrauenswürdige Daten, über die er nachdenken kann, Geschäftslogik, die er sicher durchlaufen kann, die Kontrolle über seinen eigenen Lebenszyklus, ein gemeinsames Verständnis davon, was Daten bedeuten, und einen Pfad zur Eskalation zu Menschen. Dies sind architektonische Anforderungen, keine Produkte: Wenn Salesforce einen Teil des Stapels bereitstellt, müssen die restlichen Funktionen weiterhin beachtet werden. Salesforce stellt diese Funktionen als integriertes Set bereit. Wenn Sie sie als System behandeln, werden die Abhängigkeiten explizit: schwächen und Agenten sind auf vorhersehbare Weise begrenzt. In diesem Abschnitt werden die einzelnen Funktionen beschrieben, warum sie für Agenten wichtig sind und wie Salesforce sie bereitstellt. ### Vertrauenswürdige Daten und Kontext Agenten benötigen geregelte, überprüfte Daten, um effektiv zu argumentieren. AI-Modelle kennen Muster aus Trainingsdaten, nicht aus Kundendatensätzen, Produktkatalogen oder Transaktionsverläufen eines Unternehmens. Diese Funktion schließt diese Lücke, indem Agenten Daten bereitstellen, die genau, berechtigt, aktuell und verfolgbar sind, und nicht beliebige Webinhalte oder nicht überprüfte Quellen. - **Aktuelle Betriebsdaten** steuern zeitkritische Entscheidungen: ein Commerce-Agent, der *"Wie lautet mein Auftragsstatus?"* antwortet, ein Serviceagent, der offene Kundenvorgänge aufdeckt, oder ein Vertriebsagent, der Opportunities im Ranking aufführt, die dieses Quartal abschließen. - **Historische Daten**, beispielsweise große Datensets in Data 360, unterstützen Trendanalysen, Prognosen und das Lernen aus vergangenen Mustern. - Mit **dem Verbundzugriff** können Agenten unabhängig von ihrem Standort über Daten nachdenken. Sie reduziert die Duplizierung verbundener Quellen und bietet eine einheitliche Ansicht. *Dies wird von Salesforce über das Data 360-Portfolio bereitgestellt.* > **Architektonische Bedeutung:** Die Agentenqualität hängt von der Datenqualität ab. Investieren Sie in Datenverwaltung, -klassifizierung und -herkunft. Ein Agent, der falsche Daten anzeigt, erodiert Trust schneller als einer, der sagt: "Keine Ahnung". ### Geschäftslogikagenten können handeln Ein Agent, der nur Fragen beantworten kann, ist ein Copilot. Ein Agent, der Datensätze erstellen, Opportunities aktualisieren, Mitteilungen senden und Automatisierungen auslösen kann, ist autonom. Durch diese Autonomie können Agenten *handeln* und nicht nur *unterstützen*, sondern sie rufen vorhandene, gut getestete Geschäftsprozesse auf, statt sie im generierten Code neu zu implementieren. - Agenten übersetzen Intent in natürlicher Sprache in Standardgeschäftsvorgänge, statt Benutzer zum Schreiben von Code zu verpflichten. - Agenten delegieren sie an gekapselte Prozesse in mehreren Schritten (beispielsweise einen Rückerstattungs-Flow, der Bonitätsprüfungen, Inventaraktualisierungen und Benachrichtigungen verarbeitet). - Während sich Geschäftsregeln weiterentwickeln, übernehmen Agenten die Änderungen automatisch, sofern die Logik im Workflow vorhanden ist und nicht in den Anweisungen der Agenten widergespiegelt wird. *Salesforce stellt diese Funktion über Customer 360 Business Logic und die Plattformautomatisierung bereit.* > **Architektonische Bedeutung:** Gestalten Sie Agenten so, dass sie vorhandene Workflows aufrufen und nicht ersetzen. Agenten, die bewährte Automatisierungen aufrufen, sind zuverlässiger als Agenten, die Geschäftslogik durch generierten Code neu implementieren. ### Governance über den Agentenlebenszyklus Agenten benötigen Governance von der Entwicklung über die Bereitstellung, Überwachung und Außerbetriebnahme. Ohne sie führt die Verbreitung nicht verwalteter Agenten zu Schatten-AI: Agenten mit unklaren Berechtigungen, ohne Überwachungsprotokolle, ungetestetes Verhalten und unbekannten Kosten. Diese Funktion stellt sicher, dass Agenten mit Leitplanken erstellt, über Genehmigungstore bereitgestellt, auf Abweichung überwacht und eingestellt werden, wenn sie nicht mehr benötigt werden. - Das **Entwicklungstool** generiert erste Konfigurationen aus Beschreibungen in natürlicher Sprache und erzwingt Leitplanken (Berechtigungsvalidierung, Umfang des Unteragenten) zum Zeitpunkt des Entwurfs. - Die **Laufzeitorchestrierung** verwaltet den Agentenaufruf, die Erzwingung von Berechtigungen, die Auditprotokollierung und die Fehlerverarbeitung. - Mit **wiederverwendbaren Funktionen** können Teams vorgefertigte Agenten und Aktionen – einschließlich vertikaler Domänenexpertenfunktionen – übernehmen, statt jeden Agenten neu zu erstellen. - **In der Sitzungsbeobachtbarkeit** werden Agenteninteraktionen, Argumentationsschritte und Ergebnisse für Analysen, Debugging und Drift-Erkennung gespeichert. *Salesforce bietet diese Funktion über Agentforce Studio, Agent Fabric und AgentExchange.* > **Architektonische Bedeutung:** Behandeln Sie Agenten als verwaltete Vermögenswerte und nicht als einmalige Skripts. Die Governance auf Systemebene verhindert die Ausbreitung von Agenten. ### Gemeinsames Verständnis dessen, was Daten bedeuten Agenten, die Daten abfragen, müssen die Semantik verstehen: was "Umsatz" bedeutet, welches Feld "Kundenname" ist und wie Tabellen zusammenhängen. Ohne eine freigegebene semantische Definition generieren Agenten Abfragen, die die falschen Felder verwenden, Nullen falsch interpretieren oder gegen Geschäftsregeln verstoßen. Mit einer Abfrage fragt jeder Agent geregelte Definitionen ab und gibt konsistente, richtige Ergebnisse zurück – wobei die Logik für Geschäftskalender und Umsatzrealisierung in der Definition und nicht in Agentenaufforderungen enthalten ist. Diese Ebene funktioniert im nativen Sicherheitsmodell der Plattform: Der Zugriff wird durch die eigenen Steuerelemente auf Zeilenebene und Feldebene der Plattform gesteuert und nicht erneut in der semantischen Ebene implementiert. Daher sind Agenten an dieselben Datenberechtigungen gebunden, die die Plattform erzwingt. *Salesforce bietet diese Funktion über Tableau Semantics, eine in Tableau Next und Data 360 integrierte verwaltete semantische Ebene.* > **Architektonische Bedeutung:** Definieren Sie die semantische Ebene, bevor Sie Analyseagenten bereitstellen. Agenten, die Rohtabellen abfragen, führen zu Führungslücken und inkonsistenten Ergebnissen. ### Ein Weg zur Eskalation für Menschen Vollständig autonome Agenten ohne menschliche Aufsicht verursachen Compliance-Risiken, Verantwortlichkeitslücken und Misstrauen der Benutzer. Mit dieser Funktion behalten Menschen die Kontrolle über: Agenten eskalieren, wenn sie unsicher sind, bitten um Genehmigung für Aktionen mit hoher Auswirkung und bleiben hinsichtlich ihrer Argumentation transparent. - Mit **Genehmigungsworkflows** können Agenten eine menschliche Unterschrift anfordern, bevor sie Folgeaktionen (Erstattung, Schließen einer Opportunity, Löschen von Daten) ausführen. - Der **permanente Interaktionsverlauf** protokolliert Intent, Datenzugriff, Argumentationsschritte und ausgeführte Aktionen – für eine Überprüfung, Debugging und kontinuierliche Verbesserung. - **Eskalationsmuster** werden an menschliche Spezialisten mit vollständigem Kontext weitergegeben, wenn ein Agent nicht vertraut ist oder einen Kundenvorgang anstößt. *Salesforce bietet diese Funktion über Workflows für die Genehmigung und Eskalation von Mensch-in-der-Schleife mit persistentem, überprüfbarem Interaktionsverlauf.* > **Architektonische Bedeutung:** Entwerfen Sie explizite Eskalationsregeln im Voraus. Definieren Sie, welche Entscheidungen von Menschen genehmigt werden müssen (finanzielle Schwellenwerte, nicht rückgängig zu machende Aktionen, regulierte Daten) und implementieren Sie diese Workflows, bevor Sie autonome Agenten bereitstellen. ### Funktionsweise der Funktionen Diese Funktionen sind voneinander abhängig. Ein Agent greift auf vertrauenswürdige Daten zurück, um seine Argumentation zu stützen, handelt über Geschäftslogik, arbeitet unter Lebenszyklus-Governance, fragt über freigegebene Semantik ab und eskaliert bei Bedarf an Menschen. Entfernen Sie vertrauenswürdige Daten und Agenten halluzinieren, entfernen Sie Geschäftslogik und sie können nur antworten, nicht handeln, entfernen Sie die Governance und sie entwickeln sich zu Schatten-AI, entfernen Sie freigegebene Semantik und ihre Abfragen, entfernen Sie menschliche Eskalation und handeln Sie ohne Aufsicht. Mit einem API-First-Verbrauchsmodell – Salesforce Headless 360 – können Agenten diese Funktionen über konsistente programmgesteuerte Schnittstellen (API, MCP und CLI) erreichen, statt separate Systeme einzeln zu integrieren. ## Anwenden der Säulen auf Agentensysteme Die Säulen des gut strukturierten Frameworks bilden weiterhin die Grundlage für agentische Systeme – Agenten arbeiten weiterhin innerhalb der Obergrenzen, benötigen ordnungsgemäße Zugriffssteuerungen, müssen überwacht werden, Ressourcen verbrauchen und Benutzer gleichmäßig bedienen. Beginnen Sie in der zentralen Pfeilerführung und wenden Sie dann die agentischen Überlegungen an, die der Begleiter jeder Säule hinzufügt. Kernpfeilerführung: - [Trust](/docs/architect/de-de/well-architected/guide/trust.html) — Modell der gemeinsamen Verantwortung, Zugriffskontrolle auf vier Ebenen (Organisation/Objekt/Feld/Datensatz), Verschlüsselung, OAuth-Flows, Audit-Trails, Compliance-Frameworks - [Zuverlässigkeit](/docs/architect/de-de/well-architected/guide/reliability.html): Obergrenzen mit empfohlenem Betriebspuffer (die Obergrenze von 70 % ist eine häufig zitierte bewährte Vorgehensweise in der Community und keine offizielle Salesforce-Spezifikation), asynchrone Verarbeitung, Leistungsschalter, Kapazitätsplanung, Muster mehrerer Organisationen, Notfallwiederherstellung - [Operational Excellence](/docs/architect/de-de/well-architected/guide/operational-excellence.html) — Ereignisüberwachung, Proactive Monitoring, DevOps-Praxis (quellgesteuerte Entwicklung, CI/CD), Automatisierung, Vorfallsverwaltung, DORA-Kennzahlen - [Ressourcen- und Kostenoptimierung](/docs/architect/de-de/well-architected/guide/resource-and-cost-optimization.html) – SOQL-Optimierung, Vermeidung von Datenverzerrungen, Codeorganisation, Paketerstellungsstrategien, Leistungsüberwachung, TCO-Modellierung, Build vs. Buy, Lizenzoptimierung, Kostenüberwachung - [Fairness](/docs/architect/de-de/well-architected/guide/fairness.html) – Barrierefreiheit ([WCAG 2.2 AA](https://www.w3.org/TR/WCAG22/)), Nichtdiskriminierungsmuster (Freigaberegeln), Datenschutzarchitektur, AI-Ethik-Governance ### Trust für Agentensysteme Trust Patterns (Shared Responsibility Model, geringste Berechtigung, Verschlüsselung, OAuth) bleiben grundlegend. Agentische Systeme fügen hinzu: - **Agentenidentität und -authentifizierung**: Agenten können die JWT-basierte Authentifizierung anstelle statischer API-Schlüssel verwenden, wodurch Agenten-Aktivierungsprotokolle und die Verfolgung genauer Berechtigungen möglich sind. - **Übertragung der Benutzeridentität**: Wenn Agenten externe Systeme im Namen eines Benutzers aufrufen, wird *die* Identität des Benutzers (nicht nur die des Agenten) übernommen, sodass nachgelagerte Systeme Berechtigungen auf Benutzerebene und Prüfprotokolle erzwingen - **Berechtigungsgrenzen**: Geringste Berechtigung für Agenten, Berechtigungsübernahme vom aktuellen Benutzer, explizite Agentenberechtigungen und Validierung an Delegationsgrenzen - **Human-in-the-Loop für Folgeentscheidungen** – Genehmigungsworkflows für Aktionen mit hoher Auswirkung oder nicht rückgängig zu machende Aktionen und regulierte Daten - **Erklärbarkeit**: Agenten erläutern ihre Argumentation, zitieren Quellen für Tatsachenbehauptungen und machen die von ihnen ausgeführten Daten und Aktionen transparent. - **Compliance für autonome Systeme** – Einhaltung der Risikoklassifizierung des [EU-AI-Gesetzes](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) (unterscheidet zwischen Bereitstellungen mit begrenztem und hohem Risiko) und sektorspezifischer Vorschriften wie [HIPAA](https://www.hhs.gov/hipaa/index.html) und dem Gesetz über funktionale Finanzdienste; Beibehaltung einer strengen Einwilligungsverwaltung für die agentengesteuerte Verarbeitung **Warum dies wichtig ist:** Agenten, die autonom handeln und keine richtigen Trust Grenzen aufweisen, verursachen Sicherheitslücken, Compliance-Verstöße und Misstrauen der Benutzer. Die zentrale Trust Säule bietet das Modell für die gemeinsame Verantwortung und die Zugriffssteuerung auf vier Ebenen. Die Agentenvariante fügt die optionale JWT-basierte Agentenauthentifizierung, HITL-Genehmigungsgates und Erklärbarkeit hinzu. **Weitere Informationen:** [Agentic Enterprise Trust](/docs/architect/de-de/well-architected/guide/agentic-enterprise-trust.html) ### Zuverlässigkeit für Agentensysteme Kernzuverlässigkeitsmuster (Obergrenzen für Gouverneure, asynchrone Verarbeitung, Leistungsschalter, Kapazitätsplanung) bleiben grundlegend. Agentische Systeme fügen hinzu: - **Verarbeitung nichtdeterministischer Argumente** – dieselbe Eingabe kann unterschiedliche Ausgaben hervorrufen; Design für Varianz mit Konfidenzbewertung, Validierungsprüfungen und Ausweichstrategien - **Anmutige Verschlechterung** – Wenn die Rückschlussfolgerung fehlschlägt oder ein geringes Vertrauen zurückgibt, wird die Verschlechterung auf einfachere Funktionen statt auf einen vollständigen Fehler reduziert - **Orchestrierungsfehlerverarbeitung** – Workflows mit mehreren Agenten benötigen Fehlerisolation, Wiederholungsstrategien und Teilergebnisverarbeitung, damit ein fehlschlagender Spezialagent isoliert bleibt statt zu kaskadieren - **Modellleistungs-SLOs**: Definieren Sie akzeptable Latenz-, Genauigkeits- und Verfügbarkeitsziele für Agentenservices. - **Leistungsschalter für die Agentenkoordination** – Verhindern von Fehlern bei einem Agenten oder übermäßiger Latenz **Warum dies wichtig ist:** Probabilistisches Agentenverhalten bedeutet, dass deterministische Zuverlässigkeitsmuster nicht ausreichen. Die zentrale Säule "Zuverlässigkeit" bietet asynchrone Muster und Leistungsschalter für externe Integrationen. Die agentische Variante fügt eine anmutige Verschlechterung für Rückschlussfehler und die Verarbeitung von Orchestrierungsfehlern für die Koordination mehrerer Agenten hinzu. **Weitere Informationen:** [Zuverlässigkeit für Agentenunternehmen](/docs/architect/de-de/well-architected/guide/agentic-enterprise-reliability.html) ### Operational Excellence für Agentensysteme Die zentralen betrieblichen Exzellenzmuster (Ereignisüberwachung, DevOps, Automatisierung, Vorfallsverwaltung) bleiben grundlegend. Agentische Systeme fügen hinzu: - **Agent Development Lifecycle (ADLC)** – Verwalten von Agenten über ihren gesamten Lebenszyklus hinweg – vom Design über Tests bis hin zur Bereitstellung, Überwachung und Optimierung - **Beobachtung probabilistischer Systeme**: Erfassen von Argumentationsschritten, Konfidenzbewertungen, aufgerufenen Datenquellen und Entscheidungsgründen, nicht nur Eingabe→Ausgabe - **Drifterkennung** – Überwachung auf Leistungseinbußen durch Datenverteilungsschichten, Änderungen an Geschäftsregeln oder Upstream-Modellaktualisierungen im Vergleich zu verhaltensbasierten Grundlagen - **Agentenversionierung und -bereitstellung**: schrittweise Einführung, A/B-Tests, Rollback und Versionskontrolle für Eingabeaufforderungen und Konfigurationen - **Vorfallsreaktion bei Agentenfehlern**: Unterscheiden von Modellfehlern, Orchestrierungsfehlern und Datenfehlern für die gezielte Behebung **Warum dies wichtig ist:** Nichtdeterministisches Verhalten erschwert die Beobachtbarkeit. Die zentrale Säule "Operational Excellence" bietet Ereignisüberwachungs- und DevOps-Praktiken. Die agentische Variante fügt ADLC, Drift-Erkennung und agentenspezifische Beobachtbarkeit hinzu. **Weitere Informationen:** [Agent Enterprise Operational Excellence (Operationelle Spitzenleistungen für Agentenunternehmen)](/docs/architect/de-de/well-architected/guide/agentic-enterprise-operational-excellence.html) ### Ressourcen- und Kostenoptimierung für Agentensysteme Die zentralen Ressourcen- und Kostenoptimierungsmuster (SOQL-Optimierung, Obergrenzen, Codeorganisation, Leistungsüberwachung, TCO-Modellierung, Build vs. Buy, Lizenzoptimierung, Kostenüberwachung) bleiben grundlegend. Agentische Systeme fügen hinzu: - **Optimierung der Rückschlusslatenz**: Streaming-Antworten, parallele Ausführung, Zwischenspeicherung und Aufforderungsoptimierung - **Tokensparsamkeit**: Jeder Aufruf-, Abruf- und Argumentationsschritt verbraucht Token. Entwerfen von Kontextverwaltungsstrategien (Zusammenfassung, selektiver Abruf) für begrenzte Kontextfenster - **Optimierung des Speicherabrufs** – effiziente Vektorsuche und semantischer Abruf, damit RAG-Muster keine Latenzengpässe verursachen - **Latenzverwaltung für mehrere** Agenten – parallele Ausführung von Spezialisten, asynchrone Delegation und Zeitüberschreitung des Budgets, um zu verhindern, dass sich die Latenz in sequenziellen Agentenketten ansammelt - **Agentenmodularisierung**: Zerlegen monolithischer Agenten in spezialisierte Agenten zur Wiederverwendung, unabhängigen Skalierung und gezielten Optimierung - **Verbrauchsbasierte Preise** – im Gegensatz zur Lizenzierung pro Benutzer skalieren sich die Agentenkosten mit der Nutzung, was ein anderes Budget und eine andere Prognose erfordert - **Agentische Arbeitseinheiten (AWUs)**: Messen Sie die Ausgaben anhand der von Agenten abgeschlossenen Arbeit und nicht nur anhand des Rohtokenverbrauchs und stimmen Sie den Verbrauch anhand des gelieferten Werts ab. - **Build vs. Buy for agentic features** (Erstellen im Vergleich zum Kauf für Agentenfunktionen): Bewerten Sie die Erstellung differenzierter Funktionen im Vergleich zur Übernahme von Rohstofffunktionen. - **ROI-Messung für Agenten** – Verfolgen der Geschäftsergebnisse im Vergleich zu den Betriebskosten für Agenten **Warum dies wichtig ist:** Der Tokenverbrauch und die Rückschlusslatenz sind neue Ressourceneinschränkungen und die Agentenkostenmodelle unterscheiden sich grundlegend von den Infrastrukturkosten. Die zentrale Säule bietet Anleitungen zur Obergrenze, SOQL-Optimierung und das TCO-Framework. Die agentische Variante fügt Tokensparsamkeit, Optimierung der Rückschlusslatenz, verbrauchsbasiertes Preismanagement und Agentische Arbeitseinheiten hinzu, um die Kosten mit den abgeschlossenen Arbeitsagenten zu messen. **Weitere Informationen:** [Ressourcen- und Kostenoptimierung für Agentenunternehmen](/docs/architect/de-de/well-architected/guide/agentic-enterprise-resource-and-cost-optimization.html) ### Fairness für Agentensysteme Die grundlegenden Fairness-Muster (Zugänglichkeit, Nichtdiskriminierung, Datenschutz, AI-Ethik-Governance) sind weiterhin grundlegend. Agentische Systeme fügen hinzu: - **Erklärbarkeit**: Agenten erklären, warum sie sich entschieden haben, welche Daten sie verwendet haben und welche Alternativen sie in Betracht gezogen haben. (Die Säule Trust deckt die Erklärbarkeit als Überprüfung und Transparenzkontrolle ab. Fairness gilt als das Recht eines Benutzers, eine Entscheidung zu verstehen, die ihn betrifft.) - **Anfechtbarkeit**: Benutzer können Entscheidungen von Agenten anfechten, eine Überprüfung durch Personen anfordern und den Beschwerdeprozess verstehen - **Bias-Erkennung und -Abmilderung** – Tests mit verschiedenen Eingaben und Überwachung auf unterschiedliche Ergebnisse über demografische Gruppen hinweg - **Menschliche Aufsicht proportional zu den Auswirkungen** – Entscheidungen mit hohem Einsatz erfordern "Human-in-the-Loop"; Entscheidungen mit niedrigem Einsatz können autonom funktionieren - **Gleichwertige agentengesteuerte Erfahrungen** – effektive Bereitstellung für alle Benutzer unabhängig von Sprachkenntnissen, technischen Fachkenntnissen oder Anforderungen an den barrierefreien Zugriff **Warum dies wichtig ist:** Autonome Agenten, die Entscheidungen treffen, die sich auf Personen auswirken, setzen auf Fairness. Die zentrale Fairness-Säule bietet Standards für den barrierefreien Zugriff und Nichtdiskriminierungsmuster. Die agentische Variante bietet Erklärbarkeit, Anfechtbarkeit und verhältnismäßige menschliche Aufsicht. **Weitere Informationen:** [Unternehmensfairness im Unternehmen](/docs/architect/de-de/well-architected/guide/agentic-enterprise-fairness.html) ## Verwenden dieses Dokuments mit den Säulenhandbüchern Beim Entwerfen von agentischen Lösungen: 1. **Starten Sie hier** für das Konzeptmodell: die Funktionen, die Agenten benötigen, und wie die Säulen auf Agenten angewendet werden. 2. **Lesen Sie die Leitfäden** zu den grundlegenden Ansätzen, die für alle Salesforce-Lösungen gelten. 3. **Lesen Sie die** Agentenspezifischen Designdetails in den Agentensäulen-Begleitern. Bauen Sie auf bewährten Plattformmustern auf und berücksichtigen Sie dann die von Agenten eingeführten Überlegungen. Die Kernsäulen bilden die Grundlage, die Agentengefährten die Details und diese Übersicht verbindet sie. ## Organisationsbereitschaft: Das Center of Excellence Die oben aufgeführten Funktionen und Säulen beschreiben, wie Sie ein Agentensystem erstellen. Damit dieses System in die Produktion aufgenommen werden kann, ist eine ständige Führungsstruktur erforderlich: ein Center of Excellence (CoE). Im vereinheitlichten System von Menschen, Agenten und Plattformen gibt das CoE Menschen Kontrolle. Das CoE definiert die Grenzen der Agenten, entscheidet, was die Produktion erreicht, und gleicht die Agentenarbeit mit den Geschäftsabsichten und behördlichen Anforderungen ab. Ein CoE ist der Unterschied zwischen verwalteten Agentensystemen und nicht verwalteten Experimenten, die in Schatten-AI abdriften – Agenten mit unklaren Berechtigungen, ohne Prüfprotokoll und unbekannten Kosten. Durch die Autonomie wird jede Governance-Entscheidung konsequent. Das CoE hilft Teams, diese Entscheidungen bewusst zu treffen und konsequent durchzusetzen, statt sie einzeln zu lösen. ### Was das Exzellenzzentrum leitet Ein CoE vereint Unternehmen, IT und Compliance um einen gemeinsamen Rückstand und eine gemeinsame Definition von "Bereit". Ihre Mitgliedschaft umfasst die Perspektiven, die eine Agentenentscheidung berührt: - **Ein leitender Sponsor** ist Inhaber der Budgetautorität und beseitigt Organisationshemmnisse. - **Unternehmensleads** übersetzen die Strategie in Prioritäten und sind Inhaber des Rückstands. - **Programmbüros und Datenverwalter** verbinden die Arbeit von Agenten mit umfassenderen Initiativen und bewerten die Datenintegrität und -sicherheit. - **Architekten, Administratoren und Entwickler** sind Inhaber des Datenmodells, der Integrationsmuster und des Bereitstellungsrhythmus und stellen technische Einschränkungen vor Arbeitsbeginn fest. Agenten versenden, ändern und wechseln schneller als herkömmliche Software. Damit die Governance mit der Bereitstellung in Einklang bleibt, wird der CoE in einem beschleunigten Rhythmus der asynchronen ersten Überprüfung ausgeführt. Der Rhythmus wird im Vergleich zu einem herkömmlichen CoE enger und die asynchrone Überprüfung wird zum Standardarbeitsmodus: - Die **kontinuierliche asynchrone Überprüfung** ist der primäre Modus: Mitglieder bleiben in einem freigegebenen Kanal ausgerichtet, wenn Änderungen angezeigt werden, nicht nur bei geplanten Besprechungen. - **Wöchentliche operative Überprüfungen** bestätigen, dass Änderungen im laufenden Betrieb mit aktiven Agenten und Integrationen kompatibel bleiben – und zwar schneller als die monatlichen oder vierteljährlichen Überprüfungen, die eine langsamere Bereitstellung ermöglichen würden. - **Monatliche strategische Überprüfungen** wägen den Rückstand mit den Geschäftsprioritäten ab und bewerten die Bereitschaft mit der aktuellen Datenqualitätsgrundlage. Der Ausschuss für handlungsrelevante Beziehungen trifft explizite Entscheidungen darüber, wer Änderungen an Objekten, Feldern und Automatisierungen genehmigt, von denen Agenten abhängig sind, wer die Priorität bei Anforderungen besitzt, wann die technischen Schulden eingestellt werden und welche Geschäftskennzahlen den Erfolg bestimmen. ### Bewerten der Bereitschaft über die Säulen hinweg Ein für Agenten geeignetes CoE regelt jede Säule. Die Leitfäden für die zentralen Säulen stellen die grundlegenden Kontrollen bereit. Im Rahmen des einheitlichen Geschäftsmodells werden sie zu einer erzwungenen und beobachtbaren Praxis. - **Trust**: Die Objekt-, Feld- und Datensatzebenensicherheit regelt die von Agenten verwendeten Daten. Zugriffssteuerungen auf Agentenebene begrenzen die Daten und Aktionen, auf die jeder Agent zugreifen kann. Identitäts-, Mindestberechtigungs- und Bedrohungsmodellierung sind in das Design des Agenten eingebettet. Siehe [Trust](/docs/architect/de-de/well-architected/guide/trust.html) and [Agentic Enterprise Trust](/docs/architect/de-de/well-architected/guide/agentic-enterprise-trust.html). - **Operational Excellence**: In Verfolgungs- und Überwachungsprotokollen werden Entscheidungen, Aktionen und Ausgaben von Agenten erfasst. Überwachungs-Dashboards überprüfen die Leistung und die Ausrichtung im Hinblick auf Ziele im gesamten Agentenentwicklungslebenszyklus. Entsprechende Informationen finden Sie unter [Operational Excellence](/docs/architect/de-de/well-architected/guide/operational-excellence.html) and [Agentic Enterprise Operational Excellence](/docs/architect/de-de/well-architected/guide/agentic-enterprise-operational-excellence.html). - **Zuverlässigkeit** und **Ressourcen- und Kostenoptimierung** – Spezifikation, Testgenerierung, Feedbackschleifen und Abschreibung regeln den gesamten Agentenlebenszyklus. Ratenbegrenzung, Ressourcensteuerungen und Behebungsstrategien enthalten die Auswirkungen von Agentenfehlern. Entsprechende Informationen finden Sie unter [Zuverlässigkeit](/docs/architect/de-de/well-architected/guide/reliability.html) und [Ressourcen- und Kostenoptimierung](/docs/architect/de-de/well-architected/guide/resource-and-cost-optimization.html). - **Fairness**: Über Human-in-the-Loop-Kontrollpunkte können Personen Folgeaktionen abfangen oder überprüfen. Eskalationspfade und Mitarbeiterschulungen bereiten Personen darauf vor, Agenten-Workflows zu überprüfen und außer Kraft zu setzen. Entsprechende Informationen finden Sie unter [Fairness](/docs/architect/de-de/well-architected/guide/fairness.html) und [agentische Unternehmensfairness](/docs/architect/de-de/well-architected/guide/agentic-enterprise-fairness.html). ### Bereitschaftssignale Ein CoE ist bereit, Agentenarbeitslasten zu steuern, wenn die folgenden Bedingungen erfüllt sind: - **Richtlinie**: Zugriffs- und Aktionsrichtlinien für Agenten werden definiert, erzwungen und können überprüft werden. - **Beobachtbarkeit**: Überwachungs- und Überwachungstools unterstützen Echtzeit- und nachträgliche Überprüfungen des Agentenverhaltens. - **Sicher durch Design**: Sicherheit, Datenschutz und Compliance sind von Anfang an in Agenten-Workflows integriert. - **Lebenszyklus**: Ein strukturierter Prozess regelt die Einarbeitung, Aktualisierung und Einstellung von Agenten. - **Menschliche Aufsicht**: Überprüfer verarbeiten Ausnahmen und verwenden Feedback, um die Workflows für Agenten zu verbessern. Bestätigen Sie diese vier Grundlagen, bevor Sie Ihren ersten Produktionsagenten bereitstellen: - **Eine dokumentierte Datenqualitätsgrundlage**, die regelmäßig überprüft wird. - **Ein formaler Genehmigungsprozess** für Schemaänderungen mit einem benannten Inhaber und aufgezeichneter Abmeldung. - **Ein geführtes technisches Schuldenregister**, das im strategischen Rhythmus überprüft wird. - **Eine AI-Governance-Richtlinie**, die Datenzugriff, Agentenumfang und Prüfungsanforderungen abdeckt. > **Architektonische Bedeutung:** Richten Sie die Kontaktaufnahmestelle ein und bestätigen Sie diese Grundlagen, bevor Sie autonome Agenten bereitstellen. Governance, die von Anfang an integriert ist, wird mit der Akzeptanz durch Agenten skaliert. Die nachträglich nachgerüstete Governance konkurriert mit der Ausbreitung, die verhindert werden soll. **Siehe auch:** [Bereitstellungsgenehmigungsprozesse](/docs/architect/de-de/well-architected/guide/agentic-enterprise-operational-excellence.html#deployment-approval-processes) im Agentic Enterprise Operational Excellence Guide – der Checkliste für Agenten ohne Startberechtigung, die die Bereitschaftsansicht auf Organisationsebene dieses Abschnitts ergänzt. ## Erste Schritte Organisationen, die ihre Agentenreise beginnen, sollten: 1. **Beginnen Sie mit Anwendungsfällen** mit hohem Wert – konzentrieren Sie sich zunächst auf Workflows mit klarem ROI. Erfolg schafft Dynamik. 2. **Erstellen grundlegender Funktionen**: Einrichten von Datenverwaltung, Knowledge Bases und Integrationsmustern. 3. **Entwickeln von Agentenkompetenz** – Erstellen Sie Fertigkeiten in der Eingabeaufforderungstechnik und Agentenarchitektur, auch wenn Tools mit niedrigem Code und natürlicher Sprache die Eintrittsbarriere senken. 4. **Einrichten eines Exzellenzzentrums** – Einrichten des Leitungsorgans, das Inhaber von Genehmigungsprozessen, Sicherheitstests und Überwachung ist, bevor Produktionsagenten bereitgestellt werden (siehe *Organisationsbereitschaft: Das Center of Excellence* oben). 5. **Iterate** (Iterieren): Planen Sie eine kontinuierliche Optimierung anstelle einer perfekten Erstbereitstellung. 6. **Messwert**: Verfolgen Sie Geschäftsergebnisse, Kosteneinsparungen und Benutzerzufriedenheit, um Investitionen zu unterstützen. Das Agentic Enterprise ist eine transformative Opportunity für Organisationen, die bereit sind, AI-gestützte Workflows zu nutzen. Mit einer bewussten architektonischen Gestaltung können Sie sie realisieren und gleichzeitig Risiken und Komplexität verwalten.

Teilen Sie uns Ihr Feedback zum Well-Architected Framework mit.

# Datenschutzmuster
Weitere Informationen zu Well-Architected [Trust](/docs/architect/de-de/well-architected/guide/trust.html) → [Datenschutz und Privatsphäre](/docs/architect/de-de/well-architected/guide/trust.html#data-protection-and-privacy) ## Datenklassifizierung **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Datenklassifizierungsschema | ✅ Klassifizierungsschema dokumentiert mit Ebenen (Öffentlich, Intern, Vertraulich, Eingeschränkt)
✅ Geschäftsbeispiele für jede Klassifizierungsebene
✅ Klassifizierungsschema, das an behördlichen Verpflichtungen (HIPAA, PCI DSS, DSGVO) ausgerichtet ist
✅ Datenmodellierer, die während des Designs für die einheitliche Anwendung der Klassifizierung geschult wurden
✅ Neue Felder, die als Teil des Datenmodellierungsprozesses klassifiziert werden, nicht rückwirkend | | Feldebenenklassifizierung | ✅ Klassifizierung wird auf Feldebene angewendet, nicht nur auf Objektebene
✅ Felder in einem einzelnen Objekt können unterschiedliche Klassifizierungen aufweisen
✅ Feldebenensicherheit spiegelt Klassifizierungsunterschiede wider
✅ Nicht klassifizierte Daten werden standardmäßig auf die höchste geeignete Schutzebene festgelegt
✅ Klassifizierung steuert Schutzsteuerungen (Verschlüsselung, Zugriff, Aufbewahrung) | | Benutzerdefinierte Objekte und Felder | ✅ Alle benutzerdefinierten Objekte verfügen über eine dokumentierte Datenklassifizierung
✅ Als vertraulich oder eingeschränkt klassifizierte sensible Felder (Gehalt, SSN, PHI, Zahlungsdaten)
✅ Öffentliche Felder (Firmenname, Website), die als "Öffentlich" dokumentiert sind
✅ In Feldbeschreibungen erfasste Klassifizierungsmetadaten
✅ Klassifizierung während Codeüberprüfungen und ARB überprüft | | Standardobjekte | ✅ Standardobjektfelder werden anhand des Klassifizierungsschemas ausgewertet
Shield Platform Encryption für eingeschränkte Standardfelder aktiviert
✅ Auf vertrauliche Standardfelder angewendete Feldebenensicherheit
✅ Berichte und Listenansichten gefiltert, um die Offenlegung vertraulicher Standardfelder zu verhindern | | Integrationsdaten | ✅ Daten, die durch Integrationen fließen, die vor der Implementierung klassifiziert wurden
✅ Externe Systemdatenvertraulichkeit ausgewertet und dokumentiert
✅ Integrationsendpunkte, die eingeschränkte Daten verarbeiten, verwenden zertifikatsbasierte Authentifizierung
✅ Datenklassifizierung über Systemgrenzen hinweg beibehalten | | Compliance-Zuordnung | ✅ HIPAA-PHI-Felder identifiziert und mit "Eingeschränkt" markiert
✅ PCI-Karteninhaberdaten werden nach Möglichkeit in Salesforce vermieden – zur Reduzierung des Umfangs über das Zahlungs-Gateway tokenisiert. Verwenden Sie dort, wo sie gespeichert werden müssen, "Verschlüsselte benutzerdefinierte Felder" unter PCI DSS-Steuerelementen.
✅ Identifizierte personenbezogene Daten der DSGVO, die Datenschutzkontrollen unterliegen
✅ SOX-Finanzdaten klassifiziert und unterliegen der Aufgabentrennung | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Einheitlicher Schutz | ⚠️ Gleicher Schutz für alle Felder unabhängig von der Empfindlichkeit
⚠️ Daten mit niedrigem Wert sind überschützt (Verschwendung von Ressourcen), während Daten mit hohem Wert unterschützt sind
⚠️ Öffentliche Unternehmensinformationen werden genauso behandelt wie PHI- oder Zahlungskartendaten
⚠️ Jedes verschlüsselte Feld ohne Klassifizierungsberechtigung | | Rückwirkende Klassifizierung | ⚠️ Nach Bereitstellung in der Produktion klassifizierte Daten
⚠️ Sensible Daten, die durch Compliance-Prüfungen und nicht durch Designüberprüfungen ermittelt wurden
⚠️ Nur nach Sicherheitsvorfällen klassifizierte Daten
⚠️ "Wir werden die Klassifizierung später herausfinden" ist der Standard während der Entwicklung | | Nur Klassifizierung auf Objektebene | ⚠️ Ganze Objekte, die einheitlich klassifiziert werden, wenn Felder unterschiedliche Empfindlichkeit aufweisen
⚠️ Zugriff auf Objektebene ohne Feldebenensicherheit für sensible Felder
⚠️ Alle Felder in Account- oder Kontaktobjekten weisen dieselbe Klassifizierung auf.
⚠️ Objektberechtigungen, die als einzige Zugriffssteuerung für Objekte mit gemischter Sensitivität verwendet werden | | Tribal Knowledge | ⚠️ Klassifizierung undokumentiert, nur in Knowledge wichtiger Personen vorhanden
⚠️ Entwickler vertrauten darauf, "nur zu wissen", welche Felder vertraulich sind
⚠️ Kein schriftliches Klassifizierungsschema, auf das alle Datenmodellierer zugreifen können
⚠️ Neue Teammitglieder ohne Klassifizierungstraining | ## Verschlüsselung **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Verschlüsselung im Leerlauf | ✅ Alle auf Infrastrukturebene über Hyperforce verschlüsselten Daten
Shield Platform Encryption für eingeschränkte Daten aktiviert
✅ Verschlüsselungsschema (probabilistisch, deterministisch, deterministisch mit Berücksichtigung der Groß- und Kleinschreibung), ausgewählt anhand der Anforderungen an Abfrage und Eindeutigkeit
✅ Verschlüsselungskonflikte während des Datenmodelldesigns ausgewertet | | Shield Platform Encryption-Strategie | ✅ Probabilistische Verschlüsselung für die meisten eingeschränkten Felder (unterstützt alle Abfragevorgänge)
✅ Deterministische Verschlüsselung, die für Felder verwendet wird, die exakt übereinstimmende WHERE-Klauseln oder Eindeutigkeit erfordern
✅ Deterministisches Element mit Berücksichtigung der Groß- und Kleinschreibung, bei dem die Unterscheidung von Kundenvorgängen für die Geschäftslogik wichtig ist
✅ Verhalten des verschlüsselten Felds vor der Produktionsbereitstellung getestet
✅ Formelfeldverweise auf entsprechend verarbeitete verschlüsselte Felder (bei Bedarf in Apex verschoben) | | Schlüsselverwaltung | ✅ Wichtige Rotationsvorgänge dokumentiert und automatisiert
✅ Wichtige Zerstörungsszenarien, die während der Notfallwiederherstellung getestet wurden
✅ Vom Kunden verwaltete Schlüssel (BYOK), die auf Compliance hin ausgewertet wurden und eine explizite Schlüsselkontrolle erfordern
✅ Wichtige Widerrufsverfahren dokumentiert
✅ Lebenszyklus des Verschlüsselungsschlüssels, der gemäß den Compliance-Anforderungen verwaltet wird | | Verschlüsselung während der Übertragung | ✅ TLS 1.2 oder höher für alle Integrationen erforderlich
✅ zertifikatsbasierte gegenseitige Authentifizierung für Integrationen, die eingeschränkte Daten verarbeiten
✅ HSTS-Kopfzeilen, die für Experience Cloud-Sites konfiguriert sind, um ein Herunterstufen des Protokolls zu verhindern
✅ TLS-Zertifikatablauf überwacht und automatische Verlängerung konfiguriert
✅ Schwache Chiffren und Protokolle deaktiviert | | Code und Konfiguration | ✅ Anmeldeinformationen, die nie in Code, Konfigurationsdateien oder Versionskontrolle eingebettet sind
✅ Anmeldeinformationen mit Namen und externe Anmeldeinformationen, die zur zentralen Verwaltung der Authentifizierung verwendet werden
✅ In die Architektur integrierte Rotationsfunktionen für Anmeldeinformationen
✅ Abstrakte Authentifizierung von Anmeldeinformationen mit Namen aus Code, wodurch Aktualisierungen ohne Codeänderungen ermöglicht werden | | AppExchange-Pakete | ✅ Vor der Installation bewertete Paketsicherheitsanforderungen
✅ Verschlüsselte Felder, auf die Pakete nur zugreifen können, wenn sie geschäftlich gerechtfertigt sind
✅ Über die Ereignisüberwachung überwachte Paketdatenzugriffsmuster
✅ Pakete, die Zugriff auf eingeschränkte Daten erfordern, werden einer erweiterten Überprüfung unterzogen | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Verschlüsselung ohne Auswertung | ⚠️ Probabilistische Verschlüsselung für alle Felder ohne Tests aktiviert
⚠️ Kritische Berichte, bei denen in der Produktion ein Fehler festgestellt wurde, da verschlüsselte Felder nicht aggregiert werden können
⚠️ Verschlüsselung für Formelfeldquellen aktiviert, ohne Auswirkungen zu verstehen
⚠️ Felder, die in SOQL LIKE-Abfragen verwendet werden, die ohne Wechsel zur deterministischen Verschlüsselung verschlüsselt wurden | | Eingebettete Anmeldeinformationen | ⚠️ In Code, benutzerdefinierte Einstellungen oder Versionskontrolle eingebettete Anmeldeinformationen
⚠️ In Apex Klassen hartcodierte API-Schlüssel, Kennwörter und Zertifikate
⚠️ In Quellcodeverwaltungs-Repositorys übernommene Anmeldeinformationen
⚠️ In benutzerdefinierten Metadaten oder benutzerdefinierten Einstellungen ohne Verschlüsselung gespeicherte Anmeldeinformationen | | Schwache oder ältere Protokolle | ⚠️ TLS 1.0 oder 1.1 akzeptiert (ersetzt und gefährdet)
⚠️ OAuth-Flow mit Benutzername und Kennwort zulässig, wenn JWT-Bearer verfügbar ist
⚠️ In Produktionsintegrationen akzeptierte selbstsignierte Zertifikate
⚠️ Zertifikatvalidierung deaktiviert, damit die Integration funktioniert | | Keine Schlüsselverwaltung | Shield Platform Encryption ist ohne Schlüsselrotationsverfahren aktiviert
⚠️ Keine dokumentierten Schlüsselvernichtungsszenarien
⚠️ Standardschlüssel, die verwendet werden, ohne vom Kunden verwaltete Schlüssel auf Compliance auszuwerten
⚠️ Schlüsselrotation und Widerrufsverfahren nie getestet | | Überverschlüsselung | ⚠️ Öffentliche oder interne Klassifizierungsdaten verschlüsselt, was Kosten ohne Nutzen verursacht
⚠️ Shield Platform Encryption für jedes Feld aktiviert, wodurch unnötige Komplexität entsteht
⚠️ BYOK wird verwendet, wenn die Compliance dies nicht erfordert (fügt operativen Overhead hinzu)
⚠️ Verschlüsselung erforderlich, wenn die Datenklassifizierung dies nicht rechtfertigt | ## Datenmaskierung **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Sandbox-Strategie | ✅ Eingeschränkte Daten gelangen niemals in Entwicklungs- oder Testumgebungen
✅ Teilweise Sandbox-Kopie schließt eingeschränkte Objekte und Felder aus
✅ Sandbox-Vorlagen definieren, welche Objekte und Felder nach Umgebungstyp eingeschlossen werden sollen
✅ Data Mask für Sandbox-Instanzen konfiguriert, die produktionsähnliche Daten erfordern | | Data Mask Regeln | ✅ Data Mask Regeln verbergen sensible Felder und behalten gleichzeitig die Dateneigenschaften bei
✅ Muster behalten die referenzielle Integrität bei (dieselbe Eingabe erzeugt dieselbe maskierte Ausgabe)
✅ E-Mail-Adressen werden maskiert, bleiben aber für Tests gültig
✅ Telefonnummern maskiert, aber gültiges Format beibehalten
✅ Datumsverschiebungen durchgängige Aufrechterhaltung relativer Beziehungen
✅ Numerische Felder randomisiert innerhalb realistischer Bereiche | | Synthetische Daten | ✅ Entwicklungsumgebungen verwenden die Generierung synthetischer Daten
✅ Synthetische Daten weisen realistische Eigenschaften auf, die effektive Tests ermöglichen
✅ Keine Produktionsdaten für die Entwicklung erforderlich
✅ Testdatengenerierung automatisiert in Entwicklungs-Pipelines | | Nicht-Produktionsumgebungen | ✅ Produktionsdaten wurden nie in persönliche Entwicklerorganisationen kopiert
✅ Screenshots und Demos verwenden maskierte oder synthetische Daten
✅ Trainingsumgebungen verwenden synthetische Daten oder stark maskierte Produktionsdaten
✅ Zugriff von Vertragsnehmern und Anbietern auf Nicht-Produktionsdaten auf die Klassifizierung "Nur zur geschäftlichen Verwendung" | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Produktionsdaten in Sandbox-Instanzen | ⚠️ Vollständige Sandbox-Instanzen mit nicht maskierten Produktionsdaten für die Entwicklung aktualisiert
⚠️ Eingeschränkte Daten, die zur Bequemlichkeit in Entwickler-Sandbox-Instanzen kopiert werden
⚠️ Entwicklern wurde umfassender Zugriff auf Produktionsdaten-Sandbox-Instanzen gewährt
⚠️ Sandbox-Instanzen wurden mit sensiblen Daten aktualisiert, "weil Tests mit echten Daten einfacher sind" | | Keine synthetischen Daten | ⚠️ Produktionsdaten, die nur für alle Tests verwendet werden
⚠️ Keine synthetische Datengenerierung für Entwicklungsumgebungen
⚠️ "Wir brauchen echte Daten" angenommen, ohne synthetische Alternativen zu bewerten
⚠️ Manuelle Testdaten, die erstellt werden, wenn die Generierung automatisiert werden kann | ## Datenschutz nach Design **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Datenminimierung | ✅ Nur Daten, die für angegebene Geschäftszwecke erforderlich sind, werden erfasst
✅ Jede Feldergänzung wird mit "Welche architektonische Entscheidung erfordert diese Daten?"
✅ Daten, die nicht mehr dem Sammlungszweck dienen, wurden entfernt
✅ Optionale Felder sind klar gekennzeichnet und ohne geschäftliche Begründung nicht erforderlich
✅ Historische Datenaufbewahrung an der Rechtsgrundlage ausgerichtet, nicht "alles für immer beibehalten" | | Zweckbegrenzung | ✅ Berechtigungssätze schränken den Datenzugriff basierend auf dem Zweck der Auftragsfunktion ein
✅ Marketingbenutzer können ohne dokumentierte Begründung nicht auf Support-Kundenvorgangsdetails zugreifen
✅ Vertriebsbenutzer können nur dann auf Kundendienstverläufe zugreifen, wenn der Auftrag dies erfordert
✅ Funktionsübergreifender Datenzugriff erfordert explizite Genehmigung und Überwachung
✅ Datenzugriffszweck in Berechtigungssatzbeschreibungen dokumentiert | | Einwilligungsverwaltung | ✅ Einwilligung, die auf individueller Ebene für Marketing, Analysen und optionale Verarbeitung erfasst wird
✅ Einwilligung ist granular (zweckspezifisch), nicht binäre pauschale Einwilligung
✅ Workflows zum Widerruf von Einwilligungen werden in integrierte Systeme übernommen
✅ Einwilligungsentscheidungen mit Zeitstempel, Version und Mechanismus verfolgt
✅ Einwilligungsbenutzeroberfläche erklärt eindeutig, womit der Benutzer einverstanden ist | | Rechte der betroffenen Person | ✅ Zugriffsanforderungs-Workflows stellen Datenkopien innerhalb der Frist bereit, die von der maßgebenden Verordnung für Ihre Bereitstellung festgelegt wurde
✅ Korrektur-Workflows korrigieren Ungenauigkeiten mit Audit-Trail
✅ Lösch-Workflows löschen Daten, sofern gesetzlich zulässig (unter Berücksichtigung von Aufbewahrungspflichten)
✅ Workflows zur Übertragbarkeit exportieren Daten in maschinenlesbarem Format
✅ Regelmäßig getestete Workflows für Rechte betroffener Personen zur Validierung von Zeitachsen
✅ Workflow-Automatisierung stellt sicher, dass regulatorische Zeitpläne einheitlich eingehalten werden | | Datenschutzkontrollen | ✅ Datenschutzkontrollen werden technisch erzwungen, nicht nur durch Richtlinien
✅ Freigaberegeln implementieren Zweckbegrenzung
✅ Feldebenensicherheit schützt sensible Attribute
✅ Audit Trails erfassen datenschutzrelevante Ereignisse
✅ Datenschutzkontrollen in CI/CD-Pipelines validiert | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Sammeln Sie alles | ⚠️ Ansatz “Alle möglichen Daten erfassen, wir könnten sie eines Tages benötigen”
⚠️ Felder, die ohne dokumentierten Geschäftszweck hinzugefügt wurden
⚠️ Unbegrenzt gespeicherte Daten ohne Aufbewahrungsrechtfertigung
⚠️ Optionale Daten, die durch Pflichtfelder erfasst werden | | Leere Einwilligung | ⚠️ Single "Akzeptieren" Einwilligung für alle Zwecke
⚠️ Marketingeinwilligung kombiniert mit Servicebereitstellung in einem einzigen Kontrollkästchen
⚠️ Alles-oder-nichts-Einwilligung, wenn Zwecke getrennt werden können
⚠️ Einwilligung in 20-seitige Nutzungsbedingungen eingebettet | | Police ohne Erzwingung | ⚠️ In der Datenschutzerklärung werden ideale Vorgehensweisen beschrieben, die technisch nicht umgesetzt werden
⚠️ Benutzerschulung erforderlich, um unangemessenen Datenzugriff zu verhindern
⚠️ Datenschutzgrundsätze ohne Implementierung technischer Kontrollen dokumentiert
⚠️ Annahme der Policenkonformität ohne Überwachung und Validierung | | Manuelle Anforderungen betroffener Personen | ⚠️ DSGVO/CCPA-Anforderungen, die über manuelle IT-Tickets verarbeitet werden, die Monate dauern
⚠️ Keine dokumentierten Verfahren für Zugriff, Berichtigung, Löschung, Übertragbarkeit
⚠️ Das Fenster für den Abschluss von Anforderungen, das in der maßgebenden Verordnung für Ihre Bereitstellung festgelegt ist, wurde verpasst
⚠️ Anforderung, dass Workflows, die bei Prüfungen gefunden wurden, nicht vorhanden sind | | Übermäßige Datenfreigabe | ⚠️ Weitreichender Datenzugriff über Abteilungen hinweg ohne Zweckgrund
⚠️ Marketing-Zugriff auf Support-Kundenvorgangsdetails
⚠️ Vertrieb erlaubt Zugriff auf Kundendienstverläufe ohne dokumentierte Notwendigkeit
⚠️ Öffentlicher Lese-/Schreibzugriff für Objekte, die personenbezogene Daten enthalten | ## Datenresidenz **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | Regionale Hyperforce-Bereitstellung | ✅ In Hyperforce Region bereitgestellte Organisation, die die Anforderungen an die Datenresidenz erfüllt
✅ Datenspeicherung und -verarbeitung erfolgen innerhalb der erforderlichen geografischen Grenzen
✅ Regionale Anforderungen vor der Bereitstellung dokumentiert und validiert
✅ Anforderungen an mehrere Regionen, die bei Bedarf durch eine Architektur mit mehreren Organisationen erfüllt werden | | Datenflusszuordnung | ✅ Datenfluss ordnet Dokument zu, woher die Daten stammen, weitergeleitet werden und sich dort befinden
✅ Grenzüberschreitende Datenübertragungen identifiziert und anhand von Vorschriften ausgewertet
✅ Standardvertragsklauseln oder verbindliche Unternehmensregeln für internationale Transfers
✅ Datentransferpfade, die auf die Einhaltung der Residenzen hin ausgewertet wurden, nicht nur Speicherort | | Umfang der Datenresidenz | ✅ Datenspeicherort (welche Hyperforce Region)
✅ Datenverarbeitungsstandort (Rechenregionen)
✅ Backup-Speicherort
✅ Speicherort für Protokollierungs- und Überwachungsprotokolle
✅ Integrationstransitpfade für grenzüberschreitende Datenbewegungen ausgewertet | | Architektur mit mehreren Organisationen | ✅ Architektur mit mehreren Organisationen, die verwendet wird, wenn behördliche Anforderungen in einer einzelnen Organisation nicht erfüllt werden können
✅ Jede Organisation wird in der entsprechenden Region für ihre Daten bereitgestellt
✅ Integrationsmuster berücksichtigen Einschränkungen bei der Datenresidenz
✅ In AS dokumentierte Kompromisse bei der betrieblichen Komplexität | | Compliance-Validierung | ✅ Datenresidenzanforderungen nach Gerichtsbarkeit dokumentiert
✅ Hyperforce Regionsauswahl vor der Bereitstellung anhand der Anforderungen validiert
✅ Regelmäßige Prüfungen bestätigen, dass die Daten innerhalb der erforderlichen Grenzen bleiben
✅ Änderungen an Residenzbestimmungen lösen Architekturüberprüfung aus | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | Residenzaufsicht | ⚠️ Bei Compliance-Prüfungen festgestellte Verstöße gegen die Datenresidenz
⚠️ Bereitstellung von Organisationen ohne Bewertung regionaler Anforderungen
⚠️ "Cloud is Cloud" (Cloud ist Cloud) wird ohne Berücksichtigung von Datenstandortbestimmungen angenommen
⚠️ Rechtsordnungen hinzugefügt, ohne die Residenzpflichten zu überprüfen | | Transit ignoring residency (Residenz zum Ignorieren von Transitvorgängen) | ⚠️ Nur Speicherort berücksichtigt, während Transitpfade ignoriert werden
⚠️ Durch Regionen außerhalb der Compliance-Grenzen weitergeleitete Daten
⚠️ Integrations-Middleware, die in nicht kompatiblen Regionen verwendet wird
⚠️ In anderen Regionen als Primärdaten gespeicherte Sicherungen | | Unnötige Multi-Organisation | ⚠️ Architektur für mehrere Organisationen, die verwendet wird, wenn eine einzelne Organisation mit Hyperforce Regionen ausreicht
⚠️ Operative Komplexität, Lizenzkosten und Integrations-Overhead multipliziert ohne regulatorische Notwendigkeit
⚠️ Multi-Organisation implementiert "nur um sicher zu sein" ohne eine spezifische Compliance-Anforderung
⚠️ Multi-Organisation standardmäßig verwendet, wenn Datenklassifizierung und Zugriffssteuerungen ausreichend sind | # Fairness Fairness ## Übersicht In Salesforce-Architekturen bedeutet Fairness, Lösungen zu entwickeln, die den Benutzern durch barrierefreie Oberflächen, Verzerrungserkennung und -minderung, transparente Entscheidungen und ethische Unternehmensführung gleichermaßen dienen. Die Prognosen von Einstein beeinflussen die Ergebnisse, die sich auf Kunden und Mitarbeiter auswirken. Das bedeutet, dass Architekten Systeme entwerfen sollten, die gruppenübergreifend gerechte Ergebnisse erzielen und gleichzeitig für Benutzer mit Behinderungen zugänglich bleiben. Salesforce bietet Plattformfunktionen, die auf Fairness ausgerichtet sind, und wir sind bestrebt, [WCAG 2.2 AA](https://www.w3.org/TR/WCAG22/) zu erfüllen. Bei ordnungsgemäßer Verwendung stellt das Salesforce Lightning Design System (SLDS) Komponenten bereit, die dieses Ziel unterstützen. Sehen wir uns die einzelnen Komponenten genauer an. - Die Shield Platform Encryption schützt sensible Attribute wie demografische Daten und die Ereignisüberwachung bietet die Überwachungsprotokolle, die die transparente Datenverarbeitung unterstützen. - Die Einstein Trust Layer (ETL) erfasst einen sicheren Überwachungspfad für Eingabeaufforderungen und Antworten mit generativer AI zu Überwachungs- und Compliance-Zwecken. - Experience Cloud enthält Steuerelemente für den barrierefreien Zugriff. - Das Feld-Aktivierungsprotokoll bietet eine langfristige Aufbewahrung des Datenänderungsverlaufs auf Feldebene, wodurch die algorithmische Verantwortlichkeit unterstützt wird, wenn AI-Entscheidungsdaten in verfolgten Feldern gespeichert werden. Mit diesen Funktionen können Sie die Betriebskosten von Salesforce-Fairnesspraktiken senken. Bei Salesforce funktioniert Fairness in drei Dimensionen, um Lösungen bereitzustellen. Dank des integrierten Designs können Lightning Web Components (LWC), Visualforce-Seiten und Experience Cloud-Sites vollständig aufgerufen werden. Mithilfe von KI-Fairness-Praktiken können Einstein-Prognosen mithilfe von Verzerrungserkennung, vielfältigen Trainingsdaten und kontinuierlicher Überwachung angemessene Ergebnisse erzielen. Governance bietet die Prozesse und Kontrollen, um Fairness bei der Weiterentwicklung von Modellen und der Ausweitung von Anwendungsfällen zu gewährleisten. Wenn Fairness vernachlässigt wird, entsteht ein Verschlechterungsrisiko. Nicht zugängliche Experience Cloud-Sites können Organisationen mit Rechtsstreitigkeiten gegen den [Americans with Disabilities Act](https://www.ada.gov/law-and-regs/) (ADA) und für Bundesbehörden und deren Vertragsnehmer mit Verstößen gegen [§ 508](https://www.section508.gov/) Konformitätsbestimmungen befassen. Abhängig von der Risikoklassifizierung des Systems und den neuen Gesetzen zur algorithmischen Verantwortlichkeit können verzerrte Einstein-Prognosen gegen die Anforderungen des [EU-AI Act](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) verstoßen. Nur automatisierte AI-gestützte Entscheidungen mit rechtlichen oder ähnlich bedeutenden Auswirkungen, bei denen keine aussagekräftigen Informationen über die Entscheidungslogik vorliegen, können gegen die Informationsrechte [der DSGVO gemäß Artikel 22](https://gdpr-info.eu/art-22-gdpr/) und [Artikel 15 Absatz 1 Buchstabe](https://gdpr-info.eu/art-15-gdpr/) h verstoßen. Organisationen, die auf Fairness ausgerichtet sind, reduzieren in der Regel den vorhersehbaren Schaden für Kunden, Mitarbeiter und Communities, die von ihren Systemen betroffen sind. Misserfolge der Fairness können betroffenen Personen spürbaren materiellen Schaden zufügen, einschließlich wirtschaftlicher Schäden, verweigerter Opportunities, emotionaler Belastung und Verstärkung systemischer Diskriminierung. Regulatorische Angleichung neigt dazu, betroffenen Personen gut zu dienen. ## Designprinzipien Verwenden Sie diese Grundsätze, um Ihre architektonischen Entscheidungen für Fairness auf der Plattform zu leiten. - **Design für Lightning-Muster für den barrierefreien Zugriff.** Verwenden Sie beim Erstellen das Lightning Design System und standardmäßige Lightning Web Components, die den barrierefreien Zugriff auf WCAG 2.2 AA nach Möglichkeit unterstützen. Wenn Sie mit SLDS erstellen, nutzen Sie eine Bibliothek, in der der barrierefreie Zugriff ein zentrales Designprinzip ist. SLDS-Komponenten werden auf Barrierefreiheit und Kompatibilität mit Hilfstechnologien überprüft. Viele enthalten einen Abschnitt für den barrierefreien Zugriff mit Tipps für Entwickler. Wenn eine benutzerdefinierte Komponente erforderlich ist, müssen die explizite Implementierung von barrierefreien Rich-Internet-Anwendungen ([WAI-ARIA](https://www.w3.org/WAI/standards-guidelines/aria/)), semantische HTML- und Tastaturnavigationsmuster durch unterstützende Technologietests validiert werden. - **Verringern und überwachen Sie Verzerrungen mit den richtigen Tools für jeden Modelltyp.** Validieren Sie AI-Ausgaben für gerechte Ergebnisse über demografische Gruppen hinweg vor der Bereitstellung und kontinuierlich in der Produktion. Erfassen Sie für Prognosemodelle Entscheidungsdaten über Einstein Discovery und benutzerdefinierte Instrumente und analysieren Sie sie in CRM Analytics, um Fairness-Kennzahlen zu messen. Verwenden Sie für Funktionen der generativen AI und Agentforce den Einstein Trust Layer-Aktivierungsprotokoll mit Aufforderungen und Antworten. Dokumentieren Sie Entscheidungen, um regulatorische Transparenzanforderungen zu erfüllen. - **Nutzen Sie Shield Platform Encryption für Datenschutzkontrollen.** Verwenden Sie die Shield Platform Encryption mit deterministischen Schemas für sensible Attribute, für die Abfragen mit exakter Übereinstimmung erforderlich sind und die gleichzeitig persönliche Daten schützen. Leiten Sie Ereignisüberwachungsprotokolle an ein externes SIEM-System (Security Information and Event Management) weiter, um manipulationssichere Überprüfungsprotokolle zu unterstützen, wenn das SIEM einmal schreibgeschützten Speicher und Zugriffstrennung erzwingt, die die nativen Salesforce-Aufbewahrungsfenster für erforderliche Vorschriften überschreiten. - **Entwerfen Sie Workflows zur Überprüfung von Prognosen mit hohem Einsatz.** Konfigurieren Sie Genehmigungsprozesse und Überprüfungsmechanismen im Salesforce-Flow, um sicherzustellen, dass Einstein-Prognosen, die sich auf Folgeentscheidungen auswirken, eine angemessene menschliche Überprüfung erhalten. Verwenden Sie Konfidenzschwellenwerte und Geschäftsregeln, um zu bestimmen, wann Prognosen validiert werden müssen, bevor Maßnahmen ergriffen werden. - **Wenden Sie organisationsweite Standardeinstellungen (OWD) und Feldebenensicherheit (FLS) für Nichtdiskriminierung an.** Entwerfen Sie Datenzugriffsmuster mithilfe von OWD und FLS, um den Zugriff standardmäßig einzuschränken, und gewähren Sie nur den zusätzlichen Zugriff, den jede Rolle mithilfe von Freigaberegeln benötigt. Erteilen Sie Profilen keinen übermäßigen Zugriff, der sensible Attribute offenlegen und diskriminierende Entscheidungen ermöglichen kann. - **Aktivieren Sie die Benutzeragentur über die Plattformeinwilligung.** Verwenden Sie die Einwilligungsverwaltungsfunktionen in Data 360 oder benutzerdefinierte Einwilligungsobjekte mit dem Feld-Aktivierungsprotokoll, um die detaillierte AI-Einwilligung pro Anwendungsfall zu verfolgen. Ermöglichen Sie es Benutzern, sich von AI-gestützten Funktionen abzumelden und menschliche Alternativen bereitzustellen (sofern möglich). ## Datenqualität und Darstellungsgerechtigkeit Datenarchitekturentscheidungen bestimmen die Populationen, die in Salesforce-Systemen sichtbar und unsichtbar werden. Schlechte Datenqualität ist nicht nur ein technisches Problem. Wenn Datenlücken bestimmte demografische Gruppen systematisch benachteiligen, wird dies zu einem Fairnessproblem. ### Fehlende Daten führen zu unsichtbaren Populationen - **Überprüfen Sie Pflichtfelder auf Datenverfügbarkeit.** Wenn bei Pflichtfeldern die Informationsverfügbarkeit je nach demografischen Daten variiert, wird die Vollständigkeit der Daten diskriminierend. Benutzer, die die erforderlichen Informationen nicht bereitstellen können, werden in Systemen, die unvollständige Datensätze ablehnen, unsichtbar. * Durch die Anforderung von E-Mail-Adressen werden Populationen ausgeschlossen, die nicht über zuverlässigen Internetzugang oder persönliche E-Mail-Adressen verfügen. * Wenn US-amerikanische Sozialversicherungsnummern erforderlich sind, werden internationale Kunden und aktuelle Einwanderer ausgeschlossen, denen noch kein Stettiner Sozialversicherungsnummer ausgestellt wurde. * Durch die Anforderung von Straßenanschriften werden obdachlose Bevölkerungsgruppen und Benutzer mit nicht traditionellen Anschriften ausgeschlossen. - **Überprüfen Sie die geschäftlichen Begründungen für Pflichtfelder.** Für jedes Pflichtfeld müssen Sie dokumentieren, warum die Informationen obligatorisch und nicht optional sind. Wenn Prozesse ohne bestimmte Daten über alternative Ansätze funktionieren können, legen Sie diese Felder als optional fest und entwerfen Sie Systeme, um fehlende Werte ordnungsgemäß zu verarbeiten. Dadurch wird sichergestellt, dass Benutzer, die solche Daten nicht bereitstellen können, nicht ausgeschlossen werden. ### Name Feldarchitektur und kulturelle Verzerrung Namensfelder, die westlichen Benennungskonventionen folgen (Vorname, Nachname), können Kulturen mit unterschiedlichen Benennungspraktiken ausschließen. Viele Kulturen verwenden: - Einzelne Namen (oder Mononyme) ohne Familiennamen - Patronymische Systeme, bei denen sich "Nachname" generativ ändert - Mehrere Vornamen oder Familiennamen - Namen, die sich anhand von Lebensereignissen oder sozialem Kontext ändern - Namen, bei denen "Vorname" und "Nachname" kulturlos sind Entwerfen Sie Namensarchitekturen mit einem einzelnen vollständigen Namensfeld oder einer flexiblen, mehrteiligen Struktur, die allgemeine Benennungskonventionen berücksichtigt. Vermeiden Sie es, Annahmen über die Namensreihenfolge, Übernahmemuster oder kulturelle Normen zu treffen. Testen Sie die Namensarchitektur mit verschiedenen internationalen Namen, um sicherzustellen, dass Namensfelder Folgendes akzeptieren: - Einzelwortnamen (z. B. Sukarno, Cher und Teller) - Lange Namen, die allgemeine Obergrenzen für Feldlängen überschreiten - Namen mit Diakritika, Apostrophen, Bindestrichen und Leerzeichen - Namen mit nicht lateinischen Schriften (z. B. Arabisch, Chinesisch, Kyrillisch und Devanagari) Wenn die Namensvalidierung den legitimen Namen eines Benutzers ablehnt, wird er aufgrund seiner kulturellen Identität vom System abgelehnt. ### Adressdaten und geografische Verzerrung Adressvalidierungsservices sind oft für US-amerikanische und westeuropäische Formate optimiert und erkennen häufig Folgendes nicht: - Internationale Adressformate mit unterschiedlicher Feldreihenfolge - Ländliche Adressen ohne Straßennamen - Militärische Adressen (z. B. APO und FPO) - Postfächer und alternative Zustellungsstandorte - Stammländer mit eindeutigen Adresssystemen - Länder mit nicht-lateinischen Skripts für Adresskomponenten Wenn Adressvalidierungen nicht traditionelle Adressformate ablehnen, werden Accounterstellung, Versand und Servicebereitstellung für Benutzer verhindert, deren Adressen nicht den Erwartungen der Validierungsdatenbank entsprechen. Im Folgenden finden Sie einige Möglichkeiten, Adressvalidierungen unter Berücksichtigung des barrierefreien Zugriffs zu entwerfen: - Implementieren Sie die Validierung zulässiger Adressen. - Akzeptieren Sie die Eingabe von Freiformadressen, wenn strukturierte Validierungen fehlschlagen. - Speichern Sie Adressen so, wie sie von Benutzern eingegeben werden, statt Benutzer zu ungültigen Korrekturen zu zwingen. - Verwenden Sie die Adressvalidierung für die Datenanreicherung und die Duplikaterkennung, nicht zum Validieren der Adressformatierung. Statt Datenerfassungen im Voraus zu blockieren, sollten Sie die Adressüberprüfung in Abwicklungsprozesse integrieren, bei denen es operativ auf die Genauigkeit der Adresse ankommt. ### Kommunikationsmethoden-Verzerrung Universelle Zugriffsannahmen für bestimmte Kommunikationskanäle schließen Populationen mit unterschiedlichem Technologiezugriff oder unterschiedlichen Voreinstellungen aus. Nur-E-Mail-Kommunikation schließt Folgendes aus: - Benutzer ohne zuverlässigen Internetzugang - Ältere Bevölkerungsgruppen, die weniger komfortabel mit der Verwendung von E-Mails sind - Benutzer in Regionen, in denen SMS- oder Messaging-Anwendungen die primäre Kommunikationsmethode sind Bei der reinen Telefonkommunikation sind ausgeschlossen: - Gehörlose und schwerhörige Benutzer - Benutzer ohne Telefonzugriff oder Benutzer mit freigegebenen Telefonen Entwerfen Sie eine Omnikanal-Kommunikationsarchitektur, mit der Benutzer Kanalvoreinstellungen steuern können. Speichern Sie bevorzugte Kommunikationsmethoden in Kontaktdatensätzen und berücksichtigen Sie die Präferenzen in allen ausgehenden Kommunikationssystemen einheitlich. Stellen Sie eine Vielzahl von Kommunikationsalternativen bereit, statt davon auszugehen, dass Einzelkanalmethoden universell funktionieren. ### Demografische Daten und freiwillige Selbstidentifikation Die Erfassung demografischer Daten für die Fairnessüberwachung erfordert eine sorgfältige Architektur, um Missbrauch zu vermeiden. Das Sammeln und Verarbeiten von demografischen Daten ist gerichtsstandsabhängig und rechtlich eingeschränkt (in der EU werden sie gemäß [Artikel 9](https://gdpr-info.eu/art-9-gdpr/) der DSGVO als Daten spezieller Kategorien behandelt, die eine spezifische Rechtsgrundlage erfordern; in den USA basiert die Verzerrungsüberwachung in der Regel auf der freiwilligen Selbstidentifizierung von EEOs). Wenn eine Rechtsgrundlage besteht, verwenden Organisationen demografische Daten für folgende Zwecke: - Überwachen von Fairness-Kennzahlen, die nach geschützten Gruppen stratifiziert sind - Erkennen von Verzerrungen in Automatisierungs- und AI-Systemen - Nachweisen der Einhaltung gesetzlicher Vorschriften zur Bekämpfung von Diskriminierungen Die Erfassung demografischer Daten birgt bestimmte Risiken: - Daten können für diskriminierende Zwecke verwendet werden, wenn die Zugriffssteuerung fehlschlägt - Benutzer können Sammlungsmethoden misstrauen und ungenaue Daten angeben - Sammlung kann sich invasiver oder diskriminierender anfühlen Entwerfen Sie die freiwillige Selbstidentifikation und die demografische Datenerfassung anhand folgender Informationen: - Übersichtlich erklärt mit einem transparenten Zweck (z. B. Fairness-Monitoring oder Compliance-Bericht) - "Freiwillig" mit der Option "Nicht antworten" ist immer verfügbar - Getrennt von Betriebsdaten mit strenger FLS, um unangemessenen Zugriff zu verhindern - Aggregiert für Berichte und Analysen und nicht mit einzelnen Entscheidungen verknüpft - Überwacht über die Shield-Ereignisüberwachung für die Überprüfung von Zugriffsmustern Es ist wichtig, in Datenschutzerklärungen genau zu dokumentieren, wie demografische Daten verwendet werden und wie nicht. Die Verletzung des User Trust durch die Nutzung nicht offengelegter Daten kann die Glaubwürdigkeit erheblich beeinträchtigen, was sich als schwierig erweisen kann. ### Datenanreicherung und Drittanbieterverzerrung Die Anreicherung von Drittanbieterdaten, die demografische, firmografische oder verhaltensbasierte Daten an Salesforce-Datensätze anhängt, kann zu Verzerrungen führen durch: - Ungenaue Rückschlüsse, die auf Stereotypen basieren - Unvollständige Abdeckung mit Lücken, die mit demografischen Daten korrelieren - Proprietäre Algorithmen, die unbekannte Fairness-Eigenschaften verwenden - Daten, die aus verzerrten historischen Datensätzen stammen Bevor Sie Datenanreicherungsservices implementieren, sollten Sie Folgendes überprüfen: - Fairnesstests und Verzerrungsminderungspraktiken für Anbieter - Datenabdeckung und Genauigkeit über demografische Gruppen hinweg - Rückschlussmethoden und -funktionen, die zum Erstellen von Prognosen verwendet werden - Nutzungseinschränkungen und Aufbewahrungsrichtlinien für Vertragsdaten Beachten Sie, dass Drittanbieterdaten, die in Ihre Salesforce-Organisation gelangen, sich auf Entscheidungen auswirken können, wodurch vom Anbieter eingeführte Verzerrungen entstehen, die sich auch als Verzerrungen in Ihrer Organisation widerspiegeln. ## Barrierefreiheit mit Lightning und Experience Cloud In Salesforce-Kontexten bezieht sich der barrierefreie Zugriff auf die Erstellung von Lightning Web Components, Visualforce-Seiten und Experience Cloud-Sites, die für Benutzer mit Behinderungen geeignet sind. Standardmäßige Lightning-Komponenten bieten bei ordnungsgemäßer Verwendung grundlegenden barrierefreien Zugriff. Für die benutzerdefinierte Entwicklung und Experience Cloud-Konfiguration ist jedoch eine explizite Implementierung des barrierefreien Zugriffs erforderlich. ### Muster für den barrierefreien Zugriff auf Lightning Design-Systeme Lightning Design System-Komponenten unterstützen die WCAG 2.2 AA-Konformität, wenn sie bestimmungsgemäß verwendet werden. Salesforce ist bestrebt, die vollständige Konformität zu gewährleisten, zertifiziert sie jedoch nicht. Wenn Sie von SLDS Mustern abweichen oder benutzerdefinierte Komponenten ohne Berücksichtigung des barrierefreien Zugriffs erstellen, entstehen Barrieren für Benutzer mit Behinderungen. Standardmäßige Lightning Webkomponenten bieten integrierten Zugriff. Komponenten wie Lightning, Lightning-combobox, Lightning-datatable und Lightningcard enthalten automatisch die richtigen ARIA-Attribute, Bezeichnungszuordnungen, Tastaturnavigation und Fokusverwaltung. Verwenden Sie nach Möglichkeit Standardkomponenten, statt benutzerdefinierte Alternativen zu erstellen, die ähnlich aussehen, jedoch möglicherweise nicht über die entsprechende Infrastruktur für den barrierefreien Zugriff verfügen. - **Verwenden Sie semantischen HTML-Code in benutzerdefinierten Lightning Web Components.** Verwenden Sie beim Erstellen von benutzerdefinierten Komponenten semantische HTML-Elemente (
,