Short answer: neither is inherently “safer.” Safety depends more on the capability of the system, who can access it, and how it’s governed. Openness reduces some risks and increases others; the balance flips with the threat model and deployment context.
How openness can make AI safer
•Transparency and scrutiny: Open weights/code enable independent audits, reproducibility, and faster discovery/patching of safety issues and biases.
•Diversity and resilience: Multiple implementations reduce single‑vendor “monoculture” failures and supply‑chain concentration risk.
•Defensive innovation: Researchers can build safety tools (evaluations, filters, monitoring, watermarking) that interoperate broadly.
•User agency: Organizations can harden models to their own risk posture rather than relying on vendor defaults.
How openness can increase risk
•Capability proliferation: Powerful open weights lower barriers for misuse (e.g., removing guardrails, customizing for harmful objectives).
•Harder centralized controls: No single party can revoke or throttle access if problems emerge.
•Fragmentation: Many forks with uneven safety quality; patches and advisories diffuse slowly across the ecosystem.
•Ambiguity about provenance: It’s harder to ensure training data legality, privacy guarantees, and consistent documentation.
How closed/proprietary can make AI safer
•Access control and rate‑limiting: Providers can gate sensitive capabilities, throttle abuse, and revoke access quickly.
•Centralized monitoring: Telemetry and red‑teaming at scale; coordinated updates when new risks are found.
•Liability alignment: Contractual obligations, compliance attestations, and audits can be enforced through a single entity.
How closed/proprietary can increase risk
•Opaqueness: External researchers can’t easily verify claims; hazards may go undetected or be under‑reported.
•Single point of failure: A vendor mistake, breach, or policy change can cascade to many downstream users.
•Misaligned incentives: Commercial pressures may favor speed/capability over caution, with limited outside scrutiny.
Key distinctions within “open” and “closed”
•Code vs weights vs data: Releasing code alone is much safer than releasing highly capable weights; fully open datasets can pose privacy/IP risks.
•Model scale and domain: Opening small or narrow‑domain models generally carries less misuse risk than releasing frontier‑level, dual‑use systems.
•Deployment mode: Self‑hosted models (open or closed) shift responsibility for safeguards to the operator; API‑hosted models allow provider‑side controls.
A practical decision framework
•If your primary risk is inadvertent harm, bias, or vendor lock‑in: open models with strong community audits and your own controls can be safer.
•If your primary risk is malicious misuse of powerful capabilities: closed/API access with tight governance, logging, and kill‑switches tends to be safer.
•For mixed settings: consider hybrids—open code and evaluation suites, but gated access to high‑capability weights; or use smaller open models locally and high‑risk functions via a controlled API.
Safeguards that matter more than the open/closed label
•Pre‑release evaluations for capability and misuse potential; publish model and system cards.
•Clear acceptable‑use policies and technical enforcement (filters, rate limits, dangerous‑capability wrappers).
•Security hardening: dataset governance, privacy controls, supply‑chain SBOMs, signed artifacts, and reproducible builds.
•Post‑deployment monitoring: logging, anomaly detection, abuse response, and patch SLAs.
•Staged or structured release: progressively expand access as evidence of safety and mitigations mature.
Bottom line: Open-source AI can be safer for accountability, resilience, and user control—especially for smaller or domain‑specific models—while proprietary AI can be safer for limiting access to high‑risk capabilities and enabling rapid, centralized incident response. The safest route is to align openness with capability and to invest in concrete mitigations regardless of the licensing model.