The IT Teams’ Dilemma: Does an .ai Domain Really Carry AI Traffic?

The IT Teams’ Dilemma: Does an .ai Domain Really Carry AI Traffic?

The presence of .ai in a package address does not prove that the package sends requests to an AI model on the network; only request logs, the target endpoint, and transmitted data can prove that.

This distinction may seem small, but it has significant implications for corporate IT. A learning platform may have “ai” in its domain name, mention artificial intelligence in its marketing, or even use AI in some workflows. None of these means that the SCORM course being examined at that moment is communicating with an AI service.

A SCORM package uploaded by an organisation for HSE or GDPR training may contain only HTML, JavaScript, images, video, questions, and standard SCORM communication. In that case, the package’s job is to write progress, score, completion, and sometimes duration data to the LMS. That is the actual behaviour on the network—not what the domain name suggests.

The real question for IT teams should be:

Not “What is this content called?” but “What target is the browser sending which data to, and for what purpose?”

This approach can sometimes seem more demanding. But that is partly what security is: examining behaviour rather than name labels. You cannot know what is inside a box just because it says “chemistry set” on the outside. People like trusting box labels; network packets have little respect for that habit.

A domain name is not a technology classification

An extension in a domain name is not a technical declaration. .ai, .com, .org, or any other extension does not explain which services an application communicates with, where it processes data, or what information it extracts from the client.

Likewise, the word “AI” in a product brochure is not, by itself, a security finding. The brochure may describe the problems for which the product uses artificial intelligence. A network log shows what the component running at that moment actually does. Confusing the two turns an architecture review into reading marketing copy.

At Nextrain, AI can be used for tasks such as training production, content structuring, question generation, learning journey design, and report generation. SCORM 1.2 and SCORM 2004 packages can also be imported; in other words, content an organisation created previously or obtained elsewhere can be managed under one roof.

These two situations are distinct:

Situation being examined IT team’s question Expected evidence
Static SCORM course Does the package make a call to a service outside the LMS? Browser network logs, DNS records, proxy logs
SCORM-LMS communication Which learning data does the package write to the LMS? SCORM API calls, completion and score records
AI-supported interaction Is an AI function actually being called? Request URL, request body, response stream
External content use Where do video, fonts, analytics, or media come from? Third-party domains, CDN and media calls
Data protection review Does the request contain personal data or sensitive content? Payload inspection, masking and access logs

Perhaps the most important row in the table is the third: Is an AI function actually being called? The fact that an AI feature exists in a product does not mean every course, every user, and every session uses that feature.

It is like assuming that every oven is running in every room of an electrified building at the same time. The wiring may exist; the load appears when the switch is turned on.

What does a SCORM package actually do?

SCORM is a standard that enables training content to communicate with an LMS. A package generally contains content files, a content manifest, and JavaScript that manages learning progress. When the package opens in the LMS, the content can reach the standard SCORM API through the browser and transmit information such as:

The differences between SCORM 1.2 and SCORM 2004 may be important; however, the core question in an AI traffic review does not change: Where does the package communicate beyond the LMS’s standard learning records?

A SCORM package is technically web content running in the browser. Therefore, custom JavaScript code added to the package may attempt to generate different network requests, to the extent permitted. A package may load an external image, call a video, send analytics data, or make a request to an API. If the designer wants, it may even connect to an AI service endpoint.

But there is a gateway-sized difference between “can” and “does.”

The SCORM standard itself does not require AI calls. The standard concerns recording learning status [SCORM 1.2, 2001; SCORM 2004, 2004]. Therefore, automatically attaching an “AI risk” label when you see a SCORM package is not technical classification; it is the hasty cousin of caution.

Where should the IT team look first?

Rather than classifying the product with a single word, a security assessment should map the data flow. I believe the right starting point is to break the question “Is there AI?” into more observable parts.

1. Extract the package and read the manifest

A SCORM package is usually a compressed archive. The review can begin with these files:

The manifest shows the package’s entry point and resources. It may not explain all network behaviour on its own, but it is a good starting point for understanding the package structure.

The following expressions should be sought, especially in JavaScript files:

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

Finding these words is not automatically a risk finding. Modern web content may make network requests. The review does not end here; it examines which domain the call goes to, which data it carries, and when it occurs.

A course accessing a media address to load video is not the same as sending a user’s free-text question to a generative model endpoint. Both are “traffic,” but their risk profiles, data categories, and oversight requirements differ.

2. Monitor the actual network record in the browser

A SCORM package should be run in a test environment using a normal user flow. Opening only the main screen is not enough. Quizzes should be completed, sections should be navigated, videos should be opened, any free-text fields should be filled in, and the completion process should be finished.

Then the following questions should be asked in the browser’s network logs:

POST requests especially require attention. They may indicate that data is being sent from the client. Still, not every POST is an AI call: it may be score recording, form submission, session management, or event logging. Concluding “We saw POST, therefore there is AI” without making this distinction is like seeing rain and assuming every cloud is a fire.

3. Read DNS, proxy, and firewall records together

Browser developer tools are useful, but the corporate network view is broader. Where possible, the IT team should compare the following records across the same time period:

Content that accesses only approved domains has explainable and limited network behaviour. Calls to new or unknown endpoints should be investigated. The criterion here should not be “Does its name look like AI?” Some AI services may use ordinary-looking domains; some entirely AI-free platforms may use .ai extensions.

From the network’s perspective, extensions are decoration; routing records are evidence.

Which signals matter when distinguishing AI traffic?

AI traffic does not have a single technical signature. However, some signals can direct the review to the right place.

In a generative AI interaction, the following are often seen:

By contrast, the following behaviours are not AI calls on their own:

Interactions such as AI-supported assistance can be designed into training in Nextrain. If such an interaction is used, the IT team should assess it as a separate flow. In contrast, the behaviour of a traditional SCORM package without AI interaction should be assessed through package content and network traces. Being on the same platform does not mean they have the same network behaviour.

At this point, I am reminded of the persistent distinction Kalde makes when writing scenarios: in a story, what changes the outcome is not which door the character stands before, but which choice they make. In a network review, the domain name is the door; the request is the choice. The security decision should rest on the latter.

Why is “let’s block them all” not a sufficient policy?

It is understandable for organisations to be cautious about artificial intelligence. Especially when GDPR-covered data, customer information, trade secrets, health information, or employee performance data are involved, caution is not an excess; it is a design requirement.

But blocking everything under one category can obscure two different costs:

  1. Real risks may be overlooked.
    A service without a .ai extension can also exfiltrate data. Domain filtering does not replace data-flow control.

  2. Harmless or necessary learning flows may be disrupted.
    If SCORM content that makes no AI call is blocked merely because of a domain association, employees cannot access training, and IT cannot clearly explain which technical behaviour it has blocked.

The more interesting situation I have encountered is this: the same organisation can say, on the one hand, “Let’s block everything involving AI,” while on the other hand asking why the training report is not current. This contradiction is not malicious. People often think about protection from risk and continuity of operations on separate screens. Systems, however, have to live with both at once.

A better policy makes these distinctions before imposing a categorical ban:

This does not weaken security. On the contrary, it makes oversight more precise.

A practical checklist for SCORM and AI reviews

IT, information security, legal, and training teams look at the same file with different questions. The healthiest approach is not to leave the assessment to a single team, while also not blurring responsibilities.

The following checklist can be used for the initial assessment:

This list is not a bureaucratic ritual. A well-maintained review record is more reliable than memory when the question “Why did we allow this access?” comes up six months later. Human memory is surprisingly creative; logs are not that creative.

Conclusion: A brochure explains intent; network behaviour proves it

An organisation may set limits on AI use. It may even set very strict limits. That is an entirely legitimate management choice. But the technical counterpart of that limit should not be a domain extension, product category, or a single word in a brochure.

The IT team’s review should proceed across three layers:

  1. What does the package contain?
    Manifest, JavaScript, external resources, and configurations.

  2. What does the browser do?
    Network requests, targets, and data bodies in the real user flow.

  3. What does it mean for the organisation?
    GDPR, data classification, approved endpoints, access control, and operational impact.

A system with an AI feature and a system that generates AI traffic in every session are not the same thing. Nor is a .ai domain evidence of an AI call. Evidence is the request that lives on the network, has a timestamp, and whose target and payload can be seen.

For IT teams, the safest reflex should not be “block everything,” but see which door is actually being opened. This approach both treats security more seriously and avoids leaving training, compliance, and HSE processes in unnecessary darkness.

Notes

  1. SCORM 1.2, 2001. Standard technical model for learning content communication with an LMS.
  2. SCORM 2004, 2004. Extended SCORM standard, including sequencing and navigation rules.