Skip to main content
Back to News
news/AI Safety

Nvidia CEO Says AI Safety Is an Engineering Problem

Nvidia CEO Jensen Huang says AI safety is an engineering problem, not a legal one, renewing the debate over regulation as agents gain real-world powers.

Stefan Trbojevic

Stefan Trbojevic

16 September 20262 min read
LinkedIn

The takeaway

Safety must be engineered into the complete agent runtime, while accountability and liability cannot be delegated to model developers alone.

Why it matters for builders

Separate model output from authorization. Put deterministic policy gates, approvals, narrow workflow identities, observability, rate limits, and idempotent retries around consequential agent tool calls.

Nvidia CEO Says AI Safety Is an Engineering Problem

Nvidia CEO Jensen Huang argued this week that AI safety should be handled by engineers and market forces rather than new laws. Speaking at Salesforce’s Dreamforce conference, Huang described AI as a complicated computing system built by humans, and said safety is therefore an engineering problem, not a legal one. TechCrunch reported the remarks on September 15.

Huang’s position arrives as AI systems move from answering questions to taking actions. His argument is attractive to builders because it puts responsibility close to the people who design, test, and deploy the technology. But it also leaves an unresolved question: who defines an acceptable failure when an agent can send messages, change records, spend money, or trigger production infrastructure?

The engineering case for safety

There is a strong practical argument for treating safety as an engineering discipline. Teams can test models before release, monitor behavior in production, add rate limits, restrict permissions, and stop systems that behave outside defined boundaries. These controls are concrete, measurable, and can improve without waiting for a legislative cycle.

That approach also matches the reality of agentic workflows. A model is only one component. The effective system includes prompts, retrieved documents, memory, tools, credentials, orchestration logic, and fallback paths. A failure can come from the connection between those pieces even when the model itself performs as expected.

Where builders need more than good intentions

The weakness in a pure self-governance model is that market pressure does not catch every externality. Software companies have shipped unsafe updates before, and AI systems can affect people who never chose to use them. Existing liability rules may eventually apply, but relying on future court decisions is not a runtime control.

For n8n builders, the immediate lesson is to separate model output from authorization. Let the model propose an action, then enforce deterministic policies around the tool call. Require approval for irreversible operations, give every workflow a narrow identity, log the inputs and outputs at external boundaries, and make retries idempotent.

Builder impact: Huang is right that safety must be engineered, but production agents need both engineering controls and clear accountability. Treat regulation as a constraint to design for, not as a substitute for testing, observability, and bounded autonomy.

Share𝕏

The Automation Brief

Read 5 AI stories instead of 50.

The essential moves in AI agents, models, automation and infrastructure — filtered for builders and operators, with the part that actually matters.

No noise. Unsubscribe anytime.

Editorial notes

Reported by

Stefan Trbojevic

Edited by

n8n Lab Editorial

Published

16 September 2026

Updated

16 September 2026

AI disclosure: AI assisted with research and drafting. Factual claims are reviewed by an editor.

n8n Lab is an independent service provider. We are not affiliated with, endorsed by, or sponsored by n8n GmbH. “n8n” is a trademark of n8n GmbH and is used here only to describe the platform-specific implementation and automation services we provide.