[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-content-weekly-ai-news-kw22":3},"\u003Cp>KW22 ist die Woche, in der zwei lange erwartete Schienen gleichzeitig den Bahnhof verlassen. Auf der einen Seite \u003Cstrong>vLLM v0.21.0 GA\u003C\u002Fstrong> — die Open-Source-Inference-Engine, die für DACH-Unternehmen den Unterschied zwischen \"Pilot\" und \"Production\" macht, ist seit dem 15. Mai final draußen. Auf der anderen Seite ein klares Investitions-Signal aus dem Closed-Vendor-Lager: \u003Cstrong>Anthropic übernimmt Stainless\u003C\u002Fstrong> (18. Mai), den SDK-Spezialisten hinter Python\u002FTypeScript\u002FJava\u002FGo\u002FRuby-Clients, und schaltet damit Developer-Experience auf eine neue Stufe.\u003C\u002Fp>\n\n\u003Cp>Dazwischen läuft eine ganze Welle an Plattform-News: LiteLLM v1.86.0 mit Azure GPT-5.4 und nativen Anthropic Web-Search-Blocks, LangChain Deep Agents mit DeltaChannel für State-Diffs statt Full-Snapshots, Docker Gordon AI Agent GA in Docker Desktop 4.61, Atlassian Rovo Studio als MCP-Skill-Marketplace bei Team '26, Jack Clarks Import AI #457 mit der \"AI Stuxnet\"-These, und in Brüssel verschiebt der Digital Omnibus die Annex-III-HRAIS-Deadline um 16 Monate. Hier die Einordnung.\u003C\u002Fp>\n\n\u003Ch2>Top-Story: vLLM v0.21.0 GA — Self-Hosting wird produktionsnäher\u003C\u002Fh2>\n\u003Cp>vLLM hat am 15. Mai die \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fvllm-project\u002Fvllm\u002Freleases\" target=\"_blank\" rel=\"noopener noreferrer\">v0.21.0 final freigegeben\u003C\u002Fa> — nach v0.21.0rc1 vom 12. Mai. Das ist mehr als ein Punkt-Release: vLLM v0.21 rückt selbst gehostete Frontier-Inference näher an die Anforderungen, die DACH-Teams bisher oft nur aus großen Closed-API-Diensten kannten.\u003C\u002Fp>\n\u003Cp>Die wichtigsten Neuerungen, kurz und schmerzlos: \u003Cstrong>C++20-Compiler-Pflicht\u003C\u002Fstrong> (Breaking — wer noch mit GCC 9 arbeitet, hat ein Problem), \u003Cstrong>Transformers v4 deprecated\u003C\u002Fstrong>, und das neue \u003Cstrong>TOKENSPEED_MLA Attention Backend\u003C\u002Fstrong> für DeepSeek-R1- und Kimi-K2.5\u002FK2.6-Prefill+Decode auf Blackwell-GPUs. Genauso wichtig: \u003Cstrong>KV-Offloading + Hybrid Memory Allocator (HMA)\u003C\u002Fstrong> sind jetzt vollständig integriert, \u003Cstrong>Scheduler-side Sliding-Window-Group Support\u003C\u002Fstrong> funktioniert sauber, und \u003Cstrong>Speculative Decoding respektiert Reasoning\u002FThinking-Budgets korrekt\u003C\u002Fstrong> — das war 2025 noch eine der nervigsten Fehlerquellen bei Reasoning-Modellen.\u003C\u002Fp>\n\u003Cp>Neue Architektur-Supports in v0.21: \u003Cstrong>MiMo-V2.5, Laguna XS.2, Moondream3, Qianfan-OCR, Cohere MoE, Cohere Eagle\u003C\u002Fstrong>. Dazu kommt am 18. Mai der Launch von \u003Cstrong>PegaFlow\u003C\u002Fstrong> für Production-Grade External KV Cache — eine Kooperation mit Novita AI. Und am 11. Mai wurde vLLM im Umfeld der \u003Ca href=\"https:\u002F\u002Fartificialanalysis.ai\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Artificial Analysis\u003C\u002Fa> Inference-Benchmarks prominent geführt.\u003C\u002Fp>\n\u003Cp>Für jedes Team, das eine selbst kontrollierte KI-Plattform betreibt, ist das die Nachricht der Woche. Wer noch auf v0.20.x sitzt, sollte v0.21 in einer Staging-Umgebung evaluieren — vor allem dort, wo Blackwell-GPUs, KV-Offload und Reasoning-Modelle auf der Roadmap stehen.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Quelle:\u003C\u002Fstrong> \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fvllm-project\u002Fvllm\u002Freleases\" target=\"_blank\" rel=\"noopener noreferrer\">vLLM v0.21.0 Release Notes\u003C\u002Fa> · \u003Ca href=\"https:\u002F\u002Fartificialanalysis.ai\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Artificial Analysis\u003C\u002Fa>\u003C\u002Fp>\n\n\u003Ch2>LiteLLM v1.86.0 — Azure GPT-5.4, native Anthropic Web-Search-Blocks, bedrock-mantle\u003C\u002Fh2>\n\u003Cp>Auf der Proxy-Layer-Seite hat \u003Cstrong>BerriAI am 24. Mai LiteLLM v1.86.0 stable\u003C\u002Fstrong> freigegeben, mit v1.86.0rc1 schon seit 17. Mai im RC und v1.87.0.dev1 (20. Mai) als nächster Pre-Release. Die Highlights von \u003Ca href=\"https:\u002F\u002Fgithub.com\u002FBerriAI\u002Flitellm\u002Freleases\" target=\"_blank\" rel=\"noopener noreferrer\">v1.86.0rc1\u003C\u002Fa> sind sehr konkret: \u003Cstrong>Azure AI Foundry GPT-5.4\u003C\u002Fstrong> ist mit Model-Metadaten (pro\u002Fmini\u002Fnano plus dated aliases) eingebunden, mit tiered und priority Pricing direkt im Router.\u003C\u002Fp>\n\u003Cp>Wichtig für alle, die mit Claude-Desktop oder Cowork arbeiten: LiteLLM unterstützt jetzt native \u003Cstrong>web_search_tool_result-Blocks\u003C\u002Fstrong> für Anthropic-Clients — Citations und Web-Search-Calls werden sauber durchgereicht statt im Tool-Call-JSON zu landen. Außerdem ist \u003Cstrong>bedrock-mantle\u003C\u002Fstrong> als Provider hinzugekommen — der Weg, Claude Mythos Preview über \u003Ccode>\u002Fanthropic\u002Fv1\u002Fmessages\u003C\u002Fcode> zu erreichen, wenn du AWS-First betreibst.\u003C\u002Fp>\n\u003Cp>Kleiner, aber wichtiger Fix: Vector-Store retrieve\u002Flist\u002Fupdate\u002Fdelete funktionieren jetzt auch ohne ein Completion-Model im Request. Wer Vector-Stores als reine Knowledge-Base ohne LLM-Routing nutzt, hatte hier vorher unnötigen Boilerplate. Dazu \u003Cstrong>Weighted-Routing Failover\u003C\u002Fstrong> und \u003Cstrong>OTel-Standard-Tracing\u003C\u002Fstrong>. Versioning bleibt wie gewohnt: MINOR wöchentlich am Sonntag, PATCH für Hotfixes.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Quelle:\u003C\u002Fstrong> \u003Ca href=\"https:\u002F\u002Fgithub.com\u002FBerriAI\u002Flitellm\u002Freleases\" target=\"_blank\" rel=\"noopener noreferrer\">LiteLLM v1.86.0rc1 Release Notes\u003C\u002Fa> · \u003Ca href=\"https:\u002F\u002Fdocs.litellm.ai\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">LiteLLM Docs\u003C\u002Fa>\u003C\u002Fp>\n\n\u003Ch2>LangChain Deep Agents Mai-Release — DeltaChannel verändert das State-Modell\u003C\u002Fh2>\n\u003Cp>LangChain hat am 13. Mai die \u003Ca href=\"https:\u002F\u002Fblog.langchain.com\" target=\"_blank\" rel=\"noopener noreferrer\">Deep Agents Mai-Release\u003C\u002Fa> ausgerollt — und das wichtigste Detail ist eine architektonische Entscheidung, kein neues Feature. \u003Cstrong>DeltaChannel\u003C\u002Fstrong> ersetzt die bisherige Full-Snapshot-Checkpoint-Logik durch Diff-basierte State-Speicherung: statt bei jedem Schritt das komplette Agent-State-Object zu serialisieren, wird nur die Differenz zum vorherigen Checkpoint persistiert.\u003C\u002Fp>\n\u003Cp>Klingt nach Detail, ist aber in der Praxis ein Spielentscheider. Wer Long-Running-Agents über Stunden oder Tage betreibt (Deep-Research-Workflows, Multi-Agent-Orchestration, langwierige Code-Migration), hat bisher Storage-Kosten und I\u002FO-Latenz im Quadrat zur Run-Länge gesehen. Mit DeltaChannel skaliert das deutlich entspannter. Dazu kommen \u003Cstrong>Harness Profiles\u003C\u002Fstrong> für Model-Optimierung, \u003Cstrong>Code Interpreter\u003C\u002Fstrong> als Agent-Tool, \u003Cstrong>Streaming\u003C\u002Fstrong> für parallelisierte Systeme und \u003Cstrong>ContextHubBackend\u003C\u002Fstrong> als versioniertes File-Management für Agents.\u003C\u002Fp>\n\u003Cp>Neu auch: \u003Ccode>client.threads.stream(...)\u003C\u002Fcode> für Remote-Event-Streaming, plus offizielle Framework-Integrationen für \u003Cstrong>@langchain\u002Freact, @langchain\u002Fvue, @langchain\u002Fsvelte und @langchain\u002Fangular\u003C\u002Fstrong> im v1-Pfad. \u003Cstrong>Deep Agents v0.6\u003C\u002Fstrong> wird damit zum Production-grade Multi-Agent-Backbone, den man ohne schlechtes Gewissen in eine Enterprise-Roadmap aufnehmen kann.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Quelle:\u003C\u002Fstrong> \u003Ca href=\"https:\u002F\u002Fblog.langchain.com\" target=\"_blank\" rel=\"noopener noreferrer\">LangChain Blog — Deep Agents Mai-Release\u003C\u002Fa>\u003C\u002Fp>\n\n\u003Ch2>Anthropic kauft Stainless — Developer-Experience als strategischer Layer\u003C\u002Fh2>\n\u003Cp>Am 18. Mai hat Anthropic \u003Ca href=\"https:\u002F\u002Fwww.anthropic.com\u002Fnews\" target=\"_blank\" rel=\"noopener noreferrer\">die Übernahme von Stainless\u003C\u002Fa> angekündigt — Stainless ist der Spezialist, der bisher die offiziellen SDKs für Python, TypeScript, Java, Go und Ruby aus OpenAPI-Specs auto-generierte (übrigens auch für OpenAI). Die Akquisition ist ein klares Signal: Frontier-Modelle alleine reichen nicht mehr als Differenzierungsmerkmal — die SDK-Schicht zwischen API und Entwickler ist mittlerweile ein strategischer Layer.\u003C\u002Fp>\n\u003Cp>Was das praktisch bedeuten dürfte: Die Claude-SDKs werden in den nächsten Quartalen spürbar mehr Aufmerksamkeit bekommen — sauberer typisiert, mit konsistenteren Error-Modellen und schnelleren Release-Zyklen. Wer heute den \u003Ccode>@anthropic-ai\u002Fsdk\u003C\u002Fcode> für Cowork und Skills nutzt, sollte die Entwicklung beobachten. Und es zeigt, wo Anthropic den Wettbewerb mit OpenAI sieht: nicht nur in Benchmark-Punkten, sondern in der täglichen Developer-Erfahrung über Tausende von Integrations-Stunden.\u003C\u002Fp>\n\u003Cp>Für DACH-Teams, die Multi-Provider-Setups fahren (Anthropic + OpenAI + lokales vLLM), ist das ein Hinweis: Closed-Vendor investieren jetzt aggressiv in den Layer, der Open-Source historisch weniger gepflegt hat. Wer eine On-Premise-Strategie verfolgt, sollte parallel die eigenen SDK-Wrapper auf Stainless-Niveau bringen — sonst ist die DX-Lücke in einem Jahr nicht mehr zu schließen.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Quelle:\u003C\u002Fstrong> \u003Ca href=\"https:\u002F\u002Fwww.anthropic.com\u002Fnews\" target=\"_blank\" rel=\"noopener noreferrer\">Anthropic — Stainless Acquisition\u003C\u002Fa> · \u003Ca href=\"https:\u002F\u002Fwww.stainless.com\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Stainless\u003C\u002Fa>\u003C\u002Fp>\n\n\u003Ch2>Docker Gordon GA + Docker AI Governance — Enterprise-Layer wird Standard\u003C\u002Fh2>\n\u003Cp>Docker hat am 19. Mai \u003Cstrong>Gordon GA\u003C\u002Fstrong> in \u003Ca href=\"https:\u002F\u002Fwww.docker.com\u002Fblog\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Docker Desktop 4.61\u003C\u002Fa> veröffentlicht. Gordon ist der lokale AI-Agent im Docker-Stack, der seit der ersten Tech-Preview ordentlich gereift ist. Highlights: \u003Cstrong>Persistent Local Memory\u003C\u002Fstrong> (Konversationen überleben Restarts), \u003Cstrong>MCP- und Kubernetes-Support\u003C\u002Fstrong>, \u003Cstrong>Multi-line Prompts\u003C\u002Fstrong>, \u003Cstrong>Container\u002FImage\u002FVolume Management direkt aus dem Chat\u003C\u002Fstrong>, und \u003Cstrong>K8s-Pod-Logs-Analyse\u003C\u002Fstrong>.\u003C\u002Fp>\n\u003Cp>Dazu kommt \u003Cstrong>Docker AI Governance\u003C\u002Fstrong> (12. Mai-Release), die nicht nur für Gordon, sondern für jeden Agent gilt, der im Docker-Stack läuft: \u003Cstrong>Centralized Control über Agent-Execution, Network-Reach, Credentials und MCP-Tool-Allowance\u003C\u002Fstrong>. Pattern: AI-Agent darf nicht ungebremst alles — Enterprise-Governance ist 2026 ein Pflicht-Layer, kein Nice-to-have. Mit der Kombination Gordon GA + AI Governance hat Docker den Anspruch klar formuliert: Container und AI-Agents werden im selben Lifecycle verwaltet.\u003C\u002Fp>\n\u003Cp>Wichtige Nebenmeldung: \u003Cstrong>Docker Model Runner\u003C\u002Fstrong> unterstützt jetzt \u003Cstrong>vLLM Metal + Qwen 3.5\u003C\u002Fstrong> — also die schnelle lokale Inference von Qwen-3.5-Modellen auf Apple-Silicon, ohne Custom-Compose-Hacks. Für Dev-Workstations in DACH-Teams ist das eine sehr saubere Default-Konfiguration.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Quelle:\u003C\u002Fstrong> \u003Ca href=\"https:\u002F\u002Fwww.docker.com\u002Fblog\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Docker Blog — Gordon GA + Docker Desktop 4.61\u003C\u002Fa> · \u003Ca href=\"https:\u002F\u002Fwww.docker.com\u002Fproducts\u002Fai-governance\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Docker AI Governance\u003C\u002Fa>\u003C\u002Fp>\n\n\u003Ch2>Atlassian Team '26 — Rovo Studio wird MCP-Skill-Marketplace\u003C\u002Fh2>\n\u003Cp>Auf der \u003Cstrong>Team '26 Conference\u003C\u002Fstrong> Mitte Mai hat Atlassian Rovo Studio neu aufgestellt. \u003Cstrong>Rovo Studio Unified\u003C\u002Fstrong> kombiniert die bisher getrennten Tool-, Skill- und Knowledge-Layer in eine einzige Building-Experience, und der \u003Cstrong>Open MCP Standard\u003C\u002Fstrong> verbindet Rovo direkt mit dem wachsenden Ökosystem an MCP-Skills. Built-in Analytics und Testing für Agent-Optimization sind direkt eingebaut — ein klares Signal, dass Atlassian Rovo Studio als Enterprise-Plattform für Multi-Agent-Workflows positioniert, nicht als reinen Confluence-Assistent.\u003C\u002Fp>\n\u003Cp>Begleitend: \u003Cstrong>Remix with Rovo in Confluence\u003C\u002Fstrong> — Page-Content kann direkt in Charts, Infographics oder Visuals umgewandelt werden. Ready-to-use Partner-Agents für \u003Cstrong>Lovable, Replit und Gamma\u003C\u002Fstrong> sind eingebaut, und seit April läuft \u003Cstrong>Rovo Dev in Jira\u003C\u002Fstrong> als context-aware AI-Agent für repetitive Work direkt im Ticket-Workflow.\u003C\u002Fp>\n\u003Cp>Die Zahlen, die Atlassian nennt, sind bemerkenswert: \u003Cstrong>MCP-Updates senken Token-Costs um 48 %, Graph-Search liefert 44 % genauere Ergebnisse\u003C\u002Fstrong>. Das sind Herstellerangaben, aber sie zeigen die Richtung: Wer Atlassian-Cloud nutzt, sollte sich Rovo Studio in den nächsten Wochen ansehen — die MCP-Integration ist ein direkter Hebel, um eigene interne Tools mit überschaubarem Aufwand an Multi-Agent-Workflows anzukoppeln.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Quelle:\u003C\u002Fstrong> \u003Ca href=\"https:\u002F\u002Fwww.atlassian.com\u002Fblog\u002Fdevops\" target=\"_blank\" rel=\"noopener noreferrer\">Atlassian Blog — Team '26 Rovo Studio\u003C\u002Fa> · \u003Ca href=\"https:\u002F\u002Fwww.atlassian.com\u002Fsoftware\u002Frovo\" target=\"_blank\" rel=\"noopener noreferrer\">Atlassian Rovo\u003C\u002Fa>\u003C\u002Fp>\n\n\u003Ch2>Import AI #457 — \"AI Stuxnet\" und der Muon-Optimizer\u003C\u002Fh2>\n\u003Cp>Jack Clark hat am 18. Mai die Import-AI-Ausgabe #457 veröffentlicht; der stabile Einstiegspunkt ist das \u003Ca href=\"https:\u002F\u002Fimportai.substack.com\u002Farchive\" target=\"_blank\" rel=\"noopener noreferrer\">Import AI Archiv\u003C\u002Fa>. Kerndiskussion: \u003Cstrong>AI-gestützte Cyber-Werkzeuge\u003C\u002Fstrong> im Stil von Stuxnet — also Systeme, die gezielt gegen kritische Infrastruktur eingesetzt werden könnten. Clark argumentiert, dass die Schwelle für solche Operationen mit jeder Reasoning-Generation niedriger wird, und schlägt einen Framework-Vorschlag für \"positive alignment\" als Gegen-Konzept vor.\u003C\u002Fp>\n\u003Cp>Dazu kommen neue Befunde zum \u003Cstrong>Muon-Optimizer\u003C\u002Fstrong> — eine relativ junge Alternative zu AdamW, die in einigen Training-Setups counterintuitiv stabiler arbeitet, in anderen aber unerwartete Pathologien zeigt. Für Praktiker bei kleineren Pretraining-Runs ist das ein Hinweis: nicht jedes \"neue Optimizer-Paper\" ist ein Win, einige Findings sind sehr Workload-spezifisch.\u003C\u002Fp>\n\u003Cp>Vorherige #456 (11. Mai) hatte das RSI-Wirtschaftswachstum-Thema und \"radical optionality\" für AI-Regulierung diskutiert. Wer Import AI nicht regelmäßig liest, verpasst die einzige politische AI-Analyse, die unter Praktikern in den USA wirklich gelesen wird.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Quelle:\u003C\u002Fstrong> \u003Ca href=\"https:\u002F\u002Fimportai.substack.com\u002Farchive\" target=\"_blank\" rel=\"noopener noreferrer\">Import AI Archiv\u003C\u002Fa>\u003C\u002Fp>\n\n\u003Ch2>EU Digital Omnibus — HRAIS-Deadline um 16 Monate nach hinten\u003C\u002Fh2>\n\u003Cp>Am 7. Mai wurde eine Einigung über das \u003Cstrong>Digital Omnibus\u003C\u002Fstrong> berichtet — mit einer Änderung, die für viele AI-Implementierungen in DACH-Unternehmen direkt relevant wäre: Die \u003Cstrong>Compliance-Deadline für Annex-III-High-Risk-AI-Systeme würde von 2. August 2026 auf 2. Dezember 2027 verschoben\u003C\u002Fstrong> (also um 16 Monate), Annex-I-HRAIS würde von 2. August 2027 auf 2. August 2028 rutschen.\u003C\u002Fp>\n\u003Cp>Zwei neue Verbote werden in der Einordnung ebenfalls genannt: \u003Cstrong>Non-konsensuelle Intimate-Deepfakes\u003C\u002Fstrong> und \u003Cstrong>CSAM-Generation\u003C\u002Fstrong> — beides ab 2. Dezember 2026. Die \u003Cstrong>Watermarking-Deadline für generative Inhalte\u003C\u002Fstrong> würde demnach auf drei Monate verkürzt.\u003C\u002Fp>\n\u003Cp>Kritik kommt erwartbar von \u003Ca href=\"https:\u002F\u002Fnetzpolitik.org\" target=\"_blank\" rel=\"noopener noreferrer\">netzpolitik.org\u003C\u002Fa>, die argumentieren, die Verschiebung folge der Big-Tech-Wunschliste. Aus DACH-KMU-Sicht sieht es trotzdem so aus: Die Verschiebung schafft Zeit für saubere Implementierungen — aber \u003Cstrong>gleichzeitig erhöht sich der Wettbewerbsdruck, jetzt zu liefern, bevor die Welle 2027 alle gleichzeitig treibt\u003C\u002Fstrong>. Die nächsten 18 Monate sind die Phase, in der die Marktposition für DSGVO-konforme Multi-Agent-Plattformen entschieden wird.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Quelle:\u003C\u002Fstrong> \u003Ca href=\"https:\u002F\u002Fnetzpolitik.org\" target=\"_blank\" rel=\"noopener noreferrer\">Netzpolitik.org — EU Digital Omnibus Einigung\u003C\u002Fa> · \u003Ca href=\"https:\u002F\u002Fdigital-strategy.ec.europa.eu\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">EU-Kommission — Digital Omnibus\u003C\u002Fa>\u003C\u002Fp>\n\n\u003Ch2>Fazit — Die Konsolidierungs-Welle ist da\u003C\u002Fh2>\n\u003Cp>KW22 ist die Woche, in der drei Schichten gleichzeitig reifen: \u003Cstrong>Self-Hosting-Inference\u003C\u002Fstrong> (vLLM v0.21 GA) wird produktionsnäher, \u003Cstrong>Multi-Agent-Orchestration\u003C\u002Fstrong> (LangChain Deep Agents mit DeltaChannel) bekommt die richtigen Primitiven, und \u003Cstrong>Enterprise-Governance\u003C\u002Fstrong> (Docker Gordon + AI Governance, Atlassian Rovo Studio MCP) wird zum Pflichtbaustein. Parallel investiert das Closed-Vendor-Lager mit der Anthropic-Stainless-Akquisition gezielt in den Developer-Experience-Layer — und Brüssel verschafft mit dem Digital Omnibus voraussichtlich mehr Spielraum für sauber geplante Implementierungen. Was Jack Clarks \"AI Stuxnet\"-These zeigt: Die Risiko-Seite wächst proportional mit, und Governance ist 2026 keine Option mehr, sondern eine technische Anforderung im Stack.\u003C\u002Fp>\n\n\u003Cp>\u003Cem>Kuratiert von SEADEV Studios. Weekly AI News erscheint jeden Dienstag.\u003C\u002Fem>\u003C\u002Fp>\n"]