AGI Research Opens the Release-Review Question as 30% Give Developers the Greatest Safety Responsibility

A survey of 100 Americans points to a difficult question for the AGI race: who should decide when a powerful system is safe enough to release? The public gives developers a role, but most respondents place the final responsibility outside the companies building these systems.
The release of an advanced AI system is often described as an engineering decision. A model meets a capability target, passes internal tests, and moves toward deployment. Public opinion suggests that AGI release will be judged through a wider lens. Americans want to know who reviewed the safety evidence, who had authority to delay the launch, and whether that authority could be used against a company determined to move quickly.
A recent survey of 100 Americans found that about 29.5%, or roughly 30%, gave the developing company the greatest responsibility for deciding when AGI is safe to release. Government regulators, independent scientific experts, and the company itself each received about 29% support. An international regulatory organization received 12.7%.
Those numbers show a divided view of decision-making. They also show a clear limit on corporate self-review: approximately 70.5% assigned the greatest responsibility to an actor outside the company that developed the system.
The release decision has become a governance question
AGI refers to AI systems expected to perform across a broad range of intellectual tasks, potentially matching or exceeding human performance in many areas. A system with that level of capability could affect employment, education, cybersecurity, scientific research, public services, and military planning. Its release would carry consequences beyond the company that trained it or the customers that use it.
That wider impact changes the meaning of a safety review. Internal testing can examine issues such as:
- Whether the model follows instructions reliably
- Whether it produces dangerous or deceptive outputs
- Whether safeguards can be bypassed
- Whether its behavior changes under pressure
- Whether operators can monitor and shut down the system
- Whether deployment creates new risks for users and the public
A company can conduct this work well and still face a conflict of interest. The same organization that pays for training, controls the launch schedule, answers to investors, and competes for market share also has an incentive to interpret uncertainty in a way that supports release.
That conflict sits at the center of the survey finding. Nearly three in ten respondents still trusted the developer with the greatest safety responsibility. The figure represents a substantial constituency that sees technical proximity as valuable. Developers have access to the model, the training history, the evaluation data, and the operational details that outsiders may struggle to obtain.
The larger share of respondents placed responsibility elsewhere. Their position reflects a basic governance principle: the builder should provide evidence, while an independent authority should have the power to challenge the evidence and delay deployment.
Synopsis
A survey of 100 Americans suggests that the public is open to continued AGI development but skeptical of unrestricted corporate control over release decisions. Roughly 30% gave developers the greatest responsibility for deciding whether AGI is safe, while about 70.5% placed that responsibility with an external actor. The findings support a release process in which companies prepare detailed safety evidence, independent experts test it, and regulators or authorized review bodies can require changes or delay deployment. Because the survey is small and not established as a probability sample, it offers a useful signal rather than a definitive measure of national opinion.
Americans want progress with a release gate
The survey offers a consistent picture across several questions. Respondents expressed limited support for an unrestricted AGI race. Only 12.4% favored developing AGI as quickly as possible when presented with a scenario involving a company that appeared close to a breakthrough.
The other responses favored conditions on development:
- 40.5% wanted development slowed until stronger safeguards were in place.
- 36.3% supported continued development with stronger independent safety oversight.
- 10.8% wanted development stopped entirely.
The numbers create a practical policy signal. A large majority wants a release gate, and the preferred gate has several possible forms. Some respondents favor delay. Others accept continued research and development if an independent review process has real authority. A smaller group supports a full stop.
The distinction matters for policymakers and researchers. Public skepticism does not automatically translate into opposition to AGI research. It creates a demand for conditions that make continued work more defensible. Companies seeking public acceptance will face pressure to show that safety decisions can survive outside scrutiny.
The same pattern appears in the question about technical capability and safety. Only 7.9% chose capability alone as the most important goal. Another 44.6% said capability and safety were equally important, while 42% chose safety alone. In total, 86.6% placed safety on par with or above capability.
That preference gives release reviewers a clear mandate. A system should demonstrate useful performance alongside controllability, monitoring, and credible limits on misuse. A capability benchmark by itself will carry little weight with a public that expects evidence of safe operation.
The developer still has an essential role
The approximately 30% who assigned the greatest safety responsibility to developers should not be dismissed. Their view has a strong practical basis. Developers understand the system’s architecture, training methods, known failure modes, and evaluation results better than most outside bodies.
A government office or scientific panel that receives only a polished summary may lack the information needed for a serious decision. External reviewers need access to technical evidence, secure testing environments, incident records, and staff who can explain the model’s behavior. Developers are the source of much of that evidence.
A workable release process therefore needs the company to perform several duties:
- Conduct rigorous internal evaluations before seeking approval.
- Document known limitations and unresolved safety concerns.
- Report serious incidents and failed safeguards.
- Provide reviewers with enough access to reproduce important findings.
- Explain the proposed deployment, user population, and misuse controls.
- Accept a delay when the evidence does not support release.
The developer’s role can be extensive without becoming final. A company may prepare the safety case, respond to technical questions, and make changes to the system. An external body can then determine whether the evidence meets the threshold for deployment.
This division also protects developers from carrying the entire burden alone. A company that delays a launch because of an external decision can point to a public process. That can reduce pressure on individual safety teams and senior executives who might otherwise have to choose between internal warnings and commercial deadlines.
Our Perspective
The strongest governance model is neither corporate self-approval nor government control without technical expertise. Developers should own the evidence because they understand the system best, but independent reviewers must be able to challenge that evidence and stop a release when serious risks remain unresolved. Public trust will depend less on promises of responsible innovation than on whether review authority is genuinely independent, technically capable, transparent, and enforceable.
The survey shows a three-way argument over authority
Government regulators, independent scientists, and developers each received about 29% support for the greatest responsibility. The close results show why a single decision-maker may struggle to earn public confidence.
Government regulators
Regulators have legal authority, investigative powers, and a public mandate. They can establish minimum requirements, demand records, impose penalties, and block a release that creates unacceptable risk. They can also coordinate with agencies responsible for consumer protection, critical infrastructure, labor, and national security.
Their weaknesses are familiar. Government processes can move slowly, technical expertise varies across agencies, and political pressure can affect enforcement. A regulator may also lack the staff and secure infrastructure needed to evaluate frontier systems at the pace of development.
Independent scientific experts
Independent experts can bring specialized knowledge and professional judgment. Their role could include red-team testing, replication of company evaluations, review of risk models, and assessment of whether claimed controls work in realistic conditions.
Independence requires more than a formal title. Reviewers need funding that does not depend on a favorable result, clear conflict-of-interest rules, access to relevant information, and protection from retaliation. A panel selected by the developer and paid only for rapid approval would provide limited independence.
The developer
The developer has the deepest technical access and the fastest route to system changes. It can adjust training, restrict tools, revise access controls, and investigate failures immediately. Those capabilities make internal safety work indispensable.
The commercial incentive to launch creates a structural concern. A company may sincerely believe that its system is ready while evaluating ambiguous evidence through the lens of competitive urgency. External review supplies a second judgment when that pressure becomes strongest.
International coordination
Only 12.7% selected an international regulatory organization. That result may reflect concern about distant or slow institutions. AI systems still cross borders, however, and companies can move development or deployment across jurisdictions. Domestic rules alone may produce gaps that companies can exploit.
International coordination may therefore work best through shared testing methods, incident reporting, and minimum safety standards. A single global body does not need to control every release for countries and companies to share meaningful rules.
Transparency can rebuild part of the lost trust
The survey found that 47.9% of respondents would trust an AI company more if it publicly disclosed a serious safety failure involving an advanced model. Another 31.1% said disclosure would make no difference, and 21% said it would reduce trust.
Those results support a straightforward lesson: people can distinguish between a failure and the way a company handles the failure. Public disclosure gives users, regulators, researchers, and other companies information they can use to respond. It also lets an organization show that its internal reporting system is working.
Disclosure needs useful detail. A vague statement that an incident occurred will have limited value. A credible report should explain:
- What the system did
- How the failure was discovered
- Which users or systems were exposed
- Whether the behavior was reproduced
- What controls failed
- What temporary restrictions were imposed
- What changes are being made before wider access
- Which independent parties reviewed the response
Companies may need limited confidentiality for security, privacy, and competitive reasons. Those limits should be specific and reviewable. Secrecy should not become a general excuse for withholding evidence about serious risks.
The survey also shows that transparency has limits. Among respondents who already had greater confidence in companies, 63.3% said disclosure would increase trust. Among lower-confidence respondents, that number fell to 32.6%. Skeptical audiences may view an incident report as useful evidence while still demanding changes to the underlying governance system.
For that group, transparency works when it connects to accountability. A company that reports a failure and then resumes the same release process will gain little credibility. A company that reports the failure, accepts independent review, changes its controls, and publishes the results gives the public a reason to reconsider its judgment.
Key Takeaways
- External oversight matters — About 70.5% of respondents assigned the greatest AGI release responsibility to someone outside the developing company.
- Safety must match capability — A combined 86.6% ranked safety as equally important as or more important than technical performance.
- Developers remain essential — Companies hold the technical access needed to build the safety case, disclose risks, and support independent testing.
- Authority must be enforceable — A credible review body needs the power to require mitigation, restrict deployment, or delay release.
Shared standards can preserve competition
The strongest support for a competitive structure went to companies cooperating on shared safety standards while continuing to compete. That option received 55.2% support. Another 20.2% preferred several companies competing closely. Government coordination received 11.2%, one company taking a clear lead received 8.9%, and international management received 4.4%.
The preferred model combines competition with common floor standards. Companies can compete on speed, price, usability, research quality, and product design while agreeing to baseline rules for high-risk evaluations, incident reporting, access controls, and release review.
Shared standards could cover:
- Common definitions for serious model failures
- Minimum tests for dangerous capabilities
- Rules for reporting incidents to regulators and peers
- Independent evaluation requirements for high-risk systems
- Security controls for model weights and sensitive tools
- Procedures for pausing or limiting a deployment
- Audits of monitoring and shutdown systems
The standards would need enforcement to avoid becoming voluntary public relations statements. Possible tools include licensing conditions, procurement rules, liability for reckless deployment, and penalties for concealing major failures. Regulators could also recognize companies that meet stronger standards through faster review of lower-risk systems, creating an incentive for credible compliance.
NIST’s AI Risk Management Framework provides one example of a structured approach to trustworthiness, evaluation, and risk management. The framework is voluntary, so its value depends on how organizations apply it and whether institutions connect it to stronger requirements. A common framework can improve consistency, while binding rules can give the framework practical force in high-risk settings.
The trust gap is already shaping company reputations
The survey found a striking difference between perceived capability and responsible development. OpenAI was selected by 31.7% of respondents as the company most likely to develop AGI first, yet only 11.4% trusted OpenAI most to develop it responsibly. Google received 50% for likely first development and 54.6% for responsible development.
These results show how quickly technical leadership can separate from public legitimacy. A company may be seen as the likely winner while losing confidence in its judgment. That gap creates direct business and policy risks. Regulators may apply greater scrutiny, partners may demand stronger contractual protections, and users may resist high-impact deployments.
The broader research supports the concern. A 2025 Pew Research Center survey found that 59% of the public had not too much or no confidence in US companies to develop and use AI responsibly. Stanford’s AI Index reported that more people viewed AI products and services as offering more benefits than drawbacks in 2025, while 52% also said AI made them nervous. Support and anxiety are developing at the same time.
Companies should read that combination carefully. Public support can remain available for useful AI systems while confidence in the institutions behind them stays weak. A successful product does not automatically create permission to release a more powerful system.
Before vs. After
AGI release decisions need to move from internal confidence toward accountable, evidence-based authorization.
Before
- The developer treated internal testing as the main release gate.
- Safety evidence was evaluated primarily by the organization facing commercial pressure to launch.
- Public oversight focused on the finished product rather than the decision to deploy it.
After
- The developer prepares a detailed safety case for external review.
- Independent experts test the claims, while an authorized body can require mitigation or delay.
- Release approval includes transparent conditions, incident reporting, and ongoing post-deployment monitoring.
What a credible release process could look like
A practical model would separate technical preparation from final authorization without cutting the developer out of the process.
- Internal evaluation: The developer runs capability, robustness, misuse, and control tests throughout training.
- Safety case: The company documents intended use, known risks, evidence quality, unresolved questions, and proposed limits.
- Independent testing: Qualified external teams receive controlled access to reproduce results and search for failures.
- Regulatory review: An authorized body checks whether the system and deployment meet the relevant threshold.
- Conditional approval: The system may receive limits on users, tools, scale, or duration while evidence develops.
- Incident reporting: Serious failures trigger notice to regulators, independent reviewers, and potentially the public.
- Post-release monitoring: Approval remains tied to ongoing evidence, with the ability to tighten restrictions or pause access.
This structure gives each group a defined responsibility. Developers bring technical knowledge. Independent experts challenge the safety case. Regulators provide legal authority. The public receives information about serious failures and the reasons behind release decisions.
The process will cost time and money. It may delay some launches and make frontier development harder to centralize. Those costs are part of the price of deploying systems with consequences that reach well beyond a product team.
The public standard is simple to state and hard to fake
The survey’s release-review result should guide the next stage of AGI policy. About 30% of respondents trust developers with the greatest responsibility because developers hold essential technical knowledge. Most respondents want an external actor to carry the final decision because the developer also faces pressure to win the race.
That arrangement can work when the external review has access, expertise, independence, and authority. Without those features, the process will look like a formality designed to validate a decision that has already been made.
Americans appear willing to accept continued AGI research and carefully managed development. They expect companies to prove that safety decisions are independent, transparent, and enforceable. The public is setting a demanding standard because the consequences of a rushed release could affect people who had no role in building the system and no practical way to opt out.
A company that reaches AGI first will gain attention. A company that can show its system passed serious outside review will have a stronger claim to public trust. The difference between those achievements will shape whether AGI deployment becomes a durable part of society or a source of repeated backlash and emergency intervention.
Sources and survey limits
The survey discussed here included 100 Americans ages 18 to 63. Its findings offer useful signals about attitudes toward AGI, safety, and corporate responsibility, while the small sample limits how confidently the results can represent the entire US population. The available material does not establish a probability sample, so a margin of error should not be assigned. Larger, transparent, probability-based studies would help test whether these patterns hold across the broader public.
Relevant background comes from Pew Research Center’s public opinion research, Stanford HAI’s AI Index, NIST’s AI Risk Management Framework, and guidance from the American Association for Public Opinion Research on interpreting survey results.
Frequently Asked Questions
Who should have the greatest responsibility for deciding whether an artificial general intelligence system is safe to release?
What conditions do Americans support for the continued development of artificial general intelligence?
How do Americans rank AI capability and safety when evaluating advanced artificial intelligence systems?
What role should AGI developers have in the safety review and release of advanced AI systems?
What would a credible external release-review process for an AGI system include?
How could public disclosure of serious AI safety failures affect trust in AI companies?
What shared safety standards do Americans prefer for companies competing to develop AGI?
What does the survey show about public trust in OpenAI and Google as potential AGI developers?
What are the main limitations of the survey of American views on AGI safety and corporate responsibility?
Sources
- bakslash.net – Public Trust in AI: What Americans Think About the Race to AGI
- Pew Research Center – How the US Public and AI Experts View Artificial Intelligence
- Stanford HAI – Public Opinion | The 2026 AI Index Report | Stanford HAI
- NIST – AI Risk Management Framework
- AAPOR – A Journalist’s Guide to Understanding Polls & Surveys





