Die 5 Fragen zur KI-Architektur, die Beschaffungsteams stellen werden (und wie man sie beantwortet)

(In diesem Artikel bezieht sich „KI-Architektur“ spezifisch auf das KI-Gateway bzw. die Steuerungsebene, die zwischen Anwendungen und Modellanbietern angesiedelt ist – dort, wo Routing, Governance, Observability und Kostenkontrolle stattfinden.)

Wenn Sie einen Anbieter für die Skalierung Ihrer KI-Initiativen evaluieren, stellen Einkaufs- und Plattformteams bei der Bewertung der Enterprise-KI-Architektur regelmäßig die folgenden Fragen.

1. Wie aufwendig ist eine Neuentwicklung, wenn wir den Anbieter wechseln?
2. Können wir nachweisen, welche Daten wohin geflossen sind, anstatt es nur zu behaupten?
3. Was genau ist die Abrechnungseinheit und können wir diese deckeln?
4. Was ist der Fallback, wenn dieses System ausfällt?
5. Was passiert, wenn dieser Anbieter in drei Jahren nicht mehr existiert?

Wenn Ihre KI-Architektur diese Fragen nicht klar beantworten kann, verzögert sich die Bewertung der Enterprise-KI-Architektur, Sicherheitsprüfungen weiten sich aus und Pilotprojekte bleiben im Experimentierstadium stecken.

Was Einkaufsteams tatsächlich mit „KI-Architektur“ meinen

Bei der Bewertung der Enterprise-KI-Architektur prüfen Einkaufsteams selten nur das zugrunde liegende Modell. Sie bewerten die operative Architektur rund um die Modelle, also die Infrastruktur, die bestimmt, wie KI-Systeme innerhalb des Unternehmens geroutet, gesteuert, überwacht, gesichert und betrieben werden.

In den meisten Enterprise-GenAI-Umgebungen umfasst diese Ebene Komponenten wie KI-Gateways, Anbieter-Abstraktionssysteme, Routing-Logik, Authentifizierungskontrollen, Observability-Pipelines, Governance-Richtlinien, Prompt-Management-Systeme, Telemetrie-Infrastruktur, Budgetkontrollen und Failover-Mechanismen. Zunehmend gehören dazu auch Agenten-Governance und die Verwaltung von Tool-Berechtigungen, da Unternehmen mit MCP-Servern und autonomen Workflows experimentieren.

Mit der Zeit wird diese Architektur effektiv zum Betriebssystem für die Unternehmens-KI. Sie definiert, wie Anwendungen mit Modellen interagieren, wie Richtlinien durchgesetzt werden, wie Datenbewegungen überwacht werden und wie Kosten teamübergreifend kontrolliert werden.

Deshalb konzentrieren sich Einkaufsteams heute selten nur noch auf die Modellqualität. Die wichtigere Frage ist meist operativer Natur:

„Wie schwierig wird es sein, dieses System in den nächsten Jahren zu steuern, zu prüfen, zu skalieren und zu ersetzen?“

Die Antwort auf diese Frage entscheidet oft darüber, ob eine KI-Initiative über die Experimentierphase hinausgeht und unternehmensweit eingeführt wird.

So gestalten Unternehmen, die den Beschaffungsprozess erfolgreich durchlaufen, ihren KI-Stack.

KI-Architektur-Frage Nr. 1: Können wir den Anbieter wechseln, ohne Anwendungen neu schreiben zu müssen?

Ein Satz fällt bei der Bewertung der Enterprise-KI-Architektur immer wieder:

Alle behaupten, sie seien OpenAI-kompatibel. Was bedeutet das eigentlich für Bedrock oder Gemini?

Die Sache ist die: Viele Teams sagen zwar „wir sind OpenAI-kompatibel“, aber das gilt oft nur für sehr begrenzte Modelle. Sobald Sie AWS Bedrock, Gemini oder On-Premise-Modelle (Cloudera, interne GPUs) einbinden, schleichen sich Formatinkonsistenzen in den Anwendungscode ein.

Der Einkauf erkennt das sofort:
Wenn ein Anbieterwechsel bedeutet, jede einzelne Anwendung anfassen zu müssen, sind Sie gefangen – ob Sie wollen oder nicht.

Praktische Architekturregel:

• Anwendungen sollten ein einziges, stabiles Anfrageformat verwenden.
• Die Übersetzung für Bedrock, Gemini, Azure oder selbst gehostete Modelle erfolgt außerhalb des Anwendungscodes.

Diese Unterscheidung ist wichtig. In der Zusammenarbeit mit vielen Großunternehmen haben wir festgestellt, dass ein Hyperscaler zwar seine eigenen Modelle gut unterstützt, aber die Modellformate anderer Hyperscaler nicht nativ übersetzt. Wenn Sie eine Multi-Cloud-Strategie verfolgen, bedeutet das, dass Sie die Übersetzungslogik intern selbst schreiben und pflegen müssen.

Diese Logik erscheint im ersten Jahr nicht kostspielig. Im dritten Jahr wird sie jedoch sehr teuer. Hier ist der Grund:

• Jedes Quartal erscheinen neue Modelle.
• API-Verhalten ändert sich (Token-Abrechnung, Tool-Aufrufe, Sicherheitsparameter).
• Interne Teams wechseln, und benutzerdefinierte Adapter werden zu ungeschriebenem Expertenwissen.

Test für den Einkauf:

„Wenn wir nächstes Jahr den Modellanbieter wechseln, wie viele Repositories müssen geändert werden?“

Wenn die Antwort nicht „fast keine“ lautet, haben Sie keine einkaufssichere Architektur.

Wo TrueFoundry einen Mehrwert bietet:

TrueFoundry bietet eine anbieterunabhängige API-Schicht, die OpenAI, Bedrock, Gemini, Anthropic und selbst gehostete Modelle hinter einem einzigen Vertrag normalisiert – sodass Anwendungen niemals anbieterspezifische Logik enthalten.

KI-Architekturfrage Nr. 2: Können wir jeden KI-Entscheidungspfad nachvollziehen?

Eine weitere wichtige Frage zur KI-Architektur, die Einkaufsteams bei der Evaluierung stellen, lautet:

„Wenn sich ein Kunde beschwert, können wir den vollständigen KI-Entscheidungspfad rekonstruieren?“

Herkömmliche API-Logs helfen Ihnen hier nicht weiter. LLM-Systeme sind Multi-Modell- Workflows mit mehreren Interaktionsrunden und Richtlinien.

Unternehmen, die bei der Evaluierung ihrer KI-Architektur erfolgreich sind, trennen zwei operative Ebenen strikt voneinander.

• Datenebene: Live-Traffic, latenzkritisch, verbleibt innerhalb des Unternehmensnetzwerks.
• Steuerungs-/Analytik-Ebene: Logs, Traces, Metriken, verwendet für Audits und Fehlersuche.

In großen Unternehmen fällt die Entscheidung meist explizit aus: Sie möchten einen zentralisierten Observability-Stack (zum Beispiel Arize) betreiben, unabhängig davon, welches Gateway oder welche KI-Plattform sie wählen, da sie eine Analytik-Ebene benötigen, die Daten aus verschiedenen Systemen jenseits des Gateways erfassen kann. Die Herausforderung liegt nicht im Kauf von Arize, sondern darin, die richtigen Daten zu erfassen, bevor sie dorthin übertragen werden:

• Prompts
• gewähltes Modell
• Token-Anzahl
• Richtlinienentscheidungen
• Antwortvarianten

Praktische Architekturregel:

• Speichern Sie KI-Interaktionslogs in offenen Formaten (zum Beispiel Parquet) in Ihrem eigenen Bucket.
• Sorgen Sie für Wiederholbarkeit: „Zeigen Sie mir den exakten Chat, das Modell und den Richtlinienpfad.“

Test für die Beschaffung:

„Wenn der Anbieter morgen vom Markt verschwindet, haben wir dann noch verwertbare Audit-Daten?“

Wenn Observability-Daten nur innerhalb einer proprietären Benutzeroberfläche existieren, werden Rechts- und Compliance-Abteilungen bei der Evaluierung der KI-Architektur erhebliche Bedenken anmelden.

Wo TrueFoundry einen Mehrwert bietet:

TrueFoundry bietet von Haus aus KI-natives Tracing (Chat-Ansichten, Prompt-/Modell-Wiedergabe, Kostenaufschlüsselungen), das die tägliche Fehlersuche und Governance abdeckt.

Für Unternehmen mit zentralen Observability-Vorgaben bietet TrueFoundry strukturierte, unternehmenseigene Telemetriedaten, die Tools wie Arize ergänzen, anstatt sie zu ersetzen.

KI-Architekturfrage Nr. 3: Können Prompt-Änderungen ohne erneute Bereitstellung (Redeployment) vorgenommen werden?

Das wirkt zunächst unbedeutend, bis es zum Problem wird.

In vielen Unternehmen sieht es heute so aus:

• Prompts sind fest im Code verankert
• Prompt-Änderung → Redeploy → QA → Freigaben
• Fachexperten können Prompts nicht ohne Unterstützung durch die Entwicklung ändern

Die Beschaffungsabteilung hat nicht deshalb Einwände, weil es „schlechtes Engineering“ ist.
Sie hat Einwände, weil dadurch versteckte Betriebskosten entstehen.

In großen Unternehmen ist eine hohe Frequenz bei der Prompt-Iteration zu erwarten – insbesondere bei externen oder kundenorientierten Anwendungsfällen. Jedes Redeploy bedeutet Reibungsverluste, Risiko und Kosten. Stellen Sie sich beispielsweise vor, eine Vorschrift ändert sich (z. B. der EU AI Act) und ein Disclaimer-Prompt muss in 50 Apps aktualisiert werden – können Sie das zentral in 5 Minuten erledigen oder benötigen Sie dafür 50 teure Engineering-Sprints?

Diese Frage ist bei der Evaluierung der KI-Architektur im Unternehmen von entscheidender Bedeutung.

Praktische Architekturregel:

• Anwendungen sollten eine prompt_id übergeben, nicht den Prompt selbst.
• Prompts liegen in einer zentralen Registry, sind versioniert, prüfbar und ohne Redeploy änderbar.

Das ist kein „Nice-to-have“. Es ist der entscheidende Unterschied, ob KI von Business-Teams bedient werden kann oder dauerhaft durch die Entwicklung ausgebremst wird.

Test für die Beschaffung:

„Wie viele Produktions-Releases erfordert eine einzige Prompt-Änderung?“

Wenn die Antwort größer als null ist, ist Ihre TCO-Rechnung falsch.

Wo TrueFoundry einen Mehrwert bietet:

TrueFoundry unterstützt die Prompt-Hydrierung am Gateway. Dadurch können Anwendungen Prompts per ID referenzieren, während Fachexperten die Versionen zentral und mit vollständiger Historie verwalten.

KI-Architektur-Frage Nr. 4: Wird Governance innerhalb der KI-Architektur durchgesetzt?

Einer der am schnellsten wachsenden Bereiche bei der Bewertung von KI-Architekturen betrifft die Governance.

Wir haben viele große Unternehmen erlebt, die dachten: „Gateways bieten uns jetzt eine Modellvereinheitlichung, aber MCP, Tool-Zugriff und Agenten-Governance werden später unser Problem sein.“

Viele Teams unterschätzen, wie schnell die Komplexität der Governance wächst:

• interne Entwickler
• externe Anbieter
• mehrere Agenten, die auf Tools zugreifen
• unterschiedliche Berechtigungen je nach Anwendungsfall

Wenn Governance nicht am Gateway durchgesetzt wird, bauen Teams später ein paralleles System auf – mit Beratern, Übergaben und einer dauerhaften Wartungslast.

Umsetzbare Architekturregel:

• Tool-Zugriff, Agenten-Berechtigungen, Ratenbegrenzungen und Leitplanken müssen direkt im Datenverkehr durchgesetzt werden, nicht durch nachgelagerte Prüfungen.

Test für die Beschaffung:

„Wenn wir die Anzahl der Apps im nächsten Jahr verdoppeln, verdoppeln sich dann auch die Governance-Kosten?“

Wenn ja, wird die Beschaffungsabteilung dies als zukünftiges Risiko einstufen.

Wo TrueFoundry einen Mehrwert bietet:

Das KI-Gateway von TrueFoundry umfasst ein produktionsreifes MCP-Gateway mit zentraler Richtliniendurchsetzung für Tools, Agenten und Identitäten. Es ist darauf ausgelegt, die Governance zu skalieren, ohne den Personalbestand zu erhöhen.

KI-Architektur-Frage Nr. 5: Können wir KI-Ausgaben kontrollieren und zuordnen?

Eine der praktischsten Fragen zur KI-Architektur, die Beschaffungsteams bei der Bewertung stellen, betrifft die Preisgestaltung und Kostenzuordnung.

• Pro Benutzer?
• Pro Dienstkonto?
• Pro API-Aufruf?
• Pro App?

Die Abrechnung über Service-Accounts fördert schlechte Praktiken (geteilte Schlüssel, fehlende Zuordnung). Sie benötigen Kostentransparenz pro Anwendung oder Workload, statt verschleierter Nutzung.

Praktische Architekturregel:

• Jeder KI-Workload muss zuordenbar sein: App, Eigentümer, Budget, Limits.
• Die Preisgestaltung sollte sich an diesem Zuordnungsmodell orientieren.

Test für die Beschaffung:

„Können wir die Ausgaben für eine App begrenzen, ohne andere zu beeinträchtigen?“

Wenn nicht, wird die Finanzabteilung einer Skalierung der Nutzung niemals zustimmen.

Wo TrueFoundry Mehrwert bietet:

Die Zuordnung pro App bzw. Workload ist möglich, da Apps als eigenständige Identitäten eingebunden werden können (statt die Nutzung geteilter Service-Accounts zu fördern).

Kosten-Leitplanken können zentral durchgesetzt werden (Quoten, Routing, Drosselung), damit Teams die Kosten nicht versehentlich in die Höhe treiben und sich dann mit einem „Hoppla“ herausreden können.

Warum wird die Bewertung von KI-Architekturen zur Aufgabe der Beschaffung?

Früher lag die Bewertung von KI-Architekturen fast ausschließlich bei den Engineering-Teams. Heute ist sie in Unternehmen ebenso sehr ein Thema für Beschaffung, Finanzen, Sicherheit und Compliance.

Der Grund ist einfach: KI-Systeme im Unternehmen schaffen langfristige betriebliche Abhängigkeiten, die später nur schwer rückgängig zu machen sind. Sobald sich eine Organisation auf einen bestimmten KI-Stack festlegt, wählt sie nicht mehr nur einen Modellanbieter, sondern entscheidet sich für ein Ökosystem aus Governance-Schichten, Observability-Systemen, Routing-Infrastruktur, Compliance-Tools, Cloud-Abhängigkeiten und Agent-Frameworks, die das Unternehmen über Jahre hinweg prägen können.

Beschaffungsteams erkennen zunehmend, dass Entscheidungen aus der Pilotphase oft zu dauerhaften architektonischen Vorgaben werden. Ein System, das während eines Proof of Concept flexibel erscheint, kann extrem teuer in der Migration werden, sobald Dutzende Anwendungen, Workflows und interne Teams davon abhängen.

Deshalb prüfen Unternehmenskäufer KI-Architekturen heute deutlich sorgfältiger als noch vor einem Jahr. Eine glänzende Demo mag Führungskräfte anfangs beeindrucken, doch Beschaffungsteams konzentrieren sich auf tiefergehende betriebliche Fragen: Wie schwierig ist ein späterer Anbieterwechsel? Kann das Unternehmen das KI-Verhalten zuverlässig prüfen? Wird die Governance mit zunehmender Verbreitung schwieriger? Sind die Kosten für eine langfristige Budgetierung vorhersehbar? Unterstützt das System eine realistische Multi-Cloud-Strategie?

In der Praxis ähneln KI-Architekturprüfungen in Unternehmen immer mehr Infrastrukturbewertungen als klassischen Software-Evaluierungen. Die Sorge gilt nicht mehr nur der Frage, ob die KI heute funktioniert, sondern ob die Architektur über die nächsten fünf Jahre steuerbar, portabel und wirtschaftlich nachhaltig bleibt.

Wie TrueFoundry in eine beschaffungsfreundliche GenAI-Gesamtarchitektur passt

Eine beschaffungsfreundliche GenAI-Architektur besteht aus drei unverzichtbaren Ebenen:

Ebene 1: Provider-Abstraktion (Exit-Strategie)

Ihre Anwendung ruft ein Gateway auf, nicht direkt eine Modell-API. Prompts, Tools und Guardrails werden einmalig definiert. Der Wechsel von OpenAI zu Anthropic oder einem selbst gehosteten Modell wird so zu einer Konfigurationsänderung statt zu einer kompletten Neuentwicklung.

Warum das wichtig ist: Wenn ein Anbieter die Preise verdreifacht, haben Sie Alternativen. Wenn ein Modell eingestellt wird, geraten Sie nicht in Bedrängnis. Exit-Klauseln werden damit glaubwürdig.

Ebene 2: Kosten- und Qualitätskontrolle (Budgetschutz)

Ihre Architektur leitet Anfragen basierend auf der Absicht weiter, nicht nur nach Verfügbarkeit. Einfache Anfragen gehen an schnelle, kostengünstige Modelle. Komplexe Aufgaben werden von leistungsstarken Spitzenmodellen übernommen. Wenn die Kosten steigen, passen Sie einfach die Routing-Regeln an. Sie müssen nicht in Panik über Verträge neu verhandeln.

Warum das wichtig ist: Die TCO über fünf Jahre werden planbar. CFOs können Kostenkurven modellieren. Der Einkauf kann Budgetzusagen rechtfertigen, weil Sie das System auf Kostenschwankungen ausgelegt haben.

Ebene 3: Observability und Provenance (Compliance-Nachweis)

Jede Anfrage wird protokolliert: welches Modell, welche Richtlinie wurde angewendet, auf welche Daten wurde zugegriffen, wurden Inhalte durch Guardrails blockiert? Wenn die Rechtsabteilung fragt: „Hat diese Kundeninteraktion GPT-4 genutzt?“, zeigen Sie den Trace, statt zu raten.

Warum das wichtig ist: Compliance wird systematisch statt manuell. Die Rechtsabteilung kann Audits durchführen. Der Einkauf kann dem Vorstand gegenüber Risiken fundiert begründen.

Das Fazit

Der Einkauf ist nicht gegen KI. Er ist gegen unumkehrbare Entscheidungen.

Das eigentliche Ziel der Evaluierung einer Enterprise-KI-Architektur ist die Reduzierung langfristiger operativer, regulatorischer und finanzieller Risiken, bevor die KI-Nutzung im gesamten Unternehmen skaliert.

Eine Checkliste für eine einkaufsfreundliche KI-Architektur:

• Vendor-Lock-in & Exit
  
  • Können wir den Gateway-Anbieter durch eine einfache Änderung von DNS/URL wechseln, ohne die App neu schreiben zu müssen?
  • Erfordert der Anbieter ein proprietäres SDK in unserem Anwendungscode?
  • Werden Protokolle/Telemetriedaten in offenen Formaten gespeichert, die wir auch ohne den Anbieter lesen können?
• Datenkontrolle & Compliance-Nachweise
  
  • Bleibt der Live-Datenverkehr (Data Plane) bei Bedarf innerhalb unserer Umgebung?
  • Sind Protokolle und Analysen trennbar (sodass wir sie zentralisieren können, ohne den Laufzeitverkehr zu verschieben)?
  • Können wir einen Bericht zur „Rekonstruktion von Anfragen“ erstellen: Absicht → Prompt → Modell → Richtlinienentscheidungen → nachgelagerte Aufrufe → endgültige Antwort?
  • Können wir nachweisen, wohin sensible Daten geflossen sind: welches Modell/welcher Anbieter, welche Region, welche Aufbewahrungsrichtlinie?
  • Gibt es prüfungsfertige Exporte, die wir ohne manuellen Aufwand für interne Audits oder Regulierungsbehörden bereitstellen können?
• Betriebliche Resilienz
  
  • Wie sieht das Support-SLA aus und entspricht es der Realität im Produktionsbetrieb?
  • Können wir Multi-Region-/Multi-Instanz-Setups (Aktiv-Aktiv oder Aktiv-Passiv) ohne Neugestaltung betreiben?
  • Werden Richtlinien inline ausgeführt, ohne zusätzliche Netzwerk- oder Datenbankaufrufe (sodass das Hinzufügen von Kontrollen kein Latenzrisiko darstellt)?
• Budgetdurchsetzung
  
  • Was ist die Abrechnungseinheit und steht sie im Einklang mit der Governance?
  • Können wir die Nutzung pro Anwendung/Abteilung begrenzen, ohne andere zu beeinträchtigen?
  • Können wir monatliche Chargeback-Berichte erstellen: Eigentümer, App, Umgebung, Modellmix, Token-Verbrauch?
  • Sind wir vor einer „Erfolgssteuer“ (Kostenexplosion bei zunehmender Nutzung) geschützt?
• Multi-Modell- und Multi-Cloud-Realität
  
  • Normalisiert das Gateway die Anbieter wirklich über Marketingversprechen hinaus (Unterschiede zwischen Bedrock/Gemini)?
  • Erfordert das Hinzufügen eines neuen Anbieters Änderungen am Anwendungscode oder nur an der Konfiguration?
  • Kann das Gateway auf selbst gehostete Modelle innerhalb unseres Netzwerks zugreifen?

Und hier ist der entscheidende Punkt: Diese Architektur kommt auch der Technik zugute.
Weniger Umschreiben. Weniger ungeplante Eskalationen. Sauberere Abstraktionen.

Der schnellste Weg, GenAI im Unternehmen zu skalieren, sind keine besseren Demos, sondern das System so sicher zu machen, dass es gekauft werden kann.

Erfahren Sie, wie eine beschaffungsfreundliche KI-Architektur in der Praxis funktioniert

TrueFoundry unterstützt Unternehmen dabei, GenAI-Systeme zu entwickeln, die einfacher zu steuern, zu skalieren und weiterzuentwickeln sind, ohne Anwendungen an einen einzigen Modellanbieter zu binden. Von Multi-Modell-Routing und zentraler Governance bis hin zu Observability, Prompt-Management und Kostenkontrolle: TrueFoundry AI Gateway wurde entwickelt, um Plattform-, Beschaffungs- und Engineering-Teams dabei zu helfen, KI-Projekte mit weniger operativen Überraschungen in die Produktion zu bringen. Demo buchen.