Matrix zur Auswahl von KI-Anbietern und -Modellen
Ein vollständiger Entscheidungsrahmen zur Bewertung von KI-Anbietern über 8 Dimensionen. Von den Fehlermustern, gegen die Sie sich absichern sollten, über 25 RFP-Fragen bis zu 12 Warnsignalen — alles, was Sie brauchen, um den richtigen KI-Anbieter auszuwählen und kostspielige Abhängigkeit zu vermeiden.
Warum die Auswahl von KI-Anbietern scheitert
Wer einen LLM-Anbieter auf Basis einer kurzen Demo und eines wohlwollenden öffentlichen Benchmarks auswählt, lässt die entscheidenden Fragen offen: wie lange das Modell unterstützt wird, ob die Auftragsverarbeitungsvereinbarung des Anbieters Ihre Compliance-Prüfung besteht und was der Dienst bei Produktionsvolumen kostet. Jeder dieser Punkte lässt sich vor der Festlegung mit einer strukturierten Bewertung prüfen.
Wenn eine Anbieterauswahl schiefgeht, ist die Grundursache selten die Technologie. Es ist der Prozess — oder dessen Fehlen.
Abhängigkeitsrisiko
Anbieterspezifische Prompt-Formate, Function-Calling-Schemata und SDK-Muster summieren sich zu unsichtbaren Migrationsschulden. Ein Wechsel des LLM-Anbieters mitten im Projekt kostet Engineering-Zeit und Kalendermonate, und die Abhängigkeit kann unbemerkt bleiben, bis eine Einstellungsmitteilung oder eine Preiserhöhung eintrifft.
Hype vs. Realität
Öffentliche Benchmarks (MMLU, GPQA, HumanEval) messen allgemeine akademische Fähigkeiten. Ihre Produktionslast ist nicht allgemein. Ein Modell auf Platz 1 bei MMLU kann bei Ihrer spezifischen Vertragsextraktion oder Kundensupport-Aufgabe auf Platz 4 landen. Entscheidungen, die auf Benchmarks ohne domänenspezifischen Pilotbetrieb beruhen, enttäuschen regelmäßig.
Die verborgenen Kosten
Die API-Preisgestaltung pro Token ist nur ein Teil der tatsächlichen KI-Infrastrukturausgaben. Egress-Gebühren, Fine-Tuning-Rechenleistung, Compliance-Audits, Support-Upgrades und Migrations-Engineering stehen nicht auf der Token-Rechnung. Ein Budget, das nur Tokens abdeckt, ist mit wachsender Nutzung Überschreitungen ausgesetzt.
Drei Fehlermuster, gegen die Sie sich absichern sollten
Die 8 Bewertungsdimensionen
Jede Auswahl eines KI-Anbieters sollte über diese acht Dimensionen bewertet werden. Die folgenden Standardgewichtungen eignen sich für ein Großunternehmen, das LLM-Infrastruktur in einem regulierten europäischen Kontext einsetzt — passen Sie die Gewichtungen an Ihre spezifischen Prioritäten an. Ein CISO im Gesundheitswesen wird die Sicherheit mit 35 % gewichten. Ein Start-up im Wettlauf um den Markt gewichtet die technische Leistung vielleicht mit 40 %.
Die Gewichtungen müssen sich auf 100 summieren. Die Abschnitte 3, 4 und 5 vertiefen die drei am stärksten gewichteten Dimensionen.
Technische Leistung
Modellqualität bei Ihren spezifischen Aufgaben, Latenz, Durchsatz und Genauigkeit unter realistischen Bedingungen.
Sicherheit und Compliance
Zertifizierungen (SOC 2, ISO 27001, HIPAA), Datenresidenz, GDPR-Haltung, Ausrichtung am EU AI Act.
Gesamtbetriebskosten
API-Preisgestaltung, Trainingskosten, versteckte Gebühren, Egress, Support-Stufen und Migrations-Engineering-Aufwand.
Support und SLAs
Verfügbarkeitsgarantien, Reaktionszeiten des Supports, dedizierter CSM, Verfügbarkeit einer Enterprise-Stufe.
Integration und Ökosystem
SDK-Qualität, Framework-Kompatibilität (LangChain, LlamaIndex), CI/CD-Integration, Dokumentation.
Roadmap und Stabilität des Anbieters
Finanzielle Reserven, Veröffentlichungsrhythmus der Modelle, Einstellungsrichtlinie, Ausrichtung an Ihrer Produkt-Roadmap.
Compliance und regulatorische Passung
Branchenspezifische Anforderungen — HIPAA im Gesundheitswesen, PCI-DSS im Fintech, Risikoeinstufung nach dem EU AI Act.
Ausstiegsstrategie und Portabilität
Mechanismen für den Datenexport, Modellportabilität, Migrationspfad, vertragliche Ausstiegsklauseln.
Ablaufdiagramm des Bewertungsprozesses
flowchart TD
A([Start: Vendor Evaluation]) --> B[Discovery & Requirements]
B --> B1[Define use case & constraints]
B --> B2[Set must-have criteria]
B --> B3[Identify 15-20 candidate vendors]
B1 & B2 & B3 --> C[Initial Shortlist]
C --> C1[Apply MoSCoW filter]
C1 --> C2{Passes must-haves?}
C2 -- No --> X1[Eliminate]
C2 -- Yes --> D[PoC / Pilot Phase]
D --> D1[Technical benchmark on your data]
D --> D2[Security review & DPA check]
D --> D3[Pricing & TCO modelling]
D1 & D2 & D3 --> E[Weighted Scoring Matrix]
E --> E1[Score top 3 vendors]
E1 --> F[Commercial Negotiation]
F --> F1[SLA terms]
F --> F2[Data processing agreement]
F --> F3[Exit clause negotiation]
F1 & F2 & F3 --> G([Vendor Selected])
style A fill:#1a1a2e,stroke:#7c3aed,color:#e2e8f0
style B fill:#1e293b,stroke:#475569,color:#e2e8f0
style B1 fill:#1e293b,stroke:#475569,color:#e2e8f0
style B2 fill:#1e293b,stroke:#475569,color:#e2e8f0
style B3 fill:#1e293b,stroke:#475569,color:#e2e8f0
style C fill:#1e293b,stroke:#6366f1,color:#e2e8f0
style C1 fill:#1e293b,stroke:#475569,color:#e2e8f0
style C2 fill:#1e1b4b,stroke:#6366f1,color:#e2e8f0
style D fill:#1e293b,stroke:#3b82f6,color:#e2e8f0
style D1 fill:#1e293b,stroke:#475569,color:#e2e8f0
style D2 fill:#1e293b,stroke:#475569,color:#e2e8f0
style D3 fill:#1e293b,stroke:#475569,color:#e2e8f0
style E fill:#1e293b,stroke:#8b5cf6,color:#e2e8f0
style E1 fill:#1e293b,stroke:#475569,color:#e2e8f0
style F fill:#1e293b,stroke:#f59e0b,color:#e2e8f0
style F1 fill:#1e293b,stroke:#475569,color:#e2e8f0
style F2 fill:#1e293b,stroke:#475569,color:#e2e8f0
style F3 fill:#1e293b,stroke:#475569,color:#e2e8f0
style X1 fill:#1f0d0d,stroke:#ef4444,color:#e2e8f0
style G fill:#0d1f12,stroke:#22c55e,color:#e2e8f0Dimension 1 im Detail: Technische Leistung
Standardgewichtung: 25 %
Die Bewertung der technischen Leistung hat drei Komponenten: Benchmark-Methodik, Messung von Latenz und Durchsatz sowie Genauigkeitstests in Ihrer spezifischen Domäne. Alle drei müssen vor einer Festlegung durchgeführt werden.
Benchmark-Methodik
Öffentliche Benchmarks sind ein Ausgangspunkt, kein Entscheidungskriterium. MMLU prüft breites akademisches Wissen. HumanEval prüft die Generierung von Python-Code. Keiner prüft Ihre spezifische Aufgabe. Erstellen Sie aus echten Produktionsdaten einen domänenspezifischen Bewertungssatz, bevor Sie einen Anbietervergleich durchführen.
Aufbau des Bewertungssatzes
- 100 bis 500 Beispiele aus echten Produktionsdaten
- Randfälle und bekannte Fehlermuster einbeziehen
- Leichte, mittlere und schwere Schwierigkeit abdecken
- Für Ihren Anwendungsfall relevante adversariale Prompts einbeziehen
- Ground-Truth-Labels mit menschlichen Annotatoren erstellen
Genauigkeitsmetriken nach Aufgabentyp
- Extraktion: F1-Score zur Genauigkeit von Entität/Wert
- Klassifikation: Precision, Recall, F1 pro Klasse
- Generierung: menschliche Bewertung + ROUGE/BERTScore
- Schlussfolgern: Pass@1 und Pass@3 bei Logikaufgaben
- Halluzinationsrate: Überprüfung faktischer Aussagen
Latenz- und Durchsatzmetriken
Bewerten Sie die Latenz niemals mit einer einzelnen Anfrage. Messen Sie unter realistischer gleichzeitiger Last mit Ihrem erwarteten Produktionsverkehrsmuster. Die Demo-Latenz von Anbietern ist immer der Bestfall einer Einzelanfrage.
| Metrik | Was sie misst | Akzeptabler Schwellenwert | Wie zu messen |
|---|---|---|---|
| P50-Latenz | Mittlere Antwortzeit | < 400 ms bei einfachen Aufgaben | Lasttest bei 1x Produktionsvolumen |
| P95-Latenz | 95. Perzentil — die Untergrenze der Nutzererfahrung | < 1.200 ms bei komplexen Aufgaben | Lasttest bei 2x Produktionsvolumen |
| P99-Latenz | Schlimmster Fall — die schlechtesten 1 % der Nutzer | < 3.000 ms (SLA-Obergrenze) | Lasttest bei 3x Produktionsvolumen |
| Time to First Token | Wahrgenommene Geschwindigkeit bei Streaming-Antworten | < 300 ms beim P95 | TTFT getrennt von der Gesamtlatenz messen |
| Tokens/Sekunde | Generierungsdurchsatz pro Anfrage | > 40 Tokens/s für eine Echtzeit-UX | Token-Anzahl / gesamte Generierungszeit |
| Kapazität des Ratenlimits | Maximale gleichzeitige Anfragen / Tokens pro Minute | ≥ 2x Spitzen-Produktionsvolumen | Dokumentation prüfen + Burst-Verhalten testen |
Protokoll für Genauigkeitstests
- Bewertungssatz mit identischen Prompts gegen jeden Anbieter ausführen
- Genauigkeit, Latenz und Token-Anzahl pro Antwort erfassen
- Offensichtliche Halluzinationen oder Formatfehler kennzeichnen
- Prompts für jeden Anbieter unabhängig optimieren
- Genauigkeitsgewinn durch die Optimierung messen
- Prompt-Engineering-Aufwand pro Anbieter dokumentieren
- Adversariale Eingaben und bekannte Fehlermuster testen
- Leistung bei Dokumenten mit langem Kontext messen
- Verhalten an den Grenzen des Kontextfensters testen
Dimension 2 im Detail: Sicherheit und Compliance
Standardgewichtung: 20 %
Diese Prüfungen müssen vor dem PoC erfolgen, nicht danach. Ein Anbieter, der die Compliance-Hürde nicht nimmt, wird unabhängig von der technischen Leistung ausgeschlossen.
SOC 2 Type II
- Type II deckt einen Zeitraum von 6 bis 12 Monaten ab (keine Momentaufnahme)
- Den vollständigen Bericht unter NDA anfordern — eine Zusammenfassung genügt nicht
- Abgedeckte Trust Services Criteria prüfen: mindestens Security + Availability
- Das Management-Schreiben auf offene Ausnahmen oder Einschränkungen prüfen
- Glaubwürdigkeit der Prüfungsgesellschaft verifizieren (Big 4 oder anerkannter Spezialist)
ISO 27001
- Prüfen, ob das Zertifikat aktuell und nicht abgelaufen ist
- Den Geltungsbereich prüfen: deckt er die konkret genutzten Dienste ab?
- Cloud-gehostete KI-Dienste sollten Anhang A.17 (Betriebskontinuität) umfassen
- Zwischen einer ISO-27001-Zertifizierung und bloßen Compliance-Behauptungen unterscheiden
- Wo relevant mit ISO 27017 (Cloud-Sicherheit) und ISO 27018 (PII in der Cloud) kombinieren
GDPR und Auftragsverarbeitung
- Eine unterzeichnete DPA (Auftragsverarbeitungsvereinbarung) ist nach Art. 28 GDPR verpflichtend
- Liste der Unterauftragsverarbeiter und Genehmigungsrechte bei deren Wechsel prüfen
- Datenresidenz bestätigen: nur EU-Region, keine US-Übermittlung ohne SCCs
- Lösch-SLA verifizieren: wie schnell werden Daten bei Kündigung oder auf Anfrage gelöscht?
- Bestätigen, dass Prompts und Ausgaben niemals zum Modelltraining verwendet werden
Ausrichtung am EU AI Act
- Ihren KI-Anwendungsfall den Risikokategorien des EU AI Act zuordnen
- Hochrisiko-Anwendungsfälle (HR, Kredit, Gesundheit) erfordern Konformitätsbewertungen
- Eine Anbietererklärung zu den GPAI-Modellpflichten (Transparenz, Urheberrecht) anfordern
- Verifizieren, dass der Anbieter eine technische Dokumentation gemäß Art. 53 führt
- Die Position des Anbieters zu den Meldepflichten bei Vorfällen nach Art. 62 prüfen
Optionen zur Datenresidenz nach großen Anbietern
| Anbieter | EU-Region | Können Daten in der EU bleiben? | Self-Hosting-Option | DPA verfügbar |
|---|---|---|---|---|
| OpenAI (direkt) | Ja, für berechtigte Kunden (Region Europa) | Hängt von Tarif und Konfiguration ab. Ein Projekt mit der Region Europa speichert und verarbeitet Kundeninhalte dort; Systemdaten sind ausgenommen. | Nein | Ja (Enterprise) |
| OpenAI via Azure | Ja (EU-Regionen und eine EU Data Zone) | Ja, mit einer regionalen Bereitstellung (EU-Geografie) oder EU Data Zone. Nicht mit Global-Bereitstellungen oder Batch. | Nein | Ja (Azure DPA) |
| Anthropic (direkt) | Nicht verfügbar | Nein. Daten werden in den USA gespeichert; die Inferenz läuft in den USA oder weltweit. | Nein | Ja (Enterprise) |
| Anthropic via Bedrock | Ja (EU-Regionen) | Ja, mit einem geografischen EU-Inferenzprofil. Nicht mit einem globalen Profil. | Nein | Ja (AWS DPA) |
| Mistral (direkt) | Ja (standardmäßig EU) | Standardmäßig. Einige Funktionen übertragen Daten vorübergehend aus der EU heraus, und der US-Endpunkt hostet Daten in den USA. | Offene Gewichte | Ja (Standard) |
| Google Vertex AI | Ja (EU-Regionen und eine EU-Multiregion) | Ja, mit einem regionalen oder EU-multiregionalen Endpunkt. Nicht mit dem globalen Endpunkt. | Nein | Ja (GCP DPA) |
Die Spalten „EU-Region“ und „Können Daten in der EU bleiben?“ wurden am 10. Oktober 2026 anhand der öffentlichen Dokumentation jedes Anbieters geprüft; die übrigen Spalten wurden an diesem Datum nicht erneut geprüft. Angebote ändern sich. Eine Regionsoption garantiert nicht, dass keine Daten, Telemetrie oder Supportzugriffe die EU verlassen. Lassen Sie Verarbeitungsregion, Speicherung, Unterauftragsverarbeiter und Supportzugriff im Vertrag und im aktuellen DPA des Anbieters bestätigen.
Dimension 3 im Detail: Gesamtbetriebskosten
Standardgewichtung: 15 %
Die TCO-Modellierung für KI-Anbieter umfasst 5 Kostenkategorien. Ein Budget, das nur Kategorie 1 abdeckt, lässt die anderen vier außen vor. Erstellen Sie vor einer Festlegung ein Modell über 3 Jahre.
API- und Inferenzkosten
- Preis für Eingabe-Tokens × prognostiziertes monatliches Volumen an Eingabe-Tokens
- Preis für Ausgabe-Tokens × prognostiziertes monatliches Volumen an Ausgabe-Tokens
- Mengenrabattstufen — bei jeder Preisstufe modellieren
- Abwägung zwischen zugesicherter Nutzung und nutzungsabhängiger Abrechnung bei Ihrem prognostizierten Volumen
- Kosten für die Anhebung des Ratenlimits, falls Sie dedizierten Durchsatz benötigen
Die sichtbarste Kategorie. Ein Budget, das hier endet, ist unvollständig.
Training und Anpassung
- Fine-Tuning-Rechenleistung: Kosten eines Trainingslaufs pro Epoche × Anzahl der erwarteten Läufe
- Fine-Tuning-Inferenz: den Preis des Anbieters für feinabgestimmte Modelle mit dem der Basismodell-Inferenz vergleichen
- Bewertungs-Rechenleistung: Ausführung Ihrer Bewertungssuite bei jedem Modellversions-Update
- Kosten für die Neuindizierung von Embeddings beim Wechsel oder Update der Embedding-Modelle
- Datenaufbereitung und -kennzeichnung für Trainingssätze
Fällt nur an, wenn Sie Fine-Tuning einsetzen. Schätzen Sie sie anhand Ihrer eigenen geplanten Trainingsläufe und der Preise des Anbieters.
Betrieblicher Aufwand
- Engineering-Zeit für SDK-Integration, Prompt-Engineering und Wartung
- Werkzeuge für Monitoring und Observability (LangSmith, Langfuse, Datadog LLM)
- Multi-Regionen-Replikation für Latenz- oder Failover-Anforderungen
- Abonnementkosten der Support-Stufe für ein Enterprise-SLA
- Rechtliche Prüfung von Änderungen der Nutzungsbedingungen, jedes Mal, wenn der Anbieter sie aktualisiert
Wächst mit der Reife der Bereitstellung. Schätzen Sie sie anhand Ihrer eigenen Engineering- und Werkzeugkosten.
Compliance und Sicherheit
- SOC-2-Übergangsschreiben (Bridge Letters) und Bewertungen durch Dritte
- Rechtliche Prüfung der GDPR-DPA und jährliche Neubewertung
- Kosten für Penetrationstests und Sicherheitsbewertungen
- Infrastruktur für Audit-Protokollierung und Speicher für die Aufbewahrung
- Aufpreis für Datenresidenz (falls zutreffend)
Einmalige und jährlich wiederkehrende Kosten. Budgetieren Sie sie in einer regulierten Branche anhand Ihrer eigenen Audit- und Rechtsberatungsangebote.
Migrations- und Ausstiegskosten
- Engineering-Zeit zum Umschreiben von Prompts und Adaptern bei einem Anbieterwechsel
- Regressionstests gegen Ihre Bewertungssuite nach der Migration
- Kosten für den Parallelbetrieb während der Migrationsphase (2 Anbieter gleichzeitig)
- Neueinbettung des gesamten Korpus beim Wechsel des Embedding-Anbieters
- Ausfallrisiko und Umsatzeinfluss während des Migrationsfensters
Eine Kategorie, die leicht unterschätzt wird. Bemessen Sie den Migrationsaufwand für Ihre eigene Codebasis, bevor Sie sich festlegen — nicht erst, wenn Sie wechseln müssen.
Entscheidungsrahmen: selbst entwickeln, kaufen oder partnern
Kaufen (SaaS-API)
- Time-to-Market hat oberste Priorität
- Dem Team fehlt Expertise in ML-Infrastruktur
- Das Volumen liegt unter 5.000 $/Monat an API-Kosten
- Der Anwendungsfall ist Standard (Zusammenfassung, Klassifikation)
- Anbieterabhängigkeit und Preisänderungen bei Skalierung
- Daten verlassen Ihren Perimeter
- Begrenzte Anpassung für domänenspezifische Aufgaben
Selbst entwickeln (Open Source selbst hosten)
- Das Volumen übersteigt 10.000 $/Monat an API-Kosten
- Datensouveränität ist nicht verhandelbar
- Tiefe Anpassung und Kontrolle über das Fine-Tuning erforderlich
- Das Team verfügt über ML-Infrastruktur und DevOps-Fähigkeiten
- Hoher betrieblicher Aufwand und Verantwortung für die Zuverlässigkeit
- GPU-Investitionen (Capex) oder Mietkosten
- Last für Modell-Updates und Sicherheits-Patches liegt bei Ihrem Team
Partnern (Cloud-KI-Plattform)
- Bereits stark in AWS, Azure oder GCP investiert
- Enterprise-Compliance mit bestehenden Cloud-Verträgen erforderlich
- Modellvielfalt gewünscht, ohne mehrere Anbieterbeziehungen zu verwalten
- Verwaltete Werkzeuge für Fine-Tuning und Bewertung erforderlich
- Cloud-Plattform-Abhängigkeit zusätzlich zur Modellabhängigkeit
- Modellverfügbarkeit hinkt den APIs der direkten Anbieter hinterher
- Komplexe Preisgestaltung mit mehreren Dimensionen (Tokens + Rechenleistung + Speicher)
Die Vorlage für die Bewertungsmatrix
Ein durchgerechnetes Beispiel, das vier Anbieter für eine LLM-Bereitstellung in einem europäischen Großunternehmen vergleicht. Bewerten Sie jeden Anbieter je Dimension mit 1 bis 10, multiplizieren Sie mit der Dimensionsgewichtung und summieren Sie zum gewichteten Gesamtwert.
| Dimension | Gewichtung | Anbieter AUS-Hyperscaler | Anbieter BCloud-Plattform | Anbieter CEU-nativ | Anbieter DOpen-Source-Hoster |
|---|---|---|---|---|---|
| Technische Leistung | 25% | 9/10(22.5) | 8/10(20.0) | 7/10(17.5) | 6/10(15.0) |
| Sicherheit und Compliance | 20% | 5/10(10.0) | 8/10(16.0) | 10/10(20.0) | 7/10(14.0) |
| Gesamtbetriebskosten | 15% | 6/10(9.0) | 7/10(10.5) | 8/10(12.0) | 9/10(13.5) |
| Support und SLAs | 10% | 8/10(8.0) | 9/10(9.0) | 6/10(6.0) | 5/10(5.0) |
| Integration und Ökosystem | 10% | 9/10(9.0) | 7/10(7.0) | 6/10(6.0) | 5/10(5.0) |
| Roadmap und Stabilität des Anbieters | 10% | 8/10(8.0) | 7/10(7.0) | 9/10(9.0) | 6/10(6.0) |
| Compliance und regulatorische Passung | 5% | 4/10(2.0) | 7/10(3.5) | 10/10(5.0) | 8/10(4.0) |
| Ausstiegsstrategie und Portabilität | 5% | 4/10(2.0) | 6/10(3.0) | 9/10(4.5) | 8/10(4.0) |
| Gewichteter Gesamtwert | 100% | 70.5 | 76.0 | 80.0Gewinner | 66.5 |
Die Ergebnisse lesen
Anbieter C (EU-nativ) gewinnt trotz niedrigerer Werte bei technischer Leistung und Integration. Die hohe Gewichtung von Sicherheit und Compliance (20 %) und regulatorischer Passung (5 %) spiegelt den Unternehmenskontext wider. Ein Start-up ohne Compliance-Anforderungen hätte einen anderen Gewinner.
Stichregel: Liegen zwei Anbieter weniger als 5 Punkte auseinander, führen Sie einen 2-wöchigen Parallelpiloten mit Verkehr in Produktionsgröße durch. Die Matrix grenzt das Feld ein — reale Daten zu Ihrer Last treffen die endgültige Entscheidung.
Gewichtungsanpassung: Lassen Sie vor der Bewertung Ihre wichtigsten Stakeholder (CTO, CISO, CFO, DPO) die Gewichtungen unabhängig vergeben und bilden Sie dann den Durchschnitt oder verhandeln Sie. Unterschiedliche Gewichtungen ergeben unterschiedliche Gewinner — das Gespräch über die Gewichtung ist ebenso wichtig wie die Bewertung.
RFP-Vorlage: 25 Fragen, die Sie jedem Anbieter senden sollten
Senden Sie diese Fragen vor einem Pilotbetrieb an jeden in Betracht gezogenen Anbieter. Anbieter, die eine Antwort verweigern oder vage antworten, signalisieren Probleme. Verlangen Sie schriftliche Antworten — mündliche Antworten eines Vertriebsingenieurs sind vertraglich nicht bindend.
Technische Leistung
- 1Welche veröffentlichten Latenzziele für P50, P95 und P99 gelten für unsere erwartete Anfragegröße?
- 2Welchen Durchsatz (Tokens/Sekunde) können Sie auf einer dedizierten Stufe gegenüber gemeinsam genutzter Kapazität garantieren?
- 3Wie gehen Sie mit Latenzverschlechterung bei Spitzenlast um? Werfen Sie Last ab oder stellen Sie Anfragen in eine Warteschlange?
- 4Wie lautet Ihre Methodik zum Genauigkeits-Benchmark des Modells und wie validieren Sie sie an domänenspezifischen Daten?
- 5Wie kommunizieren Sie Modell-Updates, die das Ausgabeverhalten verändern könnten?
Sicherheit und Compliance
- 6Können Sie Ihren aktuellen SOC-2-Type-II-Bericht unter NDA bereitstellen?
- 7Verfügen Sie über ein ISO-27001-Zertifikat? Falls ja, welchen Geltungsbereich deckt es ab?
- 8Wie lauten Ihre Richtlinien zur Aufbewahrung und Löschung von API-Aufrufprotokollen, Prompt-Daten und Modellausgaben?
- 9Bieten Sie eine Auftragsverarbeitungsvereinbarung (DPA) gemäß Art. 28 GDPR an?
- 10Können Sie schriftlich bestätigen, dass unsere Prompts und Ausgaben ohne ausdrückliches Opt-in niemals zum Modelltraining verwendet werden?
- 11Welche Optionen zur EU-Datenresidenz bieten Sie an und in welchen Regionen?
Preisgestaltung und kommerzielle Konditionen
- 12Wie lautet Ihre vollständige Preisstruktur einschließlich Eingabe-Tokens, Ausgabe-Tokens, Fine-Tuning und Speicher?
- 13Sind Mengenrabatte verfügbar? Ab welcher Stufe und wie ist der Vertrag zur zugesicherten Nutzung strukturiert?
- 14Was geschieht mit der Preisgestaltung, wenn wir unser zugesichertes Volumen in einem Monat überschreiten?
- 15Gibt es Egress-, Datenübertragungs- oder API-Gateway-Gebühren, die nicht im Preis pro Token enthalten sind?
- 16Wie lauten die Konditionen für Enterprise-Support-Stufen und was umfasst jede davon?
Betrieb und Integration
- 17Wie lautet Ihr SLA für die API-Verfügbarkeit? Wie berechnen und vergüten Sie Ausfallzeiten?
- 18Wie handhaben Sie Erhöhungen des Ratenlimits bei Produktions-Verkehrsspitzen?
- 19Welche Observability und Protokollierung stellen Sie Kunden bereit (Token-Nutzung, Fehlerraten, Latenz)?
- 20Stellen Sie eine Staging-/Sandbox-Umgebung zum Testen bereit, die das Produktionsverhalten widerspiegelt?
- 21Welche SDKs unterstützen Sie offiziell und wie sieht Ihr Einstellungsprozess für SDK-Versionen aus?
Strategie und Ausstieg
- 22Wie lautet Ihre Roadmap für die nächsten 12 bis 18 Monate? Welche Modellfähigkeiten sind geplant?
- 23Wie lautet die Mindestankündigungsfrist, bevor eine von uns in Produktion genutzte Modellversion eingestellt wird?
- 24Wie können wir die Gewichte unseres feinabgestimmten Modells oder die Adapter-Schichten exportieren, falls wir uns für einen Wechsel entscheiden?
- 25Wie lautet der vertragliche Prozess für eine vorzeitige Kündigung der Vereinbarung und welche Garantien zur Datenlöschung gelten?
- 26Können Sie Referenzen von Kunden aus unserer Branche oder mit ähnlichen Compliance-Anforderungen vorlegen?
Wie Sie diese Fragen verwenden
Warnsignale: 12 Anzeichen, dass ein Anbieter Sie enttäuschen wird
Dies sind beobachtbare Signale, die auf ein Risiko von Produktionsausfällen, Compliance-Problemen oder einer Verschlechterung der Beziehung hinweisen. Kritische Signale sind harte Stopps — fahren Sie nicht fort. Hohe Signale erfordern eine eingehende Untersuchung. Mittlere Signale sind Warnhinweise, die vertraglich zu steuern sind.
| Nr. | Warnsignal | Schweregrad | Was es signalisiert |
|---|---|---|---|
| 1 | Keine öffentliche Statusseite oder historische Verfügbarkeitsdaten | Kritisch | Der Anbieter hat etwas zur Zuverlässigkeit zu verbergen. Jeder ernsthafte Produktionsanbieter veröffentlicht eine Vorfallhistorie. |
| 2 | Das Opt-out vom Training erfordert eine rechtliche Prüfung, keinen UI-Schalter | Kritisch | Ihre proprietären Prompts und Geschäftsdaten werden wahrscheinlich zum Modelltraining verwendet. Für Unternehmen nicht verhandelbar. |
| 3 | Kein SOC-2-Type-II-Bericht verfügbar (nur Type I) | Kritisch | Type I ist eine Momentaufnahme ohne Nachweis dauerhafter Kontrollen. Type II deckt einen Betriebszeitraum von 6 bis 12 Monaten ab. |
| 4 | Die GDPR-/DPA-Dokumentation erfordert eine Vertriebseskalation | Kritisch | Eine DPA sollte Self-Service oder Standard sein. Eskalationsanforderungen signalisieren entweder rechtliche Unreife oder bewusste Reibung. |
| 5 | Die Preisgestaltung erfordert für Informationen zur Basisstufe ein Vertriebsgespräch | Hoch | Versteckte Preise bedeuten meist, dass sie je nach wahrgenommenem Budget variieren, was Ihre Kostenprognose unberechenbar macht. |
| 6 | Ankündigungsfrist für die Modelleinstellung kürzer als 6 Monate | Hoch | Produktionssysteme lassen sich nicht sicher in unter 6 Monaten migrieren. Kurze Einstellungsfenster zerstören Engineering-Pläne. |
| 7 | Keine Self-Hosting- oder VPC-Bereitstellungsoption für die Enterprise-Stufe | Hoch | Für regulierte Branchen oder hochsensible Daten ist gemeinsame Mandantenfähigkeit oft inakzeptabel. Kein Self-Hosting = kein Deal. |
| 8 | Das SDK ist ein dünner REST-Wrapper ohne Retry-/Backoff-Logik | Hoch | Indikator für Engineering-Reife. Produktionsreife SDKs handhaben Retries, Streaming, Backoff bei Ratenlimits und Fehlerklassifizierung. |
| 9 | Ratenlimits nicht dokumentiert oder ohne vorherige Ankündigung geändert | Mittel | Undokumentierte oder volatile Ratenlimits machen Kapazitätsplanung unmöglich und verursachen unerwartete Produktionsausfälle. |
| 10 | Keine schriftliche Zusage zur Datenresidenz | Mittel | Mündliche Zusicherungen sind nicht durchsetzbar. Anforderungen an die Datenresidenz müssen in der DPA oder dem MSA stehen, nicht in einer Vertriebspräsentation. |
| 11 | Unternehmen vor weniger als 18 Monaten gegründet, ohne referenzierbare Enterprise-Kunden | Mittel | Anbieter in der Frühphase können pivotieren, das Geld ausgehen oder übernommen werden. Für eine KI-Produktionsinfrastruktur zählt Langlebigkeit. |
| 12 | Keine Ausstiegsklausel oder Garantie zur Datenlöschung im Standardvertrag | Mittel | Was geschieht bei Ihrem Weggang mit Ihren Daten und feinabgestimmten Modellen? Schweigt der Vertrag, rechnen Sie mit dem Schlimmsten. |
Harter Stopp. Schließen Sie den Anbieter sofort aus, sofern Sie keine vertragliche Abhilfe erreichen können.
Erfordern eine detaillierte Untersuchung und einen schriftlichen Minderungsplan, bevor Sie fortfahren.
Warnsignal. Über vertragliche Schutzmaßnahmen oder eine dokumentierte Risikoakzeptanz steuern.
Auswahlprozess: von 20 Anbietern auf 3 Finalisten in 2 Wochen
Anbieterbewertungen geraten ins Stocken, wenn Teams zu viele Optionen parallel bewerten wollen. Dieser 2-wöchige Prozess nutzt eine schrittweise Ausscheidung, um effizient zu 3 qualifizierten Finalisten zu gelangen und den PoC-Aufwand für die Anbieter aufzusparen, die ihn wirklich verdienen.
Sondierung
Weites Netz auswerfen: 15 bis 20 Anbieter
MoSCoW-Filter
Harte Must-Have-Kriterien anwenden
Schreibtischrecherche
Die verbleibenden 6 bis 8 Anbieter vertieft prüfen
Demo und technisches Gespräch
30-minütiges Gespräch mit jedem Anbieter, die 25 RFP-Fragen stellen
Bewertung und Shortlist
Die gewichtete Bewertungsmatrix auf die besten 3 bis 4 Anbieter anwenden
Kriterien des MoSCoW-Filters
Wenden Sie diese als binäre Bestehen/Durchfallen-Hürden an. Jeder Anbieter, der ein Must Have nicht erfüllt, wird sofort ausgeschlossen — ohne Ausnahmen.
Must Have (jedes Versagen = Ausschluss)
- SOC-2-Type-II-Bericht verfügbar
- GDPR-konforme DPA verfügbar
- EU-Datenresidenz (falls von Ihrem DPO gefordert)
- Veröffentlichte Preise (keine vertriebsgeschützten Basisstufen)
- Verfügbarkeits-SLA ≥ 99,9 % im Vertrag
- Opt-out vom Training als Standard-Kontoeinstellung
Should Have (höher bewerten, nicht ausschließen)
- ISO-27001-Zertifikat
- Dedizierte Enterprise-Support-Stufe
- Self-Hosting- oder VPC-Bereitstellungsoption
- Unterstützung von Fine-Tuning und Anpassung
- Verfügbarkeit über mehrere Regionen
- Modellportabilität und -export
Nach der Auswahl: Anbietermanagement und SLA-Überwachung
Die Auswahl eines Anbieters ist der Anfang, nicht das Ende. Anbieterbeziehungen verschlechtern sich ohne aktives Management. Behandeln Sie das Anbietermanagement als fortlaufende Disziplin mit regelmäßigem Rhythmus, dokumentierter SLA-Verfolgung und klaren Eskalationswegen.
SLA-Überwachungs-Dashboard: zentrale Metriken
| Metrik | SLA-Ziel | Messung | Eskalationsauslöser |
|---|---|---|---|
| API-Verfügbarkeit | ≥ 99,9 % monatlich | Synthetisches Monitoring alle 60 s aus der EU-Region | P1-Vorfall, wenn die Ausfallzeit > 15 Minuten beträgt |
| P95-Latenz | < 800 ms bei Standardanfragen | 95. Perzentil der Antwortzeiten über ein gleitendes 24-h-Fenster | Alarm, wenn das P95 länger als 5 Minuten 1.200 ms überschreitet |
| Fehlerrate | < 0,5 % 5xx-Fehler pro Stunde | Fehlerrate über alle API-Endpunkte, ohne Client-Fehler | Eskalation an den Anbieter, wenn > 1 % über zwei aufeinanderfolgende Stunden |
| Spielraum beim Ratenlimit | ≥ 30 % freie Kapazität gegenüber den vertraglichen Limits | Tägliche Spitzennutzung gegenüber der vertraglichen Obergrenze des Ratenlimits | Limiterhöhung anfordern, wenn der Spielraum an 5 aufeinanderfolgenden Tagen < 20 % beträgt |
| Kosten pro 1.000 API-Aufrufe | Innerhalb von 10 % der modellierten Basis | Gleitender 7-Tage-Durchschnitt gegenüber dem ursprünglichen TCO-Modell | Überprüfen und neu verhandeln, wenn dauerhaft > 20 % über der Basis |
| Vierteljährliches Geschäftsreview | Alle 90 Tage abgehalten | Aktualisierung der Anbieter-Roadmap, Vorfallreview, Preisreview, SLA-Compliance-Bericht | Formelles Leistungsreview auslösen, wenn ein kritisches SLA verfehlt wird |
Rhythmus des Anbietermanagements
Checkliste für die Vertragsverlängerung
Beginnen Sie 3 Monate vor der Vertragsverlängerung. Dies ist Ihr Verhandlungsfenster.
- Gewichtete Bewertungsmatrix mit den Marktdaten des laufenden Jahres erneut ausführen
- Aktuellen SOC-2-Type-II-Bericht anfordern
- 2 bis 3 alternative Anbieter benchmarken, um eine Verhandlungsposition aufzubauen
- Einstellungsmitteilungen des Anbieters prüfen — sind Modelle gefährdet, von denen Sie abhängen?
- Vollständige TCO der letzten 12 Monate gegenüber dem ursprünglichen Modell berechnen
- DPA auf etwaige Konditionsänderungen der letzten 12 Monate prüfen
- Verhandeln: Mengenzusagen für bessere Preise, besseres SLA, längere Ankündigungsfristen
- Ausstiegsklausel aktualisieren: sicherstellen, dass Lösch-SLA und Rechte zur Modellportabilität aktuell sind
Strategie zur Mehr-Anbieter-Abstraktion
Ein wirksamer Weg, die Anbieterabhängigkeit zu verringern, ist, Ihre LLM-Aufrufe von Tag eins an hinter einer Routing-Schicht zu abstrahieren. Das ist eine kleine Engineering-Investition zu Beginn, die das spätere Migrationsrisiko senkt.
Open-Source-Routing-Optionen
- LiteLLM — einheitliche API für viele Anbieter
- Portkey — Gateway mit Observability und Fallbacks
- OpenRouter — Marktplatz-Routing mit Kostenoptimierung
- Eigene Abstraktionsschicht mit Anbieterschnittstelle
Was Ihnen die Abstraktion bringt
- Den Hauptanbieter wechseln, ohne den Anwendungscode umzuschreiben
- Bei Ratenlimit oder Ausfall automatisch einen Fallback-Anbieter ausführen
- Zwei Anbieter im A/B-Test auf Live-Verkehr prüfen
- Zur Anfragezeit dynamisch nach Kosten und Qualität routen
Brauchen Sie Hilfe bei der Durchführung Ihrer KI-Anbieterbewertung?
Ich kann Sie bei einer strukturierten Anbieterbewertung unterstützen — von der Anforderungsdefinition über das PoC-Design und die Bewertung bis zur Vertragsverhandlung — mit einem objektiven, dokumentierten Rahmen.
Verwandte Ressourcen
Leitfaden zur Kostenoptimierung von LLM
Senken Sie die LLM-Inferenzkosten durch Modell-Routing, Caching und Fine-Tuning
Playbook für KI-Sicherheit und Red-Teaming
Schützen Sie Ihre KI-Systeme vor Prompt-Injection und Modellangriffen
Leitfaden zur Compliance mit dem EU AI Act
Navigieren Sie durch die regulatorischen Anforderungen für KI-Systeme in Europa