← Zurück zum Blog
kidsgvocomplianceinfercheckopen-data

InferCheck: Warum ich 347 KI-Modelle nach DSGVO-Konformität katalogisiert habe

Veröffentlicht am 8 Min. Lesezeit

Wer schon mal eine DSGVO-konforme KI-API für ein Produktivsystem auswählen musste, kennt das Prozedere. Man startet auf der Marketing-Seite des Anbieters. Dort steht „Enterprise-grade Security" und „SOC 2 zertifiziert." Beides beantwortet nicht die Frage, die beantwortet werden muss: Findet die Inferenz innerhalb der EU statt, und trainiert der Anbieter mit den Daten, die ich sende?

Man klickt sich zum DPA durch. Falls es eins gibt. Falls man es findet. Falls es nicht hinter einem Sales-Call versteckt ist.

Das Ganze mal zehn Anbieter, die evaluiert werden. Dann nochmal nächstes Quartal, wenn sich die Modell-Landschaft verschoben hat. Genau dieses Problem löst InferCheck: ein neutrales, strukturiertes DSGVO-KI-Anbieterverzeichnis — 347 Modelle von 111 Anbietern, filterbar nach den Compliance-Eigenschaften, die für EU-Unternehmen relevant sind.

Das eigentliche Problem

Der KI-Inferenz-Markt bewegt sich schnell. OpenAI ist bei GPT-5.4 angekommen. Anthropic liefert Claude Opus 4.6 und Sonnet 4.6. Google hat Gemini 3.1 Pro in der Preview. Mistral, Qwen und ein Dutzend Open-Weight-Modellfamilien sind über mehrere Inferenz-Anbieter verfügbar.

Für ein EU-Team, das ein Produkt baut, das personenbezogene Daten verarbeitet, geht es bei der Modellauswahl nie nur um Leistung. Es geht um Leistung plus Datenresidenz plus DPA-Verfügbarkeit plus Trainingsrichtlinie. Und diese Compliance-Fakten sind verstreut über Rechtsseiten, Trust Center und Support-Tickets, die möglicherweise nicht aktuell sind.

An Modell-Benchmarks mangelt es nicht. An Compliance-Benchmarks schon.

Drei Schmerzpunkte kamen in Projekten, die ich für DACH-Startups gebaut habe, immer wieder auf:

  1. Entwickler wählen zuerst das Modell, dann entdecken sie die Compliance-Situation. Wenn Legal das Problem flaggt, ist die Integration halb fertig.
  2. Compliance-Informationen sind vom Anbieter verfasst. Marketing-Abteilungen schreiben DPA-Zusammenfassungen. Neutrale, strukturierte Vergleiche gibt es nicht.
  3. Die Landschaft ändert sich schneller als Compliance-Reviews. Ein Anbieter startet EU-Inferenz-Regionen, unterschreibt ein neues DPA, ändert Trainings-Defaults — und niemand aktualisiert die interne Tabelle.

Was InferCheck macht

InferCheck ist ein Verzeichnis. Keine SaaS-Plattform, kein Compliance-Tool, keine Rechtsberatung. Eine Referenzdatenbank mit Suchinterface.

Man kommt rein, sucht nach einem Modell — sagen wir claude-opus-4-6 — und sieht jeden Anbieter, der es anbietet. Für jeden Anbieter gibt es: Compliance-Status, Datenresidenz, DPA-Verfügbarkeit, Trainingsrichtlinie, Preise und das Datum der letzten Verifizierung. Jede Angabe verlinkt zurück zum Quelldokument.

Compliance-Filterprofile

Vier Filterprofile decken die häufigsten EU-Anforderungen ab:

  • Strict EU — Daten in der EU gespeichert, Inferenz-Compute in der EU, DPA verfügbar. Das ist der „Unsere Rechtsabteilung hat EU-only gesagt"-Filter.
  • EU + SCCs — DPA verfügbar, Standardvertragsklauseln vorhanden, kein Training mit Kundendaten. Deckt Anbieter wie OpenAI und Anthropic ab, die in den USA verarbeiten, aber SCCs unterzeichnet haben.
  • Kein Training — hartes Opt-out vom Modelltraining, unabhängig von der Geographie. Für Teams, bei denen Datenleckage in Modellgewichte die rote Linie ist.
  • Custom — einzelne Toggles. Eigene Filterkombination zusammenstellen.

Jede gefilterte Ansicht ist URL-persistent. Man teilt den Link mit der Rechtsabteilung. Sie sehen dieselbe Tabelle. Keine Accounts, kein Login, kein „Demo vereinbaren."

Das Farbsystem

Der Compliance-Status nutzt ein striktes Ampelschema:

  • Grün — EU Only. Daten bleiben in der EU, Inferenz in der EU, DPA verfügbar.
  • Gelb — EU + SCCs oder teilweise konform. Nutzbar mit vertraglichen Absicherungen.
  • Rot — nicht konform für EU-Zwecke. Nur US-/CN-Verarbeitung, trainiert mit Daten, oder kein DPA.
  • Grau — nicht verifiziert. Keine Daten verfügbar, oder Anbieter hat nicht genug Informationen veröffentlicht.

Diese Farben sind reserviert für Compliance-Signale. Sie tauchen nie als UI-Dekoration auf.

Die Datenarchitektur

Das ist der Teil, der für Vertrauen am wichtigsten ist: Die Daten sind flaches JSON, committed in ein öffentliches Git-Repository.

111 Anbieter-Dateien

Jeder Anbieter hat eine JSON-Datei in data/providers/. Die Datei folgt einem Zod-validierten Schema und enthält strukturierte Felder: Datenresidenz-Regionen, Inferenz-Standorte, DPA-URL, Trainingsrichtlinie, Opt-out-Mechanismus, SCC-Status, EU-AI-Act-Status, Zertifizierungen und Quell-URLs für jede Angabe.

{
  "name": "Anthropic",
  "slug": "anthropic",
  "compliance": {
    "dataResidency": ["US", "EU", "CA", "JP"],
    "inferenceLocation": ["US", "EU"],
    "dpaAvailable": true,
    "dpaUrl": "https://www.anthropic.com/dpa",
    "trainingPolicy": "no_training",
    "sccStatus": "signed",
    "lastVerified": "2026-04-07"
  }
}

Warum flaches JSON? Weil Git-Diffs lesbar sind. Weil jeder eine Korrektur per Pull Request einreichen kann. Weil ein Compliance-Team den gesamten Datensatz in einer Verzeichnisliste auditieren kann. Keine Datenbankabfragen, keine Admin-Panels, keine undurchsichtigen Datentransformationen zwischen Speicherung und Anzeige.

Modellkatalog via Neon

Die Modelldaten liegen in Postgres (Neon) via Drizzle ORM. Modelle ändern sich zu schnell für manuelle Pflege — neue Varianten erscheinen wöchentlich, Preise werden angepasst, ältere Versionen deprecated. Ein nächtlicher Vercel-Cron-Job um 2 Uhr UTC synchronisiert Modelldaten von OpenRouter und EU-nativen Anbieter-APIs.

Die Aufteilung ist Absicht: langsam ändernde Compliance-Metadaten in Git (auditierbar, community-editierbar), schnell ändernde Modell-Metadaten in einer Datenbank (automatisierbar, abfragbar).

Community-Korrekturen

Jede Anbieterseite hat einen „Report a change"-Button. Er öffnet ein vorausgefülltes GitHub-Issue. Kein Account außer GitHub nötig. Das Issue wird gelabelt, geprüft und gemergt, wenn es valide ist. Alle Reports sind öffentlich.

Das löst das Veralterungsproblem, ohne einen Vollzeit-Compliance-Analysten zu benötigen. Die Leute, die bemerken, dass ein Anbieter sein DPA aktualisiert hat, sind die Leute, die das DPA lesen — Entwickler und Rechtsteams, die mit dem Anbieter arbeiten.

Was die Daten zeigen

Über 111 Anbieter und 347 Modelle hinweg fallen einige Muster auf.

EU-Only-Inferenz ist verfügbar — wenn man weiß, wo

Anbieter wie Mistral, Scaleway, OVHcloud, STACKIT, Berget AI und Amazon Bedrock (via EU-Regional-Endpoints) bieten strikte EU-Only-Inferenz. Google Vertex AI liefert Gemini-Modelle aus EU-Regionen. Claude lässt sich auf Bedrocks Frankfurt-Endpoint betreiben.

Die Optionen sind da. Sie sind nicht immer die günstigsten oder offensichtlichsten, aber sie existieren. InferCheck macht sie in einer Tabelle auffindbar statt über ein Dutzend Marketing-Seiten verteilt.

Die großen US-Anbieter sind Gelb, nicht Rot

OpenAI und Anthropic bieten beide unterzeichnete DPAs, SCCs und No-Training-on-API-Data-Richtlinien. Das setzt sie auf Gelb — nutzbar für viele EU-Workloads, wenn der richtige vertragliche Rahmen steht. Nicht EU-only, aber vertretbar.

Das ist wichtig, weil die Compliance-Diskussion oft binär geführt wird: konform oder nicht. In der Praxis ist es ein Spektrum. Ein Produkt, das pseudonymisierte Analysedaten verarbeitet, hat ein anderes Risikoprofil als eines, das Patientenakten verarbeitet. InferCheck zeigt die Fakten; die Risikobewertung liegt bei einem selbst.

Die rote Zone ist auch informativ

DeepSeek verarbeitet in China und trainiert mit Daten. Mehrere kleinere Anbieter haben kein veröffentlichtes DPA. Manche bieten nur US-Inferenz ohne SCCs. Zu wissen, was nicht besteht, ist genauso nützlich wie zu wissen, was besteht — es spart die Evaluierungszeit, bevor man mit der Integration anfängt.

Warum offene Daten hier wichtig sind

Compliance-Verzeichnisse sind nutzlos, wenn man die zugrunde liegenden Daten nicht verifizieren kann. Die schlechteste Version dieses Produkts wäre eine proprietäre Datenbank hinter einer Paywall, bei der man der Interpretation eines Anbieters über das DPA eines anderen Anbieters vertrauen muss.

InferChecks Daten sind unter CC BY-NC-SA 4.0 lizenziert. Der Code ist MIT. Man kann das Repo klonen, jede Angabe auditieren und jeden Datenpunkt bis zur Quelle zurückverfolgen. Wenn man mit einer Klassifizierung nicht einverstanden ist, kann man einen PR öffnen. Wenn ein Anbieter seine Bedingungen aktualisiert, kann die Community das flaggen, bevor der nächste nächtliche Sync läuft.

Das ist ein bewusster Trade-off. Proprietäre Daten sind einfacher zu monetarisieren. Offene Daten sind einfacher zu vertrauen. Für ein Compliance-Referenz-Tool ist Vertrauen das Produkt.

Wie es in den Stack passt

Ich habe InferCheck auf demselben Stack gebaut, den ich für Kunden-MVPs bei CodeAttack verwende: Next.js, TypeScript, Postgres auf Neon, deployed auf Vercel. Der Data-Layer ist Drizzle ORM. Die Anbieter-JSON-Dateien werden zur Build-Zeit mit Zod validiert.

Der nächtliche Sync-Job ist eine Vercel-Cron-Funktion — nichts Exotisches. Er ruft die OpenRouter-API auf, mappt Modelle zu Anbietern, aktualisiert Preise und schreibt in die Neon-Datenbank. EU-native Anbieter-Adapter (Scaleway, STACKIT, OVHcloud) stehen auf der Roadmap für direkten API-Sync.

Die Gesamtinfrastrukturkosten sind minimal. Der teure Teil war, 111 DPAs zu lesen und das Schema aufzubauen, um das Gefundene zu strukturieren.

Was InferCheck nicht macht

Es ist kein Compliance-Tool. Es erstellt keine DSGVO-Dokumentation und führt keine Risikobewertungen durch. Es zertifiziert keine Anbieter. Es ersetzt keinen Rechtsbeistand.

Es ist ein Referenzverzeichnis. Genauso wie man den Benchmark-Score eines Modells prüft, bevor man es auswählt, prüft man sein Compliance-Profil. InferCheck stellt dieses Profil dorthin, wo es immer schon hätte sein sollen: neben den Modellnamen, in einem strukturierten, filterbaren, verifizierbaren Format.

Aktueller Stand und Ausblick

InferCheck ist live unter infercheck.eu mit 347 Modellen und 111 Anbietern. Der Modellkatalog synchronisiert sich nächtlich. Anbieter-Compliance-Daten werden manuell und über Community-Reports aktualisiert.

Nächste Schritte auf der Roadmap:

  • Anbietervergleich nebeneinander — zwei Anbieter auswählen, Compliance- und Preisunterschiede in einer Ansicht sehen.
  • DSGVO-Guides pro Anbieter — redaktionelle Inhalte, die das Datenverarbeitungs-Setup jedes Anbieters in verständlicher Sprache erklären.
  • EU-native Anbieter-Sync-Adapter — direkte API-Integration mit Scaleway, STACKIT, Aleph Alpha, OVHcloud und SAP AI Core.
  • E-Mail-Digest — wöchentliche Benachrichtigungen, wenn sich der Compliance-Status eines Anbieters ändert.
  • API-Zugang — strukturierte Compliance-Daten via REST-API für Teams, die es in ihre eigenen Tools integrieren wollen.

Das Ziel ist einfach: DSGVO-KI-Anbieter-Compliance von einem quartalsweisen Rechercheprojekt zu einem gelösten Nachschlageproblem machen.