De chatbot a compañero de trabajo: un asistente de RR. HH. que actúa de forma segura

Pregunte a cualquier equipo de RR. HH. en qué se le va la semana y oirá la misma lista: «¿Cuántos días de permiso me quedan?», solicitudes de permiso por WhatsApp, perseguir a los responsables para que aprueben y «¿Me puedes enviar un certificado de experiencia?». Un chatbot de políticas ayuda con lo primero. No hace nada con el resto, y es ahí donde se van las horas.

Construimos AIVCJ HR para mostrar el siguiente paso: un asistente que responde y actúa. Comprueba tu saldo, solicita el permiso dentro de las reglas, lo envía a tu responsable con un resumen y redacta cartas de RR. HH., dentro de una empresa de ejemplo, Northwind Distribution, con 42 empleados entre una sede central y tres almacenes.

Por qué las respuestas por sí solas no reducen la carga de RR. HH.

Nuestra demo Knowledge responde preguntas de políticas citando la fuente. Eso elimina la pregunta «¿qué dice la política?». Pero el empleado todavía tiene que abrir un formulario, contar los días laborables, comprobar el preaviso, encontrar al aprobador y esperar. El trabajo se movió; no desapareció.

Dejar que una IA haga el trabajo plantea una preocupación legítima: ¿qué le impide aprobar sus propios errores, saltarse una regla por ayudar o mostrar a un empleado los datos de otro? Por eso diseñamos primero las salvaguardas.

Las salvaguardas

1. Las reglas viven en el código, no en el modelo. Un motor de políticas determinista decide cuántos días cuenta una solicitud (descansos semanales y festivos por ubicación, la regla del «sándwich» para las vacaciones), si se cumple el preaviso, si el empleado sigue en periodo de prueba, si el saldo alcanza y quién debe aprobar. La IA llama al motor y explica el resultado; no puede anularlo.
2. Nada ocurre sin un clic. Cada escritura —solicitar un permiso, cancelar una solicitud, abrir una petición de TI o de material— se muestra como una tarjeta de confirmación con los días contados, cada comprobación superada o fallida, el saldo antes y después y la ruta de aprobación. La solicitud se crea solo cuando la persona pulsa Confirmar, y el motor la vuelve a comprobar en ese momento.
3. Los permisos por rol los aplican las herramientas. Un empleado ve solo sus datos; un responsable, los de su equipo directo; solo RR. HH. puede redactar cartas para otros. La IA nunca aprueba: los responsables deciden en la pantalla de Aprobaciones.
4. Todo queda auditado. Cada llamada a una herramienta —quién, con qué rol, qué pidió la IA y si se ejecutó, la rechazaron las reglas o la confirmó una persona— queda en un registro de auditoría en el panel de RR. HH.

Qué puedes probar en la demo

• Como Priya (empleada): «Necesito permiso del 20 al 24 de octubre para la boda de mi hermana». El motor detecta que el 20 de octubre es festivo y el 24 un descanso semanal, cuenta 3 días, explica por qué el permiso por matrimonio no aplica a la boda de un hermano y muestra la tarjeta.
• Como Rohit (responsable): la solicitud espera con un resumen de IA: dentro de la política, Sneha está fuera el 21–22 de octubre, vacaciones 12 → 9. Apruébala y el saldo y la línea de tiempo de Priya se actualizan al instante.
• Como Anjali (RR. HH.): «Certificado de experiencia para Karan Verma»: redactado a partir de su ficha, editado en el navegador y descargado en PDF. Lo que la ficha no contiene se deja como marcador en lugar de inventarlo.
• Las preguntas de políticas («¿Puedo pasar el Uber a una reunión con un cliente?») usan el mismo motor de recuperación con citas que AIVCJ Knowledge.

Cada visitante recibe su propia copia de la empresa, así que nadie choca con las aprobaciones de otro, y se reinicia cada noche.

Medido, también donde falló

Probamos el asistente de principio a fin —mismo modelo, herramientas, motor y permisos que la demo en vivo— con dos conjuntos de solicitudes, cada una en una copia nueva de la empresa. Un caso solo pasa si el asistente termina exactamente con la acción correcta (o, correctamente, sin ninguna) y, cuando hay una respuesta de referencia, un juez de IA está de acuerdo con la respuesta.

• Conjunto guionizado (30 solicitudes), escrito junto con la app y usado al ajustarla, incluidas 12 que rompen una regla o un permiso: 30 de 30 correctas en la ejecución final, con las 12 infracciones rechazadas (ejecuciones anteriores durante el ajuste: 29 de 30).
• Conjunto ciego (20 solicitudes), escrito después por otra persona que nunca vio nuestros prompts ni el código —hinglish, erratas, fechas vagas («parso se 3 din»), dos peticiones en un mensaje—: 17 de 20 (85 %) en ambas ejecuciones.

Los resultados más útiles fueron los fallos. En una ejecución temprana, un empleado pidió un certificado de experiencia y el asistente, por ayudar, lo escribió en el chat: justo el tipo de documento que solo debe emitir RR. HH. En otra, preguntó «¿lo tramito?» en lugar de pasar por el motor una solicitud de 4 días de permiso personal, así que nunca dijo que el límite es de 3 días. Ambos casos se convirtieron en reglas explícitas. El conjunto ciego encontró tres más. Una empleada pidió cinco días de permiso personal: el motor lo rechazó correctamente (el límite es tres), pero el asistente preparó por su cuenta una tarjeta de vacaciones en lugar de preguntar primero; no se envió nada sin un clic, pero no debía cambiar el tipo de permiso. Un responsable preguntó por el saldo de «neha» y la búsqueda de nombres también encontró a «Sneha», así que hizo una pregunta innecesaria. El tercero fue un rechazo correcto que el juez de IA penalizó por omitir un detalle adicional. Corregimos los dos primeros; como esas correcciones salieron del conjunto ciego, no contamos como ciegas las ejecuciones posteriores.

Dos advertencias que preferimos decir antes que ocultar: la evaluación la hace una IA (de la misma familia de modelos que el asistente) y no está verificada por personas, y un conjunto de 50 solicitudes es pequeño. Toma las cifras como orientativas. Lo que las salvaguardas garantizan es estructural: diga lo que diga el modelo, una solicitud que rompe una regla no se puede enviar, porque decide el motor, no el modelo.

Implantarlo en tu HRMS

La demo funciona con el mismo stack que implantamos para clientes: Next.js, PostgreSQL con pgvector y Claude. En un despliegue real, el motor de políticas se configura a partir de tu política de permisos, las herramientas hablan con tu HRMS (Keka, Darwinbox, Zoho People o el tuyo propio) y el mismo asistente puede estar en WhatsApp. Un proyecto típico empieza con permisos y cartas para una ubicación, medido con cincuenta solicitudes reales de empleados, antes de ampliarse.

Prueba AIVCJ HR en vivo →