Einführung

Eine Ausschreibung für eine Avatar‑KI‑Lösung auf interaktiven Kiosken erfordert die Übersetzung fachlicher Erwartungen in klare technische, operative und vertragliche Anforderungen. Dieses Dokument bietet ein einsatzfähiges Gerüst, um die RFP zu strukturieren, verwertbare Auswahlkriterien für ein Auswahlgremium zu definieren und ein POC‑Protokoll zu erstellen, mit dem Kandidaten in realistischen Szenarien bewertet werden können.

Der Leitfaden deckt Pflichtabschnitte des Pflichtenhefts ab, Sicherheits‑ und Governance‑Fragestellungen der Wissensbasis, Vertragsklauseln zur Verhandlung (SLA, Support, Datenhoheit) sowie ein operatives POC‑Protokoll. Er richtet sich an IT‑Leitung, Customer‑Experience‑Verantwortliche, IT‑Einkauf und Projektleiter, die Pilot und Lieferantenauswahl betreuen.

Empfohlene Struktur des Pflichtenhefts

Um Angebote vergleichbar zu machen, sollte die RFP eine einheitliche Struktur haben. Fordern Sie die Anbieter auf, jeden Abschnitt auszufüllen und nachweisbare Belege, funktionale Demos und technische Referenzen beizufügen.

Stellen Sie ein standardisiertes Antwortformat mit technischen Anlagen und einer vorgegebenen Scoring‑Matrix bereit, die den Bietern mitgeliefert wird, um eine objektive Bewertung sicherzustellen.

  • Projektzusammenfassung und Umfang der Pilotstandorte

  • Detaillierte funktionale Anforderungen

  • Technische Spezifikationen und Hardware‑Kompatibilität

  • Sicherheit, Datenschutz und Governance der Wissensbasis

  • Betrieb, Wartung und operativer Support

  • POC‑Protokoll und funktionale/technische Abnahmekriterien

Zu formulierende funktionale Anforderungen

Listen Sie die erwarteten Einsatzfälle des Avatars auf Kiosk oder Bildschirm präzise auf: Begrüßung, Produktinformation, Orientierung, fachliche FAQs, Übergabe an einen menschlichen Service. Für jeden Fall definieren Sie die erwartete Benutzereingabe (Sprache, Touch), Ausgabekanäle (TTS, Textanzeige) und das erforderliche Autonomielevel.

Dokumentieren Sie sprachliche Anforderungen und Persona‑Erwartungen. Geben Sie z. B. die prioritären Sprachen des Umfangs und die Anforderungen an die Konsistenz der Persona an. Beachten Sie, dass manche Mehrsprachigkeitsfunktionen von der Lösung bereitgestellt werden können: SANIA kann in mehr als 100 Sprachen kommunizieren, die RFP muss jedoch die erwartete Qualität für die Zielsprachen und entsprechende Tests verlangen.

  • Unterstützte Interaktionsmodi: nur Touch, nur Stimme oder hybrid

  • Prioritäre Use‑Cases, die im POC gestartet werden sollen

  • Erwartungen an visuelle und stimmliche Anpassung (Persona)

  • Barrierefreiheitsanforderungen zur Vor‑Ort‑Prüfung

Technische Spezifikationen und Kompatibilität

Beschreiben Sie die Zielinfrastruktur: Arten von Bildschirmen/Kiosken, SoC/OS (z. B. Samsung Tizen, Android, Windows). Weisen Sie darauf hin, dass die effektive Kompatibilität im POC getestet werden muss, da die Verfügbarkeit eines OS vom eingesetzten Gerät an jedem Standort abhängt. Nennen Sie ferner Netz‑, Proxy‑ und Sicherheitsvorgaben.

Fordern Sie klare Angaben zur Softwarearchitektur an: mögliche Hosting‑Modelle (Cloud, Edge, Hybrid), Option zur Nutzung unterschiedlicher LLM‑Motoren je nach Konfiguration und die bereitgestellten Schnittstellen (APIs, Webhooks) für POS‑, CRM‑ oder Inventarintegrationen. Präzisieren Sie, dass jede Drittanbieterintegration eine eigens zu kalkulierende Integrationsphase darstellt.

  • Kompatibilität mit OS‑Familien pro Standort anzugeben und im POC zu testen

  • Vorgeschlagene Hosting‑Optionen und betriebliche Einschränkungen

  • Technische Schnittstellen für Echtzeit‑Integrationen

  • Audioanforderungen: ASR, TTS und Umgang mit lauten Umgebungen

Sicherheit, Datenschutz und Governance der RAG‑Wissensbasis

Die RFP muss Sicherheitsanforderungen für die Dokumentenbasis und API‑Kommunikation detailliert beschreiben. Fordern Sie Zusagen zu Verschlüsselung in Transit und im Ruhezustand, Zugriffsverwaltung, Mandantentrennung und Möglichkeiten externer Audits. Klären Sie die Verantwortlichkeiten bei Erkennung, Löschung oder Anonymisierung sensibler Eingabedaten.

Fügen Sie einen Abschnitt zur Governance der Inhalte hinzu, die die RAG speisen: Dokumenten‑Ingestion‑Flows, Prozesse der menschlichen Validierung, Aktualisierungsrhythmen und Mechanismen zum Entfernen veralteter oder fehlerhafter Informationen. Vermeiden Sie die Vorgabe einer spezifischen technischen Methode; verlangen Sie stattdessen Nachweise zu Prozessen und Tools, die Qualität und Nachvollziehbarkeit der Änderungen sicherstellen.

Betrieb, SLA und zentrale Vertragsklauseln

Formulieren Sie operative Erwartungen, ohne willkürliche Werte vorzugeben: Bitten Sie Anbieter um ihre Zusagen zu Verfügbarkeit, mittleren Reaktionszeiten auf kritische Vorfälle, Wartungsfenstern und Begleitung bei Updates. Fordern Sie außerdem einen Business‑Continuity‑ und Wiederherstellungsplan nach Vorfällen an.

Diese Klauseln sollten im Vertrag enthalten oder verhandelbar sein: Definition der erwarteten Servicelevels, Eskalations‑ und Bereitschaftsverfahren, Supportbedingungen und Zugang zu Fixes, Verantwortlichkeiten für Datensicherheit, geistiges Eigentum an fachlichem Content und Austrittskonditionen bei Vertragsbeendigung. Legen Sie Validierungsmodalitäten der Deliverables im POC‑Status und einen klaren Abnahmeprozess fest.

POC‑Protokoll und operative Bewertungs‑Kriterien

Der POC ist als Bewertung anhand repräsentativer und reproduzierbarer Szenarien zu konzipieren. Fordern Sie eine Dauer und einen Umfang, die zur Besucherfrequenz und zu den Zielsprachen passen, und verlangen Sie ein isoliertes Testumfeld, das mindestens die Netzwerk‑ und Hardwarekonfiguration eines Pilotstandorts abbildet.

Bewerten Sie während des POC die Lösung an konkreten Achsen: funktionale Eignung für Use‑Cases, Robustheit der API‑Integrationen, Verhalten in mehreren Sprachen, Sprach‑Ergonomie unter realen Bedingungen und Fähigkeit, die bereitgestellte Wissensbasis zu nutzen. Legen Sie Abnahmekriterien fest, die auf Pass/Fail‑Tests und dokumentierten Fehlerberichten beruhen.

  • Vordefinierte funktionale Testsets, die am Pilotstandort wiederholt werden

  • Integrationsszenarien mit simulierten oder echten Fachsystemen

  • Mehrsprachige Tests für prioritäre Sprachen und Nutzerbeobachtung

  • Robustheitstests bei Ausfall externer Dienste

Scoring‑Matrix und Entscheidungsprozess (praktische Ausrichtung)

Schlagen Sie eine Bewertungsmatrix mit Kriterienfamilien vor: funktionale Relevanz, technische Qualität und Integrationen, Sicherheit und Governance, Betrieb und Support, Total Cost of Ownership und Reife des Anbieters. Bei Daten sensiblen Inhalten oder stark frequentierten Standorten gewichten Sie operative und Sicherheitskriterien höher.

Um eine rationale Entscheidung zu treffen, verlangen Sie überprüfbare Nachweise von Anbietern: Live‑Demos, eingeschränkte Backoffice‑Zugänge zur Validierung und detaillierte POC‑Ergebnisse. Bilden Sie ein multidisziplinäres Gremium aus IT, Betrieb und Fachseite, das die Ergebnisse zusammenführt und Kompromisse zwischen funktionalen Anforderungen und betrieblichen Zwängen abwägt.

Interne Vorbereitungsliste und konkrete Abnahmekriterien

Bereiten Sie vor Versendung der RFP ein strukturiertes Set an fachlichen Inhalten vor, das dem Bieter für den POC zur Verfügung gestellt wird: Produktdokumente, FAQs und Lesezugänge zu benötigten Systemen (APIs, Produktdaten). Legen Sie die Pilotstandorte fest und planen Sie die Logistik (Netzwerk, Gerätemandate, technischer Zugang).

Definieren Sie klare und nachvollziehbare Abnahmekriterien für die Schlussabnahme: Validierung der definierten Use‑Cases, Nachweis betrieblicher Integrationen, Multilingualitätsnachweis für Zielsprachen und Erfüllung der Sicherheitsanforderungen. Formalisieren Sie zudem den Fehlerbehebungsprozess und die Übergabe der erwarteten Deliverables am Ende des POC.

  • Fachinhalte und Datensets für den POC vorbereiten

  • Netz‑ und API‑Zugänge für den Bieter sicherstellen

  • Mindestens einen Pilotstandort auswählen und lokale Ansprechpartner definieren

  • Nutzerbeobachtungs‑ und Abnahmesessions organisieren

Fazit

Eine klare und strukturierte Ausschreibung ermöglicht den objektiven Vergleich von Angeboten und reduziert Risiken beim Rollout eines Avatar‑KI auf Kiosk oder Bildschirm. Durch ein stringentes POC, technische Nachweise und vertragliche Zusagen zu Betrieb und Sicherheit verringern Sie die betriebliche Unsicherheit beim Produktionsstart.

SANIA ist eine professionelle, dialogfähige Avatar‑KI‑Lösung, konzipiert für Empfang, Information und Orientierung auf Bildschirm oder Kiosk, mit einer Verfügbarkeit rund um die Uhr (24/7) und anerkannten Mehrsprachfähigkeiten. Um die Eignung einer Lösung für Ihre Pilotstandorte konkret zu prüfen, können Sie eine Demonstration anfragen und die RFP auf Basis dieses Modells erstellen.