© 2026 OSOS/Omega. All rights reserved.

Omega version: 0.1.0

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.