Einleitung: Ziel eines nutzerzentrierten RFP
Die Erstellung einer Ausschreibung für einen KI‑Empfangs‑Avatar erfordert ein ausgewogenes Verhältnis zwischen technischen Anforderungen, operativen Zwängen, rechtlichen Pflichten und objektiven Bewertungskriterien. Das Dokument muss unterschiedlichen Anbietern ermöglichen, vergleichbare Angebote einzureichen, und dem Auftraggeber erlauben, die Antworten eindeutig zu bewerten.
Dieser Leitfaden bietet eine strukturierte Checkliste, Muster für Vertragsklauseln und SLAs, eine gewichtete Bewertungsmatrix sowie ein Mapping zur Überprüfung gängiger technischer Differenzierer (RAG, Multi‑LLM, Integrationen, Dokumentenformate, Hardware‑Kompatibilität, Barrierefreiheit, Support 24/7).
Warum das RFP von Anfang an strukturieren
Ein strukturiertes RFP reduziert das Risiko unvollständiger Vergleiche, verhindert Auslassungen bei sensiblen Themen (Datenschutz, Barrierefreiheit, Betriebskontinuität) und macht die erwarteten Schnittstellen zu Fachsystemen klarer. Es erleichtert zudem die Vertragsverhandlungen, weil technische und operative Verpflichtungen vorher dokumentiert sind.
Das operative Ziel ist einfach: homogene, messbare und überprüfbare Antworten erhalten, um auf dokumentierten Kriterien den für den Einsatzkontext (Standorte, Zielgruppen, regulatorische Vorgaben) geeignetsten Anbieter auszuwählen.
RFP‑Checkliste – zwingende Rubriken
Folgende Rubriken als Mindestanforderungen aufnehmen: Vertragsgegenstand, Umfang der Standorte, Beschreibung der prioritären Anwendungsfälle, Barrierefreiheitsanforderungen, Erwartungen an Sprachunterstützung, Interaktionsformate (Stimme, Touch) und gewünschte Betriebsmodi.
Technische Mindestangaben konkretisieren: Kompatibilität von Bildschirmen/Terminals mit Betriebssystemfamilien (Tizen, Android, Windows) entsprechend der vorhandenen Infrastruktur, Netzwerk‑ und Sicherheitsanforderungen, Multi‑Site‑Deployments und Verfahren für zentrale Wissensdatenbank‑Updates.
Gegenstand und Umfang des Projekts
Prioritäre Anwendungsfälle und Ausschlüsse
Barrierefreiheitsanforderungen (Sprachmodalitäten, Untertitel, LSF, Touch)
Unterstützte Sprachen und Mehrsprachigkeitsfähigkeit
Hardware‑Kompatibilität und OS‑Familien (Tizen, Android, Windows) – Bestand angeben
Zielarchitektur sowie Netzwerk‑/Sicherheitsanforderungen
RFP‑Checkliste – operative und Governance‑Rubriken
Klärung der Content‑Governance verlangen: wer die Wissensdatenbank pflegt, Validierungsprozesse der Fachbereiche, Werkzeuge zur Aktualisierung und Granularität der Bearbeitungsrechte.
Erwartungen an den Betrieb definieren: Wartungsverfahren, gewünschte Verfügbarkeit (bei Bedarf durchgehender Service 24/7), Support‑Modalitäten, Schulungen und Wiederanlauf im Störfall. Ebenfalls die erwarteten Deliverables für Pilotphase und Produktionsübergang angeben.
Governance‑Modell und Rollen (Editor, Validator, Administrator)
Prozess zur Aktualisierung fachlicher Inhalte
Pilot‑Rollout‑Plan und Abnahmekriterien
Schulungen und Dokumentation
Operativer Support und Bereitschaftsdienste 24/7
Juristische Rubriken und Datensicherheit – was anzufordern ist
Eine klare Beschreibung der Datenverarbeitungen, des Umfangs der erfassten Daten und der eingesetzten Sicherheitsmaßnahmen einfordern. Angaben zur Daten‑Hosting‑Location sowie die Möglichkeit eines dedizierten Infrastruktureinsatzes bei Bedarf verlangen.
Die vertraglich zu integrierenden juristischen Vorgaben präzisieren: Haftung, geistiges Eigentum an Prompts/Personas, Vertraulichkeit, Sicherungs‑ und Wiederherstellungsbedingungen, Kündigungs‑ und Datenübernahmebedingungen. Diese Klauseln als Zulassungskriterien formulieren, nicht nur als Optionen.
Beschreibung der Verarbeitungen und ihrer Zwecke
Standort des Hostings und Infrastruktur‑Optionen
Technische und organisatorische Sicherheitsmaßnahmen
Eigentumsrechte an Inhalten und Persona‑Anpassungen
Modalitäten zur Rückgabe oder Löschung von Daten bei Vertragsende
Musterklauseln im Vertrag und SLA‑Struktur (anpassbar)
Vorlagen für Klauseln erleichtern den Vergleich. Wesentliche Elemente, die das RFP vom Anbieter als Antwort verlangen sollte: Verfügbarkeitsgarantie, Supportstufen, geplante Wartung, Wiederanlauf nach Störung, Vertraulichkeit und Auditmöglichkeiten. Klarstellen, dass konkrete Zahlen verhandelbar sind und im Endvertrag festgelegt werden.
Beispielhaftes SLA‑Gerüst für das RFP: Definition von Schweregraden, Erstreaktionszeiten je Schweregrad, Zielzeiten zur Problemlösung, Benachrichtigungs‑ und Eskalationswege, geplante Wartungsfenster und Reporting. Ebenfalls die Forderung nach einer Supportorganisation, die 24/7 arbeiten kann, wenn der Dienst durchgängig angeboten wird, angeben.
Definitionen: Verfügbarkeit, geplante Unterbrechung, kritischer Vorfall
Schweregrade und erwartete Reaktionen (Erstreaktion, Lösung)
Benachrichtigungs‑ und Eskalationsmodalitäten
Geplante Wartung und Arbeiten in definierten Fenstern
Periodisches Reporting und Service‑Reviews
Gewichtete Bewertungsmatrix und Beispiel‑Scoring (hypothetisch)
Eine Bewertungsmatrix hilft, Angebote objektiv zu vergleichen. Die Hauptkriterien (technisch, Sicherheit, Barrierefreiheit, Integrationen, Governance, Gesamtkosten) darstellen und die intern gewählte Gewichtung erläutern. Die Gewichtung ist an den Geschäftskontext und die Projektprioritäten anzupassen.
Hypothetisches Beispiel: technische Aspekte und Integrationen höher gewichten, wenn viele Fachsystemanbindungen erforderlich sind; Barrierefreiheit stärker priorisieren, wenn die Zielgruppe überwiegend vulnerabel ist. Das Folgende ist illustrativ und muss an den Bedarf angepasst werden.
Technische Kriterien: Architektur, Multi‑LLM‑Support, RAG, Dokumentenformate
Sicherheit und Compliance: technische Maßnahmen, Hosting, Audits
Barrierefreiheit: Sprach-/Touch‑Modi, Untertitel, LSF‑Support
Betrieblich: Governance, Schulung, Support 24/7
Kosten und Geschäftsmodell: Lizenzen, Integrations‑ und Wartungskosten
Praktisches Mapping zur Überprüfung technischer Differenzierer
Um technische Angaben der Anbieter zu verifizieren, reproduzierbare Nachweise verlangen: Demonstrationen an realen Fällen, Zugang zu Testumgebungen zur Validierung der RAG‑Antwortqualität, mehrsprachige Tests und Integrationsszenarien mit falschen APIs oder Sandboxes.
Jeden Anbieter auffordern, das unterstützte Dokumentenformat und die zulässigen Volumina für die Ingestion, das Versionsmanagement sowie kompatible bzw. orchestrierbare LLM‑Engines detailliert anzugeben. Die vorgesehene Kompatibilität mit Bildschirm‑/Terminalfamilien (Tizen, Android, Windows) und die Fähigkeit, in Sprach‑, Touch‑ oder Hybrid‑Modi zu arbeiten, prüfen.
Geforderte Nachweise: Demonstration, Sandbox‑Zugang, fachliche Testfälle
Unterstützte Dokumentformate für RAG (PDF, DOCX, XLSX, TXT, CSV, NDJSON) – Details erfragen
Multi‑LLM‑Support und Orchestrierungsstrategie
Hardware‑Kompatibilität und Multi‑Site‑Deployment‑Modalitäten
Barrierefreiheits‑Tests und Nachweise zur Nutzervalidierung
Operative Risiken und häufige Fehler vermeiden
Die Content‑Governance nicht vernachlässigen: Die alleinige Verantwortung für Antworten beim Anbieter zu belassen, ohne interne Validierungsprozesse zu definieren, führt häufig zu Qualitätsabweichungen. Festlegen, wer für die Aktualisierung fachlicher Informationen verantwortlich ist.
Die Pilotphase nicht vergessen. Ein Pilot validiert Integrationen, Antwortqualität, Sprach‑ und Touch‑Interaktions‑Ergonomie sowie die Akzeptanz durch Benutzer. Im RFP sollten auch die akzeptierten Testumfänge für die finale Abnahme klar definiert werden.
Content‑Governance eindeutig festlegen
Repräsentative Testszenarien und formalisierten Pilot vorsehen
Fähigkeit des Anbieters sicherstellen, eine Testumgebung zu liefern
Nicht Verfügbarkeit versprechen mit operativer Bereitschaft verwechseln
In der Praxis: Fragen für Anbieterinterviews
Zur Ergänzung der schriftlichen Unterlagen ein Fragenkatalog zu sensiblen Punkten vorbereiten: Wie schützt der Anbieter die Vertraulichkeit von Daten, welche Garantien bestehen für Sicherung und Wiederherstellung, wie werden mehrsprachige Tests durchgeführt und welche Back‑Office‑Werkzeuge werden zur Bearbeitung der Wissensdatenbank bereitgestellt.
Auch gezielte Demonstrationen anfordern zur Handhabung von Ausfällen, zu Massenuploads von Inhalten und zur Fähigkeit, Persona und Stimme unter Berücksichtigung von Rechten und Image‑Vorgaben anzupassen. Diese Punkte zeigen die operationale Reife jenseits der schriftlichen Antworten.
Beispielfragen: Incident‑Management, Wiederherstellung, Datenlokation
Demo‑Szenarien: Dokumentenimport, RAG‑Anfrage, mehrsprachiger Sprachtest
Ergonomie des Back‑Office‑Editors bewerten
Fazit: Formalisieren zur Risikoreduzierung und Entscheidungsvereinfachung
Ein vollständiges und strukturiertes RFP ermöglicht den Vergleich von Anbietern auf objektiver Basis und reduziert Risiken in Bezug auf Sicherheit, Barrierefreiheit und Betrieb. Durch die Strukturierung der Pflichtrubriken, das Anbieten von Klauselvorlagen und einer Bewertungsmatrix erleichtern Sie eine dokumentierte Entscheidungsfindung.
SANIA kann einige der hier genannten operationalen Differenzierungsmerkmale veranschaulichen: ein für Bildschirm oder interaktive Terminals konzipierter KI‑Empfangs‑Avatar, rund um die Uhr verfügbar und in vielen Sprachen kommunikationsfähig. Um die Tauglichkeit dieses Ansatzes für Ihren Kontext zu prüfen und ein anpassbares RFP‑Beispiel zu erhalten, können Sie eine Demonstration und ein RFP‑Kit anfordern.