OperativeOps und die EU-KI-Verordnung
OperativeOps ist selbstbetriebene Software, die innerhalb Ihrer eigenen Grenze läuft — damit sind Sie Betreiber des KI-Systems im Sinne der KI-Verordnung. Die Software liefert die technischen Oberflächen, die diese Rolle braucht: KI-Kennzeichnung in der Oberfläche, Freigabe-Gates pro Aktion und ein Append-only-Audit-Ledger jeder Modellentscheidung.
- OperativeOps gibt es ausschließlich im Selbstbetrieb — auf Ihren Servern, in Ihrer eigenen Cloud-Umgebung oder air-gapped. Es existiert kein gehostetes oder betreutes Angebot; die Jurisdiktion der Bereitstellung ist schlicht die, in der Sie bereitstellen.
- Sie sind Betreiber des KI-Systems. Die Pflichten aus Ihrer Risikoeinstufung liegen bei Ihnen — die Software liefert Ihnen Logs, Freigabe-Gates und Konfigurationsnachweise, um sie zu erfüllen.
- Bring your own model: Die Pflichten für ein KI-Modell mit allgemeinem Verwendungszweck treffen denjenigen, der dieses Modell bereitstellt. Sie wählen es — OpenAI, Anthropic, ein lokales Ollama- oder vLLM-Backend — und diese Wahl bestimmt, welcher vorgelagerte Anbieter überhaupt beteiligt ist.
- Ein Append-only-Audit-Ledger erfasst jede Modellentscheidung, jeden Tool-Aufruf und jede menschliche Freigabe — die Nachweisgrundlage für Post-Market-Monitoring und die Rekonstruktion von Vorfällen.
- Diese Seite ist keine Rechtsberatung. Sie beschreibt die Bereitstellungslage, damit Ihr Datenschutzbeauftragter und Ihre Rechtsabteilung eigenverantwortlich entscheiden können.
Was die EU-KI-Verordnung verlangt
Die EU-KI-Verordnung ist die umfassende Regulierung der Europäischen Union für künstliche Intelligenz mit gestaffeltem Inkrafttreten ab 2. Februar 2025 (verbotene Praktiken), 2. August 2025 (GPAI-Anbieterpflichten) und 2. August 2026 (Hauptteil der Vorschriften und Durchsetzung).
Die Pflichten variieren je Risikoklasse: verbotene Praktiken (untersagt), Hochrisikosysteme (Konformitätsbewertung, technische Dokumentation, Post-Market-Monitoring), begrenztes Risiko (Transparenz gegenüber Endnutzern) und minimales Risiko (freiwillige Verhaltenskodizes).
Die Verordnung unterscheidet außerdem den Anbieter eines KI-Systems von seinem Betreiber. Wenn Sie selbstbetriebene Software auf eigener Infrastruktur betreiben und Agenten, Modell-Backend und zulässige Aktionen selbst konfigurieren, sind Sie Betreiber — und können je nach Konfigurationstiefe zusätzlich Anbieterpflichten für das von Ihnen zusammengestellte System übernehmen.
Für die meisten Geschäftsbereitstellungen von OperativeOps sind primär Artikel 50 (Transparenzpflicht: Menschen müssen wissen, dass sie mit KI interagieren) sowie die Dokumentations- und Aufsichtspflichten relevant, sofern der Betreiber seinen Anwendungsfall nach Anhang III als Hochrisiko einstuft.
Wie OperativeOps die Anforderungen abbildet
| Requirement | Our control | Where |
|---|---|---|
| Artikel 50 — KI-Interaktion offenlegen | Agenten weisen sich in der Oberfläche als KI aus; Systemnachrichten kennzeichnen den nicht-menschlichen Urheber. Pro Bereitstellung konfigurierbar. | self-hosted |
| Nachweisführung für die technische Dokumentation des Betreibers | Die Konfiguration, die das System definiert — Agentenrollen und Berechtigungsgrenzen, angebundene Tools, Retrieval-Quellen und das Modell-Backend jedes Agenten —, liegt in Ihrer eigenen Bereitstellung und wird mit ihr versioniert. | self-hosted |
| Logging und Post-Market-Monitoring | Append-only-Audit-Ledger jeder Modellentscheidung, Agentenaktion, jedes Tool-Aufrufs und jeder menschlichen Freigabe — in Ihrer eigenen Datenbank, so lange Sie es konfigurieren. | self-hosted |
| Datenresidenz / Souveränität | Ihre Infrastruktur, Ihre Jurisdiktion. Die Software ruft von sich aus nichts nach außen; jeder Egress zu einem externen Modellanbieter läuft über ein Gate, das Sie konfigurieren. | self-hosted |
| Menschliche Aufsicht (Art. 14) | Freigabe-Gates pro Aktion für Tool-Aufrufe, mit rollenbezogen konfigurierbaren Freigabe-Bereichen. Agenten lesen und empfehlen, solange Sie eine Aktion nicht ausdrücklich freigeben. | self-hosted |
| Genauigkeit und Nachvollziehbarkeit der Ausgaben | Retrieval-Antworten tragen Quellenangaben zurück auf die Dokumente in Ihrem eigenen Vektorspeicher — eine Ausgabe lässt sich auf das Material zurückführen, aus dem sie stammt. | self-hosted |
Was der Selbstbetrieb unter der KI-Verordnung ändert
Der Selbstbetrieb platziert OperativeOps innerhalb Ihrer VPC, Ihres Rechenzentrums oder eines air-gapped Netzes. Sie kontrollieren die Netzwerkgrenze, das Modell-Backend und die Datenebene durchgehend. Das ist der sauberste Weg, Datenminimierung und Zweckbindung nachzuweisen — und es bedeutet, dass das KI-System, dessen Risiko Sie bewerten, eines ist, das Sie tatsächlich prüfen können: Agentendefinitionen, Berechtigungsgrenzen und Audit-Ledger liegen vor Ihnen, statt Ihnen von einem Anbieter beschrieben zu werden.
Es bedeutet außerdem, dass Sie eindeutig Betreiber sind. Zwischen Ihnen und dem System steht kein hostender Betreiber, also gestalten Sie Einstufung, Aufsichtsmaßnahmen und Post-Market-Monitoring selbst. Das ist mehr Arbeit als die Übernahme eines fertigen Compliance-Pakets — und zugleich der Grund, warum die Nachweise bei Ihnen entstehen, statt bei jemandem angefordert werden zu müssen.
Die eine Pflicht, die nicht vollständig bei Ihnen liegt, betrifft das KI-Modell mit allgemeinem Verwendungszweck. Leiten Sie einen Agenten auf eine gehostete Modell-API, trägt dessen Anbieter die GPAI-Anbieterpflichten nach Kapitel V, und Prompt-Inhalte verlassen dafür Ihr Netz. Leiten Sie auf ein lokales Ollama- oder vLLM-Backend, bleibt die Inferenz innerhalb Ihrer Grenze und das vorgelagerte Anbieterverhältnis entfällt — dafür übernehmen Sie mehr der Dokumentationslast auf Modellebene selbst. Beides wird unterstützt; die Abwägung ist bewusst Ihre.
Wofür Sie verantwortlich sind
- Einstufung Ihres Anwendungsfalls (verboten / Hochrisiko / begrenztes Risiko / minimal) gemäß Anhang III — und erneute Prüfung, sobald Sie Agenten ergänzen oder neue Systeme anbinden.
- Bewertung, ob Ihre Konfiguration so weitreichend ist, dass Sie für das zusammengestellte System nicht nur Betreiber, sondern auch Anbieter sind.
- Eigene Datenschutz-Folgenabschätzung sowie, soweit für Sie einschlägig, eine Grundrechte-Folgenabschätzung nach Art. 27.
- Verzeichnis der Verarbeitungstätigkeiten gemäß Art. 30 DSGVO.
- Auswahl des Modell-Backends und Verständnis der Folgen: welcher vorgelagerte Anbieter GPAI-Pflichten trägt und ob Prompt-Inhalte Ihr Netz verlassen.
- Konfiguration von Agenten-Berechtigungsgrenzen, Freigabe-Gates und Audit-Log-Aufbewahrung gemäß Ihren Pflichten.
- Beauftragung Ihrer Rechtsabteilung für die rechtliche Auslegung. Diese Seite dokumentiert die technische Oberfläche; die rechtliche Bewertung treffen Sie.
Frequently asked questions
Ist OperativeOps EU-KI-Verordnung-konform?
Konformität nach der KI-Verordnung knüpft an ein System in einem Verwendungskontext an, nicht an ein Softwarepaket für sich. OperativeOps ist darauf ausgelegt, konform betrieben zu werden: KI-Kennzeichnung in der Oberfläche, rollenbezogen abgegrenzte Agenten, Freigabe-Gates pro Aktion und ein Append-only-Audit-Ledger. Die abschließende Bewertung für Ihre Bereitstellung treffen Ihr DSB und Ihre Rechtsabteilung.
Wann tritt die EU-KI-Verordnung in Kraft?
Gestaffelt: verbotene Praktiken seit 2. Februar 2025; GPAI-Anbieterpflichten seit 2. August 2025; Hauptteil inklusive Hochrisikosystem-Anforderungen und Durchsetzung durch die Kommission ab 2. August 2026.
Gilt OperativeOps als Hochrisikosystem?
Nicht standardmäßig. OperativeOps ist universelles Geschäftswerkzeug. Ob Ihre konkrete Bereitstellung ein Hochrisikosystem ist, hängt von der Anhang-III-Einstufung und Ihrem Anwendungsfall ab — z. B. Personalauswahl oder kritische Infrastruktur lösen typischerweise Hochrisikopflichten beim Betreiber aus.
Wer ist Anbieter und wer ist Betreiber?
Sie betreiben die Software selbst und sind damit Betreiber des KI-Systems. Je nachdem, wie weitreichend Sie Agenten, Retrieval-Quellen und zulässige Aktionen konfigurieren, können Sie zusätzlich Anbieterpflichten für das zusammengestellte System übernehmen. Die Anbieterpflichten für das zugrunde liegende Modell mit allgemeinem Verwendungszweck liegen bei demjenigen, der dieses Modell bereitstellt — eine Wahl, die Sie bei der Konfiguration treffen.
Kann OperativeOps vollständig innerhalb der EU betrieben werden?
Ja — und darüber hinaus: Es lässt sich vollständig innerhalb eines einzigen Netzes ohne jede externe Abhängigkeit betreiben. Docker Compose, On-Premises-Kubernetes und air-gapped Installationen werden unterstützt; mit einem lokalen Modell-Backend gibt es überhaupt keinen ausgehenden Inferenzaufruf.
Welche Dokumentation liegt einem Release bei?
Release-Artefakte und die zugehörigen Hinweise. Wir behaupten nicht, in Ihrem Namen eine Konformitätsbewertung, eine CE-Kennzeichnung oder eine Drittprüfung zu veröffentlichen — diese knüpfen an ein System in seinem Verwendungskontext an, und die Bereitstellung ist Ihre. Was die Software Ihnen stattdessen gibt, sind unmittelbare Nachweise: die von Ihnen gesetzte Agenten- und Berechtigungskonfiguration, das gewählte Modell-Routing und ein Append-only-Ledger dessen, was das System tatsächlich getan hat.
Wird OperativeOps CE-gekennzeichnet oder drittzertifiziert?
Die Konformitätsbewertung hängt von der Risikoklassifizierung eines bereitgestellten Systems ab — einer Eigenschaft Ihrer Bereitstellung, nicht der Software. Es gibt keine Drittzertifizierung, auf die wir verweisen könnten. Soweit von Ihnen eine Konformitätsbewertung verlangt wird, sind die oben beschriebenen Kontrollen und Nachweise das Material, aus dem Sie sie erstellen.