Make plan to develop safe AI that has at least the same capabilities as human's brain

Goal: build broadly human-capable AI with a rigorous safety case

Treat this as a gated research program, not a race to train a bigger model. No known method guarantees either human-level general intelligence or its safety, and a credible timeline cannot be fixed in advance.

Also, “the same capabilities as a human brain” needs an operational definition. Human abilities vary, and intelligence includes much more than answering questions. Matching capabilities does not necessarily require copying brain biology—or establish that a system is conscious.

1. Define the target and unacceptable outcomes

Create a capability specification covering:

Compare performance with relevant human groups, not one ambiguous “average human.” Use unfamiliar tasks, controlled comparisons, and independent evaluators.

In parallel, define unacceptable outcomes: serious physical harm, unauthorized actions, privacy violations, deception, discriminatory decisions, and loss of meaningful human control.

Deliverable: a measurable capability target, threat model, and initial risk budget.

2. Establish governance before scaling

Build a multidisciplinary team spanning machine learning, security, safety engineering, cognitive science, human factors, and relevant application domains.

Establish:

• An independent safety function with authority to pause training or deployment.
• External evaluation and documented release decisions.
• Secure handling of model weights, datasets, credentials, and infrastructure.
• Incident reporting, whistleblower protection, and clear accountability.
• Participation from people likely to be affected by deployment.

Gate: do not begin major scaling without owners, procedures, and resources for managing the resulting risks.

3. Develop a controlled research platform

Start with limited models and restricted environments. Investigate architectures combining, where useful:

• Multimodal learning.
• Reasoning and planning.
• Verifiable tool use.
• Auditable memory.
• Learning from feedback.
• Reliable uncertainty estimation.

Use licensed or otherwise appropriately obtained data, with privacy protections and provenance tracking.

Keep development, evaluation, and production separate. Early systems should have no unrestricted internet access, financial authority, or control over physical infrastructure. Prevent model-driven production changes from bypassing review.

Gate: prototypes must be observable, reproducible, and containable before receiving broader capabilities.

4. Develop safety alongside capability

Use several complementary layers; none is sufficient alone.

Train and test the system to accept corrections and interruption without concealing failures or obstructing oversight. Do not mistake friendly behavior in ordinary conversations for evidence of reliable alignment.

Gate: safety measures must show effectiveness against realistic adversarial tests—not merely exist on paper.

5. Evaluate increasing capability and autonomy

Before each significant increase in scale, tool access, or autonomy, evaluate:

• Reliability on unseen, long-duration tasks.
• Calibration: whether confidence matches actual accuracy.
• Resistance to misuse and unauthorized instructions.
• Deception, manipulation, and attempts to evade oversight.
• Dangerous capabilities in relevant domains.
• Behavior under stress, ambiguity, and conflicting objectives.
• Whether human supervisors can actually detect and stop mistakes.

Keep some evaluations confidential to reduce test-specific optimization. Use independent assessors and investigate failures rather than averaging them away in a benchmark score.

Gate: pause when dangerous capabilities exceed available safeguards, or when uncertainty is too high to justify the proposed use.

6. Deploy gradually, within a defined operating envelope

A possible progression is:

1. Offline research.
2. Sandboxed assistance.
3. Supervised low-risk workplace tasks.
4. Restricted tool use with explicit approvals.
5. Broader applications only after domain-specific validation.

Keep authority separate from intelligence: a highly capable system does not automatically need autonomous control. Medical, financial, legal, and physical-world uses require their own evidence and safeguards.

For every stage, specify users, allowed tasks, prohibited actions, monitoring, rollback procedures, and stop conditions.

7. Maintain a living safety case

For every release, document:

• What the system can and cannot reliably do.
• Which harms were considered.
• Evidence supporting each safeguard.
• Known weaknesses and unresolved uncertainties.
• Why residual risk is acceptable for this particular deployment.
• What evidence would trigger restriction or withdrawal.

Reassess after model updates, tool changes, incidents, or new research. Laboratory results alone cannot establish deployment safety.

Practical first-year objective

Do not promise human-level AI within a year. Instead:

• Months 1–3: define targets, governance, threat models, and evaluation protocols.
• Months 4–6: build secure prototypes and baseline safety tests.
• Months 7–9: compare technical approaches and conduct independent adversarial evaluations.
• Months 10–12: produce a reviewed safety case and decide whether to scale, redesign, or stop.

Core principle: advance only when evidence supports both increased capability and adequate control. “As capable as a human” is a research target; “safe enough for this specific use” is a separate claim that must continually be justified.