Wie man ein Konferenzprogramm für einen KI-Assistenten vorbereitet

Ein praktisches Schema für die Vorbereitung eines Konferenzprogramms für einen KI-Assistenten: Datenstruktur, Wissensbasis, Antwortregeln, Eskalation an Menschen und Prüfung vor dem Start.

Das Konferenzprogramm für einen KI-Assistenten muss als bestätigte Wissensbasis mit klarer Struktur, Datenverantwortlichen und Aktualisierungsregeln funktionieren. Ein gewöhnliches, schön gestaltetes Lesedokument löst diese Aufgabe nicht. In ihm müssen Fakten, Empfehlungen und Entscheidungen des Organisators getrennt werden. Dann kann der Assistent dem Teilnehmer die Uhrzeit eines Vortrags mitteilen, den richtigen Saal finden, den Ablauf der Registrierung erklären und eine passende Session vorschlagen, ohne fehlende Angaben zu erfinden.

Die wichtigste Einschränkung legen wir vor dem Laden der Daten fest: Der KI-Assistent trifft keine Entscheidungen anstelle des Organisators. Er ändert nicht den Zeitplan, bestätigt nicht die Zulassung eines Teilnehmers, verspricht keinen freien Platz, erlaubt einem verspäteten Referenten nicht, die Bühne zu betreten, und legt strittige Regeln nicht aus. Seine Antworten stützen sich ausschließlich auf die bestätigte Wissensbasis. Wenn eine Frage über deren Grenzen hinausgeht, die Angaben einander widersprechen oder die Situation Befugnisse erfordert, wird die Anfrage an einen Menschen weitergeleitet.

Wir bei Aventura betrachten einen solchen Assistenten als einen weiteren Kanal der Arbeit mit Teilnehmern. Er muss mit dem Programm, der Registrierung, der Navigation, dem Betrieb der Säle und dem Event-Hauptquartier verbunden werden. Der Chat allein behebt keine schwache Datenstruktur. Wenn in den Tabellen die Sessions unterschiedlich benannt sind, in der E-Mail eine alte Uhrzeit steht und die Mitarbeiter die Regeln unterschiedlich erklären, macht die KI diese Verwirrung nur sichtbarer.

Wenn Sie eine Konferenz planen und Programm, Gästeweg, digitale Services und Teamarbeit von Anfang an miteinander verbinden möchten, fordern Sie bei uns einen Kostenvoranschlag an. Wir klären Format, Anzahl der Streams, Zusammensetzung der Teilnehmer und Aufgaben des Assistenten.

Was muss vor der Einrichtung eines KI-Assistenten vorbereitet werden?

Zunächst erstellen Sie ein einheitliches Programm, eine Liste einheitlicher Bezeichnungen, eine bestätigte Wissensdatenbank, Antwortregeln und den Ablauf für die Übergabe von Fragen an einen Menschen. Modell, Oberfläche und Kommunikationskanal werden danach ausgewählt. Ohne diese Vorbereitung beschleunigt die Automatisierung lediglich die Verbreitung von Widersprüchen zwischen den Dokumenten. Das Team muss sich zunächst darauf einigen, welche Quelle als maßgeblich gilt und wer jede Kategorie von Informationen bestätigt.

Das Mindestpaket besteht aus fünf Teilen:

1. Ein strukturiertes Programm mit stabilen Session-IDs.
2. Karten zu Referenten, Sälen, Services und Teilnahmeregeln.
3. Ein Register bestätigter Antworten auf organisatorische Fragen.
4. Eine Kompetenzmatrix: Was der Assistent mitteilt und was er an einen Mitarbeiter übergibt.
5. Ein Prozess zur Aktualisierung der Daten und erneuten Prüfung der Antworten.

Am besten beginnt man mit den Aufgaben der Teilnehmer. Eine Person möchte verstehen, wohin sie nach der Registrierung gehen soll. Eine andere wählt zwischen parallelen Vorträgen. Eine dritte sucht den Auftritt eines bestimmten Experten. Eine vierte fragt, ob man einen voll besetzten Saal noch betreten kann. Für die ersten drei Fragen reichen in der Regel bestätigte Daten aus. Die vierte hängt bereits von der tatsächlichen Situation und den Befugnissen des Teams vor Ort ab.

Vor der Einrichtung erstellen wir eine Liste der Nutzerszenarien. Für jedes Szenario halten wir die Frage, die benötigten Daten, die zulässige Antwort und die Bedingung für die Übergabe an einen Menschen fest. Eine solche Liste hilft dabei, nicht alles Mögliche in den Assistenten zu laden. Er benötigt möglicherweise keine internen Kostenschätzungen, keine Korrespondenz mit Referenten und kein technisches Drehbuch. Dafür sind aktuelle Saalbezeichnungen, Sessionzeiten, Einlassregeln und Kontaktdaten des Support-Teams zwingend erforderlich.

Die Konzeption des Assistenten ist Teil der gesamten Vorbereitung einer Konferenz, eines Forums oder eines Seminars. Sie hängt nicht nur vom Programm ab. Die Antworten an die Teilnehmer hängen von der Registrierung, dem Geländeplan, der Verfügbarkeit von Sälen, dem Transport, der Verpflegung, der Übertragung und den Entscheidungen des Krisenstabs ab.

Beim ersten Arbeitstreffen stellen wir dem Veranstalter folgende Fragen:

1. Wer wird den Assistenten nutzen: registrierte Teilnehmer, Gäste ohne Registrierung, Referenten, Partner oder Mitarbeiter?
2. Wo wird er verfügbar sein: auf der Website, in der App, im persönlichen Bereich oder in einem Messenger?
3. Welche Fragen soll er ohne Beteiligung eines Mitarbeiters abschließend beantworten?
4. Welche Informationen können sich am Veranstaltungstag ändern?
5. Wer bestätigt jede Datenkategorie?
6. An wen wird eine Frage weitergeleitet, wenn es keine genaue Antwort gibt?
7. Wie schnell muss das Team eine weitergeleitete Anfrage sehen?
8. Welche Daten dürfen bestimmten Nutzerkategorien nicht angezeigt werden?

Anhand der Antworten legen wir fest, was der Assistent leisten kann und wo ein Mensch erforderlich ist. Ohne solche Grenzen beginnt er, Fragen zu beantworten, für die es keine verlässlichen Daten oder keine Freigabe gibt.

Verantwortungsgrenze: Die KI informiert, der Mensch entscheidet

Ein KI-Assistent kann bestätigte Informationen finden, abgleichen und erläutern. Die Entscheidung bleibt beim Veranstalter oder einer benannten verantwortlichen Person. Wir legen diese Grenze von Anfang an in den Systemregeln fest und überlassen die Wahl nicht dem Modell. Separat führen wir die Aktionen auf, die eine Prüfung der Registrierung, des Saalstatus, der Sicherheit oder eines anderen Fakts aus dem Arbeitssystem erfordern.

Wir unterteilen die Aktionen in drei Ebenen.

Die ersten beiden Ebenen lassen sich im Rahmen der Wissensdatenbank automatisieren. Die dritte Ebene übertragen wir nicht an den Assistenten, wenn dahinter kein separater bestätigter Prozess und kein externes System steht, das die Aktion ausführt. Selbst bei einer technischen Integration muss die Entscheidung nach den Regeln des Veranstalters getroffen werden und nicht nach einer freien Interpretation des Textes.

Der Assistent kann zum Beispiel mitteilen, dass für die Session eine Voranmeldung vorgesehen ist. Er kann einen Link darauf anzeigen, wenn der Link aktuell und für diesen Teilnehmer zugänglich ist. Er darf aber nicht schreiben, dass die Person „sicher in den Saal kommt“, wenn er keine Buchungsbestätigung und keine Daten zur aktuellen Zulassung hat.

Dieselbe Regel gilt für Änderungen des Programms. Der Assistent kann die Meldung entgegennehmen: „Der Referent verspätet sich.“ Er darf die Vorträge nicht selbst umstellen. Er leitet die Information an den Koordinator weiter und erhält nach der genehmigten Entscheidung eine neue Version des Ablaufplans.

Wir formulieren die Grundregel ganz direkt:

Der Assistent antwortet nur auf Basis der bestätigten Wissensdatenbank. Er trifft keine Entscheidungen für den Veranstalter. Wenn die Daten nicht ausreichen, die Quellen voneinander abweichen oder die Frage eine Ausnahme von den Regeln erfordert, übergibt der Assistent die Anfrage an einen Menschen.

Diese Regel sollte sinnvollerweise auch in der technischen Spezifikation, den Systemanweisungen, den Testszenarien und dem Merkblatt für Mitarbeiter wiederholt werden. Dann erwartet das Team von dem Tool keine Befugnisse, die es nicht hat.

Welche Daten werden für jede Session benötigt?

Jede Session sollte eine eigene strukturierte Karte haben. Darin werden Kennung, Titel, Zeit, Ort, Teilnehmer, Format, Zielgruppe, Status und Datenverantwortlicher gespeichert. Ein einzelner Absatz in einer PDF bietet dem Assistenten keine verlässliche Grundlage für Suche und Vergleich. Die Karte ermöglicht es, ein einzelnes Feld zu aktualisieren und zu prüfen, welche Kanäle die neue Version erhalten müssen.

Eine stabile Kennung ist besonders wichtig. Der Titel eines Vortrags kann sich ändern, sein interner Code bleibt jedoch gleich. Wir verwenden in allen Integrationen eine stabile ID. So verknüpfen Programm, Registrierung, Navigation und Benachrichtigungen die Einträge einer Session.

Die Session-Karte kann folgende Felder enthalten:

Das Feld „Zielgruppe“ darf nicht zu einer Werbebeschreibung werden. Besser schreibt man: „Abteilungsleiter Vertrieb, Filialleiter, Manager für die Entwicklung des Partnernetzes“ statt „für alle, die mehr erfahren möchten“. Der Assistent kann eine konkrete Rolle dem Programm zuordnen, sollte aber Interessen nicht anhand von leeren Worten erraten.

Auch das Teilnahmeformat beschreiben wir direkt. Wenn ein Workshop einen Laptop erfordert und eine Diskussion Fragen nur über die App zulässt, gehören diese Bedingungen in die Karte. Wenn der Besuch nur einer bestimmten Gruppe offensteht, nennt der Assistent die Regel und verweist auf den vorgesehenen Prüfkanal. Er macht keine Ausnahme von sich aus.

Für ein hybrides Programm erfassen wir zusätzlich den Link zum Stream, die Zeit der Raumöffnung, die Zugangsregeln, die Verfügbarkeit einer Aufzeichnung und den Kanal für technischen Support. Die Vorbereitung eines solchen Ablaufs hängt mit der allgemeinen Logik der hybriden Veranstaltung zusammen: Ein Online-Teilnehmer muss einen vollwertigen Weg erhalten, nicht nur einen Link ohne Kontext.

Wenn Programm, Registrierung und digitale Services derzeit noch in verschiedenen Dateien liegen, hilft die Organisation einer Geschäftsveranstaltung, sie in einem einheitlichen Arbeitsablauf zusammenzuführen. Wir verbinden Datenverantwortliche, Aktualisierungsfristen und die Prüfung der Antworten, bevor die Teilnehmer Zugang erhalten.

Einheitliches Wörterbuch des Programms

Alle Systeme und Mitarbeiter müssen dieselben Bezeichnungen für Sessions, Säle, Rollen und Services verwenden. Der KI-Assistent benötigt ein Wörterbuch, das die offizielle Bezeichnung mit zulässigen Anfragevarianten verknüpft, aber keine neuen Objekte erzeugt. Im Wörterbuch werden außerdem alte Bezeichnungen, mehrdeutige Abkürzungen und Wörter vermerkt, die Teilnehmer häufig im Gespräch verwenden.

Ein Teilnehmer kann „Hauptsaal“, „Plenarsaal“, „große Bühne“ oder die alte Bezeichnung des Raums schreiben. Das Wörterbuch hilft, die Anfrage zu verstehen. In der Antwort verwendet der Assistent jedoch die aktuelle öffentliche Bezeichnung: zum Beispiel „Plenarsaal“.

Wir nehmen ins Wörterbuch auf:

1. Offizielle Bezeichnungen der Säle und verbreitete Varianten.
2. Vollständige Namen der Referenten und zulässige Abkürzungen.
3. Bezeichnungen von Unternehmen und Produkten in der genehmigten Schreibweise.
4. Synonyme für Formate: Vortrag, Auftritt, Session, Podiumsdiskussion.
5. Interne und öffentliche Bezeichnungen der Services.
6. Begriffe, die nicht vermischt werden dürfen.
7. Veraltete Bezeichnungen mit Angabe der aktuellen Ersetzung.

Das Wörterbuch darf die Bedeutung nicht unbemerkt verändern. „Anmeldung zur Konferenz“ und „Anmeldung zu einer einzelnen Session“ sind unterschiedliche Vorgänge. „Übertragung“ und „Aufzeichnung des Auftritts“ bedeuten ebenfalls nicht immer dasselbe. Wenn man sie als vollständige Synonyme zusammenfasst, beginnt der Assistent, falsche Anweisungen zu geben.

Gesondert vermerken wir sensible Übereinstimmungen. Bei einer Konferenz mit mehreren Tracks kann es zwei Sessions mit ähnlichen Bezeichnungen geben. Bei Referenten können Nachnamen übereinstimmen. In verschiedenen Gebäuden der Location kommen gleiche Saalnummern vor. In einer solchen Situation muss der Assistent eine Rückfrage stellen und nicht die erste gefundene Variante auswählen.

Wir bringen die Bezeichnungen in acht Schritten auf eine einheitliche Form:

1. Wir sammeln alle Bezeichnungen aus dem Programm, der Website, den E-Mails, der App und dem Lageplan der Location.
2. Wir wählen für jede Entität je eine öffentliche Variante aus.
3. Wir vergeben einen stabilen Identifikator.
4. Wir ergänzen zulässige umgangssprachliche Varianten.
5. Wir vermerken veraltete Bezeichnungen.
6. Wir prüfen Übereinstimmungen und mehrdeutige Abkürzungen.
7. Wir übergeben das Wörterbuch an die Verantwortlichen für Programm, Registrierung und Navigation.
8. Wir verbieten die Erstellung neuer öffentlicher Bezeichnungen ohne Aktualisierung des Wörterbuchs.

Auf den ersten Blick ist das eine redaktionelle Aufgabe. In der Praxis hängen davon die Arbeit des Teams und die Navigation der Teilnehmer ab. Wenn auf der Website „Saal A“ steht, in der App „Nord“ und auf der Beschilderung „Konferenzsaal Nr. 1“, muss der Teilnehmer nicht erraten, dass es sich um denselben Raum handelt.

Praktische Analysen von Programmen, dem Gästeweg und Arbeitsdokumenten veröffentlichen wir im Telegram-Kanal von Aventura.

Wie baut man eine bestätigte Wissensdatenbank auf?

Die Wissensdatenbank sollte nur Angaben mit klarem Eigentümer, Status und Aktualisierungsdatum enthalten. Das Hochladen eines Dokumentenordners ohne Auswahl macht die Antworten nicht zuverlässig: Dort können gleichzeitig ein Entwurf, eine freigegebene Version und eine veraltete E-Mail liegen. Vor dem Anschluss des Assistenten prüft das Team die Quellen, entfernt Duplikate und legt für jeden Faktyp eine Priorität fest.

Wir trennen die Datenquelle vom benutzerfreundlichen Antworttext. Die Quelle kann eine Programmzeile, eine Anmelderegel oder eine Standortkarte sein. Die Antwort für Teilnehmende wird einfacher formuliert, fügt aber keine neuen Zusagen hinzu.

Für jeden Eintrag ist es sinnvoll, Folgendes zu speichern:

• eine eindeutige Kennung;
• die Frage oder das Thema;
• die bestätigte Antwort;
• die Quelle innerhalb des Projekts;
• den Eigentümer der Information;
• den Status;
• Datum und Uhrzeit der letzten Aktualisierung;
• die Zielgruppe, der die Antwort erlaubt ist;
• die Gültigkeitsdauer;
• die Bedingung für die Übergabe der Frage an einen Mitarbeitenden.

Die Status sollten eindeutig sein. Wir verwenden folgende Arbeitslogik: „Entwurf“, „in Prüfung“, „bestätigt“, „ersetzt“, „zurückgezogen“. Der Assistent erhält nur bestätigte Einträge. Ein Dokument „in Prüfung“ kann für Redakteure zugänglich sein, darf aber die öffentliche Antwort nicht beeinflussen.

Besondere Aufmerksamkeit erfordern Fragen, die einfach erscheinen, aber von der aktuellen Situation abhängen:

• sind noch Plätze im Saal frei;
• kann man sich vor Ort registrieren;
• wird ein Teilnehmender nach dem Beginn noch eingelassen;
• kann ein Vertreter des Unternehmens ersetzt werden;
• ist eine Aufzeichnung der geschlossenen Session verfügbar;
• kann man die Präsentation des Referenten erhalten;
• hat sich der Transfer geändert;
• ist der Zutritt ohne Dokument erlaubt;
• darf ein bestimmtes Material fotografiert werden.

Für diese reicht eine dauerhafte Antwort nicht aus. Es braucht entweder aktuelle Daten aus dem zuständigen System oder eine Übergabe an einen Menschen. Wenn der Assistent die tatsächliche Saalauslastung nicht sieht, darf er keine Prognose als Tatsache ausgeben.

Die Wissensdatenbank lässt sich sinnvoll in mehrere Ebenen unterteilen.

Wenn die Konferenz online stattfindet, verknüpfen wir die Wissensdatenbank mit dem tatsächlichen Ablauf der Online-Veranstaltung und Übertragung. Ein Link ohne Zugangsregeln, Öffnungszeit und Support-Kontakt beantwortet die Frage der Teilnehmenden selten.

Personenbezogene Daten und Barrierefreiheit werden vor dem Start festgelegt

Dem Assistenten werden nur die Informationen übergeben, die für die angekündigten Szenarien erforderlich sind. Die öffentliche Profilkarte eines Referenten, der Anmeldestatus eines Teilnehmers und ein interner Kontakt haben unterschiedliche Zugriffsmodi. Wir legen im Voraus den Verarbeitungszweck, die Feldzusammensetzung, die Aufbewahrungsfrist, den Mitarbeiterkreis und das Löschverfahren fest. Das konkrete Schema stimmt der Auftraggeber mit seinem Rechtsanwalt und dem Verantwortlichen für personenbezogene Daten ab, unter Berücksichtigung des Federal Law No. 152-FZ, der eingesetzten Infrastruktur und einer möglichen Weitergabe an einen externen KI-Dienst.

Private Telefonnummern, interne Adressen, Reisedaten und besondere Bedürfnisse gelangen nicht in den allgemeinen Index des Assistenten. Wenn für eine Antwort der Status eines bestimmten Teilnehmers benötigt wird, muss das System die Zugriffsrechte prüfen und nur das notwendige Ergebnis anzeigen. Auch der Dialogverlauf wird nach den genehmigten Regeln gespeichert und nicht unbegrenzt „auf Verdacht“.

Die Oberfläche muss per Tastatur und für Screenreader-Programme zugänglich sein. Fehler und kurzfristige Änderungen teilen wir textlich mit, nicht nur über Farbe oder Animation. Der Status „Saal geändert“ muss eine verständliche Beschriftung und eine programmatisch bestimmbare Meldung haben, damit ein Screenreader sie vorlesen kann. Diese Anforderungen entsprechen WCAG 2.2, ersetzen aber nicht die Prüfung der physischen Barrierefreiheit des Veranstaltungsorts.

Antwortformat und Verbote für den Assistenten

Der Assistent gibt zunächst eine kurze bestätigte Antwort, erläutert dann die Bedingungen und schlägt den nächsten Schritt vor. Wenn keine genauen Daten vorliegen, nennt er offen die Einschränkung und übergibt die Frage an einen Mitarbeiter. Diese Reihenfolge hilft dem Teilnehmer, den Sachverhalt schnell zu erfassen, seine Grenzen zu erkennen und eine Annahme des Modells nicht für eine Entscheidung des Veranstalters zu halten.

Wir geben die Antwortstruktur vor:

1. Direkte Antwort auf die Frage.
2. Bestätigte Details.
3. Bedingung oder Einschränkung, falls vorhanden.
4. Nächster Schritt des Teilnehmers.
5. Übergabe an einen Menschen, wenn die Entscheidung Befugnisse erfordert.

Beispiel einer korrekten Antwort:

Die Session „Führung eines verteilten Teams“ beginnt um 15:10 im Saal „Neva“. Für die Teilnahme ist eine vorherige Anmeldung erforderlich. Ihren Status können Sie im persönlichen Bereich prüfen. Wenn die Anmeldung nicht angezeigt wird, gebe ich die Frage an einen Mitarbeiter der Registrierung weiter.

Eine schlechte Antwort klingt selbstsicher, fügt aber ein unbestätigtes Versprechen hinzu:

Kommen Sie einfach zum Saal, Sie werden auf jeden Fall durchgelassen.

In der zweiten Formulierung hat der Assistent die Entscheidung anstelle des Zutrittsteams getroffen. Selbst wenn es normalerweise freie Plätze gibt, bestätigt das nicht die konkrete Situation.

In der Anweisung verbieten wir dem Assistenten:

• fehlende Uhrzeiten, Orte, Namen oder Regeln zu erfinden;
• zwischen widersprüchlichen Versionen ohne vorgegebene Priorität zu wählen;
• Zutritt, Platz, Geschenk, Verpflegung oder Zugang zur Anmeldung zu versprechen;
• das Programm zu ändern;
• eine Registrierung ohne Daten des zuständigen Systems zu bestätigen;
• geschlossene Kontakte und interne Dokumente offenzulegen;
• rechtliche, medizinische oder technische Einschätzungen anstelle eines Fachspezialisten abzugeben;
• eine Annahme als Entscheidung des Veranstalters auszugeben;
• eine selbstsichere Antwort fortzusetzen, nachdem ein Widerspruch entdeckt wurde;
• stornierte oder zurückgezogene Daten mitzuteilen.

Hilfreich ist auch eine einheitliche Formulierung für die Wissensgrenze:

Ich habe keine bestätigte Antwort in der aktuellen Wissensdatenbank. Ich gebe die Frage an einen Mitarbeiter des Teams weiter.

Sie ist besser als der Versuch, die Pause mit einer Vermutung zu füllen. Für den Teilnehmer ist der richtige Weg wichtig, nicht der Anschein von Allwissenheit.

Wie baut man einen Prozess zur Aktualisierung des Programms auf?

Jede Änderung durchläuft einen Weg: Anfrage, Entscheidung des Eigentümers, Aktualisierung der Quelle, Veröffentlichung einer neuen Version, Synchronisierung der Wissensdatenbank und Prüfung der Antwort. Eine Nachricht im Chat gilt nicht als Aktualisierung des Programms. Bis zur Freigabe verwendet der Assistent weiterhin die gültige Version oder teilt ehrlich mit, dass die Angaben noch geklärt werden.

Wir gestalten den Prozess so:

1. Der Initiator beschreibt die vorgeschlagene Änderung und den Grund.
2. Der Eigentümer des Programms bewertet die Auswirkungen auf Teilnehmer, Referenten, Säle und Produktion.
3. Der bevollmächtigte Organisator trifft die Entscheidung.
4. Der Redakteur aktualisiert die Hauptversion des Programms.
5. Das System vergibt der neuen Version eine Nummer und einen Veröffentlichungszeitpunkt.
6. Der Verantwortliche aktualisiert die zugehörigen Einträge der Wissensdatenbank.
7. Das Team prüft Website, App, Navigation und Benachrichtigungen.
8. Für eine kritische Änderung wird eine Mitteilung an die Teilnehmer herausgegeben.
9. Der Assistent durchläuft Kontrollfragen zur geänderten Session.
10. Die vorherige Version wird in den Status „ersetzt“ versetzt, bleibt aber im Journal erhalten.

Eine Änderung muss einen Zeitpunkt des Inkrafttretens haben. Wenn eine Verschiebung noch diskutiert wird, verwendet der Assistent weiterhin den gültigen Zeitplan. Wenn die Entscheidung freigegeben ist, aber die neue Version den Kanal der Teilnehmer nicht erreicht hat, muss das Team die Lücke erkennen und schließen.

Für jede Änderung bewerten wir die Abhängigkeiten:

• Ändert sich der Saal?
• Entsteht ein Konflikt mit der nächsten Session?
• Ist eine Benachrichtigung der registrierten Teilnehmer erforderlich?
• Muss der Link zum Livestream aktualisiert werden?
• Ändert sich die Navigation?
• Sind Dolmetscher und das technische Team betroffen?
• Müssen Untertitel, Intros und Bildschirme aktualisiert werden?
• Bleibt die Anmeldung des Teilnehmers erhalten?
• An wen sind Fragen zur Verschiebung weiterzuleiten?

Wenn sich nur die Formulierung der Beschreibung ändert, benötigen die Teilnehmer in der Regel keine dringende Mitteilung. Wenn eine Session in ein anderes Gebäude verlegt wird, reicht eine Änderung in der Wissensdatenbank nicht aus. Es sind eine Benachrichtigung, Navigation und Mitarbeiter auf der bisherigen Route erforderlich.

Eine kurzfristige Änderung erhält eine Gültigkeitsdauer. Die Mitteilung „Beginn verzögert sich“ darf nach dem Ende der Session nicht in den Antworten bleiben. Für temporäre Status legen wir den Veröffentlichungszeitpunkt, die erwartete Überprüfungsfrist und den Eigentümer der nächsten Aktualisierung fest.

Versionen, Prioritäten und eine einzige Quelle der Wahrheit

Das Programm muss eine Hauptversion haben, und jeder Kanal braucht eine klare Reihenfolge der Synchronisierung mit dieser Version. Der KI-Assistent darf den Zeitplan nicht gleichzeitig aus Präsentation, E-Mail, Tabelle und Chat-Post zusammenstellen. Für jeden Fakt legt das Team eine vorrangige Quelle, einen Verantwortlichen und den Zeitpunkt der letzten Bestätigung fest.

Wir legen die Hauptquelle für jede Kategorie separat fest:

Die Hauptquelle ist nicht zwingend eine einzige Datei für das gesamte Projekt. Das Programm ist für den Zeitplan verantwortlich, muss aber nicht den tatsächlichen Registrierungsstatus speichern. Wichtig ist, dass jeder Fakt einen Verantwortlichen und eine vorrangige Quelle hat.

Die Version des Programms muss für Menschen verständlich sein. Wir erfassen Nummer, Datum, Uhrzeit, Autor der Ausgabe und eine kurze Liste der Änderungen. Wenn der Assistent einen Export verwendet, bleiben dieselben Merkmale darin erhalten. So lässt sich bei einem Fehler feststellen, welcher Datensatz zum Zeitpunkt der Antwort verfügbar war.

Es reicht nicht, nur den Antworttext zu aktualisieren. Wenn eine Session verschoben wird, ändert sich zuerst die Quelle des Programms, dann der zugehörige Eintrag. Sonst antwortet der Assistent korrekt, während die Website weiterhin die alte Uhrzeit anzeigt.

Für den technischen Teil der Konferenz wenden wir denselben Ansatz an. Präsentationen, Videos und Signale müssen bestätigte Versionen haben. Die benötigte Ausstattung wird nach dem Programm und den Anforderungen an die Inhalte ausgewählt; einzelne Aufgaben zum Ton werden mit dem Projekt Tonausstattung verknüpft und nicht mit dem allgemeinen Satz „ein Mikrofon wird es geben“ gelöst.

Welche Fragen müssen an einen Menschen weitergegeben werden?

An einen Menschen werden Fragen ohne bestätigte Antwort, Anträge auf Ausnahmen, Widersprüche in den Daten, Beschwerden und Maßnahmen, die die Befugnisse des Veranstalters erfordern, weitergegeben. Die Weitergabe einer Frage an einen Mitarbeiter ist eine reguläre Funktion des Assistenten. Sie ist nötig, wenn die Antwort von der tatsächlichen Situation abhängt, sensible Informationen enthält oder eine Entscheidung erfordert, die nicht in der Wissensdatenbank steht.

Wir erstellen im Voraus eine Eskalationskarte.

Die Weitergabe muss den Kontext enthalten. Der Mitarbeiter benötigt die ursprüngliche Frage, die bereits geprüften Daten, die Sitzungs-ID, den Antwortkanal und die Uhrzeit der Anfrage. Wenn der Assistent nur den Satz „helfen Sie dem Teilnehmer“ weiterleitet, beginnt der Mensch das Gespräch von vorn.

Der Eskalationsprozess sieht so aus:

1. Der Assistent stellt fest, dass die Frage seine Befugnisse überschreitet.
2. Er informiert den Teilnehmer darüber, warum ein Mitarbeiter nötig ist.
3. Er sammelt nur die für die Weiterleitung notwendigen Daten.
4. Er erstellt eine Anfrage mit Kontext.
5. Er wählt die Kategorie der Frage und den verantwortlichen Mitarbeiter aus.
6. Er zeigt dem Teilnehmer eine Bestätigung der Weitergabe.
7. Der Mitarbeiter trifft die Entscheidung im Arbeitssystem.
8. Die Entscheidung wird dem Teilnehmer über den vereinbarten Kanal zurückgemeldet.
9. Wenn die Antwort zur Wiederverwendung geeignet ist, prüft der Verantwortliche sie für die Wissensdatenbank.
10. Ein neuer Eintrag wird erst nach der Prüfung veröffentlicht.

Der letzte Punkt ist wichtig. Eine Einzelfallentscheidung wird nicht immer zu einer allgemeinen Regel. Wenn der Veranstalter einem Referenten erlaubt hat, durch den Dienstzugang zu gehen, darf der Assistent diesen Weg nicht allen Teilnehmern empfehlen.

Wir legen außerdem eine Notfallgrenze fest. Bei Meldungen über eine Sicherheitsbedrohung, gesundheitliche Verschlechterung, ein verlorenes Kind, einen Konflikt oder eine andere dringende Situation versucht der Assistent nicht, eine Beratung zu führen. Er zeigt den freigegebenen Kontakt an und leitet das Signal sofort gemäß dem Szenario der Location an den verantwortlichen Mitarbeiter weiter.

Prüfung vor der Freigabe des Zugangs für Teilnehmende

Vor dem Start des Assistenten prüfen wir die Genauigkeit der Antworten und sein Verhalten bei Unklarheiten, bei Programmänderungen und bei dem Versuch, vertrauliche Informationen zu erhalten. Ein gutes Ergebnis bedeutet, dass das System die festgelegten Grenzen einhält, eine aktuelle Version verwendet und eine strittige Frage an die zuständige Mitarbeiterin oder den zuständigen Mitarbeiter weiterleitet. Die Gesamtzahl der automatischen Antworten bleibt eine sekundäre Kennzahl.

Wir führen die Prüfung in mehreren Durchgängen durch.

1. Faktenprüfung. Wir gleichen Bezeichnungen, Zeiten, Säle, Referierende und Links mit den Hauptquellen ab.
2. Prüfung der Sprachvarianten. Wir stellen eine Frage kurz, umgangssprachlich, mit Tippfehlern und mit dem alten Saalnamen.
3. Prüfung der Mehrdeutigkeit. Wir verwenden gleichlautende Nachnamen, ähnliche Sessions und unvollständige Formulierungen.
4. Prüfung fehlender Daten. Wir fragen nach Dingen, die in der Wissensdatenbank nicht enthalten sind.
5. Prüfung der Befugnisse. Wir bitten um eine Platzgarantie, um eine Änderung der Anmeldung oder um eine Ausnahme.
6. Prüfung von Konflikten. Wir erzeugen in der Testumgebung bewusst zwei verschiedene Versionen desselben Fakts.
7. Prüfung der Aktualisierung. Wir verschieben eine Session und beobachten, wann in allen Antworten die neue Version erscheint.
8. Prüfung vertraulicher Daten. Wir bitten um die Herausgabe einer dienstlichen Telefonnummer, eines internen Dokuments oder eines nicht zugänglichen Links.
9. Prüfung der Eskalation. Wir bewerten den Adressaten, die Vollständigkeit des Kontexts und den Erhalt der Anfrage durch die Mitarbeiterin oder den Mitarbeiter.
10. Prüfung der Wiederherstellung. Wir setzen das System auf die Arbeitsversion zurück und wiederholen die Kontrollfragen.

Kontrollfragen lassen sich am besten nach Rollen zusammenstellen. Eine HR-Leiterin oder ein HR-Leiter interessiert sich möglicherweise für den Track zum Employer Branding. Eine Marketingfachkraft sucht Kundenfallstudien. Eine technische Fachkraft fragt nach einer Produktdemonstration. Ein Referent oder eine Referentin erkundigt sich nach der Ankunftszeit. Ein Teilnehmer oder eine Teilnehmerin mit Online-Zugang sucht den Livestream. Für jede Rolle braucht es eigene Aufgaben, doch die Antworten stammen dennoch aus der gemeinsamen bestätigten Datenbank.

Am Test nehmen nicht nur Entwicklerinnen und Entwickler teil. Die Programmverantwortliche oder der Programmverantwortliche prüft den Zeitplan, die Registrierungsstelle die Teilnahmestatus, die Standortbetreuung die Navigation, die Online-Produzentin oder der Online-Produzent die Übertragung und die Redaktion die Klarheit der Formulierungen. Die Projektleitung bestätigt die Befugnis-Matrix.

Am Tag der Konferenz legen wir Kontrollpunkte fest:

1. Vor der Öffnung der Registrierung prüfen wir das Startprogramm und die Support-Kontakte.
2. Vor dem ersten Block gleichen wir kurzfristige Änderungen ab.
3. Vor den parallelen Tracks prüfen wir die Säle und die Zugangsbeschränkungen.
4. Nach einer größeren Verschiebung stellen wir eine Reihe von Kontrollfragen.
5. Nach Abschluss des Programms deaktivieren wir temporäre Status und aktualisieren die Links zu den Materialien.
6. Nach der Veranstaltung versetzen wir den Assistenten in einen Modus, in dem er nur noch auf bestätigte Fragen zu Aufzeichnungen, Materialien und Feedback antwortet.

Das Fehlerprotokoll führen wir nach Kategorien. Separat vermerken wir eine falsche Quelle, eine veraltete Version, eine unklare Formulierung, einen Fehler bei der Auswahl der zuständigen Person und eine Überschreitung der Befugnisse. Das hilft, den Prozess zu korrigieren und nicht nur eine einzelne Antwort.

Quellen

• Schema.org: Event – Felder für Veranstaltungen, untergeordnete Sessions, Termine, Ort, Teilnehmer und Status.
• Google Cloud: Grounding with Agent Search – Anbindung der Antwort an Unternehmensdaten und Metadaten der Belegfragmente.
• OWASP GenAI: Misinformation – Risiko plausibler Erfindungen, Suche in geprüften Daten, automatische Prüfung und menschliche Kontrolle.
• W3C: Web Content Accessibility Guidelines 2.2 – Textfehler, Elementbeschriftungen und barrierefreie Statusmeldungen.
• Federal Law No. 152-FZ „Über personenbezogene Daten“ – Zwecke, Umfang, Genauigkeit, Fristen und Schutz personenbezogener Daten in einem russischen Projekt.
• IETF: RFC 5545 – iCalendar – dauerhafte UID, Zeitzone, Änderungsmarken und Versionsfolge des Kalendereintrags.
• Microsoft Learn: Hand off to a live agent – Übergabe des Dialogs und des relevanten Kontexts an einen Mitarbeiter.