AI:  Learning to Manage a Novel, Useful Tool

The Problem

Even as AI technology spreads rapidly through the American economy, as well as around the world, the fundamental difference between this computing technology and what we’ve already built is worth discussing because of the challenge it presents to the one thing everyone should care about: the reliability and predictability which are essential for safe operation.  AI, like every tool humans have ever built, has limits as well as capabilities, and using any tool well requires understanding where those limits are, not pretending they don’t exist.  The key to understanding how AI computing differs from what’s come before lies in the concept of “determinism.”  A useful way to picture it is an old analog clock.  If you stop such a clock at any instant and open its case, you can look at the exact position of every gear inside and know, with total certainty, precisely what the clock was doing at that moment, and what it would do next, because its behavior is fully determined by the state of its parts.

A conventional computer program works the same way, just electronically instead of mechanically.  If you pause a running conventional program and take what engineers call a memory dump, a complete snapshot of exactly what’s stored in every location in the computer’s memory at that instant, you can identify precisely which line of code was executing and exactly what value every variable held at that moment.  Like the clock, a conventional program’s behavior is, in principle, fully knowable at every point.  That’s what “deterministic” means, and it’s the property that has let engineers build reliable, predictable, safety-certified software for seventy years, including guiding us to the Moon and back, flying the Space Shuttle and commercial airplanes, and running most home appliances since around 1990.

The large AI systems now in wide use, the ones capable of writing, reasoning, and holding a conversation, don’t work this way.  They’re non-deterministic: even their own designers can’t point to a single “value” or “location” inside the system responsible for a given output, and the same input can sometimes produce different outputs on different occasions.  There is no simple memory dump you can take of one of these systems that tells you, the way it does for conventional software, exactly why it did what it did.  This results from efforts to make computers more adaptable, able to react to a larger variety of data and scenarios without requiring that specific bits of program code be written to handle each case.  The advantage of this approach is that a given combination of hardware and software can be more capable with less production effort, and the software, specifically, can easily be reused and trained, instead of programmed, by changing the data it’s given to run against.  This isn’t a bug hiding in otherwise-ordinary software.  It’s a genuinely different approach to computing technology.

Because our needs as human beings don’t really change just because we change tools, we need to be assured that we understand AI well enough, technology that already runs in military systems, on NASA spacecraft, in video games, in most new major home appliances, and in the browsers and software all of us use constantly.  The challenge we now face is that our safety-analysis techniques were developed during the era of the older, narrower, often fully deterministic systems we engineered and refined over decades.  Applied to this newer, non-deterministic technology, those same methods aren’t enough; we must revise them to achieve the understanding of AI necessary for the predictability and reliability we require everywhere we use it.

None of this is new to human thought, even if the specific technology is.  The project of trying to understand, bound, and predict the behavior of intelligent machines is over eighty years old.  Isaac Asimov, the scientist and science fiction writer, introduced his Three Laws of Robotics in his 1942 short story “Runaround” (included in the 1950 collection I, Robot), presented within the story as being drawn from the fictional “Handbook of Robotics, 56th Edition, 2058 A.D.”: [1]

“1. A robot may not injure a human being or, through inaction, allow a human being to come to harm.
2. A robot must obey the orders given it by human beings except where such orders would conflict with the First Law.
3. A robot must protect its own existence as long as such protection does not conflict with the First or Second Law.”

By using the Laws as the catalyst for plot development across his many science fiction stories, Asimov was able to test them against numerous “use cases,” as engineers now say, defining their applicability and showing how conflicts between the Laws might play out in realistic scenarios.  Across decades of stories, he spent far more time exploring how those three simple rules broke down at their edges than showing them working cleanly.  That was the whole point: to illustrate how even a brilliant, carefully constructed set of first principles runs into hard cases in the real world, and the only way to find those hard cases is sustained, rigorous, empirical study, not a slogan, and not three tidy rules.  That’s exactly the kind of work I’m calling for.

What I Propose

The first steps in this work are already underway.  The Department of Defense first issued formal policy on autonomy in weapon systems in 2012, and updated it in January 2023 as Directive 3000.09. [2]  That directive requires autonomous and semi-autonomous weapon systems to be designed so commanders and operators can exercise “appropriate levels of human judgment over the use of force,” and it requires these systems be engineered to detect when they’re behaving unexpectedly and be capable of being disengaged or shut down the moment that happens, before they’re ever fielded.  Congress requires an annual public report on which such systems have been approved and deployed.  None of that is a promise or a reassurance I’m asking you to take on faith.  It’s existing, binding federal policy, in force today, doing exactly the job people fear isn’t being done.  The proposal below extends that same discipline, not a version of it “inspired by” the military’s work, but built directly on the actual engineering requirement at its core, to the much broader set of places AI now touches civilian life.

The National Institute of Standards and Technology currently maintains a voluntary AI Risk Management Framework, and in February 2026 launched an AI Agent Standards Initiative aimed at autonomous-systems questions. [3][4]  What this effort doesn’t yet have is mandatory weight, the operational safety expertise of NASA or the NTSB, DARPA’s frontier research funding, formal industry-standards participation, or a scope extending past AI agents into physical systems like autonomous vehicles.  I’m proposing to build all five of those pieces onto the foundation that already exists, not to start over.

The most recent development:  On June 5, 2026, the White House issued National Security Presidential Memorandum NSPM-11, directing accelerated AI adoption across the national security enterprise and ordering an update to DoD Directive 3000.09. [5]  The memorandum establishes four pillars, Adoption, Adaptation, Assurance, and Accountability, and requires testing, evaluation, verification, and validation of AI systems before deployment.  It is a significant step, and its Assurance and Accountability requirements align closely with the engineering discipline this proposal seeks to extend to civilian applications.

This characterization work is already happening in the field.  In June 2026, the 3rd Mobile Brigade Combat Team of the 101st Airborne Division reported results from a year-long effort to integrate AI across all staff sections. [6]  They trained large language models on joint, Army, and division doctrine, giving each section its own tools to process the operating environment and respond faster.  In a single ten-day exercise, drone sensors and reports generated over 25,000 spot reports, a volume no human staff could process unaided.  The AI handled that data well.  But when the brigade tried to use the same tools for tactical course-of-action development, they failed.  As the brigade commander, Col. Ryan Bell, put it: large language models do not understand three-dimensional space, and therefore cannot develop courses of action.  That is exactly the kind of finding: specific, operationally grounded, discovered through disciplined use rather than speculation, that a formal characterization effort would systematize and make available to every organization facing similar adoption decisions.

Bringing in the agencies that already know how to study failure.  NIST shouldn’t do this alone.  NASA has decades of hard-won systems-safety culture from human spaceflight.  DARPA exists precisely to fund frontier research years before industry is ready to.  The National Transportation Safety Board has spent decades doing exactly the kind of independent, no-blame, what-actually-happened-and-why investigation this domain now needs.  I propose formally bringing all three in as full partners alongside NIST, not outside observers.

Real industry standards participation, not just consultation.  I propose formal participation from organizations like ASME, IEEE, and JEDEC, professional standards bodies with direct engineering expertise, brought in as co-authors of the standards, not commenters on a draft written without them.

Extending the scope to where the stakes are already highest, using the requirement that already exists for weapons.  This can’t stop at chatbots.  I want this effort’s scope to explicitly include self-driving vehicles and autonomous agent systems generally, and I want it built on the same core engineering requirement the Department of Defense already imposes on autonomous weapon systems: that a system be able to detect when it’s behaving unexpectedly, and be disengaged or shut down before that behavior causes harm. [2]  That’s not a comparison to weapons policy.  It’s taking the actual requirement and applying it everywhere the stakes justify it.

Characterization and recommendations, not mandates.  I want to be precise about what I’m asking for: federally funded research to describe, characterize, and make applicability recommendations.  I’m not proposing to restrict what anyone can build.  I’m proposing to fund the work of actually understanding these systems, so trust in them is earned through the same kind of decades of public, accountable engineering that earned trust in cars and aircraft, not assumed, and not dismissed out of fear either.

I’m not wedded to this exact agency lineup or structure.  If a different combination of institutions would do this work better, I’d rather have the right effort than the one I first thought of.  What I am committed to is the scale and seriousness of it: a genuinely federal, multi-agency, multi-stakeholder undertaking, sized to match how deeply this technology is now woven into national life.

I am not approaching this as an outsider.  I use AI extensively, at work, for entertainment, for independent research, for my hobbies, and in building this very campaign website and its content, including this page.  I contend that we don’t need to fear AI any more than we fear a laser printer, a car, an airplane, or a coffee machine.  Instead, we need to study this new technology enough to know what to expect from it, and when, where, and how to use it.

References

How We’ll Know It’s Working