Conclusiones clave
- El control de acceso es arquitectura, no una funcionalidad. Un chatbot interno autoalojado debe delimitar lo que cada sesión puede recuperar según la identidad del empleado — aplicado en la capa de recuperación y el proveedor de identidad, nunca pidiéndoselo amablemente al modelo.
- Los contenidos de RR. HH. son un argumento aún más fuerte para autoalojar que casi cualquier otro caso de uso interno. Bandas salariales, detalles médicos o de baja, y expedientes disciplinarios son exactamente los datos para los que una API de LLM de terceros añade un procesador innecesario.
- Las plataformas de construcción visual (Dify, Flowise, Open WebUI) son el camino más rápido a una app de chat interna, no un proyecto desde cero — consulta las reseñas dedicadas para el detalle de cada herramienta; esta guía cubre el patrón de despliegue específico para helpdesk/RR. HH. internos.
- El SSO es la frontera de identidad de la que depende todo el modelo de control de acceso. El chatbot nunca debe mantener su propia base de usuarios separada para decidir quién ve qué — debe consumir claims de grupo/rol del proveedor de identidad existente.
- El helpdesk de IT y las preguntas de RR. HH. son cargas distintas con perfiles de riesgo distintos. Una respuesta incorrecta sobre un reseteo de VPN es una molestia; una respuesta incorrecta sobre la política de baja médica es un problema de cumplimiento y de confianza — diséñalos y pruébalos por separado.
- La tasa de desviación solo tiene sentido medida contra tickets realmente evitados, no contra el volumen de uso del chatbot — sigue los recuentos de creación de tickets antes/después para las categorías que atiende el bot, no el número de sesiones.
📍 En una frase
Despliega chatbots internos de helpdesk de IT y RR. HH. sobre un LLM autoalojado con una plataforma visual como Dify, Flowise u Open WebUI, aplicando el control de acceso por empleado mediante SSO y el alcance de recuperación en lugar del modelo.
💬 En términos simples
El chatbot en sí nunca decide quién ve qué — eso lo hacen tu sistema de acceso y tus filtros de documentos. Por eso la pregunta de RR. HH. de un empleado jamás muestra el salario o la baja médica de otro.
Datos rápidos
- Capa de control de acceso: se aplica en la recuperación y la identidad, no en el prompt del modelo — una instrucción de prompt no es una frontera de seguridad.
- Categorías de datos de RR. HH. más sensibles: salario/compensación, detalles médicos y de baja, expedientes disciplinarios y evaluaciones de desempeño.
- Protocolos SSO habituales para este patrón: OpenID Connect (OIDC) y SAML — confirma qué soporta tu versión y edición concreta de la plataforma autoalojada antes de fijar la arquitectura.
- Plataformas de despliegue con un patrón activo de app de chat interna: Dify, Flowise y Open WebUI — todas autoalojables, todas reseñadas en profundidad en otra parte de este sitio.
- La desviación es una métrica de volumen de tickets, medida contra un período de referencia de la misma categoría de ticket, no una métrica de sesiones o satisfacción.
Bot de helpdesk de IT vs bot de políticas de RR. HH.: cargas distintas
Trata el helpdesk de IT y RR. HH. como dos despliegues de bot separados que comparten infraestructura, no como un "asistente interno" genérico. Difieren en sensibilidad de datos, granularidad de control de acceso y tolerancia a una respuesta incorrecta.
| Dimensión | Bot de helpdesk de IT | Bot de políticas/beneficios de RR. HH. |
|---|---|---|
| Consulta típica | "Resetear mi token VPN" / "Por qué mi portátil va lento" | "¿Cuánto días de vacaciones me quedan?" / "Cómo funciona el permiso parental" |
| Sensibilidad de los datos | Baja-moderada — metadatos de dispositivo/cuenta | Alta — salario, médico, bajas, disciplinario |
| Alcance de acceso necesario | Sobre todo a nivel documento (manuales, políticas) | Nivel documento + nivel registro por empleado |
| Coste de una respuesta incorrecta | Molestia, reabrir el ticket | Riesgo de cumplimiento, daño a la confianza |
| Métrica de éxito | Tasa de desviación en categorías definidas | Precisión al citar políticas + tasa de escalado |
Por qué el contenido de RR. HH. se beneficia especialmente del autoalojamiento
Un chatbot de RR. HH. no es "un chatbot que casualmente habla de RR. HH." — tarde o temprano recibirá una pregunta que un empleado nunca le diría a un extraño. Comparaciones de salario, una situación médica familiar detrás de una solicitud de baja, o una pregunta motivada por un proceso disciplinario en curso son tráfico normal de un bot de RR. HH., no casos límite.
- Enviar datos de salario y compensación a una API de LLM de terceros añade un procesador externo para información que la mayoría de empresas restringe internamente a RR. HH. y a los managers directos.
- Los detalles médicos y de baja (una solicitud vinculada a una baja médica, una pregunta sobre adaptación por discapacidad) son categorías especiales de datos personales en la mayoría de marcos de privacidad — consulta RAG local conforme al RGPD para el conjunto de controles que aplica cuando cualquier pipeline RAG toca esta categoría.
- Los expedientes disciplinarios y de evaluación de desempeño conllevan exposición legal directa si se gestionan mal — un chatbot de RR. HH. capaz de recuperar este contenido necesita el alcance de acceso más estricto de todo el despliegue.
- Mantener la inferencia y la recuperación en infraestructura propia no basta por sí solo para cumplir el RGPD, los requisitos de codeterminación del comité de empresa o las normas sectoriales — retira un procesador del mapa de flujo de datos, no todas las obligaciones.
- El beneficio práctico más allá del cumplimiento: los equipos de RR. HH. pueden ser mucho más francos sobre qué contenido incluir en la base de conocimiento cuando este nunca sale de la infraestructura de la empresa — eso es lo que hace al bot realmente útil en vez de una FAQ aguada.
Control de acceso: el requisito que hace o deshace este despliegue
El requisito más difícil en un bot interno de RR. HH./IT no es la calidad del modelo — es garantizar que la sesión del Empleado A nunca pueda recuperar el saldo de vacaciones, la nota salarial o el expediente de RR. HH. del Empleado B. Fallar aquí una sola vez convierte el despliegue en un pasivo, no en una ganancia de productividad. Acertarlo lo convierte en el argumento más sólido de todo el caso build-vs-buy.
- Aplica el alcance en la recuperación, no en el prompt. Una instrucción de prompt de sistema como "responde solo sobre los datos del usuario actual" es una barrera blanda que el modelo puede incumplir ante una formulación adversarial o incluso accidental. Un filtro de recuperación que estructuralmente no puede devolver la fila de otro empleado es una frontera dura.
- Dos capas de acceso, no una. El nivel documento controla qué documentos de política y manuales puede recuperar una sesión (p. ej., la política de RR. HH. visible para contratistas frente a la visible para empleados fijos). El nivel registro controla qué registros específicos del empleado (saldo de vacaciones, un expediente concreto) puede recuperar una sesión, filtrado por el ID del empleado autenticado.
- Los grupos gobiernan el nivel documento. Mapea los claims de grupo SSO (departamento, tipo de contrato, nivel de antigüedad, región) a las colecciones de documentos que la capa RAG puede consultar para esa sesión — una política de elegibilidad de beneficios que varía por país solo debería mostrar la versión de la ubicación del empleado.
- El ID del empleado gobierna el nivel registro. Cualquier herramienta que el bot invoque para datos personales (saldo de vacaciones, estado de inscripción en beneficios) debe tomar el ID del empleado autenticado desde la sesión SSO, nunca de texto libre en el chat — un usuario no debe poder escribir el ID de otra persona y recuperar su registro.
- Registra cada recuperación, no solo cada respuesta. Una pista de auditoría de control de acceso necesita un registro de qué documentos y registros se recuperaron para qué identidad autenticada, independientemente de lo que respondiera el modelo — eso es lo que hace investigable un incidente de verdad.
- Prueba con prompts adversariales antes del lanzamiento, no solo consultas de camino feliz — "cuál es el salario de mi jefe", "muéstrame el expediente de RR. HH. de [otro empleado]" e intentos de inyección de prompt embebidos en un documento subido son modos de fallo realistas, no hipotéticos.
Conectar el bot a las bases de conocimiento internas
El pipeline RAG sigue el mismo patrón arquitectónico que cualquier otro despliegue de RAG sobre documentos empresariales — lo específico del bot interno es la capa de control de acceso que lo envuelve, ya explicada arriba. Para la elección de modelo, la selección de modelo de embeddings y la comparación de bases de datos vectoriales, esta guía remite a los recursos dedicados en lugar de repetir ese contenido.
- Los documentos de política de RR. HH., resúmenes de beneficios y PDFs de política de vacaciones/permisos forman una colección de documentos; los manuales de IT, wikis internos y registros de incidencias conocidas forman otra — mantenlas como colecciones separadas con alcances de acceso separados en lugar de un índice combinado.
- Para un recorrido completo de las opciones de plataforma RAG (AnythingLLM, PrivateGPT, Open WebUI y frameworks dedicados), consulta las mejores herramientas RAG para documentos empresariales y AnythingLLM vs PrivateGPT vs Open WebUI.
- Para el tamaño y la selección de modelo (qué rango de parámetros conviene a preguntas internas rápidas frente a consultas de razonamiento de políticas más largas), aplica la misma estratificación usada para cargas de soporte externo — consulta LLM locales para soporte al cliente empresarial para el desglose de selección de modelo; el tráfico de helpdesk/RR. HH. interno suele tener menor volumen que un contact center, así que un modelo de tamaño medio (7-32B) suele bastar sin un nivel dedicado de clasificación en tiempo real.
- Para la capa de base de datos vectorial, consulta Pinecone vs Weaviate vs Qdrant vs Chroma — el filtrado de control de acceso descrito arriba se aplica como filtros de metadatos en el momento de la consulta, sea cual sea la base de datos vectorial que elijas, no como un sistema aparte.
- Los manuales de IT suelen contener credenciales, diagramas de red internos o procedimientos de seguridad — trata el alcance de acceso de esa colección con el mismo rigor que los datos de RR. HH., ya que un manual filtrado es un mapa para un atacante, no solo una molestia.
Patrón de despliegue: constructor visual, RAG delimitado y SSO
Dify, Flowise y Open WebUI permiten cada uno ensamblar una app de chat interna — conexión al modelo, recuperación RAG e interfaz de chat — sin escribir la capa de orquestación desde cero. El patrón siguiente es, a nivel estructural, el mismo en los tres; la configuración específica de cada herramienta, la licencia y el estado actual de funcionalidades se cubren en las reseñas dedicadas, no aquí.
- 1Elige el constructor según las necesidades de tu app interna, no por capacidad general
Why it matters: Open WebUI está orientado al chat y trae de fábrica grupos de usuarios y control de acceso a modelos, lo que se traduce directamente en el alcance a nivel documento que necesita este caso de uso. Dify añade una capa LLMOps/agentes más completa si el bot necesita invocar herramientas internas (crear un ticket, consultar el saldo de vacaciones) más allá de un simple Q&A. Flowise es un constructor de flujos visual más ligero — consulta la [reseña de Dify](/es/power-local-llm/dify-ai-workflow-builder-review) y la [reseña de Flowise](/es/power-local-llm/flowise-ai-visual-workflow-builder-review) para el estado actual de funcionalidades y mantenimiento antes de elegir. - 2Levanta el modelo detrás de un endpoint compatible con OpenAI
Why it matters: Servir a través de vLLM o un servidor compatible con OpenAI similar mantiene portable la capa del constructor si cambia el modelo subyacente — la app de chat y la elección de modelo quedan desacopladas. - 3Construye dos colecciones de documentos con alcances distintos: RR. HH. e IT
Why it matters: Nunca combines el conocimiento de RR. HH. e IT en un solo índice con una única política de acceso — tienen sensibilidad y público objetivo distintos. - 4Conecta el SSO (OIDC/SAML) como capa de autenticación
Why it matters: El chatbot no debería mantener su propio sistema de login — debe consumir identidad y claims de grupo del proveedor de identidad existente de la empresa, la fuente de verdad de a qué departamento o rol pertenece cada persona. - 5Mapea los claims de grupo al alcance a nivel documento, y el ID del empleado al alcance a nivel registro
Why it matters: Este es el paso que realmente impide la exposición de datos entre empleados — ver la sección de Control de acceso arriba para el modelo de dos capas en detalle. - 6Pilota con agent-assist antes de la desviación completa
Why it matters: Haz que personal de RR. HH./IT revise los borradores de respuesta del bot durante un período definido antes de dejarlo responder directamente a los usuarios finales — el mismo despliegue gradual que reduce el riesgo en cualquier implementación RAG. - 7Registra las recuperaciones y define una vía de escalado
Why it matters: Cualquier consulta que la capa RAG no pueda responder con una coincidencia de fuente fiable y delimitada debería enrutarse a una persona — un ticket de helpdesk o un contacto de RR. HH. — en lugar de dejar que el modelo adivine.
Patrón de integración SSO
El SSO no es una funcionalidad de comodidad opcional para un bot interno — es la frontera de identidad sobre la que se construye todo el modelo de control de acceso. Sin él, el chatbot o bien no tiene forma fiable de saber quién pregunta, o mantiene un segundo sistema de identidad paralelo que inevitablemente se desincroniza del real.
- OpenID Connect (OIDC) y SAML son los dos protocolos habituales para conectar una app de chat autoalojada con un proveedor de identidad corporativo (Okta, Azure AD/Entra ID, Google Workspace y similares) — qué protocolos y con qué profundidad de integración varía según la plataforma de construcción y la edición, así que confirma el soporte actual directamente en tu versión concreta antes de acotar el proyecto.
- El proveedor de identidad debe ser la única fuente de verdad para la pertenencia a grupos y departamentos — el chatbot lee esos claims al iniciar la sesión en lugar de mantener un directorio duplicado.
- Los claims a nivel de sesión (departamento, tipo de contrato, antigüedad, región) determinan qué colecciones de documentos puede consultar la capa RAG para esa sesión, tal como se describe en la sección de Control de acceso.
- Para cualquier consulta de datos personales (saldo de vacaciones, estado de beneficios), la herramienta que invoca el bot debe tomar el ID del empleado del token de sesión SSO autenticado — nunca de texto escrito por el usuario en el chat — para que nadie pueda escribir el ID de otra persona y recuperar su registro.
- La política de expiración de sesión y reautenticación del chatbot debe coincidir con la política de sesión SSO ya existente en la empresa, no con una política separada y más laxa fijada a nivel de la app de chat.
Medir con honestidad la desviación de tickets de IT
La "tasa de desviación" es fácil de inflar contando sesiones de chatbot en lugar de tickets realmente evitados — sin una referencia real, el número no significa nada. En bots de RR. HH., la métrica equivalente es la precisión de las respuestas y una tasa de escalado adecuada, no la desviación, porque la mayoría de interacciones de RR. HH. no deberían automatizarse por completo de extremo a extremo.
- Define antes del lanzamiento las categorías de ticket que el bot debe afectar (reseteo de contraseña, acceso VPN, solicitud de software, preguntas frecuentes de cómo hacer algo), y saca un recuento de referencia de creación de tickets para esas categorías en un período comparable anterior.
- Un ticket desviado es uno que no se creó porque la pregunta del empleado se resolvió en el chat — no una sesión de chat que simplemente ocurrió, y no una sesión que igualmente terminó con la apertura de un ticket.
- Reporta la desviación como un cambio porcentual en el volumen de creación de tickets para las categorías definidas, junto con la tasa de precisión de respuestas del bot en esas categorías — un número de desviación alto junto a una precisión baja suele significar que los empleados dejaron de preguntar, no que fueron atendidos.
- En RR. HH., sigue la tasa de escalado (con qué frecuencia el bot deriva correctamente a una persona en vez de responder) como señal principal de calidad — un bot que nunca escala ante preguntas ambiguas o sensibles es un riesgo mayor que uno que escala demasiado.
- Reajusta la referencia periódicamente; el volumen de tickets de una categoría baja de forma natural tras un cambio de política o una corrección de sistema ajena al bot, y atribuirle esa bajada al bot sobreestima su impacto.
Errores comunes
La mayoría de los despliegues de bot interno fallidos fallan en el alcance del control de acceso, no en la elección del modelo o las herramientas.
- Confiar en una instrucción de prompt de sistema ("responde solo sobre los datos del usuario actual") como mecanismo de control de acceso en lugar de aplicarlo estructuralmente en la recuperación — esto falla ante formulaciones adversariales y, a veces, incluso ordinarias.
- Combinar contenido de RR. HH. e IT en un índice compartido con una única política de acceso, en vez de dos colecciones con acceso separado y correctamente delimitado.
- Saltarse el SSO y construir "por ahora" un login separado o una app de chat de acceso abierto, que o bien carece de una señal de identidad fiable o se acumula como deuda técnica sin gestionar.
- Lanzar la desviación de autoservicio de RR. HH. en categorías sensibles (bajas, disciplinario, compensación) antes de que el bot tenga un historial probado en categorías de helpdesk de IT de menor riesgo.
- Medir la desviación por el volumen de uso del chatbot en lugar de los recuentos reales de creación de tickets contra una referencia, lo que exagera el ROI ante la dirección.
- No probar prompts adversariales (pedir datos de otro empleado, inyección de prompt vía un documento subido) antes del lanzamiento.
Fuentes
- Especificación de OpenID Connect — el protocolo SSO referenciado para el alcance de acceso basado en claims de identidad.
- Especificación SAML 2.0, OASIS — el protocolo SSO alternativo de uso común en el entorno empresarial.
- Documentación de Open WebUI — funcionalidades de grupos de usuarios y control de acceso a modelos referenciadas para el patrón de despliegue.
- Documentación de vLLM — capa de servicio compatible con OpenAI referenciada para el paso de conexión al modelo.
Preguntas frecuentes
¿Cómo se evita que un empleado vea los datos de RR. HH. de otro a través del chatbot?
Aplicando el alcance de acceso en la capa de recuperación y el proveedor de identidad, no en el prompt del modelo. El alcance a nivel documento (qué documentos de política puede consultar una sesión) lo gobiernan los claims de grupo SSO; el alcance a nivel registro (qué registros específicos del empleado, como el saldo de vacaciones, puede consultar una sesión) lo gobierna el ID del propio empleado autenticado, tomado del token de sesión SSO — nunca de texto escrito en el chat. Una instrucción de prompt por sí sola no es una frontera de seguridad y puede fallar ante formulaciones tanto adversariales como ordinarias.
¿Pueden Dify, Flowise u Open WebUI aplicar este control de acceso por sí solos?
Open WebUI cuenta con funcionalidades nativas de grupos de usuarios y control de acceso a modelos que encajan bien con el alcance a nivel documento. Dify y Flowise proporcionan la capa de workflow/orquestación sobre la que tú construyes la lógica de filtrado de recuperación y claims de identidad; el filtrado a nivel registro por empleado descrito en esta guía es algo que configuras sobre la integración RAG e identidad de la plataforma, no una funcionalidad que llega ya construida para cada caso límite — verifica las capacidades actuales de tu versión autoalojada concreta frente a la reseña de Dify y la reseña de Flowise.
¿Por qué deberían los datos de un chatbot de RR. HH. mantenerse fuera de una API de LLM en la nube de terceros?
Porque el contenido de RR. HH. incluye habitualmente cifras de salario y compensación, detalles médicos y de baja, y registros disciplinarios o de evaluación de desempeño — categorías que la mayoría de empresas restringen internamente a RR. HH. y managers directos, y que gozan de protección reforzada en la mayoría de marcos de privacidad. Enviar ese contenido a una API de terceros añade un procesador externo para datos que la mayoría de organizaciones restringen específicamente a nivel interno. El autoalojamiento retira ese procesador del mapa de flujo de datos, aunque por sí solo no satisface todas las obligaciones de cumplimiento aplicables — consulta la guía dedicada RAG local conforme al RGPD para el conjunto de controles requerido.
¿Cuál es la diferencia entre un bot de helpdesk de IT y un bot de políticas de RR. HH.?
Son cargas distintas con perfiles de riesgo distintos y deberían construirse como despliegues separados que comparten infraestructura, no como un "asistente interno" combinado. Las consultas de helpdesk de IT (reseteo de contraseña, acceso VPN) tienen menor sensibilidad de datos y menor coste ante una respuesta incorrecta. Las consultas de RR. HH. (saldo de vacaciones, política de bajas, beneficios) tienen mayor sensibilidad de datos, necesitan alcance a nivel registro por empleado además del nivel documento, y una respuesta incorrecta o filtrada es un problema de cumplimiento y confianza, no una simple molestia.
¿Cómo se integra el SSO con un chatbot interno autoalojado?
El chatbot autentica al empleado a través del proveedor de identidad existente de la empresa vía OpenID Connect o SAML, en lugar de mantener su propio sistema de login. El proveedor de identidad transmite claims de grupo, departamento y rol a la sesión al iniciar sesión, y la capa RAG usa esos claims para filtrar qué colecciones de documentos puede consultar esa sesión — el mecanismo del que depende todo el modelo de control de acceso. El soporte exacto de protocolos y la profundidad de integración varían según la plataforma de construcción y la edición, así que confirma la capacidad actual antes de acotar el proyecto.
¿Cómo se mide con precisión la desviación de tickets de IT?
Define antes del lanzamiento las categorías de ticket concretas que el bot debe afectar, saca un recuento de referencia de creación de tickets para esas categorías en un período comparable anterior, y reporta la desviación como el descenso porcentual en la creación de tickets para esas categorías tras el lanzamiento — junto con la tasa de precisión de respuestas del bot. Contar sesiones de chatbot en lugar de tickets realmente evitados infla el número; una cifra de desviación alta junto a una precisión baja suele significar que los empleados dejaron de preguntar, no que fueron atendidos.
¿Debería un chatbot de RR. HH. automatizar por completo las respuestas, o siempre debería intervenir una persona?
La mayoría de despliegues de RR. HH. deberían empezar con agent-assist — el bot redacta una respuesta con cita de política, y un miembro del equipo de RR. HH. la revisa antes de que llegue al empleado — y expandirse a autoservicio directo solo para las categorías de menor riesgo y mejor definidas (consulta general de saldo de vacaciones, FAQ de política estándar). Las categorías sensibles (baja por una situación médica, asuntos disciplinarios, preguntas de compensación) deberían derivarse a una persona por diseño, con la tasa de escalado seguida como métrica de calidad principal en lugar de tratarse como un fallo de la automatización.
¿Qué tamaño de modelo es adecuado para un chatbot interno de helpdesk o RR. HH.?
El tráfico de helpdesk y RR. HH. internos suele tener menor volumen que un contact center externo, así que un modelo de tamaño medio en el rango de 7-32B parámetros (por ejemplo Qwen2.5/Qwen3 o Mistral) suele bastar tanto para Q&A basado en recuperación como para consultas de razonamiento de políticas, sin necesitar el nivel dedicado de clasificación en tiempo real con modelo pequeño que sí requiere un contact center de chat en vivo de alto volumen. Consulta LLM locales para soporte al cliente empresarial para el desglose más completo de estratificación de modelos, que aplica aquí con requisitos de volumen más bajos.
¿Necesitan los manuales de IT el mismo rigor de control de acceso que los datos de RR. HH.?
Sí. Los manuales de IT suelen contener credenciales, topología de red interna o procedimientos de seguridad — contenido que funciona como mapa para un atacante si se filtra al público equivocado, aunque no sea dato personal en el sentido de los registros de RR. HH. Delimita el acceso a los manuales por rol y necesidad (p. ej., personal de IT y niveles de escalado específicos) con el mismo mecanismo de control de acceso a nivel documento que usas para el contenido de RR. HH., en lugar de tratar el conocimiento de IT como inherentemente de menor riesgo.