KI-Governance trifft FinOps: Kosten, Datenflüsse und Policies für GenAI kontrollieren

Generative KI ist in den IT-Abteilungen angekommen — und damit auch die Frage nach den Kosten. Wer GenAI-Workloads unkontrolliert laufen lässt, kann schnell unangenehme Überraschungen auf der Cloud-Rechnung erleben. Dieser Beitrag zeigt, wie sich KI-Governance und FinOps sinnvoll verbinden lassen.

Warum Governance ohne FinOps nicht funktioniert

Viele AI-Governance-Programme fokussieren auf Recht/Compliance (wichtig), übersehen aber:

• Token-/Request-Kosten wachsen exponentiell mit „einfach mal ausprobieren“
• Schattennutzung (private API Keys) unterläuft Security und Budget
• Datenklassifizierung entscheidet, ob ein Use Case überhaupt erlaubt ist

Wenn ihr FinOps und Governance trennt, bekommt ihr am Ende weder Compliance noch Kostenkontrolle.

Ein minimales Control-Set (das wirklich hilft)

1) Use-Case Registry

• Owner
• Zweck
• Datenklasse (Public/Internal/Confidential/Secret)
• Modell/Provider
• Architektur-Skizze (wohin gehen Prompts/Outputs?)

2) Policy: welche Daten dürfen in Prompts?

Pragmatisch starten:

• Keine Secrets/Passwörter/Tokens
• Keine personenbezogenen Daten ohne Freigabe
• Keine vertraulichen Vertragsinhalte ohne DPA/AVV

3) Kosten-Grenzen pro Use Case

• monatliches Budget
• Alert bei 70/90/100%
• harte Quota, wenn möglich

Telemetrie: die eine Metrik, die ich immer will

„Cost per outcome“ ist schwer. „Cost per request“ ist zu simpel.

Ein guter Start ist:

• Kosten pro Team/Cost Center
• Kosten pro App/Service
• Token Input/Output pro Modell

Beispiel: vereinheitlichte Logging-Events

{
  "ts": "2026-02-11T09:00:00+01:00",
  "app": "customer-support-bot",
  "provider": "openai",
  "model": "gpt-4.1-mini",
  "tenant": "prod",
  "user": "svc-supportbot",
  "input_tokens": 1200,
  "output_tokens": 180,
  "cost_eur": 0.012,
  "data_class": "internal",
  "policy_result": "allow"
}

Wenn ihr diese Events zentral (SIEM/Log-Platform) habt, sind sowohl Governance-Reports als auch FinOps-Reports plötzlich dieselbe Datenquelle.

Guardrails, die sich bewährt haben

Modell-/Provider-Whitelisting

• wenige freigegebene Modelle
• klare Kriterien (DPA, Region, Retention, Training-Opt-Out)

API Key Management

• keine Entwickler-Keys in Clients
• Keys nur serverseitig
• Rotation und Scopes

Prompt-/Output-Filtering

• DLP-Regeln für Prompts
• Content-Filter für Outputs (z.B. PII-Leaks)

Takeaways

• Governance und FinOps gehören zusammen: Transparenz ist die gemeinsame Basis.
• Startet mit einem Use-Case-Register + Datenklassifizierung.
• Baut ein einheitliches Event-Schema für Kosten und Policy-Entscheidungen.
• Whitelist statt Wildwuchs: Modelle/Provider bewusst freigeben.
• Quotas und Alerts verhindern, dass „Pilot“ zur Kostenfalle wird.