[{"data":1,"prerenderedAt":812},["ShallowReactive",2],{"/de-de/blog/what-is-mlops":3,"navigation-de-de":37,"banner-de-de":451,"footer-de-de":461,"blog-post-authors-de-de-GitLab Germany Team":697,"blog-related-posts-de-de-what-is-mlops":712,"blog-promotions-de-de":750,"next-steps-de-de":802},{"id":4,"title":5,"authorSlugs":6,"authors":8,"body":10,"category":11,"categorySlug":11,"config":12,"content":16,"date":19,"description":17,"extension":23,"externalUrl":24,"featured":13,"heroImage":22,"isFeatured":13,"meta":25,"navigation":26,"path":27,"publishedDate":19,"rawbody":28,"seo":29,"slug":15,"stem":32,"tagSlugs":33,"tags":35,"template":14,"updatedDate":24,"__hash__":36},"blogPosts/de-de/blog/what-is-mlops.yml","MLOps – systematisches ML-Lifecycle-Management mit GitLab",[7],"gitlab-germany-team",[9],"GitLab Germany Team","**MLOps (Machine Learning Operations) umfasst alle Praktiken zum zuverlässigen, nachhaltigen Deployment, Monitoring und Maintenance von Machine-Learning-Modellen in Production.**\n\n\nEin Modell in Production zu bringen ist mehr als Training. Zwischen Datenaufbereitung, Deployment, Performance-Monitoring und Maintenance stoßen Teams auf Komplexität, die weit über reine Entwicklung hinausgeht. Resultat: verlängerte Timelines, explodierende Kosten, einbrechende Zuverlässigkeit.\n\n\n**Kurz gesagt: MLOps verhält sich zu Machine Learning wie [DevOps](https://about.gitlab.com/de-de/topics/devops/) zu Software-Entwicklung – ein strukturierter Ansatz, der Workflows automatisiert, Kollaboration zwischen Data-Science- und Engineering-Teams verbessert und Modell-Kontinuität in Production garantiert.**\n\n\nDurch Organisation des kompletten Modell-Lifecycles – von Konzeption bis kontinuierlicher Verbesserung – ermöglicht MLOps Organisationen, maximalen Wert aus KI-Projekten zu ziehen und diese langfristig zu etablieren.\n\n\n> **[→ GitLab Ultimate und GitLab Duo Enterprise kostenlos testen.](https://about.gitlab.com/de-de/free-trial/devsecops/?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_x_trial_x_de_blog_de)**\n\n\n## MLOps: Definition und Rolle\n\n\nDer Begriff **MLOps** kombiniert *Machine Learning und Operations*. Er bezeichnet alle Praktiken, Tools und Methoden zur Verwaltung des kompletten Machine-Learning-Modell-Lifecycles – von Konzeption bis Production-Betrieb.\n\n\nDie zentrale Idee: **Zwei oft getrennte Welten verbinden** – **Data Scientists**, die Modelle entwickeln und trainieren, und **Engineering-Teams**, die diese deployen, monitoren und maintainen müssen. Durch diese Verbindung garantiert MLOps Kontinuität zwischen Experimentierung und realer Nutzung.\n\n\nDie Rolle geht über reine Automatisierung hinaus. MLOps zielt darauf ab, Modell-Zuverlässigkeit über Zeit zu garantieren, Team-Kollaboration zu optimieren und Organisationen einen Rahmen zu geben für [industrielle, nachhaltige Machine-Learning-Nutzung](https://about.gitlab.com/de-de/the-source/ai/6-strategies-to-help-developers-accelerate-ai-adoption/).\n\n\n![MLOps-Konzept-Übersicht](https://res.cloudinary.com/about-gitlab-com/image/upload/v1762517964/cwgub5rfekc0wzcms012.png)\n\n\n## Warum ist MLOps unverzichtbar geworden?\n\n\nMachine Learning hat sich weit über Forschung hinaus etabliert. Use Cases multiplizieren sich: Echtzeit-Betrugs-Detection, personalisierte Empfehlungen, Predictive Maintenance, generative Assistenten. Diese Modelle bleiben nicht im experimentellen Stadium – sie müssen in Production laufen, oft mit strikten Latenz-Anforderungen und unter starken Constraints.\n\n\nDoch Schwierigkeiten treten schnell auf. **Deployment-Zyklen verlängern sich**, Modelle degradieren sobald Daten evolvieren, und Ergebnisse werden schwer auditierbar. Ohne Optimierung explodieren Infrastruktur-Kosten. Diese Bremsen sind Teams inzwischen bekannt.\n\n\nMLOps bietet eine strukturierte Antwort auf diese Probleme. Es standardisiert **Deployment**, **Monitoring** und **Governance** von Modellen. Es ermöglicht auch Zukunftsvorbereitung: AutoML-Integration, generative Modell-Verwaltung, Compliance mit neuen Regelungen wie dem AI Act (Europäische KI-Verordnung).\n\n\n**Für deutsche Unternehmen wird MLOps durch die KI-Verordnung der EU (AI Act) zur strategischen Notwendigkeit.** Die Verordnung tritt vollständig im August 2026 in Kraft. Artikel 9 fordert Risiko-Management-Systeme für Hochrisiko-KI. Artikel 17 verlangt technische Dokumentation aller ML-Modelle inklusive Training-Daten, Architektur und Validation. MLOps-Praktiken – systematisches Versioning, Audit-Trails, reproduzierbare Pipelines – erfüllen diese Anforderungen direkt.\n\n\nFür viele Organisationen markiert MLOps-Adoption einen **Reife-Schritt**. Sie bedingt die Fähigkeit, Prototypen in dauerhafte Assets zu transformieren und KI in glaubwürdige Unternehmensstrategie einzubetten.\n\n\n## Welche Vorteile bietet MLOps?\n\n\nMLOps ist keine reine Methode – es ist ein Kultur-Wandel, der Machine Learning **schneller, zuverlässiger und skalierbarer** in jeder Phase des Software-Entwicklungs-Lifecycles macht.\n\n\n### 1. Endlich alignte Teams\n\n\nMLOps eliminiert Silos zwischen Data Scientists, Entwicklern und Ops-Engineers. Durch gemeinsame Pipelines und denselben Code visualisieren alle dieselben Metriken und sprechen dieselbe Sprache. Modelle gehen von R&D in Production ohne Brüche oder Informationsverlust.\n\n\n### 2. Friktionsfreier Production-Übergang\n\n\nDank CI/CD-Automatisierung laufen Training, Testing und Deployment ohne manuelle Intervention ab. Was Wochen dauerte, geschieht in Stunden – mit reproduzierbaren, kontrollierten Workflows über integrierte Plattformen wie GitLab.\n\n\n### 3. Nachvollziehbare, reproduzierbare Modelle\n\n\nJede Modell-Version, jedes Dataset und jeder Code wird archiviert. Bei Drift lässt sich ein Experiment wiederholen, die Ursache identifizieren oder eine stabile Version wiederherstellen. Diese Nachvollziehbarkeit transformiert Machine Learning in verifizierbaren, nachhaltigen Prozess.\n\n\n**Diese systematische Reproduzierbarkeit erfüllt zentrale Anforderungen der KI-Verordnung Artikel 17 (technische Dokumentation) und ermöglicht deutschen Unternehmen audit-fähige Nachweise für Compliance.**\n\n\n### 4. Kontinuierliche Production-Überwachung\n\n\nMLOps endet nicht beim Deployment. Performances werden kontinuierlich überwacht zur Drift-Erkennung. Tools wie Prometheus oder Grafana lassen sich in GitLab integrieren für Team-Alerting oder automatisches Retraining-Triggering.\n\n\n### 5. Governance by Design\n\n\nSecurity-, Compliance- und Audit-Anforderungen sind Teil der Pipeline. Automatische Dokumentation, Access-Control und Audit-Logs garantieren Transparenz und regulatorische Compliance ohne Zusatzaufwand.\n\n\n## MLOps-Prinzipien und Best Practices\n\n\nMLOps beschränkt sich nicht auf Konzepte. Es umfasst präzise Praktiken, die experimentelle Modelle in zuverlässige, nachhaltige Services transformieren. Diese Praktiken decken die gesamte Software-Chain ab: Development, Deployment, Monitoring und Governance.\n\n\n### Workflow-Automatisierung (CI/CD/CT)\n\n\nEin klassisches Machine-Learning-Projekt durchläuft mehrere repetitive Schritte:\n\n\n1. Datenaufbereitung\n\n2. Training\n\n3. Testing\n\n4. Packaging\n\n5. Deployment\n\n\nManuell durchgeführt sind diese langsam und fragil. Automatisierung transformiert diesen Pfad in kontinuierliche, vorhersagbare Chain.\n\n\nMit **[CI/CD-Pipelines](https://about.gitlab.com/de-de/topics/ci-cd/cicd-pipeline/)** triggert jede Code- oder Daten-Änderung automatisch notwendige Schritte: Training, Validation, Deployment. Modelle gehen schneller in Production, mit weniger Fehlern.\n\n\n**[GitLab CI/CD](https://about.gitlab.com/de-de/topics/ci-cd/)**, bereits breit in Software-Entwicklung adaptiert, bildet eine natürliche Basis zur Orchestrierung dieser MLOps-Pipelines.\n\n\n**CT (Continuous Training)** ergänzt CI/CD durch Automatisierung des Modell-Retrainings. Sobald Drift erkannt wird oder Performance-Schwellen überschritten werden, kann automatisch ein neuer Training-Zyklus getriggert werden. Diese Praxis hält Modelle aligned mit Daten-Evolution ohne manuelle Intervention.\n\n\n**Beispiel**: Diese minimalistische YAML-Datei illustriert eine typische ML-Pipeline, orchestriert über GitLab CI/CD:\n\n\n* Daten-Ingestion und -Aufbereitung,\n\n* Modell-Training und -Speicherung,\n\n* Testing und Evaluation,\n\n* Automatisiertes Production-Deployment.\n```yaml\n\nimage: python:3.9\n\n\nbefore_script:\n  - pip install --no-cache-dir -r requirements.txt\n\nstages:\n  - prepare\n  - train\n  - test\n  - deploy\n\nprepare_data:\n  stage: prepare\n  script:\n    - python scripts/prepare_data.py\n  artifacts:\n    paths:\n      - data/processed/\n    expire_in: 7 days\n\ntrain_model:\n  stage: train\n  script:\n    - python scripts/train.py --data data/processed/\n  artifacts:\n    paths:\n      - models/model.pkl\n    expire_in: 30 days\n\ntest_model:\n  stage: test\n  script:\n    - pytest tests/\n    - python scripts/evaluate.py models/model.pkl\n\ndeploy_model:\n  stage: deploy\n  script:\n    - bash scripts/deploy.sh models/model.pkl\n  when: on_success\n```\n\n\n### Versions-Management (Daten, Modelle, Code)\n\n\nOhne rigoroses Versions-Management ist es unmöglich zu wissen, auf welchen Daten ein Modell trainiert wurde oder zu einem früheren Zustand bei Drift zurückzukehren.\n\n\nMLOps generalisiert **systematisches Versioning**. Jedes Dataset, jedes Modell und jede Pipeline wird archiviert und mit entsprechendem Code verknüpft. GitLab bringt diese [Versions-Management-Logik](https://about.gitlab.com/de-de/topics/version-control/) nativ mit – basierend auf [Git](https://about.gitlab.com/de-de/blog/what-is-git-the-ultimate-guide-to-gits-role-and-functionality/). Erweitert auf ML-Workflows garantiert es End-to-End-Nachvollziehbarkeit.\n\n\nHinweis: Die [GitLab Model Registry](https://docs.gitlab.com/user/project/ml/model_registry/) ermöglicht ML-Modell-Versionierung und -Katalogisierung neben Quellcode und schafft eine einzige Wahrheitsquelle für das gesamte Projekt.\n\n\n### Validation und Daten-/Modell-Qualität\n\n\nEin in Test-Umgebung performantes Modell kann in Production scheitern. Um diese Diskrepanz zu vermeiden, führt MLOps Validationen auf mehreren Ebenen ein.\n\n\n* **Daten-Qualität**: Outlier-Detection, Konsistenz zwischen Training- und Validation-Sets, Vollständigkeits-Tracking.\n\n* **Modell-Robustheit**: Performance-Tests, Bias-Verifikation, Evaluation anhand repräsentativer Business-Szenarien.\n\n\nDiese in Pipelines integrierten Controls reduzieren das Risiko, fragile oder biased Modelle zu deployen.\n\n\n### Monitoring und Drift-Detection\n\n\nEin Modell ist niemals statisch. Daten evolvieren, Verhaltensweisen ändern sich, und Performance degradiert über Zeit.\n\n\nMLOps integriert **kontinuierliches Monitoring** technischer und Business-Metriken. Es detektiert statistische Drifts, generiert Alerts und kann automatisches Retraining triggern. Diese Loop verlängert Modell-Lebensdauer und erhält Alignment mit operativen Anforderungen.\n\n\n### Data Engineering\n\n\nViele Projekte scheitern nicht an Modellen, sondern an **instabilen oder schlecht strukturierten Daten**. Daher ist Data Engineering essenzielle MLOps-Komponente.\n\n\nEs basiert auf mehreren Praktiken: klare Daten-Contracts zwischen Produzenten und Nutzern definieren, Qualität und Verfügbarkeit von Daten-Flows kontinuierlich überwachen, und den richtigen Processing-Modus wählen – Batch für massive Volumen, Streaming für Realtime. Diese Fundamente garantieren, dass Modelle auf zuverlässigen, stabilen Daten basieren.\n\n\nEine Schlüsselkomponente ist der Feature Store, der von Modellen genutzte Features zentralisiert und versioniert. Er garantiert Konsistenz zwischen Training und Production, vermeidet Duplikation und beschleunigt Entwicklung neuer Modelle.\n\n\n### LLMOps für generative Modelle\n\n\nÜber traditionelle Modelle hinaus bringen generative Modelle neue Herausforderungen: evolvierende Prompts, hohe Inference-Kosten, komplexere Qualitäts-Evaluation.\n\n\n**LLMOps** überträgt MLOps-Prinzipien auf diesen Kontext. Es umfasst Prompt-Versions-Management, User-Feedback-Integration und detailliertes Execution-Cost-Tracking. In manchen Umgebungen kann eine einzelne Anwendung Inference-Kosten von mehreren tausend Euro pro Tag generieren – Kontrolle dieser Ausgaben wird strategischer Imperativ.\n\n\n## MLOps-Projekt-Lifecycle\n\n\nMLOps reduziert sich nicht auf Prinzipien. Es ist primär eine Organisationsweise für Machine-Learning-Projekt-Lifecycles – von Datenaufbereitung bis kontinuierlicher Production-Verbesserung. Jede Phase ist mit anderen verknüpft und gewinnt Effizienz durch strukturierten Ansatz.\n\n\n### Daten-Sammlung und -Aufbereitung\n\n\nDaten sind Ausgangspunkt jedes Machine-Learning-Projekts. Dennoch sind sie auch eine der Haupt-Schwierigkeitsquellen. Mehrere Studien zeigen, dass Datenaufbereitung 50-80% der Data-Scientists-Zeit beanspruchen kann – abhängig von Quellen-Qualität und verfügbarem Automatisierungsgrad.\n\n\nMLOps formalisiert diese Arbeit mit automatisierten Ingestion-Pipelines, Daten-Contracts zwischen Teams und systematischen Validationen (Vollständigkeit, Konsistenz, Anomalie-Detection). Diese Mechanismen reduzieren Fehler und sichern folgende Schritte ab.\n\n\nDiese solide Basis optimiert Training-Schritte mit bestmöglichen Bedingungen.\n\n\n### Modell-Training\n\n\nSobald Daten bereit sind, geht es nicht nur um gute Metriken, sondern auch um **Reproduzierbarkeit** der Ergebnisse.\n\n\nMLOps verstärkt diese Phase mit zwei Hebeln:\n\n\n* **Systematisches Versioning** von Daten, Code und Modellen;\n\n* **Experiment-Automatisierung** via Pipelines.\n\n\nJeder Versuch wird dokumentiert, jeder Parameter aufgezeichnet. Teams können Ergebnisse objektiv vergleichen und vielversprechendste Konfigurationen schnell identifizieren.\n\n\n### Production-Deployment\n\n\nEin in Development-Umgebung performantes Modell hat keinen Impact, solange es nicht genutzt wird. Production-Deployment ist daher Schlüsselschritt, aber oft der heikelste.\n\n\nMLOps vereinfacht diesen Übergang durch Automatisierung: standardisiertes Packaging, integrierte Tests, reproduzierbares Deployment. Wo Production-Deployment mehrere Wochen Koordination benötigte, lässt es sich nun in Tagen realisieren.\n\n\nAuch hier bietet **GitLab CI/CD** eine solide Basis zur Orchestrierung dieser Continuous-Deployments – mit Tools, die [DevOps-Teams](https://about.gitlab.com/de-de/topics/devops/build-a-devops-team/) bereits kennen.\n\n\n### Performance-Tracking und kontinuierliche Verbesserung\n\n\nSobald online, wird das Modell mit Live-Daten konfrontiert. Seine Performance evolviert, manchmal negativ.\n\n\nManche Teams gehen über reines Monitoring hinaus und implementieren **automatisiertes Retraining**, sobald Performance-Degradations-Schwellen erreicht werden. Diese kontinuierliche Verbesserungs-Loop garantiert, dass Modelle relevant bleiben und mit Business-Anforderungen aligned sind.\n\n\n## Rollen in MLOps-Projekten\n\n\nMLOps-Projekte basieren nicht auf einem einzelnen Team, sondern auf Komplementarität mehrerer Profile. Jedes spielt eine Schlüsselrolle bei Konzeption, Deployment und Modell-Maintenance.\n\n\n### Data Scientists\n\n\nData Scientists bleiben Modell-Architekten. Ihre Rolle: **Daten explorieren**, Algorithmen konzipieren und verschiedene Ansätze testen. Sie definieren auch Metriken für Performance-Evaluation.\n\n\nIn MLOps-Ansätzen evolviert ihre Mission. Notebooks werden reproduzierbar, Scripts integrieren sich in Pipelines, und Modelle werden versioniert. Dieser Rahmen-Wechsel verhindert, dass Arbeiten im Prototyp-Stadium steckenbleiben, und erleichtert Production-Übergang.\n\n\n### Data Engineers und DevOps-Teams\n\n\nModelle haben nur Wert, wenn sie genutzt werden können. Data Engineers und DevOps-Teams spielen zentrale Rollen bei der Transformation von Experimenten in robuste Lösungen.\n\n\n* **Data Engineers** bauen und maintainen Ingestion-Pipelines, garantieren Qualität und Verfügbarkeit von Daten-Flows und legen Fundamente für Daten-Governance.\n\n* **DevOps-Teams** orchestrieren Deployments, automatisieren Tests und überwachen Umgebungen. Sie wenden auf Machine Learning Praktiken an, die Software-Entwicklung bereits transformiert haben: CI/CD, Monitoring, Access-Management.\n\n\nMit Plattformen wie **GitLab** haben diese Teams bereits bewährte Tools zur MLOps-Workflow-Integration ohne Tool- und Plattform-Multiplikation.\n\n\n### Koordination mit Business-Teams\n\n\nEin Modell wird nicht nur an Predictions-Präzision gemessen. Es muss auch sichtbaren Impact für die Organisation generieren. Hier kommen Business-Teams ins Spiel.\n\n\nSie definieren **Erfolgs-Key-Indicators**, bringen Feld-Expertise ein und validieren Modell-Relevanz in konkreten Kontexten. In MLOps-Ansätzen wird diese Kollaboration permanent statt punktuell. Feedback speist Evaluation, beeinflusst Prioritäten und leitet Retraining-Entscheidungen.\n\n\nOhne diese Validierungs-Loop kann selbst ein technisch performantes Modell sein Ziel verfehlen und echten Wert nicht liefern.\n\n\n## Häufige Fehler vermeiden\n\n\nSelbst mit strukturiertem MLOps-Ansatz treten manche Fallstricke regelmäßig auf. Sie verlangsamen Projekte und kompromittieren Production-Wert.\n\n\n### Zu viele Tools ohne klaren Rahmen\n\n\nSpezialisierte Tools nutzen scheint eine gute Idee: eins für Ingestion, ein anderes für Training, ein drittes für Monitoring, etc. Aber während der Tech-Stack wächst, explodiert Komplexität. Kosten steigen und Sichtbarkeit sinkt.\n\n\nMLOps basiert stattdessen auf **unified Vision**. Pipelines müssen auf kohärenten Bausteinen basieren, idealerweise gruppiert in integrierten Plattformen wie **GitLab**, die Fragmentierung begrenzen und End-to-End-Nachvollziehbarkeit garantieren.\n\n\n### Fehlende Business-Metriken\n\n\nEin Modell kann exzellente technische Scores erreichen und dennoch für die Organisation nutzlos sein. Fehlende Business-Indikatoren führen zum Deployment scheinbar performanter Modelle, die aber **von realen Anforderungen disconnected** sind. Business-Metriken-Tracking (detektierte Betrugs-Rate, Kunden-Zufriedenheit, eingesparte Processing-Zeit) muss klassische Machine-Learning-Metriken ergänzen.\n\n\n### Instabile Daten und Technical Debt\n\n\nOhne robuste Daten-Pipelines erben Modelle instabile oder nicht-repräsentative Sets. Kurzfristig schafft dies unvorhersagbare Ergebnisse. Langfristig **generiert Bugfix-Multiplikation Technical Debt**, die jede Evolution erschwert. MLOps erfordert Data-Engineering-Praktiken und kontinuierliche Supervision zur Aufrechterhaltung zuverlässiger Daten-Flows und Vermeidung dieses Schneeballeffekts.\n\n\n## MLOps vs DevOps: Unterschiede\n\n\nMLOps ist direkt von DevOps inspiriert. Beide Disziplinen teilen dieselbe Philosophie: Development und Operations annähern, Timelines reduzieren und Deployments durch Automatisierung zuverlässiger machen. Aber ihre Anwendungen divergieren, sobald es um Machine-Learning-Modelle geht.\n\n\n### Gemeinsamkeiten\n\n\nBeide Ansätze basieren auf demselben Toolset: **CI/CD-Pipelines, Monitoring und Versions-Management**. In beiden Fällen bleibt das Ziel identisch: **schnell zuverlässige Artefakte in Production liefern.**\n\n\n### Was sie unterscheidet\n\n\nDer fundamentale Unterschied kommt von der **Artefakt-Natur**. In DevOps deployen wir statische Applikationen. In MLOps deployen wir **Modelle aus sich bewegenden Daten**.\n\n\nDiese Spezifität führt zu fünf Haupt-Konsequenzen:\n\n\n* Notwendigkeit, **Daten und Modelle zu versionieren**, nicht nur Code;\n\n* Integration von **Business-Validationen** zusätzlich zu technischen Tests;\n\n* **Kontinuierliche Performance-Überwachung**, da Modelle über Zeit degradieren;\n\n* **Experimentelle Natur**: Derselbe Code kann verschiedene Ergebnisse produzieren abhängig von Daten und Parametern – systematisches Tracking jedes Experiments erforderlich;\n\n* **Iterative Hyperparameter-Optimierung** (Learning Rate, Architektur, etc.) muss exploriert, verglichen und versioniert werden zur Identifikation der besten Konfiguration.\n\n\n### MLOps-Position zu DataOps und ModelOps\n\n\nMLOps existiert nicht isoliert. Es liegt an der Kreuzung zweier anderer Disziplinen: **DataOps**, fokussiert auf Daten-Qualität und -Governance, und **ModelOps**, fokussiert auf Modell-Management und -Deployment.\n\n\nDurch Kombination dieser beiden Dimensionen übernimmt MLOps **den gesamten Zyklus: von Daten-Zuverlässigkeit bis Modell-Industrialisierung.**\n\n\n## Aktuelle Trends\n\n\nMLOps evolviert schnell, getrieben von KI-Industrialisierung und Entstehung neuer technischer und regulatorischer Constraints. Mehrere Trends strukturieren bereits die Praktiken der kommenden Jahre.\n\n\n### Serverless MLOps und Distributed MLOps\n\n\nDie wachsende **Serverless**-Adoption vereinfacht ML-Pipeline-Execution: Ressourcen passen sich automatisch an Load an und reduzieren Kosten und Komplexität. Parallel gewinnt **Distributed MLOps an der Edge** an Bedeutung, besonders in IoT und Embedded Applications. Modelle laufen direkt näher an Daten mit weniger Latenz und mehr Reaktivität.\n\n\n### Neue Governance- und Regulations-Anforderungen\n\n\nMit dem **[europäischen AI Act](https://www.europarl.europa.eu/topics/de/article/20230601STO93804/eu-gesetz-uber-kunstliche-intelligenz-erste-regelung-zur-ki)**, der 2024 in Kraft trat, wird Compliance zum strategischen Thema. Organisationen müssen Nachvollziehbarkeit, Erklärbarkeit und Robustheit ihrer Modelle beweisen. MLOps wird essenzieller Hebel zur Integration dieser Verpflichtungen heute – statt Blockaden bei Audits oder Produkt-Launches zu erleiden.\n\n\n**Deutsche Unternehmen profitieren von MLOps-Praktiken besonders für KI-Verordnung-Compliance:** Artikel 9 fordert Risiko-Management-Systeme mit dokumentierten Testverfahren. Artikel 17 verlangt umfassende technische Dokumentation inklusive Daten-Provenienz, Modell-Architektur und Validation-Ergebnissen. MLOps-Pipelines mit systematischem Versioning, automatisierten Tests und Audit-Logs erfüllen diese Anforderungen direkt und schaffen audit-fähige Nachweise.\n\n\n## Praktische Ressourcen und Tools\n\n\nMLOps bleibt nicht bei Konzepten. Es nimmt Form an in Workflows, Metriken und Governance-Regeln, die Teams in Projekten implementieren können.\n\n\n### Checklist für MLOps-Pipeline-Launch\n\n\nMLOps-Pipeline-Setup improvisiert sich nicht. Diese Checklist hilft beim Start unter guten Bedingungen:\n\n\n* Business-Ziele und Key Performance Indicators (KPIs) definieren;\n\n* Daten-Pipelines mit automatisierten Validierungs-Regeln aufbereiten;\n\n* Code, Daten und Modelle versionieren;\n\n* Training, Tests und Deployment in CI/CD-Chain integrieren;\n\n* Kontinuierliches Performance- und Drift-Monitoring vorsehen;\n\n* Jede Phase für Governance und Compliance dokumentieren und tracken.\n\n\n### Production-Metriken-Beispiele\n\n\nEin Modell lässt sich nicht ohne Indikatoren steuern. Zu überwachende Metriken decken technische und Business-Aspekte ab:\n\n\n* **Technische Aspekte**: Präzision, Recall, F1-Score, Latenz, Fehler-Rate;\n\n* **Business-Aspekte**: detektierte Betrugs-Rate, operative Kostenreduktion, Kunden-Zufriedenheit;\n\n* **Operative Aspekte**: Ressourcen-Verbrauch, Kosten pro Prediction, Energie-Footprint.\n\n\nTracking dieser Metriken ermöglicht Drift-Antizipation, Modell-Adjustierung und Mehrwert-Nachweis.\n\n\n## Fazit: MLOps-Bedeutung für KI-Industrialisierung\n\n\nZahlreiche Machine-Learning-Projekte scheitern nicht an Modellen selbst, sondern weil sie den Production-Schritt nicht schaffen. Zu oft bleiben sie auf Notebooks beschränkt, schwer zu maintainen und unfähig, sich an sich ändernde Daten anzupassen. MLOps wurde geschaffen, um diese Lücke zu schließen.\n\n\nDurch Automatisierung kritischer Schritte, Garantie von Daten- und Modell-Nachvollziehbarkeit und Integration kontinuierlichen Trackings transformiert es isolierte Experimente in **dauerhafte Assets**. Es geht nicht mehr nur darum, eine Idee zu testen, sondern ein System zu bauen, das über Zeit Wert schaffen kann.\n\n\nMLOps-Adoption ist nicht nur technischer Ansatz – es ist **strategischer Hebel**. Es beschleunigt den Übergang von Experimentierung zu Deployment, reduziert Iterations-Kosten und gibt Business die notwendige Confidence für KI-Nutzung in großem Maßstab.\n\n\nUm weiterzugehen, benötigen Organisationen Tools, die diesen integrierten Ansatz fördern. Plattformen wie **GitLab**, bereits im Kern von DevOps-Praktiken, bieten eine solide Basis zur Pipeline-Orchestrierung, Versions-Management und Team-Annäherung. MLOps wird dann nicht nur Methode, sondern vertrauenswürdige Infrastruktur zur KI-Industrialisierung.\n\n\n## GitLab als natürliche MLOps-Basis\n\n\nMLOps-Ansatz umzusetzen bedeutet nicht, Tools zu akkumulieren, sondern eine kohärente Chain zu schaffen, die Development, Daten und Production verbindet. GitLab bietet präzise diese Kontinuität: eine einheitliche Umgebung, in der Teams Code versionieren, CI/CD-Pipelines orchestrieren, Modelle monitoren und jede Phase des Software-Entwicklungs-Lifecycles dokumentieren können. Durch Integration von MLOps-Praktiken in eine DevOps-Teams bereits vertraute Plattform vermeiden Organisationen Komplexität fragmentierter Infrastruktur und beschleunigen Transformation ihrer Machine-Learning-Projekte in operative Lösungen.\n\n\n## MLOps FAQ\n\n\n### Was ist der Unterschied zwischen MLOps und DevOps?\n\n\nDevOps adressiert klassische Software-Entwicklung, wo das finale Artefakt eine statische Applikation ist. MLOps übernimmt diese Automatisierungs- und Kollaborations-Logik, adaptiert sie aber an Machine-Learning-Spezifika. Der Haupt-Unterschied: Ein Modell ist nicht nur Code, sondern auch Daten, die sich über Zeit ändern. MLOps fügt daher Dataset- und Modell-Versioning, Business-Validation und kontinuierliches Performance-Tracking hinzu.\n\n\n### Welche Tools für MLOps-Setup?\n\n\nEin vielfältiges Ökosystem existiert: CI/CD-Plattformen, Monitoring-Lösungen, Daten-Versioning-Tools oder Modell-Management-Tools. Die Herausforderung ist weniger, Bausteine zu akkumulieren, als ihre Integration zu garantieren. Plattformen wie GitLab, bereits für DevOps und DevSecOps adaptiert, bieten eine unified Basis, die Automatisierung, Kollaboration und Nachvollziehbarkeit in MLOps-Rahmen erleichtert.\n\n\n### Wie managt man Modell-Drift in Production?\n\n\nDrift tritt auf, wenn Production-Daten nicht mehr Training-Daten ähneln und Performance sinkt. MLOps sieht kontinuierliches Metriken-Monitoring vor, Alerts bei Abweichungen und manchmal automatische Retraining-Mechanismen. Der Schlüssel: kritische Schwellen und zu überwachende Business-Metriken von Anfang an definieren.\n\n\n### Wie misst man MLOps-Ansatz-Erfolg?\n\n\nErfolg beschränkt sich nicht auf technische Modell-Performance. Er misst sich auch an:\n\n\n* **Zeit-Reduktion** vom Experiment zur Production;\n\n* **Stabilität und Nachvollziehbarkeit** deployter Modelle;\n\n* **Realem Business-Impact** via Indikatoren wie Produktivitäts-Gewinn, Kosten-Senkung oder Customer-Experience-Verbesserung.\n\n\nEin erfolgreicher MLOps-Ansatz kombiniert daher operative Effizienz und messbare Wert-Schöpfung.\n\n\n> **[→ GitLab Ultimate und GitLab Duo Enterprise kostenlos testen.](https://about.gitlab.com/de-de/free-trial/devsecops/?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_x_trial_x_de_blog_de)**\n","ai-ml",{"featured":13,"template":14,"slug":15},false,"BlogPost","what-is-mlops",{"title":5,"description":17,"authors":18,"date":19,"body":10,"tags":20,"category":11,"heroImage":22},"MLOps verbindet Data Science und Engineering, automatisiert ML-Workflows und garantiert Reproduzierbarkeit, Governance und KI-Verordnung-Compliance.",[9],"2025-11-19",[21],"AI/ML","https://res.cloudinary.com/about-gitlab-com/image/upload/v1762517473/wo6vgpvabalmnzqgzulh.jpg","yml",null,{},true,"/de-de/blog/what-is-mlops","seo:\n  config:\n    noIndex: false\n  title: MLOps für systematisches ML-Lifecycle-Management\n  ogTitle: MLOps für systematisches ML-Lifecycle-Management\n  description: MLOps verbindet Data Science und Engineering, automatisiert ML-Workflows und garantiert Reproduzierbarkeit, Governance und KI-Verordnung-Compliance.\n  ogDescription: MLOps verbindet Data Science und Engineering, automatisiert ML-Workflows und garantiert Reproduzierbarkeit, Governance und KI-Verordnung-Compliance.\n  ogImage: https://res.cloudinary.com/about-gitlab-com/image/upload/v1762517473/wo6vgpvabalmnzqgzulh.jpg\ncontent:\n  title: 'MLOps – systematisches ML-Lifecycle-Management mit GitLab'\n  description: MLOps verbindet Data Science und Engineering, automatisiert ML-Workflows und garantiert Reproduzierbarkeit, Governance und KI-Verordnung-Compliance.\n  authors:\n    - GitLab Germany Team\n  date: 2025-11-19\n  body: |\n    **MLOps (Machine Learning Operations) umfasst alle Praktiken zum zuverlässigen, nachhaltigen Deployment, Monitoring und Maintenance von Machine-Learning-Modellen in Production.**\n\n\n    Ein Modell in Production zu bringen ist mehr als Training. Zwischen Datenaufbereitung, Deployment, Performance-Monitoring und Maintenance stoßen Teams auf Komplexität, die weit über reine Entwicklung hinausgeht. Resultat: verlängerte Timelines, explodierende Kosten, einbrechende Zuverlässigkeit.\n\n\n    **Kurz gesagt: MLOps verhält sich zu Machine Learning wie [DevOps](https://about.gitlab.com/de-de/topics/devops/) zu Software-Entwicklung – ein strukturierter Ansatz, der Workflows automatisiert, Kollaboration zwischen Data-Science- und Engineering-Teams verbessert und Modell-Kontinuität in Production garantiert.**\n\n\n    Durch Organisation des kompletten Modell-Lifecycles – von Konzeption bis kontinuierlicher Verbesserung – ermöglicht MLOps Organisationen, maximalen Wert aus KI-Projekten zu ziehen und diese langfristig zu etablieren.\n\n\n    > **[→ GitLab Ultimate und GitLab Duo Enterprise kostenlos testen.](https://about.gitlab.com/de-de/free-trial/devsecops/?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_x_trial_x_de_blog_de)**\n\n\n    ## MLOps: Definition und Rolle\n\n\n    Der Begriff **MLOps** kombiniert *Machine Learning und Operations*. Er bezeichnet alle Praktiken, Tools und Methoden zur Verwaltung des kompletten Machine-Learning-Modell-Lifecycles – von Konzeption bis Production-Betrieb.\n\n\n    Die zentrale Idee: **Zwei oft getrennte Welten verbinden** – **Data Scientists**, die Modelle entwickeln und trainieren, und **Engineering-Teams**, die diese deployen, monitoren und maintainen müssen. Durch diese Verbindung garantiert MLOps Kontinuität zwischen Experimentierung und realer Nutzung.\n\n\n    Die Rolle geht über reine Automatisierung hinaus. MLOps zielt darauf ab, Modell-Zuverlässigkeit über Zeit zu garantieren, Team-Kollaboration zu optimieren und Organisationen einen Rahmen zu geben für [industrielle, nachhaltige Machine-Learning-Nutzung](https://about.gitlab.com/de-de/the-source/ai/6-strategies-to-help-developers-accelerate-ai-adoption/).\n\n\n    ![MLOps-Konzept-Übersicht](https://res.cloudinary.com/about-gitlab-com/image/upload/v1762517964/cwgub5rfekc0wzcms012.png)\n\n\n    ## Warum ist MLOps unverzichtbar geworden?\n\n\n    Machine Learning hat sich weit über Forschung hinaus etabliert. Use Cases multiplizieren sich: Echtzeit-Betrugs-Detection, personalisierte Empfehlungen, Predictive Maintenance, generative Assistenten. Diese Modelle bleiben nicht im experimentellen Stadium – sie müssen in Production laufen, oft mit strikten Latenz-Anforderungen und unter starken Constraints.\n\n\n    Doch Schwierigkeiten treten schnell auf. **Deployment-Zyklen verlängern sich**, Modelle degradieren sobald Daten evolvieren, und Ergebnisse werden schwer auditierbar. Ohne Optimierung explodieren Infrastruktur-Kosten. Diese Bremsen sind Teams inzwischen bekannt.\n\n\n    MLOps bietet eine strukturierte Antwort auf diese Probleme. Es standardisiert **Deployment**, **Monitoring** und **Governance** von Modellen. Es ermöglicht auch Zukunftsvorbereitung: AutoML-Integration, generative Modell-Verwaltung, Compliance mit neuen Regelungen wie dem AI Act (Europäische KI-Verordnung).\n\n\n    **Für deutsche Unternehmen wird MLOps durch die KI-Verordnung der EU (AI Act) zur strategischen Notwendigkeit.** Die Verordnung tritt vollständig im August 2026 in Kraft. Artikel 9 fordert Risiko-Management-Systeme für Hochrisiko-KI. Artikel 17 verlangt technische Dokumentation aller ML-Modelle inklusive Training-Daten, Architektur und Validation. MLOps-Praktiken – systematisches Versioning, Audit-Trails, reproduzierbare Pipelines – erfüllen diese Anforderungen direkt.\n\n\n    Für viele Organisationen markiert MLOps-Adoption einen **Reife-Schritt**. Sie bedingt die Fähigkeit, Prototypen in dauerhafte Assets zu transformieren und KI in glaubwürdige Unternehmensstrategie einzubetten.\n\n\n    ## Welche Vorteile bietet MLOps?\n\n\n    MLOps ist keine reine Methode – es ist ein Kultur-Wandel, der Machine Learning **schneller, zuverlässiger und skalierbarer** in jeder Phase des Software-Entwicklungs-Lifecycles macht.\n\n\n    ### 1. Endlich alignte Teams\n\n\n    MLOps eliminiert Silos zwischen Data Scientists, Entwicklern und Ops-Engineers. Durch gemeinsame Pipelines und denselben Code visualisieren alle dieselben Metriken und sprechen dieselbe Sprache. Modelle gehen von R&D in Production ohne Brüche oder Informationsverlust.\n\n\n    ### 2. Friktionsfreier Production-Übergang\n\n\n    Dank CI/CD-Automatisierung laufen Training, Testing und Deployment ohne manuelle Intervention ab. Was Wochen dauerte, geschieht in Stunden – mit reproduzierbaren, kontrollierten Workflows über integrierte Plattformen wie GitLab.\n\n\n    ### 3. Nachvollziehbare, reproduzierbare Modelle\n\n\n    Jede Modell-Version, jedes Dataset und jeder Code wird archiviert. Bei Drift lässt sich ein Experiment wiederholen, die Ursache identifizieren oder eine stabile Version wiederherstellen. Diese Nachvollziehbarkeit transformiert Machine Learning in verifizierbaren, nachhaltigen Prozess.\n\n\n    **Diese systematische Reproduzierbarkeit erfüllt zentrale Anforderungen der KI-Verordnung Artikel 17 (technische Dokumentation) und ermöglicht deutschen Unternehmen audit-fähige Nachweise für Compliance.**\n\n\n    ### 4. Kontinuierliche Production-Überwachung\n\n\n    MLOps endet nicht beim Deployment. Performances werden kontinuierlich überwacht zur Drift-Erkennung. Tools wie Prometheus oder Grafana lassen sich in GitLab integrieren für Team-Alerting oder automatisches Retraining-Triggering.\n\n\n    ### 5. Governance by Design\n\n\n    Security-, Compliance- und Audit-Anforderungen sind Teil der Pipeline. Automatische Dokumentation, Access-Control und Audit-Logs garantieren Transparenz und regulatorische Compliance ohne Zusatzaufwand.\n\n\n    ## MLOps-Prinzipien und Best Practices\n\n\n    MLOps beschränkt sich nicht auf Konzepte. Es umfasst präzise Praktiken, die experimentelle Modelle in zuverlässige, nachhaltige Services transformieren. Diese Praktiken decken die gesamte Software-Chain ab: Development, Deployment, Monitoring und Governance.\n\n\n    ### Workflow-Automatisierung (CI/CD/CT)\n\n\n    Ein klassisches Machine-Learning-Projekt durchläuft mehrere repetitive Schritte:\n\n\n    1. Datenaufbereitung\n\n    2. Training\n\n    3. Testing\n\n    4. Packaging\n\n    5. Deployment\n\n\n    Manuell durchgeführt sind diese langsam und fragil. Automatisierung transformiert diesen Pfad in kontinuierliche, vorhersagbare Chain.\n\n\n    Mit **[CI/CD-Pipelines](https://about.gitlab.com/de-de/topics/ci-cd/cicd-pipeline/)** triggert jede Code- oder Daten-Änderung automatisch notwendige Schritte: Training, Validation, Deployment. Modelle gehen schneller in Production, mit weniger Fehlern.\n\n\n    **[GitLab CI/CD](https://about.gitlab.com/de-de/topics/ci-cd/)**, bereits breit in Software-Entwicklung adaptiert, bildet eine natürliche Basis zur Orchestrierung dieser MLOps-Pipelines.\n\n\n    **CT (Continuous Training)** ergänzt CI/CD durch Automatisierung des Modell-Retrainings. Sobald Drift erkannt wird oder Performance-Schwellen überschritten werden, kann automatisch ein neuer Training-Zyklus getriggert werden. Diese Praxis hält Modelle aligned mit Daten-Evolution ohne manuelle Intervention.\n\n\n    **Beispiel**: Diese minimalistische YAML-Datei illustriert eine typische ML-Pipeline, orchestriert über GitLab CI/CD:\n\n\n    * Daten-Ingestion und -Aufbereitung,\n\n    * Modell-Training und -Speicherung,\n\n    * Testing und Evaluation,\n\n    * Automatisiertes Production-Deployment.\n    ```yaml\n\n    image: python:3.9\n\n\n    before_script:\n      - pip install --no-cache-dir -r requirements.txt\n\n    stages:\n      - prepare\n      - train\n      - test\n      - deploy\n\n    prepare_data:\n      stage: prepare\n      script:\n        - python scripts/prepare_data.py\n      artifacts:\n        paths:\n          - data/processed/\n        expire_in: 7 days\n\n    train_model:\n      stage: train\n      script:\n        - python scripts/train.py --data data/processed/\n      artifacts:\n        paths:\n          - models/model.pkl\n        expire_in: 30 days\n\n    test_model:\n      stage: test\n      script:\n        - pytest tests/\n        - python scripts/evaluate.py models/model.pkl\n\n    deploy_model:\n      stage: deploy\n      script:\n        - bash scripts/deploy.sh models/model.pkl\n      when: on_success\n    ```\n\n\n    ### Versions-Management (Daten, Modelle, Code)\n\n\n    Ohne rigoroses Versions-Management ist es unmöglich zu wissen, auf welchen Daten ein Modell trainiert wurde oder zu einem früheren Zustand bei Drift zurückzukehren.\n\n\n    MLOps generalisiert **systematisches Versioning**. Jedes Dataset, jedes Modell und jede Pipeline wird archiviert und mit entsprechendem Code verknüpft. GitLab bringt diese [Versions-Management-Logik](https://about.gitlab.com/de-de/topics/version-control/) nativ mit – basierend auf [Git](https://about.gitlab.com/de-de/blog/what-is-git-the-ultimate-guide-to-gits-role-and-functionality/). Erweitert auf ML-Workflows garantiert es End-to-End-Nachvollziehbarkeit.\n\n\n    Hinweis: Die [GitLab Model Registry](https://docs.gitlab.com/user/project/ml/model_registry/) ermöglicht ML-Modell-Versionierung und -Katalogisierung neben Quellcode und schafft eine einzige Wahrheitsquelle für das gesamte Projekt.\n\n\n    ### Validation und Daten-/Modell-Qualität\n\n\n    Ein in Test-Umgebung performantes Modell kann in Production scheitern. Um diese Diskrepanz zu vermeiden, führt MLOps Validationen auf mehreren Ebenen ein.\n\n\n    * **Daten-Qualität**: Outlier-Detection, Konsistenz zwischen Training- und Validation-Sets, Vollständigkeits-Tracking.\n\n    * **Modell-Robustheit**: Performance-Tests, Bias-Verifikation, Evaluation anhand repräsentativer Business-Szenarien.\n\n\n    Diese in Pipelines integrierten Controls reduzieren das Risiko, fragile oder biased Modelle zu deployen.\n\n\n    ### Monitoring und Drift-Detection\n\n\n    Ein Modell ist niemals statisch. Daten evolvieren, Verhaltensweisen ändern sich, und Performance degradiert über Zeit.\n\n\n    MLOps integriert **kontinuierliches Monitoring** technischer und Business-Metriken. Es detektiert statistische Drifts, generiert Alerts und kann automatisches Retraining triggern. Diese Loop verlängert Modell-Lebensdauer und erhält Alignment mit operativen Anforderungen.\n\n\n    ### Data Engineering\n\n\n    Viele Projekte scheitern nicht an Modellen, sondern an **instabilen oder schlecht strukturierten Daten**. Daher ist Data Engineering essenzielle MLOps-Komponente.\n\n\n    Es basiert auf mehreren Praktiken: klare Daten-Contracts zwischen Produzenten und Nutzern definieren, Qualität und Verfügbarkeit von Daten-Flows kontinuierlich überwachen, und den richtigen Processing-Modus wählen – Batch für massive Volumen, Streaming für Realtime. Diese Fundamente garantieren, dass Modelle auf zuverlässigen, stabilen Daten basieren.\n\n\n    Eine Schlüsselkomponente ist der Feature Store, der von Modellen genutzte Features zentralisiert und versioniert. Er garantiert Konsistenz zwischen Training und Production, vermeidet Duplikation und beschleunigt Entwicklung neuer Modelle.\n\n\n    ### LLMOps für generative Modelle\n\n\n    Über traditionelle Modelle hinaus bringen generative Modelle neue Herausforderungen: evolvierende Prompts, hohe Inference-Kosten, komplexere Qualitäts-Evaluation.\n\n\n    **LLMOps** überträgt MLOps-Prinzipien auf diesen Kontext. Es umfasst Prompt-Versions-Management, User-Feedback-Integration und detailliertes Execution-Cost-Tracking. In manchen Umgebungen kann eine einzelne Anwendung Inference-Kosten von mehreren tausend Euro pro Tag generieren – Kontrolle dieser Ausgaben wird strategischer Imperativ.\n\n\n    ## MLOps-Projekt-Lifecycle\n\n\n    MLOps reduziert sich nicht auf Prinzipien. Es ist primär eine Organisationsweise für Machine-Learning-Projekt-Lifecycles – von Datenaufbereitung bis kontinuierlicher Production-Verbesserung. Jede Phase ist mit anderen verknüpft und gewinnt Effizienz durch strukturierten Ansatz.\n\n\n    ### Daten-Sammlung und -Aufbereitung\n\n\n    Daten sind Ausgangspunkt jedes Machine-Learning-Projekts. Dennoch sind sie auch eine der Haupt-Schwierigkeitsquellen. Mehrere Studien zeigen, dass Datenaufbereitung 50-80% der Data-Scientists-Zeit beanspruchen kann – abhängig von Quellen-Qualität und verfügbarem Automatisierungsgrad.\n\n\n    MLOps formalisiert diese Arbeit mit automatisierten Ingestion-Pipelines, Daten-Contracts zwischen Teams und systematischen Validationen (Vollständigkeit, Konsistenz, Anomalie-Detection). Diese Mechanismen reduzieren Fehler und sichern folgende Schritte ab.\n\n\n    Diese solide Basis optimiert Training-Schritte mit bestmöglichen Bedingungen.\n\n\n    ### Modell-Training\n\n\n    Sobald Daten bereit sind, geht es nicht nur um gute Metriken, sondern auch um **Reproduzierbarkeit** der Ergebnisse.\n\n\n    MLOps verstärkt diese Phase mit zwei Hebeln:\n\n\n    * **Systematisches Versioning** von Daten, Code und Modellen;\n\n    * **Experiment-Automatisierung** via Pipelines.\n\n\n    Jeder Versuch wird dokumentiert, jeder Parameter aufgezeichnet. Teams können Ergebnisse objektiv vergleichen und vielversprechendste Konfigurationen schnell identifizieren.\n\n\n    ### Production-Deployment\n\n\n    Ein in Development-Umgebung performantes Modell hat keinen Impact, solange es nicht genutzt wird. Production-Deployment ist daher Schlüsselschritt, aber oft der heikelste.\n\n\n    MLOps vereinfacht diesen Übergang durch Automatisierung: standardisiertes Packaging, integrierte Tests, reproduzierbares Deployment. Wo Production-Deployment mehrere Wochen Koordination benötigte, lässt es sich nun in Tagen realisieren.\n\n\n    Auch hier bietet **GitLab CI/CD** eine solide Basis zur Orchestrierung dieser Continuous-Deployments – mit Tools, die [DevOps-Teams](https://about.gitlab.com/de-de/topics/devops/build-a-devops-team/) bereits kennen.\n\n\n    ### Performance-Tracking und kontinuierliche Verbesserung\n\n\n    Sobald online, wird das Modell mit Live-Daten konfrontiert. Seine Performance evolviert, manchmal negativ.\n\n\n    Manche Teams gehen über reines Monitoring hinaus und implementieren **automatisiertes Retraining**, sobald Performance-Degradations-Schwellen erreicht werden. Diese kontinuierliche Verbesserungs-Loop garantiert, dass Modelle relevant bleiben und mit Business-Anforderungen aligned sind.\n\n\n    ## Rollen in MLOps-Projekten\n\n\n    MLOps-Projekte basieren nicht auf einem einzelnen Team, sondern auf Komplementarität mehrerer Profile. Jedes spielt eine Schlüsselrolle bei Konzeption, Deployment und Modell-Maintenance.\n\n\n    ### Data Scientists\n\n\n    Data Scientists bleiben Modell-Architekten. Ihre Rolle: **Daten explorieren**, Algorithmen konzipieren und verschiedene Ansätze testen. Sie definieren auch Metriken für Performance-Evaluation.\n\n\n    In MLOps-Ansätzen evolviert ihre Mission. Notebooks werden reproduzierbar, Scripts integrieren sich in Pipelines, und Modelle werden versioniert. Dieser Rahmen-Wechsel verhindert, dass Arbeiten im Prototyp-Stadium steckenbleiben, und erleichtert Production-Übergang.\n\n\n    ### Data Engineers und DevOps-Teams\n\n\n    Modelle haben nur Wert, wenn sie genutzt werden können. Data Engineers und DevOps-Teams spielen zentrale Rollen bei der Transformation von Experimenten in robuste Lösungen.\n\n\n    * **Data Engineers** bauen und maintainen Ingestion-Pipelines, garantieren Qualität und Verfügbarkeit von Daten-Flows und legen Fundamente für Daten-Governance.\n\n    * **DevOps-Teams** orchestrieren Deployments, automatisieren Tests und überwachen Umgebungen. Sie wenden auf Machine Learning Praktiken an, die Software-Entwicklung bereits transformiert haben: CI/CD, Monitoring, Access-Management.\n\n\n    Mit Plattformen wie **GitLab** haben diese Teams bereits bewährte Tools zur MLOps-Workflow-Integration ohne Tool- und Plattform-Multiplikation.\n\n\n    ### Koordination mit Business-Teams\n\n\n    Ein Modell wird nicht nur an Predictions-Präzision gemessen. Es muss auch sichtbaren Impact für die Organisation generieren. Hier kommen Business-Teams ins Spiel.\n\n\n    Sie definieren **Erfolgs-Key-Indicators**, bringen Feld-Expertise ein und validieren Modell-Relevanz in konkreten Kontexten. In MLOps-Ansätzen wird diese Kollaboration permanent statt punktuell. Feedback speist Evaluation, beeinflusst Prioritäten und leitet Retraining-Entscheidungen.\n\n\n    Ohne diese Validierungs-Loop kann selbst ein technisch performantes Modell sein Ziel verfehlen und echten Wert nicht liefern.\n\n\n    ## Häufige Fehler vermeiden\n\n\n    Selbst mit strukturiertem MLOps-Ansatz treten manche Fallstricke regelmäßig auf. Sie verlangsamen Projekte und kompromittieren Production-Wert.\n\n\n    ### Zu viele Tools ohne klaren Rahmen\n\n\n    Spezialisierte Tools nutzen scheint eine gute Idee: eins für Ingestion, ein anderes für Training, ein drittes für Monitoring, etc. Aber während der Tech-Stack wächst, explodiert Komplexität. Kosten steigen und Sichtbarkeit sinkt.\n\n\n    MLOps basiert stattdessen auf **unified Vision**. Pipelines müssen auf kohärenten Bausteinen basieren, idealerweise gruppiert in integrierten Plattformen wie **GitLab**, die Fragmentierung begrenzen und End-to-End-Nachvollziehbarkeit garantieren.\n\n\n    ### Fehlende Business-Metriken\n\n\n    Ein Modell kann exzellente technische Scores erreichen und dennoch für die Organisation nutzlos sein. Fehlende Business-Indikatoren führen zum Deployment scheinbar performanter Modelle, die aber **von realen Anforderungen disconnected** sind. Business-Metriken-Tracking (detektierte Betrugs-Rate, Kunden-Zufriedenheit, eingesparte Processing-Zeit) muss klassische Machine-Learning-Metriken ergänzen.\n\n\n    ### Instabile Daten und Technical Debt\n\n\n    Ohne robuste Daten-Pipelines erben Modelle instabile oder nicht-repräsentative Sets. Kurzfristig schafft dies unvorhersagbare Ergebnisse. Langfristig **generiert Bugfix-Multiplikation Technical Debt**, die jede Evolution erschwert. MLOps erfordert Data-Engineering-Praktiken und kontinuierliche Supervision zur Aufrechterhaltung zuverlässiger Daten-Flows und Vermeidung dieses Schneeballeffekts.\n\n\n    ## MLOps vs DevOps: Unterschiede\n\n\n    MLOps ist direkt von DevOps inspiriert. Beide Disziplinen teilen dieselbe Philosophie: Development und Operations annähern, Timelines reduzieren und Deployments durch Automatisierung zuverlässiger machen. Aber ihre Anwendungen divergieren, sobald es um Machine-Learning-Modelle geht.\n\n\n    ### Gemeinsamkeiten\n\n\n    Beide Ansätze basieren auf demselben Toolset: **CI/CD-Pipelines, Monitoring und Versions-Management**. In beiden Fällen bleibt das Ziel identisch: **schnell zuverlässige Artefakte in Production liefern.**\n\n\n    ### Was sie unterscheidet\n\n\n    Der fundamentale Unterschied kommt von der **Artefakt-Natur**. In DevOps deployen wir statische Applikationen. In MLOps deployen wir **Modelle aus sich bewegenden Daten**.\n\n\n    Diese Spezifität führt zu fünf Haupt-Konsequenzen:\n\n\n    * Notwendigkeit, **Daten und Modelle zu versionieren**, nicht nur Code;\n\n    * Integration von **Business-Validationen** zusätzlich zu technischen Tests;\n\n    * **Kontinuierliche Performance-Überwachung**, da Modelle über Zeit degradieren;\n\n    * **Experimentelle Natur**: Derselbe Code kann verschiedene Ergebnisse produzieren abhängig von Daten und Parametern – systematisches Tracking jedes Experiments erforderlich;\n\n    * **Iterative Hyperparameter-Optimierung** (Learning Rate, Architektur, etc.) muss exploriert, verglichen und versioniert werden zur Identifikation der besten Konfiguration.\n\n\n    ### MLOps-Position zu DataOps und ModelOps\n\n\n    MLOps existiert nicht isoliert. Es liegt an der Kreuzung zweier anderer Disziplinen: **DataOps**, fokussiert auf Daten-Qualität und -Governance, und **ModelOps**, fokussiert auf Modell-Management und -Deployment.\n\n\n    Durch Kombination dieser beiden Dimensionen übernimmt MLOps **den gesamten Zyklus: von Daten-Zuverlässigkeit bis Modell-Industrialisierung.**\n\n\n    ## Aktuelle Trends\n\n\n    MLOps evolviert schnell, getrieben von KI-Industrialisierung und Entstehung neuer technischer und regulatorischer Constraints. Mehrere Trends strukturieren bereits die Praktiken der kommenden Jahre.\n\n\n    ### Serverless MLOps und Distributed MLOps\n\n\n    Die wachsende **Serverless**-Adoption vereinfacht ML-Pipeline-Execution: Ressourcen passen sich automatisch an Load an und reduzieren Kosten und Komplexität. Parallel gewinnt **Distributed MLOps an der Edge** an Bedeutung, besonders in IoT und Embedded Applications. Modelle laufen direkt näher an Daten mit weniger Latenz und mehr Reaktivität.\n\n\n    ### Neue Governance- und Regulations-Anforderungen\n\n\n    Mit dem **[europäischen AI Act](https://www.europarl.europa.eu/topics/de/article/20230601STO93804/eu-gesetz-uber-kunstliche-intelligenz-erste-regelung-zur-ki)**, der 2024 in Kraft trat, wird Compliance zum strategischen Thema. Organisationen müssen Nachvollziehbarkeit, Erklärbarkeit und Robustheit ihrer Modelle beweisen. MLOps wird essenzieller Hebel zur Integration dieser Verpflichtungen heute – statt Blockaden bei Audits oder Produkt-Launches zu erleiden.\n\n\n    **Deutsche Unternehmen profitieren von MLOps-Praktiken besonders für KI-Verordnung-Compliance:** Artikel 9 fordert Risiko-Management-Systeme mit dokumentierten Testverfahren. Artikel 17 verlangt umfassende technische Dokumentation inklusive Daten-Provenienz, Modell-Architektur und Validation-Ergebnissen. MLOps-Pipelines mit systematischem Versioning, automatisierten Tests und Audit-Logs erfüllen diese Anforderungen direkt und schaffen audit-fähige Nachweise.\n\n\n    ## Praktische Ressourcen und Tools\n\n\n    MLOps bleibt nicht bei Konzepten. Es nimmt Form an in Workflows, Metriken und Governance-Regeln, die Teams in Projekten implementieren können.\n\n\n    ### Checklist für MLOps-Pipeline-Launch\n\n\n    MLOps-Pipeline-Setup improvisiert sich nicht. Diese Checklist hilft beim Start unter guten Bedingungen:\n\n\n    * Business-Ziele und Key Performance Indicators (KPIs) definieren;\n\n    * Daten-Pipelines mit automatisierten Validierungs-Regeln aufbereiten;\n\n    * Code, Daten und Modelle versionieren;\n\n    * Training, Tests und Deployment in CI/CD-Chain integrieren;\n\n    * Kontinuierliches Performance- und Drift-Monitoring vorsehen;\n\n    * Jede Phase für Governance und Compliance dokumentieren und tracken.\n\n\n    ### Production-Metriken-Beispiele\n\n\n    Ein Modell lässt sich nicht ohne Indikatoren steuern. Zu überwachende Metriken decken technische und Business-Aspekte ab:\n\n\n    * **Technische Aspekte**: Präzision, Recall, F1-Score, Latenz, Fehler-Rate;\n\n    * **Business-Aspekte**: detektierte Betrugs-Rate, operative Kostenreduktion, Kunden-Zufriedenheit;\n\n    * **Operative Aspekte**: Ressourcen-Verbrauch, Kosten pro Prediction, Energie-Footprint.\n\n\n    Tracking dieser Metriken ermöglicht Drift-Antizipation, Modell-Adjustierung und Mehrwert-Nachweis.\n\n\n    ## Fazit: MLOps-Bedeutung für KI-Industrialisierung\n\n\n    Zahlreiche Machine-Learning-Projekte scheitern nicht an Modellen selbst, sondern weil sie den Production-Schritt nicht schaffen. Zu oft bleiben sie auf Notebooks beschränkt, schwer zu maintainen und unfähig, sich an sich ändernde Daten anzupassen. MLOps wurde geschaffen, um diese Lücke zu schließen.\n\n\n    Durch Automatisierung kritischer Schritte, Garantie von Daten- und Modell-Nachvollziehbarkeit und Integration kontinuierlichen Trackings transformiert es isolierte Experimente in **dauerhafte Assets**. Es geht nicht mehr nur darum, eine Idee zu testen, sondern ein System zu bauen, das über Zeit Wert schaffen kann.\n\n\n    MLOps-Adoption ist nicht nur technischer Ansatz – es ist **strategischer Hebel**. Es beschleunigt den Übergang von Experimentierung zu Deployment, reduziert Iterations-Kosten und gibt Business die notwendige Confidence für KI-Nutzung in großem Maßstab.\n\n\n    Um weiterzugehen, benötigen Organisationen Tools, die diesen integrierten Ansatz fördern. Plattformen wie **GitLab**, bereits im Kern von DevOps-Praktiken, bieten eine solide Basis zur Pipeline-Orchestrierung, Versions-Management und Team-Annäherung. MLOps wird dann nicht nur Methode, sondern vertrauenswürdige Infrastruktur zur KI-Industrialisierung.\n\n\n    ## GitLab als natürliche MLOps-Basis\n\n\n    MLOps-Ansatz umzusetzen bedeutet nicht, Tools zu akkumulieren, sondern eine kohärente Chain zu schaffen, die Development, Daten und Production verbindet. GitLab bietet präzise diese Kontinuität: eine einheitliche Umgebung, in der Teams Code versionieren, CI/CD-Pipelines orchestrieren, Modelle monitoren und jede Phase des Software-Entwicklungs-Lifecycles dokumentieren können. Durch Integration von MLOps-Praktiken in eine DevOps-Teams bereits vertraute Plattform vermeiden Organisationen Komplexität fragmentierter Infrastruktur und beschleunigen Transformation ihrer Machine-Learning-Projekte in operative Lösungen.\n\n\n    ## MLOps FAQ\n\n\n    ### Was ist der Unterschied zwischen MLOps und DevOps?\n\n\n    DevOps adressiert klassische Software-Entwicklung, wo das finale Artefakt eine statische Applikation ist. MLOps übernimmt diese Automatisierungs- und Kollaborations-Logik, adaptiert sie aber an Machine-Learning-Spezifika. Der Haupt-Unterschied: Ein Modell ist nicht nur Code, sondern auch Daten, die sich über Zeit ändern. MLOps fügt daher Dataset- und Modell-Versioning, Business-Validation und kontinuierliches Performance-Tracking hinzu.\n\n\n    ### Welche Tools für MLOps-Setup?\n\n\n    Ein vielfältiges Ökosystem existiert: CI/CD-Plattformen, Monitoring-Lösungen, Daten-Versioning-Tools oder Modell-Management-Tools. Die Herausforderung ist weniger, Bausteine zu akkumulieren, als ihre Integration zu garantieren. Plattformen wie GitLab, bereits für DevOps und DevSecOps adaptiert, bieten eine unified Basis, die Automatisierung, Kollaboration und Nachvollziehbarkeit in MLOps-Rahmen erleichtert.\n\n\n    ### Wie managt man Modell-Drift in Production?\n\n\n    Drift tritt auf, wenn Production-Daten nicht mehr Training-Daten ähneln und Performance sinkt. MLOps sieht kontinuierliches Metriken-Monitoring vor, Alerts bei Abweichungen und manchmal automatische Retraining-Mechanismen. Der Schlüssel: kritische Schwellen und zu überwachende Business-Metriken von Anfang an definieren.\n\n\n    ### Wie misst man MLOps-Ansatz-Erfolg?\n\n\n    Erfolg beschränkt sich nicht auf technische Modell-Performance. Er misst sich auch an:\n\n\n    * **Zeit-Reduktion** vom Experiment zur Production;\n\n    * **Stabilität und Nachvollziehbarkeit** deployter Modelle;\n\n    * **Realem Business-Impact** via Indikatoren wie Produktivitäts-Gewinn, Kosten-Senkung oder Customer-Experience-Verbesserung.\n\n\n    Ein erfolgreicher MLOps-Ansatz kombiniert daher operative Effizienz und messbare Wert-Schöpfung.\n\n\n    > **[→ GitLab Ultimate und GitLab Duo Enterprise kostenlos testen.](https://about.gitlab.com/de-de/free-trial/devsecops/?utm_medium=blog&utm_source=blog&utm_campaign=eg_emea_x_trial_x_de_blog_de)**\n  tags:\n    - AI/ML\n  category: ai-ml\n  heroImage: https://res.cloudinary.com/about-gitlab-com/image/upload/v1762517473/wo6vgpvabalmnzqgzulh.jpg\nconfig:\n  featured: false\n  template: BlogPost\n  slug: what-is-mlops\n",{"config":30,"title":31,"ogTitle":31,"description":17,"ogDescription":17,"ogImage":22},{"noIndex":13},"MLOps für systematisches ML-Lifecycle-Management","de-de/blog/what-is-mlops",[34],"aiml",[21],"W-1E39LKnfT37pbdXpP2ioic7jo5-04YWGlxOr4wmDo",{"data":38},{"logo":39,"freeTrial":44,"sales":49,"login":54,"items":59,"search":369,"minimal":403,"duo":421,"switchNav":430,"pricingDeployment":441},{"config":40},{"href":41,"dataGaName":42,"dataGaLocation":43},"/de-de/","gitlab logo","header",{"text":45,"config":46},"Kostenlose Testversion anfordern",{"href":47,"dataGaName":48,"dataGaLocation":43},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/de-de&glm_content=default-saas-trial/","free trial",{"text":50,"config":51},"Vertrieb kontaktieren",{"href":52,"dataGaName":53,"dataGaLocation":43},"/de-de/sales/","sales",{"text":55,"config":56},"Anmelden",{"href":57,"dataGaName":58,"dataGaLocation":43},"https://gitlab.com/users/sign_in/","sign in",[60,87,184,189,290,350],{"text":61,"config":62,"cards":64},"Plattform",{"dataNavLevelOne":63},"platform",[65,71,79],{"title":61,"description":66,"link":67},"Die intelligente Orchestrierungsplattform für DevSecOps",{"text":68,"config":69},"Die Plattform erkunden",{"href":70,"dataGaName":63,"dataGaLocation":43},"/de-de/platform/",{"title":72,"description":73,"link":74},"GitLab Duo Agent Platform","Agentische KI für den gesamten Software-Lebenszyklus",{"text":75,"config":76},"Lerne GitLab Duo kennen",{"href":77,"dataGaName":78,"dataGaLocation":43},"/de-de/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":80,"description":81,"link":82},"Warum GitLab?","Erfahre, warum sich Unternehmen für GitLab entscheiden",{"text":83,"config":84},"Mehr erfahren",{"href":85,"dataGaName":86,"dataGaLocation":43},"/de-de/why-gitlab/","why gitlab",{"text":88,"left":26,"config":89,"link":91,"lists":95,"footer":166},"Produkt",{"dataNavLevelOne":90},"solutions",{"text":92,"config":93},"Alle Lösungen anzeigen",{"href":94,"dataGaName":90,"dataGaLocation":43},"/de-de/solutions/",[96,121,144],{"title":97,"description":98,"link":99,"items":104},"Automatisierung","CI/CD und Automatisierung zur Beschleunigung der Bereitstellung",{"config":100},{"icon":101,"href":102,"dataGaName":103,"dataGaLocation":43},"AutomatedCodeAlt","/de-de/solutions/delivery-automation/","automated software delivery",[105,109,112,117],{"text":106,"config":107},"CI/CD",{"href":108,"dataGaLocation":43,"dataGaName":106},"/de-de/solutions/continuous-integration/",{"text":72,"config":110},{"href":77,"dataGaLocation":43,"dataGaName":111},"gitlab duo agent platform - product menu",{"text":113,"config":114},"Quellcodeverwaltung",{"href":115,"dataGaLocation":43,"dataGaName":116},"/de-de/solutions/source-code-management/","Source Code Management",{"text":118,"config":119},"Automatische Softwarebereitstellung",{"href":102,"dataGaLocation":43,"dataGaName":120},"Automated software delivery",{"title":122,"description":123,"link":124,"items":129},"Sicherheit","Entwickle Code schneller ohne Abstriche bei der Sicherheit",{"config":125},{"href":126,"dataGaName":127,"dataGaLocation":43,"icon":128},"/de-de/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[130,134,139],{"text":131,"config":132},"Anwendungssicherheitstests",{"href":126,"dataGaName":133,"dataGaLocation":43},"Application security testing",{"text":135,"config":136},"Schutz der Software-Lieferkette",{"href":137,"dataGaLocation":43,"dataGaName":138},"/de-de/solutions/supply-chain/","Software supply chain security",{"text":140,"config":141},"Software-Compliance",{"href":142,"dataGaName":143,"dataGaLocation":43},"/de-de/solutions/software-compliance/","software compliance",{"title":145,"link":146,"items":151},"Auswertung",{"config":147},{"icon":148,"href":149,"dataGaName":150,"dataGaLocation":43},"DigitalTransformation","/de-de/solutions/visibility-measurement/","visibility and measurement",[152,156,161],{"text":153,"config":154},"Sichtbarkeit und Auswertung",{"href":149,"dataGaLocation":43,"dataGaName":155},"Visibility and Measurement",{"text":157,"config":158},"Wertstrommanagement",{"href":159,"dataGaLocation":43,"dataGaName":160},"/de-de/solutions/value-stream-management/","Value Stream Management",{"text":162,"config":163},"Analysen und Einblicke",{"href":164,"dataGaLocation":43,"dataGaName":165},"/de-de/solutions/analytics-and-insights/","Analytics and insights",{"title":167,"items":168},"GitLab für",[169,174,179],{"text":170,"config":171},"Enterprise",{"href":172,"dataGaLocation":43,"dataGaName":173},"/de-de/enterprise/","enterprise",{"text":175,"config":176},"Kleinunternehmen",{"href":177,"dataGaLocation":43,"dataGaName":178},"/de-de/small-business/","small business",{"text":180,"config":181},"Öffentlicher Sektor",{"href":182,"dataGaLocation":43,"dataGaName":183},"/de-de/solutions/public-sector/","public sector",{"text":185,"config":186},"Preise",{"href":187,"dataGaName":188,"dataGaLocation":43,"dataNavLevelOne":188},"/de-de/pricing/","pricing",{"text":190,"config":191,"link":193,"lists":197,"feature":277},"Ressourcen",{"dataNavLevelOne":192},"resources",{"text":194,"config":195},"Alle Ressourcen anzeigen",{"href":196,"dataGaName":192,"dataGaLocation":43},"/de-de/resources/",[198,231,249],{"title":199,"items":200},"Erste Schritte",[201,206,211,216,221,226],{"text":202,"config":203},"Installieren",{"href":204,"dataGaName":205,"dataGaLocation":43},"/de-de/install/","install",{"text":207,"config":208},"Kurzanleitungen",{"href":209,"dataGaName":210,"dataGaLocation":43},"/de-de/get-started/","quick setup checklists",{"text":212,"config":213},"Lernen",{"href":214,"dataGaLocation":43,"dataGaName":215},"https://university.gitlab.com/","learn",{"text":217,"config":218},"Produktdokumentation",{"href":219,"dataGaName":220,"dataGaLocation":43},"https://docs.gitlab.com/","product documentation",{"text":222,"config":223},"Best-Practice-Videos",{"href":224,"dataGaName":225,"dataGaLocation":43},"/de-de/getting-started-videos/","best practice videos",{"text":227,"config":228},"Integrationen",{"href":229,"dataGaName":230,"dataGaLocation":43},"/de-de/integrations/","integrations",{"title":232,"items":233},"Entdecken",[234,239,244],{"text":235,"config":236},"Kundenerfolge",{"href":237,"dataGaName":238,"dataGaLocation":43},"/de-de/customers/","customer success stories",{"text":240,"config":241},"Blog",{"href":242,"dataGaName":243,"dataGaLocation":43},"/de-de/blog/","blog",{"text":245,"config":246},"Remote",{"href":247,"dataGaName":248,"dataGaLocation":43},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":250,"items":251},"Vernetzen",[252,257,262,267,272],{"text":253,"config":254},"GitLab Services",{"href":255,"dataGaName":256,"dataGaLocation":43},"/de-de/services/","services",{"text":258,"config":259},"Community",{"href":260,"dataGaName":261,"dataGaLocation":43},"/community/","community",{"text":263,"config":264},"Forum",{"href":265,"dataGaName":266,"dataGaLocation":43},"https://forum.gitlab.com/","forum",{"text":268,"config":269},"Veranstaltungen",{"href":270,"dataGaName":271,"dataGaLocation":43},"/events/","events",{"text":273,"config":274},"Partner",{"href":275,"dataGaName":276,"dataGaLocation":43},"/de-de/partners/","partners",{"background":278,"textColor":279,"text":280,"image":281,"link":285},"#2f2a6b","#fff","Perspektiven für die Softwareentwicklung der Zukunft",{"altText":282,"config":283},"The Source Promo-Karte",{"src":284},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":286,"config":287},"Aktuelles",{"href":288,"dataGaName":289,"dataGaLocation":43},"/de-de/the-source/","the source",{"text":291,"config":292,"lists":294},"Unternehmen",{"dataNavLevelOne":293},"company",[295],{"items":296},[297,302,308,310,315,320,325,330,335,340,345],{"text":298,"config":299},"Über",{"href":300,"dataGaName":301,"dataGaLocation":43},"/de-de/company/","about",{"text":303,"config":304,"footerGa":307},"Karriere",{"href":305,"dataGaName":306,"dataGaLocation":43},"/jobs/","jobs",{"dataGaName":306},{"text":268,"config":309},{"href":270,"dataGaName":271,"dataGaLocation":43},{"text":311,"config":312},"Geschäftsführung",{"href":313,"dataGaName":314,"dataGaLocation":43},"/company/team/e-group/","leadership",{"text":316,"config":317},"Team",{"href":318,"dataGaName":319,"dataGaLocation":43},"/company/team/","team",{"text":321,"config":322},"Handbuch",{"href":323,"dataGaName":324,"dataGaLocation":43},"https://handbook.gitlab.com/","handbook",{"text":326,"config":327},"Investor Relations",{"href":328,"dataGaName":329,"dataGaLocation":43},"https://ir.gitlab.com/","investor relations",{"text":331,"config":332},"Trust Center",{"href":333,"dataGaName":334,"dataGaLocation":43},"/de-de/security/","trust center",{"text":336,"config":337},"AI Transparency Center",{"href":338,"dataGaName":339,"dataGaLocation":43},"/de-de/ai-transparency-center/","ai transparency center",{"text":341,"config":342},"Newsletter",{"href":343,"dataGaName":344,"dataGaLocation":43},"/company/contact/#contact-forms","newsletter",{"text":346,"config":347},"Presse",{"href":348,"dataGaName":349,"dataGaLocation":43},"/press/","press",{"text":351,"config":352,"lists":353},"Kontakt",{"dataNavLevelOne":293},[354],{"items":355},[356,359,364],{"text":50,"config":357},{"href":52,"dataGaName":358,"dataGaLocation":43},"talk to sales",{"text":360,"config":361},"Support-Portal",{"href":362,"dataGaName":363,"dataGaLocation":43},"https://support.gitlab.com","support portal",{"text":365,"config":366},"Kundenportal",{"href":367,"dataGaName":368,"dataGaLocation":43},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":370,"login":371,"suggestions":378},"Schließen",{"text":372,"link":373},"Um Repositorys und Projekte zu durchsuchen, melde dich an bei",{"text":374,"config":375},"gitlab.com",{"href":57,"dataGaName":376,"dataGaLocation":377},"search login","search",{"text":379,"default":380},"Vorschläge",[381,383,388,390,395,400],{"text":72,"config":382},{"href":77,"dataGaName":72,"dataGaLocation":377},{"text":384,"config":385},"Codevorschläge (KI)",{"href":386,"dataGaName":387,"dataGaLocation":377},"/de-de/solutions/code-suggestions/","Code Suggestions (AI)",{"text":106,"config":389},{"href":108,"dataGaName":106,"dataGaLocation":377},{"text":391,"config":392},"GitLab auf AWS",{"href":393,"dataGaName":394,"dataGaLocation":377},"/de-de/partners/technology-partners/aws/","GitLab on AWS",{"text":396,"config":397},"GitLab auf Google Cloud",{"href":398,"dataGaName":399,"dataGaLocation":377},"/de-de/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":80,"config":401},{"href":85,"dataGaName":402,"dataGaLocation":377},"Why GitLab?",{"freeTrial":404,"mobileIcon":409,"desktopIcon":414,"secondaryButton":417},{"text":405,"config":406},"Kostenlos testen",{"href":407,"dataGaName":48,"dataGaLocation":408},"https://gitlab.com/-/trials/new/","nav",{"altText":410,"config":411},"GitLab-Symbol",{"src":412,"dataGaName":413,"dataGaLocation":408},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":410,"config":415},{"src":416,"dataGaName":413,"dataGaLocation":408},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":199,"config":418},{"href":419,"dataGaName":420,"dataGaLocation":408},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/de-de/get-started/","get started",{"freeTrial":422,"mobileIcon":426,"desktopIcon":428},{"text":423,"config":424},"Mehr über GitLab Duo erfahren",{"href":77,"dataGaName":425,"dataGaLocation":408},"gitlab duo",{"altText":410,"config":427},{"src":412,"dataGaName":413,"dataGaLocation":408},{"altText":410,"config":429},{"src":416,"dataGaName":413,"dataGaLocation":408},{"button":431,"mobileIcon":436,"desktopIcon":438},{"text":432,"config":433},"/Option",{"href":434,"dataGaName":435,"dataGaLocation":408},"#contact","switch",{"altText":410,"config":437},{"src":412,"dataGaName":413,"dataGaLocation":408},{"altText":410,"config":439},{"src":440,"dataGaName":413,"dataGaLocation":408},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1773335277/ohhpiuoxoldryzrnhfrh.png",{"freeTrial":442,"mobileIcon":447,"desktopIcon":449},{"text":443,"config":444},"Zurück zur Preisübersicht",{"href":187,"dataGaName":445,"dataGaLocation":408,"icon":446},"back to pricing","GoBack",{"altText":410,"config":448},{"src":412,"dataGaName":413,"dataGaLocation":408},{"altText":410,"config":450},{"src":416,"dataGaName":413,"dataGaLocation":408},{"title":452,"button":453,"config":458},"Sieh dir an, wie agentische KI die Softwarebereitstellung transformiert",{"text":454,"config":455},"GitLab Transcend jetzt ansehen",{"href":456,"dataGaName":457,"dataGaLocation":43},"/de-de/events/transcend/virtual/","transcend event",{"layout":459,"icon":460,"disabled":26},"release","AiStar",{"data":462},{"text":463,"source":464,"edit":470,"contribute":475,"config":480,"items":485,"minimal":688},"Git ist eine Marke von Software Freedom Conservancy und unsere Verwendung von „GitLab“ erfolgt unter Lizenz.",{"text":465,"config":466},"Quelltext der Seite anzeigen",{"href":467,"dataGaName":468,"dataGaLocation":469},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":471,"config":472},"Diese Seite bearbeiten",{"href":473,"dataGaName":474,"dataGaLocation":469},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":476,"config":477},"Beteilige dich",{"href":478,"dataGaName":479,"dataGaLocation":469},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":481,"facebook":482,"youtube":483,"linkedin":484},"https://x.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[486,531,584,626,653],{"title":185,"links":487,"subMenu":502},[488,492,497],{"text":489,"config":490},"Tarife anzeigen",{"href":187,"dataGaName":491,"dataGaLocation":469},"view plans",{"text":493,"config":494},"Vorteile von Premium",{"href":495,"dataGaName":496,"dataGaLocation":469},"/de-de/pricing/premium/","why premium",{"text":498,"config":499},"Vorteile von Ultimate",{"href":500,"dataGaName":501,"dataGaLocation":469},"/de-de/pricing/ultimate/","why ultimate",[503],{"title":351,"links":504},[505,507,509,511,516,521,526],{"text":50,"config":506},{"href":52,"dataGaName":53,"dataGaLocation":469},{"text":360,"config":508},{"href":362,"dataGaName":363,"dataGaLocation":469},{"text":365,"config":510},{"href":367,"dataGaName":368,"dataGaLocation":469},{"text":512,"config":513},"Status",{"href":514,"dataGaName":515,"dataGaLocation":469},"https://status.gitlab.com/","status",{"text":517,"config":518},"Nutzungsbedingungen",{"href":519,"dataGaName":520,"dataGaLocation":469},"/terms/","terms of use",{"text":522,"config":523},"Datenschutzerklärung",{"href":524,"dataGaName":525,"dataGaLocation":469},"/de-de/privacy/","privacy statement",{"text":527,"config":528},"Cookie-Einstellungen",{"dataGaName":529,"dataGaLocation":469,"id":530,"isOneTrustButton":26},"cookie preferences","ot-sdk-btn",{"title":88,"links":532,"subMenu":541},[533,537],{"text":534,"config":535},"DevSecOps-Plattform",{"href":70,"dataGaName":536,"dataGaLocation":469},"devsecops platform",{"text":538,"config":539},"KI-unterstützte Entwicklung",{"href":77,"dataGaName":540,"dataGaLocation":469},"ai-assisted development",[542],{"title":543,"links":544},"Themen",[545,549,554,559,564,569,574,579],{"text":106,"config":546},{"href":547,"dataGaName":548,"dataGaLocation":469},"/de-de/topics/ci-cd/","cicd",{"text":550,"config":551},"GitOps",{"href":552,"dataGaName":553,"dataGaLocation":469},"/de-de/topics/gitops/","gitops",{"text":555,"config":556},"DevOps",{"href":557,"dataGaName":558,"dataGaLocation":469},"/de-de/topics/devops/","devops",{"text":560,"config":561},"Versionskontrolle",{"href":562,"dataGaName":563,"dataGaLocation":469},"/de-de/topics/version-control/","version control",{"text":565,"config":566},"DevSecOps",{"href":567,"dataGaName":568,"dataGaLocation":469},"/de-de/topics/devsecops/","devsecops",{"text":570,"config":571},"Cloud-nativ",{"href":572,"dataGaName":573,"dataGaLocation":469},"/de-de/topics/cloud-native/","cloud native",{"text":575,"config":576},"KI für das Programmieren",{"href":577,"dataGaName":578,"dataGaLocation":469},"/de-de/topics/devops/ai-for-coding/","ai for coding",{"text":580,"config":581},"Agentische KI",{"href":582,"dataGaName":583,"dataGaLocation":469},"/de-de/topics/agentic-ai/","agentic ai",{"title":585,"links":586},"Lösungen",[587,590,592,597,601,604,607,610,612,614,616,621],{"text":131,"config":588},{"href":126,"dataGaName":589,"dataGaLocation":469},"Application Security Testing",{"text":118,"config":591},{"href":102,"dataGaName":103,"dataGaLocation":469},{"text":593,"config":594},"Agile Entwicklung",{"href":595,"dataGaName":596,"dataGaLocation":469},"/de-de/solutions/agile-delivery/","agile delivery",{"text":598,"config":599},"SCM",{"href":115,"dataGaName":600,"dataGaLocation":469},"source code management",{"text":106,"config":602},{"href":108,"dataGaName":603,"dataGaLocation":469},"continuous integration & delivery",{"text":157,"config":605},{"href":159,"dataGaName":606,"dataGaLocation":469},"value stream management",{"text":550,"config":608},{"href":609,"dataGaName":553,"dataGaLocation":469},"/de-de/solutions/gitops/",{"text":170,"config":611},{"href":172,"dataGaName":173,"dataGaLocation":469},{"text":175,"config":613},{"href":177,"dataGaName":178,"dataGaLocation":469},{"text":180,"config":615},{"href":182,"dataGaName":183,"dataGaLocation":469},{"text":617,"config":618},"Bildungswesen",{"href":619,"dataGaName":620,"dataGaLocation":469},"/de-de/solutions/education/","education",{"text":622,"config":623},"Finanzdienstleistungen",{"href":624,"dataGaName":625,"dataGaLocation":469},"/de-de/solutions/finance/","financial services",{"title":190,"links":627},[628,630,632,634,637,639,641,643,645,647,649,651],{"text":202,"config":629},{"href":204,"dataGaName":205,"dataGaLocation":469},{"text":207,"config":631},{"href":209,"dataGaName":210,"dataGaLocation":469},{"text":212,"config":633},{"href":214,"dataGaName":215,"dataGaLocation":469},{"text":217,"config":635},{"href":219,"dataGaName":636,"dataGaLocation":469},"docs",{"text":240,"config":638},{"href":242,"dataGaName":243,"dataGaLocation":469},{"text":235,"config":640},{"href":237,"dataGaName":238,"dataGaLocation":469},{"text":245,"config":642},{"href":247,"dataGaName":248,"dataGaLocation":469},{"text":253,"config":644},{"href":255,"dataGaName":256,"dataGaLocation":469},{"text":258,"config":646},{"href":260,"dataGaName":261,"dataGaLocation":469},{"text":263,"config":648},{"href":265,"dataGaName":266,"dataGaLocation":469},{"text":268,"config":650},{"href":270,"dataGaName":271,"dataGaLocation":469},{"text":273,"config":652},{"href":275,"dataGaName":276,"dataGaLocation":469},{"title":291,"links":654},[655,657,659,661,663,665,667,672,677,679,681,683],{"text":298,"config":656},{"href":300,"dataGaName":293,"dataGaLocation":469},{"text":303,"config":658},{"href":305,"dataGaName":306,"dataGaLocation":469},{"text":311,"config":660},{"href":313,"dataGaName":314,"dataGaLocation":469},{"text":316,"config":662},{"href":318,"dataGaName":319,"dataGaLocation":469},{"text":321,"config":664},{"href":323,"dataGaName":324,"dataGaLocation":469},{"text":326,"config":666},{"href":328,"dataGaName":329,"dataGaLocation":469},{"text":668,"config":669},"Nachhaltigkeit",{"href":670,"dataGaName":671,"dataGaLocation":469},"/sustainability/","Sustainability",{"text":673,"config":674},"Vielfalt, Inklusion und Zugehörigkeit",{"href":675,"dataGaName":676,"dataGaLocation":469},"/de-de/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":331,"config":678},{"href":333,"dataGaName":334,"dataGaLocation":469},{"text":341,"config":680},{"href":343,"dataGaName":344,"dataGaLocation":469},{"text":346,"config":682},{"href":348,"dataGaName":349,"dataGaLocation":469},{"text":684,"config":685},"Transparenzerklärung zu moderner Sklaverei",{"href":686,"dataGaName":687,"dataGaLocation":469},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":689},[690,692,695],{"text":517,"config":691},{"href":519,"dataGaName":520,"dataGaLocation":469},{"text":693,"config":694},"Cookies",{"dataGaName":529,"dataGaLocation":469,"id":530,"isOneTrustButton":26},{"text":522,"config":696},{"href":524,"dataGaName":525,"dataGaLocation":469},[698],{"id":699,"title":700,"body":24,"config":701,"content":703,"description":24,"extension":23,"meta":707,"navigation":26,"path":708,"seo":709,"stem":710,"__hash__":711},"blogAuthors/en-us/blog/authors/gitlab-germany-team.yml","Gitlab Germany Team",{"template":702},"BlogAuthor",{"name":9,"config":704},{"headshot":705,"ctfId":706},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659488/Blog/Author%20Headshots/gitlab-logo-extra-whitespace.png","6tNquF8jQeRRRi8k3ZXpvS",{},"/en-us/blog/authors/gitlab-germany-team",{},"en-us/blog/authors/gitlab-germany-team","vGs9BT_ji6dORS29vl80DKX6mSputlQV2W7-4vW2hL8",[713,726,739],{"content":714,"config":724},{"title":715,"description":716,"authors":717,"heroImage":719,"date":720,"body":721,"category":11,"tags":722},"GitLab und Anthropic: Governed AI für die Unternehmensentwicklung","GitLab vertieft die Anthropic-Integration – KI-Governance, Auditierbarkeit und Cloud-Flexibilität für regulierte Unternehmen und den öffentlichen Sektor.",[718],"Stuart Moncada","https://res.cloudinary.com/about-gitlab-com/image/upload/v1776457632/llddiylsgwuze0u1rjks.png","2026-04-28","Für Führungskräfte in Unternehmen und im öffentlichen Sektor ist die Spannung\nvertraut: Softwareteams müssen mit KI schneller werden, während Sicherheits-,\nCompliance- und regulatorische Anforderungen weiter steigen. GitLab vertieft\ndie Integration mit Anthropic Claude, sodass Unternehmen Zugang zu neu\nveröffentlichten Claude-Modellen innerhalb von GitLabs intelligenter\nOrchestrierungsplattform erhalten – dort, wo Governance, Compliance und\nAuditierbarkeit bereits verankert sind.\n\nClaude treibt Funktionen der gesamten GitLab Duo Agent Platform als\nStandardmodell an – für Anwendungsfälle von Code-Generierung und -Review bis\nhin zu agentischem Chat und Vulnerability Resolution. Wer GitLab Duo bereits\nnutzt, hat bereits erlebt, wie Duo-Agenten Workflows über den gesamten Software\nDevelopment Lifecycle (SDLC) automatisieren.\n\nDas beschleunigt die Integration von Claudes Fähigkeiten in GitLab, erweitert\ndie Deployment-Optionen für Unternehmen und unterstreicht, was GitLab als\nPlattform für Softwareentwicklung grundlegend unterscheidet: Governance,\nCompliance und Auditierbarkeit, die in jede KI-Interaktion eingebaut sind.\n\n> \"GitLab Duo hat beschleunigt, wie unsere Teams Software planen, bauen und\n> ausliefern. Die Kombination aus Anthropics Claude und GitLabs Plattform\n> bedeutet, dass wir leistungsfähigere KI erhalten, ohne zu ändern, wie wir\n> arbeiten oder wie sie kontrolliert wird.\"\n>\n> – Mans Booijink, Operations Manager, Cube\n\n\n## Der entscheidende Unterschied: Governed AI\n\nBei GitLab sind Governance-Kontrollen und Auditing in den SDLC eingebaut. Wenn\nClaude über die GitLab Duo Agent Platform eine Codeänderung vorschlägt, durchläuft\ndieser Vorschlag denselben Merge-Request-Prozess, dieselben Freigaberegeln,\ndasselbe Security Scanning und denselben Audit-Trail wie jede andere Änderung.\nKI erhält keine Ausnahme von den bestehenden Kontrollen. Sie operiert innerhalb\ndieser Kontrollen.\n\nJe weiter GitLab in die agentische Softwareentwicklung vordringt – bei der KI\nklar definierte Aufgaben autonom übernimmt – desto wichtiger wird die\nGovernance-Schicht. Ein KI-Agent, der einen Merge Request öffnen, eine\nSchwachstelle beheben oder einen Service refaktorieren kann, muss auditierbar\nund zuordenbar sein und denselben Richtliniendurchsetzungen unterliegen wie ein\nmenschlicher Entwickler. Diese Anforderung ist eine architektonische Entscheidung,\ndie GitLab von Beginn an getroffen hat – und die umso bedeutsamer wird, je mehr\nVerantwortung KI-Agenten übernehmen.\n\n\n## Deployment-Flexibilität für Unternehmen\n\nDie Integration erweitert auch, wie Unternehmen über GitLab auf die neuesten\nClaude-Modelle zugreifen. Claude ist innerhalb von GitLab über Google Cloud\nVertex AI und AWS Bedrock verfügbar – Unternehmen können KI-Workloads über die\nHyperscaler-Commitments und Cloud-Governance-Frameworks leiten, die bereits\nbestehen. Kein separater Anbietervertrag, keine neuen Fragen zur Datenresidenz.\nDie bestehende GCP- oder AWS-Beziehung ist der Einstiegspunkt.\n\nGitLab ist jetzt auch im [Claude Marketplace](https://claude.com/platform/marketplace)\nverfügbar. Kunden können dort GitLab Credits erwerben und auf bestehende\nAnthropic-Ausgaben-Commitments anrechnen – KI-Ausgaben konsolidieren und die\nBeschaffung von GitLab neben Anthropic-Investitionen vereinfachen.\n\n\n## Auf dem Weg in eine agentische Zukunft\n\nGitLabs Vision für agentische Softwareentwicklung – bei der KI definierte\nAufgaben autonom über Planung, Coding, Testing, Security und Deployment hinweg\nübernimmt – setzt Modelle mit starkem Reasoning, Zuverlässigkeit und\nSicherheitseigenschaften voraus. Und sie setzt eine Plattform voraus, auf der\ndiese autonomen Aktionen vollständig kontrolliert werden.\n\nAgentische Workflows erfordern Modelle mit starkem Reasoning, Zuverlässigkeit\nund Sicherheitseigenschaften – Kriterien, die die Auswahl und Integration von\nKI-Modellpartnern bei GitLab leiten. GitLabs Governance-Framework stellt sicher,\ndass Unternehmen bei zunehmendem KI-Einsatz in der Entwicklung vollständige\nTransparenz und Kontrolle darüber behalten, was diese Agenten tun, wann sie es\ntun und wie Änderungen nachverfolgt werden.\n\n\n## Was das für GitLab-Kunden bedeutet\n\nWer GitLab Duo Agent Platform bereits einsetzt, erhält Zugang zu Claude-Modellen\nund tieferer KI-Unterstützung über den gesamten Software Development Lifecycle –\ninnerhalb des Governance-Frameworks, auf das bereits vertraut wird.\n\nWer KI-gestützte Softwareentwicklungsplattformen evaluiert, sollte nicht zwischen\nfortschrittlichen KI-Fähigkeiten und Unternehmenskontrolle wählen müssen. Diese\nstrategische Integration ist darauf ausgelegt, beides zu liefern.\n\n> Mehr über GitLab Duo Agent Platform erfahren?\n> [Demo anfragen oder kostenlose Testversion starten](https://about.gitlab.com/de-de/gitlab-duo-agent-platform/).\n",[21,723,276],"product",{"featured":26,"template":14,"slug":725},"gitlab-and-anthropic-governed-ai-for-enterprise-development",{"content":727,"config":737},{"title":728,"description":729,"authors":730,"heroImage":732,"date":733,"body":734,"category":11,"tags":735},"glab CLI: Strukturierter GitLab-Zugriff für KI-Agenten","Das GitLab CLI (glab) gibt KI-Agenten strukturierten Zugriff auf Projekte via MCP. Tutorial: Code-Reviews und Issue-Triage mit glab beschleunigen.",[731],"Kai Armstrong","https://res.cloudinary.com/about-gitlab-com/image/upload/v1776347152/unw3mzatkd5xyfbzcnni.png","2026-04-27","Wenn Teams GitLab Duo, Claude, Cursor und andere KI-Assistenten einsetzen,\nläuft ein wachsender Teil des Entwicklungs-Workflows über einen KI-Agenten,\nder im eigenen Auftrag handelt – Issues liest, Merge Requests prüft, Pipelines\nausführt und dabei hilft, schneller zu liefern. Die meisten Entwickler(innen) nutzen\n`glab` bereits vom Terminal aus, um mit GitLab zu interagieren. Beides zu\nkombinieren ist der naheliegende nächste Schritt.\n\nDas Problem: Ohne die richtigen Werkzeuge rät ein KI-Agent im Wesentlichen,\nwenn es um GitLab-Projekte geht. Er könnte die Details eines Issues\nhalluzinieren, den er nie gesehen hat, einen Merge Request auf Basis veralteter\nTrainingsdaten zusammenfassen statt anhand seines tatsächlichen Zustands – oder\nverlangen, dass Kontext manuell aus einem Browser-Tab kopiert und in ein\nChat-Fenster eingefügt wird, bevor überhaupt begonnen werden kann. Jede dieser\nUmgehungslösungen ist Reibung: Sie verlangsamt die Arbeit, eröffnet\nFehlermöglichkeiten und setzt eine harte Obergrenze dafür, was der Agent\ntatsächlich leisten kann. Das GitLab CLI (`glab`) ändert das, indem es Agenten\neine direkte, zuverlässige Schnittstelle zu Projekten gibt.\n\nMit `glab` ruft der Agent das Benötigte direkt von GitLab ab, handelt darauf\nund meldet das Ergebnis zurück – sodass weniger Zeit damit verbracht wird,\nInformationen weiterzugeben, und mehr Zeit für die eigentliche Arbeit bleibt.\n\nIn diesem Tutorial wird gezeigt, wie `glab` KI-Agenten strukturierten,\nzuverlässigen Zugriff auf GitLab-Projekte ermöglicht – und wie das einen\nschnelleren, leistungsfähigeren Entwicklungs-Workflow freischaltet.\n\n\n## KI-Agent über MCP mit GitLab verbinden\n\nDer direkteste Weg, KI-Workflows deutlich leistungsfähiger zu machen, besteht\ndarin, dem KI-Agenten nativen Zugriff auf `glab` über das Model Context\nProtocol ([MCP](https://about.gitlab.com/topics/ai/model-context-protocol/))\nzu geben.\n\nMCP ist ein offener Standard, der KI-Werkzeugen ermöglicht, externe Fähigkeiten\nzur Laufzeit zu entdecken und zu nutzen. Nach der Verbindung kann der\nKI-Assistent Issues lesen, Merge Requests kommentieren, Pipeline-Status prüfen\nund zurück in GitLab schreiben – ohne etwas aus der UI zu kopieren oder auch\nnur einen einzigen API-Aufruf selbst zu schreiben.\n\nEinstieg mit:\n\n```shell\n# MCP-Server von glab starten\nglab mcp serve\n```\n\nSobald der MCP-Client konfiguriert ist, kann die KI Fragen wie *„Was ist der\nStatus meiner offenen MRs?\"* oder *„Gibt es fehlgeschlagene Pipelines auf\nmain?\"* beantworten, indem sie GitLab direkt abfragt – nicht durch Scraping der\nWeb-UI, nicht durch veraltete Trainingsdaten. Die\n[vollständige Setup-Dokumentation](https://docs.gitlab.com/cli/) enthält\nKonfigurationsschritte für Claude Code, Cursor und andere Editoren.\n\nEin wichtiges Detail: `glab` fügt automatisch `--output json` hinzu, wenn es\nüber MCP aufgerufen wird – für jeden Befehl, der das unterstützt. Der Agent\nerhält saubere, strukturierte Daten, ohne dass über Ausgabeformate nachgedacht\nwerden muss. Und da `glab` das offizielle MCP SDK verwendet, bleibt es\nkompatibel, wenn sich das Protokoll weiterentwickelt.\n\nWir haben bewusst entschieden, *welche* Befehle über MCP zugänglich sind.\nBefehle, die interaktive Terminalausgabe erfordern, sind absichtlich\nausgeschlossen – der Agent bleibt nie in einem Wartezustand für Eingaben, die\nnie kommen. Was zugänglich ist, funktioniert zuverlässig im Agenten-Kontext.\n\n\n## KI am Code-Review beteiligen\n\nDie meisten Entwickler(innen) haben einen Rückstand an MRs, die auf Review warten.\nDas ist einer der zeitintensivsten Teile der Arbeit – und einer der besten\nAnsatzpunkte für KI. Mit `glab` beobachtet der Agent die Review-Queue nicht\nnur, sondern arbeitet sie gemeinsam durch.\n\n### Genau sehen, was noch offen ist\n\nEinstieg mit:\n\n```shell\nglab mr view 2677 --comments --unresolved --output json\n```\n\nDieser Befehl gibt den vollständigen MR zurück: Metadaten, Beschreibung und\njede ungelöste Diskussion als einzelnes strukturiertes JSON-Payload. Das gibt\nder KI alles, was sie braucht: welche Threads offen sind, was der Reviewer\nangefragt hat und in welchem Kontext. Kein Tab-Wechsel, kein manuelles Kopieren\neinzelner Kommentare.\n\n```json\n{\n  \"id\": 2677,\n  \"title\": \"feat: add OAuth2 support\",\n  \"state\": \"opened\",\n  \"author\": { \"username\": \"jdwick\" },\n  \"labels\": [\"backend\", \"needs-review\"],\n  \"blocking_discussions_resolved\": false,\n  \"discussions\": [\n    {\n      \"id\": \"3107030349\",\n      \"resolved\": false,\n      \"notes\": [\n        {\n          \"author\": { \"username\": \"dmurphy\" },\n          \"body\": \"This error handling will swallow panics — consider wrapping with recover()\",\n          \"created_at\": \"2026-03-14T09:23:11.000Z\"\n        }\n      ]\n    },\n    {\n      \"id\": \"3107030412\",\n      \"resolved\": false,\n      \"notes\": [\n        {\n          \"author\": { \"username\": \"sreeves\" },\n          \"body\": \"Token refresh logic needs a test for the expired token case\",\n          \"created_at\": \"2026-03-14T10:05:44.000Z\"\n        }\n      ]\n    }\n  ]\n}\n```\n\nStatt jeden Thread selbst durchzulesen, lässt sich der Agent fragen:\n*„Was muss ich in MR 2677 noch beheben?\"* – und erhält eine priorisierte\nZusammenfassung mit Änderungsvorschlägen. Das alles aus einem einzigen Befehl.\n\n### Den Kreislauf programmatisch schließen\n\nSobald der KI geholfen hat, das Feedback zu adressieren, kann sie Diskussionen\nauflösen:\n\n```shell\n# Alle Diskussionen auflisten – strukturiert, bereit für den Agenten\nglab mr note list 456 --output json\n\n# Diskussion auflösen, sobald das Feedback adressiert wurde\nglab mr note resolve 456 3107030349\n\n# Wieder öffnen, wenn etwas erneut geprüft werden muss\nglab mr note reopen 456 3107030349\n```\n\n```json\n[\n  {\n    \"id\": 3107030349,\n    \"body\": \"This error handling will swallow panics — consider wrapping with recover()\",\n    \"author\": { \"username\": \"dmurphy\" },\n    \"resolved\": false,\n    \"resolvable\": true\n  },\n  {\n    \"id\": 3107030412,\n    \"body\": \"Token refresh logic needs a test for the expired token case\",\n    \"author\": { \"username\": \"sreeves\" },\n    \"resolved\": false,\n    \"resolvable\": true\n  }\n]\n```\n\nNote-IDs sind direkt in der GitLab-UI und der API sichtbar – kein zusätzlicher\nLookup nötig. Der Agent kann die vollständige Liste durcharbeiten, jeden Fix\nprüfen und dabei auflösen.\n\n\n## Mit der KI effektiver über Code sprechen\n\nAuch ohne laufenden MCP-Server gibt es eine einfachere Umstellung, die einen\ngroßen Unterschied macht: `glab` einsetzen, um der KI bessere Informationen zu\nliefern.\n\nBeim letzten Mal, als ein KI-Assistent bei der Issue-Triage oder beim Debuggen\neiner fehlgeschlagenen Pipeline geholfen hat, wurde wahrscheinlich etwas Text\naus der GitLab-UI kopiert und in den Chat eingefügt. Das ist es, womit der\nAgent tatsächlich arbeitet:\n\n```text\nopen issues: 12 • milestone: 17.10 • label: bug, needs-triage ...\n```\n\nIm Vergleich dazu, was er mit `glab` erhält:\n\n```json\n[\n  {\n    \"iid\": 902,\n    \"title\": \"Pipeline fails on merge to main\",\n    \"labels\": [\"bug\", \"needs-triage\"],\n    \"milestone\": { \"title\": \"17.10\" },\n    \"assignees\": []\n  },\n  ...\n]\n```\n\nStrukturiert, typisiert, vollständig – keine Mehrdeutigkeit, kein\nInterpretationsaufwand beim Parsen. Das ist der Unterschied zwischen einem\nAgenten, der handeln kann, und einem, der Rückfragen stellen muss.\n\nMit dem MCP-Server passiert das automatisch: `glab` fügt `--output json` für\njeden Befehl hinzu, der das unterstützt. Beim direkten Arbeiten im Terminal\neinfach das Flag selbst ergänzen:\n\n```shell\n# Offene Issues für Triage abrufen\nglab issue list --label \"needs-triage\" --output json\n\n# Pipeline-Status prüfen\nglab ci status --output json\n\n# Vollständige MR-Details abrufen\nglab mr view 456 --output json\n```\n\nDie JSON-Ausgabe wurde in letzten Releases erheblich erweitert. Sie deckt jetzt\nCI-Status, Milestones, Labels, Releases, Schedules, Cluster-Agenten, Work\nItems, MR-Genehmiger, Repository-Mitwirkende und mehr ab. Was `glab` abrufen\nkann, kann die KI sauber verarbeiten.\n\n### Ein echter Workflow\n\n```shell\n$ glab issue list --label \"needs-triage\" --milestone \"17.10\" \\\n--output json\n```\n\n```text\nAgent: I found 2 unassigned bugs in the 17.10 milestone that need triage:\n1. #902 — Pipeline fails on merge to main (opened 5 days ago)\n2. #903 — Auth token not refreshing on expiry (opened 4 days ago)\nBoth are unassigned. Want me to draft triage notes and suggest assignees based on recent commit history?\n```\n\n\n## Der Agent ist keineswegs auf eingebaute Befehle beschränkt\n\nDie nativen Befehle von `glab` decken die gängigsten Workflows ab – aber der\nAgent ist nicht darauf beschränkt. Über `glab api` hat er authentifizierten\nZugriff auf die vollständige GitLab REST- und GraphQL-API-Oberfläche, mit\nderselben Session, ohne zusätzliche Credentials oder Konfiguration.\n\nDas ist ein wesentlicher Unterschied. Die meisten CLI-Werkzeuge beschränken\nsich auf das, was ihre Befehle abbilden. Mit `glab` gilt: Wenn GitLabs API es\nunterstützt, kann der Agent es tun – immer aus einem vertrauenswürdigen,\nauthentifizierten Kontext heraus.\n\nEin praktisches Beispiel: nur die Liste der geänderten Dateien in einem MR\nabrufen, bevor entschieden wird, welche Diffs vollständig geladen werden:\n\n```shell\n# Geänderte Dateipfade abrufen – leichtgewichtig, noch kein Diff-Inhalt\nglab api \"/projects/$CI_PROJECT_ID/merge_requests/$CI_MERGE_REQUEST_IID/diffs?per_page=100\" \\\n| jq '.[].new_path'\n\n# Dann nur die spezifische Datei laden, die der Agent benötigt\nglab api \"/projects/$CI_PROJECT_ID/merge_requests/$CI_MERGE_REQUEST_IID/diffs?per_page=100\" \\\n| jq '.[] | select(.new_path == \"path/to/file.go\")'\n```\n\n```text\n\"internal/auth/token.go\"\n\"internal/auth/token_test.go\"\n\"internal/oauth/refresh.go\"\n```\n\nFür alles, was die REST API nicht abdeckt (Epics, bestimmte Work-Item-Abfragen,\nkomplexe projektübergreifende Daten), bietet `glab api graphql` die vollständige\nGraphQL-Schnittstelle:\n\n```shell\nglab api graphql -f query='\n{\n  project(fullPath: \"gitlab-org/gitlab\") {\n    mergeRequest(iid: \"12345\") {\n      title\n      reviewers { nodes { username } }\n    }\n  }\n}'\n```\n\n```json\n{\n  \"data\": {\n    \"project\": {\n      \"mergeRequest\": {\n        \"title\": \"feat: add OAuth2 support\",\n        \"reviewers\": {\n          \"nodes\": [\n            { \"username\": \"dmurphy\" },\n            { \"username\": \"sreeves\" }\n          ]\n        }\n      }\n    }\n  }\n}\n```\n\nEin einziger, authentifizierter Einstiegspunkt zu allem, was GitLab\nbereitstellt – ohne Token-Jonglieren, separate API-Clients oder\nKonfigurationsaufwand.\n\n\n## Was als Nächstes kommt – und Feedback\n\nZwei Verbesserungen, an denen aktiv gearbeitet wird, werden `glab` für\nAgenten-Workflows noch nützlicher machen:\n\n**Auf Agenten abgestimmter Hilfetext.** Heute ist die `--help`-Ausgabe für\nMenschen am Terminal geschrieben. Sie wird aktualisiert, um für jeden\ninteraktiven Befehl die nicht-interaktive Alternative anzuzeigen, Befehle mit\n`--output json`-Unterstützung zu kennzeichnen und Hilfe generell zu einer\nnützlichen Ressource für Agenten zu machen, die Fähigkeiten zur Laufzeit\nentdecken – nicht nur für Menschen.\n\n**Besser maschinenlesbare Fehlermeldungen.** Wenn heute etwas schiefläuft,\nerhalten Agenten dieselben menschenlesbaren Fehlermeldungen wie\nTerminal-Nutzende. Das wird geändert: Fehler im JSON-Modus geben strukturierte\nAusgaben zurück, die dem Agenten die Informationen liefern, die er braucht, um\nFehler sauber zu behandeln, intelligent zu wiederholen oder den richtigen\nKontext zurückzugeben.\n\nBeide Punkte sind in aktiver Entwicklung. Wer `glab` bereits mit einem\nKI-Werkzeug einsetzt, ist genau die Zielgruppe, deren Erfahrungen uns\ninteressieren.\n\n* **Welche Reibungspunkte gibt es?** Befehle, die sich in Agenten-Kontexten\n  nicht gut verhalten, Fehlermeldungen ohne Handlungsanleitung, Lücken in der\n  JSON-Ausgabe. Feedback ist willkommen.\n\n* **Welche Workflows wurden erschlossen?** Reale Nutzungsmuster helfen dabei,\n  Prioritäten für die weitere Entwicklung zu setzen.\n\nDie Diskussion findet im\n[Feedback-Issue](https://gitlab.com/gitlab-org/cli/-/issues/8177) statt –\ndort wird die Roadmap für Agenten-Freundlichkeit gestaltet, und Beiträge haben\ndort den direktesten Einfluss. Wer eine spezifische Lücke gefunden hat,\nkann ein [Issue öffnen](https://gitlab.com/gitlab-org/cli/-/issues/new). Wer\neinen Fix im Sinn hat: Beiträge sind willkommen. Details unter\n[CONTRIBUTING.md](https://gitlab.com/gitlab-org/cli/-/blob/main/CONTRIBUTING.md).\n\nDas GitLab CLI stand schon immer dafür, Entwickler(inne)n mehr Kontrolle über ihren\nWorkflow zu geben. Da KI ein immer größerer Teil der täglichen Arbeit wird,\nbedeutet das, `glab` zur bestmöglichen Schnittstelle zwischen KI-Werkzeugen\nund GitLab-Projekten zu machen. Wir stehen am Anfang – und freuen uns darauf,\nden nächsten Teil gemeinsam zu gestalten.\n",[21,723,736],"tutorial",{"featured":26,"template":14,"slug":738},"give-your-ai-agent-direct-structured-gitlab-access-with-glab-cli",{"content":740,"config":748},{"title":741,"description":742,"authors":743,"heroImage":732,"date":745,"body":746,"category":11,"tags":747},"GitHubs neue Copilot-Richtlinie: Was regulierte Unternehmen jetzt prüfen müssen","Warum GitLabs Datenverwaltungsansatz strukturell anders ist – und was GitHubs neue Copilot-Richtlinie für regulierte Unternehmen bedeutet.",[744],"Allie Holland","2026-04-20","GitHub hat kürzlich angekündigt, wie Interaktionsdaten von Copilot-Nutzenden\nkünftig verwendet werden. Ab dem 24. April 2026 werden Daten aus Copilot Free,\nPro und Pro+ standardmäßig zum Training von KI-Modellen genutzt, sofern\nNutzende nicht aktiv widersprechen. Betroffen sind Eingaben, Ausgaben,\nCode-Snippets und zugehöriger Kontext. Copilot Business und Enterprise sind\naufgrund bestehender Vertragskonditionen ausgenommen.\n\nFür Unternehmen in regulierten Branchen wirft diese Änderung Fragen auf, die\nüber individuelle Entwicklerpräferenzen weit hinausgehen. Sie zwingt zu einer\ngrundlegenden Prüfung, die Führungskräfte aus Engineering und IT-Sicherheit\njedem KI-Anbieter in ihrem Stack stellen sollten: Werden unsere Daten für\nKI-Training verwendet?\n\nGitLabs Antwort lautet: Nein. GitLab trainiert KI-Modelle nicht mit\nKundendaten – auf keiner Preisstufe. KI-Anbieter sind vertraglich verpflichtet,\nKundeneingaben und -ausgaben nicht für eigene Zwecke zu verwenden. Das\n[GitLab AI Transparency Center](https://about.gitlab.com/de-de/ai-transparency-center/)\nmacht diese Zusage prüfbar. Eine zentrale Dokumentation zeigt, welche Modelle\nwelche Funktionen betreiben, wie Daten verarbeitet werden, welche\nUnterauftragsverarbeiter beteiligt sind und wie lange Daten gespeichert werden.\nDas AI Transparency Center dokumentiert außerdem den Compliance-Status jeder\nFunktion – einschließlich der Bestätigung, dass GitLabs aktuelle KI-Funktionen\nnicht als Hochrisikosysteme im Sinne des EU AI Act eingestuft werden. Diesen\nStandard hat GitLab-CEO Bill Staples\n[wiederholt bekräftigt](https://www.linkedin.com/posts/williamstaples_gitlab-1810-agentic-ai-now-open-to-even-activity-7443280763715985408-aHxf)\n– er spiegelt GitLabs Unternehmensmission und das\n[Trust Center](https://trust.gitlab.com/) wider.\n\n\n## Was die Richtlinienänderung tatsächlich bedeutet\n\nGitHub gibt zudem an, dass die Daten mit verbundenen Unternehmen – darunter\nMicrosoft – für KI-Entwicklungszwecke geteilt werden können.\n\nQuellcode zählt häufig zum sensibelsten geistigen Eigentum eines Unternehmens.\nEr kann proprietäre Geschäftslogik abbilden, interne Systemarchitekturen\noffenlegen oder Datenflüsse berühren, die strengen Aufbewahrungs- und\nZugriffsrichtlinien unterliegen. Wenn dieser Code einen KI-Assistenten\ndurchläuft und zum Training von Modellen verwendet wird, die auch Wettbewerbern\ndienen, werden Anbieterdatenpraktiken zu einem konkreten IP-Risiko. Regulierte\nBranchen weltweit – von Finanzdienstleistungen über Gesundheitswesen bis zum\nöffentlichen Sektor – operieren unter Compliance-Anforderungen, die genau\ndiesen Punkt adressieren: dokumentierte, prüfbare Kontrolle über den Umgang\nDritter mit sensiblen Daten.\n\nEine Anbieterrichtlinie, die Datenstandardeinstellungen ändert, ein aktives\nWiderspruchsrecht erfordert und je nach Vertragsstufe unterschiedliche\nSchutzstandards bietet, erzeugt genau die Art unkontrollierbarer Variablen,\ndie Compliance-Teams nicht akzeptieren können. Der\n[Digital Operational Resilience Act (DORA)](https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng)\n– seit Januar 2025 für europäische Finanzinstitute verbindlich – macht dies\nexplizit: Wesentliche Änderungen an IT-Drittanbieterbeziehungen erfordern\ndokumentierte Bewertung und Nachverfolgung.\n\n\n## Was regulierte Unternehmen von KI-Anbietern tatsächlich benötigen\n\nRegulierte Unternehmen diskutieren nicht mehr grundsätzlich, ob KI in\nEntwicklungs-Workflows eingesetzt werden soll. Der Fokus liegt darauf, dies so\nzu tun, dass es gegenüber Aufsichtsbehörden, Vorständen und Kunden vertretbar\nist. Dabei sind branchenübergreifend konsistente Anforderungen sichtbar\ngeworden.\n\n**Vertragliche Klarheit.** Regulierte Unternehmen benötigen spezifische,\ndokumentierte und bedingungslose Zusagen darüber, was mit ihren Daten geschieht\n– nicht etwas, das je nach Vertragsstufe variiert oder eine Handlung vor einem\nStichtag erfordert.\n\n**Prüfbarkeit.** IT-Risikomanagement-Frameworks verlangen von Unternehmen, die\neingesetzten KI-Systeme zu verstehen und zu validieren: die Trainingsdaten\nhinter diesen Modellen und die beteiligten Drittparteien. Anbieter, die diese\nFragen nicht beantworten können, erzeugen Dokumentationsrisiken für die\nOrganisationen, die sich auf sie stützen.\n\n**Trennung von Anbieterinteressen.** Wenn ein KI-Anbieter Modelle auf Basis\nvon Kundennutzungsdaten trainiert, werden Code und Workflows zu Eingaben für\nein System, das auch Wettbewerbern dient. Für Institutionen mit proprietären\nHandelsalgorithmen, Underwriting-Modellen oder Betrugserkennungssystemen ist\ndas ein konkretes IP-Risiko.\n\n\n## GitLabs Position zur KI-Datenverwaltung\n\nGitLab verwendet Kundendaten nicht zum Training von KI-Modellen. Diese Zusage\ngilt auf jeder Preisstufe; KI-Anbieter sind vertraglich verpflichtet, Eingaben\nund Ausgaben, die mit GitLab-Kunden verbunden sind, nicht für eigene Zwecke zu\nverwenden.\n\nDies ist eine bewusste architektonische und richtlinienbezogene Entscheidung –\nkein Merkmal einer bestimmten Preisstufe. Wie GitLabs\n[Beitrag zur Enterprise-Unabhängigkeit](https://about.gitlab.com/de-de/blog/why-enterprise-independence-matters-more-than-ever-in-devsecops/)\nfesthält, ist Datenverwaltung zu einem \"zunehmend kritischen Faktor bei\nUnternehmensentscheidungen\" geworden – getrieben durch nationale und regionale\nDatenschutzgesetze und wachsende Bedenken hinsichtlich der Kontrolle über\nsensibles geistiges Eigentum.\n\nGitLab ist cloud-neutral und modell-neutral und unterstützt\nSelf-Hosted-Deployments ohne kommerzielle Bindung an einen einzelnen\nCloud-Anbieter oder ein Large Language Model. Diese Unabhängigkeit ist für\nregulierte Unternehmen relevant, die Risiken durch Anbieterkonzentration\nbewerten. Der\n[AI Continuity Plan](https://handbook.gitlab.com/handbook/product/ai/continuity-plan/)\ndokumentiert, wie Anbieterveränderungen gehandhabt werden – einschließlich\nwesentlicher Änderungen daran, wie KI-Anbieter Kundendaten behandeln. Er ist\neine direkte Antwort auf die Governance-Anforderungen unter Frameworks wie\n[DORA](https://handbook.gitlab.com/handbook/legal/dora/).\n\n\n## Die Governance-Lücke, die KI-Teams schließen müssen\n\nGitHubs Richtlinienaktualisierung macht deutlich: Für Unternehmen in\nregulierten Branchen ist das genaue Verständnis des Datenumgangs eines\nKI-Werkzeugs eine Voraussetzung für dessen Einsatz. Das bedeutet, Anbietern\nklare, dokumentierte Antworten auf folgende Fragen abzuverlangen:\n\n1. Werden unsere Daten zum Training von KI-Modellen verwendet?\n2. Wer sind Ihre KI-Modell-Unterauftragsverarbeiter?\n3. Was geschieht, wenn ein Anbieter seine Datenpraktiken ändert?\n4. Lässt sich ein Deployment realisieren, das alle KI-Verarbeitung innerhalb\n   der eigenen Infrastruktur hält?\n5. Welche Haftungsübernahme wird für KI-generierte Ausgaben angeboten?\n\nAnbieter, die diese Fragen klar beantworten und die Antworten in prüfbarer\nForm dokumentieren, sind Anbieter, auf die sich aufbauen lässt.\n**Wer das nicht kann, schafft Compliance-Risiken bei jedem Policy-Update.**\nWenn ein Anbieter Datenpraktiken mit 30 Tagen Ankündigungsfrist ändern kann,\nist das kein partnerschaftlicher Rahmen für regulierte Unternehmen – das ist\nein strukturelles Compliance-Risiko.\n\n> Mehr zu GitLabs Ansatz für KI-Governance im\n> [GitLab AI Transparency Center](https://about.gitlab.com/de-de/ai-transparency-center/).\n",[21,723],{"featured":13,"template":14,"slug":749},"github-copilots-new-policy-for-ai-training-is-a-governance-wake-up-call",{"promotions":751},[752,765,776,788],{"id":753,"categories":754,"header":755,"text":756,"button":757,"image":762},"ai-modernization",[11],"Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":758,"config":759},"Get your AI maturity score",{"href":760,"dataGaName":761,"dataGaLocation":243},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":763},{"src":764},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":766,"categories":767,"header":768,"text":756,"button":769,"image":773},"devops-modernization",[723,568],"Are you just managing tools or shipping innovation?",{"text":770,"config":771},"Get your DevOps maturity score",{"href":772,"dataGaName":761,"dataGaLocation":243},"/assessments/devops-modernization-assessment/",{"config":774},{"src":775},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":777,"categories":778,"header":780,"text":756,"button":781,"image":785},"security-modernization",[779],"security","Are you trading speed for security?",{"text":782,"config":783},"Get your security maturity score",{"href":784,"dataGaName":761,"dataGaLocation":243},"/assessments/security-modernization-assessment/",{"config":786},{"src":787},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"id":789,"paths":790,"header":793,"text":794,"button":795,"image":800},"github-azure-migration",[791,792],"migration-from-azure-devops-to-gitlab","integrating-azure-devops-scm-and-gitlab","Is your team ready for GitHub's Azure move?","GitHub is already rebuilding around Azure. Find out what it means for you.",{"text":796,"config":797},"See how GitLab compares to GitHub",{"href":798,"dataGaName":799,"dataGaLocation":243},"/compare/gitlab-vs-github/github-azure-migration/","github azure migration",{"config":801},{"src":775},{"header":803,"blurb":804,"button":805,"secondaryButton":810},"Beginne noch heute, schneller zu entwickeln","Entdecke, was dein Team mit der intelligenten Orchestrierungsplattform für DevSecOps erreichen kann.\n",{"text":806,"config":807},"Kostenlosen Test starten",{"href":808,"dataGaName":48,"dataGaLocation":809},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/de-de/","feature",{"text":50,"config":811},{"href":52,"dataGaName":53,"dataGaLocation":809},1777493575915]