Abuse (of ML systems)
Concrete Problems in AI Safety — inherited
An adjacent research area concerned with preventing the misuse of machine learning systems to attack or harm people.
An ML system can itself be the weapon, built or deployed to defraud, spam, or harm people at scale. That is what this corpus means by abuse, one of the adjacent research areas Concrete Problems in AI Safety (2016) gestures to while marking out its own territory of accidents.
A section on what the term covers comes first, then one on its modest place in the corpus, beside the security research it borders.
What the term covers
Abuse, in the vocabulary Concrete Problems borrows for its closing survey of adjacent research, names the study of how machine learning systems can be turned into weapons: an ML system trained or deployed by an adversary specifically to attack or harm people, such as a system that automates fraud, generates spam or phishing content at scale, or (the paper's own example) a "smart hacker" system trained to break into a website (concrete-problems, §"Abuse:", p. 21). The concern predates this paper by years, tracking a broader security-research awareness that machine learning lowers the cost of running attacks that once required a skilled human, not just the cost of defending against them. Concrete Problems cites the area only in passing, as one line in a list, without proposing any technique of its own for it.
Its place in the corpus
Abuse-ml does no technical work inside the paper; it exists to mark a boundary. Section 8 lists it alongside privacy, fairness, Security (attacks against ML systems), transparency, and policy as six areas the paper's own subject, Accidents in machine learning systems, deliberately does not cover, because accidents are unintended harm from poor design rather than harm an adversary sets out to cause. The one substantive claim attached to it is a footnote distinction from security: security is an attack against a legitimate ML system, while abuse is an attack carried out by an ML system an adversary controls (concrete-problems, §"Abuse:", p. 21). That symmetry is captured directly in Security (attacks against ML systems) — is the mirror image of → Abuse (of ML systems), which places the two concepts as mirror images defined by which side of the attack the ML system sits on — a relationship documented in the Two things built identically, pointed in opposite directions connective theme, while the broader six-way list sits inside the Drawing the boundary: what accident risk is not theme and the Where Concrete Problems draws its own lines supertheme. Read against Long-term / superintelligence AI-risk framing, abuse and security share something accidents-in-ml lacks entirely: both require an adversary, whereas an accident by definition does not.