Agentes de IA internos: RR.HH. y soporte de IT (y por qué no conviene mezclarlos con el de clientes)

Si en tu empresa ya tienes un agente de IA respondiendo a clientes, es cuestión de tiempo para que alguien de RR.HH. pregunte si se puede usar lo mismo puertas adentro. La respuesta corta es sí. La completa es que no debería ser el mismo agente, y esa diferencia es la que separa un proyecto que funciona de uno que un empleado deja de usar a la segunda mala respuesta.

El caso de uso interno no es una curiosidad. Un agente que atiende empleados enfrenta el mismo problema que uno que atiende clientes (preguntas repetidas, información dispersa en carpetas y canales de Slack que nadie revisa) con una diferencia que cambia todo: la audiencia. Un cliente que no encuentra respuesta se va a la competencia. Un empleado que no encuentra respuesta le escribe a un compañero de RR.HH., que deja lo que está haciendo para contestar por sexta vez esa semana cuántos días de licencia por maternidad corresponden.

Por qué el mismo agente de soporte no sirve para esto

La tentación es reciclar el agente que ya funciona con clientes: cambiarle el nombre, agregarle unos documentos de RR.HH. y listo. No funciona, y no es un detalle menor de configuración. Un agente de soporte a clientes está entrenado con instrucciones, tono y límites pensados para alguien de afuera que no conoce tu empresa. Un agente de RR.HH. necesita lo contrario: puede asumir contexto interno (el nombre del sistema de nómina, la política de vacaciones vigente este año, a quién escalar según el área), y sobre todo necesita un límite de confidencialidad que un agente de cara a clientes nunca tuvo que resolver.

La regla que aplica acá es la misma que separa a un agente de ventas de uno de soporte: un agente por audiencia, no por tema. Si mezclas preguntas de clientes con preguntas de empleados en el mismo agente, terminas con un asistente que responde de más a unos o de menos a otros, porque el conocimiento que carga y el tono con que contesta tienen que servir a las dos audiencias a la vez. En la práctica, sirve mal a ambas.

Las preguntas que se repiten en cualquier equipo

Antes de pensar en la herramienta, mira qué preguntas ocupan el tiempo del equipo de RR.HH. y de IT interno sin necesitar criterio humano para responderlas:

• Cuántos días de vacaciones le quedan a alguien y cómo se piden.
• Qué cubre la obra social o el seguro médico de la empresa, y cómo se agrega un familiar.
• Cómo se pide el reintegro de un gasto y qué comprobantes hacen falta.
• Dónde está el instructivo para configurar el correo corporativo en un celular nuevo.
• Cómo se resetea la contraseña de una herramienta sin abrir un ticket de IT que tarda un día en atenderse.

Ninguna de estas cinco necesita que una persona piense la respuesta. Todas necesitan que la respuesta correcta exista en algún lado y que alguien la escriba siempre igual, sin errores de una vez a la otra. Es exactamente el tipo de trabajo que un agente de IA hace bien, y el tipo de trabajo que hoy consume horas de gente que podría estar resolviendo la excepción real: el caso disciplinario, la negociación de un beneficio puntual, la falla de infraestructura que sí necesita un ingeniero.

Cómo se arma esto en la práctica

En MelonHelp puedes tener varios agentes en el mismo workspace, cada uno con sus propias instrucciones, su propio conocimiento y su propio link de chat. Para separar el agente de clientes del de RR.HH. no hace falta contratar otra herramienta ni duplicar la cuenta: se crea un segundo agente con instrucciones específicas para esa audiencia, y se organiza el conocimiento en categorías (por ejemplo “Clientes” y “RR.HH.”) que se asignan a cada agente con un clic. El de RR.HH. solo ve lo que está en su categoría; el de clientes, lo suyo. No hay riesgo de que uno le conteste a un cliente con una política interna, ni al revés.

Cada agente publicado tiene además su propio link de chat: el de soporte a clientes va en tu web pública, y el de RR.HH. lo compartes solo en tu intranet o en el canal interno de Slack. Y como cada agente reporta sus conversaciones por separado, el equipo de RR.HH. puede ver qué preguntas le hacen sin que esos datos se mezclen con las métricas de atención a clientes que mira el equipo de soporte.

Un problema típico cuando esto se configura mal: dos agentes responden distinto a la misma pregunta porque no comparten las mismas fuentes. Si eso pasa, la primera revisión es qué categoría de conocimiento tiene asignada cada uno, no el prompt.

Dónde tiene que intervenir un humano, siempre

Acá el límite es más estricto que en un agente de cara a clientes. Hay preguntas que un agente de RR.HH. no debería intentar responder nunca, aunque tenga la información cargada:

• Cualquier dato de otra persona. Sueldo, evaluación de desempeño, motivo de una licencia médica. Que el agente tenga acceso técnico a un documento no significa que deba mostrarlo ante cualquier pregunta; esa información se comparte por canal formal, no por chat.
• Situaciones disciplinarias o de conflicto. Un reclamo de acoso, una desvinculación, cualquier caso donde haya una persona en el medio con un problema real. Esto escala directo a un humano: hay conversaciones donde el costo de una respuesta automática mal calibrada no se mide en tickets, se mide en confianza.
• Cualquier duda legal o de cumplimiento normativo local. Un agente puede citar la política de la empresa, pero no puede opinar sobre qué dice la ley laboral de tu país en un caso específico. Eso se deriva a RR.HH. o a legal, sin intento previo.

La lógica de escalación es la misma que explicamos para cuándo un agente de IA debe escalar a un humano, con el límite corrido un paso más hacia la prudencia.

Lo que esto no reemplaza

Un agente de RR.HH. bien configurado saca de encima las preguntas repetidas, no la parte humana del trabajo. Onboarding de una persona nueva, una conversación difícil, la negociación de condiciones: nada de eso se automatiza y no debería intentarse. El objetivo es que el tiempo de RR.HH. se vaya a esas cosas, no a explicar por sexta vez cómo se carga un recibo médico.

Tampoco tiene sentido en todos los tamaños de equipo. Si RR.HH. en tu empresa es una persona que además conoce a cada empleado por nombre, la fricción de armar y mantener un segundo agente probablemente pesa más que lo que ahorra. El caso se vuelve claro cuando el volumen de preguntas repetidas ya justifica un sistema de tickets para atención a clientes: si tu equipo ya llegó a ese punto puertas afuera, es una buena señal de que puertas adentro también hay terreno ganado.

Cuánto conocimiento hace falta para arrancar

No hace falta documentar todo desde cero. La misma lógica que usamos para alimentar la base de conocimiento de un agente de IA aplica acá: si ya existe un manual del empleado, una guía de onboarding o un instructivo de IT, esa es la base. Lo que falta después son las preguntas que nunca se escribieron en ningún lado, y esas se suman con el mismo ciclo de lecciones aprobadas: un empleado pregunta algo que el agente no sabe, escala a una persona, la persona resuelve, y esa respuesta se convierte en conocimiento nuevo solo si alguien la aprueba.

El plan gratuito de MIA alcanza para arrancar con un solo agente (el de clientes, por ejemplo) y confirmar que el modelo funciona. Para separar clientes de RR.HH. y de IT interno necesitas un plan que permita varios agentes en el mismo workspace.

Cómo medirlo sin adivinar

Una vez que el agente de RR.HH. está en marcha, el error más común es no medirlo con el mismo criterio que el de soporte a clientes. Las mismas preguntas aplican: cuántas conversaciones se cierran sin escalar, cuántas escalan y por qué, y si el CSAT (cuando lo pides) baja en algún tema puntual. La guía completa de qué métricas mirar en un agente de IA sirve igual para el interno que para el de clientes; lo único que cambia es que acá el “cliente” es un compañero de trabajo, y eso baja bastante el margen de error que un empleado está dispuesto a tolerar antes de volver a escribirle a una persona.

Vale la misma honestidad que ya pedimos para el agente de cara a clientes en qué resuelve de verdad un agente de IA: que una conversación se haya cerrado sin escalar no significa que el empleado haya quedado conforme. Si nadie mide el CSAT del agente interno, la señal de que algo anda mal no llega por dashboard, llega cuando la gente vuelve a escribirle directo a RR.HH. “para asegurarse”.

Preguntas frecuentes