Cómo pueden los equipos de RR. HH. desplegar aplicaciones creadas con IA sin exponer los datos de los empleados

La empresa de seguridad RedAccess buscó aplicaciones creadas con herramientas de programación con IA y publicadas en el alojamiento de esas mismas herramientas, y encontró más de 5.000 prácticamente sin ningún tipo de seguridad ni autenticación. Entre las capturas que compartió con Wired había lo que parecía ser la asignación de tareas de un hospital, con información personal de los médicos incluida.

Crear la aplicación es la parte que las herramientas de programación con IA han facilitado. La exposición en las aplicaciones creadas con IA para RR. HH. llega después, cuando un registro de ausencias o una ficha de evaluación de entrevistas se publica tal como se mostró en la demostración: un enlace público, una cuenta de administrador y toda la tabla de empleados detrás.

TL;DR

• Una herramienta que ayuda a decidir a quién contratar o ascender, o cómo evaluar a las personas, puede considerarse de alto riesgo según el Reglamento de IA de la UE. Debe pasar por TI y por el departamento jurídico o el DPO antes de puntuar a nadie.
• Los registros de los empleados nunca deben alojarse en el servicio de la propia herramienta de programación con IA. La opción predeterminada es un servidor controlado por el equipo, accesible solo desde una red privada, con inicio de sesión corporativo como puerta de entrada cuando los responsables o todos los empleados necesiten acceso.
• Las correcciones se realizan con la misma herramienta de IA que creó la aplicación: reducir los campos que lee, ofrecer vistas diferentes a administradores de RR. HH., responsables y empleados, sacar las credenciales del código, reducir lo que envía al exterior, registrar quién abre cada registro y gestionar las solicitudes de supresión teniendo en cuenta los requisitos de conservación. Cada corrección se confirma con una comprobación que realizas tú; no con el informe de la propia IA.
• El acceso a la herramienta debe terminar el día que termina la relación laboral, una persona identificada debe hacerse responsable de ella y elegir la ubicación del servidor no garantiza el cumplimiento de ninguna norma.

Los errores de despliegue que exponen los datos de los empleados

Una herramienta de RR. HH. creada con IA expone los datos de los empleados a quien encuentre su enlace, a quien tenga una credencial pegada en un chat o en el código, a compañeros que abran registros ajenos, a servicios externos a los que envía datos y a personas que ya se han marchado, sin dejar constancia de quién los consultó. Leer toda la tabla de empleados amplía cada una de esas vías.

La primera fila corresponde a lo que RedAccess encontró a gran escala. En el reportaje de Wired sobre los hallazgos de RedAccess, tres de las cuatro empresas de programación con IA cuestionaron las afirmaciones de los investigadores (la cuarta no respondió), pero no negaron que las aplicaciones creadas mediante vibe coding que encontró RedAccess habían quedado expuestas. Lo interpreto como un problema de configuración y un paso de revisión omitido.

Comprueba si la herramienta ayuda a decidir a quién contratar, ascender o evaluar

El hecho de haberse creado con una herramienta de programación con IA no convierte, por sí solo, una herramienta de RR. HH. en un sistema de alto riesgo según el Reglamento de IA de la UE. Lo determina lo que hace la herramienta. El anexo III del Reglamento de IA de la UE enumera los sistemas de IA usados para contratar o seleccionar personas y para tomar decisiones sobre ascensos, despidos, asignación de tareas o supervisión y evaluación del rendimiento.

Así que, antes de decidir dónde se ejecutará la herramienta, plantea una pregunta: ¿toma o influye en una decisión sobre a quién contratar, ascender, despedir, asignar trabajo o evaluar por su rendimiento?

Un registro de ausencias, una lista de incorporación o un directorio de la organización almacena registros y los muestra, por lo que cae del lado del «no». Una ficha de evaluación de entrevistas que ordena candidatos, o una herramienta de rendimiento que puntúa personas (especialmente si la puntuación la calcula un modelo de IA), puede caer del lado del «sí». Cuando no puedo determinar de qué lado está una herramienta, la trato como un sí y dejo que TI y el departamento jurídico me indiquen lo contrario.

El Reglamento no se limita a empresas de la UE: el artículo 2 abarca a proveedores y responsables del despliegue establecidos fuera de la UE cuando los resultados de su sistema de IA se utilizan en la UE. Según el artículo 113 en su versión modificada, las obligaciones para los sistemas de alto riesgo del anexo III se aplican a partir del 2 de diciembre de 2027. Incluyen un sistema de gestión de riesgos, gobernanza de datos, documentación técnica, conservación de registros, transparencia para los responsables del despliegue y supervisión humana (artículos 9 a 14), y corresponde a TI y al departamento jurídico evaluarlas.

Si la respuesta es sí, detente antes de que la herramienta puntúe a un solo candidato o empleado real. Llévala a TI y a tu responsable jurídico o de protección de datos (el DPO, si lo hay). Esta comprobación no determina si una herramienta concreta está dentro del ámbito del Reglamento; te indica quién debe decidirlo. Algunos estados de EE. UU. también regulan las decisiones automatizadas de contratación, y esas normas aparecen en la tabla que encontrarás más abajo.

Puedes adelantar parte de esa revisión. Yo pediría a la herramienta de IA que argumentara contra su propia puntuación en vez de defenderla:

Esta aplicación puntúa u ordena candidatos a puestos de trabajo o empleados. Enumera todos los campos de datos y todos los pasos de cálculo que intervienen en la puntuación o clasificación. Para cada uno, dime si podría reflejar directa o indirectamente una característica protegida: edad, raza, sexo, nacionalidad, origen étnico, discapacidad, embarazo, religión u orientación sexual. Cuando no estés seguro, dilo en lugar de adivinar. Después señala cualquier cuestión sobre la equidad de esta puntuación por la que no haya preguntado y por la que debería haberlo hecho.

Comprobación: trata la respuesta como una lista inicial para quienes revisan la herramienta, no como un veredicto, y entrégala junto con la propia herramienta. Ejecutar este prompt no constituye una auditoría de sesgos ni satisface ningún requisito legal.

Dónde debería ejecutarse una herramienta de RR. HH.

Mantén los registros de los empleados fuera del alojamiento de la propia herramienta de IA. Para una herramienta que solo usa el equipo de RR. HH., la opción predeterminada es un servidor controlado por el equipo, accesible solo desde una red privada, con inicio de sesión corporativo como puerta de entrada cuando lo necesiten responsables o empleados. Una herramienta que no supere la comprobación sobre decisiones de contratación, o que no tenga a nadie responsable de su servidor, debe pasar a TI.

Publicar en el alojamiento de una herramienta de programación con IA sitúa la aplicación en una dirección del dominio del proveedor y, salvo que su visibilidad se configure como privada, cualquiera que encuentre esa dirección puede acceder. RedAccess identificó miles de aplicaciones creadas así mediante búsquedas normales en Google y Bing de esos dominios. Una red privada funciona al revés: la herramienta solo responde a dispositivos que se hayan conectado a ella. El inicio de sesión corporativo (inicio de sesión único) permite a los compañeros abrir la herramienta con la cuenta de empresa que ya usan, verificada por un proveedor de identidad, el servicio que gestiona esas cuentas.

Hasta que la herramienta se ejecute en el servidor del equipo, créala y pruébala con datos sintéticos, es decir, nombres, salarios y fechas de ausencia inventados con el mismo formato que los reales. Un túnel gratuito desde un portátil hasta una dirección pública es público igual que el alojamiento del proveedor, por lo que también pertenece a la fase de demostración.

¿Por qué una red privada y no la página de inicio de sesión que ya tiene la aplicación? Una red privada significa que la herramienta no responde en absoluto desde fuera, así que nadie externo puede cargarla, sondearla ni adivinar contraseñas. Una página de inicio de sesión escrita por la herramienta de IA no basta por sí sola. Cualquiera puede acceder a ella y su solidez depende del código generado que hay detrás. El informe de Veracode de 2025 sobre seguridad del código GenAI encontró que el 45% de las muestras de código probadas, procedentes de más de 100 modelos, no superaron sus pruebas de seguridad por una vulnerabilidad OWASP Top 10 (una de una lista ampliamente utilizada de los riesgos de seguridad más críticos para aplicaciones web). Por eso prefiero poner un candado delante de la aplicación a depender del que escribió la IA.

Para la entrega, la herramienta se ejecuta en un VPS (un servidor alquilado que el equipo controla por completo) bajo una herramienta de despliegue como Coolify o Dokku, que ejecuta la aplicación a partir de su código; Coolify también permite revertir una actualización defectuosa a una versión anterior desde su panel. Elegir entre Coolify y Dokku depende en gran medida de cuántas aplicaciones alojará el servidor y de si el apoyo de TI prefiere un panel. La red privada la proporciona Tailscale o WireGuard. Tailscale es el más rápido de configurar, pero su servicio de coordinación lo gestiona Tailscale, mientras que WireGuard se aloja íntegramente en infraestructura propia. El inicio de sesión corporativo lo proporciona un proveedor de identidad como Authentik o Keycloak. Un proxy inverso como Caddy o Nginx Proxy Manager añade HTTPS cuando el inicio de sesión está expuesto a la web. Esta es la parte que debes entregar al apoyo de TI, junto con la lista de comprobación del final.

Las correcciones, como prompts para tu propia herramienta de IA

La mayor parte del trabajo para desplegar con seguridad una aplicación de RR. HH. creada con IA pasa por la herramienta que la creó, pero solo si se lo pides. Como dijo a Wired el investigador de seguridad Joel Margolis, las herramientas de programación con IA «hacen lo que les pides. Y, salvo que les pidas que lo hagan de forma segura, no se van a esforzar especialmente por hacerlo».

Trata cada prompt siguiente como un punto de partida y adapta los nombres de los campos y los roles a tu herramienta. Considero la herramienta de IA como el ingeniero y a mí mismo como el revisor, por lo que su informe de que un cambio está terminado es un borrador. La comprobación que aparece bajo cada prompt es la prueba, y ninguna exige leer código. Cuando una comprobación falla, la corrección vuelve a la herramienta de IA y la lección se guarda en un archivo de reglas para tu herramienta de IA para que la siguiente sesión parta de ella. Cada prompt también pide a la herramienta que señale lo que no tiene claro; un asistente que admite una carencia es más útil que uno que parece seguro. Ejecútalos sobre el código y registros ficticios, nunca con registros reales ni contraseñas pegados en el chat.

Identifica los campos de empleados que utiliza la herramienta y bloquea los demás

No puedes bloquear un campo que no sabes que la herramienta contiene, así que el primer prompt es una auditoría:

Revisa la base de datos, el código, las pantallas y las exportaciones de esta aplicación. Enumera todos los campos que puedan contener datos personales de un empleado o candidato: nombres, identificadores de empleado, SSN o números de identificación nacional, identificadores fiscales, fechas de nacimiento, domicilios, información sanitaria, situación de discapacidad, registros de adaptaciones laborales, documentos de inmigración o autorización de trabajo, salario, bonus, participaciones, evaluaciones del rendimiento y notas disciplinarias. Para cada campo, dime qué pantalla o función lo utiliza y si lo necesita la función principal de la aplicación. Si no puedes determinarlo, márcalo como incierto en lugar de adivinar.

Comprobación: abre las pantallas principales y las exportaciones de la herramienta y asegúrate de que todos los campos de datos personales que ves figuran en la lista. Si ves un campo que la lista no menciona, la auditoría ha pasado algo por alto, así que vuelve a preguntar.

El segundo prompt elimina lo que la herramienta no necesita. Se basa en una cuenta de base de datos (la cuenta que utiliza la aplicación para comunicarse con su base de datos), que puede limitarse a campos concretos.

Modifica esta aplicación para que lea solo estos campos: [enumera los campos que necesita la herramienta]. Elimina cualquier otro campo de datos personales de la copia de los datos de la aplicación, del código, de todas las pantallas y de todas las exportaciones. Después crea una cuenta de base de datos independiente para la aplicación que solo pueda leer esos campos y modificar los datos que la propia herramienta escribe, como las solicitudes de ausencia. Cambia la aplicación para que use esa cuenta. Informa exactamente de lo que has cambiado, archivo por archivo, e indica todo lo que no hayas podido hacer.

Modificar solo las pantallas no basta. Si la cuenta de base de datos de la aplicación no puede leer la columna de salarios, un error en otra parte del código escrito por IA tampoco podrá mostrarla. Si los datos están cifrados en reposo es una pregunta para TI, porque depende de la configuración del servidor y del disco, que un asistente que lee el código no puede comprobar con fiabilidad.

Comprobación: inicia sesión como usuario normal y abre todas las pantallas y exportaciones; no debe aparecer ninguno de los campos eliminados. Después pide al apoyo de TI que gestiona el servidor (o a la herramienta de IA, mostrando los resultados) que solicite un campo eliminado conectado con la cuenta de base de datos de la aplicación. Un error de permiso denegado o que indique que el campo no existe significa que la prueba se supera. Un error de conexión, de sintaxis o cualquier otro no relacionado no sirve. Una columna vacía o un valor real significa que la prueba falla. Conserva la lista de la auditoría, porque la utiliza la herramienta de supresión.

Ofrece vistas diferentes a administradores de RR. HH., responsables y empleados

Aquí es donde los datos de los empleados se filtran dentro de la empresa: al compañero que abre el salario de otro o la nota sobre adaptaciones laborales de alguien de su equipo. El control de acceso basado en roles lo corrige, y el siguiente prompt especifica dónde debe hacerse la comprobación:

Añade control de acceso basado en roles con tres roles, comprobados en el servidor en cada solicitud, no solo ocultando botones o enlaces en la página.

- Administrador de RR. HH.: puede leer y editar todos los registros de empleados.

- Responsable de equipo: solo puede leer los registros de las personas que dependen directamente de él y nunca ve campos salariales, médicos, de adaptaciones laborales, disciplinarios ni migratorios.

- Empleado: solo puede leer su propio registro.

Rechaza todo lo demás con una respuesta de «acceso denegado» (403). Obtén el rol de cada usuario de la cuenta con la que ha iniciado sesión, nunca de algo que pueda escribir o cambiar en la página o en la barra de direcciones. Enumera todos los lugares donde hayas añadido una comprobación y señala cualquier página o exportación cuya cobertura no tengas clara.

Algunas empresas permiten a los responsables ver los salarios durante las revisiones de remuneración; si la tuya lo permite, debes cambiar esa línea del rol de responsable.

Comprobación: crea un responsable y un empleado de prueba. Con la sesión del responsable, abre el registro de una persona que dependa directamente de él, copia su dirección, cambia el número de registro por el de alguien de fuera del equipo y cárgalo: debes recibir «acceso denegado». Repite la prueba como empleado con el número de registro de un compañero. Después confirma que la vista del responsable nunca muestra campos de salario, adaptaciones laborales o inmigración.

Saca las credenciales del código y del chat

Una contraseña de base de datos o un token de API del HRIS o del sistema de nóminas (la clave larga que usa un sistema para acceder a otro) puede eliminarse del código actual y seguir en versiones anteriores guardadas del proyecto; por eso el prompt también pregunta por el historial. Una variable de entorno resuelve la parte del código. Es un valor que el servidor entrega a la aplicación cuando arranca, de modo que el código lo referencia por su nombre sin contenerlo.

Busca todas las contraseñas, claves de API, tokens de acceso y cadenas de conexión a bases de datos de este proyecto, incluidos los de nuestros sistemas HRIS, de nóminas o de correo. Sustituye cada uno en el código por una variable de entorno y dame la lista de nombres de variables. Asegúrate de que los archivos que contienen los valores reales, como .env, queden excluidos del repositorio de código. Después enumera todos los lugares del historial del proyecto donde siga apareciendo un valor antiguo, para saber qué credenciales sustituir.

El prompt no puede realizar el paso más importante. En la consola de administración del HRIS o de la base de datos, emite una credencial nueva por cada una que haya aparecido alguna vez en un chat o en el repositorio y desactiva la antigua.

Las copias de esas contraseñas que conserva el equipo deben estar en un gestor de contraseñas, como un servidor Vaultwarden autoalojado (qué opción conviene a un equipo es una decisión aparte). Almacena credenciales para las personas y no suministra valores a una aplicación en ejecución, que los obtiene de la herramienta de despliegue. Para los secretos que lee la propia aplicación en ejecución, HashiCorp Vault es la opción más compleja, con políticas centralizadas y rotación para los equipos que las necesitan.

Comprobación: pide a la herramienta de IA que busque los valores antiguos en los archivos actuales y lee los resultados de búsqueda que te muestra, no su resumen. Los archivos actuales no deben tener coincidencias. Las coincidencias en el historial son esperables y no hace falta borrarlas; son la lista de credenciales que debes sustituir. La prueba de que cada una ha dejado de funcionar está en la consola de administración del HRIS o de la base de datos: cada credencial antigua figura como revocada, o TI confirma que el sistema la rechaza.

Comprueba qué datos de empleados salen de la herramienta

Una vez que una llamada ha enviado las notas de entrevista de un candidato a un servicio externo, borrar el registro en tu herramienta no elimina la copia que ese servicio puede conservar. Por eso la solución consiste en enviar menos datos desde el principio.

Audita todas las llamadas externas de esta aplicación: a OpenAI, Anthropic o cualquier otra API de IA, a cualquier sistema de RR. HH. como un HRIS o ATS, a herramientas de analítica o seguimiento de errores y a cualquier webhook. Para cada llamada, enumera exactamente qué campos de empleados o candidatos se incluyen en lo enviado. Señala cualquier servicio que pueda almacenar o registrar lo que recibe y dime qué llamadas podrían funcionar con menos datos. Marca todo aquello de lo que no estés seguro.

Comprobación: crea un empleado o candidato ficticio con un nombre inventado distintivo y usa cada función que haga una llamada externa (genera el resumen de entrevista, activa el webhook, abre la página que carga el script de analítica). Abre el panel de cada servicio externo, como la herramienta de analítica, el sistema de seguimiento de errores, el registro de webhooks recibidos del ATS o el registro de uso del proveedor de IA donde muestre solicitudes, y busca ese nombre. Solo debe aparecer donde la llamada lo necesite. Si aparece en otro sitio, devuelve esa llamada a la herramienta de IA con menos datos y repite la comprobación. Algunos paneles no muestran lo que recibieron. Para esos servicios, y para cualquiera que deba seguir recibiendo datos de empleados, entrega sus condiciones de conservación de datos a la persona que firma los contratos con proveedores en tu empresa.

Registra quién abrió cada registro de empleado

Un empleado pregunta quién exportó la hoja de salarios el trimestre pasado. Sin un registro de auditoría (un registro continuo de quién hizo qué en cada registro), nadie puede responder.

Añade un registro de auditoría. Cada vez que un usuario vea, edite, exporte o borre un registro de empleado, añade una fila con el ID del usuario, el ID del registro de empleado, la acción, los campos modificados y la hora. Configura la base de datos para que la cuenta de base de datos de la aplicación pueda añadir filas a este registro, pero no editarlas ni borrarlas. Solo los administradores de RR. HH. pueden leer el registro en la aplicación. Dime cómo se aplica la regla de no editar ni borrar, y dónde.

La condición de «solo añadir» debe derivar de los permisos de la cuenta de base de datos, no de que la aplicación prometa comportarse bien. El registro también contiene datos personales por sí mismo, ya que muestra quién consultó el registro de quién; por eso solo lo leen los administradores de RR. HH.

Comprobación: como administrador de RR. HH., abre un registro, consulta después el registro de auditoría y confirma que la entrada está ahí. Pide a TI o a la herramienta de IA (mostrando los resultados) que intente borrar una fila del registro de auditoría usando la cuenta de base de datos de la aplicación; debes ver el propio error de permisos.

Gestiona las solicitudes de supresión sin incumplir las normas de conservación

¿Qué ocurre cuando un empleado solicita la supresión y parte de sus registros son archivos de nóminas que la empresa debe conservar? El prompt evidente («borra todos los datos personales de este empleado de todas las tablas») los elimina igualmente, y eso provoca dos problemas. Los empleadores suelen tener que conservar algunos registros, como archivos de nóminas, fiscales y de autorización de trabajo, y el derecho de supresión del RGPD no se aplica en la medida en que el tratamiento sea necesario para cumplir una obligación legal o para reclamaciones legales (artículo 17(3)(b) y (e)). Un botón de borrar todo también es una función peligrosa si queda disponible sin más. La versión más segura separa «borrar a petición» de los registros sujetos a conservación obligatoria, es decir, los que la empresa debe conservar independientemente de la solicitud, y muestra su plan antes de borrar nada:

Crea una herramienta de solicitudes de supresión que solo puedan abrir los administradores de RR. HH. Con un ID de empleado, muestra primero todas las tablas y campos que contienen datos de esa persona, agrupados en las categorías de la auditoría de campos. Cada categoría tiene un ajuste de conservación que establece un administrador de RR. HH.: «borrar a petición» o «conservar: conservación obligatoria». Tras la confirmación de un administrador de RR. HH., la herramienta elimina solo las categorías configuradas como «borrar a petición». Registra únicamente el ID del empleado, la hora, quién confirmó y qué categorías se borraron o conservaron, y nada más sobre la persona. Cualquiera que no sea administrador de RR. HH. recibe «acceso denegado».

Los ajustes de conservación los determina tu responsable de cumplimiento o el DPO, no la herramienta de IA ni la mejor suposición de quien la creó. Indícales que el registro de auditoría conserva el ID del empleado después de una supresión para que decidan cuánto tiempo debe permanecer ese identificador. Las copias de seguridad y las copias que conservan servicios externos necesitan su propio proceso de conservación o supresión.

Comprobación: crea un empleado de prueba con registros en dos categorías: una configurada como «borrar a petición» y otra como conservación obligatoria. Ejecuta la herramienta como administrador de RR. HH. y confirma que solo ha desaparecido la primera categoría. Después abre la herramienta con una cuenta de responsable y espera recibir «acceso denegado».

Normas laborales que debes consultar con tu DPO o responsable de cumplimiento

Las normas laborales que afectan a una herramienta de RR. HH. dependen de lo que hace y a quién pertenecen los datos que contiene, no de cómo se creó. Esta es una lista de normas para consultar con tu DPO o responsable de cumplimiento, no asesoramiento jurídico, y no determina si alguna se aplica a tu caso.

Un registro de ausencias que contiene notas de adaptaciones laborales para personal en Alemania y California está sujeto a normas distintas de las de un planificador de plantilla que solo contiene nombres de puestos. La cuestión del Reglamento de IA de la UE corresponde a la comprobación sobre decisiones de contratación.

La ubicación del servidor determina dónde están físicamente los registros; por sí sola no satisface ninguna de las normas anteriores. Para personal fuera de esos lugares, empieza por el regulador nacional, estatal o local de privacidad o empleo correspondiente, o por tu responsable jurídico o de cumplimiento.

El acceso termina cuando termina la relación laboral

Cuando se desactiva la cuenta corporativa de una persona en su último día, su correo, calendario y archivos se cierran en un solo paso. La herramienta de RR. HH. debe cerrarse en ese mismo paso y, detrás del inicio de sesión corporativo, puede hacerlo siempre que la baja también revoque las sesiones activas. Cualquier herramienta que no esté detrás de ese inicio de sesión debe figurar como una línea propia en la lista de baja para que alguien elimine la cuenta manualmente.

Quien crea la herramienta también terminará marchándose. Cuando esa persona deja la empresa o cambia de función, la responsabilidad pasa a un sucesor identificado que puede iniciar sesión como administrador y sabe dónde está el servidor, y se cierra la cuenta de administrador de quien la creó. Yo nombraría a ese sucesor antes de la puesta en producción, porque el periodo de preaviso es un mal momento para buscarlo.

Revisa con una periodicidad establecida quién tiene cada rol y si la herramienta sigue en uso. Cuando haya que ampliar el acceso, hazlo un nivel cada vez (el equipo de RR. HH., después los responsables y luego todos los empleados) y repite la prueba de la barra de direcciones en cada nivel. Cuando deje de usarse, retírala: desactiva su cuenta de base de datos y sus credenciales, borra sus datos según los ajustes de conservación de la herramienta de supresión, detenla y elimínala de la red privada o del sistema de inicio de sesión.

El sucesor identificado hereda un servidor que alguien tuvo que configurar, con una herramienta de despliegue, una red privada y, para un acceso más amplio, inicio de sesión corporativo. Nuestro VPS Linux ofrece acceso root, y Coolify, Tailscale y Authentik se despliegan cada uno como una aplicación con un clic, para que el apoyo de TI dedique sus horas a las comprobaciones. Las ubicaciones incluyen Fráncfort y Ámsterdam en la UE, Londres en el Reino Unido y varias ciudades de EE. UU. Eso determina en qué país está el servidor, un dato para la conversación con el DPO, no un sustituto de ella.

Lista de comprobación para la puesta en producción

Cada punto siguiente está completado o no lo está antes de introducir registros de empleados; esta es la lista que debes entregar a quien configure el servidor.

1. La pregunta sobre decisiones de contratación está respondida y cualquier «sí» se ha remitido a TI y al departamento jurídico.
2. La herramienta se ejecuta en un servidor controlado por el equipo, no en el alojamiento de la herramienta de IA.
3. Solo es accesible desde la red privada o mediante inicio de sesión corporativo.
4. La cuenta de base de datos de la aplicación lee únicamente los campos enumerados.
5. Tanto un responsable como un empleado de prueba reciben «acceso denegado» en la prueba de la barra de direcciones.
6. Todas las credenciales que aparecieron en un chat o en el código se han sustituido, y las antiguas se han revocado.
7. La auditoría de datos salientes está completada y se han eliminado los campos innecesarios.
8. El registro de auditoría registra las consultas y la cuenta de la aplicación no puede editarlo ni borrarlo.
9. Los ajustes de conservación y las normas laborales han pasado por el DPO o el responsable de cumplimiento.
10. Hay un responsable identificado y un sustituto identificado.

Preguntas frecuentes

¿Qué es la IA en la sombra en RR. HH.?

La IA en la sombra en RR. HH. es el uso de herramientas de IA, o aplicaciones creadas con ellas, sobre datos de RR. HH. sin el conocimiento o la aprobación de TI. La encuesta anual de sistemas de RR. HH. de Sapient Insights de 2026, según informó Cornerstone OnDemand, encontró que más del 80% de los profesionales de RR. HH. usan a diario herramientas personales de IA, mientras que el 3% usa la IA integrada en sus sistemas de RR. HH.

¿Puedo usar registros reales de empleados mientras creo la herramienta?

No. Mantén los registros reales fuera del chat mientras creas una herramienta de RR. HH. mediante vibe coding. Pegarlos en un asistente de chat supone un riesgo distinto del despliegue de la aplicación y surge en el momento de pegarlos, independientemente de que la herramienta llegue a publicarse. Trabaja con registros ficticios hasta que la herramienta se ejecute en un servidor controlado por el equipo.

¿Deben los empleados consentir que una herramienta de RR. HH. use sus datos?

Normalmente, el consentimiento es una base inadecuada. Las directrices sobre el consentimiento del EDPB señalan que «considera problemático que los empleadores traten datos personales de empleados actuales o futuros sobre la base del consentimiento, ya que es poco probable que se otorgue libremente». Qué base jurídica se aplica conforme al artículo 6 del RGPD es una cuestión para tu DPO.

¿Cubre HIPAA las notas médicas de una herramienta de RR. HH.?

Normalmente no. La definición de información sanitaria protegida de HIPAA excluye la información en registros laborales que conserva una entidad cubierta en su función de empleador (45 CFR 160.103). Eso no significa que esas notas no estén reguladas, así que pregunta a tu responsable de cumplimiento qué normas las cubren.