Casi un tercio de los empleados encuestados compartió con la IA credenciales de trabajo, claves y accesos

Un desarrollador copia un registro de errores en un chat de IA y le pide que identifique la causa de un fallo. El registro contiene una clave de trabajo activa. Es una tarea habitual que lleva unos segundos, pero el acceso al sistema ya se ha entregado a un servicio externo. Son precisamente estas situaciones las que conviene abordar con el equipo antes de la próxima corrección urgente.

Según RB.RU, casi uno de cada tres empleados encuestados en empresas rusas compartió con sistemas de IA credenciales de trabajo, claves y accesos a carpetas en los últimos seis meses. El medio cita un estudio de Kiberdom. Solo el 5% de los participantes afirmó que su empresa tiene normas escritas sobre el uso de IA, mientras que casi uno de cada cinco no sabe qué datos de trabajo está permitido compartir con estos sistemas.

Qué dicen las cifras y qué no demuestran

Para un fundador o un responsable de desarrollo, esto plantea una pregunta concreta: ¿entienden los empleados exactamente qué envían a la IA junto con la tarea? Alguien puede recordar que no debe compartir una contraseña, pero pasar por alto un token en un fragmento largo de código o un enlace de acceso dentro de una conversación.

Sin embargo, un titular que afirme que «solo el 5% de las empresas» tiene normas exige cautela. La descripción facilitada se refiere al porcentaje de empleados encuestados que afirmaron que existían esas normas. Esto no permite calcular directamente la proporción de empresas: varios participantes podrían trabajar en la misma organización y algunos empleados podrían simplemente desconocer la existencia de un documento de política interna.

El texto disponible tampoco incluye el tamaño ni la composición de la muestra, la formulación de las preguntas ni los detalles de la metodología. Por tanto, los resultados no se pueden extrapolar a todos los empleados de empresas rusas. Compartir un nombre de usuario, una clave secreta activa o un enlace a una carpeta también genera riesgos distintos. La encuesta los agrupa en una misma visión general, pero no indica cuántos casos derivaron en accesos no autorizados o filtraciones.

Cómo acaba un secreto en una consulta corriente

Imaginemos un equipo hipotético que está integrando un servicio de pagos. La integración devuelve un error y un desarrollador envía al asistente una solicitud de ejemplo, las cabeceras y la respuesta del servidor. En la cabecera de autorización permanece un token real. No hace falta para analizar la estructura de la solicitud: se puede sustituir por un valor de ejemplo, conservando los nombres de los campos y el código de error.

Un responsable de producto se enfrenta a una situación similar cuando pide a la IA que analice consultas de clientes. La exportación puede contener datos de contacto, enlaces internos e información sobre pedidos. Conviene empezar por reunir unos cuantos ejemplos anonimizados y comprobar si bastan para el análisis necesario. Enviar toda la hoja de cálculo solo porque resulta cómodo adjuntarla aumenta innecesariamente el volumen de datos compartidos.

El mero hecho de enviar información a un servicio de IA no demuestra que se haya publicado ni utilizado para entrenar un modelo. Las condiciones dependen del producto, el plan, la configuración y el contrato concretos. Es necesario comprobarlas por separado. El nombre del servicio, por sí solo, no determina qué datos está autorizado a confiarle el equipo.

Qué pueden hacer los equipos

Conviene empezar con normas breves y ejemplos claros. ¿Qué servicios están autorizados? ¿Se puede subir código fuente? ¿Cómo deben tratarse los documentos de clientes? ¿A quién hay que acudir si ya se ha enviado una clave a un chat? Las respuestas deben estar disponibles donde trabajan los empleados y ser aplicables a tareas reales.

El siguiente paso es preparar ejemplos seguros: un registro sin secretos, una solicitud de prueba con un valor de ejemplo en lugar de un token y una consulta de cliente anonimizada. Para un desarrollador es más fácil seguir un ejemplo ya preparado que determinar por su cuenta, cada vez, los límites de lo permitido. La detección automática de secretos puede complementar este proceso, pero sus resultados también requieren revisión.

Si ya se ha compartido una clave activa con un servicio externo, la respuesta práctica es revocarla, emitir una nueva y revisar los registros de uso disponibles. Eliminar el mensaje no sustituye el cambio de clave.

Para un responsable, el principal valor de esta encuesta es que invita a examinar un proceso de trabajo concreto. Tomen una tarea habitual que el equipo resuelva con IA y revisen qué datos se envían junto con ella. Ese análisis mostrará dónde hace falta una norma clara, una plantilla ya preparada o una restricción técnica.