Sicherheitsfragen für Unternehmen an Anbieter von Verhandlungsplattformen

Käufer, die die Sicherheit einer Verhandlungsplattform bewerten, sollten Anbieter auffordern nachzuweisen – und nicht nur zu behaupten –, wie sie Kundendaten isolieren, Aufbewahrung und Löschung steuern, Verschlüsselung anwenden, Berechtigungen einschränken und vertrauenswürdige Audit-Trails erzeugen. Diese Kontrollen sollten die vollständige Architektur der Negotiation platform abdecken, einschließlich Prompts, Anhängen, Embeddings, Backups, Support-Tools, Integrationen und Unterauftragsverarbeitern.

Für die Sicherheit von KI-Verhandlungen und den Datenschutz bei Verhandlungsplattformen ist ein Fragebogen nur der Anfang. Teams der Unternehmensbeschaffung benötigen Architekturdiagramme, Testergebnisse, Konfigurationsdemonstrationen, Beispiel-Logs, vertragliche Zusagen und eine verantwortliche menschliche Genehmigung des Restrisikos. Eine Zertifizierung kann die Prüfung unterstützen, sie kann jedoch produktspezifische Nachweise nicht ersetzen.

Kurze Antwort

Fragen Sie, wie der Anbieter jeden Mandanten trennt, was er speichert und löscht, wo Verschlüsselung angewendet wird, wer sensible Aktionen ausführen kann und welche Ereignisse Kunden auditieren können. Verlangen Sie Architekturdiagramme, Testergebnisse, Aufbewahrungspläne, Details zum Schlüsselmanagement, Berechtigungsmatrizen und Beispiel-Logs. Überführen Sie akzeptierte Antworten anschließend in vertragliche Verpflichtungen, wobei Sicherheits-, Datenschutz-, Rechts-, Beschaffungs- und Geschäftsverantwortliche Ausnahmen genehmigen.

Fünf Kontrollen, fünf Nachweisanforderungen

Verwenden Sie diese Zusammenfassung, um das erste Gespräch mit dem Anbieter zu strukturieren.

Das NIST Cybersecurity Framework 2.0 benennt Zugriffsautorisierung, Datenschutz und Log-Erzeugung als Cybersecurity-Ergebnisse. Es ist eine nützliche Grundlage, aber kein Nachweis dafür, dass ein bestimmter Anbieter diese Ergebnisse wirksam umgesetzt hat.

1. Isolation über die gesamte Architektur hinweg testen

Mandantenisolation bedeutet, zu verhindern, dass ein Kunde oder Workload auf einen anderen zugreift oder ihn beeinflusst. Ein Anbieter kann sagen, dass jeder Datenbankeintrag eine Kundenkennung hat, aber diese Antwort lässt Suchindizes, Caches, Analysen, Dateispeicher, Integrationen und KI-Dienste außer Acht.

Bitten Sie den Anbieter, jede Komponente zu benennen, in der Kundeninformationen gemeinsam vorkommen können:

• Anwendungsdienste und APIs
• Datenbanken, Replikate und Data Warehouses
• Objekt- und Anhangsspeicher
• Caches und Nachrichtenwarteschlangen
• Such- und Retrieval-Indizes
• Analyse- und Diagnosesysteme
• Prompts, Ausgaben, Embeddings und Evaluierungsdaten
• Entwicklungs-, Test-, Demonstrations- und Support-Umgebungen
• Modellanbieter und andere Unterauftragsverarbeiter

Fragen Sie dann, wie die Mandantenidentität für jede Objektanfrage und jeden API-Aufruf verifiziert wird. Wird die Isolation durch Infrastruktur, Konten, Schemata, Datenbankrichtlinien oder Anwendungscode erzwungen? Wo hat ein Programmierfehler das Potenzial, eine Grenze zu überschreiten?

NIST SP 800-53 Release 5.2.0 enthält Kontrollen zu Zugriff, gemeinsam genutzten Ressourcen und dem Schutz gespeicherter Informationen. Die begleitende Bewertungsveröffentlichung NIST SP 800-53A unterstützt ein wichtiges Beschaffungsprinzip: Verlangen Sie Nachweise dafür, dass eine Kontrolle implementiert ist und funktioniert, nicht nur eine Richtlinie, die besagt, dass sie existieren sollte.

Nachweisfragen zur Isolation

1. Deckt der Umfang des Penetrationstests ausdrücklich mandantenübergreifenden Zugriff ab?
2. Wurden API-, Such-, Export-, Cache- und Dateispeicherpfade getestet?
3. Werden Produktionsdaten jemals in Nicht-Produktionsumgebungen kopiert?
4. Wie erhalten Mitarbeiter des Anbieters temporären Zugriff auf die Produktion?
5. Wird der Zugriff genehmigt, zeitlich begrenzt, protokolliert und überprüft?
6. Sind KI-Prompts, Retrieval-Indizes, Ausgaben und Embeddings mandantenisoliert?
7. Hat der Anbieter eine bestätigte oder vermutete Offenlegung zwischen Kunden erlebt, und wie wurde damit umgegangen?

Ein allgemeines Schreiben zu einem Penetrationstest ist unzureichend, wenn das gekaufte Produkt, die Bereitstellungsregion, KI-Funktionen oder Mandantengrenzen nicht Teil des Testumfangs waren.

2. Aufbewahrung abbilden, bevor Löschung verhandelt wird

Der Datenschutz bei Verhandlungsplattformen hängt von mehr ab als von einem Versprechen, „Kundendaten bei Vertragsende zu löschen“. Eine Beschaffungsverhandlung kann Angebote, Lieferantenanhänge, interne Notizen, Genehmigungsverläufe, Prompts, Modellausgaben und geschäftlich sensible Metadaten erzeugen. Kopien können auch in Logs, Replikaten, Support-Tickets, Backups und Systemen von Unterauftragsverarbeitern vorhanden sein.

Erstellen Sie eine Aufbewahrungsmatrix, bevor Sie die vorgeschlagenen Bedingungen des Anbieters akzeptieren:

Übernehmen Sie keine universelle Aufbewahrungsfrist aus einer Checkliste. Angemessene Fristen hängen von Ermittlungsbedarfen, Streitfenstern, Unternehmensrichtlinien, rechtlichen Pflichten, Datensensibilität und den Rollen der Parteien ab.

Wo die Regeln der DSGVO für Auftragsverarbeiter gelten, müssen Verträge im Allgemeinen die Rückgabe oder Löschung personenbezogener Daten und die Unterstützung bei Audits regeln. Die Verordnung verankert außerdem das Prinzip der Speicherbegrenzung. Siehe den offiziellen GDPR text. Rechtsberater müssen bestimmen, ob und wie diese Regeln auf eine bestimmte Bereitstellung anwendbar sind.

Vertragsfragen zur Aufbewahrung

• Kann der Käufer die Aufbewahrung nach Datenklasse konfigurieren?
• Was löscht eine benutzerseitige Löschaktion tatsächlich?
• Wie schnell werden aktive Kopien, Caches und Replikate entfernt?
• Wann laufen unveränderliche Backups ab?
• Umfasst die Löschung auch abgeleitete Indizes und Embeddings?
• Welche Daten können aufgrund eines Legal Hold verbleiben?
• Wird der Anbieter vor Vertragsende Unterstützung beim Export leisten?
• Wer unterzeichnet die Löschbestätigung?
• Werden gleichwertige Anforderungen an Unterauftragsverarbeiter weitergegeben?

Die FTC’s vendor-security guidance empfiehlt, Erwartungen an Datennutzung, Aufbewahrung, Weitergabe und Löschung von Anbietern vertraglich festzulegen – und die Einhaltung zu prüfen, statt sich auf Zusicherungen zu verlassen.

3. Über einen Verschlüsselungsslogan hinausblicken

„Mit AES-256 verschlüsselt“ beantwortet nicht, wo Verschlüsselung angewendet wird, wer die Schlüssel kontrolliert oder was passiert, wenn die Anwendung Klartextdaten verwendet. Verschlüsselung kann Missbrauch durch eine autorisierte Anwendung, einen Administrator oder ein kompromittiertes Konto nicht verhindern.

Bitten Sie den Anbieter, jeden Datenzustand zu erläutern:

• Bei der Übertragung: Browser-Sitzungen, APIs, Integrationen, Verbindungen zu Modellanbietern, Support-Kanäle und Datenexporte
• Im Ruhezustand: Datenbanken, Anhänge, Logs, Replikate, Backups, Indizes und Embeddings
• Während der Nutzung: Suche, Analysen, Modellinferenz, Dokumentenverarbeitung und Generierung von Empfehlungen

Das Schlüsselmanagement sollte Erzeugung, Speicherung, Zugriff, Rotation, Widerruf, Backup und Vernichtung abdecken. Dieser Lebenszyklus spiegelt sich in der NIST definition of key management wider.

Fragen zu Verschlüsselung und Schlüsselmanagement

1. Welche Protokolle und Algorithmen schützen jede Speicherklasse und jeden Datenpfad?
2. Sind Schlüssel nach Kunde, Umgebung, Dienst oder Region getrennt?
3. Wer kann Schlüssel administrieren oder aufrufen?
4. Werden Schlüsseloperationen protokolliert und unterliegen sie dem Vier-Augen-Prinzip?
5. Kann der Käufer kundenseitig verwaltete Schlüssel verwenden, und welche Daten bleiben außerhalb dieser Kontrolle?
6. Macht ein Widerruf die betreffenden Daten unzugänglich?
7. Wie werden Schlüssel bei Vertragsende vernichtet?
8. Welche genauen kryptografischen Module sind unabhängig validiert?

Wenn ein Anbieter eine FIPS-Validierung behauptet, verlangen Sie die Zertifikatsnummer, Produktversion, das Modul und die Betriebsumgebung. FIPS 140-3 betrifft kryptografische Module; die bloße Verwendung eines zugelassenen Algorithmus belegt nicht, dass das bereitgestellte Produkt validiert ist.

4. Zugriff von Entscheidungsbefugnis trennen

Unternehmenssysteme für Verhandlungen benötigen mehr als grundlegende Administrator- und Benutzerrollen. Berechtigungen müssen möglicherweise nach Lieferant, Geschäftseinheit, Verhandlung, Feld und Aktion variieren.

Verlangen Sie eine Live-Demonstration von:

• SAML- oder OIDC-Single-Sign-on
• Erzwingbarer Multifaktor-Authentifizierung
• SCIM oder gleichwertiger Provisionierung und Deprovisionierung
• Default-Deny- und Least-Privilege-Rollen
• Benutzerdefinierten Rollen und granularen Scopes
• Einschränkungen für Exporte und Massen-Downloads
• Eigentümerschaft von Servicekonten und Token-Rotation
• Zeitlich begrenztem Support-Zugriff
• Regelmäßiger Zugriffsbestätigung
• Warnungen bei Rechteausweitung, Identitätsübernahme und Massenexport

Der wichtigste Test ist die Funktionstrennung. Ein Benutzer, der ein Angebot entwirft, sollte es nicht automatisch auch genehmigen und übermitteln können. Ebenso kann ein KI-Dienst eine Klausel empfehlen, ohne die Befugnis zu erhalten, das Unternehmen zu verpflichten.

CISAs secure-by-design guidance empfiehlt MFA für privilegierte Benutzer, standardbasiertes SSO und nützliche, für Kunden zugängliche Audit-Logs. Käufer sollten außerdem klären, ob diese Kontrollen in der wirtschaftlich tragfähigen Produktstufe enthalten sind, die in Betracht gezogen wird.

Für einen breiteren Blick darauf, wie Sicherheit in den operativen Workflow passt, lesen Sie AI negotiations und den zugehörigen Leitfaden zur data readiness for a Negotiation platform. Käufer, die sourcing-spezifische Workflows vergleichen, können auch procurement negotiation software prüfen.

5. Auditierbarkeit verlangen, nicht nur „Logging“

Logging ist die Erzeugung von Aufzeichnungen. Auditierbarkeit erfordert Aufzeichnungen, die ausreichend vollständig, zuverlässig, geschützt, aufbewahrt und zugänglich sind, um ein Ereignis zu rekonstruieren.

Fragen Sie, ob die Negotiation platform Folgendes aufzeichnet:

• Erfolgreiche und fehlgeschlagene Anmeldungen
• Änderungen an MFA, Benutzern, Rollen und Berechtigungen
• Support-Zugriff des Anbieters und Identitätsübernahme
• Anzeigen, Erstellen, Bearbeiten und Löschen von Datensätzen
• Angebots-, Gegenangebots- und Genehmigungsverlauf
• Uploads, Downloads, Freigaben und Massenexporte
• API- und Servicekonto-Aktivitäten
• Änderungen an Konfiguration und Aufbewahrungsrichtlinien
• KI-generierte Empfehlungen
• Menschliche Annahme, Bearbeitung oder Ablehnung von KI-Ausgaben
• Änderungen an Logging-Einstellungen

Jedes wesentliche Ereignis sollte identifizieren, wer oder was gehandelt hat, wann gehandelt wurde, welches Objekt betroffen war, welche Aktion stattgefunden hat und ob sie erfolgreich war. Fragen Sie nach abgestimmten Zeitstempeln, vorzugsweise UTC, sowie nach dokumentierten Schemata und automatisiertem SIEM-Export.

CISAs Cloud Security Technical Reference Architecture weist darauf hin, dass SaaS-Kunden durch die Logs eingeschränkt sein können, die ein Anbieter offenlegt. Sie bevorzugt automatisierte Log-Übertragung und hebt zentrale Protokollierung sowie Konsistenz von Zeitstempeln hervor.

Eine wiederverwendbare Checkliste für Sicherheits-Due-Diligence

Verwenden Sie die folgende Checkliste während einer Unternehmensverhandlung. Markieren Sie jeden Punkt als Verifiziert, Teilweise, Nicht verifiziert oder Nicht anwendbar. „Verifiziert“ sollte bedeuten, dass Nachweise geprüft wurden – nicht, dass der Anbieter Ja gesagt hat.

Architektur und Isolation

• Aktuelle Architektur- und Datenflussdiagramme bereitgestellt
• Jede gemeinsam genutzte Speicher- und Verarbeitungsschicht identifiziert
• Methode zur Mandantendurchsetzung für UI- und API-Anfragen erläutert
• Isolation von Suche, Cache, Anhängen, Analysen und Exporten getestet
• KI-Prompts, Ausgaben, Embeddings und Retrieval-Indizes isoliert
• Produktions- und Nicht-Produktionsumgebungen getrennt
• Privilegierter Support-Zugriff ist genehmigt, zeitlich begrenzt und protokolliert
• Mandantenübergreifende Tests erscheinen im aktuellen Bewertungsumfang

Datennutzung, Aufbewahrung und Löschung

• Vollständiges Dateninventar bereitgestellt
• Verarbeitungszweck für jede Datenkategorie dokumentiert
• Regeln für Sekundärnutzung und Modelltraining dokumentiert
• Aufbewahrungsfristen nach Datenklasse und Speicherschicht definiert
• Frist für Löschung aus aktiven Systemen definiert
• Ablauf von Replikaten, Caches und Backups definiert
• Umgang mit Legal Hold dokumentiert
• Löschpflichten von Unterauftragsverarbeitern bestätigt
• Export- und Löschbestätigung in den vorgeschlagenen Bedingungen enthalten

Verschlüsselung und Schlüssel

• Verschlüsselungsabdeckung für Übertragung, Ruhezustand, Backup und Verarbeitung abgebildet
• Protokolle und Algorithmen dokumentiert
• Eigentümerschaft der Schlüssel und Zugriffskontrollen erläutert
• Rotation, Widerruf, Backup und Vernichtung dokumentiert
• Schlüsseloperationen protokolliert
• Einschränkungen bei kundenseitig verwalteten Schlüsseln offengelegt
• Behauptete FIPS-Zertifikate stimmen mit dem bereitgestellten Modul und der Umgebung überein

Identität, Berechtigungen und Genehmigungen

• SSO und MFA demonstriert
• Automatisierte Provisionierung und sofortige Deprovisionierung getestet
• Rollen- und Berechtigungsmatrix bereitgestellt
• Zugriff kann auf Geschäftseinheit, Lieferant, Verhandlung und Aktion begrenzt werden
• Aufgaben für Erstellung, Änderung, Genehmigung und Übermittlung getrennt
• Kontrollen für Export, API-Token und Servicekonten demonstriert
• Privilegierter Zugriff wird regelmäßig überprüft
• KI kann ohne autorisierte menschliche Genehmigung keine verbindliche Verpflichtung erzeugen

Logging und Assurance

• Beispiel-Logs und Ereignisschema bereitgestellt
• Administrator-, Support-, API-, KI-, Export- und Genehmigungsereignisse werden erfasst
• Eindeutige Identitäten und verlässliche Zeitstempel vorhanden
• Logs sind vor gewöhnlicher administrativer Veränderung geschützt
• Automatisierter SIEM-Export demonstriert
• Log-Aufbewahrung entspricht den Anforderungen des Käufers
• Umfang unabhängiger Audits entspricht dem gekauften Dienst
• Penetrationstest-Feststellungen haben Verantwortliche und einen Behebungsstatus
• Verfahren für Incident Response und Kundenbenachrichtigung geprüft
• Nachweise zu Business Continuity und Recovery-Tests geprüft

Vertrag und Exit

• Akzeptierte Kontrollen in die Vereinbarung oder den Sicherheitsanhang aufgenommen
• Sicherheitsanhang hat Vorrang vor schwächeren Website-Richtlinien
• Verfahren für Benachrichtigung über Unterauftragsverarbeiter und Widerspruch vereinbart
• Wesentliche Reduzierungen von Kontrollen erfordern Benachrichtigung
• Zugang zu Nachweisen, Behebung und Audit-Rechte definiert
• Auslöser für Vorfälle und Benachrichtigungsfristen definiert
• Unterstützung bei Datenexport und Löschung definiert
• Benannter Risikoverantwortlicher des Käufers genehmigt jede Ausnahme

Nachweise in eine Entscheidungsdokumentation überführen

Eine praktische Scorecard sollte Unsicherheit bewahren, statt sie hinter einem einzigen Prozentsatz zu verbergen.

Mitteln Sie einen fehlgeschlagenen Pflichtkontrollpunkt nicht weg. Ein gut aufbereiteter Audit-Bericht kann eine ungetestete Mandantengrenze nicht kompensieren, und starke Verschlüsselung kann übermäßige Berechtigungen nicht ausgleichen.

Hypothetisches Beispiel: Bewertung eines KI-Verhandlungsworkflows

Hypothetisch – keine Aussage über einen bestimmten Anbieter: Ein Team der Unternehmensbeschaffung möchte eine Plattform, um Lieferantenvorschläge zu analysieren und Antwortoptionen vorzuschlagen. Die Datensätze enthalten Lieferantenpreise, interne Zielwerte, Anhänge und Benutzeridentitäten.

Während der Prüfung demonstriert der Anbieter mandantenbezogene Kontrollen auf Datenbankebene und SSO. Seine Nachweise zeigen jedoch nicht, ob Embeddings mandantengetrennt sind, Diagnosedaten eine definierte Löschfrist haben oder Support-Identitätsübernahme in Kunden-Logs erscheint.

Das Team sollte diese Unbekannten nicht in ein angenommenes Bestehen umwandeln. Es kann:

1. Die drei Punkte als nicht verifiziert einstufen.
2. Architekturdetails und gezielte Testnachweise anfordern.
3. Einen konfigurierten Workflow-Test mit Nicht-Produktionsdaten durchführen.
4. Verlangen, dass Support-Zugriff genehmigt, temporär und protokolliert ist.
5. Aufbewahrung von Diagnosedaten und Löschung von Embeddings in den Sicherheitsanhang aufnehmen.
6. Die Produktionsnutzung verhindern, bis der Sicherheitsverantwortliche die Nachweise genehmigt oder das Restrisiko formell akzeptiert.

Wenn Negotiations.AI für diesen Beschaffungsworkflow in Betracht gezogen würde, sollte es derselben nachweisbasierten Prüfung unterliegen. Markenbekanntheit oder Workflow-Relevanz würden die Pflicht des Käufers, die gekaufte Bereitstellung zu validieren, nicht aufheben.

Was ist verifiziert, angenommen, geschätzt und empfohlen?

Verifizierte Fakten

• NIST veröffentlichte CSF 2.0 am 26. Februar 2024, einschließlich Ergebnissen zu Autorisierung, Datenschutz und Logs.
• NIST veröffentlichte SP 800-53 und SP 800-53A Release 5.2.0 am 27. August 2025.
• FIPS 140-3 definiert Sicherheitsanforderungen für kryptografische Module.
• CISA empfiehlt sichere Standardeinstellungen, MFA für privilegierte Benutzer, standardbasiertes SSO und zugängliche, hochwertige Logs.
• Anwendbare DSGVO-Regelungen für Auftragsverarbeiter behandeln im Allgemeinen Löschung oder Rückgabe sowie Audit-Unterstützung.

Die verlinkten Primärquellen stützen diese Aussagen; keine davon beweist, dass ein bestimmter Anbieter sicher ist.

Annahmen

Dieses Framework geht von einer mandantenfähigen SaaS-Negotiation platform aus, die sensible geschäftliche und Identitätsdaten verarbeitet. Es geht außerdem davon aus, dass einige Bereitstellungen generative KI, Optimierung oder Empfehlungsdienste nutzen. Eine private, Single-Tenant- oder On-Premises-Bereitstellung kann einen anderen Nachweissatz erfordern.

Schätzungen

Aus den zitierten Standards lassen sich weder eine Eintrittswahrscheinlichkeit für Sicherheitsverletzungen noch ein universeller Sicherheitswert oder eine allgemein sichere Aufbewahrungsfrist berechnen. Wiederherstellungsziele, Aufbewahrungsfristen und Log-Dauern müssen auf Grundlage des Kontexts des Käufers festgelegt werden.

Empfehlungen

Behandeln Sie Isolation als Pflichtkontrolle; dokumentieren Sie Datenlebenszyklen; testen Sie Berechtigungsgrenzen; verlangen Sie exportierbare Logs; und verankern Sie akzeptierte Zusagen im Vertrag. Dies sind Empfehlungen, keine Feststellungen, die jede Organisation identisch umsetzen muss.

Wo verantwortliche menschliche Genehmigung weiterhin zwingend erforderlich ist

Die Sicherheit von KI-Verhandlungen ist eine Governance-Verantwortung, kein Ergebnis eines automatisierten Fragebogens. Verantwortliche Personen müssen entscheiden:

• Ob die Plattform privilegierte, regulierte, exportkontrollierte oder hochvertrauliche Informationen verarbeiten darf
• Ob Assurance-Berichte das gekaufte Produkt, die Funktionen, die Region und die Unterauftragsverarbeiter abdecken
• Welche Aufbewahrungsfristen und Legal-Hold-Ausnahmen akzeptabel sind
• Ob vom Anbieter verwaltete Schlüssel oder gemeinsam genutzte Infrastruktur ein tragbares Restrisiko schaffen
• Wer privilegierten und Notfall-Support-Zugriff genehmigen kann
• Ob eine Ausnahme von der Funktionstrennung gerechtfertigt ist
• Ob KI-Empfehlungen wesentliche Preise, Bedingungen, Vergaben oder Verpflichtungen informieren, aber niemals autorisieren dürfen
• Ob ein Vorfall eine Benachrichtigung von Geschäftsleitung, Kunden, Rechtsabteilung oder Aufsichtsbehörden erfordert
• Wer jede ungelöste vertragliche oder technische Ausnahme akzeptiert

Sicherheitswerkzeuge können Nachweise sammeln und Lücken kennzeichnen. Sie können die Risikoakzeptanz nicht übernehmen.

Grenzen dieses Frameworks

Diese Checkliste ist keine Zertifizierungsmethode. Externe Audits sind durch ihren Umfang und ihren Prüfzeitraum begrenzt. Penetrationstests liefern stichtagsbezogene Nachweise. Verschlüsselung verhindert keinen autorisierten Missbrauch oder kompromittierte Endpunkte. Logs sind nur dann nützlich, wenn wichtige Ereignisse erfasst und überprüft werden. Die Löschung aus aktivem Speicher bedeutet nicht die sofortige Vernichtung unveränderlicher Backups.

Anforderungen variieren außerdem je nach Rechtsraum, Branche, Datenkategorie, Hosting-Modell und Verhältnis zwischen Verantwortlichem und Auftragsverarbeiter. Hochregulierte oder nationale Sicherheitsumgebungen können Kontrollen erfordern, die über diesen Artikel hinausgehen. Umgekehrt können Fragen zur Mandantenisolation für eine tatsächlich dedizierte Installation weniger relevant sein, obwohl Umgebungs-, Administrator- und Netzwerkisolation weiterhin geprüft werden müssen.

FAQ

Reicht ein SOC-Bericht aus, um die Sicherheit einer Verhandlungsplattform zu genehmigen?

Nein. Er kann wertvolle unabhängige Assurance liefern, aber Käufer sollten Zeitraum, Umfang, Ausnahmen, Unterauftragsverarbeiter, Produktfunktionen und Bereitstellungsregionen des Berichts bestätigen. Produktspezifische Nachweise zu Architektur, Konfiguration und Tests bleiben notwendig.

Sollten Verhandlungsdaten zum Training eines KI-Modells verwendet werden?

Nur wenn die Nutzung ausdrücklich verstanden und autorisiert ist. Fragen Sie, ob Prompts, Anhänge, Ausgaben, Feedback oder abgeleitete Daten das Modelltraining oder die Produktverbesserung unterstützen. Verlangen Sie die Antwort in verbindlichen Bedingungen und holen Sie gegebenenfalls die Genehmigung von Datenschutz, Sicherheit, Recht und Fachbereich ein.

Was ist die wichtigste Sicherheitskontrolle für KI-Verhandlungen?

Es gibt keine universelle einzelne Kontrolle. Mandantenisolation ist in gemeinsam genutztem SaaS grundlegend, aber schwache Berechtigungen, unklare Aufbewahrung, unzugängliche Logs oder unkontrollierte Unterauftragsverarbeiter können jeweils unabhängig ein inakzeptables Risiko schaffen. Behandeln Sie Pflichtkontrollen als Gates und nicht als austauschbare Score-Komponenten.

Wie sollten Käufer mit einem Anbieter umgehen, der keine detaillierten Testergebnisse offenlegen kann?

Verlangen Sie alternative Nachweise: einen geschwärzten Executive Report, eine Bestätigung des Auditors, eine kontrollierte Einsicht, eine Live-Konfigurationsdemonstration oder vertraglich zugesagte Abhilfemaßnahmen. Dokumentieren Sie, was unbekannt bleibt. Ein verantwortlicher Risikoeigentümer des Käufers – nicht der Anbieter – muss entscheiden, ob diese verbleibende Unsicherheit akzeptabel ist.

Weiterführende Lektüre

• NIST Cybersecurity Framework 2.0
• NIST SP 800-53: Security and Privacy Controls
• CISA: Principles and Approaches for Security-by-Design and Default
• FTC Cybersecurity Vendor Guidance

Haftungsausschluss: Dieser Artikel bietet allgemeine Informationen zu Beschaffung und Sicherheit, keine Rechts-, Datenschutz-, Cybersecurity- oder Finanzberatung.