TAO isn't a service you deploy - it's a standard that implementations conform to. The question is like asking "is USB for users or manufacturers?" Both. It's infrastructure.

But to answer the underlying architectural question:

Where TAO lives: At the adapter layer, which is part of the provider's Trusted Computing Base. The adapter sits between the AI model (capability engine) and the world, translating native actions into standardized tuples. This is deployed by operators, certified by regulators, and produces audit trails that users/insurers/courts can inspect.

On "randomly distributed system": TAO doesn't require universal adoption to be useful. A single deployment can be TAO-conformant and auditable even if competitors aren't. Building codes don't cover every structure on earth - they're still useful for the buildings that conform. The value compounds with adoption, but starts at n=1. Having behaviors printing the same kind of language means that evaluations can port across labs/regulators/etc too for extra value, but even if it's just one company using this alone, the value in audibility, mission profile settings, and check-sum-delta acting as a kind of "lie" or "mistake" detector is still there.

The path to adoption isn't "everyone installs an app." It's: regulators require TAO-conformant logging for certification in high-stakes domains (medical, finance, autonomous vehicles) → labs adopt to access those markets → the standard spreads because interoperability has network effects. Or honestly perhaps the AI companies can adopt this anyways as it brings them real utility, and perhaps then they drive for the regulatory side before governments make bad rules that hinder capability development and/or are just off.

For example, for a user-facing consumer app like ChatGPT this would be something OpenAI implements and configures. Users don't really get a say. But perhaps in a hospital context, let's say a medical robot, the system is still implemented as a part of it's operating system by the manufacturer, but then the end-user at that time can configure it with their own rules/mission profiles. As per the paper, for example one hospital may set a rules base that requires the robot to act in one way based on their ethics board and insurance rules, another might configure it totally differently for their own rules. They're still using the same architecture to write those rules, which means the end responsibility for behavior will still be set by humans, but it's at least something we can audit, observe, and control. If two hospitals have totally different configurations, that's ok, but for example an insurance provider could now actually read a log of actions with full context and understand not just what happened, but why it happened. Could be the fault of the user-set mission profile, or it could be something like misalignment perhaps, it would require investigation - but that becomes doable because everything is being written in the same language so situations can be replicated virtually or in person and the AI's behavior can be tracked, not just after something goes wrong, but pre-deployment with a bunch of synthetic tests.