Wer entscheidet, ob ein KI-Agent 0,03 oder 0,12 US-Dollar pro Transaktion kostet? Nicht das Modell. Nicht das Budget. Die Antwort liegt in der Data Architecture. Im dritten und letzten Teil dieser Serie zeigen wir, wie Finance Layer Data Architecture in der Praxis aussieht: von der Plattformwahl über Agent-Readiness bis zur strategischen Dekommissionierung. Wer die ersten Teile noch nicht gelesen hat: Dort haben wir das Fundament gelegt, warum Adressierbarkeit über Datenqualität geht (Teil 1) und warum Kapital sich zur Datenschicht verschiebt (Teil 2).
Wie wirkt sich Data Architecture auf Financial Statements aus?
Data-Platform-Verantwortliche sprechen selten die Sprache der Bilanz. CFOs, die Plattformausgaben prüfen, verstehen umgekehrt die technischen Kostentreiber nicht. Diese gegenseitige Unleserlichkeit erzeugt Probleme, die sich über Zeit potenzieren.
Klassische On-Premise-Infrastruktur war CAPEX: Server werden gekauft, über die Nutzungsdauer abgeschrieben, als Vermögenswert bilanziert. Cloud-Infrastruktur ist überwiegend OPEX: sofort aufwandswirksam, direkt in der Periode der Entstehung in der GuV. Das macht Plattformkosten für CFOs auf Quartalsbasis sichtbarer, was zwar nach verbesserter Governance klingt, aber perverse Anreize erzeugt. Der Druck, Cloud-Ausgaben im laufenden Quartal zu senken, geht auf Kosten von Architekturinvestitionen, die den Total Cost of Ownership über mehrere Jahre reduzieren würden.
Wo Kosten landen, bestimmt die Prüfungsintensität
- KI-Kosten in den COGS erhalten intensive Board-Aufmerksamkeit. Sie beeinflussen die Bruttomarge direkt
- KI-Kosten in F&E werden als investitionsähnlich bewertet mit Ertrag in späteren Perioden
- KI-Kosten in der G&A erhalten oft die geringste strategische Aufmerksamkeit und senden dabei möglicherweise genau die falschen Signale
Die Abschreibungsfrage wird zunehmend problematisch: Unternehmen, die KI-Entwicklung nach ASC 350-40 oder IAS 38 aktivieren, behaupten eine Nutzungsdauer über mehrere Jahre, für Systeme, die oft schon nach 18 Monaten grundlegend überarbeitet werden müssen.
Snowflake vs. Databricks: Zwei unterschiedliche Finanzinstrumente
Wenn ein CIO eine dreijährige Plattformverpflichtung unterzeichnet, trifft er eine Kapitalallokationsentscheidung. Sie prägt Kostenpfade, schränkt Architekturentscheidungen ein und bestimmt, was sich das Unternehmen mit Agenten leisten kann. Dennoch bewerten die meisten Plattformauswahlprozesse Features und Benchmarks. Fast keiner modelliert das Finanzverhalten der Plattform unter den Workload-Mustern, die Agentic-Deployment erzeugt.
Snowflake und Databricks sind keine austauschbaren Produkte mit unterschiedlichem Logo. Sie sind unterschiedliche Finanzinstrumente.
Snowflake
Das separierte Compute-Modell berechnet nach Warehouse-Laufzeit und belohnt Disziplin und Vorhersehbarkeit. Es bestraft Parallelität: Agenten, die Hunderte von kurzen, hochfrequenten Abfragen gegen die Semantic Layer ausgeben, lösen Skalierungskosten aus, die BI-only-Projektionen nie vorgesehen haben.
Databricks
Die Abrechnung über DBUs (normierte Verarbeitungseinheiten) belohnt starke Engineering-Disziplin. Es bestraft Unreife: Unoptimierte Spark-Jobs, schlecht partitionierte Tabellen und überweitende Retrieval-Pipelines verbrennen DBUs ohne proportionalen Mehrwert.
In der Praxis: Bei vergleichbaren Workloads können die jährlichen Plattformkosten um 100 % auseinanderlaufen. Rein basierend auf der Passung zwischen dem Finanzmodell der Plattform und der operativen Reife der Organisation.
Was bedeutet Apache Iceberg für diese Entscheidung?
Die Konvergenz rund um Apache Iceberg dürfte die finanziell bedeutendste Infrastrukturentwicklung seit der Cloud-Migration sein. Wenn Daten in einem offenen Format auf Object Storage liegen, wird die Compute-Schicht austauschbar. Entscheidungen, deren Rückgängigmachung früher 18-monatige Migrationen erforderte, können nun in Wochen revidiert werden. Organisationen, die Iceberg adoptieren, kaufen sich Optionalität.
Welche drei Schichten braucht eine agentenfähige Data Architecture?
Agent-Readiness lässt sich als Stack mit drei Schichten verstehen:
Schicht 1 „Retrieval“: Kann ein Agent die benötigten Daten finden? Hier konzentrieren sich heute die meisten Investitionen: Vector Stores, RAG-Pipelines, Embedding-Optimierung.
Schicht 2 „Semantik:“ Versteht der Agent, was die Daten bedeuten, welche Geschäftslogik gilt, welche Einschränkungen anwendbar sind?
Schicht 3 „Aktion“: Kann der Agent eine gesteuerte Operation mit Kostenzuordnung, Audit-Trail und Leitplanken ausführen ?
Die meisten Unternehmen investieren in Schicht 1, während Schichten 2 und 3 unterfinanziert bleiben. Deshalb können aktuelle Agent-Deployments Informationen abrufen, aber nicht zuverlässig handeln.
Warum sind spezialisierte Agenten generalistischen wirtschaftlich überlegen?
Der häufigste Architekturirrtum ist der Generalist-Agent. Ein Agent, der für alle Domänen gebaut wird, muss den Kontext jeder möglichen Aufgabe mitführen. Mit Zugriff auf alle Datenquellen, alle Schemas, alle Geschäftsregeln. Das Ergebnis: größere Kontextfenster, mehr Token pro Inference, schwächere Governance.
Spezialisierte Agenten invertieren diese Gleichung. Ein Beschaffungsagent benötigt Zugriff auf Lieferantendaten, Vertragsbedingungen und Genehmigungsworkflows, aber nicht auf HR-Daten, Marketing-Analytics oder Finanzplanungsmodelle. Weniger Token pro Inference, präziseres Retrieval, engere Governance. Die Unit Economics verbessern sich auf jeder Ebene des Stacks.
Konkret: Ein spezialisierter Agent, der Beschaffungsanfragen für 0,03 US-Dollar pro Transaktion verarbeitet, übertrifft einen Generalisten bei derselben Aufgabe für 0,12 US-Dollar. Allein aufgrund dieser Architekturentscheidung.
Agent Routing wird damit zur Architekturanforderung: Eine Routing-Schicht über den spezialisierten Agenten klassifiziert eingehende Anfragen und leitet sie an den am besten geeigneten Agenten weiter. Der Model Context Protocol (MCP)-Standard vereinheitlicht dabei die Schnittstelle, über die Agenten auf Datenquellen und Tools zugreifen und reduziert den Engineering-Aufwand für Spezialisierung erheblich.
Was ist der Dual-Run-Tax und was kostet er?
Nicht alle Architekturentscheidungen haben gleiches Gewicht. Manche sind reversibel: ein Datenmodell ändern, ein Orchestrierungstool tauschen, eine Pipeline refaktorieren. Andere sind strukturell: Plattformwahl, mehrjährige Cloud-Commitments, Data-Residency-Entscheidungen, Kern-Schema-Design.
Wer strukturelle Entscheidungen falsch trifft oder eine inkonsistente Doppelarchitektur betreibt, zahlt den Dual-Run-Tax: die multiplikative Last, alte und neue Systeme gleichzeitig zu betreiben. In der Praxis liegt dieser Faktor bei 2,2x bis 2,5x und nicht bei 2x weil parallele Systeme Datensynchronisation zwischen Umgebungen erfordern, Mitarbeiterkapazitäten zwischen zwei Paradigmen aufteilen, doppelte Governance erzeugen und Zeitpläne verlängern.
Was bedeutet strategische Dekommissionierung?
Diese Asymmetrie schafft eine Verpflichtung, die die meisten Organisationen vernachlässigen: den aktiven Abbau von Legacy-Komponenten. Systeme in Produktion, die nicht zur aktuellen Wertschöpfung beitragen, verursachen laufende Kosten: Wartung, Security-Patching, gebundenes Wissen, Governance-Overhead.
Die freigesetzte Kapazität durch Legacy-Abbau ist oft wertvoller als die durch Neueinstellungen hinzugewonnene. Die Frage, die Finance vor jeder Plattformentscheidung stellen sollte: Was ist der Umkehrpreis? Entscheidungen mit hohem Umkehrpreis erfordern eine andere Governance-Intensität als Entscheidungen, die zum Preis von Engineering-Zeit rückgängig gemacht werden können.
Fazit: Data Architecture ist eine wirtschaftliche Disziplin
Data Architecture ist keine technische Spezialisierung, die Artefakte für andere Teams produziert. Sie ist zu einer wirtschaftlichen Disziplin geworden, die bestimmt, was eine Organisation mit KI erreichen kann und zu welchen Kosten.
Data Architects, die die Sprache von Unit Economics, TCO-Modellierung und OPEX/CAPEX-Abwägungen nicht sprechen, werden an Einfluss verlieren. Gerade während die technische Bedeutung ihrer Arbeit wächst. Die Perspektive des CFO sollte als Einschränkung betrachtet werden, die Architektur verbessert indem sie Klarheit über Wertschöpfung und Kostenzuordnung erzwingt.
Unternehmen, die im Agentic-Zeitalter am schnellsten Wert schöpfen, werden jene sein, die Data Architecture als erstklassige strategische Investition behandeln. Mit derselben Strenge wie M&A-Aktivitäten oder bedeutende Kapitalallokationsentscheidungen.
Möchten Sie wissen, wo Ihre Data Architecture im Agentic-Zeitalter steht?
Specific Group unterstützt Unternehmen dabei, Datenarchitekturen zu entwickeln, die nicht nur technisch, sondern auch wirtschaftlich tragfähig sind. Sprechen Sie mit unseren Experten für Data & AI und finden Sie heraus, wie Ihre Organisation von einem Finance-Layer-Ansatz profitieren kann.
Karl Ivo Sokolov ist Managing Director Data & AI bei der Specific Group Austria und leitet internationale Teams in acht europäischen Ländern. Er ist Mitglied des Global Board of Directors des U.S. Institute of Management Accountants (IMA).
Mario Meir-Huber ist ehemaliger Head of Data und Ex-Microsoftie. Er hat Datenprodukte für europäische Unternehmen entwickelt, lehrt an der WU Wien und TU Wien und ist Mitautor des Handbook Data Science & AI.
Karl Ivo Sokolov und Mario Meir-Huber sind Co-Autoren von „Finance-Grade Data & AI Products: The VANE Loop Framework“ (Jan. 2026).
Quellen
- Sokolov, K.I. & Meir-Huber, M. (2026). Finance-Grade Data & AI Products: The VANE Loop Framework. Vane Loop Research. vaneloop.com/book
- Frey, M. (2026). „Scaling Beyond Code: The Architecture of Leadership.“ Vienna Engineering Management Meetup.
- Inmon, W.H. & Linstedt, D. (2014). Data Architecture: A Primer for the Data Scientist. Morgan Kaufmann.
- Taleb, N.N. (2012). Antifragile: Things That Gain from Disorder. Random House.
- Gartner (2025). „40% of Enterprise Applications Will Feature Task-Specific AI Agents by 2026.“
- MuleSoft (2026). „2026 Connectivity Benchmark Report.“
By Franz Zahn
By Nathalie Nesiba
By Christoph Frohner
By DI Dr. Christoph Auer
By Dzevad Mujezinovic