Zum Hauptinhalt springen
Drei schwebende Steinplatten mit je einem eigenen Schlüsselloch und Schlüssel. Auf der mittleren steht eine kleine Figur.
Blog·

OpenCode mit Kimi K3 am EU-Endpunkt: DSGVO und Lieferkette

OpenCode läuft mit Kimi K3 über einen EU-Endpunkt. Der Test trennt Datenschutz, Lieferkettenrisiken und technische Anbieterwahl und zeigt, was AVV, Subprozessorenliste und EU-Standort tatsächlich belegen.

Porträt von Antonio Agudo

Geschrieben von

Antonio Agudo

Trainer & Fractional CTO · Konzern und Venture Building seit 2001 · Köln

Ein Modell kann über Nacht verschwinden, ohne dass sich an Ihrem Code eine einzige Zeile geändert hat. Im Juni 2026 ist genau das passiert. Zwei Modelle eines US-Anbieters wurden von einer Exportkontrollmaßnahme erfasst. Eines wurde später weltweit wieder freigeschaltet, das andere zunächst nur für ausgewählte US-Organisationen. Die Nachweisfolgen habe ich getrennt behandelt, hier interessiert die andere Frage: Lässt sich in der Praxis wirklich wechseln, oder steht diese Möglichkeit nur auf dem Papier?

Also habe ich es ausprobiert. OpenCode als Agentensoftware, Kimi K3 als Modell mit offenen Gewichten und ein europäischer Inferenzanbieter. Die Antwort ist dreiteilig und nur zu einem Drittel erfreulich.

OpenCode läuft. Für die technische Anbindung reichte ein Nachmittag. Nötig waren ein eigener Provider-Block, korrekt gesetzte Modelllimits und eine anbieterspezifische Modell-ID. Aus der Wahl eines EU-Endpunkts lässt sich aber noch keine DSGVO-Konformität ableiten. Ein Firmensitz in der EU sagt nichts darüber aus, welcher Rechtsträger die Inferenz erbringt, welche Subprozessoren beteiligt sind und ob Zugriffe aus Drittländern möglich bleiben. Und Kimi K3 lässt sich noch nicht abschließend beurteilen. Drei Läufe liefern einen Praxisbefund, aber kein belastbares Urteil über das Modell.

Ob die DSGVO greift und ob der konkrete Einsatz zulässig ist, hängt zunächst von den verarbeiteten Daten, dem Zweck und der Rechtsgrundlage ab. Diese Punkte bewertet der Beitrag nicht. Er untersucht, welche Anbieter- und Vertragsmerkmale für die anschließende Datenschutz- und Sicherheitsprüfung relevant sind, entlang der drei Schichten Agentensoftware, Modell und Inferenzanbieter. Wie sich diese Entscheidung in den übrigen Rollout einordnet, zeigen die Beschaffungs- und Betriebsfragen im Coding-Agents-Leitfaden.

Dieser Beitrag ist keine Rechtsberatung. Ich bin kein Anwalt.

Was im Test funktioniert hat

Am 31. Juli 2026 habe ich OpenCode 1.18.10 mit TensorX als Inferenzanbieter und der Modell-ID moonshotai/kimi-k3 im Repository spring-petclinic-rest getestet. Ausgangslage: Commit c7b5f5e, sauberer Arbeitsbaum, 237 bestandene Tests, ein tatsächlich vorhandener Defekt, kein künstlich eingebauter Fehler. Ich führte drei vollständige Testläufe mit derselben Aufgabe durch.

Der Defekt lag in Pet.getVisits(). Dort sortierte der Code die Besuche mit einem Comparator, der nicht nullsicher ist. Der Fehler blieb zunächst verborgen, weil List.sort bei einer einelementigen Liste den Comparator nicht aufruft. Er tritt erst bei mindestens zwei Besuchen auf, von denen einer kein Datum enthält. Der Endpunkt GET /api/pets/{id} antwortete deshalb mit HTTP 500 statt HTTP 200. In allen drei Läufen war der Fix bytegenau identisch.

-        sortedVisits.sort(Comparator.comparing(Visit::getDate).reversed());
+        sortedVisits.sort(Comparator.comparing(Visit::getDate, Comparator.nullsLast(Comparator.reverseOrder())));

Die Erfolgsmeldung des Agenten habe ich nicht ungeprüft übernommen: Nach git stash scheiterte der Test mit Status expected:<200> but was:<500>, nach git stash pop bestand er wieder.

Interessanter als der Fix ist der Regressionstest. Er fiel dreimal anders aus, und seine Aussagekraft nahm von Lauf 1 bis Lauf 3 zu. Die Anzahl der Besuche prüfen alle drei. Die Sortierreihenfolge, also die Eigenschaft, die der Fix tatsächlich herstellt, prüfen nur Lauf 2 und Lauf 3, und nur diese beiden verwenden feste Testdaten statt LocalDate.now(). Dass das Datumsfeld beim undatierten Besuch in der JSON-Antwort ausgelassen wird und nicht mit dem Wert null erscheint, prüft allein Lauf 3. Am Diff des Produktivcodes ist dieser Unterschied nicht zu erkennen. Wer mehrere Läufe eines Agenten vergleicht, prüft deshalb die erzeugten Tests, nicht den Diff. Genau dafür braucht es ein eigenes Eval-Set aus echten Repository-Aufgaben: Es zeigt, welche Prüfungen ein Agent ohne vorgegebene Lösungsstrategie selbst entwickelt.

In Lauf 1 fehlte temperature in allen 17 Request-Bodies. Naheliegend wäre der Schluss, dass die konfigurierte Temperatur am Endpunkt nicht ankommt. Die Ursache fand ich stattdessen im installierten Binary, in der Dokumentation wird sie nicht beschrieben. In OpenCode 1.18.10 ist temperature im Modellblock kein numerischer Einstellungswert, sondern ein boolesches Flag, das die Unterstützung des Parameters kennzeichnet. Fehlt das Flag, lässt OpenCode den Parameter im Request weg, unabhängig davon, welcher Wert in der Agentenkonfiguration steht.

"moonshotai/kimi-k3": {
  // Fähigkeitsflag, kein Wert:
  "temperature": true
}

// Der Zahlenwert wird beim Agenten gesetzt, nicht beim Modell:
"agent": { "build": { "temperature": 0.37 } }

Nachdem ich das Flag auf true gesetzt hatte, enthielten alle Requests der beiden folgenden Läufe den Wert temperature: 0.37. Ein fehlender Parameter im Mitschnitt kann also bedeuten, dass der Client ihn gar nicht erst gesendet hat.

Ein Modell außerhalb der OpenCode-Registry braucht einen eigenen Provider-Block mit passendem npm-Paket. limit.context muss von Hand gesetzt werden, für K3 liegt der Wert bei 1.048.576. Dazu kommt die Modellkennung, die anbieterspezifisch ist: TensorX schreibt moonshotai/kimi-k3, Berget moonshotai/Kimi-K3. Base-URL und Schlüssel zu tauschen reicht also nicht.

Ein Proxy-Mitschnitt muss den Prozessen zugeordnet werden, die die Verbindungen ausgelöst haben, sonst erfasst er auch andere Programme aus derselben Shell. Nach dem Bereinigen der Shell-Umgebung kontaktierte OpenCode nur api.tensorx.ai und einmal models.opencode.ai. In einem Artikel darüber, welche Ziele ein Coding Agent tatsächlich kontaktiert, wäre diese Verwechslung besonders folgenreich.

Sechs Fragen zu Datenschutz, Sicherheit und Anbieterwahl

Seit Ende Juli 2026 sind Agentensoftware, Modellgewichte und Inferenz einzeln zu haben. Datenschutzrechtlich haben diese drei Schichten aber nicht dieselbe Rolle. OpenCode läuft lokal und macht den Hersteller Anomaly nicht schon dadurch zum Auftragsverarbeiter, relevant wird er erst, soweit die Software Daten an eigene Dienste übermittelt, etwa an Telemetrie- oder Cloudfunktionen. Moonshot liefert die Modellgewichte, wer sie herunterlädt und selbst betreibt, übermittelt dorthin keine Repository-Daten. Der Inferenzanbieter dagegen ist regelmäßig Auftragsverarbeiter, sobald Prompts, Repository-Inhalte, Nutzungs- oder Metadaten personenbezogene Daten enthalten. Nutzt er dieselben Inhalte zusätzlich für eigenes Training, ist seine Rolle für diese Nutzung neu zu bewerten, mit der Einordnung als weisungsgebundener Auftragsverarbeiter ist es dann womöglich nicht getan. Artikel 28 DSGVO greift dort, wo jemand personenbezogene Daten im Auftrag verarbeitet, und nach Auffassung des EDSA wird eine weitere Stelle nur dann Teil der Unterauftragsverarbeitungskette, wenn ihr Tätigkeiten übertragen werden, die eine solche Verarbeitung erfordern.

Ob sich ein Anbieter auf eine Verarbeitung in der EU festlegt, steht im Auftragsverarbeitungsvertrag (AVV) und in der Subprozessorenliste. Am 30. Juli 2026 boten fünf Anbieter mit EU-Niederlassung oder ausdrücklicher EU-Standortzusage K3 an: Berget (SE), Nebius (NL), Melious (DE), HostYourAI (NL) und TensorX (IE). Diese fünf bilden meine K3-Marktstichprobe, auf sie beziehen sich die folgenden Befunde zu K3-Anbietern. Der ZDR-Vergleich weiter unten verwendet eine separate Stichprobe aus fünf Plattformbetreibern. Für die Auswahl sind vor allem die Vertragsunterschiede relevant. Zuvor muss geklärt sein, was der Agent in Ihrem Repository überhaupt sehen darf.

Sechs Fragen, die keine Preisseite beantwortet:

FrageWorauf achten?
Wer verarbeitet welche personenbezogenen Daten?Vertragspartner und vollständige Verarbeitungskette
Wo wird verarbeitet, und von wo ist ein Zugriff möglich?Konkreter Standort und Betreiber statt „Europa“, dazu die Transfergrundlage
Was wird gespeichert, wie lange, mit welchen ZDR-Ausnahmen?Löschfrist je Datenart und das Verhalten der Sicherheitsklassifikatoren
Werden Inhalte für Training oder Modellverbesserung genutzt?Ausschluss im Vertrag, nicht nur im Marketing
Wie sind Verfügbarkeit, Vorfälle und Lieferantenrisiken abgesichert?Zuständigkeiten und Nachweise, bei NIS2-Pflicht zusätzlich dokumentiert
Welches Modell, welche Version, welche Quantisierung laufen?Technische Beschaffung: Modell-ID, Format und Status

Die ersten vier Fragen sind datenschutzrechtlich relevant, soweit personenbezogene Daten betroffen sind. Bei Frage fünf fallen Sicherheit und Verfügbarkeit der Verarbeitung unter Artikel 32 DSGVO. Das allgemeine Lieferantenrisiko gehört zur Informationssicherheit und bei nach dem BSIG erfassten wichtigen oder besonders wichtigen Einrichtungen zusätzlich in die NIS2-Prüfung. Frage sechs ist technische Beschaffung und Qualitätskontrolle.

Befund 1: US-Rechtsträger in der Verarbeitungskette erfordern eine Transferprüfung

Die Subprozessorenliste von HostYourAI unterscheidet seit dem 31. Juli 2026 zwischen dem Sitz des Rechtsträgers und dem Ort der Verarbeitung. Für den europäischen Standardbetrieb nennt sie TensorX (Irland), Scaleway (Frankreich), Mistral AI (Frankreich), Nebius (Niederlande) und UpCloud (Finnland). Plattform und Datenbank werden in Amsterdam betrieben. Vast.ai, Inc. und RunPod, Inc. bleiben als US-Gesellschaften mit Verarbeitung in EU-Rechenzentren gelistet. Über RunPod lief laut Anbieter zum Stichtag kein Datenverkehr. Der optionale „Sovereignty Mode“ schließt beide aus, dazu Nebius und alle vom Kunden zusätzlich eingebundenen Anbieter. Das AVV-Muster (Version 1.0, 31. Juli 2026) untersagt jede Nutzung von Kundendaten zum Training, ausdrücklich auch durch Subprozessoren. Eine belastbare Preisangabe für K3 konnte ich der Preisliste nicht entnehmen, die dort genannten Tarife sind ausdrücklich nur Richtwerte. Abruf aller Angaben: 1. August 2026.

Auch Nebius nennt mit Eigen AI, Inc. (US) einen US-Rechtsträger für Inferenzleistungen. Melious listet zwölf Inferenz-Subprozessoren in acht Ländern, alle in der EU oder im EWR, ist aber ein Router ohne eigene Recheninfrastruktur. Die Belastbarkeit der Zusage hängt damit davon ab, welchen nachgelagerten Anbieter Melious je Anfrage auswählt.

Ein US-Rechtsträger in der Liste ist für sich genommen kein Verstoß und auch kein Beleg dafür, dass Daten physisch in den USA landen. Er löst vier Prüfschritte aus: Erhält dieser Rechtsträger personenbezogene Daten oder Zugriff darauf, welche Verarbeitung übernimmt er, liegt darin eine Übermittlung in ein Drittland, und auf welche Transfergrundlage samt zusätzlicher Schutzmaßnahmen stützt sie sich? Artikel 44 DSGVO verbietet solche Übermittlungen nicht, er bindet sie an Kapitel V. Bei HostYourAI ist die Frage konkret zu beantworten, denn Vast.ai und RunPod stehen ausdrücklich als Unterauftragsverarbeiter in der Liste, Prompt- und Antwortinhalte sind als vorübergehend verarbeitete Daten benannt, und der AVV sieht für erforderliche Übermittlungen Standardvertragsklauseln vor. Ein EU-Rechenzentrum allein erledigt diese Prüfung nicht.

EUrouter ist ein zusätzlicher Vergleichsfall und gehört nicht zur K3-Marktstichprobe.

Befund 2: ZDR ist nicht einheitlich definiert und nicht dauerhaft garantiert

Für Zero Data Retention (ZDR) gibt es keine verbindliche Definition, weder in der DSGVO noch in der KI-Verordnung, in EDSA-Leitlinien oder in ISO-Normen. Von den fünf geprüften Plattformbetreibern (OpenAI, Anthropic, Google, AWS Bedrock, Azure AI Foundry) garantiert keiner unter allen Umständen den vollständigen Verzicht auf Speicherung. Google erlaubt RAM-Caching mit einer TTL von 24 Stunden, AWS beschränkt seinen Modus none auf „durable storage“, Anthropic bewahrt Ergebnisse des Sicherheitsklassifikators auf. Anthropic hebt ZDR für bestimmte „Covered Models“ zum 9. Juni 2026 auf, Prompts und Ausgaben werden dann auch bei ZDR-Kunden 30 Tage gespeichert.

Die konkrete Prüffrage lautet deshalb: Gilt der ZDR-Modus auch bei einem Treffer des Sicherheitsklassifikators, und was wird dann wie lange aufbewahrt? TensorX speichert Prompts, Eingaben und Ausgaben laut AVV nicht und schließt ihre Nutzung zum Training und Fine-Tuning ausdrücklich aus. Die 45 Tage, die in diesem Vertrag stehen, betreffen etwas anderes: sonstige personenbezogene Kundendaten. Auf schriftliche Anfrage gibt TensorX diese innerhalb der Frist zurück oder löscht sie, die Wahl trifft der Kunde. Die Erfüllung dieser Klausel muss TensorX bestätigen. Wer die Frist auf die Inferenzdaten bezieht, liest den Vertrag falsch. Bei Nebius muss ZDR dagegen ausdrücklich aktiviert werden, standardmäßig ist es deaktiviert.

Befund 3: Von drei geprüften Endpunkten nennt nur Berget die Quantisierung

Diese Frage ist kein Datenschutzthema, sondern technische Beschaffung. Sie beeinflusst, ob eine gemessene Qualität reproduzierbar ist und ob zwei Angebote vergleichbar sind. Das veröffentlichte K3-Modell nutzt MXFP4 für die Gewichte und MXFP8 für die Aktivierungen, eine BF16-Version liegt nicht vor. Von den sechs Fragen habe ich nur diese selbst per API an drei Endpunkten geprüft. Bergets /v1/models nennt je Modell eine Quantisierung, moonshotai/Kimi-K3 ist dort als INT4-Variante mit lifecycle_state: "eval" gekennzeichnet. TensorX liefert nur id, object, created und owned_by, Nebius nennt das Format ebenfalls nicht. Die API-Angabe erhöht die Transparenz, belegt aber nicht, welche Gewichte der Dienst tatsächlich geladen hat.

Befund 4: Verfügbarkeit und Lieferantenrisiken sind eine eigene Prüfung

Soweit personenbezogene Daten verarbeitet werden, verlangt Artikel 32 DSGVO angemessene Verfügbarkeit und Belastbarkeit sowie regelmäßige Wirksamkeitsprüfungen. Das allgemeine Lieferantenrisiko reicht darüber hinaus. Für regulierte Unternehmen kommt dieselbe Anbieterkette deshalb ein zweites Mal auf den Tisch, dann unter dem Gesichtspunkt der Cybersicherheit: Geschäftskontinuität, sichere Beschaffung, Schwachstellenmanagement, Wirksamkeitskontrollen und die Risiken direkter Lieferanten und Dienstleister. Um Löschfristen oder Drittlandübermittlungen geht es dabei nicht. Das seit dem 6. Dezember 2025 geltende BSIG erfasst allerdings nicht jedes Unternehmen. Es gilt für bestimmte Sektoren oberhalb festgelegter Schwellenwerte bei Beschäftigten, Umsatz und Bilanzsumme und unterscheidet dort zwischen wichtigen und besonders wichtigen Einrichtungen. Wer nicht darunterfällt, hat trotzdem gute Gründe, dieselben Punkte zu klären, nur eben als Beschaffungspraxis und nicht als Pflicht.

Zertifizierungen ersetzen keine der sechs Prüfungen. Artikel 32 Absatz 3 nennt genehmigte Verhaltensregeln nach Artikel 40 und genehmigte Zertifizierungsverfahren nach Artikel 42 als mögliche Nachweismittel. ISO 27001 und SOC 2 sind damit nicht gleichzusetzen, sie können aber Hinweise auf die Qualität des Sicherheitsmanagements liefern. Eine solche Prüfung belegt weder den Verarbeitungsort noch die vollständige Unterauftragsverarbeitungskette. TensorX kennzeichnet ISO 27001 als „In Progress“ und SOC 2 Type II als „Planned“.

Vertrag und Durchsetzbarkeit

Für Artikel 28 DSGVO zählt die Identität des Vertragspartners. Welches Recht gilt und welches Gericht zuständig ist, entscheidet dagegen nicht über die Datenschutzkonformität, sondern darüber, wie gut sich der Vertrag im Streitfall durchsetzen lässt. Für TensorX Limited gilt irisches Recht, für Nebius B.V. und Doornbos Ventures B.V. (HostYourAI, Amsterdam) niederländisches Recht. Die Melious AI GmbH sitzt in Saarbrücken, ihr AVV regelt weder Rechtswahl noch Gerichtsstand.

Der Direktbezug über Moonshot fällt aus dieser Reihe heraus. Vertragspartner ist MOONSHOT AI PTE. LTD. in Singapur, und die Nutzung der Inhalte zur Modellverbesserung ist nach den allgemeinen Bedingungen erlaubt, solange keine abweichende Enterprise-Vereinbarung besteht. Die Datenschutzerklärung nennt Singapur ausdrücklich als Speicher- und Verarbeitungsort, auch für Nutzer aus dem EWR. In den von mir geprüften öffentlichen Unterlagen fand ich jedoch weder einen AVV noch konkrete Standardvertragsklauseln oder eine vollständige Liste der beteiligten Dienstleister. Für Singapur besteht kein Angemessenheitsbeschluss der EU.

Warum das Urteil über Kimi K3 noch offen ist

Kimi K3 wurde am 27. Juli 2026 von Moonshot AI veröffentlicht, vier Tage vor meinem Test. Das Modell umfasst insgesamt 2,8 Billionen Parameter, von denen pro Token 104 Milliarden aktiviert werden, und das Kontextfenster fasst 1.048.576 Token. Moonshot ordnet K3 im Abstract des technischen Berichts (arXiv 2607.24653) selbst hinter Claude Fable 5 und GPT-5.6 Sol ein. Diese Einordnung fällt zuungunsten des eigenen Produkts aus.

Zahlreiche Berichte nennen als Lizenz „MIT“. Das ist falsch. Die ausgelieferte Datei heißt „Kimi K3 License“ und enthält eine Klausel zu Model as a Service, die K2 noch nicht hatte: Wer K3 als Dienst anbietet und in zwölf aufeinanderfolgenden Monaten mehr als 20 Mio. US-Dollar Umsatz erzielt, braucht eine gesonderte Vereinbarung mit Moonshot. Für eine rein interne Nutzung greift die Schwelle nach meiner Auslegung nicht, das ist kein Rechtsrat. Moonshot veröffentlicht die vollständigen Modellgewichte unter der eigenen Kimi-K3-Lizenz. Trainingsdaten und eine vollständige Trainingspipeline gehören nicht dazu. K3 ist damit ein Open-Weights-, aber kein vollständiges Open-Source-Modell.

Nach einer unabhängigen Qualitätsmessung von K3 im Zusammenspiel mit OpenCode habe ich gezielt gesucht, zum 30. Juli 2026 lag mir keine vor. Selbst im Terminal-Bench 2.1 schwanken die veröffentlichten Werte für dieselbe Modellversion zwischen 80,9 Prozent (Vals.ai), 85,0 Prozent (Artificial Analysis) und 88,3 Prozent (Moonshot selbst). Dieselbe Versionsangabe belegt weder identische Gewichte noch identische Quantisierung oder Inferenzkonfiguration.

Selbsthosting ist für K3 keine einfache Ausweichlösung. Die Modellgewichte umfassen rund 1,56 Terabyte, vLLM nennt mindestens acht B300-GPUs als geeignete Konfiguration. Für einzelne Entwicklungsteams ist ein externer Endpunkt deshalb meist wirtschaftlicher. Welche Betriebsform sich wirtschaftlich trägt, erläutern die vier Stufen zwischen SaaS und Air-Gap.

Fazit

Die Anbindung funktioniert. Sie hält einen technischen Wechsel des Inferenzanbieters offen, aus einem EU-Endpunkt folgt jedoch noch keine DSGVO-konforme Nutzung. Für den Datenschutz zählen die tatsächlich verarbeiteten personenbezogenen Daten, die Verarbeitungskette, mögliche Drittlandübermittlungen, Aufbewahrungsfristen und die konkrete Kontokonfiguration. Für die Informationssicherheit kommen Verfügbarkeit, Lieferantenrisiken und Sicherheitsnachweise hinzu. Modell-ID und Quantisierung bleiben technische Beschaffungsfragen. Vertraglich hat der getestete Aufbau einige Vorteile: Vertragspartner ist TensorX Limited, es gilt irisches Recht, und als Standorte sind Dublin (Digital Realty) und Helsinki (Verda) samt Betreiber benannt. Was fehlt, sind abgeschlossene Zertifizierungen. Kimi K3 hat die Aufgabe in allen drei Läufen gelöst. Ob das Modell auch für anspruchsvollere Aufgaben genügt, muss ein Eval-Set aus dem eigenen Repository zeigen. Die zusätzliche Wechselmöglichkeit erkauft sich das Team mit mehr Betriebsaufwand: Sobald sich der Katalog ändert, muss jemand opencode.json und die Provider-Konfiguration nachziehen.

Drei Schritte für diese Woche:

  1. Legen Sie Auftragsverarbeitungsvertrag und Subprozessorenliste nebeneinander. Verfolgen Sie die Verarbeitungskette bis zu jedem Unterauftragsverarbeiter, der Prompt-, Ausgabe-, Konto- oder Telemetriedaten verarbeitet oder darauf zugreifen kann. Identität und Aufgabe müssen Sie kennen, ob Sie zusätzlich die nachgelagerten Verträge einsehen, richtet sich nach dem Risiko der konkreten Verarbeitung. Die übrige technische Lieferkette erfassen Sie getrennt, sie gehört in die Prüfung von Sicherheit und Verfügbarkeit. Ein Eintrag mit dem Vermerk „Planned“ ist keine aktive Infrastruktur.
  2. Stellen Sie dem Anbieter zwei Fragen per E-Mail. Erstens: In welchem Format wird das Modell bereitgestellt, nativ oder nachträglich requantisiert? Zweitens: Gilt der ZDR-Modus auch dann, wenn ein Sicherheitsklassifikator anschlägt? Ausbleibende Antworten gehören ins Beschaffungsprotokoll. Ich selbst habe diese Fragen bei zwei der geprüften Anbieter noch nicht gestellt.
  3. Führen Sie dieselbe Aufgabe dreimal aus. Prüfen Sie danach zuerst den erzeugten Regressionstest, nicht den Diff am Produktivcode.

Quellen

Alle Anbieter- und Herstellerdokumente wurden am 30. Juli 2026 abgerufen, die HostYourAI-Seiten, der unter tensorx.ai veröffentlichte AVV und die Aufbewahrungsdokumentation der fünf Plattformbetreiber am 1. August 2026. Die eigenen Testläufe stammen vom 31. Juli 2026. Anbieterpreise, ZDR-Stufen und Bergets lifecycle_state können sich kurzfristig und ohne gesonderte Ankündigung ändern. Vor einer Beschaffungsentscheidung sollten diese Angaben anhand der jeweils verlinkten Primärquelle erneut geprüft werden. Bei zwei Einträgen fehlt ein Link, weil mir dafür keine geprüfte URL vorliegt. Dort nenne ich nur das Dokument.

Weiterlesen
Großes Prozentbanner neben einer Werkbank, an der eine Person eigene Tickets mit einer Schieblehre prüft
·de

SWE-bench ist kein Einkaufstest: So bauen Sie ein internes Eval-Set für Coding Agents

Person mit Laterne vor einer Wand nummerierter Archivschubladen, drei davon geöffnet und miteinander verbunden
·de

Spec-Driven Development im Team: Zuständigkeiten, Freigabe und Pflege regeln

Nächster Schritt

Interesse an AI-Training für Ihr Entwicklerteam? Coding Agents meistern: 3 Tage, die den Unterschied machen.

Lesen Sie hier regelmäßig mit? Sie können antonioagudo.com bei Google als bevorzugte Quelle markieren, damit diese Inhalte in Ihren Suchergebnissen sichtbarer bleiben.