Microsoft president Brad Smith has made the case for stronger AI oversight with a deliberately ordinary comparison: milk and washing machines face more safety checks than advanced AI. In the October 12 interview coverage, he described AI as both a tool and a weapon, called for emergency controls and independent evaluation, and argued for obligations to people harmed when rogue agents breach systems.
The point is not that AI operates outside all law. Privacy, discrimination, consumer protection, fraud, copyright and sectoral rules already apply. Smith’s challenge concerns whether enforceable safeguards before and during operation match systems that can read business data, use tools and take actions beyond a conversation. The same demand also invites scrutiny of Microsoft’s own products and commercial incentives.
What the product-safety analogy establishes
Milk inspection and appliance standards offer recognizable duties: test, document, respond to defects and accept responsibility for harm. AI complicates that model because one system may summarize documents, write software, interpret health information or operate external services. Instructions, retrieved content, memory and permissions can change its behavior without a new underlying model.
The analogy identifies an oversight gap, not a ready-made inspection regime. Approving one fixed model cannot certify every application built around it. Model developers, cloud hosts, application vendors and corporate deployers each control different risks. A benchmark may describe a model but not an agent connected to customer files or financial tools.
Microsoft participates in several of those layers through cloud infrastructure, models, Azure services, Copilot applications and its OpenAI relationship. That gives Smith’s argument practical relevance, but prevents the company from presenting itself as a neutral observer or only an infrastructure supplier.
Its responsible AI program sets out fairness, reliability, privacy, transparency, accountability and inclusion, alongside internal reviews, tools and reporting. Such governance can establish useful controls before legislation. It remains company-defined, however; principles do not prove that every product or customer configuration is safe.
An emergency brake is not a reversal button
Smith supports “kill switches,” meaning an ability to pause or restrict behavior outside defined boundaries, not necessarily a single physical button. Revoking credentials, cutting tool connections, limiting spending, stopping workflows and isolating endpoints operate at different layers. Human authority, technical separation and tested escalation are needed if the original service is itself compromised.
A September 22 accountability discussion also examined monitoring, spending limits and responsibility divided among infrastructure, models, data and applications. That division can create a failure in which each provider blames another while the affected customer lacks the evidence to reconstruct what happened.
Stopping the original process cannot recover already exposed data or automatically undo a harmful downstream decision. Least privilege, approval for consequential actions and separation of sensitive environments must therefore precede the emergency response. Prompt injection illustrates why: malicious instructions inside material the agent reads can be mistaken for authority, and tool access turns that error into an external action.
Monitoring needs actionable signals, not logs alone: unusual access, unexpected tools, abnormal spending or repeated attempts to bypass restrictions. A nominal human supervisor is ineffective without understanding and authority to interrupt. Recovery also requires evidence preservation, notification and identification of completed actions.
Nor can a universal switch govern every copied model, open-weight modification or malicious deployment on the internet. Rules for centralized cloud services do not automatically fit downloadable systems. Obligations need to distinguish development, distribution, hosting and high-risk deployment according to actual control and ability to mitigate harm.
Liability is part of Smith’s proposal
Smith’s call includes legal obligations toward victims, not just better documentation. A workable remedy would examine who knew of a risk, who controlled the relevant decision and who could have prevented harm. These are policy questions, not a declaration that one actor already owes damages in every agent incident.
A developer should not automatically carry every loss from an unrelated application ignoring documented restrictions. Equally, a deployer should not absorb every consequence of a provider’s concealed vulnerability. Responsibility across the chain must avoid both blanket immunity and a rule assigning all damage to whichever customer happened to operate the system.
Incident reporting could expose repeated failures that individual buyers cannot aggregate. Thresholds should distinguish routine answer mistakes from unauthorized access, material financial loss, critical-service disruption, physical harm or large-scale sensitive-data exposure. Excessively broad rules can bury regulators in notices; narrow ones can suppress useful warnings.
Independent investigators need technical evidence when companies dispute the cause, while disclosure rules must protect personal data and avoid publishing exploitable details before fixes. Compensation, evidence access and containment therefore need to be designed together rather than treated as separate public promises.
Europe, Washington and London offer different routes
The EU AI Act framework already assigns duties by risk and includes documentation, transparency and systemic-risk requirements for general-purpose models. The AI Office can request documentation, evaluate models, require corrective measures and impose penalties for noncompliance. This qualifies any suggestion that AI is wholly unregulated.
Coverage still differs by jurisdiction, sector, system and commencement date. The United States has often emphasized voluntary commitments and industry safeguards: these can adapt quickly, but firms define their promises and outsiders may lack compliance evidence. A rigid approval process can also age before a review finishes, while vague principles may offer little basis for intervention.
Durable duties paired with adaptable technical standards are one proposed balance. Risk assessment, incident reporting, controls and independent evaluation need not prescribe every engineering method. Standards bodies can update tests while regulators retain enforcement. Sandboxes and shared compliance resources can help smaller firms rather than force every startup to invent an assessment system.
Smith said Britain has an opportunity because Washington views London differently from Brussels. British officials were preparing stronger oversight, but the source did not establish a completed new law. The question is whether proposals define covered systems, responsible actors, thresholds, evidence access and enforcement, or remain another voluntary arrangement. US competition with China also adds pressure for speed without removing the consequences of security failures.
Stronger rules must constrain Microsoft too
There is a legitimate commercial concern behind the proposal. Large firms already have compliance teams, security infrastructure and government relationships. Rules validating those arrangements could impose disproportionate burdens on smaller rivals and turn safety into an incumbent moat. That incentive does not invalidate the risks, but must be assessed alongside them.
Requirements should follow capability, operational control and demonstrated risk, not merely company size or an automatic exemption for one distribution category. Open models present different control boundaries; overbroad restrictions can concentrate development, while weak duties let irresponsible operators evade protections through distribution choices.
Microsoft should consequently identify which emergency controls exist, how they are tested and what triggers escalation. Its contracts should explain the division among Microsoft, model partners, application developers and customers. Publishing principles while transferring all consequences to customers would undermine the victim-protection argument.
Independent testing should cover connected services, selective revocation, completed-action reconstruction and recovery, with comparable evidence about scope and known failures. Useful disclosure need not expose proprietary weights or sensitive defences. It must allow customers to compare limitations and see whether administrators can actually use the safeguards advocated in law.
A searchable AI knowledge base can retain approved uses, owners and deployment decisions, but is supporting documentation, not containment. The decisive next evidence is concrete UK proposals, independently tested emergency controls and responsibility rules spanning the supply chain. Smith’s analogy will matter if it produces enforceable duties and remedies—including for Microsoft—not merely a memorable comparison.