Nachnutzung

Einleitung, Zweck und Mehrwert

Das Nachnutzungskonzept dient als verbindliche Grundlage für Planung, Onboarding, Betrieb, Governance sowie die gemeinschaftliche Weiterentwicklung im Sinne des Einer-für-Alle-Prinzips.

Zielsetzung: Das Dokument soll Klarheit über technische und organisatorische Anforderungen schaffen und die Nutzung, Inbetriebnahme und Integration der Plattform standardisieren. Es adressiert Risiken und Abhängigkeiten frühzeitig.

Zentrale Mehrwerte der KIVA-Plattform für Nachnutzer:

1. Digitale Souveränität: Die Plattform ist als Open-Source-Lösung konzipiert und vermeidet Vendor Lock-in. Sie unterstützt den Betrieb On-Premises oder bei deutschen Cloud-Anbietern.
2. Modularität und Wiederverwendbarkeit: Die Architektur erlaubt die unabhängige Entwicklung und den Austausch von Komponenten. Horizontale und vertikale Anwendungsfälle entstehen durch geeignete Kombination der Bestandteile (Microservices, RAG-Services, Agenten, Tools).
3. Offene Standards: Nutzung von OpenAI API, MCP, OpenID Connect und OpenTelemetry als Basis für Interoperabilität.
4. EfA-Fähigkeit & Community-Modell: Blueprints, Referenzimplementierungen und der Use Case Shop ermöglichen die gemeinschaftliche Weiterentwicklung nach dem EfA-Prinzip.

Technische Voraussetzungen und Integrationsanforderungen

Die Nachnutzung setzt die Einhaltung klarer architektonischer und technischer Standards voraus.

Architektonische Basis

Die KIVA-Architektur basiert auf lose gekoppelten Mikroservices (Service-orientierte Architektur) und einem Infrastruktur-agnostischen Deployment-Ansatz in Kubernetes. Die Referenzarchitektur und die dazugehörige Referenzimplementierung bilden die technische Grundlage für alle Nachnutzer.

Offene Standards und Interoperabilität

Nachnutzer müssen folgende vier Schlüsselstandards unterstützen, um die Interoperabilität und Unabhängigkeit zu gewährleisten:

1. OpenAI API-Schema: Dient als standardisierte Abstraktion für den Zugriff auf LLM-Modelle.
2. Model Context Protocol (MCP): Standardisiert den Zugriff auf Daten, Tools und Prompt-Templates (Prompt Store).
3. OpenID Connect (OIDC): Notwendig für die Authentifizierung und Autorisierung der Nutzer (z. B. über Keycloak).
4. OpenTelemetry (OTel): Standardisiert die Observability (Logging, Metrics, Tracing).

Integration und Datenmanagement

• Integrationspunkte: Die Integration erfolgt über definierte Punkte zu Fachverfahren, zur Datenhaltung (z. B. PostgreSQL für Audit-Logs und ChromaDB für Vektor-Daten) sowie zu Logging- und Monitoring-Systemen.
• Datenhoheit: Die Plattform folgt dem Prinzip des Föderierten Datenmanagements, bei dem die Daten dezentral und souverän in spezialisierten Datenbanken gespeichert werden.
• Golden Paths: Für typische Integrationsszenarien, wie die Einbindung des Identity Providers (OIDC) oder die Nutzung des API Gateways, werden standardisierte Integrationswege (Golden Paths) und Template-Konfigurationen bereitgestellt.

Betriebsmodell und Verantwortlichkeiten

Die Nachnutzung der KIVA-Plattform ist in drei Modellen möglich:

1. Zentraler Betrieb: Das Originator-Land (bereitstellendes Land) betreibt den Dienst vollständig zentral. Nachnutzer greifen über API-Schnittstellen zu. Dabei werden zentrale SLAs, Supportleistungen und Kapazitätsmodelle festgelegt.
2. Dezentraler Betrieb: Der Nachnutzer führt ein vollständiges Deployment der Open-Source-Plattform durch. Dies erfordert die Bereitstellung von Installationspaketen und klaren Vorgaben für Monitoring und Updates.
3. Hybridmodelle: Mögliche Mischformen, z. B. die zentrale Bereitstellung der GPU-Infrastruktur/Inference-Layers (zur Optimierung der Performance und Kosten) bei dezentraler Integration der Fachdaten und Services.

Betriebsverantwortung: Die Verantwortlichkeiten sind klar zuzuordnen (z. B. über ein RACI-Modell). Dazu gehören die Definition von Rollenmodellen, Eskalationswegen und Standard Operating Procedures (SOPs).

Onboarding-Prozess und Adoption

Der strukturierte Onboarding-Prozess gewährleistet eine effiziente Übernahme der Plattform:

1. Vorbereitungsphase: Erstberatung, Prüfung der technischen Voraussetzungen, Zugang zur umfassenden Dokumentation und zu Testzugängen.
2. Integrations- und Testphase: Implementierung der Integrationsschnittstellen, Durchführung von Sicherheits-, Last- und Abnahmetests auf Basis definierter Testfälle und Akzeptanzkriterien.
3. Rollout: Konfiguration, Aktivierung produktiver Schnittstellen und Übergabe in den Wirkbetrieb.
4. Stabilisierung und Support: Begleitung des Betriebs in der Anfangsphase (Post-Go-Live-Support) und Übergabe in die definierten Regelprozesse und Supportstrukturen.

Governance und Zusammenarbeit (EfA-Mechanismen und Wiederverwendung)

Die nachhaltige Entwicklung und der gemeinsame Fortschritt der Plattform werden durch eine klare Governance und spezifische Mechanismen zur Förderung der Wiederverwendbarkeit sichergestellt.

Wiederverwendungs-Mechanismen

• Use Case Shop zur Bereitstellung von Lösungen: Über die Plattform kann ein Use Case Shop bereitgestellt werden, der den zentralen Austausch und die Veröffentlichung von erfolgreich implementierten Lösungen ermöglicht.

• Gemeinsames Repository für Blueprints und Referenzen: Es wird ein gemeinsames Repository genutzt, um Blueprints und Referenzimplementierungen für Architekturen und Use Cases in der Community zu teilen (geshared). Diese Artefakte (z. B. Container/Helm, Konfigurationen, Schnittstellenbeschreibungen) dienen als Vorlage für neue Implementierungen.

• Möglichkeit der Adaption und Wiederverwendung: Durch die modulare Architektur und die Bereitstellung von Blueprints ist die Möglichkeit zur Adaption und Wiederverwendung von Use Cases und Komponenten maximiert. Dadurch wird die Vermeidung redundanter Arbeiten gewährleistet.

• Horizontale und vertikale Anwendungsfälle: Die Implementierung neuer Use Cases, sowohl horizontal (für breite Nutzergruppen) als auch vertikal (spezialisierte Fachverfahren), basiert auf der geeigneten Kombination der modularen Bestandteile der KIVA-Plattform und muss basierend auf der Referenzarchitektur beschrieben und implementiert werden.

Koordinations- und Abstimmungsprozesse

• Koordination: Die Steuerung erfolgt über strategische Gremien (z. B. EfA-Board) und technische Arbeitsgruppen für die gemeinsame Roadmap-Planung.

• Beitragsmodell: Der definierte Contribution Workflow stellt sicher, dass Weiterentwicklungen der Nachnutzer in die gemeinsame Open Source-Basis einfließen

Qualität, Sicherheit und Observability

Die Plattform ist darauf ausgelegt, hohe Sicherheits- und Qualitätsstandards zu erfüllen.

• Sicherheit: Die Architektur adressiert die OWASP Top 10 für LLM. Mechanismen wie RBAC (Role-Based Access Control), Input/Output Guardrails (gegen Prompt Injection) und Groundedness Score Monitoring (gegen Halluzinationen) sind implementiert. Die logische Mandantentrennung auf Datenbankebene (Row-Level Security) und die Isolation der Vector-Stores gewährleisten, dass kein Datenabfluss zwischen Mandanten erfolgt.
• Observability: Die Nutzung des OpenTelemetry-Standards ist verpflichtend. Dieser gewährleistet End-to-end Tracing, ein einheitliches Logformat und die Erfassung aller notwendigen Metriken. Es müssen Audit Logs aller KI-Interaktionen geführt werden, inklusive des Token Consumption (Verbrauchstracking), was auch für die Kostenabrechnung relevant ist.
• Risikomanagement: Risiken wie Komplexität der Integration oder Fachliche Divergenzen werden durch klare Governance und Golden Paths abgemildert.

Kosten- und Lizenzmodell

• Lizenzierung: Die Referenzimplementierung nutzt Open-Source-Lizenzen. Nutzungs- und Weiterentwicklungsrechte sind durch die EfA-Governance geregelt.
• Kostenstruktur: Es wird zwischen Einmalkosten (CapEx) (Onboarding, Integrationsunterstützung) und Laufenden Kosten (OpEx) (Betrieb, Support, Weiterentwicklung) unterschieden.
• Abrechnung: Die Verteilung der Kosten erfolgt in der Regel über Umlageverfahren und vertraglich geregelte Budgets. Das Monitoring des Token Consumption (Verbrauchstracking) sowie ggf. der GPU-Stunden ermöglicht eine verbrauchsabhängige Kostenkontrolle.