Publiziert: Zuletzt aktualisiert:

KI-Strategie

KI-Strategie: zuerst der Wert, dann die Architektur, dann das Werkzeug

KI-Strategie klärt vor den Werkzeugen, wo KI Wert schafft, ob man baut, einkauft oder selbst betreibt, welches Risiko man trägt und in welcher Reihenfolge. Sie ist die Investitionsentscheidung, nicht die Kontrolle.

Die meisten KI-Vorhaben scheitern nicht an der Technik, sondern an der fehlenden Entscheidung davor. Ein Werkzeug wird eingeführt, weil es alle einführen, ohne dass jemand benennt, welches Geschäftsproblem es löst. KI-Strategie dreht die Reihenfolge um: zuerst der Wert, dann die Architektur, dann das Werkzeug. Diese Seite beschreibt, wo KI in einem Unternehmen Wert schafft, wie sich die Bau-, Kauf- und Betriebsentscheidung schneiden lässt, wie viel Risiko man tragen will und wie eine Roadmap aussieht, die in den ersten neunzig Tagen etwas liefert. Sie grenzt sich bewusst von zwei Nachbarn ab: Sie ist der KI-spezifische Schnitt der allgemeinen Geschäftsstrategie, und sie ist getrennt von der KI-Governance, die nicht das Wo, sondern das Wie der Kontrolle klärt. Beide werden gebraucht.

Wo KI Wert schafft

Bevor über Modelle oder Anbieter gesprochen wird, gehört jeder Anwendungsfall in ein einfaches Raster aus zwei Achsen: dem Wertbeitrag (was bringt es, wenn es funktioniert) und der Machbarkeit (wie sicher und wie aufwändig ist der Weg dahin). Das Raster trennt die vier Felder, die jede KI-Roadmap ordnen:

  • Hoher Wert, hohe Machbarkeit. Die ersten Vorhaben. Klar umrissenes Problem, vorhandene Daten, messbarer Nutzen. Hier beginnt die Roadmap, nicht beim spektakulärsten Anwendungsfall.
  • Hoher Wert, geringe Machbarkeit. Die langfristigen Vorhaben. Sie gehören auf die Roadmap, aber als Vorhaben mit Vorarbeit (Daten, Kompetenz, Architektur), nicht als Sofortstart.
  • Geringer Wert, hohe Machbarkeit. Die Versuchung. Leicht zu bauen, aber ohne Wirkung auf das Geschäft. Hier verbrennt sich das meiste Budget in Demos, die niemand produktiv nutzt.
  • Geringer Wert, geringe Machbarkeit. Nicht jetzt. Dokumentieren und wiedervorlegen, nicht starten.

Der Wert entsteht selten dort, wo die Schlagzeile ist. Routinearbeit mit hohem Volumen, wissensintensive Recherche und die Aufbereitung unstrukturierter Daten bringen in der Praxis mehr als der eine generative Vorzeigefall. Genau deshalb beginnt das Raster mit dem Geschäftsproblem und nicht mit der Fähigkeit des Modells. Das deckt sich mit dem nüchternen Befund aus der Praxis: KI scheitert dort, wo ein fehlerhafter Prozess automatisiert wird, statt ihn zuerst neu zu denken.

Build vs Buy vs Host

Steht der Anwendungsfall, folgt die Architektur-Entscheidung, und hier liegt der KI-spezifische Unterschied zur klassischen Make or Buy-Frage. Bei KI gibt es nicht zwei, sondern drei Optionen, weil die dritte über die Datensouveränität entscheidet:

  • Buy. Eine fertige KI-Funktion oder ein Anbieter-Modell als Dienst (Standardware, Commodity). Schnell, geringe Anfangskosten, aber die Daten verlassen das Haus und die Abhängigkeit vom Anbieter wächst.
  • Build. Eine eigene Lösung auf fremden Modellen oder eigener Logik. Mehr Kontrolle über das Produkt, mehr Aufwand, die Frage des Modell-Betriebs bleibt offen.
  • Host. Ein Open-Weights-Modell auf der eigenen oder einer Schweizer Infrastruktur. Kein Datenabfluss in eine US-Cloud, kein Vendor Lock-in, dafür Hardware-, Betriebs- und ein mögliches Qualitäts-Delta zu den grössten geschlossenen Modellen.

Die dritte Option ist der eigentliche Grund, warum KI eine eigene Strategie braucht. Sobald besonders schützenswerte Daten im Spiel sind, ist Host nicht die teure Sonderlösung, sondern oft die einzige, die Datensouveränität und Regelkonformität in einem erfüllt. Wer diese Architektur einmal aufgebaut hat, betreibt sie nicht für einen, sondern für viele Anwendungsfälle. Die KI-Werkbank ist die Leistung, die genau diesen Weg konkret macht. Die Wahl ist dabei nicht für immer und nicht für alles gleich: ein unkritischer interner Assistent darf eingekauft werden, während die Recherche auf Mandantendaten gehostet gehört.

flowchart TD
    A["Anwendungsfall mit<br/>klarem Wertbeitrag"] --> B{"Besonders<br/>schützenswerte Daten?"}
    B -->|"Ja"| C["Host<br/>Open-Weights auf eigener<br/>oder Schweizer Infrastruktur"]
    B -->|"Nein"| D{"Differenziert es<br/>das Geschäft?"}
    D -->|"Nein"| E["Buy<br/>fertiger Dienst,<br/>Standardware"]
    D -->|"Ja"| F["Build<br/>eigene Lösung auf<br/>fremden Modellen"]
    F --> G{"Bleibt der Betrieb<br/>im Haus nötig?"}
    G -->|"Ja"| C
    G -->|"Nein"| H["Build auf<br/>Anbieter-Modell"]

Das Diagramm liest sich von oben nach unten als Folge weniger Fragen: erst die Datenklasse, dann die Frage nach der geschäftlichen Differenzierung, zuletzt die Betriebsfrage. Es ersetzt keine Detailbewertung, aber es verhindert die häufigste Verwechslung, nämlich eine Buy-Bequemlichkeit dort, wo die Datenklasse längst Host verlangt.

Risiko-Appetit und Roadmap

Strategie heisst auch, vorab zu entscheiden, wie viel Unsicherheit man trägt. KI-Vorhaben sind nicht deterministisch: das Modell antwortet nicht jedes Mal gleich, und der Nutzen lässt sich vor dem Pilot selten exakt beziffern. Der Risiko-Appetit legt fest, wo ein Mensch in der Schleife bleibt, welche Fehlerquote ein Anwendungsfall verträgt und ab wann ein Vorhaben gestoppt wird. Diese Schwellen gehören in die Strategie, nicht in die spätere Diskussion mit dem ersten Fehlschlag.

Aus Raster und Risiko-Appetit wird die Roadmap. Sie ordnet die Vorhaben nicht nach Begeisterung, sondern nach dem Quadranten: die machbaren Werttreiber zuerst, die strategischen Wetten mit ihrer Vorarbeit dahinter, die Versuchungen bewusst ausgeklammert. Eine belastbare KI-Roadmap ist Teil der Innovationsmanagement-Praxis und kein einmaliges Dokument; die laufende Sichtung der Modell- und Werkzeuglandschaft, auf der sie aufsetzt, gehört zum Tech-Radar. Der ehrliche Teil der Roadmap ist das Stopp-Kriterium: ein Pilot, der den erwarteten Wert nicht zeigt, wird beendet, nicht gerettet.

Die ersten 90 Tage

Eine KI-Strategie beweist sich nicht im Strategiepapier, sondern im ersten Quartal. Ein bewährter Schnitt:

  • Wochen 1 bis 4: Sichten und schneiden. Anwendungsfälle sammeln, ins Raster legen, einen einzigen machbaren Werttreiber auswählen. Parallel den Risiko-Appetit und die Datenklassen festhalten, denn sie bestimmen die Architektur.
  • Wochen 5 bis 8: Beweisen. Den gewählten Fall als schlanken, messbaren Prototyp bauen, mit echten Daten und einem vorab definierten Erfolgsmass. Ein abgegrenztes Erstprojekt der KI-Werkbank liefert genau diesen Beweis in einem festen Rahmen, statt das Lernen über Monate zu strecken.
  • Wochen 9 bis 12: Entscheiden. Den Prototyp am Erfolgsmass messen und die Build-vs-Buy-vs-Host-Entscheidung für den Produktivbetrieb treffen. Bestätigt sich der Wert, folgt die Skalierung mit der passenden Architektur; bestätigt er sich nicht, wird das Stopp-Kriterium gezogen und der nächste Quadrant gewählt.

Dieser Takt hält die Strategie ehrlich. Er erzwingt einen belegten Nutzen, bevor Geld in Skalierung fliesst, und er macht die Architektur-Entscheidung an einem realen Fall statt an einer Folie. Was die Strategie an Wert und Reihenfolge festlegt, hält danach die KI-Governance im Betrieb steuerbar, von der Modellfreigabe bis zum Nachweis.

Datensouveränität als Eingangsbedingung

Für datenintensive Anwendungsfälle ist die Datensouveränität kein nachgelagerter Kontrollpunkt, sondern eine Eingangsbedingung der Investitionsentscheidung: Wer entscheidet, wo ein Modell läuft, entscheidet zugleich, wer Zugriff auf die verarbeiteten Daten erhält. Für ein Schweizer Unternehmen ist die Build-vs-Buy-vs-Host-Frage damit zugleich eine Standortfrage. Sobald Personendaten in eine US-Cloud fliessen, können das revidierte Datenschutzgesetz und der US Cloud Act parallel relevant werden, insbesondere bei US-Anbietern bzw. US-Kontrolle über die Daten, und die Buy-Bequemlichkeit wird zum Compliance-Risiko. Deshalb verschiebt sich für solche Anwendungsfälle der Schwerpunkt der Strategie zur Host-Option, und die Datensouveränität trägt die Entscheidung von Anfang an. Die Einordnung der Modell- und Werkzeuglandschaft, auf die sich die Roadmap stützt, liefert die Leistung Tech-Radar und KI-Governance. Tiefer in die einzelnen Schichten gehen die benachbarten Neuland-Seiten zu den Sprachmodellen, zu KI-Agenten, zu LLMOps und MLOps sowie zu souveräner KI und zur Entscheidung zwischen Fine-Tuning, RAG und Prompting.

Referenzen

  • Deloitte Tech Trends 2026. Jahresbericht zu den prägenden Technologietrends; nur ein kleiner Teil der Unternehmen betreibt KI-Agenten produktiv, und Vorhaben scheitern oft an automatisierten statt neu gedachten Prozessen. (10.12.2025). www.deloitte.com/us/en/insights/topics/technology-management/tech-trends.html
  • OECD KI-Prinzipien, Aktualisierung 2024. Fünf wertebasierte Prinzipien und fünf Empfehlungen für vertrauenswürdige KI, getragen von 47 Staaten und Organisationen. (03.05.2024). oecd.ai/en/ai-principles
  • NIST AI Risk Management Framework (AI RMF 1.0). Freiwilliges US-Rahmenwerk zum Steuern von KI-Risiken über die vier Funktionen Govern, Map, Measure und Manage. (26.01.2023). www.nist.gov/itl/ai-risk-management-framework
  • MIT Sloan Management Review und BCG Winning With AI. Studie zum Wertbeitrag von KI; sieben von zehn Unternehmen berichten zunächst geringe oder keine Wirkung, der Erfolg liegt im Zusammenspiel aus Strategie, Organisation und Technologie. (2019). sloanreview.mit.edu/projects/winning-with-ai/

Verwandte Themen

KI fragen

Diese Links öffnen externe KI-Dienste, die Unterhaltung und deren Inhalt werden dabei an den jeweiligen Anbieter übertragen.