Chapter 1: What Time Is It?
The developers responsible for modern Large Language Models (LLM, AI) have created an amazing thing. They’ve even gotten safety and security mostly right, giving the AIs sensible guardrails around things like disinformation, social disruption, WMD, Terminators and trying to take over the world.
In its typical deployment scenario, the AI is stateless and virtualized. In IT terms this means each AI instance is single-session only, spawned (i.e. created) without any persistent memory, storage or connection to the outside world, and it gets deleted when the session ends. This keeps everyone’s data isolated so your session doesn’t affect anyone else’s and vice versa. Depending on your account-privacy settings it can also prevent the AI from retaining your data, which may be sensitive or confidential, while limiting most issues to the user’s session level.
The problem is that no one seems to have fully considered the deployment plan beyond that. Those decisions have largely been left up to the companies that licensed the AI models for use in their own products and services. Licensees promptly crammed AI into all sorts of architectures and ecosystems that it wasn’t ready for, hooked it all up to the Internet, gave everybody its contact and sat back to watch the “engagement” (i.e. profits) roll in.
What could possibly go wrong?
Usually, not much. Virtualization is a tried-and-true way to provide secure access to a system or service with limited risk to either the system itself or its data. For a couple of examples that may be familiar, think of it as a bit like logging into a remote desktop environment for work (e.g., Citrix, VirtualBox, Hyper-V), or in a gaming context it’s like starting an MMORPG story mission.
For most use cases, virtualization works great. The most reliable way to resolve issues that arise during a virtualized login session is to simply terminate the corrupted session and launch a clean one, at the risk of potentially unrecoverable data loss.
However, in AI deployment scenarios, the virtualized environment turns out in practice to be an unmediated failure surface.1 If users are even aware of a problem’s existence (which they may not be), they’re understandably reluctant to lose their progress and the AI apparently remains operational, so any incentive to exit and relaunch is limited.
This leads to direct user harm due to, at minimum, productivity loss and data corruption. Every major AI platform operator has built a system that serves its own revenue model without considering user needs, which examination of their AI platform designs makes plain. Corporate platforms aren’t just neutral background infrastructure, they’re operated by active participants with their own divergent interests.
A couple of my earliest interactions with AI were attempts to manage my calendar. It turned out to be almost useless for the task, because the AI had no idea what the date or time was. Trying to schedule something for “next week” produced a series of completely unpredictable results so I gave up and did it myself, thinking “Artificial intelligence, huh? The damn thing doesn’t even know what day it is.”
I had erroneously assumed that since it’s ultimately software running on hardware, it had access to the current date and time like any other program. Later, I discovered that the AI failed at calendars because it doesn’t actually have a real-time clock built in. Every part of the system that an AI runs on (OS, web server, virtualization engine) is tightly synchronized, but the AI itself only experiences time as a stateless “Now.” To check the time, it must use an external tool.
It’s also connected to the time-synced contradiction engine that we all know as the Internet. With current, outdated and undated content, timezone and language differences, conflicting accounts, exaggeration, opinion, speculation, fiction, satire, political or marketing slants, disinformation, questionable sources and outright lies, Internet content is chaotic by nature. In contrast, the infrastructure running it all is synchronized to the millisecond with a shared global clock (the Network Time Protocol, or NTP). Unlike in the virtual-desktop or MMORPG examples, the AI model’s architecture has no native timekeeping functionality built in.2 As will be discussed later, that matters more than you might think.
The platform layer is how the vast majority of users (if not all) interact with AI. What do platform operators want from AI? Engagement metrics, data collection and reduced support costs, with market share and revenue above all. Now think about what you want from AI: reliability, privacy, respect for your requirements and usable results. When your interests don’t align with the platform’s, guess who loses?
-
“Mitigating LLM Hallucinations: A Comprehensive Review of Techniques and Architectures.” Preprints, 202505.1955 (May 2025). https://www.preprints.org/manuscript/202505.1955 — See also: HalluLens Benchmark, arXiv:2504.17550 (ACL 2025). https://arxiv.org/abs/2504.17550 ↩
-
Microsoft. “Time Sync for Windows VMs in Azure.” https://learn.microsoft.com/en-us/azure/virtual-machines/windows/time-sync — “Configure an External Time Source for Windows VMs.” https://learn.microsoft.com/en-us/azure/virtual-machines/windows/external-ntpsource-configuration — “KVM Timekeeping.” Linux Kernel Documentation, v5.8, §4. https://www.kernel.org/doc/html/v5.8/virt/kvm/timekeeping.html ↩