KI-Integration und EU AI Act Compliance

# KI-Integration und EU AI Act Compliance - OTSM

**Dokument-Version**: 1.0

**Stand**: Februar 2026

**Verantwortlich**: Thomas [Nachname], Founder & Lead Developer

**Nächste Review**: August 2026

---

## 1. Executive Summary

OTSM (Operational Technology Systems Management) nutzt lokale KI-Modelle zur Unterstützung von Requirements Engineering, FMEA-Analyse und Compliance-Management. Alle KI-Funktionen arbeiten als **Assistenzsysteme** ohne autonome Entscheidungsbefugnis. Die finale Verantwortung für alle Engineering-Entscheidungen liegt ausschließlich beim menschlichen Nutzer.

**Risikoklassifizierung nach EU AI Act**: Minimal-Risiko-System mit Transparenzpflicht

**Rechtsgrundlage**: EU AI Act (Verordnung 2024/1689), anwendbar ab 02.08.2026

---

## 2. Zweck und Umfang der KI-Integration

### 2.1 Geschäftlicher Kontext

OTSM ist eine B2B-SaaS-Plattform für Requirements Engineering, Compliance Management und FMEA-Analyse, primär für die Automotive- und Fertigungsindustrie in Baden-Württemberg. KI-Funktionen dienen der Effizienzsteigerung und Qualitätsverbesserung, ersetzen jedoch keine menschliche Expertise.

### 2.2 Grundprinzipien der KI-Nutzung

1. **Human-in-the-Loop**: Alle KI-Outputs erfordern menschliche Validierung

2. **Transparenz**: KI-generierte Inhalte sind als solche gekennzeichnet

3. **Datenschutz**: Lokale Verarbeitung, keine Übermittlung an externe AI-Provider

4. **Kontrolle**: Nutzer können KI-Features deaktivieren

5. **Assistenz**: KI unterstützt, ersetzt keine Engineering-Entscheidungen

### 2.3 Keine autonomen Entscheidungen

OTSM nutzt KI **nicht** für:

- Autonome Safety-Entscheidungen

- Finale Compliance-Bewertungen ohne menschliche Validierung

- Automatische Freigaben von Requirements oder FMEA-Analysen

- Direkte Steuerung von Produktionssystemen oder kritischer Infrastruktur

---

## 3. Eingesetzte KI-Technologien

### 3.1 Technische Architektur

|------------|-------------|-------|---------|

**Hosting-Standort**: Deutschland (Nähe München)

**Datenverarbeitung**: Ausschließlich innerhalb Deutschlands/EU

**Externe AI-Provider**: Keine

### 3.2 Modell-Details

#### nomic-embed-text

- **Version**: v1.5 (via Ollama)

- **Typ**: Embedding-Modell (768 Dimensionen)

- **Lizenz**: Open Source (Apache 2.0)

- **Training**: Öffentliche Datensätze, keine kundenspezifischen Daten

- **Update-Strategie**: Kontrollierte Updates nach Validierung

#### llama3.2

- **Version**: 3B Parameter (via Ollama)

- **Typ**: Large Language Model

- **Lizenz**: Meta Llama 3.2 Community License

- **Training**: Öffentliche Datensätze, keine kundenspezifischen Daten

- **Update-Strategie**: Kontrollierte Updates nach Validierung

### 3.3 Keine externe API-Nutzung

OTSM nutzt **bewusst keine** externen AI-Provider wie:

- OpenAI (ChatGPT, GPT-4)

- Anthropic (Claude)

- Google (Gemini, PaLM)

- Microsoft (Azure OpenAI)

**Begründung**: Vollständige Datenkontrolle, GDPR-Compliance, keine Vendor-Lock-ins, volle Transparenz über Datenverarbeitung.

---

## 4. KI-Features und Funktionsbeschreibung

### 4.1 Semantische Suche

**Zweck**: Auffinden ähnlicher Requirements basierend auf semantischer Bedeutung

**Technische Umsetzung**:

- Requirements werden via nomic-embed-text in Vektoren transformiert

- Speicherung in PostgreSQL mit pgvector-Extension

- Similarity Search über Cosine-Similarity

**Nutzerinteraktion**:

- Nutzer gibt Suchbegriff ein

- System zeigt ähnliche Requirements sortiert nach Relevanz

- Nutzer entscheidet, welche Ergebnisse relevant sind

**Autonomie-Grad**: **Null** - Reine Anzeigefunktion, keine Aktionen

**Risikobewertung**: **Minimal** - Keine Entscheidungen, keine direkten Auswirkungen

**Transparenz-Maßnahmen**:

- UI zeigt "Semantische Suche" als Feature-Bezeichnung

- Similarity-Score wird angezeigt (0-100%)

- Nutzer kann klassische Textsuche alternativ verwenden

---

### 4.2 Duplikatserkennung

**Zweck**: Identifikation potenziell doppelter oder ähnlicher Requirements

**Technische Umsetzung**:

- Embedding-basierter Vergleich aller Requirements

- Threshold-basierte Erkennung (konfigurierbar, Standard: 85% Similarity)

- Gruppierung ähnlicher Requirements

**Nutzerinteraktion**:

- System schlägt potenzielle Duplikate vor

- Nutzer prüft Vorschläge manuell

- Nutzer entscheidet über Zusammenführung oder Beibehaltung

**Autonomie-Grad**: **Null** - Nur Vorschläge, keine automatischen Änderungen

**Risikobewertung**: **Minimal** - Keine automatischen Löschungen oder Änderungen

**Transparenz-Maßnahmen**:

- UI kennzeichnet "KI-Vorschlag: Mögliches Duplikat"

- Similarity-Score wird angezeigt

- Nutzer kann Vorschläge ignorieren

**Fehlerbehandlung**:

- False Positives: Nutzer ignoriert Vorschlag

- False Negatives: Nutzer kann manuelle Suche durchführen

- Keine negativen Auswirkungen bei KI-Fehlern

---

### 4.3 Compliance-Mapping (NIS2, ISO 27001, etc.)

**Zweck**: Vorschlag von Zuordnungen zwischen Requirements und Compliance-Anforderungen

**Technische Umsetzung**:

- LLM analysiert Requirement-Text

- Vergleich mit Compliance-Regelwerken (NIS2, ISO 27001, etc.)

- Generierung von Mapping-Vorschlägen mit Begründung

**Nutzerinteraktion**:

- System schlägt passende Compliance-Anforderungen vor

- Nutzer prüft Vorschlag und Begründung

- Nutzer akzeptiert, modifiziert oder verwirft Vorschlag

- Finale Zuordnung erfolgt durch Nutzer-Aktion (Klick)

**Autonomie-Grad**: **Null** - Keine automatischen Compliance-Zuordnungen

**Risikobewertung**: **Gering** - Nutzer validiert alle Zuordnungen vor Übernahme

**Transparenz-Maßnahmen**:

- UI kennzeichnet "KI-Vorschlag" mit Icon

- Begründung des Mappings wird angezeigt

- Nutzer sieht Original-Compliance-Text vor Übernahme

- Mapping-Historie zeigt manuelle vs. KI-vorgeschlagene Zuordnungen

**Fehlerbehandlung**:

- False Positives: Nutzer verwirft unpassende Vorschläge

- False Negatives: Nutzer kann manuelle Zuordnungen ergänzen

- Compliance-Audit basiert auf finalen (validierten) Zuordnungen, nicht KI-Vorschlägen

**Compliance-Relevanz**:

- Finale Compliance-Verantwortung liegt beim Nutzer/Unternehmen

- OTSM dokumentiert Mapping-Rationale zur Audit-Unterstützung

- KI-Feature beschleunigt Prozess, ersetzt keine Compliance-Expertise

---

### 4.4 FMEA Failure-Suggestions

**Zweck**: Vorschlag potenzieller Ausfallarten (Failure Modes) basierend auf Funktionsbeschreibung

**Technische Umsetzung**:

- LLM analysiert Function-Charakteristiken

- Generierung typischer Failure Modes für diese Funktionsklasse

- Vorschlag mit Severity/Occurrence-Schätzung

**Nutzerinteraktion**:

- System schlägt Failure Modes vor

- FMEA-Experte prüft Plausibilität

- Experte übernimmt, modifiziert oder verwirft Vorschläge

- Finale Risikobewertung erfolgt durch FMEA-Team

**Autonomie-Grad**: **Null** - Keine automatischen FMEA-Einträge oder Risikobewertungen

**Risikobewertung**: **Gering-bis-Mittel**

- Fehlende Failure Modes können zu Sicherheitsrisiken führen

- **Mitigation**: OTSM ersetzt keine vollständige FMEA-Methodik

- **Mitigation**: Nutzer sind geschulte FMEA-Experten

- **Mitigation**: KI ergänzt, ersetzt nicht die Expertise

**Transparenz-Maßnahmen**:

- UI kennzeichnet "KI-generierter Vorschlag"

- Vorschläge sind deutlich von manuell erstellten Failure Modes getrennt

- FMEA-Report kennzeichnet Herkunft (manuell/KI-unterstützt)

**Safety-Considerations**:

- KI-Vorschläge dürfen NIEMALS als vollständige FMEA betrachtet werden

- Systematische FMEA-Methodik (z.B. nach AIAG-VDA) muss eingehalten werden

- Finale Safety-Bewertung erfordert menschliches Expertenwissen

- OTSM dokumentiert, dass KI-Features Hilfswerkzeuge sind

**Validation-Anforderungen**:

- FMEA-Team muss alle Vorschläge kritisch prüfen

- Vollständigkeit-Check unabhängig von KI-Vorschlägen

- Risikobewertung (RPN) erfolgt ausschließlich durch Menschen

---

### 4.5 Requirements-Konvertierung (SOPHISTEN-Syntax)

**Zweck**: Umwandlung natürlichsprachiger Requirements in strukturierte SOPHISTEN-Syntax

**Technische Umsetzung**:

- LLM analysiert Requirement-Text

- Identifikation von Aktoren, Prozesswörtern, Objekten

- Generierung SOPHISTEN-konformer Formulierung

**Nutzerinteraktion**:

- Nutzer gibt unstrukturiertes Requirement ein

- System schlägt SOPHISTEN-Formulierung vor

- Nutzer prüft und editiert Vorschlag

- Finale Formulierung wird durch Nutzer gespeichert

**Autonomie-Grad**: **Null** - Keine automatische Übernahme

**Risikobewertung**: **Minimal** - Syntaktische Hilfe, keine inhaltliche Änderung

**Transparenz-Maßnahmen**:

- Original-Text bleibt sichtbar

- Änderungen sind nachvollziehbar (Diff-View)

- Nutzer kann Konvertierung ablehnen

**Qualitätssicherung**:

- Automatische Validierung gegen SOPHISTEN-Regeln

- Warnungen bei unklaren Formulierungen

- Finale Qualitätsprüfung durch Requirements Engineer

---

## 5. Risikobewertung nach EU AI Act

### 5.1 Klassifizierung

**OTSM KI-Funktionen sind KEINE Hochrisiko-KI-Systeme gemäß Artikel 6 EU AI Act, weil**:

1. **Keine kritische Infrastruktur**: OTSM verwaltet keine kritische Infrastruktur direkt

2. **Keine Sicherheitskomponente**: KI ist nicht Teil von Safety-kritischen Produkten

3. **Keine autonomen Entscheidungen**: Alle Outputs erfordern menschliche Validierung

4. **Assistenz-Charakter**: KI unterstützt Experten, ersetzt sie nicht

**Einstufung**: **Minimal-Risiko-System mit Transparenzpflicht** (Artikel 50 EU AI Act)

### 5.2 Begründung der Nicht-Hochrisiko-Einstufung

| Hochrisiko-Kriterium (Art. 6) | OTSM-Situation | Erfüllt? |

|--------------------------------|----------------|----------|

| Sicherheitskomponente in Produkten | KI ist Teil eines Entwicklungstools, nicht des Endprodukts | ❌ Nein |

| Management kritischer Infrastruktur | Dokumentation, keine Steuerung | ❌ Nein |

| Biometrische Identifikation | Nicht vorhanden | ❌ Nein |

| Kritische Infrastruktur (Energie, Wasser, etc.) | B2B-Software für Engineering | ❌ Nein |

| Bildung/Berufliche Bildung | Produktivsystem, kein Bildungssystem | ❌ Nein |

| Beschäftigung/HR | Requirements Engineering Tool | ❌ Nein |

| Zugang zu Dienstleistungen | Internes Engineering-Tool | ❌ Nein |

| Strafverfolgung | Keine Anwendung | ❌ Nein |

| Migration/Asyl | Keine Anwendung | ❌ Nein |

| Rechtspflege | Keine Anwendung | ❌ Nein |

### 5.3 Restrisiken und Mitigation

#### Risiko 1: Unvollständige FMEA durch Übervertrauen in KI

**Wahrscheinlichkeit**: Gering

**Impact**: Mittel-Hoch (potenzielle Safety-Lücken)

**Mitigation**:

- UI-Warnhinweise: "KI-Vorschläge ersetzen keine vollständige FMEA"

- Dokumentation betont Hilfswerkzeug-Charakter

- Schulungsunterlagen für Nutzer

- FMEA-Vollständigkeits-Checklisten unabhängig von KI

#### Risiko 2: Fehlerhafte Compliance-Zuordnungen

**Wahrscheinlichkeit**: Mittel

**Impact**: Mittel (Compliance-Lücken, Audit-Probleme)

**Mitigation**:

- Alle Mappings erfordern explizite Nutzer-Bestätigung

- Compliance-Reports kennzeichnen Validierungsstatus

- Regelmäßige Compliance-Reviews empfohlen

- KI-Confidence-Score wird angezeigt

#### Risiko 3: Datenschutzverletzung durch KI

**Wahrscheinlichkeit**: Sehr gering

**Impact**: Hoch (GDPR-Verstöße)

**Mitigation**:

- Lokales Hosting, keine externen AI-Provider

- Keine Übermittlung von Kundendaten an Dritte

- Ollama-Modelle laufen vollständig offline

- Multi-Tenant-Isolation in der Datenbank

#### Risiko 4: Bias in KI-Vorschlägen

**Wahrscheinlichkeit**: Mittel

**Impact**: Gering (ineffiziente Vorschläge)

**Mitigation**:

- Nutzer können alle Vorschläge ablehnen

- Keine automatische Übernahme

- Feedback-Loop für Verbesserung geplant (Phase 2)

### 5.4 Risiko-Matrix

|---------|-----------|--------|-------------|-------------|---------------|

**Gesamt-Risikobewertung**: **MINIMAL bis GERING**

---

## 6. Compliance-Maßnahmen

### 6.1 Transparenzpflichten (Artikel 50 EU AI Act)

✅ **Erfüllt durch**:

- KI-generierte Inhalte sind in der UI deutlich gekennzeichnet

- Nutzer werden über KI-Nutzung informiert (Onboarding, Dokumentation)

- Diese Compliance-Dokumentation ist für Kunden verfügbar

- Terms of Service erwähnen KI-Features explizit

### 6.2 Technische Dokumentation

✅ **Vorhanden**:

- Modell-Spezifikationen (siehe Abschnitt 3)

- Feature-Beschreibungen (siehe Abschnitt 4)

- Risikobewertung (siehe Abschnitt 5)

- Datenfluss-Diagramme (siehe Abschnitt 7)

### 6.3 Menschliche Aufsicht (Human Oversight)

✅ **Implementiert**:

- **Alle** KI-Outputs erfordern menschliche Aktion zur Übernahme

- Keine automatischen Entscheidungen oder Änderungen

- Nutzer können KI-Features deaktivieren

- Opt-Out-Mechanismus in den Settings

### 6.4 Genauigkeit und Robustheit

✅ **Maßnahmen**:

- Versionskontrolle der Ollama-Modelle

- Kontrollierte Updates (Test-Umgebung → Produktion)

- Monitoring der KI-Performance (geplant: Feedback-Loop)

- Fallback auf manuelle Prozesse bei KI-Ausfall

### 6.5 Cybersecurity

✅ **Maßnahmen**:

- Ollama läuft in isolierter Umgebung

- Keine Internetverbindung für KI-Modelle erforderlich

- Reguläre Security-Updates des Host-Systems

- Multi-Tenant-Isolation verhindert Cross-Tenant-Zugriffe

### 6.6 Datenqualität und Datenverwaltung

✅ **Maßnahmen**:

- Embeddings werden aus finalen (validierten) Requirements generiert

- Keine KI-Training auf Produktionsdaten

- Klare Trennung zwischen Trainings- und Produktionsdaten

- Nutzer-Daten werden nicht für Modell-Verbesserung verwendet (keine Telemetrie)

---

## 7. Datenfluss und Verarbeitung

### 7.1 Datenfluss-Diagramm

```

[Nutzer-Input (Browser)]

↓

[OTSM Frontend (React)]

↓

[OTSM Backend (Node.js/Fastify)]

↓

[Ollama Service (lokal)]

↓ ↓

[nomic-embed] [llama3.2]

↓ ↓

[PostgreSQL + pgvector]

↓

[OTSM Backend (Ergebnis)]

↓

[OTSM Frontend (Anzeige)]

↓

[Nutzer-Validierung]

```

**Kritischer Punkt**: Keine Daten verlassen das lokale System. Keine API-Calls an externe AI-Provider.

### 7.2 Datenarten und Verarbeitung

|-----------|----------|-----------------|-------------|-----------|

### 7.3 Keine Übermittlung sensibler Daten

**OTSM überträgt KEINE Daten an**:

- Externe AI-Provider (OpenAI, Anthropic, etc.)

- Cloud-basierte ML-Services

- Drittanbieter-Analytics

- Telemetrie-Services (kein Sentry für KI-Logs)

**Begründung**: Automotive Requirements können geistiges Eigentum, Geschäftsgeheimnisse oder sicherheitskritische Informationen enthalten.

---

## 8. Nutzer-Information und Transparenz

### 8.1 Onboarding und Dokumentation

**Neue Nutzer werden informiert durch**:

1. **Onboarding-Tour**: Einführung in KI-Features mit Hinweis auf Validierungspflicht

2. **Feature-Tooltips**: UI zeigt "KI-unterstützt" mit Info-Icon

3. **Hilfe-Dokumentation**: Detaillierte Beschreibung aller KI-Features

4. **Video-Tutorials**: Demonstration der KI-Nutzung mit Best Practices

### 8.2 UI-Kennzeichnungen

**Alle KI-generierten Inhalte tragen folgende Kennzeichnungen**:

- **Icon**: 🤖 oder "AI" Badge

- **Tooltip**: "Dieser Vorschlag wurde KI-gestützt generiert und erfordert Ihre Validierung"

- **Farb-Codierung**: KI-Vorschläge haben hellen Hintergrund (z.B. hellblau)

- **Differenzierung**: Klare visuelle Trennung zwischen manuellen und KI-Inhalten

**Beispiel (Compliance-Mapping)**:

```

┌─────────────────────────────────────────┐

│ 🤖 KI-Vorschlag: NIS2-Mapping │

│ ──────────────────────────────────── │

│ Empfohlene Zuordnung: │

│ NIS2 Art. 21 (2) - Risikoanalyse │

│ │

│ Begründung: Das Requirement beschreibt │

│ Risikobewertung für kritische Systeme │

│ │

│ [✓ Übernehmen] [✗ Ablehnen] [✎ Anpassen]│

└─────────────────────────────────────────┘

```

### 8.3 Opt-Out Mechanismus

**Nutzer können KI-Features deaktivieren**:

- **Global**: Alle KI-Features in Settings deaktivieren

- **Feature-spezifisch**: Einzelne Features (z.B. nur FMEA-Suggestions) deaktivieren

- **Temporär**: "Nicht mehr vorschlagen" für spezifische Vorschläge

**Auswirkung bei Deaktivierung**:

- System funktioniert vollständig ohne KI

- Keine Einschränkungen bei Kern-Funktionalitäten

- Manuelle Prozesse bleiben verfügbar

---

## 9. Kundeninformation (Extern)

### 9.1 Website / Produktbeschreibung

**Empfohlene Formulierung für Marketing-Materialien**:

> **KI-gestützte Effizienz mit voller Kontrolle**

> OTSM nutzt lokal gehostete KI-Modelle (Ollama), um Ihre Requirements Engineering Prozesse zu beschleunigen. Alle KI-Vorschläge sind transparent gekennzeichnet und erfordern Ihre explizite Validierung. Ihre Daten bleiben in Deutschland und werden niemals an externe AI-Provider übermittelt.

> - ✅ Semantische Suche in Requirements

> - ✅ Intelligente Duplikatserkennung

> - ✅ Compliance-Mapping-Vorschläge

> - ✅ FMEA Failure-Suggestions

> - ✅ EU AI Act konform

> - ✅ 100% Datenkontrolle - keine externen AI-APIs

### 9.2 Terms of Service / Nutzungsbedingungen

**Empfohlener Abschnitt für ToS**:

> **§X - KI-gestützte Funktionen**

> (1) OTSM nutzt lokal gehostete KI-Modelle (Ollama mit nomic-embed-text und llama3.2) zur Unterstützung folgender Funktionen:

> - Semantische Suche in Requirements

> - Duplikatserkennung

> - Vorschläge für Compliance-Zuordnungen (NIS2, ISO 27001, etc.)

> - Vorschläge für FMEA Failure Modes

> - Konvertierung in SOPHISTEN-Syntax

> (2) Alle KI-Vorschläge sind als solche gekennzeichnet und erfordern die explizite Validierung durch den Nutzer. Die finale Verantwortung für alle Engineering-Entscheidungen, Compliance-Zuordnungen und Risikobewertungen liegt beim Nutzer bzw. dessen Organisation.

> (3) Die KI-Modelle werden ausschließlich auf Servern in Deutschland betrieben. Es erfolgt keine Übermittlung von Nutzer-Daten an externe AI-Provider (wie OpenAI, Anthropic, Google, etc.).

> (4) Nutzer können KI-Features jederzeit in den Einstellungen deaktivieren. Die Kern-Funktionalitäten von OTSM bleiben auch ohne KI-Unterstützung vollständig verfügbar.

> (5) OTSM erfüllt die Transparenzpflichten nach Artikel 50 der EU AI Act Verordnung (2024/1689). Details zur KI-Nutzung und Compliance finden sich in der technischen Dokumentation (auf Anfrage verfügbar).

### 9.3 FAQ für Kunden

**Empfohlene FAQ-Einträge**:

**Q: Welche KI-Technologie nutzt OTSM?**

A: OTSM nutzt Ollama mit den Open-Source-Modellen nomic-embed-text (für semantische Suche) und llama3.2 (für Text-Generierung). Diese Modelle laufen vollständig auf unseren Servern in Deutschland, ohne externe API-Calls.

**Q: Werden meine Daten an OpenAI, ChatGPT oder andere AI-Provider übermittelt?**

A: Nein, niemals. Alle KI-Verarbeitung erfolgt lokal auf unseren Servern in Deutschland. Ihre Requirements, FMEA-Daten und Compliance-Informationen verlassen unser System nicht.

**Q: Ist OTSM konform mit der EU KI-Verordnung?**

A: Ja. OTSM ist als Minimal-Risiko-System eingestuft, da alle KI-Features als Assistenzsysteme ohne autonome Entscheidungsbefugnis konzipiert sind. Wir erfüllen alle Transparenzpflichten nach Artikel 50 EU AI Act.

**Q: Kann ich die KI-Features deaktivieren?**

A: Ja, Sie können KI-Features global oder einzeln in den Einstellungen deaktivieren. OTSM funktioniert vollständig ohne KI-Unterstützung.

**Q: Wer ist verantwortlich für Engineering-Entscheidungen?**

A: Sie bzw. Ihre Organisation. Alle KI-Vorschläge erfordern Ihre explizite Validierung und Freigabe. OTSM unterstützt Ihre Experten, ersetzt sie nicht.

**Q: Kann die KI falsche Vorschläge machen?**

A: Ja, wie jedes Assistenzsystem kann auch unsere KI unpassende oder unvollständige Vorschläge generieren. Deshalb ist die menschliche Validierung durch Ihre Experten zwingend erforderlich und technisch erzwungen.

---

## 10. Interne Prozesse und Governance

### 10.1 Verantwortlichkeiten

| Rolle | Verantwortung | Person |

|-------|---------------|--------|

| **Product Owner** | Strategische KI-Integration | Thomas [Nachname] |

| **Technical Lead** | KI-Implementierung, Modell-Updates | Thomas [Nachname] |

| **Compliance Officer** | EU AI Act Monitoring, Dokumentation | [zukünftig zu besetzen] |

| **Quality Manager** | Testing, Validierung | [zukünftig zu besetzen] |

**Hinweis**: Bei aktueller Team-Größe (1 Person) liegt alle Verantwortung beim Founder. Bei Team-Wachstum sind obige Rollen zu besetzen.

### 10.2 Review-Zyklus

**Dieses Dokument wird überprüft**:

- **Halbjährlich** (Februar & August)

- **Nach Modell-Updates** (neue Ollama-Version)

- **Nach EU AI Act Änderungen** (Gesetzesanpassungen)

- **Nach kritischen Incidents** (Security, Fehlfunktionen)

**Nächster Review-Termin**: August 2026

### 10.3 Modell-Update-Prozess

**Vor einem Modell-Update (neue Ollama-Version)**:

1. **Test-Installation** in separater Umgebung

2. **Funktions-Tests** aller KI-Features

3. **Output-Quality-Vergleich** (alte vs. neue Version)

4. **Risiko-Assessment** (neue Risiken durch Update?)

5. **Dokumentations-Update** (Versions-Nummern, Change-Log)

6. **Produktions-Rollout** mit Rollback-Plan

**Dokumentation**:

- Change-Log: `/docs/AI_Model_Updates.md`

- Test-Reports: `/test-reports/ai-model-tests/`

### 10.4 Incident Response

**Bei KI-bezogenen Incidents (z.B. fehlerhafte Vorschläge, Ausfälle)**:

1. **Identifikation**: Incident-Meldung (Nutzer-Report, Monitoring)

2. **Triage**: Kritikalität bewerten (Sicherheitsrelevant? Compliance-relevant?)

3. **Mitigation**:

- Kritisch: KI-Feature temporär deaktivieren

- Unkritisch: Dokumentation, Tracking für nächstes Update

4. **Root Cause Analysis**: Ursache ermitteln (Modell-Fehler? Daten-Problem? Bug?)

5. **Fix**: Implementierung + Test

6. **Dokumentation**: Incident-Report + Lessons Learned

7. **Kommunikation**: Bei kritischen Incidents → Kunden-Info

**Incident-Log**: `/docs/AI_Incidents.md`

---

## 11. Zukünftige Entwicklungen

### 11.1 Geplante KI-Erweiterungen (Phase 2)

**Potenzielle neue Features (frühestens Q3/Q4 2026)**:

- Automatische Requirements-Extraktion aus Dokumenten (PDF, DOCX)

- Verbesserte FMEA-Vorschläge mit Detection-Measures

- Multi-Lingual Support für Requirements (Übersetzungs-Vorschläge)

- Trace-Vorschläge zwischen Requirements und Tests

**Compliance-Relevanz bei Erweiterungen**:

- Jedes neue KI-Feature erfordert Risiko-Assessment

- Update dieser Compliance-Dokumentation

- Ggf. Anpassung der Nutzer-Information

### 11.2 Monitoring EU AI Act Entwicklung

**Relevante Stichtage**:

- **02.08.2026**: EU AI Act Anwendungsbeginn (High-Risk-Systeme)

- **02.02.2027**: Allgemeine Anwendung (alle KI-Systeme)

**Maßnahmen**:

- Halbjährliche Review relevanter Rechtsprechung

- Monitoring von BfDI (Bundesdatenschutzbeauftragter) Guidance

- Teilnahme an Industry-Foren (z.B. Bitkom AI Compliance)

### 11.3 Exit-Strategie

**Falls OTSM als Hochrisiko-System eingestuft wird** (z.B. durch Rechtsprechung):

**Option 1: Compliance-Upgrade**

- Konformitätsbewertung nach Artikel 43 EU AI Act

- Technische Dokumentation erweitern (Artikel 11)

- Risikomanagementsystem implementieren (Artikel 9)

- CE-Kennzeichnung beantragen

- **Aufwand**: Hoch (6-12 Monate, ca. 50.000-100.000 EUR)

**Option 2: KI-Degradierung**

- KI-Features optional machen (reine Assistenz, klar deaktivierbar)

- Noch stärkere Betonung des Human-in-the-Loop

- Marketing-Fokus auf manuelle Prozesse, KI als Bonus

- **Aufwand**: Gering (hauptsächlich Marketing/Kommunikation)

**Option 3: KI-Removal**

- Vollständige Entfernung aller KI-Features

- Fokus auf strukturierte Datenverwaltung ohne AI

- **Aufwand**: Mittel (2-3 Monate Refactoring)

**Aktuelle Einschätzung**: Option 1 oder 2 wahrscheinlich ausreichend, Option 3 unwahrscheinlich notwendig.

---

## 12. Anhänge

### 12.1 Definitionen und Glossar

| Begriff | Definition |

|---------|------------|

| **EU AI Act** | Verordnung (EU) 2024/1689 über Künstliche Intelligenz (AI Act) |

| **Hochrisiko-KI-System** | KI-System gemäß Artikel 6 EU AI Act mit hohem Risikopotenzial |

| **Minimal-Risiko-System** | KI-System mit minimalen oder keinen Risiken (Art. 50 Transparenzpflicht) |

| **Human-in-the-Loop** | KI-Design, bei dem menschliche Aufsicht vor jeder Entscheidung erforderlich ist |

| **Ollama** | Open-Source-Plattform für lokales Hosting von LLMs |

| **Embedding** | Vektorrepräsentation von Text für semantische Ähnlichkeitssuche |

| **SOPHISTEN** | Methodik für strukturierte Requirements-Formulierung |

| **FMEA** | Failure Mode and Effects Analysis - Risikoanalysemethode |

| **pgvector** | PostgreSQL-Extension für Vektor-Similarity-Search |

### 12.2 Referenzen und Rechtsgrundlagen

**Primäre Rechtsgrundlagen**:

- EU AI Act (Verordnung 2024/1689) - https://eur-lex.europa.eu/

- GDPR (Verordnung 2016/679) - Datenschutz-Grundverordnung

- NIS2-Richtlinie (EU 2022/2555) - Netz- und Informationssicherheit

**Technische Standards**:

- ISO/IEC 23894:2023 - AI Risk Management

- ISO/IEC 42001:2023 - AI Management System

- SOPHISTEN Requirements Engineering Methodik

**Weitere Quellen**:

- Ollama Documentation - https://ollama.ai/

- nomic-embed-text Model Card - https://huggingface.co/nomic-ai/nomic-embed-text-v1.5

- Meta Llama 3.2 License - https://llama.meta.com/

### 12.3 Kontakt und Fragen

**Für Fragen zu dieser Dokumentation**:

- **Technisch**: Thomas [Nachname], [E-Mail]

- **Compliance**: [E-Mail] (oder Thomas während Gründungsphase)

- **Allgemein**: support@otsm.de

**Dokumenten-Historie**:

- **Version 1.0** (Februar 2026): Initiale Erstellung vor Go-Live

---

## Unterschrift und Freigabe

**Erstellt durch**: Thomas [Nachname], Founder & Lead Developer

**Datum**: [Datum einfügen]

**Nächste Review**: August 2026

**Freigegeben für**:

- ✅ Interne Verwendung (Team-Dokumentation)

- ✅ Externe Verwendung (Kunden auf Anfrage)

- ✅ Audit-Zwecke (Compliance-Prüfungen)

---

**Hinweis**: Dieses Dokument ist ein lebendes Dokument und wird entsprechend der EU AI Act Entwicklung, technischer Änderungen und neuer Erkenntnisse aktualisiert.