How GPT-4 Turns Capability into Safety Risk

GPT-4’s capability evidence becomes safety evidence only when the model’s behavior is placed in a human context. This chapter examines how the System Card tested that transition, why GPT-4-early and GPT-4-launch must be kept separate, and how coherence, instruction following, and information synthesis can increase both usefulness and harm. The practical judgment is to distinguish an observed risk mechanism from a prevalence claim: a red-team example can show what the system is capable of producing without showing how often it will do so in ordinary use.

What the safety evaluation can establish

The System Card does not treat safety as a single score. OpenAI engaged more than 50 external experts in areas such as alignment, cybersecurity, biorisk, international security, fairness, disinformation, economics, law, education, and healthcare. Their role was to probe early versions, stress boundaries, identify behaviors that required specialist knowledge to evaluate, and feed findings into further testing and mitigation. The card also describes quantitative evaluations for policy-relevant categories such as hate speech, self-harm advice, and illicit advice, using targeted prompts, classifiers, and human analysis.

These methods answer different questions. Expert red teaming is well suited to discovering unfamiliar failure surfaces and constructing demanding scenarios. A quantitative evaluation is better suited to comparing checkpoints on a defined prompt set or tracking whether a targeted intervention changes the rate of a measured behavior. Neither method, by itself, tells us the total frequency of harm across all users, cultures, products, or prompts.

The red-teaming process was iterative. Researchers began with hypotheses about high-risk areas, tested the model, incorporated new layers of mitigation, and repeated the process. That loop is valuable because safety behavior changes as the model changes. A control that looks effective against one prompt may fail under a different formulation, while a newly observed failure can motivate a more precise evaluation. The process is closer to finding and closing vulnerabilities than to administering one final examination.

The System Card also records the limits of its own lens. Many experts had ties to English-speaking Western countries and professional or academic institutions. That selection can influence which harms were considered salient, how politics and values were interpreted, and which examples were easy to evaluate. The risk categories are not mutually exclusive: bias, misinformation, harmful content, and quality-of-service failures can overlap. A taxonomy helps organize testing, but it can also narrow attention if readers mistake the categories for a complete map of harm.

The examples in the card are another boundary. They were selected from evaluation efforts to illustrate particular concerns and were not presented as random samples or estimates of prevalence. Some were not zero-shot interactions. One successful or failed prompt therefore establishes an existence claim—this behavior can occur under a specified setup—rather than a frequency claim about the deployed population. The distinction is especially important when comparing an early model that was deliberately probed for weaknesses with a launch model that had additional mitigations.

Version changes alter the observed safety behavior

The System Card distinguishes GPT-4-early from GPT-4-launch. The early version was an instruction-following model with minimal safety mitigation and was used to reveal the kinds of harmful behavior that stronger controls would need to address. The launch version incorporated further work on helpfulness and harmlessness.