Gary Marcus Challenges AI Developers on System Control

Robust AI Inc. co-founder and former CEO Gary Marcus argues that AI developers, including OpenAI, lack sufficient safeguards for systems they cannot reliably control.

Gary Marcus is challenging the basis on which artificial intelligence systems are deployed: whether developers have adequate safeguards for technology they cannot reliably control. His criticism includes OpenAI and puts operational reliability, rather than a system’s apparent intelligence, at the center of the debate.

For businesses weighing AI adoption, that distinction matters. A system can produce useful answers without being dependable enough to act without supervision. The commercial question is not simply whether it can complete a task, but whether a buyer can define its authority, detect failures and stop an unwanted action.

Marcus, Robust AI Inc. co-founder and former CEO, made the argument in a conversation with Romaine Bostick on Bloomberg’s “The Close,” according to Bloomberg Technology. His criticism is an assessment of developers’ safeguards, not evidence in itself that a particular product has suffered a particular failure.

Capability and control are different tests

The central distinction in Marcus’s argument is between what an AI system can do and whether its behavior can be reliably constrained. A convincing demonstration may establish that a task is possible. It does not, by itself, establish that the system will behave acceptably across the situations it encounters after deployment.

That creates a different test for customers. Rather than judging only the quality of an answer, they need to consider the consequences of a wrong answer and the authority the system has to act on it. Drafting text for review and making a consequential decision without review are different operating arrangements, even if they use similar underlying technology.

Marcus’s stated concern does not identify a specific missing safeguard, a named technical test or a particular system configuration. It would therefore go beyond the available facts to assign him a detailed prescription. The defensible takeaway is narrower: he argues that existing protections are insufficient relative to developers’ ability to control their systems.

That leaves an important question for the industry to answer with evidence. What does reliable control mean for a particular product, and under which conditions has it been demonstrated? A general assurance about safety cannot answer every question about a specific business use.

Business buyers need evidence tied to the task

For a company evaluating AI, the practical response to this criticism is to examine the proposed deployment rather than accept or reject the technology as a whole. A useful review would ask what information the system can access, what changes it can make and which decisions require a person’s approval.

These are analytical questions prompted by Marcus’s argument, not safeguards he is reported to have individually demanded. They help translate a broad concern about control into procurement decisions that a business can assess before granting a system access to sensitive work.

The distinction also changes how performance should be evaluated. An impressive result on a selected task may matter less to a buyer than consistent behavior under the buyer’s actual conditions. Testing should address the intended workflow and the consequences of failure, rather than rely solely on demonstrations of general capability.

Responsibility is another issue. Buyers should be able to identify who reviews errors, who can suspend the system and who owns the decision to expand its permissions. Those questions concern business governance as much as model design. Technical safeguards cannot settle an accountability problem if the organization has not assigned responsibility.

None of this establishes that OpenAI or another developer lacks any particular control. It establishes the evidence a customer would need to evaluate Marcus’s broader claim. The supplied facts contain no developer response or detailed description of developers’ safety measures, so a direct comparison with those measures is not possible here.

The financial risk lies in deployment decisions

Marcus’s warning has a financial dimension even without a company-specific share-price reaction. Businesses considering AI must weigh potential benefits against the costs of supervision, testing and correction. If a proposed workflow requires extensive human checking, that requirement belongs in the investment decision rather than being treated as an afterthought.

Failures could also create costs beyond correcting an output, depending on the task and the information involved. That is a potential exposure, not a reported loss in this case. The available facts do not establish damages, a customer incident or a change in spending attributable to Marcus’s remarks.

The broader market backdrop was positive. At the most recent close, as of October 2, 2026, at 20:00 GMT, the supplied market data showed the S&P 500 benchmark proxy up 0.74% and the Nasdaq 100 benchmark proxy up 1.02% on the day. Those broad moves do not establish how investors assessed Marcus’s criticism or the safety of any AI product.

For investors, the relevant distinction is between enthusiasm for AI demand and evidence that deployments can produce durable business value. Strong demand does not answer the control question. Conversely, a criticism of safeguards does not, by itself, prove that a developer’s commercial prospects have deteriorated.

Watch for testable claims, not competing assurances

The next useful development would be evidence that makes the disagreement more specific. Developers could explain the boundaries of a system’s permitted behavior, the conditions under which controls were tested and the limitations that remain. Customers could assess whether those conditions resemble their own intended uses.

Specificity matters on the critical side as well. Identifying the behavior that cannot be reliably controlled would allow buyers to distinguish a general objection from a problem relevant to their deployment. Without that detail, the debate risks remaining too broad to guide a purchasing or investment decision.

Marcus’s intervention puts that burden of proof in focus. The commercial test is not whether an AI system looks capable, but whether its capabilities can be used within boundaries a business understands and can enforce. That is the question buyers should carry into their next demonstration, contract discussion and deployment review.

Frequently asked questions

What is Gary Marcus’s concern about AI development?

Gary Marcus argues that AI developers, including OpenAI, lack sufficient safeguards for systems they cannot reliably control. His criticism centers on whether systems can be constrained reliably, rather than simply whether they can perform useful tasks. The available facts do not identify a particular product failure or a specific missing safeguard.

Who is Gary Marcus?

Gary Marcus is Robust AI Inc. co-founder and former CEO. He discussed concerns about AI development with Romaine Bostick on Bloomberg’s “The Close.” In that conversation, he argued that developers, including OpenAI, have insufficient safeguards for systems they cannot reliably control.

Did Marcus identify specific safeguards that are missing?

The supplied account states Marcus’s broad criticism but does not identify specific safeguards, technical tests or product configurations. It would therefore be unsupported to attribute a detailed safety prescription to him. Questions about permissions, human review and stopping unwanted actions are practical analytical extensions, not reported individual demands from Marcus.

How should businesses evaluate this warning?

Businesses can use the warning to examine a proposed AI deployment’s authority, failure consequences and supervision requirements. Relevant questions include what the system can access, what actions require approval and who can suspend its use. Those checks help evaluate a specific workflow without assuming that all AI applications carry identical risks.

Does the report establish that OpenAI suffered a safety failure?

No particular OpenAI safety failure is established by the supplied facts. Marcus includes OpenAI in his criticism of developers’ safeguards, but that assessment is not documentation of a specific incident. The available material also does not provide a developer response or enough detail to compare individual safety measures.

Do the market figures show investors reacting to Marcus?

No. The supplied market snapshot shows positive daily moves in broad benchmark proxies at the most recent close, but it does not establish a reaction to Marcus’s remarks. Broad market performance cannot demonstrate whether investors accepted his criticism, rejected it or changed their assessment of any particular AI developer.

Sources

• NYU's Gary Marcus on AI development concerns — Bloomberg Technology

Photo: StockSnap · Pixabay Content License — source