La IA no roba tus datos industriales. Se los estamos pegando nosotros

La exfiltración más cómoda de tu planta cabe en un portapapeles

Hay una conversación sobre IA que se repite en las empresas: qué modelo utilizar, qué procesos automatizar, cuánto tiempo se ahorra con Copilot, ChatGPT, Gemini o Claude. Perfecto. Pero hay otra bastante menos atractiva que convendría tener antes: qué información de planta estamos copiando dentro de esas herramientas.

La fuga de información industrial asociada a IA generativa no necesita ransomware, ni una CVE crítica, ni que un atacante atraviese cuatro firewalls. A veces necesita un ingeniero copiando veinte líneas de código de un PLC y preguntando por qué no funciona. Y ya está.

No es un escenario teórico. En 2023 Samsung acabó restringiendo internamente el uso de IA generativa después de que varios empleados pegaran código fuente y notas de reuniones en ChatGPT. Ninguno actuaba de mala fe: estaban trabajando.

El problema no es la IA, es el dato que le damos

Pensemos en usos perfectamente razonables. Un técnico pega una configuración de firewall para pedir ayuda con una regla. Mantenimiento sube un manual con anotaciones internas. Ingeniería introduce un fragmento de lógica de un PLC para depurarlo. Alguien copia parte de un informe de vulnerabilidades para que la IA prepare un resumen ejecutivo. Nada especialmente extravagante.

El problema aparece cuando dentro de esa información viajan direcciones IP, nombres de host, versiones de firmware, reglas de acceso, arquitecturas de red, credenciales, bloques de programa, parámetros de proceso, inventarios OT o vulnerabilidades todavía sin corregir.

Por separado pueden parecer datos poco interesantes. Juntos empiezan a contar una historia bastante buena sobre tu planta: qué tienes, cómo está conectado, qué versiones utilizas, qué equipos hablan entre sí, dónde están las debilidades y, con suerte para quien esté al otro lado, cómo acceder.

Llevamos años diciendo que una topología, un inventario y una matriz de comunicaciones son información sensible. Pues resulta que ahora tenemos interfaces fantásticas donde copiar las tres cosas en treinta segundos.

Shadow AI: el Shadow IT con esteroides

El problema tiene nombre nuevo, aunque tampoco hayamos inventado nada. Es el mismo Shadow IT de siempre, pero esta vez el servicio no almacena únicamente un PDF ni sincroniza una carpeta: puede recibir código, configuraciones, correos, documentos completos y datos extraídos de SharePoint, repositorios Git o conectores corporativos.

Y aquí empieza la parte interesante para CISO y CIO:

• ¿Sabes qué modelos están utilizando tus empleados, y con cuentas personales o corporativas?
• ¿Dónde se procesan los prompts y durante cuánto tiempo se retienen?
• ¿Se utilizan esos datos para entrenamiento?
• ¿La herramienta tiene conectores contra Microsoft 365, Google Workspace, GitHub o repositorios internos?
• ¿Quién ha autorizado esos conectores y quién puede consultar los logs?

Si la respuesta a varias de esas preguntas es "no lo sé", tienes un problema de gobierno bastante antes de tener un problema de IA.

En OT, el contexto importa mucho

En una red IT, filtrar un documento interno puede ser grave. En OT, filtrar contexto técnico es otra cosa.

Una arquitectura Purdue, las VLAN, los rangos IP, un listado de PLC, las versiones de firmware, qué estación utiliza cada herramienta de ingeniería, cómo se accede remotamente y qué firewall separa IT de OT no son simplemente datos técnicos. Son reconocimiento: exactamente el tipo de información que un atacante dedica tiempo a recopilar antes de intentar moverse por una red industrial.

Y ahí está la ironía. Durante años hemos intentado evitar que un atacante obtuviera esa información mediante escaneo y enumeración. Ahora podemos entregársela nosotros mismos dentro de un prompt. Mucho más cómodo.

"Tenemos ChatGPT Enterprise" no cierra la discusión

Utilizar servicios empresariales es mejor que dejar que cada empleado trabaje con su cuenta personal. Pero no basta con comprar una licencia y declarar resuelto el problema: hay que revisar la arquitectura completa.

Qué información puede introducirse. Qué modelos están autorizados. Qué conectores pueden activarse. Qué retención existe. Cómo se gestionan identidades y permisos. Si los prompts generan logs auditables. Qué ocurre con los ficheros adjuntos. Qué APIs utilizan las aplicaciones internas. Y dónde terminan los embeddings cuando alguien monta un RAG contra la documentación corporativa.

Porque un RAG privado puede ser una magnífica solución, hasta que conectamos toda la documentación técnica de planta a una base vectorial accesible por más usuarios de los que deberían. Entonces tenemos un problema nuevo, pero con arquitectura moderna.

Tres premisas que rompen la lista habitual

Aquí es donde la mayoría de artículos sobre este tema recitan lo mismo: DLP, MFA, logging, revisión de APIs. Está bien, y sirve para una gestora de fondos. En un entorno industrial hay tres premisas que rompen esa lista antes de empezar.

La estación de ingeniería no está donde tú crees. El equipo que tiene abierto el proyecto del PLC y la topología completa de la línea probablemente no esté bajo el MDM corporativo, no tenga agente de DLP y no pase por el proxy de la organización. Es un portátil que vive en planta, que a veces ni siquiera es de la empresa, y que hace exactamente lo que necesita hacer para que la producción no se pare. Cualquier control que dependa de un agente en el endpoint tiene ahí un agujero por diseño.

La clasificación de información en OT casi nunca existe. No como política escrita, que esa suele existir, sino como práctica real. Nadie ha etiquetado nunca el fichero de proyecto, la matriz de comunicaciones o el informe del último FAT. Si vas a prohibir introducir información sensible en herramientas de IA, primero tienes que ser capaz de decir cuál es, y en la mayoría de plantas esa lista no está hecha.

Buena parte de tu topología ya está fuera de tu perímetro. El integrador que hizo la puesta en marcha tiene el proyecto. El OEM tiene los esquemas. La ingeniería externa tiene la documentación de acceso remoto. Y ninguno está sujeto a tu política de uso de IA. El ingeniero de un tercero pegando la lógica del PLC de tu planta en su cuenta personal es hoy un escenario más probable que el de tu propio personal, y ninguna medida técnica tuya lo alcanza. Solo lo alcanza el contrato.

Por dónde empezar

Con eso encima de la mesa, el orden que tiene sentido es este.

Descubrir qué se está utilizando. No lo que IT cree que se utiliza, sino lo que realmente se utiliza. Los registros de DNS y del proxy dan una primera foto en una tarde. Conviene mirar tanto la red IT como los accesos desde la red industrial y las conexiones de terceros.

Definir qué no sale, en concreto. Nada de categorías abstractas: una lista corta y explícita con configuraciones de dispositivo, topologías y diagramas de red, código y bloques de PLC, inventarios OT, credenciales y certificados, informes de vulnerabilidades, documentación de acceso remoto y parámetros de proceso. Escrita en un lenguaje que un técnico de mantenimiento entienda sin abrir un anexo.

Cerrar el vector de la cuenta personal por donde se cierra de verdad. No con MFA, porque nadie usa el segundo factor corporativo para abrir un chatbot en su móvil. Se cierra con SSO obligatorio contra el servicio autorizado, control de egress o CASB para ver y bloquear el resto, y sobre todo con una alternativa sancionada igual de cómoda. Si la vía oficial es más lenta que la personal, la gente elige la personal. Siempre.

Extenderlo a la cadena de suministro. Cláusula de uso de IA generativa en contratos con integradores, OEM y mantenimiento externo. Es probablemente la medida de mayor impacto por unidad de esfuerzo de toda la lista, y la que casi nadie está aplicando todavía.

Trazabilidad. Logs de la plataforma autorizada hacia el SIEM. Si no puedes reconstruir qué se envió y quién lo envió, no tienes control: tienes una declaración de intenciones.

Y la parte menos tecnológica: explicárselo a la gente. Un ingeniero que jamás enviaría por correo una configuración de firewall a una dirección desconocida puede copiarla entera en un chatbot sin percibir el mismo riesgo. No es mala fe; es que la interfaz parece inocente.

Conviene además saber que esto ya no es solo buena práctica. El Reglamento Europeo de IA obliga a las organizaciones a garantizar un nivel suficiente de alfabetización en IA entre quienes la utilizan por cuenta de la empresa. Y para las entidades en el ámbito de NIS2, el control de accesos y la gestión de riesgos de proveedores ya son obligaciones exigibles, con IA o sin ella.

La IA no ha inventado la fuga de información

Como en tantas cosas de ciberseguridad, el problema de fondo tampoco es nuevo. Seguimos hablando de clasificación de información, control de accesos, gestión de terceros, mínimo privilegio, trazabilidad y prevención de pérdida de datos. Solo ha cambiado la interfaz, y esa interfaz es extraordinariamente fácil de utilizar.

Por eso la respuesta tampoco puede ser prohibir y mirar hacia otro lado. La prohibición sin alternativa no elimina el uso: lo hace invisible. Una organización con IA prohibida y usada a escondidas está bastante peor que una con IA autorizada, acotada y registrada. El Shadow AI no aparece a pesar de las políticas restrictivas; muchas veces aparece gracias a ellas.

Así que la pregunta que deberíamos hacernos en cualquier organización industrial no es si permitimos utilizar IA. Es bastante más concreta: ¿sabemos qué información de nuestra planta está entrando en herramientas de IA, quién la está enviando y dónde termina?

Porque la IA no necesita entrar en tu red OT para llevarse información de ella. A veces basta con que alguien pulse Ctrl+C, Ctrl+V.