SubseBot · Piloto Cursos Obligatorios · GCBA

Arquitectura MCP, multi-rol y OAuth

Cómo un colaborador y RRHH consultan el mismo bot sin que ninguno vea datos que no le corresponden. Basado en la Especificación de Requerimientos EARS del proyecto.

El sistema de un vistazo

Entra

Colaboradorpregunta por sus propios cursos

RRHHfiltra por equipo o curso, exporta

OAuth 2.0 · Google Workspaceresuelve identidad antes de que haya conversación

→

Decide

Servidor MCPmiddleware fijo: valida token, resuelve rol y legajo

tool: consultar_estadocolaborador — solo su propio legajo

tool: listar_por_equipoRRHH — filtrado por rol

tool: exportar_excelRRHH — archivo generado por código

→

Sale

Copia anonimizadaSheet (piloto) o Postgres con RLS (a escala)

Respuesta en lenguaje naturalredactada por el LLM sobre datos ya filtrados

Enlaces a ICBA + Excelgenerados por tabla y plantilla, no por el modelo

núcleo fijo — no cambia entre propuestas intercambiable — canal, almacenamiento, IdP

Los contratos

consultar_estado(identidad_resuelta) → estado[]el legajo nunca viaja como texto libre del usuario

listar_por_equipo(equipo, rol) → estado[]rechaza si el rol no es RRHH

exportar_excel(filtro, rol) → archivo.xlsxplantilla de código, cero texto generado

La regla que sostiene todo: el permiso se resuelve antes de que el modelo vea el dato — nunca dentro del prompt.

El detalle — lo mismo, desarmado

Entra — identidad y roles

Cada mensaje llega ya con una identidad verificada, no con un nombre que el usuario escribió. El id_token de Google se cruza contra una tabla chica email → legajo → rol. RRHH se define por pertenecer a un Google Group dedicado, no por heurística de dominio.

Lo que suele hacerse El usuario escribe su legajo en el chat y el sistema confía en ese dato para responder.

Lo que proponemos acá El legajo se resuelve server-side desde el token OAuth. El texto libre del usuario no puede pedir el legajo de otra persona.

Decide — el servidor MCP y qué es determinístico

El LLM solo decide qué herramienta llamar a partir del lenguaje. Todo lo que toca datos o permisos es código, no criterio del modelo.

Determinístico — código

resolución de rol y legajo autorización fila por fila el query en sí anonimización de la copia generación del Excel links a ICBA manejo de errores

No determinístico — el LLM

interpretar la intención redactar la respuesta pedir aclaración si es ambiguo narrar el resumen para líderes

Regla práctica: si un error ahí muestra un dato ajeno, tiene que ser código. Si el error es una respuesta mal redactada, puede ser el LLM.

Sale — dos propuestas de almacenamiento

Misma capa de decisión (02), dos formas de resolver "sale" según qué tan lejos va el piloto.

	A · Sheets + MCP liviano	B · Postgres + MCP desacoplado
Tiempo a producción	Días	Semanas
Dónde se impone el permiso	Código del servidor	Base de datos (RLS) + servidor
Auditoría de accesos	Manual	Tabla nativa
Reutiliza el prototipo actual	Casi entero	Solo el criterio de anonimización
Recomendado para	El piloto tal como está pedido	Si se adopta en más áreas

La regla que sostiene todo

REQ-UBI-01 de la spec original ya lo pedía: el sistema opera solo sobre una copia anonimizada, nunca sobre el original. MCP es la forma de cumplir esa regla en el diseño técnico, no solo en el papel — poniendo una frontera de código entre "quién soy" y "qué puedo ver" que ningún prompt puede saltear.

Para la reunión de equipo: empezar por A (evolución del prototipo), dejar B documentado como el paso siguiente si RRHH decide extender SubseBot a más áreas.