In dieser Folge sprechen wir über den EU AI Act: was er unter einem KI-System versteht, welche Risikostufen er unterscheidet und welche Regeln bereits gelten. Wir gehen auf die kurzfristigen Änderungen durch den EU AI Omnibus ein, unter anderem die verschobenen Fristen für Hochrisiko-Systeme. Außerdem erklären wir, welche Pflichten für Anbieter von General-Purpose-AI-Modellen gelten und welche Rolle der Code of Practice dabei spielt. Im Deep Dive zur Transparenzpflicht geht es darum, wie sich KI-generierte Inhalte kennzeichnen lassen und wie Text-Watermarking mit SynthID technisch funktioniert. Zum Schluss ordnen wir ein, was die Regulierung für Data-Science-Projekte in der Praxis bedeutet.

**Zusammenfassung**

• Stand der Umsetzung: Verbotene Praktiken und die Pflicht zur KI-Kompetenz gelten seit dem 2.2.2025, die Transparenzpflichten seit dem 2.8.2026.
• EU AI Omnibus: Die Fristen für Hochrisiko-Systeme wurden auf den 2.12.2026 (Stand-alone) bzw. 2.12.2027 (eingebettet) verschoben, zudem kam ein Verbot nicht einvernehmlicher sexualisierter Deepfakes hinzu.
• Definition von KI: Der AI Act beschreibt KI-Systeme als maschinengestützte Systeme mit unterschiedlichem Autonomiegrad, die aus Eingaben ableiten, wie sie Vorhersagen, Inhalte, Empfehlungen oder Entscheidungen erzeugen.
• Risikostufen: Unterschieden werden verbotene Praktiken (z. B. Manipulation, Social Scoring), Hochrisiko-Anwendungen (z. B. kritische Infrastruktur, Gesundheit, Bildung, Justiz) und die Restkategorie mit geringem Risiko.
• General-Purpose-AI: Große Foundation-Modelle unterliegen Dokumentations- und Informationspflichten, etwa zu Trainingsdaten und Urheberrecht; ab 10^25 FLOPs Trainingsaufwand wird ein systemisches Risiko vermutet.
• Code of Practice: Anbieter*innen können Compliance über den Code of Practice mit den Kapiteln Transparenz, Urheberrecht sowie Sicherheit und Gefahrenabwehr nachweisen.
• Kennzeichnung von KI-Inhalten: Bilder, Videos und Audio lassen sich per Wasserzeichen oder Metadaten (C2PA) markieren, Texte über eine subtile Beeinflussung der Token-Auswahl wie bei SynthID – beide Ansätze haben aber klare Grenzen bei Erkennung und Manipulationssicherheit.
• Bedeutung für die Praxis: Wichtig sind die Risikoeinordnung eines Projekts, eingebaute Transparenzmechanismen etwa bei Chatbots und dokumentierte Maßnahmen zur KI-Kompetenz – vieles davon entspricht ohnehin guter Praxis.

**Links**

• Verordnung (EU) 2024/1689 (AI Act) auf EUR-Lex: https://eur-lex.europa.eu/eli/reg/2024/1689/oj Bundesnetzagentur – KI-Verordnung, Zeitplan und Überblick (deutsch): https://www.bundesnetzagentur.de/DE/Fachthemen/Digitales/KI/1_Ziel/start_ziel.html
• EU-Kommission – Safer and more transparent AI (2.8.2026): https://commission.europa.eu/news-and-media/news/safer-and-more-transparent-ai-2026-08-02_en
• Rat der EU – Final green light für den AI Omnibus: https://www.consilium.europa.eu/en/press/press-releases/2026/06/29/artificial-intelligence-council-gives-final-green-light-to-simplify-and-streamline-rules/
• technology.org – What actually applies on 2 August 2026: https://www.technology.org/2026/07/17/eu-ai-act-what-actually-applies-on-2-august-2026/
• Nature-Paper zu SynthID-Text: https://www.nature.com/articles/s41586-024-08025-4
• Google DeepMind – Watermarking mit SynthID: https://deepmind.google/blog/watermarking-ai-generated-text-and-video-with-synthid/
• C2PA – Standard für Herkunftsnachweise von Inhalten: https://c2pa.org/

Lust auf einen Schnack bei der goto; Konferenz in Kopenhagen?

Sebastian auf LinkedIn: https://www.linkedin.com/in/sebastianwarnholz

goto; Konferenz in Kopenhagen: https://gotocph.com/2026

📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de

Ein Geschäftsführer will im Quartalsmeeting wissen, welche Kundengruppe die profitabelste ist – der Vertrieb antwortet mit einer Zahl aus Excel, das Controlling mit einer anderen aus SAP, und das Meeting endet ohne Entscheidung. Mit dieser Szene startet der "Data Strategy Kompass", eine vierteilige Serie über Datenstrategie im Mittelstand. In Teil 1 klären Mira und Amit, was eine Datenstrategie ist und was sie nicht ist: keine Software-Entscheidung und kein Data-Warehouse-Projekt, sondern die Frage, welche Entscheidungen ein Unternehmen künftig besser treffen will. Sie gehen die Bestandteile durch – von der Anbindung an die Unternehmensstrategie über Datenhaltung und Governance bis zum menschlichen Faktor – und diskutieren, wann sich eine Datenstrategie lohnt und wann eher nicht. Anhand von Beispielen und Gegenbeispielen aus über 15 Jahren Projektarbeit zeigen sie, woran es in der Praxis meist hängt: selten an der Technik.

**Zusammenfassung**

• Datenstrategie beantwortet die Frage "Welche Entscheidungen wollen wir besser treffen?" und nicht "Welche Software kaufen wir?"
• Erst Use Cases, dann Infrastruktur: Alles zu speichern und später zu schauen, wofür man es braucht, ist ein Relikt der Big-Data-Zeit
• Bestandteile: Verbindung zur Unternehmensstrategie, Priorisierung von Use Cases, Datenhaltung und Architektur, Governance, Organisation und Kultur
• Kein isoliertes Projekt einer Datenabteilung: Es braucht die Führungsebene, mehrere Fachbereiche und kontinuierliche Anpassung
• Personalbedarf wird unterschätzt: gebraucht werden vor allem Menschen, die Pipelines bauen und Daten aufbereiten, nicht nur Data Scientists
• Wann es sich nicht lohnt: zehn Mitarbeitende und ein Excel; niemand ist bereit, datenbasiert zu entscheiden; Daten dienen nur der Rechtfertigung ohnehin gefasster Meinungen
• Datenbasiert heißt nicht "alle Entscheidungen datenbasiert": Strategische Weichenstellungen kommen oft ohne belastbare Datenbasis aus
• Typische Stolpersteine aus der Praxis: SaaS-Tool ohne Datenexport, parallele Excel-Welten ohne Dokumentation, Compliance-Lücken bereits bei der Datenerhebung

**Zum Mitnehmen: vier Fragen für den nächsten Führungskreis**

• Welche Entscheidung wurde in den letzten drei Monaten aus dem Bauch heraus getroffen, weil die Zahlen fehlten?
• Wenn du heute drei wichtige Fragen an deine Daten stellen könntest, welche wären das?
• Wer würde der KI (z.B. eine Prognose, nicht Chatbot ist gemeint) vertrauen, wenn sie ihr/ihm widerspricht?
• Die Datenprojekte, die wir schon machen - wissen wir, wie viel sie uns eigentlich bringen?

**Links**

• #33: Data Science bei Zalando – Dr. Claudia Baldermann im Gespräch über Product Development & Organisation https://www.podbean.com/ew/pb-q25zg-14b82e0
• #5: Data Warehouse vs. Data Lake vs. Data Mesh https://www.podbean.com/ew/pb-a4xzx-127be01
• #36: Der Data Mesh Hype und was davon bleibt https://www.podbean.com/ew/pb-7er7v-15080c1
• Data Mesh Principles and Logical Architecture (Zhamak Dehghani): https://martinfowler.com/articles/data-mesh-principles.html
• INWT Website: https://www.inwt-statistics.de/

📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de

Sebastian und Michelle sprechen in dieser Folge über Cluster-Architektur mit Kubernetes: was das Tool leistet, welche Betriebsvarianten es gibt und für wen sich der Einsatz überhaupt rechnet. Ausgangspunkt sind die typischen Gründe für k8s – Skalierung, Ausfallsicherheit durch Health Checks und Rolling Updates sowie Infrastructure as Code. Danach geht es um die Frage self-hosted (k8s, k3s) oder managed (AWS, GCP, Azure) und um den Unterschied zwischen plain Kubernetes und Red Hat OpenShift. Ein zweiter Schwerpunkt liegt auf dem Zuschnitt der Umgebung: wie viele Cluster sinnvoll sind (pro Stage, pro Produkt) und wie innerhalb eines Clusters mit Namespaces und Network Policies getrennt wird. Zum Schluss diskutieren die beiden Alternativen ohne Kubernetes und die Voraussetzungen, die im Team erfüllt sein müssen.

**Zusammenfassung**

• Kubernetes verwaltet containerisierte Anwendungen und arbeitet mit Docker zusammen – die beiden Tools sind keine Konkurrenz
• Hauptargumente für k8s: Skalierung und Ressourcennutzung, Verfügbarkeit über Health Checks (Liveness, Readiness), Rolling Updates und Rollbacks, Konfiguration als Code in YAML
• Self-hosted (k8s, k3s) bedeutet eigene Versions-Updates und Skills in Systemadministration und Provisionierung; Managed Cluster kosten mehr, reduzieren aber Maintenance und erhöhen die Verfügbarkeitsgarantie
• OpenShift bringt eigene CLI, UI, Monitoring und Enterprise Support mit (Open-Source-Variante: OKD), plain k8s läuft dafür auf schlankerer Hardware
• Anzahl der Cluster: mindestens eine Trennung von DEV und PRD, größere Organisationen provisionieren pro Produkt x Stage – jedes zusätzliche Cluster bedeutet mehr Aufwand für Updates, Monitoring und Provisionierung
• Trennung nach Produkt statt nach Team, weil Zuständigkeiten sich ändern; Namespaces sind die leichtgewichtige Alternative zur vollen Isolation
• Network Policies funktionieren wie Firewall-Regeln für Pods (Ziel/Quelle, ingress/egress); standardmäßig ist alles erlaubt, sobald ein Pod eine Policy hat, gilt für ihn Deny-All – ein Deny-All pro Namespace ist deshalb Pflicht
• Alternative für kleine Setups: ein oder zwei VMs mit mehreren Instanzen hinter einem Loadbalancer, Rolling Updates per Skript; entscheidend sind Produkt, Verfügbarkeitsanspruch und vorhandenes Know-how

**Links**

• Episode #14: Kubernetes https://inwt.podbean.com/e/14-kubernetes/
• Training Course by The Linux Foundation: Introduction to Kubernetes (LFS158) https://training.linuxfoundation.org/training/introduction-to-kubernetes/
• Kubernetes: https://kubernetes.io/
• k3s: https://k3s.io/

📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de

Sebastian und Liel setzen die Folge #91 zur Zukunft der Softwareentwicklung fort und widmen sich diesmal den Risiken beim Einsatz von AI Agents. Sie ordnen ein, welche Gefahren beim lokalen Arbeiten mit Agents tatsächlich bestehen – von autonom ausgeführten Befehlen mit Datenverlust über Prompt Injection bis zur Weitergabe sensibler Daten an externe Modelle. Im zweiten Teil geht es um konkrete Strategien zur Risikominimierung: durchdachte Berechtigungen, Repository-scoped Tokens, isolierte Workspaces mit Dev-Containern oder Mini-VMs sowie eine bewusste Auswahl der eingesetzten Modelle. Zum Abschluss diskutieren die beiden, wohin sich die Arbeit mit Coding-Agents entwickelt und welche Rolle Reviews und Wartbarkeit dabei spielen. Ein "sicher" gibt es dabei nicht, wohl aber ein "sicherer".

**Zusammenfassung**

• AI Agents führen im YOLO-Mode Code direkt auf dem eigenen System aus – Datenverlust durch unbedachte Befehle ist ein reales Risiko.
• Prompt Injection kommt über README-Anweisungen, MCP-Server und Webfetch ins System; halluzinierte Library-Namen lassen sich durch Squatting für Schadcode ausnutzen.
• Die "lethal trifecta" beschreibt die kritische Kombination aus Zugriff auf private Daten, Verarbeitung nicht vertrauenswürdiger Inhalte und Möglichkeit zur Kommunikation nach außen.
• Kompromittierung betrifft Credentials, proprietären Code und personenbezogene Daten – jede Query an ein extern gehostetes Modell verlässt das eigene System.
• Default-Konfigurationen (OpenCode, VSCode + GitHub Copilot) sind ein häufiger Stolperstein, da Daten oft standardmäßig zum Training genutzt werden.
• Zur Absicherung helfen fein eingestellte Berechtigungen, Repository-scoped Tokens, Provisionierung im Unternehmen und isolierte Workspaces (Dev-Container, VibePod, nono).
• Bei der Modellauswahl lohnt der Blick auf Selfhosting sowie europäische bzw. offene Alternativen wie Mistral und das Schweizer Apertus.
• Traceability, Live- und Kostenmonitoring werden wichtiger, da Agents Tokenverbrauch und Aktionen kaum noch kontrollierbar machen.

**Links**

• #91: Software ohne Entwickler*innen? Wie AI Agents unsere Arbeit neu definieren https://www.podbean.com/ew/pb-2if5e-1a90f94
• The lethal trifecta for AI agents: private data, untrusted content, and external communication (Simon Willison): https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/
• The Vulnerable MCP Project (Übersicht zu MCP-Schwachstellen): https://vulnerablemcp.info/index.html
• Cory Doctorows Blog (Quelle zum Halluzinations-Beispiel): https://pluralistic.net
• VibePod CLI - The zero-config CLI for running AI coding agents locally https://vibepod.dev/
• nono - Run AI agents in a zero-latency sandbox in seconds, with zero setup. https://nono.sh/
• Docker Sandboxes https://docs.docker.com/ai/sandboxes/
• Agentlytics https://agentlytics.io/
• Apertus, das offene Schweizer Sprachmodell (Hugging Face): https://huggingface.co/collections/swiss-ai/apertus-llm
• Mistral (europäischer Modellanbieter): https://mistral.ai

📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de

Wie misst man die Qualität von Gen-AI-Projekten, wenn der Output selten eindeutig richtig oder falsch ist und ein Ground Truth oft fehlt? Auf Anregung unserer Hörerin Andrea sprechen Mira und Tobias darüber, warum die Evaluation generativer Anwendungen ein Umdenken gegenüber klassischen ML-Projekten erfordert. Sie stellen verschiedene Ansätze vor – von klassischem Testen über Goldstandard-Datensätze und "LLM as a Judge" bis zu Similarity-Metriken und User Testing – und ordnen deren Stärken und Schwächen ein. Außerdem geht es um den Umgang mit Spezial- und Off-Topic-Fällen, Manipulationsversuche, Red-Teaming und die Frage, wie groß ein Goldstandard eigentlich sein sollte. Das Fazit: Es gibt keine Faustformel, dafür rücken Domänenverständnis, Produktfokus und Risikomanagement stärker in den Mittelpunkt.

**Zusammenfassung**

• Umdenken nötig: Bei Gen-AI ist der Output oft nicht klar richtig oder falsch, was klassische Evaluationslogik an ihre Grenzen bringt
• Frühe Validierung mit Endnutzenden ist sinnvoll und oft erforderlich, weil man schnell etwas Vorzeigbares hat
• Klassisches Testen funktioniert weiterhin, wo es fixe Metriken oder einen Goldstandard gibt; ein schrittweiser oder verdeckter Rollout liefert früh Ergebnisse
• LLM as a Judge: gut automatisierbar, aber korreliert oft schlecht mit menschlicher Einschätzung; ein Ensemble mehrerer Modelle kann helfen
• Similarity-Metriken wie Cosine Similarity eignen sich als günstiger Vorfilter, bevor der teure LLM-Judge läuft
• User Testing über Testmatrix, Testszenarien und Testpersonas ist aussagekräftig, aber aufwändig und bei jeder Änderung erneut nötig
• Spezialfälle absichern: Umgang mit Off-Topic-, Nonsense- und Manipulationsversuchen, Red-Teaming und ein kleiner Standard-Datensatz als Sanity-Check
• Fazit: keine Faustformel – das Skillset wird breiter, Domänenverständnis und Produktfokus wichtiger, Risikomanagement rückt in den Vordergrund

**Links**

• #47: Von Prognosen und Prompts: Data Science trifft generative KI mit Tobias Sterbak https://www.podbean.com/ew/pb-dkyex-1613842
• Tobias Sterbak auf LinkedIn: https://www.linkedin.com/in/tobias-sterbak/

Fragen, Feedback oder Themenwünsche?

Pünktlich zum Pride Month widmen sich Mira und Liel der Frage, was bei der Arbeit mit sensiblen personenbezogenen Daten am Beispiel queerer Daten zu beachten ist. Sie gehen die drei Phasen Datenerfassung, -bereinigung und -analyse durch und zeigen, wie schon die Wahl von Kategorien die Realität beeinflusst und wie sich Diskriminierung in Daten und Algorithmen fortschreibt. Ein Schwerpunkt liegt auf dem Umgang mit sehr kleinen Gruppen, für die sich statistisch oft wenig ableiten lässt, und auf möglichen Lösungen wie Oversampling oder qualitativen Methoden. Die Episode macht deutlich, dass es keine einzelne richtige Lösung gibt, sondern bewusste Entscheidungen und Mitdenken gefragt sind. Die besprochenen Überlegungen gelten über Queerness hinaus auch für andere Kategorien sozialer Ungleichheit und das Thema Intersektionalität.

**Zusammenfassung**

• Begriffsklärung: Was "queer" bedeutet, von der ursprünglichen Beleidigung zur positiven Selbstbezeichnung, und der Bezug zu LGBTQIA+
• Datenerfassung: Was man erfasst, hängt vom Kontext ab (Sex in der Medizin, Gender beim Verhalten, sexuelle Orientierung im Marketing)
• Kategorien sind nicht neutral: Sie prägen, wie Menschen sich wahrnehmen, wie Umfragen ankommen und ob man Diskriminierung überhaupt messen kann
• Repräsentativität: Wie prüft man sie, wenn die Gruppengröße unbekannt ist – etwa über bayesianische Ansätze mit Annahmen, die durch Daten aktualisiert werden
• Datenbereinigung: Schon wenige Fehleingaben verzerren kleine Gruppen stark, wie das Beispiel der US-Zensusdaten zeigt
• Umgang mit kleinen Gruppen: Optionen sind große Datenmengen, Oversampling, qualitative Methoden oder zumindest transparentes Berichten
• Analyse: Algorithmen reproduzieren und skalieren bestehende Biases und sind nicht automatisch neutral; das Weglassen einzelner Merkmale löst das Problem nicht (Proxy-Variablen)
• Fazit: Es gibt keine technische Patentlösung gegen Diskriminierung – entscheidend sind bewusste Entscheidungen, Mitdenken und der Blick auf Intersektionalität

**Links**

• Buch "Queer Data" von Kevin Guyan: https://kevinguyan.com/queer-data/
• Buch "Rainbow Trap" von Kevin Guyan: https://kevinguyan.com/rainbow-trap/
• Buch "Data Feminism" von Catherine D'Ignazio und Lauren F. Klein (MIT Press, frei verfügbar): https://data-feminism.mitpress.mit.edu/
• Episode #40: Sonderfolge: Frauen in Data Science und Tech mit Catrin & Isa von Mind the Tech https://www.podbean.com/eas/pb-ypy32-15747e6
• Episode #93: Bayesianische Statistik: Vorwissen und Daten kombinieren https://www.podbean.com/eas/pb-crgji-1ab8218

📬 Fragen, Feedback oder Themenwünsche? Schreibt uns gern an: podcast@inwt-statistics.de