ia con factorial factorial rrhh integraciones

Conectar la IA con Factorial consiste en dar a un agente acceso controlado a la API pública del HRIS para que resuelva por sí solo el trabajo administrativo de recursos humanos: solicitudes de vacaciones, certificados y documentos, altas y onboarding, fichajes con incidencias y las consultas repetidas de los empleados. Factorial expone una API REST versionada por fecha —la versión mayor vigente en agosto de 2026 es 2026-04-01, con nombre en clave «Legendre»— que cubre empleados, contratos, ausencias, asistencia, nómina, ATS, desempeño, formación, documentos y webhooks, de modo que el agente no necesita ningún truco de navegador: trabaja contra endpoints oficiales.

Esto importa porque Factorial es el HRIS por defecto de miles de pymes españolas, y en casi todas ocurre lo mismo: el sistema está bien montado pero la persona de RRHH sigue siendo el intermediario humano entre el empleado y el software. Este artículo explica qué parte de ese intermediario puede asumir un agente, cómo se conecta sin abrir la puerta a datos que no debe ver, y dónde ponemos nosotros la raya.

¿Qué partes de Factorial puede tocar un agente?

Prácticamente todo el ciclo de vida del empleado, porque la API pública está organizada por dominios y cada uno tiene sus propios permisos. Según la documentación oficial de desarrolladores (apidoc.factorialhr.com, consultada en agosto de 2026), las superficies disponibles incluyen empleados y contratos, asistencia y fichajes, ausencias y vacaciones, conceptos de nómina, gastos, documentos, selección (ATS), desempeño, formación, proyectos y una superficie de aprobaciones, además de webhooks para reaccionar a eventos.

Esa organización por dominios es justo lo que permite un despliegue prudente. Un agente de consultas de empleado necesita leer ausencias, calendario y documentos propios; no necesita nómina, ni desempeño, ni ATS. Un agente de onboarding necesita crear empleado, asignar documentos y lanzar tareas; no necesita leer los salarios del resto de la plantilla.

Además de la API, Factorial publica su esquema OpenAPI y SDKs generados en varios lenguajes (Ruby, Python, Java, PHP, TypeScript y Node.js) en su repositorio público, lo que acorta bastante la fase de integración. En la práctica, el trabajo pesado del proyecto no está en hablar con Factorial: está en decidir qué puede hacer el agente y qué tiene que escalar.

¿Cómo se autentica el agente sin regalar acceso total?

Con el modelo de autenticación correcto para cada caso: una clave de API a nivel de empresa cuando el agente actúa como sistema (procesos de fondo, sincronizaciones, informes), y OAuth2 en nombre del usuario cuando el agente actúa por un empleado concreto y debe ver exactamente lo que ese empleado vería. Factorial soporta ambos y ofrece un catálogo amplio de scopes —más de treinta— para acotar el acceso por dominio.

La regla que aplicamos siempre es la del privilegio mínimo por caso de uso, no por proveedor. Es decir: no se crea "la clave del agente de IA" con todo activado, se crea una credencial por función con los scopes de lectura o escritura estrictamente necesarios. Si el agente de vacaciones no puede leer nóminas, la conversación sobre privacidad con el comité de empresa se acorta muchísimo.

Caso de uso	Autenticación	Acceso típico
Consultas del empleado ("¿cuántos días me quedan?")	OAuth2 en nombre del usuario	Lectura de ausencias, calendario y documentos propios
Solicitud y tramitación de ausencias	OAuth2 + aprobaciones	Lectura y escritura de ausencias del solicitante
Onboarding de una nueva incorporación	Clave de empresa	Escritura en empleados, contratos, documentos y tareas
Informes y cuadros de mando de RRHH	Clave de empresa (solo lectura)	Lectura agregada de asistencia, ausencias y plantilla
Avisos de incidencias de fichaje	Webhooks + clave de empresa	Lectura de asistencia, escritura de notificaciones

¿Qué casos de uso se pagan solos?

Los cuatro que concentran el volumen de tickets internos de cualquier departamento de RRHH: ausencias, documentos, onboarding y preguntas frecuentes. No son los más vistosos, pero son los que consumen el tiempo de la persona que debería estar haciendo selección, planes de desarrollo o clima laboral.

1. Ausencias y vacaciones. El empleado escribe en lenguaje natural ("me pido del 14 al 18 y el puente de diciembre") y el agente comprueba saldo, solapamientos con el equipo y política de la empresa, crea la solicitud en Factorial y la enruta al aprobador con el contexto ya resuelto. El responsable aprueba en un clic en lugar de abrir el HRIS a comprobar cosas.
2. Documentos y certificados. Certificados de empresa, justificantes de retenciones, copias de contrato, nóminas del mes pasado. Son peticiones de valor cero para quien las tramita y de valor alto para quien las pide; el agente las resuelve al instante contra los documentos que ese empleado tiene derecho a ver.
3. Onboarding. Cuando se firma una incorporación, el agente crea la ficha, lanza la checklist de documentación, agenda las sesiones de la primera semana, pide los accesos a IT y hace seguimiento de lo que falta. Un onboarding bien orquestado se nota en la productividad del primer mes y es de los procesos más agradecidos de automatizar.
4. Consultas repetidas. Política de teletrabajo, retribución flexible, cómo funciona el fichaje, qué pasa con las horas del puente. El agente responde citando la política interna vigente y, cuando no la tiene clara, escala en lugar de improvisar.

Estos cuatro se apoyan en la misma arquitectura que describimos en nuestra guía de automatizar RRHH y selección con IA: lo que cambia aquí es que el sistema de registro es Factorial y el agente escribe en él, no en un Excel paralelo.

¿Dónde vive el agente: en Factorial o en el chat de la empresa?

En el chat, casi siempre. El empleado que quiere saber cuántos días le quedan no va a abrir el HRIS: va a preguntar por Slack, por Teams o por WhatsApp, que es donde ya está. El agente vive en esa conversación y usa Factorial como fuente de verdad por detrás.

Esta decisión de diseño tiene un efecto medible en la adopción. Un portal de autoservicio bien hecho reduce tickets un poco; un agente en el canal donde la gente ya escribe los reduce mucho más, porque elimina el paso de "entrar a otro sitio". Cómo se monta esa capa conversacional la explicamos en agentes de IA en Slack y Teams.

El segundo efecto es de trazabilidad: cada respuesta del agente queda registrada junto con la consulta que hizo a Factorial. Cuando alguien discute un saldo de vacaciones o una fecha de contrato, hay un rastro completo de qué se preguntó, qué devolvió el sistema y qué se respondió.

¿Qué NO deberías automatizar en RRHH?

Las decisiones sobre personas. Un agente puede preparar, consultar, redactar y tramitar; no debe decidir a quién se contrata, a quién se despide, quién promociona ni cómo se evalúa a nadie. Esta no es solo nuestra postura: es la dirección que marca la normativa europea.

• Decisiones de contratación y despido. El agente puede cribar por requisitos objetivos y preparar la información; la decisión y su justificación son humanas y deben poder explicarse.
• Evaluaciones de desempeño. Redactar un borrador a partir de evidencias que el responsable aporta, sí. Puntuar a una persona, no.
• Datos de salud y bajas médicas. Categoría especial bajo el RGPD. El agente puede registrar que existe un parte, no leer ni procesar su contenido clínico.
• Conflictos laborales y disciplinarios. Detectar y escalar, sí; responder en automático, nunca.

Sobre el marco legal conviene tener dos fechas presentes. Desde el 2 de agosto de 2026 se aplican las obligaciones de transparencia del artículo 50 del Reglamento Europeo de IA: si un empleado habla con un agente, hay que decírselo. Y los sistemas de IA en empleo y gestión de trabajadores están en el Anexo III como alto riesgo, con un calendario que, tras la revisión del paquete ómnibus digital, sitúa su exigibilidad en diciembre de 2027 (dato a agosto de 2026; conviene confirmar el texto final antes de presupuestar cumplimiento). Traducción práctica: un agente que responde consultas y tramita papeleo está fuera de esa categoría, y uno que puntúa candidatos o empleados, dentro.

¿Cuánto cuesta y cuánto tarda el proyecto?

Una integración acotada —consultas de empleado, ausencias y documentos, con el agente en Slack o Teams— es un proyecto de 4 a 8 semanas y entra en la horquilla de 15.000 a 40.000 € típica de un agente a medida en pyme, con la mayor parte del coste en el diseño de permisos, la carga de las políticas internas y las pruebas, no en la conexión técnica. El mantenimiento anual se mueve entre el 10% y el 20% de la construcción y cubre cambios de la API, actualizaciones de políticas y ajustes de comportamiento.

Ampliar después a onboarding e informes suele costar menos que el primer bloque, porque la autenticación, la capa de permisos y el canal ya están montados. Ese es el patrón habitual: el primer caso de uso paga la infraestructura y los siguientes se aprovechan de ella.

Antes de firmar nada, conviene tener resuelto el mapa de permisos: quién puede preguntar qué, qué puede escribir el agente y qué escala siempre a una persona. Ese diseño es el que separa un despliegue tranquilo de un incidente, y lo tratamos a fondo en gobernanza de agentes de IA y permisos. Si prefieres plantearlo con un equipo que integra este tipo de sistemas cada semana, así trabajamos desde nuestra agencia de inteligencia artificial en Madrid.

Preguntas frecuentes

¿Necesito un plan concreto de Factorial para usar la API?

El acceso a la API pública y a las integraciones depende del plan contratado y de los módulos activos, así que el primer paso del proyecto es confirmarlo con tu contacto de Factorial o en el panel de administración. Lo que sí es común a todos los casos es que necesitas permiso de administración para generar credenciales: no es algo que pueda montar un empleado por su cuenta.

¿El agente puede ver el sueldo de mis empleados?

Solo si le das scopes de nómina, y para la mayoría de casos de uso no hacen falta. Nuestra recomendación por defecto es excluir nómina y desempeño de las credenciales del agente conversacional y crear, si algún día hace falta, una credencial separada y auditada para informes agregados.

¿Qué pasa si Factorial cambia su API?

Es una API versionada por fecha, lo que significa que las versiones antiguas siguen funcionando mientras estén soportadas y las novedades llegan en versiones nuevas. Aun así, el mantenimiento anual existe precisamente para esto: revisar avisos de deprecación, migrar de versión y probar que nada se ha roto antes de que lo note un empleado.

¿Sirve esto si además usamos otro ERP o un CRM?

Sí, y suele ser lo normal: el mismo agente puede consultar Factorial para lo laboral y otro sistema para lo económico, siempre que cada conexión tenga sus propios permisos. Lo que no recomendamos es un único agente todopoderoso con acceso a todo; es más seguro y más fácil de mantener un conjunto de agentes especializados.

¿Cómo evito que el agente invente una política que no existe?

Obligándolo a responder solo con las políticas cargadas y a citar la fuente, y haciendo que escale cuando no encuentra respaldo documental. En la práctica, el proyecto suele destapar un problema previo: que las políticas internas están desactualizadas o dispersas. Ordenarlas es parte del trabajo, y es una de esas tareas que la empresa lleva años posponiendo hasta que la automatización la obliga.