Am Anfang eines KI-Projekts dreht sich oft alles um die Modellfrage: Welches Modell passt, was kann es und wie lässt es sich anbinden? Sobald die Arbeit beginnt, zeigt sich jedoch schnell, dass die eigentlichen Hürden woanders liegen.
Zuerst braucht es einen Anwendungsfall, der den Aufwand rechtfertigt. Dann müssen Daten rechtmässig und zuverlässig verfügbar sein, Identitäts- und Fachsysteme zusammenspielen und klare Qualitätskriterien feststehen. Nach dem Launch kommt der Betrieb hinzu. Schon ein neuer Prompt, ein anderes Modell oder ein aktualisierter Suchindex kann das Verhalten verändern. Google Cloud behandelt generative KI deshalb als laufenden Software-Lebenszyklus aus Discovery, Experimenten, Evaluation, Deployment und Überwachung, nicht als einmalige Einführung eines Modells.
Bei der Wahl einer Beratung zählt daher mehr als technisches KI-Wissen. Sie sollte offene Fragen klären und das eigene Team in die Lage versetzen, nach dem Mandat selbstständig weiterzuarbeiten.
Der Teil, der wirklich schwierig ist
Bei den richtigen Aufgaben schafft KI einen messbaren Nutzen. Daraus folgt allerdings nicht, dass sie auch bei der nächsten Aufgabe zuverlässig funktioniert. Ein Blick auf die Forschung zeigt beide Seiten.
Das National Bureau of Economic Research untersuchte Mitarbeitende im Kundendienst. Wer Zugang zu einem generativen KI-Assistenten hatte, arbeitete im Schnitt knapp 14 % produktiver. Die Harvard Business School begleitete 758 Beratende in einem Feldexperiment. Innerhalb der Leistungsgrenze des Modells erledigten sie 12,2 % mehr Aufgaben und brauchten 25,1 % weniger Zeit. Bei einer Aufgabe, die bewusst jenseits dieser Grenze lag, fanden dieselben Personen die richtige Lösung um 19 % seltener.
Die Zahlen liefern kein einfaches Urteil für oder gegen KI. Sie zeigen etwas Wichtigeres: Die Grenze zwischen „funktioniert gut“ und „liegt überzeugend daneben“ verläuft unregelmässig, mitten durch die konkreten Aufgaben eines Unternehmens. Wo genau, weiss zu Beginn niemand. Ein gutes Mandat macht diese Grenze sichtbar. Eine allgemeine Präsentation zur KI-Strategie schafft das nicht.
Für die Auswahl eines Partners lässt sich daraus ein einfacher Grundsatz ableiten:
Eine KI-Beratung lohnt sich nicht, weil ein Unternehmen „etwas mit KI“ machen möchte. Sie lohnt sich, wenn konkrete Unsicherheiten bei Nutzen, Daten, Architektur, Integration, Sicherheit, Regulierung oder Betrieb geklärt werden müssen. Am Ende sollten nicht nur Folien bleiben, sondern Ergebnisse, mit denen das eigene Team weiterarbeiten kann.
Was Sie in jeder Phase erhalten sollten
Methodendiagramme sehen bei fast allen Beratungen überzeugend aus. Aussagekräftiger ist eine einfache Frage: Was liegt am Ende jeder Phase tatsächlich vor, und wem gehört es? Strategie, generative KI, Retrieval-Augmented Generation, Agenten und Modellauswahl sind dabei keine voneinander getrennten Disziplinen. Sie gehören zum selben Software-Lebenszyklus. Auch das NIST behandelt KI-Risiken in seinem AI Risk Management Framework als fortlaufenden Kreislauf aus Govern, Map, Measure und Manage, nicht als einmalige Prüfung.
| Phase | Was die Beratung tut | Was Sie erhalten sollten |
|---|---|---|
| Strategie und Opportunity Discovery | Befragt Fach- und Technikverantwortliche, prüft Mengen, Fehlerkosten und messbare Ziele und trennt KI-Probleme von gewöhnlichen Softwareproblemen | Priorisierte Anwendungsfälle, Nutzenhypothesen, Baseline-Kennzahlen, Machbarkeits- und Risikomatrix sowie eine Liste der verworfenen Fälle mit Begründung |
| Prozessanalyse | Zeichnet Ablauf, Entscheidungen, Ausnahmen und Übergaben auf, bevor etwas automatisiert wird | Ist- und Soll-Prozesse, Integrationsübersicht, Ausnahmepfade, Rolle der menschlichen Aufsicht, Grenzen der Automatisierung |
| Datenreife | Klärt, welche Daten es gibt, wer sie verantwortet, wie aktuell und verlässlich sie sind und was rechtmässig genutzt werden darf | Dateninventar, Zugriffsmatrix, Qualitätsbefunde, Berechtigungsmodell, Plan für die Lücken und ein repräsentativer Evaluationsdatensatz |
| Architektur und Modellintegration | Vergleicht Foundation Models und klassisches ML und entscheidet über APIs, Orchestrierung, Abruf, Fine-Tuning oder deterministische Bausteine | Architekturbilder, Entscheidungsprotokolle, Modellvergleich, Sicherheitsgrenzen, Kostentreiber, Abhängigkeit von Anbietern |
| Prototyp oder MVP | Baut einen möglichst kleinen, aber vollständigen Ablauf, der den Nutzen unter realistischen Bedingungen belegt | Funktionsfähige Anwendung, Quellcode, Deployment-Konfiguration, erste Integrationen, erste Evaluationsergebnisse, dokumentierte Grenzen |
| Produktionsengineering | Ergänzt Anmeldung, Berechtigungen, Umgang mit Geheimnissen, Logging, Observability, Fallbacks, Limits, Nachvollziehbarkeit und Eskalation | Produktionscode, CI/CD-Pipeline, IAM-Konfiguration, Bedrohungsmodell, Tests, Governance-Unterlagen, Runbooks |
| Evaluation und Launch | Prüft Antwortqualität, Abruf, Sicherheit, Verhalten unter Angriff und Fachkennzahlen gegen vorher vereinbarte Kriterien | Versionierter Testsatz, Ergebnisse je Anwendungsfall, Schwellenwerte, Befunde aus dem Red Teaming, Launch-Entscheid, Liste offener Risiken |
| Betrieb und Optimierung | Überwacht Verhalten, Latenz, Kosten, Fehler, Rückmeldungen und Regressionen, während Modelle und Daten sich ändern | Dashboards, Alarme, Incident-Prozess, Regressionstests, Versionshistorie, Update-Politik, Wissenstransfer |
Wenn ein Anbieter die rechte Spalte nicht konkret beschreiben kann, bleibt es bei Beratung, auch wenn das Angebot von Umsetzung spricht. Google nennt in seinen Leitlinien unter anderem Evaluationsdaten für typische Fälle und Randfälle, Versionskontrolle und CI/CD auch für Prompts und Abrufsysteme, Logging über die gesamte Kette sowie fortlaufende Evaluation nach dem Launch.
Prompt Engineering ist davon nur ein kleiner Ausschnitt. Ob eine Anwendung im Alltag funktioniert, hängt genauso von Abruf, Anwendungslogik, Modellen, Schnittstellen, Berechtigungen und Bedienung ab.
RAG und Agenten erhöhen die Anforderungen
Retrieval-Augmented Generation, kurz RAG, eignet sich für Systeme, die mit internen oder häufig wechselnden Informationen arbeiten. Vereinfacht gesagt sucht die Anwendung zuerst passende Inhalte in den Unternehmensdaten und gibt sie dem Modell als Kontext mit. Das klingt geradlinig, hat aber einige Tücken. Microsoft weist in der Foundry-Dokumentation selbst darauf hin, dass die Qualität stark von der Aufbereitung der Dokumente und den Einstellungen des Abrufs abhängt. Auch mit Quellenkontext kann eine Antwort falsch sein. Sind die Zugriffsrechte unsauber umgesetzt, macht die Suche zudem vertrauliche Inhalte auffindbar.
Zu einem RAG-Mandat gehört deshalb mehr als eine Vektordatenbank. Nötig sind verlässliche Import- und Aktualisierungsprozesse, eine durchdachte Aufteilung und Beschreibung der Inhalte, ein Abruf mit sauberer Berechtigungsprüfung, nachvollziehbare Quellen und eigene Tests für die Suche. Ein Anbieter sollte erklären können, wie er die Qualität des Abrufs unabhängig von der formulierten Antwort misst. Bleibt das vage, fehlt wahrscheinlich Erfahrung aus dem produktiven Betrieb. Zusätzliche Abrufe, Embeddings und mehr Tokens im Prompt erhöhen sowohl die Antwortzeit als auch die Kosten pro Anfrage.
Bei Agenten liegt die Messlatte noch höher. Sobald ein Modell Schnittstellen aufruft, Datenbanken verändert, Nachrichten verschickt, Tickets eröffnet oder Cloud-Ressourcen anpasst, formuliert es nicht mehr bloss Text, sondern handelt. OWASP hat 2026 deshalb eine eigene Top 10 für agentische Anwendungen veröffentlicht. Sie nennt Risiken, die über klassische LLM-Anwendungen hinausgehen: manipulierte Ziele, missbrauchte Werkzeuge und Identitäten, kompromittierte Lieferketten oder unerwartet ausgeführten Code. Prompt Injection bleibt ebenfalls ein Thema. Die schädliche Anweisung kann dabei in einem Dokument versteckt sein, das der Agent verarbeitet, statt direkt von einem Nutzer zu kommen.
Ein Agentenprojekt braucht daher klar begrenzte Rechte für jedes Werkzeug, eigene Identitäten nach dem Prinzip der geringsten Rechte, Freigaben vor folgenreichen Aktionen, Transaktionslimits, nachvollziehbare Protokolle und gezielte Angriffstests. Ebenso wichtig ist eine Möglichkeit, Aktionen zu stoppen oder rückgängig zu machen. Schlägt ein Anbieter schon früh weitreichende Rechte für den Agenten vor, ist das kein Zeichen von Pragmatismus, sondern ein Warnsignal.
Wann Sie keine Beratung brauchen
Nicht jedes KI-Vorhaben braucht externe Unterstützung. Ein internes Team kommt meist gut allein zurecht, wenn das Risiko überschaubar ist, eine fertige Lösung den Bedarf abdeckt und keine anspruchsvolle Integration nötig wird. Die Daten sollten sauber zugänglich sein, das Engineering-Team sollte den Betrieb beherrschen, die Sicherheit den gewählten Dienst bereits beurteilt haben und der Fachbereich selbst sagen können, woran er Erfolg misst.
Externe Hilfe wird interessant, wenn mehrere Bereiche gemeinsam offene Fragen lösen müssen. Typische Beispiele sind mehrere Quellsysteme, sensible eigene Daten, ungeklärte Architektur, Inhalte mit Kundenkontakt, regulierte Entscheide, komplexe Berechtigungen, Agenten mit Schreibrechten oder der Schritt vom Prototyp zum verlässlichen Betrieb.
Für eine erste Einschätzung helfen sieben Fragen:
- Können Sie ein messbares Ziel benennen, statt nur „KI einsetzen“ zu wollen? Wenn nicht, beginnt die Arbeit beim Prozess, nicht bei der Entwicklung.
- Verstehen Sie den heutigen Ablauf und seine Schwachstellen? Wenn nicht, sollte er vor jeder Automatisierung analysiert werden.
- Haben Sie Zugang zu repräsentativen, rechtmässig nutzbaren und ausreichend verlässlichen Daten? Wenn nicht, ist die Datenbasis das erste Projekt.
- Gibt es im Team Engineers, die das System integrieren und betreiben können? Wenn nicht, brauchen Sie praktische Umsetzung statt einer reinen Beratung.
- Können Sie selbst Testfälle und Abnahmekriterien festlegen? Wenn nicht, sollte der Partner diese Kompetenz gemeinsam mit Ihrem Team aufbauen.
- Kann Ihr Sicherheitsteam die Risiken von RAG, Prompt Injection und Agenten beurteilen? Wenn nicht, braucht es dafür zusätzliche Expertise.
- Wer übernimmt das System nach dem Launch? Ist das ungeklärt, sollte der Vertrag den Betrieb oder einen echten Wissenstransfer einschliessen.
Manchmal ist KI schlicht die falsche Antwort. Lässt sich das gewünschte Ergebnis exakt beschreiben, sind klassische Software, Suche, Workflow-Automatisierung oder ein paar klare Regeln oft günstiger und zuverlässiger. Ein Modell bringt dann vor allem zusätzliche Unsicherheit. Fehlt ein messbares Ziel oder die nötige Datengrundlage, sollte das Vorhaben warten. Dasselbe gilt, wenn Fehler nicht tragbar wären, keine sinnvolle Kontrolle möglich ist oder sich der Ablauf ständig grundlegend verändert.
Automatisieren
Klar begrenzte Arbeit in grosser Zahl, bei der ein Fehler schnell auffällt und günstig zu korrigieren ist.
- Ausgangswerte sind gemessen
- Repräsentative Testfälle lassen sich zusammenstellen
- Fehler zeigen sich früh und sind umkehrbar
Unterstützen
Arbeit mit viel Ermessen, bei der ein Mensch für das Ergebnis verantwortlich bleibt.
- Die KI entwirft, eine benannte Person entscheidet
- Das Prüfen kostet weniger als die Arbeit ohne KI
- Folgenreiche Schritte behalten eine Freigabe
Nicht mit KI lösen
Aufgaben mit exakt vorhersehbarem Ergebnis oder mit Fehlern, die sich nicht mehr korrigieren lassen.
- Deterministische Software liefert die Antwort schon
- Eine sinnvolle Prüfung lässt sich nicht einbauen
- Der Ablauf ist zu unstet, um ihn zu verantworten
Welcher Anbieter zu welchem Engpass passt
Bei der Suche nach einem Partner hilft eine Rangliste wenig. Entscheidend ist, ob dessen Erfahrung zum konkreten Engpass passt. Ein Schweizer Industrieunternehmen, das SAP und technische Dokumentation mit einem Assistenten erschliessen möchte, braucht andere Fähigkeiten als eine regulierte Bank, ein Onlinehändler oder ein Infrastrukturteam, das mit Agenten arbeitet.
| Anbietertyp | Passt bei | Worauf Sie achten |
|---|---|---|
| Strategieberatung | Priorisierung des Portfolios, Betriebsmodell, Rückhalt in der Geschäftsleitung | Wer setzt die Strategie danach um, und wurde die technische Machbarkeit geprüft? |
| Softwarehaus | Integration von KI-Funktionen in ERP, CRM, SaaS und interne Plattformen | Bringt das Team auch Erfahrung mit Daten und Evaluation mit? |
| Spezialisierte KI-Beratung | Anspruchsvoller Abruf, ML, Modellvergleich, Fine-Tuning, Agenten, KI-Sicherheit | Kann sie die Anwendung rundherum bauen und danach betreiben? |
| Systemintegrator | Breite Vorhaben über etablierte Plattformen und Altsysteme hinweg | Wer arbeitet konkret am Projekt, und wie viele Abstimmungsebenen gibt es? |
| Freelancer | Enge Fragestellung, Architekturreview, Evaluation, kurzfristige Kapazität | Was passiert, wenn diese Person ausfällt? Wer verantwortet Sicherheit und Betrieb? |
| Grosse internationale Beratung | Länderübergreifende Vorhaben mit regulatorischem Gewicht und Change Management | Wer arbeitet konkret am Projekt, und welche Aufgaben gehen an Dritte oder weniger erfahrene Teammitglieder? |
Ein guter Umsetzungspartner kann die Verbindung vom Fachprozess über Daten und Architektur bis zu Quellcode, Integration, Evaluation, Infrastruktur und Betrieb zeigen. Endet die Verantwortung nach Strategie und Architektur, handelt es sich um Beratung, unabhängig davon, wie überzeugend die Präsentation aussieht.
Was es kostet und warum die Spanne so gross ist
Einen belastbaren Durchschnittspreis für KI-Beratung gibt es nicht, weil unter diesem Begriff völlig unterschiedliche Leistungen angeboten werden. Das kann eine zweiwöchige Discovery sein, zusätzliche Engineering-Kapazität, ein komplettes RAG-System, Data Engineering, Sicherheitsarbeit oder ein internationales Transformationsprogramm.
Einen groben Eindruck vermitteln öffentlich zugängliche Beschaffungsunterlagen. Im britischen Rahmenvertrag G-Cloud nennt ein Data-Science-Dienst mit KI und ML Tagessätze von 240 bis 940 GBP. Eine andere Preisliste reicht von 500 GBP für eine Datenschutzanalystin über 850 GBP für einen AI Data Engineer und 1.100 GBP für einen Lead AI Architect bis zu 1.400 GBP für einen Principal AI Architect, jeweils ohne Mehrwertsteuer und Spesen. Ein weiteres Angebot für generative KI nennt 300 bis 1.400 GBP pro Tag. Das sind Listenpreise aus Grossbritannien, keine unabhängigen Durchschnittswerte und erst recht keine verlässlichen Schweizer Marktpreise.
Trotzdem lässt sich daraus etwas ableiten: Teamzusammensetzung und Umfang beeinflussen die Gesamtkosten meist stärker als ein einzelner Tagessatz. Ein erfahrener Architekt, der die wichtigen Fragen in zwei Wochen klärt, kann günstiger sein als ein preiswerteres Team, das drei Monate in die falsche Richtung baut. Für Routinearbeit wiederum wäre dieselbe Seniorität unnötig teuer.
In der Praxis begegnen uns vier Vertragsformen. Abrechnung nach Aufwand passt zu offener Discovery und iterativer Entwicklung, ein Festpreis zu klar abgegrenzten Ergebnissen. Ein Betriebsvertrag deckt Überwachung, Optimierung und Support ab. Besonders sinnvoll sind bei KI oft bezahlte Meilensteine: Nach der Discovery wird entschieden, ob sich ein MVP lohnt. Nach dem getesteten MVP folgt der Entscheid über die Produktionsreife und erst danach über einen laufenden Service. So lässt sich ein Vorhaben ohne Gesichtsverlust stoppen, wenn die Fakten nicht für die nächste Investition sprechen.
Ein Vertrag sollte nie voraussetzen, dass jeder Prototyp automatisch in Produktion geht.
Auch bei der Frage „kaufen oder bauen?“ liegt die Antwort meist dazwischen. Für standardisierte Aufgaben, die ein fertiges Produkt bereits gut abdeckt, lohnt sich Eigenentwicklung selten. Individuell wird es dort, wo eigene Abläufe, Daten, Benutzerführung oder Kontrollen den Unterschied machen. Viele Unternehmen kaufen deshalb das Modell oder die Plattform ein und entwickeln die Schichten für Prozess, Integration und Governance selbst. Ein eigenes Foundation Model ist dagegen nur selten sinnvoll. Laut Google braucht es dafür grosse Datenmengen, spezialisierte Hardware und viel Erfahrung.
Wie lange die Arbeit dauert
Auch bei der Dauer gibt es keinen sinnvollen Branchendurchschnitt. Veröffentlichte Zeitpläne einzelner Anbieter geben immerhin eine Grössenordnung, solange man sie als Angebot und nicht als Norm liest. IBM nennt für seinen G-Cloud-Dienst einen Tag für den Strategieauftakt, zwei bis vier Wochen für Discovery-Workshops und danach etwa drei bis vier Wochen bis zum gemeinsam entwickelten MVP. Ein anderer Anbieter rechnet mit ein bis zwei Wochen Vorbereitung, vier bis sechs Wochen iterativer Discovery und weiteren vier bis sechs Wochen vom Prototyp in Richtung Betrieb.
Unsere Erfahrungswerte sind bewusst breiter. Für Discovery und Reifegradprüfung rechnen wir meist mit zwei bis sechs Wochen. Sind Datenverantwortung oder regulatorische Einordnung ungeklärt, dauert es länger. Ein fokussiertes MVP braucht häufig drei bis acht Wochen, je nachdem, wie viel Datenaufbereitung und Integration nötig ist. Für den Schritt in einen belastbaren Betrieb kommen nochmals vier bis zwölf Wochen oder mehr hinzu. Dann geht es um IAM, Sicherheitstests, bestehende Systeme, Ausfallsicherheit und Governance. Mit dem Launch ist die Arbeit nicht vorbei: Modelle, Anbieter, Daten und die Nutzung im Alltag verändern sich weiter.
Die öffentlich beschriebenen Mandate und Googles Anforderungen an den Betrieb passen zu diesen Erfahrungswerten. Bei regulierten Anwendungen, eigenem ML, autonomen Agenten oder selbst betriebener Infrastruktur muss mit deutlich mehr Zeit gerechnet werden.
- 012 bis 6 Wochen
Discovery und Reifegradprüfung
- Priorisierte Anwendungsfälle mit Ausgangswerten
- Ablauf, Daten und Berechtigungen aufgezeichnet
- Regulatorische Einordnung geklärt
- Liste dessen, was nicht gebaut wird
- 023 bis 8 Wochen
Ein fokussiertes MVP
- Kleinster Ablauf, der von Anfang bis Ende trägt
- Testsatz und Abnahmeschwellen
- Dokumentierte Grenzen
- Entscheid über das Weitermachen anhand von Belegen
- 034 bis 12 Wochen und mehr
Härten für den Betrieb
- Anmeldung, Berechtigungen, Umgang mit Geheimnissen
- Observability, Fallbacks und Rollback
- Sicherheitstests und Tests unter Angriff
- CI/CD und Runbooks
- 04Laufend
Betreiben und verbessern
- Qualität, Latenz, Kosten und Fehler im Blick
- Regressionstests, während Modelle sich ändern
- Versionen von Prompts, Modellen und Abruf
- Wissenstransfer an Ihr Team
Cloud, privat oder selbst gehostet
Bei der Betriebsform gibt es keine pauschal richtige Antwort. Sie hängt davon ab, welche Kontrolle nötig ist und welchen Aufwand das eigene Team übernehmen kann.
| Ansatz | Was Sie gewinnen | Was Sie übernehmen |
|---|---|---|
| Verwaltete Cloud oder API | Schnell starke Modelle, kaum eigene Serving-Infrastruktur, früher Zugang zu Neuem | Abhängigkeit vom Anbieter, Prüfung von Vertrag und Auftragsbearbeitung, schwankende Nutzungskosten, Änderungen an Modell und Schnittstelle ohne Ihr Zutun |
| Verwaltet privat oder gemischt | Engere Grenzen für Netz und Daten, bei weiterhin verwalteten Bausteinen | Mehr Arbeit an Architektur und Plattform, und die Abhängigkeiten verschwinden nicht |
| Selbst gehostet mit offenen Gewichten | Volle Kontrolle über Laufzeit, Infrastruktur und bestimmte Datenwege | GPU-Kapazität, Skalierung, Patches, Modellpflege, Observability, Sicherheit und Pikett liegen bei Ihnen |
Ein häufiges Missverständnis sollte früh geklärt werden: Selbsthosting ist nicht automatisch compliant. Das Datenschutzrecht in der Schweiz und in der EU fragt, wie Personendaten bearbeitet werden, nicht bloss, wo die Modelldatei liegt. Ein RAG-System mit fehlerhaften Berechtigungen gibt vertrauliche Inhalte aus dem eigenen Rechenzentrum genauso bereitwillig preis wie aus der Cloud.
Die Betriebskosten gehören deshalb auf den Tisch, bevor die Architektur festgelegt wird. Je nach Aufbau zählen dazu Inferenz oder API-Nutzung, Embeddings, Such- und Vektorinfrastruktur, Speicher, Datenimport, GPUs, Hosting, Überwachung, Sicherheitswerkzeuge, Evaluationsläufe, Wartung und Support.
Wie Sie eine Beratung vor der Unterschrift prüfen
Im Auswahlgespräch zählen konkrete Erfahrungen mehr als das richtige Vokabular. Bitten Sie den Anbieter, ein vergleichbares Projekt vom ursprünglichen Problem bis zum laufenden Betrieb zu erklären. Ein ansprechender Prototyp sagt wenig, wenn offenbleibt, wie Identitäten und Berechtigungen umgesetzt wurden, wie die Evaluation aussah, was bei einem Störfall geschieht und wie das System an das Kundenteam übergeben wurde.
| Bereich | Die Frage | Was eine gute Antwort enthält |
|---|---|---|
| Nutzen | Woran erkennen Sie, dass dieser Fall besser ohne KI läuft? | Baseline-Kennzahlen, geprüfte Alternativen, klare Abbruchkriterien |
| Daten | Was brauchen Sie, bevor die Entwicklung beginnt? | Quellenverzeichnis, Analyse von Zugriff und Qualität, Prüfung der Rechtmässigkeit |
| Modellwahl | Wie vergleichen Sie Modelle? | Prüfung an den eigenen Aufgaben statt Ranglisten |
| Abruf | Wie prüfen Sie den Abruf getrennt von der Antwort? | Kennzahlen für den Abruf, repräsentative Fragen, Quellenangaben, Berechtigungen in der Suche |
| Agenten | Was darf der Agent ohne Freigabe tun? | Geringste Rechte, klar begrenzte Schnittstellen, Freigabepunkte, Protokolle |
| Entwicklung | Wer verantwortet die Anbindung an unsere Systeme? | Erfahrung mit Schnittstellen, Tests, CI/CD, Infrastructure as Code, Eigentum am Code |
| Evaluation | Was muss vor dem Betrieb erfüllt sein? | Versionierter Testsatz, Abnahmeschwellen, menschliche Prüfung, Fälle unter Angriff |
| Sicherheit | Wie gehen Sie mit Prompt Injection und Datenabfluss um? | Bedrohungsmodell, Red Teaming, Kontrolle der Ausgaben, Berechtigungen im Abruf |
| Regulierung | Wer ordnet die Pflichten nach DSG, DSGVO und KI-Verordnung ein? | Dokumentierte Datenwege, Rollen als Verantwortlicher und Auftragsbearbeiter, Verfahren für Folgenabschätzungen |
| Betrieb | Was überwachen Sie nach dem Launch? | Qualität, Latenz, Fehler, Nutzung, Kosten und Sicherheitssignale |
| Ausfall | Was passiert, wenn Modell oder Abruf ausfallen? | Zeitlimits, Fallbacks, geordnete Einschränkung, Rollback |
| Eigentum | Was wird uns nach Abschluss übergeben? | Quellcode, Infrastruktur als Code, Prompts, Testsätze, Dokumentation |
Auch die Warnzeichen ähneln sich von Projekt zu Projekt: Genauigkeitsangaben ohne definierte Messgrösse, kein eigener Testsatz, das Versprechen eines RAG-Systems ohne Halluzinationen oder weitreichende Rechte für Agenten. Skepsis ist ebenso angebracht, wenn ein Anbieter Code und Konfiguration nur zögerlich übergeben will, ausschliesslich Demos zeigen kann, zum Support nach dem Launch nichts Konkretes sagt oder schon ein Produkt empfiehlt, bevor die Anforderungen geklärt sind.
Besonders leicht täuscht eine gute Demo über die eigentliche Arbeit hinweg. Mit wenigen ausgewählten Dokumenten wirkt eine Oberfläche schnell überzeugend. Im Alltag kommen jedoch veraltete Inhalte, unterschiedliche Berechtigungen, gleichzeitige Zugriffe, Fehlerfälle, schwankende Quellenqualität und fehlende Integrationen dazu. Microsoft betont selbst, dass Abrufqualität und Zugriffskontrolle technische Daueraufgaben bleiben, lange nachdem die Architektur festgelegt wurde.
Die Schweiz und die EU im Jahr 2026
Für Schweizer Unternehmen ist die rechtliche Ausgangslage klarer, als es die Diskussion über ein künftiges KI-Gesetz vermuten lässt: Das bestehende Datenschutzrecht gilt bereits heute. Das revidierte Datenschutzgesetz ist seit dem 1. September 2023 in Kraft. Laut EDÖB erfasst es auch KI-gestützte Bearbeitungen von Personendaten. Geht es ausschliesslich um Sachangaben ohne Bezug zu bestimmbaren Personen, fällt die Bearbeitung in der Regel nicht darunter.
Ein allgemeines KI-Gesetz gibt es in der Schweiz im August 2026 noch nicht. Der Bundesrat will die Rahmenkonvention des Europarats über KI umsetzen und dabei insbesondere Transparenz, Datenschutz, Nichtdiskriminierung und Aufsicht regeln. Eine Vernehmlassungsvorlage ist bis Ende 2026 angekündigt. Daneben gelten weiterhin die Vorschriften der jeweiligen Branche.
Wer unter die KI-Verordnung der EU fällt, hat einen genaueren Fahrplan. Die Verordnung ist seit dem 2. August 2026 allgemein anwendbar. Die Vorschriften zu verbotenen Praktiken und zur KI-Kompetenz gelten seit Februar 2025, jene zu Governance und zu Modellen mit allgemeinem Verwendungszweck seit August 2025. Nach dem AI Omnibus, der am 27. Juli 2026 in Kraft trat, gilt für Hochrisikofälle nach Anhang III eine Frist bis zum 2. Dezember 2027, für Hochrisiko-KI in regulierten Produkten nach Anhang I bis zum 2. August 2028.
Wo die DSGVO anwendbar ist, kommt eine weitere Ebene hinzu. Artikel 22 begrenzt Entscheide, die allein auf automatisierter Bearbeitung beruhen und rechtliche oder ähnlich erhebliche Folgen haben. Artikel 35 verlangt eine Folgenabschätzung, wenn die Bearbeitung voraussichtlich ein hohes Risiko für die Rechte der betroffenen Personen mit sich bringt. In seiner Stellungnahme 28/2024 befasst sich der Europäische Datenschutzausschuss ausdrücklich mit KI-Modellen. Ob ein mit Personendaten trainiertes Modell als anonym gilt und ob berechtigte Interessen als Rechtsgrundlage ausreichen, muss demnach im Einzelfall beurteilt werden.
Für die Beschaffung bedeutet das: Datenwege und Verwendungszwecke müssen ebenso dokumentiert werden wie Modellanbieter, Auftragsbearbeiter und Unterauftragnehmer, Aufbewahrungsfristen, Übermittlungen ins Ausland, Zugriffsrechte, automatisierte Entscheide und menschliche Eingriffe. Eine gute Beratung liefert diese Dokumentation, statt die Themen nur in einem Workshop anzusprechen. Die rechtliche Beurteilung selbst gehört weiterhin in die Hände von Fachleuten für Recht und Datenschutz.
Was die Studien wirklich zeigen
Bei veröffentlichten Erfolgsgeschichten lohnt sich eine klare Trennung zwischen Unternehmensangaben und unabhängigen Studien.
UBS berichtet etwa von einem System, das im Leistungsmanagement Beurteilungstexte vorbereitet, während die Vorgesetzten für das Urteil verantwortlich bleiben. Nach Angaben der Bank spart das mehr als 32.000 Führungsstunden pro Jahr. Das Beschaffungssystem „Front Door“ soll die Zahl der manuell erfassten Felder um fast 40 % reduziert und Vorhaben um bis zu 60 % beschleunigt haben. Siemens nennt aus ersten Pilotprojekten mit dem Industrial Copilot eine durchschnittlich 25 % kürzere Zeit für reaktive Wartung. Solche Eigenangaben sind keine kontrollierten Studien und taugen nicht als Prognose für das eigene Projekt. Interessant ist aber das gemeinsame Muster: Die KI übernimmt einen klar umrissenen Teil eines Ablaufs, während die Verantwortung bei einem Menschen bleibt.
Die weiter oben erwähnten Arbeiten des National Bureau of Economic Research und von Harvard sind unabhängiger, ihre Ergebnisse gelten aber jeweils für die untersuchten Aufgaben. In dieselbe Richtung weisen beide Arten von Belegen dennoch: klein anfangen, den Ausgangszustand messen, mit repräsentativen Fällen testen und menschliche Kontrolle dort einbauen, wo Fehler ernsthafte Folgen haben. Ausgeweitet wird erst, wenn sich der Nutzen im Alltag bestätigt.
Wo Sie anfangen sollten
Für das erste Gespräch mit einem Anbieter ist die Reihenfolge wichtiger als eine lange Namensliste. Ausgangspunkt ist das fachliche Problem: Wie läuft die Arbeit heute, und was soll sich messbar verbessern? Danach folgen Datenlage und regulatorisches Risiko. Erst dann lohnt sich der Vergleich zwischen einer KI-Lösung und einer klassischen Alternative. Gebaut wird die kleinste Version, die den Ablauf vollständig abbildet. Sie muss vorher vereinbarte Tests bestehen, bevor sie in Betrieb geht. Und auch danach bleibt Überwachung nötig, denn in einem halben Jahr arbeitet das System nicht mehr unter exakt denselben Bedingungen wie am ersten Tag.
Das klingt weniger spektakulär als das Versprechen von Agenten für jeden Prozess. Dafür ist es der Weg, auf dem belastbare Systeme tatsächlich entstehen.
Bei Alpine Edge beginnen wir deshalb nicht mit dem Versprechen einer umfassenden KI-Transformation. Zuerst klären wir gemeinsam, ob ein Anwendungsfall die Investition wert ist. Wenn die Antwort ja lautet, begleiten wir ihn von der Discovery über Architektur und Integration bis zum produktiven Betrieb. Als erster Schritt ist eine klar abgegrenzte Discovery oder technische Beurteilung meist sinnvoller als die sofortige Zusage für ein grosses Programm.
Woher diese Zahlen kommen
- Europäische Kommission, Rechtsrahmen für KI. Anwendungsdaten der KI-Verordnung inklusive der Omnibus-Änderungen 2026.
- Europäische Kommission, Inkrafttreten des AI Omnibus. Bestätigt den 27. Juli 2026.
- Schweizerische Bundeskanzlei, Regulierung von KI. Stand und geplante Vernehmlassung.
- EDÖB, KI und Datenschutz. Zur Anwendbarkeit des DSG.
- EDÖB, KI im Alltag. Zu Personendaten in KI-Bearbeitungen.
- EUR-Lex, DSGVO. Volltext, inklusive Artikel 22 und 35.
- Europäischer Datenschutzausschuss, Stellungnahme 28/2024. KI-Modelle und DSGVO-Grundsätze.
- NIST, AI Risk Management Framework.
- NIST, AI RMF Playbook. Govern, Map, Measure und Manage.
- Microsoft, Retrieval-Augmented Generation und Indizes. Azure AI Foundry: Aufbau, Sicherheit, Grenzen und Kosten.
- Google Cloud, generative KI-Anwendungen bereitstellen und betreiben. Evaluation, CI/CD, Überwachung und Lebenszyklus.
- OWASP, Top 10 für LLM-Anwendungen 2026.
- OWASP, Top 10 für agentische Anwendungen 2026.
- National Bureau of Economic Research, Generative AI at Work. Felddaten zur Produktivität im Kundendienst.
- Harvard Business School, Navigating the Jagged Technological Frontier. Das Feldexperiment mit 758 Beratenden.
- UBS, Innovation und KI. Angaben des Unternehmens.
- Siemens, Mitteilung zum Industrial Copilot. Angabe des Herstellers zum Pilotprojekt.
- UK Digital Marketplace, IBM-Dienst für generative KI. Veröffentlichte Struktur von Discovery und MVP.
- UK Digital Marketplace, Dienst für generative KI. Veröffentlichter Zeitplan und Preise.
- UK Digital Marketplace, Cloud Data Science AI/ML. Veröffentlichte Preisspanne.
- UK Digital Marketplace, Saracen AI Services. Rollenbasierte Tagessätze.