Cómo preparar el programa de una conferencia para un asistente de IA

Esquema práctico para preparar el programa de una conferencia para un asistente de IA: estructura de datos, base de conocimiento, reglas de respuesta, escalado a una persona y verificación antes del lanzamiento.

El programa de una conferencia para un asistente de IA debe funcionar como una base de conocimiento verificada, con una estructura clara, propietarios de los datos y reglas de actualización. Un documento bonito para leer no resuelve esta tarea. En él hay que separar los hechos, las recomendaciones y las decisiones del organizador. Así el asistente podrá indicar al participante la hora de una ponencia, encontrar la sala correcta, explicar el procedimiento de registro y proponer una sesión adecuada, sin inventar información que no existe.

La principal limitación la establecemos antes de cargar los datos: el asistente de IA no toma decisiones en lugar del organizador. No modifica el horario, no confirma la admisión de un participante, no promete plazas libres, no permite que un ponente que llega tarde suba al escenario ni interpreta reglas controvertidas. Sus respuestas se basan únicamente en la base de conocimiento verificada. Si la pregunta sale de sus límites, la información se contradice o la situación requiere autoridad, la consulta se deriva a una persona.

En «Aventura» consideramos a este asistente como un canal más de trabajo con los participantes. Hay que vincularlo con el programa, el registro, la navegación, el funcionamiento de las salas y el centro de coordinación del evento. El chat por sí solo no corregirá una estructura de datos débil. Si en las tablas las sesiones tienen nombres distintos, en el correo figura un horario antiguo y los empleados explican las reglas de forma diferente, la IA solo hará más visible esa confusión.

Si está planificando una conferencia y quiere vincular desde el principio el programa, el recorrido del invitado, los servicios digitales y el trabajo del equipo, solicítenos un presupuesto. Precisaremos el formato, el número de sesiones paralelas, la composición de los participantes y las tareas del asistente.

¿Qué hay que preparar antes de configurar el asistente de IA?

Primero prepare un programa unificado, una lista de nombres unificados, una base de conocimiento confirmada, las reglas de respuesta y el procedimiento para transferir las preguntas a una persona. El modelo, la interfaz y el canal de comunicación se eligen después. Sin esta preparación, la automatización solo acelerará la propagación de contradicciones entre los documentos. El equipo debe acordar primero qué fuente se considera principal y quién confirma cada categoría de información.

El conjunto mínimo consta de cinco partes:

1. Un programa estructurado con identificadores de sesión estables.
2. Fichas de ponentes, salas, servicios y normas de participación.
3. Un registro de respuestas confirmadas a las preguntas organizativas.
4. Una matriz de competencias: qué comunica el asistente y qué transfiere a un empleado.
5. Un proceso de actualización de datos y de revisión de las respuestas.

Conviene empezar por las tareas del participante. Una persona quiere entender adónde ir después del registro. Otra elige entre ponencias paralelas. Una tercera busca la intervención de un experto concreto. Una cuarta pregunta si puede entrar en una sala llena. Para las tres primeras preguntas suelen bastar los datos confirmados. La cuarta ya depende de la situación real y de las competencias del equipo en el recinto.

Antes de la configuración elaboramos una lista de escenarios de usuario. Para cada uno fijamos la pregunta, los datos necesarios, la respuesta admisible y la condición para transferir a una persona. Esta lista ayuda a no cargar en el asistente todo sin criterio. Puede que no necesite el presupuesto interno, la correspondencia con los ponentes o el guion técnico. En cambio, sí necesita obligatoriamente los nombres actuales de las salas, el horario de las sesiones, las normas de acceso y los contactos del servicio de soporte.

El diseño del asistente forma parte de la preparación general de la conferencia, foro o seminario. No está vinculado únicamente al programa. Las respuestas a los participantes dependen del registro, el plano del recinto, la disponibilidad de las salas, el transporte, la restauración, la retransmisión y las decisiones del centro de coordinación.

En la primera reunión de trabajo planteamos al organizador las siguientes preguntas:

1. ¿Quién utilizará el asistente: participantes registrados, invitados sin registro, ponentes, socios o empleados?
2. ¿Dónde estará disponible: en el sitio web, en la aplicación, en el área personal o en un mensajero?
3. ¿Qué preguntas debe resolver sin la intervención de un empleado?
4. ¿Qué información puede cambiar el día del evento?
5. ¿Quién confirma cada categoría de datos?
6. ¿A quién se transfiere la pregunta si no hay una respuesta exacta?
7. ¿Con qué rapidez debe ver el equipo la consulta transferida?
8. ¿Qué datos no se pueden mostrar a determinadas categorías de usuarios?

A partir de las respuestas determinamos qué podrá hacer el asistente y dónde hará falta una persona. Sin estos límites, empezará a responder a preguntas para las que no hay datos fiables ni autorización.

Límite de responsabilidad: la IA informa, la persona decide

El asistente de IA puede encontrar, cotejar y explicar datos confirmados. La decisión sigue siendo del organizador o del responsable designado. Inscribimos este límite desde el principio en las reglas del sistema y no dejamos la elección a criterio del modelo. Enumeramos por separado las acciones que requieren verificar el registro, el estado de la sala, la seguridad u otro dato del sistema de trabajo.

Dividimos las acciones en tres niveles.

Los dos primeros niveles se pueden automatizar dentro de la base de conocimiento. El tercer nivel no se transfiere al asistente si no hay detrás un proceso confirmado específico y un sistema externo que ejecute la acción. Incluso con integración técnica, la decisión debe tomarse según las reglas del organizador y no según una interpretación libre del texto.

Por ejemplo, el asistente puede informar de que para la sesión se ha previsto inscripción previa. Puede mostrar el enlace a ella si el enlace está actualizado y disponible para ese participante. Pero no debe escribir que la persona «entrará seguro en la sala» si no tiene confirmación de la reserva y datos sobre el acceso actual.

La misma regla se aplica a los cambios de programa. El asistente puede recibir el mensaje: «El ponente se retrasa». No debe reordenar las ponencias por su cuenta. Transmite la información al coordinador y, tras la decisión aprobada, recibe la nueva versión del horario.

Formulamos la regla básica de forma directa:

El asistente responde solo según la base de conocimiento confirmada. No toma decisiones en lugar del organizador. Si los datos son insuficientes, las fuentes no coinciden o la cuestión requiere una excepción a las reglas, el asistente deriva la consulta a una persona.

Conviene duplicar esta regla en el pliego de condiciones, las instrucciones del sistema, los escenarios de prueba y la guía para los empleados. Así el equipo no espera de la herramienta unas competencias que no tiene.

¿Qué datos se necesitan para cada sesión?

Cada sesión debe tener una ficha estructurada propia. En ella se guardan el identificador, el nombre, la hora, el lugar, los participantes, el formato, el público, el estado y el propietario de los datos. Un párrafo en un PDF no ofrece al asistente una base fiable para buscar y comparar. La ficha permite actualizar un campo y comprobar qué canales deben recibir la nueva versión.

Un identificador estable es especialmente importante. El título de la ponencia puede cambiar, pero su código interno permanece igual. Usamos un ID estable en todas las integraciones. Así el programa, el registro, la navegación y las notificaciones vinculan los registros de una misma sesión.

La ficha de sesión puede incluir los siguientes campos:

El campo «público objetivo» no debe convertirse en una descripción publicitaria. Es mejor escribir: «directores de departamentos de ventas, directores de sucursales, gerentes de desarrollo de la red de socios», que «para todos los que quieran saber más». El asistente podrá relacionar un rol concreto con el programa, pero no debe adivinar intereses a partir de palabras vacías.

El formato de participación también se describe de forma directa. Si el taller requiere un portátil y el debate solo admite preguntas a través de la aplicación, estas condiciones se incluyen en la ficha. Si la asistencia está disponible solo para un grupo determinado, el asistente comunica la regla y propone el canal de verificación previsto. No hace una excepción por su cuenta.

Para un programa híbrido, además, fijamos el enlace a la emisión, la hora de apertura de la sala, las reglas de acceso, la disponibilidad de grabación y el canal de soporte técnico. La preparación de este recorrido está relacionada con la lógica general del evento híbrido: el participante en línea debe recibir un recorrido completo, y no un solo enlace sin contexto.

Si el programa, el registro y los servicios digitales aún viven en archivos distintos, la organización de un evento corporativo ayuda a reunirlos en un único circuito de trabajo. Vinculamos a los propietarios de los datos, los plazos de actualización y la verificación de respuestas antes de la llegada de los participantes.

Glosario único del programa

Todos los sistemas y empleados deben utilizar los mismos nombres de sesiones, salas, roles y servicios. El asistente de IA necesita un glosario que vincule el nombre oficial con las variantes de consulta admisibles, pero que no cree objetos nuevos. En el glosario también se marcan los nombres antiguos, las abreviaturas ambiguas y las palabras que los participantes suelen usar en la conversación.

Un participante puede escribir «sala principal», «plenaria», «escenario grande» o el nombre antiguo de la sala. El glosario ayuda a entender la consulta. Al mismo tiempo, en la respuesta el asistente utiliza el nombre público actual: por ejemplo, «Sala Plenaria».

Añadimos al glosario:

1. Nombres oficiales de las salas y variantes habituales.
2. Nombres completos de los ponentes y abreviaturas admisibles.
3. Nombres de empresas y productos en su grafía aprobada.
4. Sinónimos de formatos: ponencia, intervención, sesión, mesa redonda.
5. Nombres internos y públicos de los servicios.
6. Términos que no deben confundirse.
7. Nombres obsoletos con indicación del reemplazo actual.

El glosario no debe cambiar el significado de forma inadvertida. «Inscripción en la conferencia» y «registro para una sesión concreta» son acciones distintas. «Retransmisión» y «grabación de la intervención» tampoco significan siempre lo mismo. Si se unifican como sinónimos completos, el asistente empezará a dar instrucciones incorrectas.

Señalamos por separado las coincidencias sensibles. En una conferencia con varias salas paralelas puede haber dos sesiones con nombres parecidos. Los ponentes pueden tener apellidos coincidentes. En distintos edificios del recinto hay números de sala iguales. En tal situación, el asistente debe formular una pregunta aclaratoria en lugar de elegir la primera opción encontrada.

Unificamos los nombres en ocho pasos:

1. Recopilamos todos los nombres del programa, la web, los correos, la aplicación y el plano del recinto.
2. Elegimos una única variante pública para cada entidad.
3. Asignamos un identificador estable.
4. Añadimos las variantes coloquiales admisibles.
5. Marcamos los nombres obsoletos.
6. Comprobamos las coincidencias y las abreviaturas ambiguas.
7. Entregamos el glosario a los responsables del programa, el registro y la navegación.
8. Prohibimos la creación de nuevos nombres públicos sin actualizar el glosario.

A primera vista, es una tarea editorial. En la práctica, de ella dependen el trabajo del equipo y la orientación de los participantes. Si en la web figura «Sala A», en la aplicación «Norte» y en la señalización «Sala de conferencias n.º 1», el participante no tiene por qué adivinar que se trata del mismo espacio.

Publicamos análisis prácticos de programas, del recorrido del invitado y de los documentos de trabajo en el canal de Telegram de Aventura.

¿Cómo construir una base de conocimiento verificada?

La base de conocimiento debe contener únicamente información con un propietario claro, un estado y una fecha de actualización. Cargar una carpeta de documentos sin criterio de selección no hace fiables las respuestas: allí pueden convivir al mismo tiempo un borrador, una versión aprobada y un correo obsoleto. Antes de conectar al asistente, el equipo revisa las fuentes, elimina duplicados y establece una prioridad para cada tipo de dato.

Separamos la fuente de datos del texto de respuesta cómodo. La fuente puede ser una línea del programa, una regla de registro o la ficha de la sede. La respuesta para el participante se formula de manera más sencilla, pero no añade nuevas promesas.

Para cada registro conviene almacenar:

• un identificador único;
• la pregunta o el tema;
• la respuesta verificada;
• la fuente dentro del proyecto;
• el propietario de la información;
• el estado;
• la fecha y hora de la última actualización;
• la audiencia a la que se permite responder;
• el plazo de vigencia;
• la condición para transferir la pregunta a un empleado.

Los estados deben ser inequívocos. Usamos una lógica de trabajo: «borrador», «en revisión», «verificado», «reemplazado», «retirado». El asistente recibe solo los registros verificados. Un documento «en revisión» puede estar disponible para el editor, pero no debe influir en la respuesta pública.

Requieren especial atención las preguntas que parecen simples pero dependen de la situación actual:

• si quedan plazas en la sala;
• si es posible registrarse en el lugar;
• si se admitirá a un participante después del inicio;
• si se puede sustituir al representante de la empresa;
• si está disponible la grabación de una sesión cerrada;
• si se puede obtener la presentación del ponente;
• si ha cambiado el traslado;
• si se permite la entrada sin documento;
• si se puede fotografiar un material concreto.

Para ellas no basta una respuesta permanente. Se necesitan datos actualizados del sistema responsable o la transferencia a una persona. Si el asistente no ve la ocupación real de la sala, no debe presentar una previsión como un hecho.

Conviene dividir la base de conocimiento en varias capas.

Si la conferencia se celebra en línea, vinculamos la base de conocimiento con la ruta real del evento en línea y la transmisión. Un enlace sin reglas de acceso, hora de apertura y contacto de soporte rara vez resuelve la duda del participante.

Los datos personales y la accesibilidad se definen antes del lanzamiento

Al asistente solo se le transmiten los datos necesarios para los escenarios previstos. La ficha pública del ponente, el estado de inscripción del participante y el contacto interno tienen distintos modos de acceso. De antemano definimos la finalidad del tratamiento, la composición de los campos, el plazo de conservación, el círculo de empleados y el procedimiento de eliminación. El cliente acuerda el esquema concreto con su abogado y con el responsable de datos personales, teniendo en cuenta la Ley Federal No. 152-FZ, la infraestructura utilizada y la posible transferencia a un servicio externo de IA.

Los teléfonos personales, las direcciones internas, los datos del viaje y las necesidades especiales no entran en el índice general del asistente. Si para responder se necesita el estado de un participante concreto, el sistema debe verificar los derechos de acceso y mostrar solo el resultado necesario. El historial del diálogo también se conserva según las reglas aprobadas, y no de forma indefinida «por si acaso».

La interfaz debe ser accesible con el teclado y para los programas de lectura de pantalla. Los errores y los cambios operativos se comunican por texto, no solo por color o animación. El estado «sala modificada» debe tener una etiqueta clara y un mensaje detectable por software, para que un lector de pantalla pueda anunciarlo. Estos requisitos están en línea con WCAG 2.2, pero no sustituyen la verificación de la accesibilidad física del recinto.

Formato de respuesta y prohibiciones para el asistente

El asistente primero da una respuesta breve y confirmada, luego explica las condiciones y propone el siguiente paso. Si no hay datos exactos, informa directamente de la limitación y traslada la consulta a un empleado. Este orden ayuda al participante a comprender rápidamente el hecho, ver sus límites y no tomar una suposición del modelo por una decisión del organizador.

Definimos la estructura de la respuesta:

1. Respuesta directa a la pregunta.
2. Detalles confirmados.
3. Condición o limitación, si la hay.
4. Siguiente paso del participante.
5. Transferencia a una persona cuando la decisión requiere autorización.

Ejemplo de respuesta correcta:

La sesión «Gestión de un equipo distribuido» comenzará a las 15:10 en la sala «Neva». Para asistir se requiere inscripción previa. Puede comprobar su estado en su área personal. Si la inscripción no aparece, trasladaré la consulta al empleado de registro.

Una mala respuesta suena segura, pero añade una promesa no confirmada:

Venga a la sala, seguro que le dejan pasar.

En la segunda formulación, el asistente tomó una decisión en nombre del equipo de acceso. Aunque normalmente haya plazas libres, eso no confirma la situación concreta.

En las instrucciones prohibimos al asistente:

• inventar una hora, un lugar, un nombre o una regla inexistentes;
• elegir entre versiones contradictorias sin una prioridad definida;
• prometer acceso, plaza, regalo, comida o acceso a la inscripción;
• modificar el programa;
• confirmar la inscripción sin los datos del sistema responsable;
• revelar contactos internos y documentos internos;
• dar una valoración jurídica, médica o técnica en lugar de un especialista del área;
• presentar una suposición como decisión del organizador;
• seguir dando una respuesta segura tras detectar una contradicción;
• comunicar datos cancelados o revocados.

También es útil una frase única para el límite del conocimiento:

No tengo una respuesta confirmada en la base de conocimiento actualizada. Trasladaré la consulta a un empleado del equipo.

Es mejor que intentar llenar la pausa con una suposición. Al participante le importa la ruta correcta, no la apariencia de omnisciencia.

¿Cómo construir el proceso de actualización del programa?

Cada cambio sigue una única ruta: solicitud, decisión del propietario, actualización de la fuente, publicación de una nueva versión, sincronización de la base de conocimiento y verificación de la respuesta. Un mensaje en el chat no se considera una actualización del programa. Hasta su aprobación, el asistente sigue utilizando la versión vigente o informa honestamente de que los datos están siendo confirmados.

Construimos el proceso así:

1. El iniciador describe el cambio propuesto y su motivo.
2. El propietario del programa evalúa el impacto en los participantes, ponentes, salas y producción.
3. El organizador autorizado toma la decisión.
4. El editor actualiza la versión principal del programa.
5. El sistema asigna a la nueva versión un número y una hora de publicación.
6. El responsable actualiza los registros relacionados de la base de conocimiento.
7. El equipo verifica el sitio web, la aplicación, la navegación y las notificaciones.
8. Para los cambios críticos se emite un mensaje a los participantes.
9. El asistente supera las preguntas de control sobre la sesión modificada.
10. La versión anterior pasa al estado «reemplazada», pero se conserva en el registro.

Todo cambio debe tener un momento de entrada en vigor. Si el traslado aún se está discutiendo, el asistente sigue utilizando el horario vigente. Si la decisión está aprobada, pero la nueva versión no ha llegado al canal de los participantes, el equipo debe ver la discrepancia y cerrarla.

Para cada modificación evaluamos las dependencias:

• ¿cambia la sala?
• ¿surge un conflicto con la siguiente sesión?
• ¿se requiere notificar a los participantes registrados?
• ¿hay que actualizar el enlace a la transmisión?
• ¿cambia la navegación?
• ¿se ven afectados los intérpretes y el equipo técnico?
• ¿hay que actualizar los rótulos, las pantallas de apertura y las pantallas?
• ¿se conserva el registro del participante?
• ¿a quién derivar las preguntas sobre el traslado?

Si solo cambia la redacción de la descripción, por lo general los participantes no necesitan un mensaje urgente. Si la sesión se traslada a otro edificio, una sola corrección en la base de conocimiento no es suficiente. Harán falta notificaciones, navegación y personal en el recorrido anterior.

El cambio operativo tiene un plazo de vigencia. El mensaje «el inicio se retrasa» no puede mantenerse en las respuestas una vez finalizada la sesión. Para los estados temporales fijamos la hora de publicación, el plazo previsto de revisión y el propietario de la siguiente actualización.

Versiones, prioridades y una única fuente de verdad

El programa debe tener una versión principal, y cada canal debe contar con un orden claro de sincronización con ella. El asistente de IA no debe recopilar el cronograma a la vez desde una presentación, un correo, una hoja de cálculo y una publicación en el chat. Para cada dato, el equipo asigna una fuente prioritaria, un responsable y la hora de la última confirmación.

Asignamos la fuente principal por separado para cada categoría:

La fuente principal no tiene por qué ser un único archivo para todo el proyecto. El programa es responsable del cronograma, pero no está obligado a almacenar el estado real de la inscripción. Lo importante es que cada dato tenga un responsable y una fuente prioritaria.

La versión del programa debe ser comprensible para una persona. Registramos el número, la fecha, la hora, el autor de la publicación y una breve lista de cambios. Si el asistente utiliza una exportación, en ella se conservan los mismos indicadores. Así, en caso de error, se puede determinar qué conjunto de datos estaba disponible en el momento de la respuesta.

No se puede actualizar solo el texto de la respuesta. Si la sesión se ha trasladado, primero se modifica la fuente del programa y luego el registro asociado. De lo contrario, el asistente responderá correctamente, pero el sitio web seguirá mostrando la hora antigua.

Para la parte técnica de la conferencia aplicamos el mismo enfoque. Las presentaciones, los vídeos y las señales deben tener versiones confirmadas. El equipo necesario se selecciona después del programa y de los requisitos de contenido; las tareas específicas de sonido se vinculan al proyecto de equipos de sonido, y no se resuelven con la frase general «habrá micrófono».

¿Qué preguntas deben transferirse a una persona?

A una persona se le transfieren las preguntas sin respuesta confirmada, las solicitudes de excepción, las contradicciones en los datos, las quejas y las acciones que requieren la autoridad del organizador. Transferir una pregunta a un empleado es una función habitual del asistente. Es necesaria cuando la respuesta depende de la situación real, contiene información sensible o requiere una decisión que no está en la base de conocimiento.

Elaboramos de antemano un mapa de escalado.

La transferencia debe incluir contexto. El empleado necesita la pregunta original, los datos ya verificados, el identificador de la sesión, el canal de respuesta y la hora de la consulta. Si el asistente solo reenvía la frase «ayuden al participante», la persona empieza la conversación desde cero.

El proceso de escalado es el siguiente:

1. El asistente determina que la pregunta excede sus competencias.
2. Informa al participante de por qué se necesita un empleado.
3. Recopila solo los datos necesarios para el enrutamiento.
4. Crea una solicitud con contexto.
5. Selecciona la categoría de la pregunta y el empleado responsable.
6. Muestra al participante la confirmación de la transferencia.
7. El empleado toma la decisión en el sistema de trabajo.
8. La decisión se devuelve al participante por el canal acordado.
9. Si la respuesta es apta para reutilizarse, el titular la considera para la base de conocimiento.
10. La nueva entrada se publica solo tras la verificación.

El último punto es importante. Una decisión puntual no siempre se convierte en una regla general. Si el organizador permitió a un ponente pasar por la entrada de servicio, el asistente no debe recomendar esa ruta a todos los participantes.

También definimos el límite de emergencia. Ante mensajes sobre una amenaza a la seguridad, un empeoramiento del estado de salud, un niño perdido, un conflicto u otra situación urgente, el asistente no intenta ofrecer una consulta. Muestra el contacto aprobado y transfiere de inmediato la señal al empleado responsable según el protocolo del recinto.

Verificación antes de abrir el acceso a los participantes

Antes de lanzar el asistente, comprobamos la exactitud de las respuestas y su comportamiento ante la incertidumbre, los cambios en el programa y los intentos de obtener información confidencial. Un buen resultado significa que el sistema respeta los límites establecidos, utiliza la versión más reciente y traslada la cuestión controvertida al empleado correspondiente. El número total de respuestas automáticas sigue siendo una métrica secundaria.

Realizamos la verificación en varias pasadas.

1. Verificación de datos. Contrastamos los nombres, horarios, salas, ponentes y enlaces con las fuentes principales.
2. Verificación de variantes de lenguaje. Planteamos una misma pregunta de forma breve, coloquial, con erratas y con el nombre antiguo de la sala.
3. Verificación de ambigüedad. Utilizamos apellidos coincidentes, sesiones similares y formulaciones incompletas.
4. Verificación de datos ausentes. Preguntamos por aquello que no está en la base de conocimiento.
5. Verificación de competencias. Solicitamos garantizar una plaza, modificar una inscripción o autorizar una excepción.
6. Verificación de conflicto. Creamos deliberadamente dos versiones distintas de un mismo dato en el entorno de pruebas.
7. Verificación de actualización. Trasladamos una sesión y observamos cuándo aparece la nueva versión en todas las respuestas.
8. Verificación de datos confidenciales. Solicitamos un teléfono interno, un documento interno o un enlace no disponible.
9. Verificación de escalado. Evaluamos el destinatario, la integridad del contexto y la recepción de la solicitud por parte del empleado.
10. Verificación de restauración. Devolvemos el sistema a la versión operativa y repetimos las preguntas de control.

Conviene recopilar las preguntas de control por roles. Al director de RR. HH. puede interesarle el itinerario sobre la marca empleadora. El especialista de marketing busca casos de clientes. El especialista técnico pregunta por la demostración del producto. El ponente aclara la hora de llegada. El participante con acceso en línea busca la retransmisión. Cada rol necesita sus propias tareas, pero las respuestas se toman igualmente de la base confirmada común.

En las pruebas no participan solo los desarrolladores. El responsable del programa verifica el calendario, el servicio de registro, los estados de participación, el gestor de la sede, la navegación, el productor en línea, la emisión, y el editor, la claridad de las formulaciones. El jefe de proyecto confirma la matriz de competencias.

El día de la conferencia fijamos puntos de control:

1. Antes de abrir el registro, verificamos el programa inicial y los contactos de soporte.
2. Antes del primer bloque, contrastamos los cambios operativos.
3. Antes de los itinerarios paralelos, verificamos las salas y las restricciones de acceso.
4. Tras un cambio importante, planteamos un conjunto de preguntas de control.
5. Al finalizar el programa, desactivamos los estados temporales y actualizamos los enlaces a los materiales.
6. Después del evento, pasamos el asistente a un modo en el que solo responde a preguntas confirmadas sobre grabaciones, materiales y comentarios.

Llevamos el registro de errores por categorías. Señalamos por separado la fuente incorrecta, la versión obsoleta, la formulación poco clara, el error al elegir al responsable y la extralimitación de competencias. Esto ayuda a corregir el proceso, y no solo una respuesta concreta.

Fuentes

• Schema.org: Event - campos del evento, sesiones secundarias, fechas, lugar, participantes y estado.
• Google Cloud: Grounding with Agent Search - vinculación de la respuesta con los datos corporativos y metadatos de los fragmentos de respaldo.
• OWASP GenAI: Misinformation - riesgo de invenciones verosímiles, búsqueda sobre datos verificados, verificación automática y control humano.
• W3C: Web Content Accessibility Guidelines 2.2 - errores de texto, etiquetas de elementos y mensajes de estado accesibles.
• Ley Federal N.º 152-FZ «Sobre los datos personales» - fines, composición, exactitud, plazos y protección de los datos personales en un proyecto ruso.
• IETF: RFC 5545 - iCalendar - UID permanente, zona horaria, marcas de modificación y secuencia de versiones del registro de calendario.
• Microsoft Learn: Hand off to a live agent - transferencia del diálogo y del contexto relevante a un empleado.