OSOS/Omega← Back

AI Data Policy

Produkt: OSOS / Omega

Anbieter: Osos AI GmbH, Cosimastraße 121, 81925 MĂŒnchen, Germany

Stand: 30.04.2026

Version: 1.0

VerhÀltnis zu anderen Dokumenten: Diese AI Data Policy ist Anlage zum EULA. Sie geht den allgemeinen Bestimmungen des EULA bei KI-spezifischen Fragestellungen vor, soweit sie speziellere Regelungen enthÀlt. Bei der Verarbeitung personenbezogener Daten gilt zusÀtzlich der Auftragsverarbeitungsvertrag (AVV).


1. Zweck und Geltungsbereich

OSOS / Omega ("Software") nutzt KI-Komponenten – insbesondere Large Language Models (LLM) und nachgelagerte Modellbestandteile – zur UnterstĂŒtzung von Engineering-Workflows (z.B. Anforderungs-Analyse, Generierung, Traceability, Review). Diese AI Data Policy beschreibt transparent,

  • welche Daten ("AI Inputs") in die KI-Komponenten eingehen,
  • welche KI-Subdienstleister und Modelle eingesetzt werden,
  • ob, wann und wie Daten zum Training oder zur Verbesserung von Modellen verwendet werden,
  • welche Schutzmechanismen, Kontrollen und Wahlmöglichkeiten der Lizenznehmer hat und
  • welche Pflichten zur menschlichen Aufsicht und Verifikation der KI-Outputs bestehen.

Diese Policy gilt fĂŒr alle Bereitstellungsmodelle (Cloud Software / Self-Hosted / Air-Gapped); modellspezifische Unterschiede sind im jeweiligen Abschnitt gekennzeichnet.


2. Definitionen

  • AI Input: Daten, Eingaben, Dokumente, Anforderungen, Code-Schnipsel, Metadaten oder Prompts, die durch den Lizenznehmer oder seine Authorized User in die KI-Komponenten der Software eingebracht werden.
  • AI Output: Vom KI-System generierte Inhalte, VorschlĂ€ge, Klassifikationen, Embeddings oder Zusammenfassungen.
  • Baseline Model: Vom Lizenzgeber oder einem KI-Subdienstleister bereitgestelltes, mehreren Kunden gemeinsam zugĂ€ngliches Foundation- bzw. Standardmodell.
  • Customer-Specific Model / Tenant-Specific Model: Ein fĂŒr einen einzelnen Lizenznehmer trainiertes oder fein-abgestimmtes Modell, das ausschließlich diesem Lizenznehmer zugeordnet bleibt.
  • No-Train-Modus: Verarbeitung mit aktivem technischem und vertraglichem Ausschluss der Verwendung von AI Inputs/Outputs zum Modelltraining.
  • Subprocessor / KI-Subdienstleister: Drittanbieter, der KI-Modell- oder Inferenz-Leistungen fĂŒr die Software bereitstellt (z.B. Hyperscaler-AI-Dienste, Modellhoster).

3. Grundprinzipien

3.1 Kein Training auf Customer Data

Customer Data, AI Inputs und AI Outputs des Lizenznehmers werden vom Lizenzgeber nicht zum Training, Fine-Tuning, Reinforcement Learning oder zur sonstigen Verbesserung von Baseline Models verwendet.

3.2 Mandantentrennung ("Data Isolation by Design")

Daten verschiedener Lizenznehmer werden logisch getrennt verarbeitet und gespeichert. AI Inputs eines Lizenznehmers fließen nicht in Antworten an andere Lizenznehmer ein. Embeddings, Vektorindizes und Caches sind mandantenspezifisch separiert.

3.3 BerĂŒcksichtigung interner Berechtigungen

Innerhalb eines Mandanten respektiert die KI-Komponente die im Lizenznehmersystem konfigurierten Zugriffs- und Berechtigungsrichtlinien. Authorized User erhalten keine KI-Outputs aus Projekten oder Dokumenten, auf die sie laut Berechtigungssystem keinen Zugriff haben.

3.4 Zweckbindung

AI Inputs werden ausschließlich verarbeitet, um den jeweils angefragten KI-Output zu generieren, die Software bereitzustellen, deren Sicherheit zu gewĂ€hrleisten sowie zur ErfĂŒllung gesetzlicher Pflichten.

3.5 Transparenz

Die Software kennzeichnet KI-generierte Inhalte und stellt – soweit technisch sinnvoll – Hinweise auf das verwendete Modell bzw. den Modelltyp bereit (Art. 50 EU AI Act).


4. KI-Komponenten und Subprocessor

4.1 Eingesetzte Modelle

Die Software setzt folgende Arten von Modellen ein:

  • vom Lizenzgeber bereitgestellte oder kuratierte Eigenmodelle (z.B. domĂ€nenspezifische Klassifikatoren, Embedding-Modelle);
  • Foundation Models von Drittanbietern (LLMs, Vision-Modelle), die ĂŒber API oder dedizierte Hosting-Umgebungen angesprochen werden;
  • optional: vom Lizenznehmer selbst bereitgestellte oder lizenzierte Modelle ("Bring-your-own-Model"), die in der Software konfiguriert werden.

4.2 KI-Subdienstleister

Die jeweils aktuelle Liste der KI-Subprocessor (inkl. Hosting-Standort, Modelltyp und Verarbeitungszweck) wird unter [Link Subprocessor-Liste] veröffentlicht. Die Liste wird zugleich als Anlage zum AVV gefĂŒhrt.

Bei Änderung der Liste gilt das Notifikations- und Widerspruchsverfahren gemĂ€ĂŸ AVV (in der Regel mindestens 30 Tage Vorlauf, Widerspruchsrecht bei wesentlichen Änderungen).

4.3 Wahl der Verarbeitungsregion

Soweit verfĂŒgbar, kann der Lizenznehmer die Verarbeitungsregion (z.B. EU, EU-only-Modus) im Order Form bzw. in den Plattformeinstellungen wĂ€hlen. Voreinstellung fĂŒr Kunden mit Hauptsitz im EWR ist die Verarbeitung in EU-Rechenzentren.

4.4 Air-Gapped / On-Premise

Bei Self-Hosted oder Air-Gapped Deployments lÀuft die Inferenz in der vom Lizenznehmer kontrollierten Umgebung; KI-Subdienstleister werden in diesem Fall nur nach gesonderter Vereinbarung eingebunden.


5. Verarbeitungszwecke und Datenkategorien

5.1 Verarbeitungszwecke

KI-Inputs werden ausschließlich verarbeitet zur

  • Erzeugung der vom Lizenznehmer angefragten KI-Outputs (Generierung, Klassifikation, Suche, Embeddings, Zusammenfassung);
  • Sicherstellung der FunktionsfĂ€higkeit, StabilitĂ€t und Sicherheit (z.B. Missbrauchserkennung, Rate Limiting);
  • Verbesserung der Plattform (nicht: der Modelle) auf Basis aggregierter und anonymisierter Telemetrie;
  • ErfĂŒllung gesetzlicher Pflichten.

5.2 Datenkategorien

Im KI-Verarbeitungspfad können insbesondere folgende Kategorien auftreten:

  • Anforderungstexte, Spezifikationen, Glossare, Policies des Lizenznehmers;
  • Code- und Dokumentationsausschnitte;
  • Metadaten (Projekt-ID, Modul, Status, Zeitstempel);
  • ggf. personenbezogene Daten (z.B. Autoren-/Bearbeiternamen, Kommentare). FĂŒr deren Verarbeitung gilt der AVV.

5.3 Besonders sensible Daten

Der Lizenznehmer wird besonders sensible Daten (Art. 9 DSGVO, klassifizierte Informationen, Zahlungsdaten, Gesundheitsdaten) ohne ausdrĂŒckliche vorherige Vereinbarung nicht in die KI-Komponenten einbringen. Werden solche Daten ohne Vereinbarung eingebracht, kann der Lizenzgeber die Annahme verweigern und/oder eingehende Inhalte automatisiert unterdrĂŒcken.


6. Aufbewahrung, Caching und Logging

6.1 Inferenz

AI Inputs werden zum Zweck der Inferenz an die jeweilige Modellumgebung ĂŒbermittelt. Bei Drittanbieter-LLMs wird – soweit verfĂŒgbar – die "Zero Data Retention"- bzw. "No-Train"-Variante der API genutzt. Bei diesen APIs erfolgt keine Speicherung der Inputs/Outputs durch den Drittanbieter ĂŒber die unmittelbare Inferenz hinaus, mit Ausnahme kurzfristiger Speicherung zu Sicherheitszwecken (typischerweise ≀ 30 Tage).

6.2 Plattform-seitiges Caching

Zur Performance-Optimierung kann die Software AI Inputs/Outputs mandantenspezifisch zwischenspeichern. Cache-Inhalte sind logisch isoliert und werden nach konfigurierbarer Frist gelöscht. Caches enthalten keine cross-tenant-zugÀnglichen Daten.

6.3 Logging

Es werden Log-Daten (Zeitstempel, Modell, Tokenzahlen, Status-Codes, Fehler) gespeichert. Inhaltliche AI Inputs/Outputs werden – soweit zur Diagnostik nicht erforderlich – nicht in Klartext geloggt; wo unvermeidlich, erfolgt Speicherung nur in einer mandantenspezifischen, zugriffsbeschrĂ€nkten Logging-Umgebung mit gesonderter Aufbewahrungsfrist (Standard: 30 Tage, sofern nicht anders vereinbart).

6.4 Telemetrie

Aggregierte, anonymisierte Telemetriedaten (z.B. Anzahl Anfragen, durchschnittliche Latenz) können zur Verbesserung der Plattform genutzt werden. Sie enthalten keine Customer Data und keine PersonenbezĂŒge.


7. Customer-Specific Customizations

7.1 Opt-in

Customer-Specific Models, Fine-Tunings, Retrieval-Indizes oder Ă€hnliche kundenspezifische Anpassungen werden nur auf ausdrĂŒckliche, dokumentierte Anweisung des Lizenznehmers ("Opt-in") und nur unter Verwendung explizit freigegebener Datenmengen erstellt.

7.2 Isolation

Customer-Specific Models bleiben mandantenspezifisch und werden nicht in Baseline Models zurĂŒckgefĂŒhrt. Es findet kein "Backflow" in andere Tenants statt.

7.3 Beendigung

Mit Ende des Subscription Term werden Customer-Specific Models nach Wahl des Lizenznehmers entweder ausgeliefert (sofern technisch und lizenzrechtlich möglich) oder unwiderruflich gelöscht; Standardvorgang ist die Löschung gemĂ€ĂŸ AVV.


8. Pflichten und Verantwortlichkeiten

8.1 Verantwortung des Lizenznehmers

Der Lizenznehmer ist verantwortlich fĂŒr

  • die RechtmĂ€ĂŸigkeit, Korrektheit und Eignung der von ihm in die KI-Komponenten eingebrachten Daten;
  • die Einholung erforderlicher Einwilligungen oder Rechtfertigungsgrundlagen fĂŒr betroffene Personen;
  • die abschließende inhaltliche PrĂŒfung, Verifikation und Freigabe aller KI-Outputs vor produktiver Verwendung;
  • die Konfiguration interner Zugriffsrechte und die Schulung seiner Authorized User im Umgang mit der Software.

8.2 Menschliche Aufsicht ("Human Oversight")

KI-Outputs sind VorschlĂ€ge, keine autoritativen Entscheidungen. Der Lizenznehmer stellt eine angemessene menschliche Aufsicht im Sinne von Art. 14 EU AI Act sicher und implementiert dokumentierte Review-Prozesse fĂŒr sicherheitsrelevante oder regulierte AnwendungsfĂ€lle.

8.3 Output-Disclaimer

Generative KI-Modelle können fehlerhafte, unvollstĂ€ndige, veraltete oder irrefĂŒhrende Inhalte erzeugen ("Halluzinationen"). Die Software ĂŒbernimmt keine GewĂ€hr fĂŒr Richtigkeit, VollstĂ€ndigkeit, AktualitĂ€t, Schutzrechtsfreiheit oder Eignung der KI-Outputs fĂŒr einen bestimmten Zweck.

8.4 Keine Umgehung von Schutzmechanismen

Der Lizenznehmer wird keine technischen oder organisatorischen Schutz- und Sicherheits-Mechanismen (insbesondere Safety- oder Compliance-Filter) umgehen, deaktivieren oder zu umgehen versuchen.

8.5 Keine Konkurrenzmodelle

Der Lizenznehmer wird KI-Outputs der Software nicht zum Training, Fine-Tuning oder zur Evaluierung konkurrierender KI-Modelle verwenden.


9. Sicherheit der KI-Komponenten

Der Lizenzgeber implementiert insbesondere folgende Maßnahmen:

  • VerschlĂŒsselung in transit (TLS 1.2+) und at rest (AES-256 oder gleichwertig);
  • Authentifizierung gegen KI-Subdienstleister mittels rotierender, gehĂ€rteter Credentials;
  • mandantenspezifische Trennung von Vector Stores, Caches und Logs;
  • Schutzmechanismen gegen Prompt-Injection-Angriffe (Eingabesanitierung, Output-Filterung, Allow-/Deny-Lists);
  • Monitoring auf Anomalien und missbrĂ€uchliche Nutzung;
  • regelmĂ€ĂŸige Penetrationstests und Red-Teaming der KI-Schnittstellen.

Detaillierte Informationen finden sich in den Zertifikats- und Sicherheits-Hinweisen sowie in der TOM-Anlage zum AVV.


10. EU AI Act, ISO 42001 und regulatorische Einordnung

10.1 Klassifikation

OSOS / Omega ist als KI-System nach Verordnung (EU) 2024/1689 (EU AI Act) einzuordnen. Nach derzeitiger EinschĂ€tzung handelt es sich beim Standard-Funktionsumfang nicht um ein "Hochrisiko-KI-System" im Sinne von Anhang III der Verordnung. Setzt der Lizenznehmer die Software in einem Anwendungsfall ein, der bei ihm als Hochrisiko-KI-System einzustufen ist, hat er den Lizenzgeber rechtzeitig zu informieren; der Lizenzgeber stellt in diesem Fall die zur ErfĂŒllung der Provider-/Betreiberpflichten (insbesondere Art. 11, 13, 14, 26 AI Act) erforderlichen Dokumentationen gegen VergĂŒtung bereit, soweit dies seinem Status als Anbieter im Sinne der Verordnung entspricht.

10.2 ISO 42001

Der Lizenzgeber strebt die KonformitÀt seiner KI-Managementprozesse mit ISO/IEC 42001 ("AI Management System") an bzw. hÀlt diese aufrecht. Der jeweils aktuelle Status wird in den Zertifikats-Hinweisen veröffentlicht.

10.3 Transparenz und Kennzeichnung

KI-generierte Inhalte werden als solche gekennzeichnet (Art. 50 EU AI Act). Bei Interaktion mit KI-Funktionen wird auf den KI-Charakter hingewiesen.

10.4 Bias, Diskriminierung und Fairness

Der Lizenzgeber unternimmt angemessene Anstrengungen, Bias und diskriminierende Effekte in den eingesetzten Modellen zu erkennen und zu mitigieren. Eine vollstÀndige Freiheit von Bias kann jedoch bei generativen Modellen nicht garantiert werden.


11. IP-Rechte an AI Output

Vorbehaltlich anderslautender gesetzlicher Bestimmungen und der Bedingungen des KI-Subprocessors stehen die AI Outputs dem Lizenznehmer zur freien Verwendung im Rahmen seines GeschĂ€ftsbetriebs zur VerfĂŒgung. Aufgrund der probabilistischen Natur generativer KI-Modelle kann eine ExklusivitĂ€t der Outputs jedoch nicht zugesichert werden; Ă€hnliche Outputs können auch anderen Nutzern angezeigt werden.

Der Lizenznehmer ist verpflichtet zu prĂŒfen, ob AI Outputs Rechte Dritter (insbesondere Urheber-, Marken-, Patent- und Persönlichkeitsrechte) verletzen, bevor er sie produktiv einsetzt.


12. Beschwerden, VorfÀlle, Kontakt

Der Lizenznehmer kann Anfragen, VorfÀlle und Beschwerden im Zusammenhang mit der KI-Verarbeitung an folgende Adresse richten:

  • E-Mail: [ai-policy@anbieter.com]
  • Postanschrift: [Anbieter GmbH, Anschrift]

Bei sicherheitsrelevanten VorfĂ€llen oder Datenschutzverletzungen gelten die Meldewege gemĂ€ĂŸ AVV (insbesondere unverzĂŒgliche Meldung im Rahmen der dortigen Fristen).


13. Änderungen dieser AI Data Policy

Diese Policy kann bei wesentlichen VerĂ€nderungen der eingesetzten Modelle, Subdienstleister oder regulatorischen Vorgaben angepasst werden. Wesentliche Änderungen werden mit angemessener Frist angekĂŒndigt. Im Übrigen gelten die Änderungsbestimmungen des EULA entsprechend.


14. VerhÀltnis zu anderen Dokumenten

Bei WidersprĂŒchen geht diese Policy fĂŒr KI-spezifische Sachverhalte den allgemeinen Bestimmungen des EULA vor; AVV-Bestimmungen fĂŒr personenbezogene Daten haben Vorrang vor dieser Policy.