AI safety is the study of whether these systems do what they were built to do, and what happens when they do not. That is narrower than it sounds and it covers a great deal.
The three kinds of risk
The field usually separates risk by where it comes from, because the remedies are different.
Misuse. The system works as intended and somebody uses it to cause harm. Fraud at scale, synthetic media of real people, generating material for an attack. Nothing is broken. The remedy is access control, refusal training, monitoring and law, and none of it is a modelling problem.
Accidents. The system fails, or succeeds at something other than what was intended. A model that scores well in testing and behaves badly in deployment, one that learns a shortcut nobody noticed, one applied to a population it was never trained on. The remedy is evaluation, oversight and design.
Structural harm. Nothing malfunctions and nobody intends harm, and the outcome is still bad. Competitive pressure to deploy faster than anyone can check, concentration of capability, or a labour effect nobody chose. The remedy is institutional rather than technical, which is why this branch is mostly policy.
The useful discipline is asking which of the three a given worry belongs to, because a misuse problem does not get solved by a better model and an accident does not get solved by a policy.
Present and future harm
The field's loudest internal disagreement is about weighting.
One position holds that the harms already happening are the subject. Discrimination in automated decisions, surveillance, labour displacement, fabricated information. These are measurable now and they fall hardest on people with the least recourse.
The other holds that capability is rising fast enough that future systems pose risks of a different order, and that preparation has to start before the capability arrives, because afterwards is too late.
These are frequently presented as opposed camps and the practical work overlaps heavily. Evaluation, interpretability, oversight and incident response serve both. It is worth knowing the argument exists so that a paper's framing makes sense, rather than treating the field as a single view.
Alignment and control
Two words used loosely and worth separating.
Alignment is whether a system pursues what its designers intended. A model optimising a proxy that diverges from the goal is misaligned, however capable it is.
Control is whether people can correct or stop a system regardless of whether it is aligned. Oversight, interruptibility and permissions are control problems, and they matter precisely because alignment cannot be assumed.
Most practical safety work is control. It does not require solving alignment and it does require deciding what a system is permitted to do.
Why it is not a solved engineering problem
Ordinary software is specified. Somebody writes down what it should do and it can be tested against that.
A learned system has no specification in that sense. Its behaviour is inferred from data, described statistically, and inspected only from the outside. You can measure what it did on the cases you tried and you cannot enumerate the cases you did not.
Everything that follows in this certification is a response to that one fact.