# Mission 006: Abhängigkeiten bleiben steuerbar

> Wie bleiben Modelle, Anbieter, Zustände und Kosten austauschbar beziehungsweise beherrschbar?

**Ergebnis:** Portabilität, Souveränität, transparente Wirtschaftlichkeit und bewusste Abhängigkeiten.

Veröffentlicht 24.06.2026 · zuletzt geändert 25.06.2026 · fachlich geprüft von Markus Berg (25.06.2026) · für Architektur, IT-Leitung, FinOps.

## In 30 Sekunden
Modell-, Cloud- und Plattformabhängigkeiten müssen steuerbar bleiben — ohne die Architektur durch übermäßige Abstraktion zu verkomplizieren. Portabilität entsteht durch klare Verträge, eigene Evaluationsdaten und bewusst gewählte Abhängigkeiten.

## Warum das wichtig ist
Modelle, Clouds und Frameworks ändern sich schnell. Wer ohne Wechselmöglichkeit baut, zahlt später mit Lock-in, steigenden Kosten oder fehlender Souveränität.

Gleichzeitig ist totale Anbieterunabhängigkeit teuer. Ziel ist nicht maximale Abstraktion, sondern eine bewusste, dokumentierte Entscheidung pro Abhängigkeit.

_Redaktionelle Einordnung:_ Portabilität heißt nicht „alles austauschbar machen“, sondern wissen, was austauschbar sein muss. Ein Model Gateway und eigene Evaluationsdaten bringen mehr als eine generische Abstraktionsschicht über allem.

## Zentrale Architekturfragen
- Welche Abhängigkeiten sind bewusst gewählt — und welche schleichend entstanden?
- Können wir den Modellanbieter wechseln, ohne die Anwendung neu zu bauen?
- Ist der Agent-State portabel oder an einen Anbieter gebunden?
- Kennen wir die Kosten pro Geschäftsergebnis, nicht nur pro Token?
- Evaluieren wir Qualität vor und nach einem Anbieterwechsel?

## Typische Muster
- **Model Gateway:** ein kontrollierter Punkt für Modellauswahl und -wechsel.
- **Portabler Agent State:** Zustand nicht an proprietäre Dienste gebunden.
- **Cloud Exit & Data Residency:** bewusste Entscheidungen über Ort und Ausstieg.
- **FinOps for AI:** Kosten- und Wertsteuerung von KI-Workloads.
- **Kosten pro Ergebnis:** Wirtschaftlichkeit am Geschäftsergebnis gemessen.

## Anti-Patterns
- Direkte Bindung an proprietäres Anbieter-Memory ohne Ausweg.
- Abstraktion über alles — Komplexität ohne realen Nutzen.
- Kosten nur pro Token, nie pro Geschäftsergebnis betrachtet.
- Anbieterwechsel ohne Vorher-Nachher-Evaluation.

## Praktische Prüffragen
- Könnten wir den Hauptmodellanbieter in vertretbarer Zeit wechseln?
- Ist der Agent-State exportierbar?
- Kennen wir die Kosten pro Geschäftsergebnis?
- Haben wir eigene Evaluationsdaten für einen Wechselvergleich?

## Bezug zum Praxisbeispiel (Service-Agent)
Welche Anbieterabhängigkeiten bestehen, was kostet ein Vorgang — und welche Daten verlassen das Haus?

- Der Modellanbieter ist über ein Model Gateway austauschbar, ohne die Anwendung neu zu bauen.
- Die Kosten werden pro bearbeitetem Fall (Geschäftsergebnis) gemessen, nicht nur pro Token.
- Es ist bewusst entschieden, welche Daten externe Dienste erreichen dürfen und welche im Haus bleiben.
- Eigene Evaluationsdaten erlauben einen Vorher-Nachher-Vergleich bei einem Anbieterwechsel.

[Zum durchgehenden Praxisbeispiel](https://agent-007.ai/praxis/service-agent.md)

## Bezug zur Referenzarchitektur
Diese Mission betrifft die unteren Ebenen (Core Systems, Cloud) und das Control Plane (Model Routing, Cost & Usage). Sie hält die in 003 gebauten Integrationen wirtschaftlich und souverän.

## Primärquellen
- [FinOps for AI](https://www.finops.org/framework/technology-categories/ai/) — FinOps Foundation (Primärquelle), geprüft 24.06.2026. Rahmen für Kosten- und Wertsteuerung von KI-Workloads.
- [Model Context Protocol — Spezifikation](https://modelcontextprotocol.io/specification/2025-11-25) — MCP Project (Spezifikation), geprüft 24.06.2026. Offener Standard für Tool-/Kontextanbindung — reduziert anbieterspezifische Bindung.
- [CycloneDX ML-BOM](https://cyclonedx.org/capabilities/mlbom/) — OWASP / CycloneDX (Spezifikation), geprüft 24.06.2026. Maschinenlesbare Bestandteile und Abhängigkeiten von ML-/KI-Systemen.



---
Quelle (kanonisch): https://agent-007.ai/missionen/006-portabilitaet-souveraenitaet-oekonomie/