Ciberseguridad

Qué revisar antes de introducir información en un prompt

Antes de enviar un prompt, la primera pregunta no debería ser si la herramienta “parece segura”, sino qué información contiene y si realmente necesita utilizarse para completar la tarea. Esa clasificación determina qué comprobaciones vienen después.

También importa el contexto. Un mismo documento puede ser adecuado para un caso de uso autorizado y resultar inapropiado en otra herramienta o para una finalidad diferente.

Qué tipo de información contiene

¿Qué debería hacer que un empleado se detenga a revisar el contenido? No existe una única categoría de “datos sensibles”. Conviene distinguir, al menos:

• Información pública: que sea accesible públicamente no significa que pueda reutilizarse sin más; también hay que revisar finalidad, datos personales u otras restricciones.
• Documentos de uso interno pueden contener información corporativa que no está destinada a servicios externos.
• Información confidencial incluye, por ejemplo, contratos, documentación de clientes, operaciones o contenidos sometidos a reserva.
• Estrategias, código, diseños o conocimiento cuyo valor depende de mantenerlo protegido pueden constituir secretos empresariales o propiedad intelectual.
• Contraseñas, tokens, API keys y claves privadas son secretos técnicos que no deberían formar parte de un prompt ordinario.
• Los datos personales identifican o pueden hacer identificable a una persona, incluso cuando no aparece su nombre.
• Información sobre salud, origen racial o étnico, opiniones políticas, religión, afiliación sindical o determinados datos biométricos pertenece a categorías especiales de datos personales.

Estas categorías pueden solaparse. Un contrato, por ejemplo, puede contener a la vez información confidencial, datos personales y propiedad intelectual. La AEPD advierte sobre este nuevo perímetro de riesgo en los prompts, donde también pueden aparecer secretos empresariales o documentación sometida a reserva.

¿La herramienta y la finalidad permiten ese uso?

¿Una herramienta corporativa permite introducir cualquier dato? No automáticamente. Que una solución esté autorizada significa que la organización ha aprobado determinados usos y controles, no que cualquier información pueda tratarse en ella.

Antes de continuar conviene comprobar para qué casos está aprobada, qué tipos de información admite la política interna y qué proveedores o integraciones intervienen. Si el empleado no puede responder con claridad, la autorización de la herramienta no debería utilizarse como un pase libre.

La finalidad importa tanto como el entorno. Antes de copiar un documento completo conviene preguntarse por la necesidad real de esos datos. Si basta con un fragmento, datos ficticios o información agregada, introducir el conjunto completo aumenta exposición sin aportar valor.

Con estas dos comprobaciones, tipo de información y uso previsto, ya puede decidirse si continuar directamente o pasar al siguiente nivel: minimizar, anonimizar, cambiar de herramienta o escalar.

Cómo decidir si continuar, minimizar o escalar

Identificar el tipo de información y comprobar la herramienta no siempre basta para tomar una decisión. Antes de enviar el prompt conviene preguntarse si está utilizando solo lo necesario y si puede reducirse la exposición sin impedir que la IA complete la tarea.

El objetivo no es transformar al empleado en especialista en privacidad o seguridad, sino ofrecerle una regla operativa: cuando pueda reducir el riesgo, hacerlo; cuando la política sea clara, seguirla; y cuando exista una duda relevante, detenerse antes de enviar.

¿Puede reducirse o anonimizarse la información?

Minimizar significa utilizar solo los datos necesarios para la finalidad concreta. Es también uno de los principios del Reglamento General de Protección de Datos: cuando se tratan datos personales, deben ser adecuados, pertinentes y limitados a lo necesario.

En la práctica, esto puede significar enviar únicamente un fragmento de un documento, sustituir datos reales por ejemplos ficticios o eliminar campos que no aportan nada a la tarea. Si queremos mejorar la redacción de una respuesta, por ejemplo, probablemente no sea necesario incluir el expediente del cliente completo.

Anonimizar exige más que borrar un nombre. La información debe dejar de permitir razonablemente la identificación de la persona, también mediante otros datos o combinaciones disponibles. Si todavía puede relacionarse con alguien mediante información adicional, podemos estar ante seudonimización, y los datos siguen siendo personales.

Por eso, el empleado no debería asumir que ha anonimizado correctamente un contenido solo porque ha eliminado identificadores evidentes. Cuando exista duda sobre la posibilidad de reidentificación, conviene tratarla como una señal de escalado.

Matriz de decisión: dato, herramienta, finalidad y acción

La decisión puede resumirse en una matriz sencilla. Los ejemplos son orientativos y deben adaptarse a las políticas, herramientas y contratos de cada organización:

Tipo de información	Herramienta y finalidad	Qué revisar	Acción
Información pública	Herramienta admitida para redactar o resumir	Que el contenido pueda reutilizarse para esa finalidad y no incluya restricciones o datos que requieran otra revisión	Puede continuar si no detecta restricciones
Documento interno	Herramienta no aprobada para información corporativa	Si la tarea puede realizarse en un entorno autorizado y con menos contenido	Usar solo la herramienta autorizada
Información interna necesaria para una tarea aprobada	Entorno corporativo autorizado	Si hace falta el documento completo o basta con un fragmento	Minimizar antes de usar
Datos personales	Herramienta o caso de uso no claramente autorizado	Finalidad, necesidad y condiciones de tratamiento	Detener y consultar
Credencial o API key	Prompt utilizado para revisar código	El secreto no es necesario para resolver la tarea	Eliminar la credencial antes de continuar

Una herramienta autorizada puede cambiar la decisión, pero no elimina las restricciones sobre la información. Del mismo modo, un contenido accesible públicamente puede requerir otra respuesta si incorpora datos personales, derechos de terceros o limitaciones sobre su reutilización.

Cuándo detener el envío y escalar

¿Qué situaciones deberían hacer que un empleado no pulse “enviar”? No hace falta memorizar una lista cerrada, pero sí reconocer señales claras:

• Ante categorías especiales de datos personales, conviene comprobar que el tratamiento y el caso de uso están expresamente contemplados antes de continuar.
• Contraseñas, tokens o claves privadas son una señal de parada: el secreto debe retirarse del contenido y, si ya se expuso, puede ser necesario avisar a Seguridad.
• Si un documento pertenece a un cliente o tercero y existen dudas sobre confidencialidad o derechos de uso, no debería asumirse que la herramienta corporativa basta.
• Una herramienta no autorizada es motivo suficiente para detener el envío cuando la información no sea pública o la política interna exija un entorno concreto.
• Cuando no esté claro si la anonimización es efectiva, es preferible escalar la duda antes de tratar el contenido como si hubiera dejado de ser personal.

Escalar no significa que el uso esté necesariamente prohibido. Significa que la decisión requiere información o autoridad que el empleado no tiene. El siguiente paso es identificar el canal adecuado, en lugar de recurrir siempre a un genérico “pregunta a Legal”.

Cómo aplicar estas reglas en situaciones reales

Una política resulta útil cuando el empleado sabe resolver una duda antes de enviar información. No todas las situaciones deben acabar en Legal ni todas las decisiones corresponden a Seguridad: el escalado depende del tipo de información, del riesgo y de quién tenga autoridad para resolverlo.

También importa detectar cuándo el problema no es el dato, sino la herramienta. Si las personas recurren a soluciones fuera de los entornos aprobados, la decisión individual puede convertirse en un problema más amplio de productividad en la sombra.

A quién consultar según el tipo de riesgo

No existe una distribución universal de responsabilidades, pero una organización debería dejar suficientemente claro quién resuelve la duda. Como orientación práctica:

• IT o Seguridad deberían intervenir ante herramientas no autorizadas, credenciales, integraciones, accesos o posibles exposiciones técnicas.
• Si aparecen datos personales, categorías especiales o dudas sobre las condiciones de tratamiento, conviene acudir a Privacidad, DPO o Legal, según la estructura de la empresa.
• Para contratos, propiedad intelectual, información estratégica o documentación de terceros, puede ser necesario involucrar al responsable del dato o del negocio además de las funciones jurídicas correspondientes.
• Cuando la información afecta a empleados o procesos de personas, RRHH puede coordinar el escalado con Privacidad, Legal o Seguridad según el contenido y el uso previsto.

El objetivo no es que el empleado determine por sí mismo qué normativa o cláusula contractual resulta aplicable. Su responsabilidad práctica es reconocer la señal de duda, detener el envío y activar el canal que la organización haya definido.

Tres escenarios: contrato, baja médica y código con credenciales

Un empleado necesita resumir un contrato de cliente para preparar una reunión. Antes de introducirlo completo debería comprobar si contiene información confidencial, datos personales o condiciones cuya divulgación esté restringida. Si la tarea puede resolverse con algunas cláusulas, conviene minimizar el contenido; si existen dudas sobre confidencialidad o la herramienta autorizada, debe escalar antes de continuar.

En otro caso, una persona de RRHH quiere utilizar IA para redactar una comunicación relacionada con una ausencia y dispone de un documento que incluye información sobre salud. La finalidad de redactar un texto no justifica automáticamente introducir esos datos. Al tratarse de una categoría especial de datos personales, la decisión adecuada es detenerse y comprobar con RRHH y Privacidad qué caso de uso y entorno están autorizados.

Un desarrollador, por último, pide ayuda para depurar un fragmento de código y descubre que contiene una API key real. La credencial no es necesaria para analizar el código, por lo que debe eliminarla antes de utilizar el fragmento. Si ya la ha enviado accidentalmente a un entorno no autorizado, además de retirar el dato puede ser necesario comunicar la exposición a Seguridad y gestionar la credencial según el procedimiento interno.

Los tres casos siguen la misma lógica: identificar la información, comprobar si es necesaria, revisar la herramienta y la finalidad y, cuando falte una respuesta clara, detenerse antes de enviar. Para desarrollar este criterio en quienes utilizan IA de forma habitual, una formación como Privacidad y seguridad en IA: Desafíos en el entorno corporativo puede complementar las políticas y controles técnicos de la organización.

Conclusiones

Usar IA con información corporativa exige algo más que saber redactar prompts. Antes de enviar contenido, el empleado debe entender qué información está tratando, para qué la necesita y si la herramienta elegida está autorizada para ese uso.

La decisión correcta no siempre es continuar o prohibir. A veces basta con minimizar datos, retirar una credencial o utilizar un entorno corporativo específico; en otros casos, lo adecuado es detenerse y escalar antes de exponer información personal, confidencial o estratégica.

Para OpenWebinars, esta capacidad forma parte de una alfabetización en IA realmente aplicada: personas que saben utilizar las herramientas con criterio, reconocer límites y proteger la información sin convertir cada decisión cotidiana en una consulta técnica o legal.