Tag 7: From Data Audit to AI Platform Stack

Marc

Hallo und herzlich willkommen zum heutigen vertieften Update für die AI Business Specialist Klasse der Graduate School for Applied Technology und Management Zürich. Heute ist Mittwoch, der 26. August 2026. Ich bin Marc.

Stefan

Und ich bin Stefan. Wir nehmen uns heute intensiv Zeit für Tag 7 des Programms mit Martin Meyer. Die Lektion wurde umgestellt und wir führen euch heute durch die fundamentale Methodik der Lagebeurteilung für KI Plattformen. Das Ziel des Abends ist eine belegbare Basis für das spätere Solution Design. Wir wollen die 20 Minuten Grenze knacken und gehen deshalb in jedes wichtige Detail rein.

Marc

Absolut. Beginnen wir gleich mit dem wichtigsten Grundsatz für alle Aussagen im gesamten Programm. Martin Meyer betont das immer wieder: Es bringt überhaupt nichts, wenn man im Management oder in der Prüfung mit Bauchgefühl argumentiert. Floskeln wie Ich habe das Gefühl, dass diese Cloud besser ist, sind wertlos. Jede fachliche Bewertung muss zwingend dreiteilig aufgebaut sein: Aussage, Erkenntnis und Konsequenz.

Stefan

Genau. Schauen wir uns diese Dreiheit an einem konkreten Beispiel an. Die Aussage lautet: Drei Viertel unserer unstrukturierten Reglementsdaten weisen fehlende oder veraltete Metadaten auf. Die Erkenntnis daraus: Ein automatisierter KI Abruf über diese ungeprüften Dokumente führt mit hoher Wahrscheinlichkeit zu falschen Antworten beim Kunden. Die Konsequenz: Wir können diesen Anwendungsfall derzeit nicht direkt in Produktion bringen, sondern müssen zuerst die Datenbasis bereinigen. Das ist sauberes Management Handwerk.

Marc

Und genau diese Dreiheit durchzieht den ganzen Abend an Tag 7. Das Herzstück der heutigen Lagebeurteilung ist eine Zwölf Punkte Checkliste. Es handelt sich um zwölf kritische Fragen, die man klären muss, bevor überhaupt eine Zeile Code geschrieben oder eine konkrete Lösung angedacht wird. Wir deklinieren diese zwölf Fragen heute Abend an einem sehr einleuchtenden Fall durch: dem Chatbot für den Innovationsverband Schweizer Arbeitsmarkt, kurz ISA.

Stefan

Bevor wir in die einzelnen Fragen und Schichten einsteigen, müssen wir zwingend das Leitprinzip der Data Gravity klären. Dave McCrory hat das schon 2010 auf den Punkt gebracht: Daten besitzen virtuelle Masse und erzeugen eine Anziehungskraft. Die fundamentale Regel lautet: Die Logik und die Intelligenz folgen den Daten, nicht die Daten der Intelligenz. Wer versucht, riesige Datenmengen dorthin zu bewegen, wo gerade ein schickes KI Modell sitzt, zahlt gewaltig drauf.

Marc

Das Bewegen von Daten über Cloud Grenzen hinweg kostet dreifach: erstens die reinen Egress und Transfergebühren, zweitens Latenzzeit im laufenden Betrieb und drittens gewaltige Governance Risiken wegen doppelter Datenhaltung. Deshalb schauen wir im Daten Audit von Tag 6 zuerst nach, wo die Führungssysteme und Betriebsdaten liegen. Und genau dorthin bringen wir die Plattform. Ist es das Lakehouse bei Databricks, das Warehouse bei Snowflake, das ERP bei SAP oder das CRM bei Salesforce? Die Datenlage bestimmt die Kandidatenliste.

Stefan

Jetzt gehen wir Schritt für Schritt durch das Sieben Layer Modell der KI Plattformwahl. Wir schauen uns jeden Layer im Detail an, erklären die Fragen aus der Zwölf Punkte Checkliste, zeigen auf, wo Deadlocks drohen, woran man ein Projekt rechtzeitig stoppen kann und wo kreative Lösungen liegen. Es ist im Enterprise Bereich nämlich nie nur schwarz oder weiß.

Marc

Beginnen wir ganz unten bei Layer 1: Infrastruktur und Compute. Hier geht es um physische Rechenleistung, Speicher, Netzwerke und Standorte. Die erste kritische Frage lautet: In welcher Region läuft das System und steht diese Region explizit im Vertrag statt nur in einer Marketing Broschüre? Für unseren ISA Chatbot haben wir öffentlich zugängliche Reglementsdaten, aber auch Anfragen von Kunden. Wir prüfen als Kandidaten eine Schweizer Region beim Hyperscaler wie Azure Switzerland North oder lokale Schweizer Anbieter wie Exoscale.

Stefan

Wo liegt hier auf Layer 1 ein klassischer Deadlock? Ein Deadlock entsteht, wenn eure Compliance Vorgaben zwingend eine Speicherung und Verarbeitung im Schweizer Rechtsraum verlangen, der gewählte Anbieter aber in seinen AGBs vorbehält, Daten zur Inferenz in US Rechenzentren zu leiten. Ist diese Klausel nicht verhandelbar, ist das Projekt auf dieser Plattform sofort tot. Ein K.o. Kriterium schließt die Option aus.

Marc

Wie sieht hier die pragmatische Lösung aus? Es ist eben nicht nur schwarz weiß. Die Lösung kann eine hybride Netztrennung sein: Wir halten den Wissensspeicher mit den Reglementen in der eigenen DMZ auf Schweizer Servern, beispielsweise bei Exoscale in Zürich. An die externe Modell API schicken wir pro Anfrage nur den reinen Fragetext ohne Personendaten. Dadurch schrumpft das rechtliche Risiko auf ein Minimum, ohne dass wir auf leistungsfähige Sprachmodelle verzichten müssen.

Stefan

Gehen wir zu Layer 2: Foundation Models. Hier geht es um das Sprachmodell selbst, um Tiers wie Frontier, Mid Tier oder Open Weight, um Kontextfenster, Tokenpreise und API Formate. Die kritische Frage lautet: Welches Modell Tier braucht die Aufgabe wirklich und was gilt bei einer Abkündigung des Modells ohne direkten Nachfolger? Für unseren ISA Chatbot brauchen wir für einfache Fragen wie Wann startet der Kurs kein teures Frontier Modell wie GPT 5 oder Claude Opus. Ein Mid Tier Modell oder ein Open Weight Modell reicht völlig.

Marc

Der Deadlock auf Layer 2 entsteht, wenn ein Anbieter ein Modell in eurer Region mendantenweit abkündigt und ihr den Prompt direkt fest an die herstellerspezifische API verdrahtet habt. Wenn das Modell verschwindet, bricht eure gesamte Anwendung zusammen. Ein reales Beispiel zeigt OpenAI: Im Februar 2026 kündigten sie ältere Modelle in ChatGPT mit kurzer Frist ab. Wenn ein Unternehmen darauf nicht vorbereitet ist, steht der Betrieb still.

Stefan

Die Lösung auf Layer 2 lautet: Bauet eine eigene Abstraktionsschicht vor die Modell API. Verdrahtet Prompts und Werkzeugaufrufe nicht direkt mit dem Endpunkt des Anbieters. Wenn ihr eine Abstraktionsschicht nutzt, wird der Wechsel von Claude auf GPT oder auf das offene Schweizer Modell Apertus zu einer reinen Konfigurationsfrage. Wir lassen das offene Modell Apertus im Regressionstest dauerhaft mitlaufen, damit der Ausweichpfad erprobt ist.

Marc

Kommen wir zu Layer 3: Daten und Kontext. Hier liegen Quelltexte, Vektorindexe, Kurskataloge und Zugriffsrechte. Die kritischen Fragen lauten: Wo liegt der Index, in welchem Format, wer darf löschen und wie schnell kommen Änderungen in den Vektorraum? Beim ISA Chatbot kommen Kursdaten per API aus der Kurs App, während die Beschreibungen in Broschüren PDFs liegen. Ein enormer Deadlock entsteht, wenn sich zwei Quellen im eigenen Haus widersprechen, etwa alte Preise auf der Website und neue Preise im PDF.

Stefan

Das ist der berühmte Fall Air Canada von 2024: Der Chatbot erfand einen Trauerfall Tarif, weil veraltete Richtlinien im System standen. Das Gericht urteilte, dass das Unternehmen für Aussagen seines Bots voll haftet. Der Deadlock auf Layer 3 ist also kein technischer, sondern ein inhaltlicher. Ein Modell kann schlechte Daten oder widersprüchliche Dokumente nicht von alleine korrigieren. Kein Modell behebt schlechte Labels oder fehlende Governance.

Marc

Die Lösung auf Layer 3: Definiert für jede Information genau ein führendes System of Record. Im ISA Case bestimmt die Kurs App verbindlich den Preis. Der Vektorindex in der DMZ wird nachts automatisch aus diesem führenden System aktualisiert. Wenn zwei Dokumente sich widersprechen, muss der Mensch vor der Indexierung entscheiden, welcher Text gilt. Ohne saubere Datenlandkarte aus Tag 6 darf kein Wissensspeicher gebaut werden.

Stefan

Weiter zu Layer 4: Orchestrierung und Runtime. Hier sitzt der eigentliche Ablauf zwischen Frage und Antwort: Suchen, Prüfen, Formulieren, Wiederholen und Eskalieren. Die kritische Frage lautet: Wem gehört die Ablaufkonfiguration, dem Anbieter im No Code Baukasten oder unserem eigenen Code Repository? Das ist der aufwendigste Teil des ganzen Systems und hier versteckt sich das größte technische Lock in.

Marc

Der Deadlock auf Layer 4: Wenn ihr den Agentenablauf komplett in einem proprietären Baukasten eines Anbieters zusammenklickt, könnt ihr bei einem Plattformwechsel gar nichts mitnehmen. AWS hat das eindrücklich gezeigt: Als Bedrock Agents Classic nach 32 Monaten für Neukunden geschlossen wurde, mussten Anwendende auf AgentCore migrieren. Wer seinen Ablauf in proprietären Logiken gebaut hat, fängt bei Null an. Auch Sicherheitsprobleme wie bei Replit 2025, wo ein Agent unkontrolliert Daten löschte, passieren auf der Runtime Ebene.

Stefan

Die Lösung auf Layer 4: Versioniert die Ablauflogik, die Prompts und die Guardrails in eurem eigenen Repository, beispielsweise mit offenen Frameworks wie LangGraph. Der Agent selbst ist portabel, wenn die Steuerung in eurem Code liegt. So könnt ihr die Runtime wechseln, ohne die Logik neu erfinden zu müssen. Zudem gehört eine strikte Trennung von Entwicklungs und Produktivumgebungen mit echten Schranken dazu.

Marc

Schauen wir auf Layer 5: Integration und Protokolle. Wie kommt der Agent an eure Systeme wie CRM, Mailserver oder Kursverwaltung? Die Fragen lauten: Welche Protokolle nutzen wir, welche Rechte hat der Agent und was passiert im Fehlerfall? Wenn ein System nicht antwortet, darf der Bot nicht abstürzen oder halluzinieren, sondern muss den Fall sauber in eine Warteschlange stellen oder an einen Menschen übergeben.

Stefan

Auf Layer 5 ist die Technik dank offener Standards heute weitgehend gelöst, aber die wirtschaftliche Seite erzeugt Deadlocks. Standards wie das Model Context Protocol MCP von Anthropic und Agent to Agent A2A 1 Punkt 0 der Linux Foundation erlauben es, dass Agenten herstellerübergreifend kommunizieren. Aber wo liegt der wirtschaftliche Haken? Wer bezahlt die Rechenzeit, wenn ein fremder Agent euren Agenten aufruft? Wenn eine Schnittstelle plötzlich monetarisiert wird, wie Reddit das 2023 zeigte, explodieren die Integrationskosten über Nacht.

Marc

Die Lösung auf Layer 5: Nutzt konsequent offene Standards wie MCP für Werkzeuge und A2A für Agenten Interaktion. Baut eigene MCP Server vor eure Systeme wie die Kurs App. Und sichert euch vertraglich ab: Datenexporte, Fristen und Rechte an Protokollen müssen im Vertrag stehen. Holt euch Leserechte für den Bot, aber gebt ihm niemals ohne menschliche Freigabe Schreibrechte auf produktive Kundendatenbanken.

Stefan

Jetzt zu Layer 6: Application und Agenten. Das ist das Fenster, in dem die Nutzerin tippt, also das Chat Widget auf der Website oder die Einbettung in Microsoft Teams. Die Frage lautet: Wem gehören Oberfläche, Gesprächsverlauf und Auswertungen? Hier entsteht der schnellste Nutzen, aber auch die stärkste Bindung. Wenn ihr ein fertiges Bot Produkt kauft, gehören dem Anbieter meist die Prozesslogik und das Datenmodell. Ein Wechsel bedeutet ein neues Projekt.

Marc

Ein Deadlock auf Layer 6 zeigt das Beispiel Klarna aus dem Jahr 2024 und 2025. Klarna ersetzte hunderte Kundendienstmitarbeitende durch einen KI Assistenten. Anfangs feierten sie die Einsparungen, korrigierten aber 2025 öffentlich nach: Die Antwortqualität war gesunken und Kunden waren unzufrieden. Klarna musste wieder verstärkt menschliche Fachkräfte aufbauen. Wer auf Layer 6 den menschlichen Eskalationspfad streicht, um Kosten zu sparen, kauft sich eine Qualitätskrise ein.

Stefan

Die Lösung auf Layer 6: Garantierte Übergabe an den Menschen. Für unseren ISA Chatbot gilt: Wenn der Bot eine Frage zu komplexen Themen wie individuelle Fördergelder oder Rechnungen nicht sicher beantworten kann, reicht er den bisherigen Gesprächsverlauf nahtlos per E Mail an die Geschäftsstelle weiter. Der Mensch übernimmt sofort ohne Informationsverlust. Zudem bauen wir das Chat Widget im eigenen Code auf swiss aibs.ch, damit der Verlauf in unserer Hand bleibt.

Marc

Schließlich Layer 7: Vertical SaaS. Das sind fertige Branchenlösungen, die einen kompletten Fachprozess abdecken, etwa spezialisierte Software für Bildungsanbieter. Ihr kauft kein Modell, sondern ein fertiges Ergebnis samt fremdem Prozessmodell. Der Deadlock droht hier, wenn eure spezifischen Schweizer Sonderregeln, zum Beispiel AMM Bestimmungen oder RAV Vorgaben, nicht in das starre Schema des Anbieters passen. Das Projekt MD Anderson mit IBM Watson zeigt eine 62 Millionen Dollar Abschreibung, weil die Vertikallösung nicht in das Spitalsystem passte.

Stefan

Deshalb gilt an Tag 7 die Prüftiefe Regel: Vertical SaaS ist heute nur eine Zeile in eurer Kandidatenliste mit der Layer Angabe. Die detaillierte Produktevaluation und der Beschaffungsentscheid Build, Buy oder Partner gehören zu Tag 10. Wer heute schon Produkte vergleicht, nimmt Tag 10 vorweg und verliert die Vergleichbarkeit über die Plattformen.

Marc

Jetzt kommen wir zu einem ganz zentralen Block der heutigen Lektion: der detaillierten Kostenrechnung. Marc, lass uns die Zahlen für den ISA Chatbot genau durchrechnen. Warum sieht ein Eigenbau auf den ersten Blick verlockend aus, erweist sich aber bei genauer Betrachtung als intensiv beim internen Personalaufwand?

Stefan

Das ist der Aha Effekt des Abends. Viele denken, KI Kosten bestehen nur aus Token Preisen. Beim ISA Chatbot rechnen wir mit rund 300 Kundenanfragen im Monat. Bei 5 Verarbeitungsschritten pro Anfrage entstehen etwa 7 Millionen Token im Monat. Das kostet bei modernen Modellen gerade einmal 15 bis 55 Franken im Monat, also etwa 700 bis 2000 Franken über drei Jahre. Die reinen Inferenzkosten machen weniger als 3 Prozent der Gesamtkosten aus.

Marc

Und wie sieht die Gesamtrechnung über drei Jahre aus? Schauen wir uns alle sieben Kostenpositionen beim Eigenbau im Vergleich zu fertigen SaaS Lösungen an. Beim Eigenbau kostet die Technik für Hosting und Vektorsuche etwa 1500 bis 6000 Franken über drei Jahre. Der Erstbau von Widget, Retrieval und API Anbindung dauert dank moderner Entwicklerwerkzeuge nur etwa 6 bis 12 Personentage, was etwa 5000 bis 10000 Franken entspricht.

Stefan

Aber jetzt kommt der große Posten, der in fast jeder Offerte fehlt: der laufende Betrieb und die inhaltliche Pflege. Technischer Betrieb für Updates, Regressionstests bei Modellwechseln und Protokollanalysen schlägt mit 4 bis 8 Tagen pro Jahr zu, also 9000 bis 19000 Franken in drei Jahren. Die inhaltliche Pflege, also Antworten stichprobenartig prüfen, Reglement und Preise bei Änderungen nachführen, erfordert 1 bis 2 Stunden pro Woche. Das macht 13000 bis 27000 Franken.

Marc

Rechnet man noch Schulung der Geschäftsstelle mit 1500 bis 4000 Franken dazu, kommt der Eigenbau über drei Jahre auf eine Bandbreite von 31000 bis 68000 Franken. Und das Entscheidende: Rund 70 bis 75 Prozent dieser Summe sind interner Personalaufwand. Nicht die Lizenz ist teuer, sondern die Arbeit von Menschen, die die Qualität sichern. Ist das bei fertigen Softwareprodukten wie Copilot Studio, Intercom Fin oder Agentforce anders?

Stefan

Vergleicht man fertige Lösungen für unser Volumen von 300 Anfragen im Monat, zeigt sich ein verblüffendes Bild. ChatGPT Business kostet rund 14000 Franken über drei Jahre, ist aber nur intern nutzbar. Copilot Studio kommt auf etwa 19500 Franken. Intercom Fin verlangt pro gelöster Anfrage und liegt bei ca 20400 Franken. Zendesk mit Copilot liegt bei 31600 Franken. Und Salesforce Agentforce verlangt 2 Dollar pro Konversation, was bei 47800 Franken landet.

Marc

Das bedeutet: Bei einem geringen Volumen von 300 Anfragen im Monat ist eine fertige SaaS Lösung rein finanziell bei den Ausgaben oft günstiger als der vollständige Eigenbau, weil der eigene Aufwand für Pflege und Betrieb voll zu Buche schlägt. Der Eigenbau rechtfertigt sich bei kleinem Volumen nicht über den Preis, sondern über maßgeschneiderte Passung, Datenresidenz und volle Kontrolle über die Daten. Erst ab 1200 bis 1500 Anfragen im Monat kippt die reine Kostenrechnung zugunsten des Eigenbaus.

Stefan

Vergesst zudem nicht das Gartner Inferenz Paradoxon vom 17. August 2026: Die Kosten pro Token sinken zwar stetig, aber die Inferenzkosten pro agentischem Ablauf steigen bis 2028 um mehr als das Fünffache, weil Agenten mehr Rechenschritte und Selbstkorrekturen durchführen. Wer nur den Tokenpreis rechnet, rechnet falsch. Maßgebend sind die Gesamtkosten pro gelöstem Fall. Gebt in eurer Vergleichsmatrix daher immer eine Bandbreite an und niemals einen Punktwert.

Marc

Lass uns nun die Entscheidungsmethodik nach Kepner Tregoe festigen. Martin Meyer verlangt in der Lektion eine saubere Trennung von MUSTS und WANTS. Ein K.o. Kriterium, also ein MUST, wird nie verrechnet oder mit Punkten gewichtet. Wer die Schweizer Datenresidenz oder die Auftragsverarbeitung nicht erfüllt, fliegt sofort aus der Matrix. Gewichtet werden nur die WANTS wie Modellauswahl, Integration, Betriebsreife oder Dreijahreskosten.

Stefan

Ganz wichtig: Kriterien und Gewichte müssen feststehen, bevor der erste Kandidat bewertet wird. Wer Gewichte nachträglich anpasst, schreibt eine Rechtfertigung und keine Entscheidung. In jede Zelle der Matrix gehören drei Angaben: der Wert, der Beleg mit Stand Datum und die Konfidenz, also ob die Angabe belegt, geschätzt oder dünn ist. Dünn hinzuschreiben ist kein Makel, sondern ehrliches Management.

Marc

Und die Entscheidung ist erst dann vollständig, wenn sie einen Revisionsauslöser enthält. Das ist die Bedingung, unter der ihr die Entscheidung offiziell zurücknehmt. Ein Auslöser muss messbar, terminiert und von einer dritten Person überprüfbar sein. Für unseren ISA Chatbot lautet ein Revisionsauslöser: Bleibt die Übergabequote an die Geschäftsstelle über zwei Quartale hinweg über 40 Prozent, wird die Plattformwahl neu aufgemacht. Das ist konkret und prüfbar.

Stefan

Zum Schluss blicken wir auf die Aufgabenzerlegung, die von Tag 6 hierher verschoben wurde. Machbarkeit ist auf Rollenebene nicht beurteilbar. Die Aussage Der Kundendienst wird automatisiert ist wertlos. Wir zerlegen eine Rolle in 10 bis 20 konkrete Tätigkeiten mit Verben. Für jede Aufgabe bestimmen wir die Datenlage aus Tag 6, die Fehlerkosten und den Automatisierungsgrad. Die Studien von Frey und Osborne zeigten auf Rollenebene 47 Prozent Automatisierungsrisiko, die OECD auf Aufgabenebene nur 9 Prozent.

Marc

Genau. Aufgaben mit guter Datenlage und hohen Fehlerkosten werden nicht vollautomatisiert, sondern nur assistiert aufgebaut. Aufgaben mit schlechter Datenlage stellt man zurück. Nur Aufgaben mit guter Datenlage und geringen Fehlerkosten eignen sich für automatisierte Agenten. Das ist die Vorarbeit, die ihr ab 20 Uhr in der begleiteten Projektarbeit für euer eigenes Projekt leistet und die Tag 8 als Kriterium Realisierbarkeit benötigt.

Stefan

Zusammenfassend für den heutigen Abend: Wendet konsequent das Schema Aussage, Erkenntnis, Konsequenz an. Beantwortet die zwölf kritischen Fragen der Checkliste. Beachtet Data Gravity. Rechnet alle sieben Kostenarten als Bandbreite über drei Jahre durch. Setzt K.o. Kriterien vorab und formuliert einen messbaren Revisionsauslöser. So baut ihr ein Fundament, das vor jeder Revisionsprüfung hält. Wir wünschen euch viel Erfolg bei der Projektarbeit. Bis zum nächsten Mal.