I think one intuition I have here is the point Michael Nielsen brings up in his Notes on the Vulnerable World Hypothesis re: contemporary surveillance. Currently, we have a class of powerful elites and organizations with the ability to collect massive amounts of data and legally abuse that power for sadistic purposes, but who ultimately very rarely chose to. If an executive or even engineer at google was feeling malicious, they could choose to ruin the lives of most people using their services by revealing damaging information about them in deniable ways.
But for the most part, those elites don’t exercise this capacity for fun or even much profit, even though they have a level of insight into their customers that could make the Gestapo blush. This seems like decent evidence of inter-elite norms/principals restricting abuse of their leverage over otherwise powerless subjects.
I’ve had similar intuitions for a while now (see: human auditing as all you need to verify a comprehensive slowdown). Basically, I think technical verification work is approaching the problem from the wrong end. Instead of spending years figuring out all the technical details behind getting extremely robust and privacy-preserving verification tech, we should instead be gunning for simpler types of slowdown that are inherently more privacy preserving and harder to subvert. Lower the bar instead of trying to jump for it.
Ex: lets say you want to slowdown AI development by limiting training. One easy way to do this would be to make sure that no large AI training campuses have enough networking hardware to actually conduct a pre-training run. An inspector could go check, with their eyes, that there isn’t any Infiniband being run between server racks.
This is obviously a pretty robust and privacy-preserving regime: either the hardware is there or it isn’t, and its presence doesn’t give you any useful information for stealing model weights and research. You don’t need chips that are immune to laser bit-flips to do this. It’s main problem is that it’s not comprehensive: the other country could still use their compute for algorithmic research, gradually undermining the effects of your hardware enforced pre-training ban.
But isn’t that fine? It’d still buy us time—either to develop better verification technology, which preserves privacy at a greater level of detail, or to get more political will, which creates more tolerance for loss of privacy.
Another way of thinking about this is that there are “tiers of access” for verification: the further down you go, the more flexible and comprehensive your verification policy can be, but the more information you have to reveal. You should start by implementing slowdown regimes that only need the highest tiers to work, and then use the time they buy to invest in better verification tech and to build greater political will for international verification through empirical research/warning shots/public engagement, letting you implement stronger restrictions with fewer tradeoffs.
Rough tiering as follows:
Physical access to hardware. The simplest and most important basis for trust over an international agreement will be hardware inspections. Physical access to the datacenters being used would let inspectors check whether a) a given datacenter’s declared compute count is accurate, b) whether that datacenter has the networking infrastructure that would make it pre-training capable (as opposed to being inference-only) and c) whether further governance hardware, such as a tamper-evident enclosure, has been installed and not interfered with.
Job metadata / Compute telemetry. Outside of high-level hardware agreements, auditors might also want guarantees about whether training and deployment is happening at a given site. The most important piece of this is the metadata of the jobs: Job ID, unique agent or user IDs, timestamps, execution duration, compute/cluster allocation, as well as telemetry records of GPU utilization, power draw, and network bandwidth. This information would give inspectors the ability to check a) whether unapproved training runs are being conducted, and b) whether specific models are being deployed (such as whether they are being used internally in spite of not passing an pre-deployment eval)
Experiment logs. To extend restrictions further down to research and the specifics of what the training runs are being used for, auditors would need the full job logs. This would be things like inputs/prompts, model outputs/CoT, tool calls, environment interactions, datasets used, and benchmark scores. This would allow auditors to specifically check a) what permissions models have (especially whether they can autonomously approve deployments or training runs), b) what models are being trained to accomplish, and c) the resulting capabilities or efficiency uplift.
Company communications and workflows. Finally, as a general catch all, you’d want auditors to have access to company communications and the ability to conduct on-the-spot interviews about work, to get a qualitative sense of what research agendas are being pursued and what the priorities are (e.g. are we aiming for RSI or developing business software?). This would also make it extremely difficult to maintain an internal conspiracy to game which information is being provided to inspectors.