KI-Pilotprojekt in der Schweiz: Datenfluss, Anbieter und Kontrolle sauber planen

Mit einer Pilotfrage beginnen, nicht mit einem Tool

Die stärkste Pilotfrage beschreibt einen betrieblichen Zustand. Zum Beispiel: Kann ein System eingehende Supportanfragen aus freigegebenen Quellen vorsortieren und einen Antwortentwurf vorbereiten, während das Fachteam jede externe Antwort freigibt? Darin sind Eingang, Tätigkeit, Ausgabe und menschliche Entscheidung bereits erkennbar. «Wir testen generative KI im Kundendienst» lässt diese Grenzen offen.

Zur Frage gehört ein bewusstes Nicht-Ziel. Der Pilot darf etwa keine Zusagen versenden, keine Kundenklassifikation in ein führendes System schreiben und keine neuen Datenquellen selbständig erschliessen. Solche Ausschlüsse sind keine Bremse. Sie halten den Test klein genug, damit Fehler einer Ursache zugeordnet und später gezielt korrigiert werden können.

Vor dem Start sollte ausserdem feststehen, wer die Pilotfrage fachlich besitzt. IT kann Zugriffe und Integration verantworten; die Beurteilung einer fachlich richtigen Ausgabe gehört jedoch zu einer Rolle, die den realen Prozess kennt. Ohne diese Trennung wird technische Funktionsfähigkeit leicht mit betrieblicher Eignung verwechselt.

Sechs Nachweise vor der Umsetzungsfreigabe

Die folgende Matrix ist ein Arbeitsinstrument für das Projektteam. Jede Zeile braucht einen sichtbaren Nachweis. Ein offener Punkt führt nicht automatisch zum Abbruch, aber er darf auch nicht still als erledigt gelten.

Tabelle auf kleinen Bildschirmen horizontal scrollen.

Praktisch bewährt sich ein kurzer Status je Zeile: belegt, offen oder gestoppt. Entscheidend ist nicht eine Gesamtpunktzahl, sondern ob ein einzelner kritischer Daten- oder Kontrollpunkt den Pilot unvertretbar macht. Eine starke technische Lösung kann eine ungeklärte Berechtigung oder fehlende fachliche Freigabe nicht kompensieren.

Den Weg jeder Information vom Eingang bis zur Ausgabe zeichnen

Ein Datenfluss beginnt nicht beim KI-Modell. Er beginnt dort, wo eine Information in den Prozess gelangt: in einem Formular, einer E-Mail, einem Dokument, einem CRM, einem Dossier oder einer internen Wissensquelle. Für jede Quelle werden Datenart, verantwortliche Stelle, Zweck und Zugriffsberechtigung festgehalten. Danach folgt jede technische Übergabe bis zum geplanten Ergebnis.

Die Darstellung muss auch temporäre Schritte enthalten. Kopiert eine Integration Inhalte in einen Zwischenspeicher? Werden Prompts, Ausgaben oder Fehlerprotokolle aufbewahrt? Greift ein Supportteam des Anbieters auf die Umgebung zu? Gelangt das Ergebnis zurück in ein führendes System? Solche Übergaben entscheiden darüber, welche Personen und Anbieter tatsächlich Teil des Datenwegs sind.

Hilfreich ist eine Eingaberegel mit drei Listen:

• Erlaubt: konkret benannte Datenarten und Quellen, die der Pilot benötigt.
• Ausgeschlossen: Inhalte, die weder nötig noch freigegeben sind.
• Eskalation: Eingaben, die ein Mensch beurteilen muss, bevor sie weiterverarbeitet werden.

Damit wird Datenminimierung zu einer Betriebsregel statt zu einer abstrakten Absicht. Das Team kann Testfälle gezielt gegen die Grenzen prüfen und erkennt, ob die technische Umsetzung eine ausgeschlossene Eingabe zuverlässig stoppt.

Produktname und tatsächliche Verarbeitungskette trennen

Bei cloudbasierten KI-Diensten endet die Prüfung nicht beim Vertragspartner. Relevant sind die angebotene Produktvariante, aktivierte Funktionen, mögliche Unterauftragnehmer, Bearbeitungs- und Speicherorte, Zugriffsrollen, Protokollierung, Löschmöglichkeiten und die Frage, ob Eingaben oder Ausgaben für eigene Zwecke des Anbieters verwendet werden können. Allgemeine Marketingseiten reichen dafür selten als Projektakte.

Die Anbieterakte sollte deshalb Quelle und Prüfdatum enthalten. Geeignet sind aktuelle Vertragsunterlagen, Datenverarbeitungszusätze, Unterauftragnehmerlisten, Sicherheitsdokumentation und konkrete Administrationsansichten der gewählten Konfiguration. Widersprechen sich Angaben, bleibt der Punkt offen. Eine mündliche Zusage wird nicht als technische Einstellung dokumentiert.

Auch Änderungen brauchen einen Prozess. Ein neuer Unterauftragnehmer, eine andere Region, eine geänderte Aufbewahrung oder eine neue Standardfunktion kann den geprüften Datenweg verändern. Die Pilotakte benennt deshalb eine Person, die Anbieteränderungen bewertet, und legt fest, wann Tests oder Freigaben wiederholt werden müssen.

Menschliche Kontrolle als echte Eingriffsmöglichkeit bauen

«Ein Mensch prüft» ist erst dann belastbar, wenn Rolle, Zeitpunkt, Informationen und Handlungsmöglichkeiten feststehen. Die prüfende Person muss die Quelle sehen, Unsicherheit erkennen, eine Ausgabe korrigieren oder verwerfen und den Vorgang in einen sicheren manuellen Ablauf übergeben können. Eine Freigabeschaltfläche ohne ausreichenden Kontext ist nur formale Kontrolle.

Für jede mögliche Folge wird eine Kontrollstufe bestimmt. Ein interner Entwurf kann eine andere Prüfung benötigen als eine externe Nachricht, eine Änderung im CRM oder eine Empfehlung mit Auswirkungen auf eine Person. Je schwerer eine falsche Ausgabe korrigierbar ist, desto früher muss der menschliche Eingriff stattfinden.

Zusätzlich braucht es einen erreichbaren Rückfallweg. Wenn der Dienst nicht verfügbar ist, eine Eingabe ausserhalb der Regeln liegt oder die prüfende Rolle fehlt, darf der Prozess nicht unbemerkt weiterlaufen. Der Pilot beschreibt, wie der Vorgang markiert, geparkt und manuell übernommen wird. Erst dieser Fehlerweg macht aus einer Demo einen betriebsfähigen Test.

DSG-Fragen am konkreten Datenweg prüfen

Für Schweizer Unternehmen bildet das Datenschutzgesetz den nationalen Ausgangspunkt; je nach Angebot, betroffenen Personen und Marktbezug können weitere Vorgaben hinzukommen. Der EDÖB betont bei Datenbearbeitungen Transparenz und eine verständliche Information darüber, welche Personendaten zu welchem Zweck bearbeitet und an wen sie bekanntgegeben werden. Für ein KI-Pilotprojekt bedeutet das: Die Beschreibung muss zur tatsächlichen Konfiguration passen.

Ob eine Bearbeitung zulässig ist, welche Information erforderlich wird oder wie eine Bekanntgabe ins Ausland abzusichern ist, lässt sich nicht aus dem Begriff «KI-Pilot» ableiten. Diese Fragen benötigen die Prüfung des konkreten Zwecks, der Datenarten, Empfänger, Länder und Schutzmassnahmen. Die technische Pilotakte liefert dafür eine belastbare Sachverhaltsgrundlage, ersetzt aber keine rechtliche Einzelfallprüfung.

Amtliche Ausgangsquellen zu DSG, DSV, Informationspflicht, Auslandbekanntgabe und KI sind auf der Seite Schweizer Quellen zu KI und Datenschutz gebündelt. Anbieterunterlagen und interne Prozessangaben müssen daneben separat aktuell gehalten werden.

Mit repräsentativen Fällen testen und ohne Automatismus entscheiden

Der Testbestand sollte nicht aus beliebigen Beispielen entstehen. Er deckt typische Fälle, unvollständige Eingaben, widersprüchliche Angaben, ausgeschlossene Daten, fachliche Ausnahmen und technische Fehlerwege ab. Für jeden Fall ist vorab definiert, was eine akzeptable Ausgabe ist, wann ein Mensch eingreifen muss und welches Ergebnis als Fehler zählt.

Gemessen werden nur Grössen, die zur Pilotfrage passen: etwa Vollständigkeit, Art der Fehlzuordnung, notwendige Korrekturen, Anteil der korrekt eskalierten Ausnahmen, Bearbeitungsweg und Stabilität der Übergaben. Zielwerte werden vom Unternehmen vor dem Test festgelegt; sie dürfen nicht nachträglich so verschoben werden, dass der Pilot erfolgreich wirkt.

Die Abschlussentscheidung kennt mindestens drei Wege. Stop bedeutet, dass Nutzen, Datenlage oder Kontrolle den Betrieb nicht tragen. Ändern bedeutet, dass ein begrenzter weiterer Test mit klar benannten Korrekturen sinnvoll ist. Scale bedeutet nicht sofortige Vollautomatisierung, sondern eine neue, versionierte Freigabe für einen definierten grösseren Umfang.

Damit bleibt die Entscheidung auch später nachvollziehbar. Neue Modelle, Anbieteränderungen oder zusätzliche Datenquellen werden nicht still in den bestehenden Pilot aufgenommen, sondern lösen eine neue Prüfung aus.