¿Es seguro usar IA con datos de empresa? Guía RGPD y AI Act

La pregunta que frena la mayoría de los proyectos de IA

Usar inteligencia artificial con datos de empresa es seguro siempre que se cumplan tres condiciones: que el dato que sale de tu organización esté justificado, que el tratamiento esté respaldado por una base legal, y que exista un control sobre qué puede leer el sistema y qué hace con lo que lee. Sin esas tres cosas, ninguna herramienta es segura; con ellas, la mayoría de los usos habituales en una pyme lo son.

En seguridad inteligencia artificial para empresas, la pregunta casi nunca es si la tecnología es segura, sino qué dato concreto sale de tu organización, quién lo ve y bajo qué garantía. Resolverlo por escrito es lo que separa un proyecto que supera una revisión de uno que se paraliza en el comité de seguridad.

La pregunta no es “la IA es segura o no”. Es qué dato concreto vas a meter, en qué sistema, bajo qué base legal y con qué garantías. Cuando esa pregunta está respondida, la decisión es técnica y barata. Cuando no, el proyecto se paraliza en el comité de seguridad o, peor, se ejecuta a ciegas.

La seguridad de la inteligencia artificial para empresas y la privacidad de la IA en el trabajo son, en el fondo, la misma pregunta: qué sale de tu organización, quién lo ve y bajo qué garantía. Por eso, cuando un equipo pregunta por la privacidad IA en su empresa, la respuesta nunca es “compra un producto”: es decidir qué datos se procesan, con qué base legal y con qué garantías. Este artículo recorre el marco que aplicamos en los proyectos de consultoría de IA para empresas: qué datos admiten las herramientas de IA, qué obligaciones introduce el RGPD y el Reglamento Europeo de IA, y qué cinco medidas concretas puedes aplicar esta semana.

El riesgo no está en usar IA. Está en usarla sin haber decidido, por escrito, qué datos salen de tu empresa y bajo qué garantía.

De qué hay que protegerse realmente

Antes de hablar de normativa conviene separar el ruido. Cuando alguien pregunta si la IA es segura, suele estar mezclando cuatro riesgos con respuestas muy distintas:

Riesgo real	Qué ocurre en la práctica	Cómo se controla
Filtración de datos	Un prompt incluye información de un cliente y esa información acaba en un registro del proveedor	Minimización del dato y clasificación previa
Alucinación	El sistema inventa un dato que se usa para decidir sobre una persona o un contrato	Verificación humana y trazabilidad de la fuente
Acceso indebido	Un sistema con permisos excesivos lee información que no necesitaba	Límite de permisos y principio de mínimo acceso
Imposibilidad de explicar	Cuando ocurre un problema, nadie sabe qué datos se procesaron ni con qué instrucción	Registro de la actividad y diseño documentado

La tabla importa porque cada riesgo tiene un dueño distinto: el primero y el tercero son del responsable de sistemas, el segundo del responsable del proceso y el cuarto del responsable legal. En las empresas que han tenido problemas, la causa nunca es la herramienta: es que nadie se asignó la responsabilidad de responder a esa pregunta concreta.

Conviene decir también lo que no es un riesgo real: que el modelo “se acuerde” de un dato entre conversaciones es un caso particular de fuga, y se corrige con el diseño del acceso, no con un aviso a los usuarios. No hay un interruptor de “modo seguro” en estos sistemas: la seguridad se diseña antes de conectarlos y se demuestra después.

Cuándo es seguro usar IA con datos de empresa

La pregunta se responde combinando cuatro variables, no con un sí o un definitivo:

1. Qué dato. No todo lo que hay en tu empresa tiene el mismo nivel de sensibilidad. Un precio o un texto de marketing no es comparable con un historial clínico o la información fiscal de un cliente.
2. Quién lo trata. Un chat de uso individual y una plataforma empresarial con contrato, residencia del dato en la UE y gestión de accesos no ofrecen la misma garantía, aunque el modelo sea el mismo.
3. Para qué se usa. Procesar un correo para extraer un dato de una factura y usarlo para preparar un diagnóstico médico tienen niveles de exigencia distintos.
4. Quién responde. Si la decisión final la firma una persona y puede justificarse, hay un control humano. Si el sistema decide y nadie revisa, no.

El dato nunca debería salir sin clasificarlo

La clasificación previa es lo que separa un uso legítimo de una fuga. En la práctica son tres niveles, y basta con asignar el dato a uno antes de escribir el prompt:

• Datos sin datos personales. Catálogos, precios, descripciones de producto, procesos internos. Se pueden trabajar en herramientas generalistas sin más cautela.
• Datos personales identificables. Nombre, correo, teléfono, dirección, historial de cliente. Solo en plataformas empresariales con contrato y sin uso del dato para entrenar modelos, y minimizando: si el prompt no necesita el nombre, no lo incluyas.
• Datos sensibles o de terceros. Salud, datos bancarios, información fiscal, propiedad intelectual no cedida, datos de clientes de otros. Aquí la respuesta por defecto es no, salvo que exista una base legal y un tratamiento documentado.

Este último nivel no es una categoría residual. Cualquier dato personal entra en algún nivel de riesgo —el RGPD no distingue entre “dato importante” y “dato poco importante”— pero hay una diferencia operativa decisiva: los datos de salud, los datos biométricos y los datos de menores tienen una protección reforzada en el artículo 9 del RGPD y requieren una base legal reforzada y, en muchos casos, una evaluación de impacto. La AEPD publica el procedimiento para esa evaluación.

La regla práctica: si el dato identifica a una persona y la decisión afecta a esa persona, hay que documentar la base legal antes de automatizar. Si solo se usa para redactar un texto interno, el listón es más bajo.

El error más caro no es meter un dato sensible en una herramienta: es automatizar una decisión sobre una persona sin base legal, sin control humano y sin registro de por qué se tomó.

Qué dice el RGPD: la parte que más se olvida

El RGPD no prohíbe la IA. Regula el tratamiento de datos personales, y la IA no cambia ninguno de sus requisitos: base legal, información al interesado, minimización, seguridad, registro de actividades y, cuando el riesgo es alto, evaluación de impacto. IA y RGPD no son temas distintos: es el mismo marco aplicado a un tipo de tratamiento que antes no existía a esta escala.

Lo que cambia con la IA es el número de tratamientos que se pueden generar sin darse cuenta. Un formulario pide tres datos. Un proceso automatizado con IA puede acabar procesando veinte, en tres países y con cuatro subencargados que nadie ha revisado.

El registro de actividades: el documento que casi nadie tiene

El RGPD obliga a llevar un registro de las actividades de tratamiento: qué datos, con qué finalidad, quién es responsable, qué base legal, con qué transferencias. En una empresa que ya usa IA esto es una tarea nueva, porque cada uso de IA con datos personales es un tratamiento. El registro no lo hace el proveedor: lo hace quien decide qué datos entran. La tarea es más pequeña de lo que parece si se empieza por los usos grandes en lugar de catalogar cada prompt individual.

El RGPD no es el único problema: la transferencia internacional

Aquí está la duda que más nos llega y la que menos se formula en las reuniones internas. Si la herramienta que usas está alojada fuera de la Unión Europea, los datos personales que introduces se transfieren a un tercer país. Eso tiene un régimen propio.

Según la AEPD, una transferencia internacional no necesita autorización de la Agencia siempre que se dé alguna de estas situaciones:

• El destinatario está en un país o territorio declarado de nivel de protección adecuado por la Comisión Europea. Incluye Reino Unido, Japón, Canadá, Corea, Brasil, Israel y otros. Estados Unidos solo si el proveedor concreto está autocertificado en el marco EU-US Data Privacy Framework.
• Existen garantías adecuadas aportadas por el exportador: cláusulas contractuales tipo de la Comisión Europea, normas corporativas vinculantes del grupo, o un código de conducta o mecanismo de certificación reconocido.
• La transferencia encaja en una excepción del artículo 49: consentimiento explícito de la persona, ejecución de un contrato con ella, cumplimiento de una obligación legal, o similares.

La consecuencia práctica: la pregunta útil para tu proveedor no es “los datos se cifran?”, sino “¿dónde se procesan, con qué garantías y en qué contrato me comprometo a no usarlos para entrenar modelos?” Esa información está en el acuerdo de tratamiento de datos, no en la web del producto.

Cuando la transferencia no está cubierta ni por una decisión de adecuación ni por garantías adecuadas, el tratamiento requiere una autorización previa de la AEPD. Es un escenario poco frecuente cuando se elige bien el proveedor, pero es exactamente el que se descubre tarde si no se revisó el contrato antes de empezar.

La verificación que evita el 90 % de los problemas de cumplimiento con IA: leer el contrato de tratamiento de datos del proveedor antes de comprar la licencia, no después del primer incidente.

La evaluación de impacto, cuando toca

La evaluación de impacto en protección de datos es obligatoria en casos concretos, no en todos. Se exige, entre otros supuestos, cuando el tratamiento implica decisiones con efectos jurídicos sobre personas, cuando se realiza a gran escala, o cuando hay datos sensibles y un tratamiento системático. Un sistema que cualifica clientes o filtra currículums con IA y decide a quién se encamina encaja en este supuesto con frecuencia. La decisión de no realizar la evaluación también debe documentarse, con su justificación.

Qué exige el Reglamento Europeo de IA

El Reglamento (UE) 2024/1689, conocido como AI Act, es la pieza que se ha incorporado al debate en los últimos años. Su calendario de aplicación es progresivo: las prohibiciones y las obligaciones de alfabetización en IA son aplicables desde el 2 de febrero de 2025, las obligaciones sobre modelos de propósito general, gobernanza y confidencialidad desde el 2 de agosto de 2025, y el resto del Reglamento es aplicable desde el 2 de agosto de 2026. Puede consultarse la cronología oficial de aplicación.

Tu rol importa más que la tecnología

El Reglamento distingue entre quien desarrolla el sistema y quien lo utiliza. Casi todas las empresas que se plantean esta pregunta son usuarias, no proveedoras. Y para el usuario las obligaciones son más livianas que para el proveedor: informar a las personas cuando interactúan con una IA, no manipular la decisión mediante IA, y garantizar la supervisión humana cuando el uso es de alto riesgo.

Cuándo el sistema es de alto riesgo

La clasificación depende del uso, no de la tecnología. Un mismo modelo puede ser una herramienta de redacción (riesgo bajo) o el motor que decide qué candidatos pasan a una entrevista (alto riesgo), según el Anexo III y el artículo 6. Un sistema de selección de personal o de evaluación de candidatos es uno de los casos de alto riesgo más habituales, junto con la gestión de riesgos en crédito y los sistemas de identificación y seguros.

La interacción con las personas

Si el sistema se dirige directamente a personas —un asistente en la web, un sistema de respuesta automática— hay obligaciones de transparencia: la persona tiene que saber que está hablando con una IA. En la práctica, eso se resuelve con un aviso visible y honesto, sin más.

El AI Act no es un prohibitorio para las empresas: es un catálogo de obligaciones según el uso. Saber en qué categoría cae tu sistema es la mitad del trabajo, y no requiere un jurista para empezar.

El marco de decisión: cuatro preguntas antes de conectar

La forma más útil de resolver la duda es reducirla a cuatro preguntas contestables. Si las cuatro tienen respuesta satisfactoria, el uso es defendible y puedes documentarlo. Si alguna falla, el proyecto no está bloqueado: está mal diseñado todavía.

1. ¿Qué dato entra exactamente? Escribe el prompt literal que vas a usar, con los datos reales. No “datos de clientes”, sino el nombre, el correo y el histórico de compra. Si al leerlo te incomoda, ese es tu dato.
2. ¿Quién es el responsable del tratamiento y cuál es la base legal? Para automatizar una decisión sobre una persona, hace falta una base legal explícita. Si no la tienes, empieza por obtenerla.
3. ¿Dónde se procesa y bajo qué garantías? Ubicación del procesamiento, contrato de tratamiento de datos, compromiso de no usar los datos para entrenar modelos, y si la transferencia a un tercer país está cubierta.
4. ¿Quién revisa y qué queda registrado? La persona que valida las salidas del sistema, con qué criterio, y qué se guarda de cada ejecución para poder justificar una decisión meses después.

Estas cuatro preguntas son, en la práctica, el documento que una empresa necesita tener antes de conectar IA a un sistema que toca datos de clientes. No es un documento largo: es un par de páginas que evita el escenario caro.

El orden de trabajo que funciona

1. Inventariar los usos previstos, no las herramientas. Un proceso, un objetivo.
2. Clasificar el dato que entra en cada uso con los tres niveles descritos.
3. Aplicar las cuatro preguntas solo a los usos que tocan datos personales.
4. Documentar la base legal, el proveedor, el contrato y el responsable de cada uso que las supere.
5. Definir la revisión humana y el registro antes de ponerlo en producción.

Este orden es intencionado: la clasificación del dato es la que descarta rápido la mitad de los usos, y es la que no requiere presupuesto ni proyecto.

La mayoría de los “no” que escuchas en el comité de seguridad no son un no a la IA: son un no a un uso mal definido que se puede rehacer en una tarde.

Un caso real: por qué la respuesta fue “sí, pero así”

Una empresa de servicios profesionales con tres oficinas en Andalucía conectó IA a dos procesos distintos. La decisión no fue sobre la herramienta, sino sobre el uso.

Proceso 1 — Resumen de documentación de clientes para preparar una reunión comercial. El dato que entraba: histórico de interacción, sin datos de salud ni categorías especiales. La base legal: la ejecución del contrato con el cliente. El proveedor: plataforma empresarial con contrato en la UE y compromiso de no entrenar con los datos. La salida se revisaba a mano antes de llegar al comercial.

Proceso 2 — Priorización de oportunidades de venta. Un sistema puntuaba a cada cliente para decidir a qué comercial se le asignaba. Aquí el equipo se detuvo. No por la tecnología, sino por tres razones concretas: la puntuación condicionaba el trato comercial de personas identificables, no existía una base legal documentada para automatizar esa decisión, y nadie había diseñado cómo se explicaría a un cliente que su oportunidad había sido priorizada automáticamente.

El resultado fue distinto en cada caso, y en ninguno se descartó la IA. En el primero se implantó en semanas. En el segundo, la prioridad se convirtió en una propuesta de asignación manual assistida por resúmenes: la IA proponía, la persona decidía y el motivo quedaba registrado.

El coste de la segunda vía fue mayor en tiempo de diseño y mucho menor en exposición: ese intercambio no es exotismo regulatorio, es la forma de hacer que un proyecto sobreviva a una revisión.

Casi ninguna de esas decisiones se tomó por el nivel tecnológico. Se tomaron por una pregunta sobre el dato y una pregunta sobre quién responde.

Las cinco medidas que puedes aplicar esta semana

Si tienes que hacer algo mañana, esta es la lista. Cuesta poco y elimina la mayor parte del riesgo:

1. Escribe una política de uso de IA en una página. Qué herramientas están permitidas, cuáles no, qué datos no se pegan nunca y quién pregunta cuando no esté claro. Publicarla reduce el riesgo más que cualquier configuración, porque el uso indebido viene casi siempre de un empleado que no sabía la regla.
2. Clasifica los datos de la empresa en tres niveles y dales un color. En una pyme, una tabla con tres filas basta.
3. Pasa a una plataforma empresarial con contrato para todo uso que toque datos de clientes. La versión de consumo y la de empresa no ofrecen las mismas garantías, y la diferencia de coste es pequeña comparada con el riesgo.
4. Registra cada uso de IA con datos personales en el registro de actividades: proceso, dato, base legal, proveedor, responsable. Una fila por uso, no por prompt.
5. Diseña el punto de revisión humana antes del piloto, no después. Si el sistema no tiene un sitio claro donde una persona valide, todavía no está listo para producción.

Si además quieres dejar el marco formal cerrado, la formación en IA para tu equipo cubre la parte que ninguna configuración técnica cubre: el criterio de la persona que decide si un dato se pega o no.

El siguiente paso

La pregunta “es seguro usar IA con datos de empresa” tiene respuesta, y es afirmativa bajo condiciones concretas: datos clasificados, base legal, control de permisos y una persona que responde. Lo que no tiene respuesta automática es si tu caso concreto cumple esas condiciones, porque depende de qué sistemas usas, qué proveedores tienes contrato con y qué decides automatizar.

En Pheria hacemos una revisión de implantación segura en la que revisamos tus usos de IA actuales o previstos, clasificamos los datos, identificamos los puntos de riesgo reales de tu caso y te entregamos por escrito qué se puede conectar, cómo y con qué garantías. El resultado es un documento que la empresa se queda —inventario de usos, clasificación del dato, bases legales, proveedores con su ubicación de procesamiento y puntos de revisión humana— que sirve para implementar el proyecto y para responder a una auditoría o a un cliente que pregunte. Sin informe de marketing y sin compromiso de proyecto: primero saber si es seguro, después decidir si conviene.

Revisar una implantación segura

Para preparar la conversación, te puede servir la guía para implementar IA en tu empresa y el listado de procesos automatizables con IA. Y si el debate no es solo el cumplimiento sino la elección de herramienta, está el ChatGPT vs. agente de IA: muchas decisiones de seguridad se toman antes, cuando se elige qué se conecta.