KI-Marketing-Tools systematisch auswählen

Eine belastbare Auswahl beginnt nicht bei Anbieternamen, sondern bei einem Testauftrag. Klären Sie zuerst, welche Aufgabe erfüllt sein muss, welche Daten zulässig sind, welche Rechte geklärt sein müssen und welche Anforderungen zwingend gelten. Erst wenn Muss-Kriterien und Abnahmeregeln feststehen, lohnt sich eine Shortlist.

Aus dem Anwendungsfall eine prüfbare Aufgabe machen

«Wir brauchen ein KI-Werkzeug fürs Marketing» ist keine prüfbare Anforderung. Formulieren Sie die Aufgabe als beobachtbare Arbeit: «Aus einem freigegebenen Produktdossier drei Textentwürfe im vorgegebenen Format erstellen und jede Tatsachenbehauptung auf eine Quelle zurückführen.» Oder: «Eine Kampagnentabelle auf definierte Anomalien prüfen und die Fundstellen markieren, ohne Änderungen im Werbekonto vorzunehmen.»

Die Aufgabe nennt Eingaben, erlaubte Quellen, Ausgabeformat, Qualitätskriterien, ausgeschlossene Aktionen und die zuständige Prüfrolle. Sie trennt Muss von Wunsch. Eine Integration ins CRM kann später wichtig sein, ist für einen ersten Offline-Test aber vielleicht kein Muss. Dagegen können fehlende Datenlöschung, unklare Nutzungsrechte oder nicht begrenzbare Schreibrechte bereits ein Ausschlussgrund sein.

Toolkategorien statt Produktnamen vergleichen

Ein allgemeiner Assistent kann viele Formate bearbeiten, braucht aber klare Vorlagen und Kontrollen. Ein spezialisiertes Fachwerkzeug bildet eine engere Aufgabe ab, etwa Bildvarianten, Transkription oder Analyse. Eine eingebettete KI-Funktion sitzt bereits in einem Marketing- oder Werbesystem und übernimmt dessen Identitäten und Berechtigungen teilweise. Eine Orchestrierungsplattform verbindet mehrere Schritte und Systeme. Ein selbst betriebener Baustein bietet mehr technische Kontrolle, verlangt aber eigenes Modell-, Sicherheits- und Betriebswissen.

Diese Kategorien sind nicht automatisch besser oder schlechter. Sie verschieben Verantwortung. Ein eingebettetes Werkzeug kann schneller zugänglich sein, aber an den Daten- und Berechtigungsrahmen der Plattform gebunden bleiben. Eine offene API kann flexibel wirken, doch Integration, Monitoring und Fehlerbehandlung liegen dann beim eigenen Team. Schreiben Sie diese Verantwortungsverschiebung in die Entscheidungsvorlage.

Zuerst die zwingenden Anforderungen prüfen

Ein Punktescore darf keinen grundlegenden Mangel überdecken. Definieren Sie zuerst die zwingenden Anforderungen. Kann der Anbieter den vorgesehenen Datenzweck und die beteiligten Auftragsbearbeiter erklären? Sind Aufbewahrung, Löschung und Export prüfbar? Lässt sich die Nutzung von Eingaben für Training oder Produktverbesserung passend konfigurieren oder vertraglich klären? Können Rollen und Rechte auf die Aufgabe begrenzt werden? Gibt es einen nachvollziehbaren Weg für Störungen und Dienständerungen?

Für Inhalte und Visuals kommen Rechtefragen hinzu. Welche Zusagen macht der Anbieter zu Eingaben, Ausgaben und Freistellungen? Welche Pflichten verbleiben beim Nutzer? Das Eidgenössische Institut für Geistiges Eigentum (IGE) weist darauf hin, dass bei KI-Einsatz verschiedene technische Vorgänge und mögliche Rechte an Input und Output getrennt zu beurteilen sind. Eine Marketingfreigabe ersetzt keine Rechteprüfung.

Scheitert ein Werkzeug an einer für die Aufgabe zwingenden Anforderung, wird es nicht durch gute Bedienbarkeit aufgewertet. Das Ergebnis lautet «nicht geeignet für diese Aufgabe»; für eine andere, weniger sensible Aufgabe kann die Beurteilung anders ausfallen.

Qualität mit einem festen Testset prüfen

Live-Demos geben einen ersten Eindruck, sind aber schlecht vergleichbar. Erstellen Sie ein kleines, repräsentatives Testset mit synthetischen oder freigegebenen Daten. Es enthält einfache Fälle, Grenzfälle, fehlende Angaben, widersprüchliche Quellen und einen bewusst unzulässigen Auftrag. Alle Kandidaten erhalten gleichwertige Eingaben, Daten- und Qualitätsvorgaben; identische Prompts sind bei unterschiedlichen Werkzeugen nicht sinnvoll. Halten Sie die dokumentierte Konfiguration und die tatsächlich einsehbare Version fest. Nicht einsehbare Angaben werden als solche vermerkt und sind kein automatischer Ausschlussgrund.

Bewerten Sie nicht nur «gefällt mir». Für Text können Kriterien Faktentreue, Quellenbezug, Vollständigkeit, Ton, Format und Korrekturaufwand lauten. Für Analysen zählen die sachliche Richtigkeit der Befunde, ihre Reproduzierbarkeit, der Umgang mit fehlenden Werten und eine nachvollziehbare Darstellung der Unsicherheit. Für Visuals kommen Markenkonformität, Artefakte, Rechtehinweise und technische Formate hinzu. Eine fachlich zuständige Person bewertet blind, soweit das praktikabel ist.

Ein Durchschnittswert allein reicht nicht. Zeigen Sie Fehlertypen und Streuung. Ein Werkzeug, das neun harmlose Fälle gut löst, beim kritischen zehnten aber eine unbelegte Aussage veröffentlicht, braucht eine strengere menschliche Prüfung. Notieren Sie auch, wann das System korrekt ablehnt oder Unsicherheit sichtbar macht. Eine sichere Eskalation kann wertvoller sein als eine selbstsichere Antwort.

Datenschutz und Sicherheit am realen Datenfluss prüfen

Der Eidgenössische Datenschutz- und Öffentlichkeitsbeauftragte (EDÖB) hält fest, dass das Schweizer DSG direkt auf KI-gestützte Personendatenbearbeitung anwendbar ist. Die Prüfung richtet sich deshalb nicht nach dem Etikett «KI», sondern nach Zweck, Daten, Empfängern, Transparenz und Risiko der konkreten Bearbeitung. Erstellen Sie für jeden Testkandidaten eine Datenflusskarte: Welche Felder verlassen welches System? In welcher Region werden sie verarbeitet? Wie werden Anträge auf Auskunft, Berichtigung oder Löschung an die beteiligten Auftragsbearbeiter übermittelt und dort tatsächlich umgesetzt?

Vermeiden Sie reale Personendaten im ersten Pilot. Zugangsdaten, Tokens und interne Geheimnisse gehören nicht in Prompts. OWASP betont, dass ein Systemprompt nicht als Geheimnis oder Autorisierungskontrolle behandelt werden darf. Prüfen Sie echte Rollen, kurzlebige Credentials, Protokollierung und die Trennung von Lese- und Schreibrechten. Prüfen Sie für jede Integration, ob die hier empfohlenen Kontrollen tatsächlich umgesetzt sind.

Auch ein «nur lesender» Connector kann umfangreiche Daten offenlegen. Lassen sich Objekte, Felder, Konten und Zeiträume begrenzen? Kann eine menschliche Freigabe technisch vor einer externen Wirkung erzwungen werden? Was geschieht bei Prompt Injection aus einem Dokument oder einer Webseite? Diese Fragen gehören in eine Sicherheitsprüfung und gegebenenfalls in einen technischen Test; ein Fragebogen allein beweist keine Sicherheit. Autorisierungen gehören in deterministische Regeln ausserhalb des Modells, nicht in den Prompt.

Integration und Betrieb sind eigene Kostenblöcke

Der Lizenzpreis zeigt nicht die gesamten Betriebskosten. Hinzu kommen Konfiguration, Schnittstellen, Identitätsmanagement, Tests, fachliche Prüfungen, Monitoring, Schulung, Störungsbehandlung und Ausstieg. Dieser Artikel nennt bewusst keine Marktpreise. Stattdessen soll jedes Angebot denselben Umfang ausweisen, damit Unterschiede sichtbar werden. Bilden Sie zwei getrennte Kennzahlen für denselben Zeitraum und dieselbe Testpopulation: die Gesamtkosten pro akzeptiertem Ergebnis in CHF und die menschliche Prüfzeit pro akzeptiertem Ergebnis in Minuten. Wird die Prüfzeit monetarisiert, nennen Sie den verwendeten Stundensatz und rechnen Sie sie genau einmal in die Gesamtkosten ein; addieren Sie keine Stunden zu CHF und zählen Sie die Prüfzeit nicht doppelt. Ohne akzeptierte Ergebnisse ist keine der beiden Kennzahlen berechenbar. Eine unbekannte Eingabe bleibt unbekannt und wird nicht als null summiert; fehlende Angaben blockieren nur die davon abhängige Kennzahl.

Prüfen Sie API-Dokumentation nicht nur auf Vorhandensein. Sind benötigte Endpunkte, Limits, Webhooks, Versionen und Fehlermeldungen dokumentiert? Gibt es eine Sandbox? Können Daten und Konfigurationen exportiert werden? Wer informiert über Modell- oder Produktänderungen? Ein Werkzeug kann einzelne Ergebnisse überzeugend liefern und trotzdem unpassend sein, wenn sein Betrieb nicht in die Organisation passt.

Bestimmen Sie ausserdem eine verantwortliche Person für den Betrieb. Sie verantwortet nicht das Modell im abstrakten Sinn, sondern den konkreten Einsatz: Benutzer, Vorlagen, Quellen, Prüfquote, Störungen und Abschaltentscheidung. Fachbereich, IT, Security, Datenschutz und Einkauf haben unterschiedliche Prüfrollen. Eine RACI-Matrix macht sichtbar, wer entscheidet, wer mitwirkt und wer nur informiert wird.

Ausstieg vor dem Vertragsabschluss testen

Ein glaubwürdiger Ausstieg beantwortet: Können eigene Daten, Vorlagen, Evaluationsfälle, Logs und Konfigurationen exportiert werden? In welchem Format? Wie werden gespeicherte Daten gelöscht und wie wird dies dokumentiert? Welche Workflows fallen aus, wenn das Werkzeug endet? Gibt es einen manuellen Fallback? Welche Modell- oder API-Abhängigkeiten müssen ersetzt werden? Ein solcher Test gehört in einen vereinbarten, isolierten Pilot; er ist keine Aufforderung, ein laufendes System abzuschalten. Neue Zwecke, Daten oder Aktionen brauchen eine eigene Prüfung des betroffenen Ausschnitts.

Die aktuelle offizielle UK-Leitlinie für Entwicklung, Lieferung und Beschaffung von GenAI-Werkzeugen behandelt die Einführung als organisatorische Aufgabe mit Training, Support, Risikomanagement und Monitoring. Testen Sie für den hier beschriebenen Piloten zusätzlich das Ausstiegsverfahren, bevor Sie den Vertrag unterschreiben. Führen Sie im Pilot mindestens einen Export und eine Deaktivierung durch. Ein nur auf dem Papier zugesagter Export ist noch kein getesteter Rückweg.

Nicht nur das Tool, sondern die Arbeitsfähigkeit bewerten

Ein Pilot kann technisch überzeugen und organisatorisch trotzdem scheitern. Prüfen Sie, ob die zuständigen Personen Ergebnisse verstehen, Fehler erkennen und den Prozess ohne Anbieter-Demo bedienen können. Ein Testtag unter Idealbedingungen sagt wenig über Vertretung, Ferien, Prioritätskonflikte oder eine Störung aus. Simulieren Sie deshalb eine Rückfrage, eine falsche Ausgabe, einen gesperrten Benutzer und eine kurzfristige Abschaltung.

Dokumentation wird anhand einer konkreten Aufgabe geprüft: Kann eine neue Fachperson den freigegebenen Anwendungsfall, die Datenquellen, Reviewkriterien und die Stopprozedur nachvollziehen? Kann die IT Rechte entziehen, ohne andere Systeme zu blockieren? Kann der Einkauf eine wesentliche Produktänderung erkennen und eine vertragliche Neubewertung auslösen? Ein guter Help-Center-Artikel ersetzt keine organisationseigene Betriebsanweisung.

Beziehen Sie zudem die Lernkurve in die Entscheidung ein. Erfassen Sie Schulungsbedarf, wiederkehrende Supportfragen und Korrekturarten, ohne daraus einen erfundenen Produktivitätswert zu machen. Wenn nur eine Person das Werkzeug sicher beherrscht, besteht ein Betriebsrisiko. Wenn das Team jede Ausgabe vollständig neu erstellen muss, passen Aufgabe und Werkzeug womöglich nicht zusammen. Diese Befunde können zu einem engeren, klar abgegrenzten Umfang führen, statt zu einem vorschnellen Rollout.

Vor einer Ausweitung wird das feste Testset erneut ausgeführt. Modell-, Policy- oder Schnittstellenänderungen erhalten eine neue Bewertungsrunde. Die ursprüngliche Beschaffungsnote ist kein dauerhaftes Gütesiegel.

Entscheiden: ablehnen, begrenzt pilotieren oder vertiefen

Am Ende gibt es nicht nur «kaufen» oder «nicht kaufen». Ein Kandidat kann an einer zwingenden Anforderung scheitern. Er kann einen begrenzten Offline-Pilot bestehen, aber noch Security- oder Vertragsklärungen benötigen. Oder er kann für genau eine Aufgabe freigegeben werden, während Integrationen und Live-Aktionen blockiert bleiben. Halten Sie den Geltungsbereich ausdrücklich fest.

Wie maitiq hilft: Dasselbe Arbeitspaket mit allen Kandidaten testen

Nutzen Sie für die Auswahl ein freigegebenes Briefing, dieselben Quelldaten und dieselbe erwartete Ausgabe. Erfassen Sie fachliche Fehler, manuelle Nacharbeit, Exportierbarkeit sowie die zwei Kennzahlen aus dem Abschnitt zu Integration und Betrieb: Gesamtkosten pro akzeptiertem Ergebnis und Prüfminuten pro akzeptiertem Ergebnis. Alle Mengen beziehen sich auf denselben Zeitraum und dieselbe Testpopulation. Ein günstiges Abonnement ist teuer, wenn das Team jedes Ergebnis neu aufbauen muss.

maitiq begleitet die Auswahl im Rahmen eines vereinbarten Piloten. Welche Aufgabe soll besser oder automatisiert erledigt werden, welche Verantwortung bleibt beim Team, und wie fügt sich die Lösung in Ihre Systeme? So wird aus einem Toolvergleich eine umsetzbare Entscheidung. Erst ein bestandener Praxistest rechtfertigt eine breitere Einführung.

Wie ein erster Pilot mit maitiq beginnt

In einer vereinbarten Vorabklärung klärt maitiq, welche Kategorie zur Aufgabe passt, welche zwingenden Anforderungen offen sind und wie ein begrenzter Pilot aufgesetzt wird. Sie erhalten eine klar abgegrenzte Aufgabe, die offenen Daten- und Kontrollfragen, einen Pilotplan und die Kriterien für die Entscheidung, ob das Werkzeug für den Betrieb bereit ist.

Entscheidungsregel: Definieren Sie zuerst die Aufgabe und die Ausschlussgründe; vergleichen Sie danach Qualität, Integration, Betriebskosten und Prüfzeit pro akzeptiertem Ergebnis sowie den geprüften Ausstieg.

Quellen und Einordnung

Die vier Quellen decken verschiedene Prüffelder ab: Der EDÖB erklärt, wie das Schweizer DSG bei KI-gestützter Personendatenbearbeitung greift. Das IGE ordnet Urheberrechtsfragen beim Training und beim Einsatz von KI ein. Die UK-Leitlinie beschreibt die Einführung von GenAI-Werkzeugen als organisatorische Aufgabe. OWASP benennt mit System Prompt Leakage ein Sicherheitsrisiko, aus dem die Prüfung von Rollen und Geheimnissen folgt. Lesen Sie diese Quellen als Grundlage der genannten Prüfschritte, nicht als Zusage für ein einzelnes Werkzeug oder Ergebnis.

Lassen Sie Ihren konkreten Fall von maitiq prüfen.