Die beste AI-API ist nutzlos, wenn dein Use Case nicht erlaubt ist

Ein Team möchte eine AI-gestützte Funktion bauen: Vertragsprüfung, Support-Antworten, Bildgenerierung für einen Marktplatz oder Zusammenfassungen aus internen Dokumenten. Die Modellauswahl beginnt oft mit einem Benchmark, einer Preisübersicht und ein paar Playground-Tests.

Das ist zu spät angesetzt.

Bevor Modellqualität, Latenz oder Preis relevant werden, muss eine grundlegendere Frage beantwortet sein:

Darf und kann dieser Provider den konkreten Use Case unter den tatsächlichen Betriebsbedingungen bedienen?

Wenn die Antwort nein lautet, ist das technisch beste Modell keine Option. Nicht „eine riskante Option“, nicht „eine Option mit juristischem Review“, sondern keine belastbare Architekturgrundlage.

Provider-Policies sind damit keine Beschaffungsdetails. Sie sind Architekturconstraints – vergleichbar mit einer fehlenden Region, einem unzureichenden Durchsatzlimit oder einer nicht verfügbaren Datenbankfunktion.

Der verbreitete Fehler: Qualität vor Machbarkeit bewerten

In vielen Vendor-Shortlists stehen zuerst Kriterien wie diese:

• Benchmark-Ergebnisse
• Kontextfenster
• Preis pro Token oder Bild
• Funktionsumfang der API
• Demo-Qualität

Alle sind relevant. Keines beantwortet jedoch, ob das Produkt später in Produktion gehen darf und kann.

Einige typische Fälle:

• Ein Moderations- oder Safety-Policy schließt Inhalte aus, die im Kerngeschäft unvermeidbar vorkommen – etwa medizinische, rechtliche, sexuelle, politische oder altersbezogene Inhalte.
• Die Vertragsbedingungen erlauben den gewünschten Einsatz nur in einer Produktklasse, einem Land oder unter zusätzlichen Freigaben.
• Die Datenverarbeitung findet nicht in der für Kunden, Vertrag oder Regulierung erforderlichen Region statt.
• Die API hat in der Startphase ausreichende Limits, aber keine verbindliche Perspektive für den geplanten Produktionsdurchsatz.
• Der Provider akzeptiert die im Zielmarkt verfügbare Zahlungs- oder Rechnungsart nicht.
• Ein Account, eine Organisation oder ein Projekt kann gesperrt werden, ohne dass der Betrieb mit einem alternativen Anbieter kurzfristig fortgesetzt werden kann.

Jeder dieser Punkte kann ein Projekt stoppen, obwohl der Prototyp hervorragend funktioniert.

Die relevante Reihenfolge lautet daher:

1. Zulässigkeit prüfen
2. Betriebliche Lieferfähigkeit prüfen
3. Daten- und Vertragsanforderungen prüfen
4. Erst dann Modelle, Qualität und Kosten vergleichen

Policies sind funktionale Anforderungen

ToS und Content Policies werden häufig dem Legal- oder Compliance-Track zugeordnet. Das ist organisatorisch verständlich, architektonisch aber irreführend.

Wenn ein Provider bestimmte Eingaben oder Ausgaben nicht zulässt, verändert das direkt den Funktionsumfang des Systems. Eine Policy wirkt dann wie eine nicht erfüllte fachliche Anforderung.

Nehmen wir eine Anwendung zur Bearbeitung von Schadensmeldungen. In den Texten und Bildern können Verletzungen, Gewalt, Gesundheitsdaten oder detaillierte Unfallbeschreibungen vorkommen. Wenn der ausgewählte Dienst solche Inhalte regelmäßig ablehnt, ist das keine Ausnahmebehandlung. Der zentrale Geschäftsprozess ist mit diesem Dienst nicht implementierbar.

Dasselbe gilt für einen Marktplatz mit nutzergenerierten Inhalten. Wenn die Anwendung Inhalte klassifizieren, zusammenfassen oder transformieren soll, die der Provider nicht verarbeiten möchte, entsteht eine Lücke genau dort, wo Automatisierung gebraucht wird.

Die richtige Frage lautet nicht: „Können wir mit Prompting oder einem Fallback die Ablehnungen reduzieren?“

Sie lautet: „Ist eine vorhersehbare, policy-konforme Verarbeitung unseres normalen Datenprofils möglich?“

Einzelne erwartbare Ablehnungen können Teil eines Designs sein. Wiederkehrende Ablehnungen im Hauptpfad sind ein Vendor-Mismatch.

Die Architekturmatrix für die Vendor-Auswahl

Eine belastbare Auswahl betrachtet nicht nur das Modell, sondern den gesamten Liefergegenstand. Ich verwende dafür eine Matrix mit sechs Dimensionen:

Diese Dimensionen sind keine Checkliste, die nacheinander abgehakt wird. Sie beeinflussen sich gegenseitig.

Ein Modell mit besserer Qualität kann beispielsweise höhere Latenzen erzeugen, dadurch mehr parallele Requests verlangen und damit früher an Rate Limits stoßen. Eine Datenresidenz-Anforderung kann die verfügbaren Modelle oder Regionen einschränken. Ein günstiger Tokenpreis kann durch hohe Fehlerraten, Retries und zusätzliche Moderationsaufrufe irrelevant werden.

Die Auswahl ist deshalb eine Architekturentscheidung mit kommerziellen und rechtlichen Randbedingungen – keine reine Modellentscheidung.

Policy-Fit konkret prüfen

„Der Provider erlaubt unseren Use Case“ darf nicht das Ergebnis einer allgemeinen Produktbeschreibung sein. Es braucht eine überprüfbare Zuordnung zwischen dem eigenen Nutzungsszenario und den geltenden Regeln.

Dazu gehören mindestens diese Fragen:

1. Welche Daten gehen tatsächlich an das Modell?

Nicht die beabsichtigten Daten sind entscheidend, sondern die Daten, die im Betrieb auftreten.

Bei einem Support-Assistenten können das Freitext, Anhänge, Zitate aus E-Mails, Namen, Adressen, Zahlungsinformationen und sensible Beschwerdeinhalte sein. Bei RAG-Systemen gelangen oft Dokumentausschnitte in den Prompt, die bei einer oberflächlichen Datenklassifikation nicht berücksichtigt wurden.

Erstellt daher ein Dateninventar pro Request-Typ:

• Quellen der Eingabe
• Datenkategorien und Sensitivität
• erwartete Inhaltsklassen
• mögliche Sonderfälle
• Übertragungsweg und Zielregion
• Speicherdauer in Logs, Traces und Evaluationsdaten

2. Welche Handlung automatisiert das System?

Policies unterscheiden häufig zwischen Assistenz, Empfehlung und autonomer Entscheidung. Auch wenn die API technisch eine Funktion anbietet, kann der beabsichtigte Automatisierungsgrad eingeschränkt sein.

Besonders relevant ist das bei Entscheidungen mit Folgen für Personen: Kredit, Versicherung, Beschäftigung, Bildung, Gesundheit, Sicherheit oder Rechtsdurchsetzung. Ein Human-in-the-Loop ist kein universelles Compliance-Pflaster. Er muss tatsächlich wirksam sein: mit ausreichendem Kontext, Entscheidungsspielraum und nachvollziehbarer Verantwortlichkeit.

3. Welche Inhalte sind ein Normalfall, nicht nur ein Edge Case?

Ein Content Filter kann im Demo-Test unsichtbar bleiben und im Betrieb zum dominanten Fehlerbild werden. Deshalb sollten Teams repräsentative, zulässigerweise anonymisierte oder synthetische Testdaten verwenden – einschließlich der unangenehmen Fälle.

Messen Sie dabei nicht nur Modellqualität, sondern auch:

• Ablehnungsrate nach Inhaltsklasse
• Fehlklassifikationen durch Safety-Mechanismen
• Unterschiede zwischen Regionen und Modellversionen
• Verhalten bei mehrsprachigen Eingaben
• Qualität und Maschinenlesbarkeit von Fehlermeldungen
• Auswirkungen auf Endnutzer und Support-Prozesse

Das Ergebnis gehört in die Architekturentscheidung, nicht in ein separates Legal-Memo.

Datenresidenz: Region ist nicht gleich Datenkontrolle

„Der Anbieter hat eine EU-Region“ ist kein ausreichender Abschluss der Prüfung.

Relevant ist, welche Verarbeitung wo stattfindet: Inferenz, Logging, Abuse Monitoring, Support-Zugriffe, Backup, Telemetrie, Content-Review und Subprozessoren können unterschiedliche Pfade haben. Ebenso wichtig sind die Vertragsgrundlagen, Aufbewahrungsfristen und die Frage, ob Daten für Training oder Produktverbesserung verwendet werden können.

Für die Architektur folgt daraus:

• Datenklassifikation muss vor dem Prompt-Design stehen.
• Mandantentrennung und Zugriffskontrolle müssen auch für Prompts, Retrieval und Observability gelten.
• Logging darf nicht versehentlich den strengsten Datenpfad unterlaufen.
• Es braucht eine klare Entscheidung, welche Daten das Modell nie verlassen dürfen.

Eine häufig sinnvolle Struktur ist ein vorgeschalteter Data-Gateway-Layer. Er übernimmt PII-Erkennung und -Redaktion, Routing nach Datenklasse und Region, Request-Protokollierung mit minimierten Daten sowie die Durchsetzung von Allow- und Deny-Regeln. Das ersetzt keine vertragliche Prüfung, macht die technische Durchsetzung aber explizit und testbar.

Rate Limits sind Kapazitätsplanung, keine Fußnote

Rate Limits werden gern als Skalierungsproblem für später behandelt. In AI-Systemen sind sie oft schon beim Produktdesign relevant.

Ein Limit auf Requests pro Minute oder Tokens pro Minute sagt allein wenig aus. Entscheidend ist die Lastformel:

benötigte Tokenrate = parallele Nutzer × Requests pro Nutzer × Tokens pro Request

Dazu kommen Retries, Tool-Aufrufe, RAG-Kontext, Streaming, Batch-Jobs und Hintergrundverarbeitung. Ein Chat-Feature mit 500 gleichzeitigen Nutzern kann unter realistischen Promptgrößen eine Tokenrate benötigen, die weit über dem Standardtier eines Accounts liegt.

Prüfen Sie daher vor dem Go-live:

• Welche Limits gelten pro Modell, Region, Projekt und Organisation?
• Sind Erhöhungen vertraglich oder nur „best effort“ verfügbar?
• Welche Limits gelten für Embeddings, Moderation, Dateien und Batch-APIs?
• Wie reagiert die Anwendung auf 429-Fehler und temporäre Kapazitätsengpässe?
• Gibt es Priorisierung, Reservierung oder eine SLA für den geplanten Durchsatz?
• Welche Qualitätsdegradation ist bei Fallbacks akzeptabel?

Ein Fallback auf ein anderes Modell ist nur dann ein Fallback, wenn es vorher mit denselben fachlichen Testfällen, Datenregeln und Lastannahmen validiert wurde.

Zahlungs- und Accountrestriktionen sind Betriebsrisiken

Das klingt banal, wird aber regelmäßig zu spät entdeckt: Ein Dienst kann technisch verfügbar sein und dennoch für das eigene Unternehmen oder den Zielmarkt nicht beschaffbar sein.

Mögliche Hürden sind fehlende Rechnungsstellung, nicht unterstützte Zahlungsmittel, regionale Verfügbarkeit, Unternehmensverifikation, Kreditlimits, Exportkontrollen oder die Bindung an ein bestimmtes Cloud-Billing-Konto.

Für einen Prototypen kann eine Firmenkreditkarte genügen. Für ein Produkt mit Kostenstellen, Umsatzsteueranforderungen, Procurement-Prozess und mehreren Mandanten genügt sie nicht.

Die Frage ist deshalb nicht nur, ob ein Entwickler heute einen API-Key erzeugen kann. Die Frage lautet: Kann das Unternehmen den Dienst in zwölf Monaten revisionsfähig, budgetierbar und ohne personengebundene Abhängigkeiten betreiben?

Kosten richtig modellieren: nicht nur Input und Output

Tokenpreise sind sichtbar und leicht vergleichbar. Die Gesamtkosten entstehen jedoch im System.

Berücksichtigen Sie mindestens:

• Input-, Output- und Caching-Kosten
• Embeddings und Retrieval
• Moderation und Sicherheitsprüfungen
• Retries, Timeouts und fehlgeschlagene Requests
• Evaluations- und Testläufe
• Observability, Prompt-Logging und Datenhaltung
• Engineering-Aufwand für Provider-spezifische Anpassungen
• Kosten eines zweiten Providers als Resilienz- oder Exit-Option

Eine besonders häufige Fehlannahme: Der günstigste Modellpreis ist der günstigste Betrieb. Wenn ein Modell mehr Nachbearbeitung, längere Prompts, mehr Wiederholungen oder stärkere menschliche Kontrolle benötigt, kann ein nominell teureres Modell wirtschaftlicher sein.

Umgekehrt ist ein hochklassiges Modell für jede Anfrage selten sinnvoll. Gute Architektur routet nach Aufgabe, Datenklasse, Qualitätsanforderung und Kostenbudget – aber nur innerhalb einer vorher geprüften Policy- und Datenhülle.

Exit-Fähigkeit bewusst einbauen

Provider-Wechsel ist bei generativer AI schwerer als ein Austausch einer REST-API. Prompts, Tool-Schemata, Safety-Verhalten, Kontextgrenzen, Structured Outputs und Modellcharakteristika beeinflussen das Produktverhalten.

Vollständige Austauschbarkeit ist oft unrealistisch. Eine kontrollierbare Wechseloption ist dagegen erreichbar.

Praktische Maßnahmen:

• Eine interne Abstraktion für Nachrichten, Tools, Antworten und Fehlercodes definieren.
• Provider-spezifische Optionen an einer Stelle kapseln, nicht im Fachcode verteilen.
• Prompts, Modellversionen und Evaluationsdaten versionieren.
• Für kritische Use Cases mindestens einen alternativen Anbieter regelmäßig gegen denselben Testkorpus evaluieren.
• Eigene Qualitätsmetriken festlegen, statt nur öffentliche Benchmarks zu übernehmen.
• Fallback-Regeln fachlich definieren: Welche Aufgaben dürfen mit geringerer Qualität beantwortet, verzögert oder abgelehnt werden?

Ein Adapter-Pattern allein schafft keinen Exit. Ohne Testdaten, Qualitätsgrenzen und Betriebserfahrung bleibt die Alternative theoretisch.

Ein praxistauglicher Auswahlprozess

Für AI Strategy, Vendor Selection und Solution Architecture hat sich ein kurzer, harter Prozess bewährt.

Phase 1: Use Case in überprüfbare Merkmale zerlegen

Beschreiben Sie nicht nur „AI für Support“, sondern zum Beispiel:

• Sprachen und Märkte
• Eingabe- und Ausgabemodalitäten
• Datenklassen
• Inhaltsrisiken
• Automatisierungsgrad
• Lastprofil und Verfügbarkeitsziel
• fachliche Qualitätskriterien
• akzeptable Fehler- und Ablehnungsmodi

Phase 2: Ausschlusskriterien vorab definieren

Formulieren Sie harte Grenzen, etwa:

• Verarbeitung personenbezogener Daten nur in definierten Regionen
• kein Training auf Kundendaten
• verbindlich erreichbare Zielkapazität
• zulässige Verarbeitung der erwarteten Inhaltsklassen
• Rechnung und Vertrag für die eigene Gesellschaft möglich
• dokumentierter Incident- und Support-Prozess

Anbieter, die eines dieser Kriterien nicht erfüllen, fallen vor dem Benchmark aus der Auswahl.

Phase 3: Repräsentativen Pilot bauen

Der Pilot muss den späteren Betrieb simulieren, nicht eine Demo optimieren. Er braucht reale Lastannahmen, typische und schwierige Inhalte, Fehlerfälle, Observability sowie einen Kostenmesser.

Testen Sie insbesondere Ablehnungen, Timeouts, Quota-Überschreitungen und regionale Besonderheiten. Der Happy Path ist selten das Risiko.

Phase 4: Entscheidung dokumentieren

Die Entscheidungsvorlage sollte die Architekturmatrix enthalten, offene Annahmen benennen und ein Re-Evaluation-Datum festlegen. Policies, Preise, Limits und Modellversionen ändern sich. Eine Vendor-Entscheidung ist deshalb kein einmaliger Beschluss, sondern ein kontrollierter Betriebsgegenstand.

Fazit

Die beste AI-API ist diejenige, die den konkreten Use Case zulässig, datenschutzkonform, ausreichend zuverlässig und wirtschaftlich betreiben kann. Modellqualität ist dabei wichtig – aber nur innerhalb dieser Grenzen.

Wer zuerst Benchmarks vergleicht und Policies später liest, optimiert möglicherweise eine Lösung, die nie produktiv gehen darf. Wer Policies, Daten, Betrieb, Kosten und Exit-Optionen als gemeinsame Architekturmatrix behandelt, reduziert genau dieses Risiko.

Die entscheidende Frage in der Vendor-Auswahl lautet daher nicht: „Welches Modell ist am besten?“

Sondern: „Welcher Anbieter erfüllt unsere fachlichen Anforderungen unter den Bedingungen, unter denen wir das System tatsächlich betreiben müssen?“