Design the Reactor , Not the Treaty

Recently I published an article with a title that made a few people wince: Stop Governing AI Like the Bomb. I had just spent a week in Geneva at the inaugural UN Global Dialogue on AI Governance, WSIS and AI for Good, and I came home convinced that the model underneath almost every framework in that room is not enough. This is the argument I made, and the work I am building because of it.

The wrong blueprint

We are governing artificial intelligence the way the world governed the atomic bomb. Build the artifact first, then convene the powers to contain it from the outside, through treaties, inspectors, and deterrence. For the bomb, that worked. No nuclear weapon has been used in conflict since 1945. But it worked because it had no alternative. You cannot design restraint into the physics of fission, so safety had to live outside the device, in treaties and inspection regimes.

AI is different in the one way that matters most, and it is the difference our frameworks keep ignoring. An AI system can carry its safety properties inside its own architecture. We are importing a governance model built for a technology whose safety could only ever be external, and applying it to a technology whose safety can be engineered in. That is an understandable category error. It also wastes the single real advantage AI has over the bomb.

We are governing artificial intelligence the way the world governed the atomic bomb.

The human who cannot see in

Look at where the consensus concentrates, and you find human oversight at the center of nearly every safety architecture. In practice that rarely means a person authorizing each decision. It usually means someone monitoring a system that has already acted, empowered in theory to intervene. And here is the harder problem underneath the consensus: that human is overseeing a system they cannot see into.

Frontier models are not interpretable by default. Without the tools to inspect the features and circuits driving an output, the overseer cannot audit the reasoning behind a decision. They can only ratify the result. Place a person at the end of an opaque pipeline and you have not added a safety layer. You have built what researchers call a moral crumple zone: someone positioned to absorb the blame for a system they were never given the tools to control.

Place a person at the end of an opaque pipeline and you have not added a safety layer. You have built what researchers call a moral crumple zone.

I am not arguing for removing the human. I am arguing for honesty about the sequence. Human oversight is a necessary bridge, and it is necessary precisely because the tools to verify alignment directly do not yet exist. Governance by architecture is the destination. The danger is treating the bridge as the destination, and the placeholder as a permanent solution.

What responsible architecture means

Responsible architecture inverts the order of operations. Safety is not a governance layer bolted on after a model is trained. It is a set of properties designed into the system and verified before deployment: alignment shaped at training time rather than patched at runtime, bounded autonomy with tripwires that can halt an agent at machine speed, provenance and audit trails that can be reconstructed after the fact, and interpretability access so that verifiers can inspect what a model is actually doing rather than just read its compliance documentation.

We have made this move before. Privacy-by-design turned data protection from after-the-fact penalties into an engineering requirement. Security has secure-by-design. AI safety needs the same shift. And to be clear, the existing frameworks- the UN Dialogue, the OECD principles, the EU AI Act- are not wrong. They are essential. They set the floor and establish the norms without which no technical solution means anything. What I am arguing is that the technical infrastructure has to catch up with the governance ambition. The two are not in competition. They are the same project.

What I am arguing is that the technical infrastructure has to catch up with the governance ambition. The two are not in competition. They are the same project.

The layer I am building

This is where my work lives, and it has a specific edge for the regions I come from.

Governance by architecture requires technical verification capacity, and that capacity is even more concentrated than regulatory capacity. Left unexamined, verification requirements can become a moat. Mandate interpretability access and formal evaluation, and you privilege the handful of laboratories that can already afford both. A regime meant to make AI verifiable everywhere could end up entrenching the very incumbents who wrote the verification tools.

I do not think that is inevitable. If safety is formally specified, then verification is a technical capability, and a technical capability can be built anywhere. The Middle East and the Global South do not need to depend indefinitely on the goodwill of frontier developers to tell us whether a deployed system is safe. We can build the capacity to verify it ourselves.

There is a second problem, and it is the one I have spent years documenting while writing my book on AI Renaissance. Even a sound, verifiable safety specification undergoes translation failure when it travels. By the time it reaches a government ministry in Cairo, Nairobi, or Riyadh, it has passed through layers of policy interpretation that strip out the operational context that made it verifiable. The architecture may be coherent. The translation is not.

That is what Breakthrough Ins. is building. Not another policy framework. Technical verification capacity for AI governance in the Middle East and Global South, through our Governance Translation and Operationalization Framework, or GTOF. The ability to check the architecture and translate the specification, with a named owner attached to each obligation, rather than simply read the documentation. Governance by architecture and governance translation are not competing ideas. They are the same problem at different layers of the stack. You need both.

How I ended up here

For twenty-five years, I worked across the public sector, the private sector, and civil society; in many roles and at every level. Across all of it, I learned to read a problem as a business case, not a use case: what it is worth, to whom, and at what risk.

Even so, people sometimes ask how a strategist and advisor at the intersection of governance, business, and sustainable development ended up making an argument about interpretability and model internals. The honest answer? Four years ago, I decided this technology could not stay a black box I was only allowed to describe from the outside. So, I taught myself to read it.

This technology could not stay a black box I was only allowed to describe from the outside. So, I taught myself to read it.

I started with Harvard’s introductory computer science course, moved through cybersecurity, and went as far into how models are trained, evaluated, and verified as I needed to make a safety claim and actually check it. For a long time, that made me the person in the technical room who was assumed not to belong there. Building this verification capacity ...and building it within the region rather than importing it...is part of how I answer that assumption.

Geneva to New York

Geneva asked who should decide and answer. The better question, the one I will be taking to New York in 2027, is what we must build so that whoever decides can genuinely see, verify, and halt the system they are answering for. And whether the regions most affected by that system had any voice in specifying what they were meant to verify.

By Rania Hamoud, DBA

• CEO of Breakthrough Institute for Research and Development
• Co-founder of Tailored XTech
• Board member of Tech x Elkheir NGO
• Author of book AI Renaissance
• Research member at Center of AI Policy and Digital Policy Washington DC
• Ex CEO of Mansour Group Foundation

Rania.hamoud@sciencespo.fr
+44 7518 473561 / +20 122782 8282