Aislamiento en IA: protege los datos de selección más allá del ATS

El aislamiento entre clientes de IA impide que un cliente acceda a las entradas, el contexto recuperado y las respuestas de otro. En un flujo de selección, debes examinar tanto la aplicación que autoriza el acceso a los candidatos como el proveedor que procesa el prompt resultante. La promesa de no entrenar un modelo con tus datos responde a otra pregunta.

La distinción importa incluso cuando la persona responsable de selección tiene permiso para leer todos los campos que envías. La autorización puede ser correcta al inicio de la solicitud, mientras que otra parte de la cadena de procesamiento necesita sus propios controles. Sigue el recorrido de los datos del candidato por toda esa cadena, incluida la respuesta que recibes.

La pregunta práctica es concreta: ¿qué pruebas justifican enviar estos campos por esta ruta para esta tarea? Empieza por ahí antes de aprobar otra función de IA para todo el proceso de selección.

¿Qué establece la divulgación de Cloudflare?

La divulgación del 26 de octubre se refiere a GLM-5.3 en Workers AI. Cloudflare informa de una exposición de contenido entre clientes en 155 respuestas, entre el 27 de agosto y el 9 de septiembre de 2026, con prompts de más de 681 280 tókenes. No identifica ningún otro modelo de Workers AI afectado y afirma no haber encontrado pruebas de explotación deliberada.

Según Cloudflare, el motor de inferencia no transmitió un rechazo de la fase de precarga a la fase de decodificación, que leyó páginas de caché que la solicitud no había escrito. Cloudflare recibió el aviso del investigador el 8 de septiembre, restringió el modelo al día siguiente y lo restableció tras corregir la configuración y el comportamiento del motor. El informe se publicó después como parte de una divulgación coordinada.

Esto describe un fallo de aislamiento durante la inferencia, no una prueba de que se usaran prompts de clientes para entrenar modelos. La conversación en Hacker News situó la divulgación entre los temas de actualidad; ninguna de las dos fuentes demuestra que se vieran afectados expedientes de candidatos o tráfico de Kit.

¿Qué preguntas responde cada garantía de privacidad de IA?

Revisa por separado el entrenamiento, la conservación, la autorización y el aislamiento. Una respuesta tranquilizadora sobre uno de estos aspectos no resuelve los demás.

La documentación oficial suele separar estos temas. La página actual de uso de datos de Workers AI trata el entrenamiento y la conservación durante la inferencia, junto con las funciones con estado, el almacenamiento elegido y los registros o la caché en pasarelas. Lee las condiciones del servicio que utilizas realmente; no extiendas sus compromisos a otro servicio al que accedes mediante una pasarela.

La documentación de privacidad de Microsoft Foundry también distingue entre aislamiento de clientes, uso para entrenamiento, funciones con almacenamiento y supervisión de abusos. Las condiciones dependen del despliegue y de las funciones utilizadas. Estas páginas ilustran las preguntas que conviene hacer; no establecen una clasificación de proveedores.

Anota el alcance de cada respuesta. «Sin entrenamiento» sin un servicio identificado y unas condiciones aplicables deja al equipo con dudas. «Sin conservación» sin una lista de funciones activadas, también. Guarda un enlace fechado o una referencia contractual aprobada junto a la configuración que describe, para que quien revise la decisión más adelante pueda entender qué cubría.

¿Qué contexto del candidato necesita realmente esta tarea?

Elige los campos mínimos antes de construir el prompt. Que un miembro pueda abrir el perfil de un candidato no significa que todos los campos deban formar parte de una solicitud de IA.

Imagina esta petición: «Resume la experiencia de este candidato en la gestión de bases de datos en producción en relación con los requisitos de este puesto de backend». La tarea necesita la experiencia pertinente y los criterios del puesto. Normalmente no necesita un teléfono, un domicilio, una firma de correo ni correspondencia privada ajena a ese objetivo.

Define las entradas previstas antes de conectar la integración:

Es una propuesta de selección de campos, no una descripción de los valores predeterminados de un producto. Otra tarea puede necesitar otros datos. Redactar un mensaje puede requerir un nombre; enviarlo exige un destino en el sistema de envío. Ninguna de esas tareas exige por sí sola incluir la dirección en el prompt del modelo.

Las recomendaciones de OWASP sobre divulgación de información sensible abordan el mínimo privilegio, las fuentes de datos restringidas y la ocultación o tokenización. Aplica esos principios a la tarea concreta en lugar de considerar una instrucción genérica de «mantener los datos privados» como un control.

Una referencia interna también requiere cuidado. Si la aplicación puede vincularla de nuevo con una persona, no describas el resultado como anónimo. Un historial profesional detallado puede identificar a alguien sin mencionar su nombre. La minimización reduce la información expuesta; no puede reparar un motor de inferencia ni impedir todas las deducciones posibles.

Prepara una ficha breve de revisión para cada flujo de trabajo. Anota la tarea, el rol que la inicia, los expedientes de origen, los campos seleccionados, el destino y los lugares donde permanecen las entradas o las respuestas. Incluye los reintentos y las rutas alternativas. Señala expresamente las preguntas sin resolver y asígnales un responsable, para que una incertidumbre no se convierta sin más en una suposición aprobada. Nuestra guía de seguridad de los datos de candidatos amplía el contexto sobre el tratamiento de los expedientes relacionados con esa solicitud.

¿Qué debes preguntar al proveedor de inferencia?

Pide pruebas vinculadas al servicio, modelo y despliegue que utilizas. Una página general de seguridad aporta contexto; tu decisión debe considerar la ruta que recibirá los datos de candidatos.

Empieza por describir el flujo de trabajo con precisión. Explica qué tipos de expedientes vas a enviar, si utilizas una pasarela o un enrutador, qué funciones de almacenamiento están activadas y si la aplicación reintenta solicitudes fallidas. Da al proveedor detalles suficientes para responder sobre tu configuración.

Después plantea preguntas cuyas respuestas permitan decidir:

• Separación del procesamiento: ¿cómo se aplica la separación entre clientes durante la inferencia y al estado reutilizable del procesamiento? ¿Qué componentes se comparten y qué controles mantienen la separación?
• Comportamiento ante fallos: ¿qué sucede cuando una solicitud se rechaza, cancela, interrumpe o reintenta? ¿El mecanismo de aislamiento documentado cubre esas situaciones?
• Persistencia: ¿qué funciones activadas almacenan prompts, respuestas o datos asociados? ¿Qué ajustes de registros y caché corresponden a la pasarela y no al servicio del modelo?
• Pruebas para investigar incidentes: ¿qué identificadores permiten al proveedor localizar una solicitud y delimitar un problema comunicado? ¿Cómo sabrás si el servicio o modelo correspondiente resulta afectado?
• Responsabilidad sobre los cambios: ¿quién avisa al equipo si una modificación de ruta, modelo, función o condiciones de procesamiento exige una nueva revisión?

Son preguntas propuestas para compradores. No constituyen un sistema de certificación, y un proveedor puede reservarse razonablemente detalles técnicos sensibles. Aun así, el responsable de seguridad necesita pruebas suficientemente concretas para decidir si el flujo de trabajo es aceptable.

Las recomendaciones del NIST para el desarrollo seguro de IA generativa se dirigen a productores y compradores a lo largo del ciclo de vida. Usa esa perspectiva al repartir responsabilidades: la adquisición, la configuración, el funcionamiento y la gestión de incidentes necesitan responsables. Las preguntas anteriores son nuestra aplicación de ese enfoque a los flujos de selección, no una lista prescrita por el NIST.

Deja constancia de una decisión expresa. Puedes aprobar una tarea limitada, reducir sus campos de entrada, desactivar una función de almacenamiento o mantener el flujo sin aprobar hasta resolver una cuestión importante. Guarda la explicación junto al inventario de rutas. Quien se incorpore al equipo debe entender qué cambios obligarían a reconsiderarla.

¿Qué pueden demostrar tus propias pruebas de aislamiento?

Tus pruebas pueden verificar comportamientos observados en la aplicación y los entornos que controlas. No pueden certificar el funcionamiento interno de toda la infraestructura de inferencia de un proveedor de servicios gestionados.

Usa candidatos ficticios en cuentas de tu organización. Asigna a cada expediente datos inventados y referencias que permitan distinguirlo de los demás. No utilices información real de candidatos como marcador de prueba ni intentes recuperar contenido de otros clientes.

Un plan de pruebas útil sigue el acceso hasta la respuesta:

1. Comprueba la separación entre cuentas. Un miembro de la cuenta de prueba A solicita el candidato ficticio que pertenece exclusivamente a la cuenta B. Verifica que la aplicación rechaza el acceso antes de construir una solicitud saliente que contenga contexto de B.
2. Comprueba las restricciones dentro de una cuenta. Un miembro sin acceso a un puesto restringido solicita su contexto ficticio. Verifica los permisos aplicables a la oferta, sin confiar únicamente en la pertenencia a la cuenta.
3. Comprueba los errores y reintentos. Interrumpe una solicitud en el entorno de prueba controlado. Verifica que el reintento conserva la cuenta y el contexto de tarea autorizados, y que un error no provoca una recuperación más amplia de datos.
4. Comprueba el destino. Completa una solicitud permitida y verifica dónde se guarda y muestra la respuesta. Comprueba tanto la finalización en segundo plano como la respuesta inmediata.
5. Comprueba el acceso tras un cambio. Modifica los permisos del miembro de prueba mientras el trabajo está pendiente. Verifica el comportamiento que promete el producto cuando la respuesta esté disponible.

Para cada prueba, anota el resultado esperado antes de ejecutarla. Recoge pruebas suficientes para distinguir una solicitud rechazada de otra que recuperó datos no autorizados y se limitó a ocultar la respuesta después. Son comportamientos distintos de la aplicación, con consecuencias diferentes.

Los marcadores ficticios únicos pueden ayudar a rastrear un error en tu sistema. Una ejecución correcta no demuestra el aislamiento de todas las solicitudes, modelos, equipos o despliegues del proveedor. Limita la conclusión: el recorrido de la aplicación que probaste se comportó como estaba previsto en las condiciones registradas.

Define cuándo hay que actualizar el plan de pruebas. Los cambios en recuperación de datos, tareas en segundo plano, rutas alternativas o almacenamiento de respuestas pueden modificar los límites aunque la función de selección no parezca distinta. Revisa las pruebas pertinentes cuando cambien esos recorridos y mantén separadas las preguntas al proveedor de las comprobaciones de la aplicación.

¿Cómo debes actuar ante datos inesperados en una respuesta de IA?

Trata la aparición de un expediente personal inesperado como un incidente que hay que contener e investigar. Una explicación convincente del modelo no demuestra de dónde procede la información.

Primero restringe el acceso a la respuesta y pausa el flujo de trabajo o la ruta del modelo afectados mientras el responsable del incidente los evalúa. Delimita con precisión qué procesamiento queda suspendido. Evita copiar el expediente inesperado en una conversación compartida, una captura para asistencia técnica u otra herramienta externa de IA para analizarlo.

Conserva los identificadores y la configuración necesarios para investigar: referencias de solicitud y respuesta, marcas de tiempo, modelo y ruta, ajustes pertinentes y cuenta que inició la solicitud. Sigue el procedimiento de incidentes para retener el contenido mínimo necesario. Limita el acceso a esas pruebas y asigna un responsable.

Después contacta con el proveedor por su canal de incidentes o seguridad. Pide ayuda para establecer el origen y el alcance de la respuesta. Tu investigación también debe examinar la recuperación de datos y el envío de las respuestas a sus destinatarios; un error de la aplicación sigue siendo una explicación posible hasta que las pruebas indiquen lo contrario. Si estás creando ese canal de comunicación, nuestra guía de divulgación de vulnerabilidades describe el proceso de recepción que lo acompaña.

Rastrea lo ocurrido después de recibir la respuesta. ¿Se guardó como nota, se incluyó en un resumen de candidatura, se exportó o se mostró a otro revisor? La contención debe abarcar esas copias además de la solicitud original. Registra las conclusiones sin ampliar el acceso a la información personal.

Deja que los responsables designados de privacidad y seguridad valoren las posibles obligaciones de notificación a partir de los hechos confirmados y los requisitos aplicables. La aparición de texto inesperado no basta para establecer una conclusión jurídica concreta. Antes de restablecer el flujo, documenta qué falló, qué cambio justifica la reanudación y qué dudas siguen abiertas.

Define con claridad los límites de cada protección en Kit

Incorpora los controles de la aplicación y los ajustes de proveedores de Kit a la revisión, con una explicación clara de lo que cubre cada uno. Sigue siendo necesario examinar qué información sale de la aplicación.

Una revisión del código de la herramienta MCP de resumen de candidatos de Kit muestra un control de acceso concreto en la aplicación: exige pertenecer a la cuenta, busca al candidato dentro de la cuenta actual y comprueba las ofertas de empleo accesibles. La herramienta no devuelve un candidato asociado únicamente a ofertas restringidas a un miembro que no tenga acceso.

El resumen autorizado puede contener el nombre, el correo, el teléfono y el contexto accesible del currículum. El cifrado en reposo del correo y el teléfono no impide que esos campos aparezcan en texto claro en el resultado autorizado de una herramienta. Revisa la herramienta y la tarea reales antes de asumir que se han excluido los datos de contacto.

La documentación de proveedores de IA de Kit también describe rutas de procesamiento separadas. El proveedor preferido gestiona la mayoría de las conversaciones y tareas de generación dentro de la aplicación. La indexación y la búsqueda semánticas usan el servicio de representaciones vectoriales de Google con la clave de plataforma de Kit, con independencia de esa preferencia. Hiring Live Review utiliza la clave Gemini de la propia cuenta, y el enriquecimiento en segundo plano del módulo de investigación de compensación tiene otra ruta fija de Gemini. Los límites de gasto asociados a la clave de la cuenta no detienen todas estas rutas separadas.

Un asistente externo conectado mediante MCP añade su propio ámbito de procesamiento. Su permiso para solicitar información a Kit y el tratamiento que hace de la información recibida son cuestiones distintas. Cambiar el proveedor preferido de Kit no configura ese asistente externo.

Empieza por una tarea de selección. Identifica quién puede recuperar los expedientes, examina los campos que salen de la aplicación y revisa la ruta real de procesamiento y la respuesta guardada. Después prueba los límites de la aplicación que controlas y aclara con el proveedor las dudas pendientes junto al responsable adecuado. Si estás evaluando Kit, usa las rutas documentadas y un candidato ficticio para concretar esa revisión antes de añadir datos de selección sensibles.