El dilema de los equipos de TI: ¿un dominio .ai realmente transporta tráfico de IA?

Que .ai aparezca en la dirección del paquete no demuestra que este envíe solicitudes a un modelo de inteligencia artificial en la red; solo el registro de solicitudes, el punto de conexión de destino y los datos transportados pueden demostrarlo.

Esta distinción puede parecer pequeña, pero tiene consecuencias considerables para la TI corporativa. El dominio de una plataforma de formación puede incluir «ai», su presentación puede hablar de inteligencia artificial e incluso la plataforma puede usar inteligencia artificial en algunos flujos de trabajo. Nada de ello significa que la formación SCORM que se está examinando en ese momento esté comunicándose con un servicio de IA.

El paquete SCORM que una organización carga para una formación de PRL o RGPD puede contener únicamente HTML, JavaScript, imágenes, vídeo, preguntas y comunicación SCORM estándar. En ese caso, lo que hace el paquete es registrar en el LMS el progreso, la puntuación, la finalización y, a veces, la duración. Ese es su comportamiento real en la red. No lo que sugiere el nombre de dominio.

La pregunta principal para los equipos de TI debería ser:

No «¿cómo se denomina este contenido?», sino «¿a qué destino envía el navegador qué datos y con qué propósito?»

Este enfoque a veces puede parecer más laborioso. Pero la seguridad consiste en parte precisamente en eso: examinar el comportamiento, no las etiquetas de los nombres. No se puede saber qué hay dentro de una caja porque ponga «juego de química» en la parte superior. A la gente le gusta confiar en las etiquetas de las cajas; los paquetes de red, sin embargo, no respetan mucho ese hábito.

Un nombre de dominio no es una clasificación tecnológica

La extensión de un nombre de dominio no es una declaración técnica. .ai, .com, .org u otra extensión no explica con qué servicios se comunica una aplicación, dónde procesa los datos ni qué información extrae del cliente.

Del mismo modo, que aparezca la palabra «IA» en el folleto de un producto no es por sí solo un hallazgo de seguridad. El folleto puede explicar para qué problemas utiliza inteligencia artificial el producto. Un registro de red, en cambio, muestra qué hace realmente el componente que se ejecuta en ese momento. Confundir ambos convierte una revisión de arquitectura en la lectura de un texto de marketing.

En Nextrain, la inteligencia artificial puede utilizarse para la creación de formación, la estructuración de contenidos, la generación de preguntas, el diseño de recorridos de aprendizaje y la elaboración de informes. Además, se pueden importar paquetes SCORM 1.2 y SCORM 2004; es decir, los contenidos que la organización haya creado previamente u obtenido en otro lugar pueden gestionarse bajo un mismo techo.

Estas dos situaciones son distintas:

Quizá la fila más importante de la tabla sea la tercera: ¿se invoca realmente una función de IA? Que exista una función de IA en el producto no significa que todos los cursos, todos los usuarios y todas las sesiones la utilicen.

Se parece a asumir que, en un edificio electrificado, el horno funciona al mismo tiempo en todas las habitaciones. Puede haber cableado; la carga surge cuando se enciende el interruptor.

¿Qué hace realmente un paquete SCORM?

SCORM es un estándar que permite que la formación se comunique con el LMS. Un paquete suele incluir archivos de contenido, un manifiesto de contenido y JavaScript que gestiona el progreso de la formación. Cuando el paquete se abre dentro del LMS, el contenido puede acceder a la API estándar de SCORM mediante el navegador y transmitir información como:

• Si se ha iniciado la formación,
• El estado de finalización,
• El estado de éxito o aprobación,
• La puntuación de la prueba,
• El tiempo dedicado a la formación,
• En algunos diseños, datos de respuestas o interacciones.

Las diferencias entre SCORM 1.2 y SCORM 2004 pueden ser importantes; sin embargo, la pregunta esencial en una revisión de tráfico de IA no cambia: ¿con qué destino se comunica el paquete fuera de los registros de aprendizaje estándar del LMS?

Un paquete SCORM es técnicamente contenido web que se ejecuta en el navegador. Por ello, código JavaScript personalizado añadido al paquete puede intentar generar diferentes solicitudes de red, en la medida en que se le permita. Un paquete puede cargar una imagen externa, llamar a un vídeo, enviar datos de analítica o realizar una solicitud a una API. Incluso puede conectarse al punto de conexión de un servicio de IA si así lo desea el diseñador.

Pero entre «puede hacerlo» y «lo está haciendo» hay tanta diferencia como una puerta de enlace de red.

El propio estándar SCORM no requiere llamadas de inteligencia artificial. El estándar se ocupa del registro del estado de aprendizaje [SCORM 1.2, 2001; SCORM 2004, 2004]. Por tanto, colocar automáticamente la etiqueta de «riesgo de IA» al ver un paquete SCORM no es una clasificación técnica, sino el primo precipitado de la prudencia.

¿Dónde debería mirar primero el equipo de TI?

Una evaluación de seguridad debe mapear el flujo de datos en lugar de clasificar el producto con una sola palabra. Creo que el punto de partida correcto es dividir la pregunta «¿hay IA?» en partes más observables.

1. Abra el contenido del paquete y lea el manifiesto

Un paquete SCORM suele ser un archivo comprimido. La revisión puede comenzar con estos archivos:

• imsmanifest.xml
• Páginas HTML
• Archivos JavaScript
• Archivos de configuración
• Direcciones de recursos externos
• Enlaces a vídeo, imágenes y PDF

El manifiesto muestra el punto de entrada y los recursos del paquete. Por sí solo puede no describir todo el comportamiento de red; pero es un buen comienzo para comprender la estructura del paquete.

En los archivos JavaScript se deben buscar especialmente las siguientes expresiones:

fetch(
XMLHttpRequest
WebSocket
EventSource
sendBeacon
axios
https://
wss://

Encontrar estas palabras no constituye automáticamente un hallazgo de riesgo. El contenido web moderno puede realizar solicitudes de red. La revisión no termina aquí; se examina a qué dominio, con qué datos y en qué momentos se realiza esta llamada.

Que un curso se dirija a una dirección de medios para cargar un vídeo no es lo mismo que enviar la pregunta de texto libre de un usuario al punto de conexión de un modelo generativo. Ambos son «tráfico»; pero sus perfiles de riesgo, categorías de datos y requisitos de control son diferentes.

2. Observe el registro real de red en el navegador

Un paquete SCORM debe ejecutarse en un entorno de prueba con el flujo normal de un usuario. No basta con abrir la pantalla principal. Se debe resolver el cuestionario, avanzar por las secciones, abrir el vídeo, completar los campos de texto libre si los hay y finalizar el proceso de completado.

Después, deben plantearse las siguientes preguntas en los registros de red del navegador:

• ¿A qué dominios van las solicitudes?
• ¿Cuál es el método de solicitud: GET, POST, PUT?
• ¿Qué contiene el cuerpo de la solicitud?
• ¿La respuesta llega en flujo continuo?
• ¿La solicitud se produce cuando el usuario realiza una acción?
• ¿La misma solicitud se produce en todas las sesiones o solo en una interacción específica?
• ¿El tráfico se limita al dominio del LMS o hay nuevos destinos externos?

En particular, las solicitudes POST requieren atención. Porque pueden indicar que se envían datos desde el cliente. Sin embargo, no todo POST es una llamada de IA: también podría ser un registro de puntuación, envío de formulario, gestión de sesión o registro de eventos. Concluir «hemos visto un POST, hay IA» sin hacer esta distinción es como pensar que cada nube es un incendio al ver lluvia.

3. Lea conjuntamente los registros de DNS, proxy y cortafuegos

Las herramientas de desarrollo del navegador son útiles; sin embargo, la visibilidad de la red corporativa es más amplia. Siempre que sea posible, el equipo de TI debería comparar los siguientes registros en el mismo intervalo de tiempo:

• Consultas DNS,
• Registros de pasarela web segura o proxy,
• Registros de salida del cortafuegos,
• Registros de acceso a aplicaciones,
• Solicitudes de CDN y medios,
• Eventos de autenticación.

Que un contenido acceda solo a dominios aprobados es un comportamiento de red explicable y limitado. En cambio, las llamadas a puntos de conexión nuevos o desconocidos deben investigarse. El criterio no debería ser «¿su nombre parece de IA?». Algunos servicios de IA pueden usar dominios de apariencia corriente; algunas plataformas completamente ajenas a la IA pueden tener una extensión .ai.

Desde la perspectiva de la red, las extensiones son decoración; los registros de redireccionamiento son evidencia.

¿Qué señales importan para distinguir el tráfico de IA?

El tráfico de IA no tiene una única firma técnica. Sin embargo, algunas señales pueden orientar la revisión hacia el lugar correcto.

En una interacción de IA generativa, suele observarse lo siguiente:

• El texto libre escrito por el usuario aparece en el cuerpo de la solicitud,
• Se envían fragmentos de texto largos o contenidos de documentos,
• La solicitud y la respuesta avanzan en formato de conversación,
• Se recibe una respuesta en flujo continuo,
• Se genera texto dinámico que cambia según la pregunta del usuario,
• Hay una estructura de llamada dirigida a un modelo o servicio de inferencia.

En cambio, los siguientes comportamientos no constituyen por sí solos una llamada de IA:

• Registrar el estado de finalización de SCORM,
• Enviar la puntuación de un cuestionario,
• Registrar un evento de reproducción de vídeo,
• Verificar la condición de un certificado,
• Informar del progreso de la formación,
• Cargar archivos de imágenes, fuentes o vídeo.

En Nextrain pueden diseñarse interacciones como ayuda asistida por IA dentro de la formación. Si se utiliza una interacción de este tipo, el equipo de TI debe evaluarla como un flujo independiente. En cambio, el comportamiento de un paquete SCORM clásico que no incluye interacción de IA debe evaluarse mediante el contenido del paquete y sus rastros de red. Que estén en la misma plataforma no demuestra que tengan el mismo comportamiento de red.

En este punto recuerdo la persistente distinción que hace Kalde al escribir escenarios: en una historia, lo que cambia el resultado no es ante qué puerta está el personaje, sino qué elección hace. En la revisión de red, el dominio es la puerta; la solicitud es la elección. La decisión de seguridad debe basarse en la segunda.

¿Por qué «bloquearlo todo» no es una política suficiente?

Es comprensible que las organizaciones sean cautelosas con la inteligencia artificial. Especialmente cuando están en juego datos cubiertos por el RGPD, información de clientes, secretos comerciales, datos de salud o datos de rendimiento de empleados, la cautela no es un exceso, sino un requisito de diseño.

Pero bloquear todo bajo una única categoría puede ocultar dos costes diferentes:

1. Los riesgos reales pueden pasar desapercibidos.
   Un servicio sin extensión .ai también puede extraer datos. El filtrado por nombre de dominio no sustituye el control del flujo de datos.

2. Los flujos de formación inocuos o necesarios pueden interrumpirse.
   Si se bloquea contenido SCORM que no realiza llamadas de IA solo por la asociación de su dominio, los empleados no podrán acceder a la formación; y TI no podrá explicar con claridad qué comportamiento técnico ha bloqueado.

La situación más interesante que he encontrado es esta: la misma organización puede decir por un lado «bloqueemos todo lo que contenga IA» y, por otro, preguntar por qué el informe de formación no está actualizado. Esta contradicción no es malintencionada. A menudo, las personas consideran en pantallas distintas la protección frente al riesgo y la continuidad de la operación. Los sistemas, sin embargo, tienen que vivir ambas cosas a la vez.

Una política mejor realiza las siguientes distinciones antes de aplicar una prohibición categórica:

• ¿Se está utilizando una función de IA?
• Si se utiliza, qué datos se envían?
• ¿Estos datos contienen datos personales, datos sensibles o información confidencial interna?
• ¿A qué punto de conexión aprobado se dirige la solicitud?
• ¿Las condiciones de transferencia y conservación de datos cumplen la política corporativa?
• Si no se utiliza una función de IA, el contenido funciona con el flujo SCORM estándar?

Esto no significa relajar la seguridad. Al contrario, hace que el control sea más preciso.

Lista de comprobación aplicable para la revisión de SCORM e IA

Los equipos de TI, seguridad de la información, legal y formación examinan el mismo archivo con preguntas diferentes. Lo más saludable es no dejar la evaluación a un solo equipo; pero tampoco difuminar las responsabilidades.

La siguiente lista de comprobación puede utilizarse para una primera evaluación:

• ¿Se ha extraído el paquete SCORM del archivo?
• ¿Se han revisado los archivos de manifiesto, HTML y JavaScript?
• ¿Se han listado las URL externas?
• ¿Se ha ejecutado el paquete de extremo a extremo en un entorno de prueba?
• ¿Se han exportado los registros de red del navegador?
• ¿Se ha realizado una comparación con los registros de DNS y proxy?
• ¿Hay datos personales, texto libre o contenido documental en los cuerpos de las solicitudes?
• Si existe interacción de IA, ¿se ha identificado qué acción del usuario inicia la llamada?
• ¿Se ha definido una regla de acceso solo para los dominios necesarios?
• ¿Se han evaluado las categorías de datos y las condiciones de transferencia desde la perspectiva del RGPD?
• ¿Se ha documentado el impacto operativo, de cumplimiento o de PRL si se interrumpe la formación?
• ¿La decisión se ha justificado con el tráfico y el flujo de datos observados en lugar de con el «nombre de dominio»?

Esta lista no es un ritual burocrático. Un registro de revisión bien mantenido es más fiable que la memoria cuando, seis meses después, surge la pregunta «¿por qué habíamos autorizado este acceso?». La memoria humana es sorprendentemente creativa; los logs no lo son tanto.

Conclusión: el folleto explica la intención, el comportamiento de red aporta la prueba

Una organización puede establecer límites al uso de inteligencia artificial. Incluso puede establecer límites muy estrictos. Es una decisión de gestión totalmente legítima. Pero el equivalente técnico de ese límite no debe ser la extensión del dominio, la categoría del producto ni una sola palabra en el folleto.

La revisión del equipo de TI debe avanzar en tres capas:

1. ¿Qué contiene el paquete?
   Manifiesto, JavaScript, recursos externos y configuraciones.

2. ¿Qué hace el navegador?
   Solicitudes de red, destinos y cuerpos de datos en el flujo real del usuario.

3. ¿Qué significa para la organización?
   RGPD, clasificación de datos, puntos de conexión autorizados, control de acceso e impacto operativo.

Un sistema que tiene una función de IA y un sistema que genera tráfico de IA en cada sesión no son lo mismo. Un dominio .ai tampoco es evidencia de una llamada de IA. La evidencia es la solicitud que vive en la red, tiene marca de tiempo y cuyo destino y carga útil pueden verse.

Para los equipos de TI, el reflejo más seguro no debe ser «bloquearlo todo», sino ver qué puerta se abre realmente. Este enfoque aborda la seguridad con mayor seriedad y no deja los procesos de formación, cumplimiento y PRL en una oscuridad innecesaria.

Notas

1. SCORM 1.2, 2001. Modelo técnico estándar para la comunicación del contenido de aprendizaje con el LMS.
2. SCORM 2004, 2004. Estándar SCORM ampliado, incluidas las reglas de secuenciación y navegación.