1) Like 'opless wrote, AIs in most games are simple; they're designed to execute in real-time.
2) From the point of view of a networked game, AIs and players are the same - the server(s) only care about inputs. The difference between keyboard input and AI input need not to be relevant, and this suggest a trivial approach - execute AIs on clients, and send their inputs along with players' inputs.
I'd suggest digging through old EVE:online devblogs and presentations. They describe server architecture and design points, as well as the process of tuning those with each other and actual community use.
That seems strange, you'd be sending multiple times the same AI's actions to the server, in which case you better be certain that it's deterministic, not to mention the security concerns. It seems far easier to execute the AI on the server and send its actions to each player, especially if it's a trivial AI.
Of course, for this, you need a bit of determinism, and some games need to synchronize other parameters, which can lead to "security" concerns: bullet spread, hit detection and such for FPSs, for example.
This can also lead to some hilarious de-sync issues when a player tries to cheat on its local game instance. By altering its local state, the AI is effectively desynchronized, and the players can observe different outcomes on their local instances. This is often used as a punishment for cheating.
The alternative (for serverless, p2p games) is to have a central host, but it might take a lot of computing resources, and the host is then generally free to cheat.
One side effect of having deterministic AIs synced over the lobby is that the code needs to have the exact same behavior, down to the rounding errors. This can dramatically increase the complexity of cross-platform multiplayer games, and usually requires the exact same binary to be used by every client.
I think that Civilization and Sins of a solar empire use this kind of distributed AI scheme (as well as most games that don't have cross platform multiplayer, and those where you can experience de-syncs).
This gives you the benefit of low-latency on the client (don't have to wait for the server to tell it what the AI is doing) but also avoids security and non-determinism worries. (Although the AI might still be non-deterministic, it probably can't diverge too much before the client receives the next snapshot from the server).
This might be more effort than it's worth, though...
you achieve the benefit by loosening consistency, i.e. the local ai will have to react to local events before those are acknowledged by the server to see any gain, and the server might come to different opinions because it sees a different state of the game considering multiple clients who are constantly out of sync.
That leads to warping. A rocket, to take an example of an extremely simple entity, might fly a few meters on your screen only to explode right in front of your face because the server sent a message that the flight path was blocked by an online enemy that your client didn't predict.
Sure, if you can execute AI server-side, go ahead. But the GP asked about scaling it up, and this offers a trivial way of doing so.
A player remaining still doesn't benefit the player. All the AI enemies nearby standing still does.