Un bot con Chrome anonimo en Docker grabo 1.170 reuniones y entrega resumenes en 4,6 minutos

Los acuerdos alcanzados en una reunion suelen durar exactamente hasta la siguiente. Nadie redacta el acta y, una semana despues, los participantes recuerdan cerca del 10% de lo dicho. El segundo problema es mas reciente: la empresa utiliza agentes de IA, pero estos solo conocen aquello que se ha registrado e indexado. Todo lo decidido de palabra simplemente no existe para ellos. El autor del articulo de Habr decidio cerrar ambas brechas con un asistente de reuniones propio y publico cifras de produccion.

Por que no Copilot ni la transcripcion nativa

Copilot solo funciona para quienes tienen una suscripcion, por lo que no sirve para automatizar el proceso en todos los equipos sin intervencion manual. Tampoco cubre tenants externos, Telemost, MTS Link ni TrueConf. Ademas, la empresa queria procesar en sus propios servidores el audio de las reuniones con clientes.

La transcripcion nativa de Teams para ruso tampoco convencio al autor. En las mismas reuniones producia entre 26 y 37 palabras por minuto, cuando el ritmo normal del habla profesional ronda las 100 y el flujo del autor entregaba entre 99 y 108. Teams tambien escribe foneticamente los terminos tecnicos: representa “add button” como “ed batton.” La muestra es pequena y el autor reconoce que la comparacion es una referencia, no un benchmark.

Dos flujos en lugar de uno

No fue posible construir una solucion universal porque existen dos tipos de reuniones en Teams.

Las reuniones de canal —dailies, sesiones de planificacion y retrospectivas— se graban automaticamente por politica y se almacenan en SharePoint. No tienen un chat de grupo convencional: la conversacion vive en un hilo bajo la publicacion raiz del canal y los invitados anonimos no pueden acceder. Por eso se instala un bot en el equipo.

Este lee el canal y detecta el evento de servicio CallRecording con estado Success. Descarga el MP4, lo convierte en WAV de 16 kHz, lo envia al sistema de reconocimiento y publica el resumen en el hilo de la reunion. Para ello necesita el permiso RSC ChannelMessage.

Read.Group, que concede el propietario del equipo sin que un administrador tenga que autorizar el acceso a todo el tenant.

El “Asistente de reuniones” atiende todas las demas reuniones. Se anade a la invitacion como un participante normal y, al comenzar la reunion, entra un Chrome anonimo ejecutado en Docker. Solo se graba con consentimiento explicito: si el asistente fue invitado y admitido, graba; de lo contrario, no. Los flujos estan separados fisicamente y tienen registros, aplicaciones y permisos propios, por lo que la filtracion de una clave no afecta al otro.

Problemas que conviene recordar

Condicion de carrera durante la grabacion. Al principio, el estado se guardaba en archivos JSON y, en la primera semana, el listener y un cron de respaldo enviaron dos veces una misma grabacion. La solucion fue Postgres con INSERT … ON CONFLICT DO NOTHING y SELECT … FOR UPDATE; la operacion claim devuelve uno de cuatro modos: new, retake, attach o skip.

Callejones sin salida con las transcripciones. El permiso RSC ChannelMeetingTranscript.Read.Group devolvia 403, SharePoint no aceptaba un token app-only sin certificado y onlineMeetings/transcripts de Graph exige una application access policy para el organizador. Por eso, la base del flujo son los archivos MP4 y el reconocimiento propio, mientras que el VTT de Teams se utiliza como fuente auxiliar.

Nombres de los hablantes. Del archivo VTT se obtienen el numero de hablantes —la pista num_speakers— y sus nombres. Despues, los segmentos se comparan con los clusters de diarizacion segun el desfase temporal. En tres reuniones verificadas manualmente, entre el 94% y el 99% de los segmentos recibieron el nombre correcto. Cualquier fallo se etiqueta como “Anonimo”: una intervencion atribuida a la persona equivocada es peor que una anonima.

Graph API tampoco puede ver el calendario de Exchange on-prem, por lo que hubo que recurrir a EWS. La sesion del publicador basado en navegador caducaba silenciosamente por una cookie de sesion, y el detector del hablante activo solo capturaba una cuarta parte del discurso hasta que se sustituyeron los eventos por sondeos de estado.

Que significa esto en la practica

Si esta construyendo algo similar, la conclusion es clara. No intente cubrir todas las plataformas con una unica solucion: es mas barato gestionar las reuniones de canal de Teams mediante un bot instalado en el equipo y atender el resto participando en la conversacion. Guarde el estado en una base de datos con bloqueos, no en archivos. Adapte los prompts de resumen al tipo de reunion —daily, retrospectiva o planificacion— y carguelos en cada envio para poder modificarlos sin reiniciar. Lo mas importante es que las transcripciones indexadas por la plataforma proporcionan a los agentes memoria de las decisiones tomadas de palabra. Esa es la base de los agentes proactivos.

Tambien hay limitaciones. El flujo 1 no admite canales privados; en reuniones externas hay que admitir al bot desde la sala de espera; y Teams tiene errores que pueden hacer que el bot deje de recibir actualizaciones del canal (issue #11106 de msteams-docs). Ademas, las cifras proceden de una sola empresa y no cuentan con verificacion independiente, aunque cuatro meses en produccion con 93 organizadores constituyen un argumento convincente.