OperativeOps und das BDSG
Das Bundesdatenschutzgesetz (BDSG) ergänzt die DSGVO um nationale Spezifika — insbesondere im Beschäftigtendatenschutz (§ 26), bei der DSB-Bestellpflicht (§ 38) und der Verarbeitung besonderer Kategorien personenbezogener Daten (§ 22). Diese Pflichten treffen Sie als Arbeitgeber und Betreiber. OperativeOps ist selbstbetriebene Software: Sie läuft auf Infrastruktur, die Sie kontrollieren, Beschäftigtendaten verlassen Ihre Umgebung nicht, und im Verarbeitungspfad steht kein Anbieter, den Ihr Datenschutzbeauftragter zusätzlich bewerten müsste. Diese Seite ist keine Rechtsberatung.
- OperativeOps gibt es ausschließlich im Selbstbetrieb — auf Ihren Servern, in Ihrem eigenen Cloud-Konto oder air-gapped. Es existiert kein gehostetes, betreutes oder SaaS-Angebot, also verlassen Beschäftigtendaten Ihre Umgebung nicht.
- § 26 BDSG: Beschäftigtendatenverarbeitung — besonders relevant für HR-nahe Agentenrollen. Zweckbindung, Erforderlichkeit und die Mitbestimmung des Betriebsrats nach § 87 Abs. 1 Nr. 6 BetrVG liegen bei Ihnen als Arbeitgeber.
- § 38 BDSG: DSB-Bestellpflicht ab 20 Personen, die ständig automatisiert personenbezogene Daten verarbeiten — die Pflicht trifft den Betreiber, also Sie.
- § 22 BDSG: Verarbeitung besonderer Kategorien personenbezogener Daten (Gesundheit, Gewerkschaftszugehörigkeit, Biometrie) — engerer Erlaubnistatbestand als die allgemeine DSGVO-Regelung.
- Da uns im Laufzeitbetrieb keine personenbezogenen Daten erreichen, ist ein Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO für die Bereitstellung selbst in der Regel nicht erforderlich. Diese Bewertung treffen Sie — ein Support-Fall, in dem Sie Logs oder Diagnosedaten übermitteln, ist eine eigenständige Frage.
- Richten Sie einen Agenten auf eine gehostete Modell-API (OpenAI, Anthropic), ist dieser Anbieter Ihr Auftragsverarbeiter, und Prompt-Inhalte verlassen Ihr Netz. Mit einem lokalen Modell über Ollama oder vLLM entfällt das vollständig.
- § 67 BDSG: Datenschutz im Strafverfolgungsbereich (JI-Richtlinie) — in der Regel nicht relevant für Standard-B2B-Bereitstellungen.
- Diese Seite ist keine Rechtsberatung. Sie beschreibt die Bereitstellungslage, damit Ihr DSB und Ihre Rechtsabteilung eigenverantwortlich entscheiden können.
Was das BDSG verlangt
Das Bundesdatenschutzgesetz (BDSG) ist das nationale Datenschutzgesetz Deutschlands und konkretisiert die Datenschutz-Grundverordnung (DSGVO) im deutschen Rechtskontext. Das BDSG macht von den Öffnungsklauseln der DSGVO Gebrauch und ergänzt den europäischen Rahmen um nationale Spezifika — insbesondere für Beschäftigte, für die Verarbeitung besonderer Datenkategorien, für die Bestellung von Datenschutzbeauftragten und für den Bereich Strafverfolgung und Justiz. Das BDSG schafft also kein eigenes, von der DSGVO unabhängiges Regime, sondern füllt die Spielräume, die das europäische Recht den Mitgliedstaaten gelassen hat.
§ 26 BDSG — Datenverarbeitung im Beschäftigungskontext: Diese Vorschrift regelt, unter welchen Voraussetzungen personenbezogene Daten von Beschäftigten verarbeitet werden dürfen. Die Verarbeitung ist zulässig, wenn sie zur Begründung, Durchführung oder Beendigung des Beschäftigungsverhältnisses erforderlich ist — etwa für Lohnabrechnung, Zeiterfassung oder Leistungsbeurteilung. Besonders relevant für den Einsatz von KI-Agenten im HR-Bereich: Der Zweck der Verarbeitung muss klar definiert und dokumentiert sein (Zweckbindungsgrundsatz), Betriebsräte haben Mitbestimmungsrechte nach § 87 Abs. 1 Nr. 6 BetrVG bei Einführung technischer Einrichtungen, die das Verhalten oder die Leistung der Beschäftigten überwachen können, und es gilt ein strengeres Einwilligungsregime, da Einwilligungen im Beschäftigungsverhältnis wegen des strukturellen Machtungleichgewichts nur unter engen Voraussetzungen als freiwillig gelten.
§ 38 BDSG — Pflicht zur Bestellung eines Datenschutzbeauftragten (DSB): In Deutschland gilt eine gesetzliche DSB-Bestellpflicht, wenn in der Regel mindestens 20 Personen ständig mit der automatisierten Verarbeitung personenbezogener Daten beschäftigt sind. Diese Schwelle kann bei Unternehmen, die KI-Agenten für administrative oder operative Prozesse einsetzen, schnell erreicht sein. Der DSB muss über ausreichend Fachwissen im Datenschutzrecht und in der Praxis des Datenschutzes verfügen; er kann intern oder extern bestellt werden. Beachten Sie: Die Pflicht trifft den Betreiber, also Sie. Bei einer selbstbetriebenen Bereitstellung gibt es keinen zweiten Beteiligten, dessen Angaben Ihr DSB einholen müsste — die Beschreibung der Verarbeitung entsteht aus Ihrer eigenen Konfiguration.
§ 22 BDSG — Verarbeitung besonderer Kategorien personenbezogener Daten: § 22 BDSG konkretisiert die in Art. 9 DSGVO geregelten besonderen Kategorien personenbezogener Daten für den deutschen Kontext. Dazu zählen unter anderem Daten zur Gesundheit, zur Gewerkschaftszugehörigkeit, zu ethnischer Herkunft, religiöser Überzeugung sowie biometrische Daten zur eindeutigen Identifizierung. Für die Verarbeitung dieser Daten gelten engere Erlaubnistatbestände: Sie ist nur zulässig, wenn einer der in § 22 BDSG aufgeführten Tatbestände erfüllt ist — etwa zur Ausübung von Rechten oder Erfüllung von Pflichten aus dem Arbeitsrecht, zum Schutz lebenswichtiger Interessen oder für Zwecke des Gesundheitswesens. Für Agentenrollen, die im Personalwesen oder im Gesundheitsbereich eingesetzt werden, ist diese Vorschrift besonders zu beachten.
§ 67 BDSG — Strafverfolgungsbereich und JI-Richtlinie: Teil 3 des BDSG (§§ 45 ff.) setzt die EU-Richtlinie für den Datenschutz bei Strafverfolgungsbehörden (Richtlinie (EU) 2016/680, sog. JI-Richtlinie) in nationales Recht um. Dieser Bereich ist für Standard-B2B-Bereitstellungen von OperativeOps in der Regel nicht einschlägig, da er ausschließlich für Stellen gilt, die für die Verhütung, Ermittlung, Aufdeckung oder Verfolgung von Straftaten oder die Strafvollstreckung zuständig sind. Ist Ihre Organisation in einem dieser Bereiche tätig, prüfen Sie mit Ihrer Rechtsabteilung, ob Teil 3 des BDSG auf Ihre Bereitstellung Anwendung findet.
BDSG-Anforderungen und die Kontrollen der Software
| BDSG-Anforderung | Unsere Kontrolle | Wo |
|---|---|---|
| § 26 BDSG — Beschäftigtendaten: Zweckbindung, Erforderlichkeit, Betriebsratsrechte | Agenten sind rollenbezogen abgegrenzt: Jeder Agent kann nur die Quellen lesen und die Tools aufrufen, die seine Berechtigungsgrenze zulässt — damit begrenzen Sie technisch, welche Beschäftigtendaten überhaupt in seinen Kontext gelangen. Jeder Zugriff, Tool-Aufruf und jede menschliche Freigabe landet im Append-only-Audit-Log in Ihrer eigenen Datenbank und ist mit Ihren vorhandenen Werkzeugen auswertbar. | self-hosted |
| § 38 BDSG — DSB-Bestellpflicht: ab 20 Personen, die ständig automatisiert Daten verarbeiten | Die Bestellpflicht trifft Sie als Betreiber. Das Material, das Ihr DSB dafür braucht, liegt in Ihrer eigenen Bereitstellung: Agentenrollen samt Berechtigungsgrenzen, angebundene Tools und Dokumentquellen, konfigurierte Aufbewahrungsfristen und das Modell-Backend jedes Agenten. Da im Laufzeitbetrieb kein Anbieter im Pfad steht, entfällt die sonst übliche Abfrage von Unterauftragnehmerlisten. | self-hosted |
| § 22 BDSG — Besondere Kategorien: Gesundheitsdaten, Gewerkschaftszugehörigkeit, biometrische Daten | Welche Retrieval-Quellen ein Agent lesen und welche Tools er aufrufen darf, wird pro Rolle festgelegt. Bestände mit besonderen Kategorien lassen sich damit außerhalb der Berechtigungsgrenze jeder Rolle halten, die sie nicht benötigt. Zugriffe auf freigegebene Quellen sind im Audit-Log nachvollziehbar; die Aufbewahrungsfrist konfigurieren Sie pro Workspace. | self-hosted |
| Mitbestimmungsrechte des Betriebsrats (§ 87 Abs. 1 Nr. 6 BetrVG) bei Einführung von KI-Tools | Den Beteiligungsprozess — Anhörung, Verhandlung, gegebenenfalls Betriebsvereinbarung — führen Sie mit Ihrem Betriebsrat. Die technische Grundlage dafür können Sie unmittelbar aus der Bereitstellung belegen: Agentendefinitionen, Berechtigungsgrenzen, protokollierte Ereignisarten, Freigabe-Gates und Aufbewahrungsfristen liegen als Ihre eigene, versionierte Konfiguration vor. Weitergehende Unterlagen werden auf Anfrage schriftlich vereinbart. | self-hosted |
| Auftragsverarbeitung (Art. 28 DSGVO) im Zusammenspiel mit dem BDSG | Die Software läuft vollständig auf Ihrer Infrastruktur und übermittelt uns keine laufenden personenbezogenen Daten; aus ihrem Betrieb entsteht daher in der Regel kein Auftragsverarbeitungsverhältnis. Jeder Dritte, den Sie anbinden — eine gehostete Modell-API, ein über MCP verbundenes SaaS-Tool — ist Ihr Auftragsverarbeiter, nicht unserer. Soll ein Support-Fall Diagnosedaten mit Personenbezug umfassen, regeln Sie das gesondert und vorab schriftlich. | self-hosted |
| Verschlüsselung, Schlüsselmanagement und Datenresidenz für Beschäftigtendaten | TLS zwischen den Komponenten bei der Übertragung. Die Verschlüsselung im Ruhezustand liefern die Speicherschicht und das Schlüsselmanagement, die Sie betreiben — Ihr KMS, Ihre Schlüssel, Ihre Rotationsrichtlinie. Der Speicherort ist schlicht der Ort Ihrer Bereitstellung; ausgehender Modellverkehr läuft über ein Egress-Gate, das Sie konfigurieren. | self-hosted |
| § 67 BDSG — Strafverfolgungsbereich (JI-Richtlinie) | In der Regel nicht anwendbar für Standard-B2B-Bereitstellungen. Fällt Ihre Organisation in den Anwendungsbereich von Teil 3 des BDSG, prüfen Sie die zusätzlichen Anforderungen an Protokollierung und Zweckbindung gegen Ihre Konfiguration; die abschließende Bewertung trifft Ihre Rechtsabteilung. | self-hosted |
Was der Selbstbetrieb für das BDSG ändert
OperativeOps existiert ausschließlich als Software, die Sie selbst betreiben — on-premises, in Ihrer eigenen Cloud-Umgebung oder air-gapped. Es gibt kein gehostetes Angebot und keinen betreuten Betrieb, also auch kein Szenario, in dem Beschäftigtendaten in fremder Infrastruktur liegen. Ihre Organisation ist alleiniger Verantwortlicher im Sinne des Art. 4 Nr. 7 DSGVO für alles, was die Bereitstellung verarbeitet, und zugleich Arbeitgeber im Sinne des § 26 BDSG. Für die Betriebsratsanhörung ist das eine deutlich einfachere Ausgangslage als ein SaaS-Einkauf: Es gibt keine Unterauftragsverarbeiter-Liste zu erklären, keinen fremden Anbieter, dessen Zugriffsmöglichkeiten diskutiert werden müssten, und kein fremdes Löschkonzept, das mit Ihrem abgeglichen werden müsste.
Die Folge für Art. 28 DSGVO verdient eine präzise Formulierung. Ein Auftragsverarbeitungsvertrag ist erforderlich, wenn eine Partei personenbezogene Daten in Ihrem Auftrag verarbeitet. In einer gewöhnlichen selbstbetriebenen Bereitstellung erreichen uns überhaupt keine personenbezogenen Daten; es gibt damit nichts, was ein solcher Vertrag regeln könnte, und er ist in der Regel nicht erforderlich. Diese Bewertung müssen Sie treffen, nicht wir — sie hängt von den Umständen Ihrer Bereitstellung ab. Buchen Sie Support und übermitteln dabei Diagnosepakete, Log-Auszüge oder Reproduktionsdaten mit Personenbezug, ist das eine eigenständige Verarbeitungstätigkeit und sollte gesondert vertraglich geregelt werden, bevor Sie etwas übermitteln.
Der Selbstbetrieb lässt die BDSG-Pflichten nicht verschwinden, er bündelt sie bei Ihnen. Die Rechtsgrundlage nach § 26 BDSG, eine etwaige Betriebsvereinbarung, die Datenschutz-Folgenabschätzung bei systematischer Verarbeitung von Beschäftigtendaten, die DSB-Bestellung nach § 38 BDSG und die Meldung von Datenschutzverletzungen nach Art. 33 und 34 DSGVO liegen sämtlich in Ihrer Hand — ebenso der Betrieb des Stacks mit Verschlüsselung, Schlüsselmanagement, Backups, Patching und Zugriffskontrolle. Ebenso liegt die Entscheidung über das Modell-Routing bei Ihnen: Ein Agent, der auf eine gehostete Modell-API zeigt, übermittelt Prompt-Inhalte — bei HR-Anwendungsfällen möglicherweise Beschäftigtendaten — an diesen Anbieter, der damit Ihr Auftragsverarbeiter wird. Zeigt derselbe Agent auf ein lokales Ollama- oder vLLM-Backend, bleibt der gesamte Inferenzpfad in Ihrem Netz.
Wofür Sie verantwortlich sind
- DSB-Bestellung gemäß § 38 BDSG, falls die Schwelle von 20 ständig mit automatisierter Datenverarbeitung beschäftigten Personen erreicht wird — oder freiwillig, wenn sektorale Anforderungen oder interne Governance dies nahelegen.
- Verzeichnis von Verarbeitungstätigkeiten gemäß Art. 30 DSGVO, ergänzt um die beschäftigtenbezogenen Verarbeitungen — das Material dafür stammt aus Ihrer eigenen Konfiguration: Agentenrollen, angebundene Tools, Dokumentquellen, Aufbewahrungsfristen und Modell-Backends.
- Mitbestimmung des Betriebsrats nach § 87 Abs. 1 Nr. 6 BetrVG bei der Einführung von KI-Tools, die Verhalten oder Leistung von Beschäftigten überwachen können — Anhörung, Verhandlung und gegebenenfalls Betriebsvereinbarung führen Sie.
- Datenschutz-Folgenabschätzung (DSFA) bei Hochrisiko-Verarbeitungen — insbesondere bei systematischer Überwachung von Beschäftigten, Verarbeitung besonderer Kategorien nach § 22 BDSG oder umfangreicher Profilbildung.
- Rechtsgrundlage für die Verarbeitung von Beschäftigtendaten nach § 26 BDSG definieren und dokumentieren — Zweck, Erforderlichkeit und gegebenenfalls eine Betriebsvereinbarung als Rechtsgrundlage.
- Betrieb der Bereitstellung — Verschlüsselung, Schlüsselmanagement, Backups, Patching, Zugriffskontrolle und Angriffserkennung. Hinter einer selbstbetriebenen Installation steht kein Betreiber außer Ihnen.
- Auswahl des Modell-Backends und Bewertung der Folgen: Eine gehostete Modell-API ist Empfängerin dessen, was Ihre Prompts enthalten; ein lokales Modell-Backend ist es nicht. Diese Wahl ist Konfiguration, und ihre datenschutzrechtlichen Folgen tragen Sie.
- Zuständige Aufsichtsbehörde identifizieren: Bei privatrechtlichen Unternehmen ist in der Regel die Landesdatenschutzbehörde des jeweiligen Bundeslandes zuständig; für Bundesbehörden und bestimmte Sektoren ist der Bundesbeauftragte für den Datenschutz und die Informationsfreiheit (BfDI) zuständig.
- Meldepflichten bei Datenschutzverletzungen nach Art. 33 DSGVO (72-Stunden-Frist gegenüber der Behörde) und Art. 34 DSGVO (Benachrichtigung betroffener Personen) wahrnehmen — der Audit-Ledger liegt in Ihrer Datenbank, die rechtliche Bewertung und die Meldung nehmen Sie vor.
- Qualifizierten Rechtsbeistand hinzuziehen. Diese Seite dokumentiert die technische Oberfläche; die rechtliche Bewertung treffen Sie.
Frequently asked questions
Wann brauche ich einen Datenschutzbeauftragten (DSB)?
In Deutschland gilt gemäß § 38 BDSG eine gesetzliche Pflicht zur DSB-Bestellung, wenn in der Regel mindestens 20 Personen ständig mit der automatisierten Verarbeitung personenbezogener Daten beschäftigt sind. Setzen Sie OperativeOps-Agenten im operativen Betrieb ein und arbeiten mehr als 20 Beschäftigte regelmäßig damit, ist diese Schwelle möglicherweise bereits erreicht. Darüber hinaus besteht in bestimmten Fällen eine Pflicht unabhängig von der Personenzahl — etwa bei umfangreichen Verarbeitungen besonderer Datenkategorien nach § 22 BDSG oder wenn eine Datenschutz-Folgenabschätzung vorgeschrieben ist. Wir leisten keine Rechtsberatung; Ihre Rechtsabteilung oder ein Datenschutzberater klärt, ob die Pflicht für Sie gilt.
Können wir OperativeOps in der HR-Abteilung einsetzen?
Technisch ja, und der Selbstbetrieb ist für diesen Anwendungsfall die einfachere Ausgangslage: Beschäftigtendaten bleiben in Ihrer eigenen Datenbank, und es gibt keinen Anbieter im Verarbeitungspfad, dessen Zugriffsmöglichkeiten Sie gegenüber Betriebsrat und DSB erklären müssten. Was die Software dafür bietet: rollenbezogen abgegrenzte Agenten, die nur die freigegebenen Quellen lesen und nur die freigegebenen Tools aufrufen können, Freigabe-Gates pro Aktion, ein Append-only-Audit-Log über jeden Zugriff und konfigurierbare Aufbewahrungsfristen. Was Sie sicherstellen müssen: die Rechtsgrundlage nach § 26 BDSG, die Beteiligung des Betriebsrats nach § 87 Abs. 1 Nr. 6 BetrVG, gegebenenfalls eine Betriebsvereinbarung und — bei systematischer Verarbeitung von Beschäftigtendaten — eine DSFA. Die rechtliche Gesamtverantwortung liegt bei Ihnen als Arbeitgeber.
Wie wird der Betriebsrat bei der Einführung von KI-Tools einbezogen?
Gemäß § 87 Abs. 1 Nr. 6 BetrVG hat der Betriebsrat ein Mitbestimmungsrecht bei der Einführung und Anwendung von technischen Einrichtungen, die dazu bestimmt oder objektiv geeignet sind, das Verhalten oder die Leistung der Arbeitnehmer zu überwachen. KI-Agenten, die Interaktionen von Beschäftigten protokollieren oder auswerten, können in diesen Anwendungsbereich fallen. Der Selbstbetrieb hilft dabei, weil sich die maßgeblichen Fragen aus Ihrer eigenen Bereitstellung beantworten lassen: Welche Agentenrollen es gibt, welche Quellen und Tools jeder Rolle zugestanden sind, welche Ereignisse protokolliert werden, welche Aktionen eine menschliche Freigabe verlangen und wie lange die Daten aufbewahrt werden — all das ist Ihre eigene, versionierte Konfiguration und muss nicht bei einem Anbieter erfragt werden. Den Beteiligungsprozess führen Sie mit Ihrem Betriebsrat; wir empfehlen, ihn früh im Einführungsprozess zu beginnen.
Welche Aufsichtsbehörde ist für mein Unternehmen zuständig?
Die Zuständigkeit richtet sich nach der Art Ihrer Organisation und Ihrem Hauptsitz: Privatrechtliche Unternehmen unterliegen der Aufsicht der Landesdatenschutzbehörde des Bundeslandes, in dem Ihr Unternehmen seinen Hauptsitz oder seine datenschutzrechtliche Hauptniederlassung hat — etwa der Landesbeauftragte für den Datenschutz und die Informationsfreiheit Baden-Württemberg (LfDI BW) oder der Bayerische Landesbeauftragte für den Datenschutz (BayLfD). Bundesbehörden und bundesweit tätige Telekommunikations- und Postunternehmen unterliegen der Aufsicht des Bundesbeauftragten für den Datenschutz und die Informationsfreiheit (BfDI). Bei grenzüberschreitenden Verarbeitungen innerhalb der EU kann die One-Stop-Shop-Regelung der DSGVO die Behörde Ihrer EU-Hauptniederlassung als federführende Aufsichtsbehörde bestimmen. Wir leisten keine Rechtsberatung; Ihr DSB identifiziert die zuständige Behörde für Ihre Situation.
Was unterscheidet das BDSG von der DSGVO?
Die DSGVO ist eine EU-Verordnung mit unmittelbarer Geltung in allen Mitgliedstaaten — sie schafft einen einheitlichen europäischen Datenschutzrahmen. Das BDSG ist das nationale Umsetzungsgesetz Deutschlands, das die von der DSGVO gewährten Öffnungsklauseln nutzt und den europäischen Rahmen um spezifisch deutsche Regelungen ergänzt: § 26 BDSG regelt den Beschäftigtendatenschutz detaillierter als die DSGVO. § 38 BDSG konkretisiert die DSB-Bestellpflicht mit einem zahlenmäßigen Schwellenwert (20 Personen), den die DSGVO selbst nicht vorsieht. § 22 BDSG konkretisiert die Erlaubnistatbestände für besondere Datenkategorien im deutschen Kontext. Teil 3 des BDSG setzt die JI-Richtlinie für Strafverfolgungsbehörden um, die nicht unter die DSGVO fällt. Kurz gefasst: Die DSGVO ist das Fundament, das BDSG die nationale Ergänzung.
Ist OperativeOps BDSG-konform?
Das BDSG ist ein nationales Gesetz, kein Zertifizierungsrahmen — eine 'BDSG-Konformitätsbescheinigung' gibt es nicht, und Konformität ist ohnehin eine Eigenschaft Ihrer Bereitstellung und Ihres Betriebs, nicht der Software allein. OperativeOps ist darauf ausgelegt, BDSG-konform betrieben zu werden: Es läuft auf Ihrer Infrastruktur, hält Beschäftigtendaten in Ihrer Umgebung, grenzt jede Agentenrolle über Berechtigungsgrenzen ab, verlangt für konfigurierte Aktionen eine menschliche Freigabe und schreibt ein Append-only-Audit-Log. Die Gesamtverantwortung — Rechtsgrundlage nach § 26 BDSG, DSB-Bestellung nach § 38 BDSG, Beteiligung des Betriebsrats — liegt bei Ihnen als Betreiber und Arbeitgeber. Die abschließende Bewertung treffen Ihr DSB und Ihre Rechtsabteilung.
Brauchen wir für die Verarbeitung von Beschäftigtendaten einen AVV mit Ihnen?
In einer gewöhnlichen selbstbetriebenen Bereitstellung gibt es in der Regel nichts, was ein Auftragsverarbeitungsvertrag regeln könnte, weil uns keine Beschäftigtendaten erreichen: Die Software läuft auf Ihrer Infrastruktur, und die Datenebene verlässt Ihre Grenze nicht. Ob das für Ihre Bereitstellung zutrifft, beurteilen Sie. Zwei Fälle sollten Sie gesondert betrachten. Erstens: Soll ein Support-Fall die Übermittlung von Diagnosedaten mit Personenbezug umfassen, behandeln Sie das als eigenständige Verarbeitungstätigkeit und vereinbaren Sie die Bedingungen schriftlich, bevor Sie etwas übermitteln. Zweitens: Jeder externe Dienst, den Sie anbinden — eine gehostete Modell-API oder ein SaaS-Tool über MCP —, ist Ihr Auftragsverarbeiter nach dem Vertrag, den Sie mit ihm ohnehin haben.
Wo liegen die Beschäftigtendaten, die die Agenten verarbeiten?
Dort, wo Sie sie ablegen. Dokumente, Embeddings, Gesprächsverläufe und Audit-Logs liegen in der Datenbank und dem Vektorspeicher, die Sie bereitstellen — in der Region und Jurisdiktion Ihrer Wahl, typischerweise in derselben Umgebung, in der Ihre Personalsysteme ohnehin laufen. In der Architektur gibt es keinen von OperativeOps betriebenen Speicher, also auch keine zweite Kopie, die Ihr DSB berücksichtigen müsste. Verlässt etwas Ihr Netz, dann nur, weil Sie einen Agenten ausdrücklich auf eine gehostete Modell-API oder ein externes Tool gerichtet haben — und dieser Egress läuft über ein Gate, das Sie konfigurieren.