Seguridad de los datos al usar IA en una empresa

Cada vez más empresas conectan la IA a CRM, soporte, marketing, analítica y bases internas de conocimiento. A medida que crece el valor, también crece el riesgo: en los prompts empiezan a aparecer datos personales, condiciones comerciales, correspondencia con clientes, contratos y documentación interna. Los problemas suelen surgir no por una "IA maliciosa", sino por controles de acceso débiles, logs mal gestionados, integraciones poco seguras y falta de reglas para el equipo. A continuación veremos de forma práctica cómo usar IA en la empresa sin fugas innecesarias ni sorpresas legales.

• el principal riesgo no está en el modelo, sino en qué datos se le envían;
• el peligro no viene solo de ataques externos, sino también de errores de empleados y proveedores;
• los servicios públicos de IA no siempre son adecuados para información sensible;
• la empresa necesita no solo NDA, sino también reglas de acceso, enmascaramiento y auditoría;
• una IA segura combina tecnología, procesos y contratos con proveedores.

Por qué este tema ya es crítico

Cuando la IA se usa de forma aislada, el riesgo parece pequeño: un empleado pide un borrador de correo, un gerente recibe una respuesta modelo, un marketer genera texto. Pero en la práctica, los prompts pronto incluyen:

• nombres, teléfonos, correos y el historial de pedidos de clientes;
• contratos, facturas, precios y descuentos;
• propuestas comerciales y políticas internas;
• fragmentos de código, tokens, claves de acceso y configuraciones;
• datos de RR. HH., currículums y evaluaciones de empleados.

Si esos datos van a un servicio inadecuado, se guardan en logs sin control o quedan accesibles para demasiadas personas, la empresa ya no tiene un "experimento con IA", sino un verdadero incidente de seguridad de la información.

Qué datos es especialmente peligroso enviar a la IA

No todos los datos tienen la misma sensibilidad. Para una empresa conviene dividirlos al menos en cuatro grupos:

Un error típico

Un empleado copia en un chat público "para trabajar más rápido" una solicitud de cliente, un fragmento de contrato o una tabla de ventas. El modelo ayuda, pero la empresa ya ha transferido datos a un sistema externo que no controla por completo. Aunque el proveedor prometa protección, sin contrato, política de retención y límites de acceso sigue siendo un punto débil.

Principales riesgos del uso de IA en una empresa

1. Fuga a través de los prompts

El escenario más común es que datos sensibles entren directamente en el texto de la solicitud. Esto pasa en ventas, soporte, RR. HH., contabilidad y desarrollo. Sin reglas claras, los empleados envían a la IA más información de la necesaria.

2. Logs e historial de solicitudes

Aunque la respuesta del modelo sea segura, los logs de solicitudes pueden almacenar los datos originales completos. El problema aparece cuando ese historial es accesible para varios equipos, proveedores o se conserva más tiempo del necesario.

3. Derechos de acceso excesivos

Si un bot de IA está conectado al mismo tiempo a CRM, correo, base de conocimiento y ERP, pero los permisos no están limitados, cualquier fallo o prompt incorrecto puede exponer demasiada información. En IA es especialmente peligroso el principio de "dar acceso a todo y luego ver".

4. Proveedor y transferencia transfronteriza

Muchos modelos y APIs operan en otra jurisdicción. Esto afecta a datos personales, acuerdos de procesamiento, plazos de retención y subprocesadores. Para algunos casos no es una prohibición, pero sí exige una arquitectura legal y técnica consciente.

5. Alucinaciones con consecuencias de negocio

El problema no es solo la fuga. Si la IA inventa con seguridad condiciones de contrato, promete a un cliente un descuento inexistente o clasifica mal una solicitud, la empresa sufre un daño directo. Por eso, la seguridad de la IA también implica controlar la calidad de las decisiones, no solo proteger la base de datos.

Qué debe hacer la empresa antes del lanzamiento

La seguridad no aparece después del primer incidente, sino en la fase de diseño. Un mínimo práctico sería:

1. Describir los casos de uso. Quién envía datos a la IA, para qué, de dónde salen y adónde vuelve la respuesta.
2. Separar los datos por sensibilidad. Qué puede ir a un modelo público, qué solo a uno corporativo y qué no debe enviarse nunca.
3. Limitar accesos. Bots y empleados deben ver solo el volumen de datos necesario para cada tarea.
4. Configurar el enmascaramiento. Eliminar de los prompts nombres, números de documento, datos de pago, tokens y otros identificadores innecesarios.
5. Revisar los contratos del proveedor. Importan el DPA, la retención de logs, el entrenamiento con datos, la región de procesamiento y los subprocesadores.

Medidas prácticas de protección

Política para empleados

Hace falta una instrucción corta y clara, no un documento abstracto de 40 páginas. El empleado debe saber:

• qué datos no se pueden pegar en una IA pública;
• en qué casos hace falta una herramienta corporativa;
• cuándo una respuesta de IA debe ser revisada por una persona;
• a quién informar sobre un error o una respuesta sospechosa.

Medidas técnicas

Para la mayoría de las empresas, estas medidas básicas son útiles:

• SSO y control de acceso por roles;
• registro de interacciones con la IA;
• enmascaramiento automático de datos personales;
• bloqueo del envío de secretos y claves;
• una pasarela o middleware separado antes de la API externa;
• límites a la exportación de datos desde sistemas internos.

Medidas organizativas

Ni siquiera una buena tecnología funciona sin procesos. Conviene asignar responsables de:

• aprobar los escenarios de uso de IA;
• conceder acceso a nuevos empleados y proveedores;
• revisar periódicamente roles y permisos;
• analizar incidentes y actualizar reglas;
• formar al equipo para trabajar con IA de forma segura.

Cuándo hace falta IA corporativa y no pública

Un servicio público no sirve para todas las tareas. Es mejor un entorno corporativo cuando:

• el flujo incluye datos personales de clientes o empleados;
• la IA accede a contratos, finanzas o analítica interna;
• las respuestas influyen en precios, condiciones, contratación o procesos jurídicamente relevantes;
• se necesita controlar logs, roles, región de almacenamiento y desactivar el entrenamiento con datos de la empresa.

Para tareas sensibles, muchas empresas usan una capa intermedia: limpia la solicitud, oculta campos innecesarios, registra la interacción y solo entonces envía datos desidentificados a un modelo externo o a un entorno interno de RAG.

Checklist antes de la implantación

Antes de producción conviene comprobar:

• si existe un mapa de datos que muestre qué entra en la IA;
• si los campos sensibles están enmascarados;
• si los roles y accesos están limitados;
• si están firmados los acuerdos necesarios con el proveedor;
• si está claro el plazo de retención de logs;
• si existe una vía de escalado a una persona;
• si hay un responsable de incidentes asignado;
• si los empleados conocen las reglas básicas.

Resumen

La seguridad de los datos al usar IA en una empresa no es una prohibición de las redes neuronales, sino gestión del riesgo. La empresa obtiene valor de la IA cuando entiende con claridad qué datos puede transferir, quién recibe acceso, dónde se guardan los logs y quién responde por el resultado. Si se implanta IA sin esas reglas, la mayor velocidad se convierte rápidamente en riesgo de fuga, multas y errores operativos. Sale mucho más barato diseñar desde el principio control de acceso, enmascaramiento y revisión humana que resolver las consecuencias después.

Si necesita un escenario seguro de implantación de IA para un sitio web, bot o proceso interno, contáctenos.

Preguntas frecuentes

¿Pueden los empleados usar ChatGPT o Claude normales para tareas de trabajo?

Solo en escenarios donde no haya datos sensibles y existan reglas internas claras. Si los empleados pegan en una IA pública solicitudes de clientes, contratos, precios o documentos internos, aparece un riesgo de fuga y problemas legales. Para trabajar de forma habitual con datos de la empresa, es mejor usar un entorno corporativo o una capa intermedia propia.

¿Qué datos no deben enviarse a la IA sin una revisión aparte?

Ante todo, datos personales, contratos, información financiera, claves API, contraseñas, condiciones comerciales y correspondencia interna. Aunque el modelo se use "solo para un borrador", enviar esos datos sin enmascaramiento y sin un proceso aprobado crea un riesgo innecesario. Cuanto más fácil sea identificar a una persona, cliente o sistema a partir de esos datos, más cuidado debe tener el flujo.

¿Basta con firmar un NDA con empleados y proveedores?

No. Un NDA ayuda, pero no sustituye la protección técnica. Si un empleado puede acceder a todos los sistemas y no hay límites para copiar datos a la IA, el documento por sí solo no resuelve el problema. Se necesitan roles, registros, restricciones a la exportación y una política clara de uso de IA.

¿Cómo reducir el riesgo de fuga si la IA ya está conectada a CRM y a la base de conocimiento?

Empiece por el principio de mínimo acceso necesario: la IA debe recibir solo los campos y documentos que necesita para la tarea. Después añada enmascaramiento de datos personales, registro de interacciones, limitación de roles y revisión manual en escenarios críticos. Una buena práctica es poner una capa separada entre los sistemas internos y el modelo para filtrar solicitudes y bloquear el envío de información extra.

¿Hace falta un responsable específico de seguridad de IA en una empresa pequeña?

Sí, al menos como función, no necesariamente como puesto separado. Alguien debe responder por las reglas de acceso, la aprobación de escenarios, la relación con el proveedor, la revisión de logs y la gestión de incidentes. En una pyme puede ser un jefe de proyecto, CTO o proveedor externo, pero la responsabilidad debe asignarse de forma explícita.