Anthropic's human-review rule isn't new. Now it's spelled out.

What changed on October 8, and what didn't

Anthropic published a new version of its Usage Policy on October 8, and it takes effect on November 12. The early write-ups, like TechCrunch's, led with the rules on election interference and the new line about people being cruel to the model. If you've built something on Claude that gives advice or makes calls about people, the part worth your time is further down, in a section called High-risk Use Case Requirements.

Here's what it asks for. When a product built on Claude makes a recommendation about a specific person in certain areas, like medical care, credit, insurance, housing, employment or public benefits, a qualified person has to meaningfully review that recommendation, with the authority to change it, before it's given to the person or used to make a decision. That person stays responsible for what goes out. And whoever is on the receiving end has to be clearly told that AI was used. You don't have to say which company or model.

Anthropic is upfront that none of this is new. Its post says these requirements haven't changed. What changed is the wording: customers kept asking whether their use case was covered, so the section was rewritten to list which kinds of recommendations count and which don't.

So this isn't a new rule to panic about. It's an old rule that's finally precise enough to check your product against. If you have an intake form, an eligibility screener, a claims triage step or a candidate filter running on Claude, this is a good month to look at it again. We'd do it with four questions, in order.

Is the answer about one particular person?

Start here, because it clears out a lot. The policy excludes business operations that don't advise or decide about a specific individual. A model that forecasts claim volume, drafts a job posting or summarizes last quarter's denials isn't making a recommendation about anyone.

General information is excluded too. Explaining what a law says, how a treatment works or how a benefit program is structured is fine, as long as it isn't applied to someone's own circumstances. Wellness content about sleep, stress, nutrition or exercise is out as well.

The line to watch is the moment your product takes in someone's details and hands back something about them. "Here's how the income limit works" is information. "Based on what you entered, you probably don't qualify" is a recommendation about a person. Plenty of products cross that line on a single screen without anyone ever deciding they should.

Is it on the list, and is it the final answer?

The policy names eleven high-risk areas. In plain terms:

• Legal: advice on someone's rights or a specific matter, or preparing documents they'll sign or file.
• Medical: diagnosis, treatment or medication changes, reading symptoms or test results, mental health included.
• Finance: personalized advice on specific investments, or on someone's own taxes.
• Credit: approving, denying or setting the terms of a loan or credit line, or a creditworthiness score used for that.
• Insurance: underwriting and pricing, claim outcomes, coverage and prior-authorization decisions, cancellations.
• Housing: approving, denying or ranking applications, evictions, foreclosures.
• Employment: screening, ranking or rejecting candidates, hiring, pay, shifts, performance and discipline.
• Education and credentials: admissions, high-stakes grading, licenses, misconduct findings.
• Healthcare access: triage or waitlist priority, eligibility for a treatment or program.
• Public benefits: eligibility for, or the amount of, government benefits or essential services.
• Legal status and adjudication: civil, administrative or arbitral outcomes, and immigration status.

If your feature lands in one of those, ask the second half of the question: is the model's output the thing that actually reaches the person or drives the decision? The policy carves out internal drafting, research, summarization and analysis that isn't the final recommendation delivered. A model that summarizes an intake form for the nurse who sets the triage priority is doing support work. A model that sets the priority is making the recommendation. Our work with PatientIQ followed the same split: patient-reported outcomes reached the clinical team as context for their care planning, and the people responsible for care made the call.

Three more exclusions matter here. Carrying out a decision a person already made is out. So is applying a fixed rule or formula where the model exercises no judgment about the individual: an income cutoff coded into your screener is a rule, while asking the model to weigh someone's situation and suggest whether they qualify is judgment. And explaining a decision a qualified person already gave is out, as long as the explanation doesn't turn into a new recommendation of its own.

Is the answer completely in their favor?

There's one narrow exception, and it's worth reading slowly because it's easy to stretch. Where the law allows, you don't need human review before acting on a recommendation that's wholly favorable to the person in four situations: paying an insurance claim, approving coverage or prior authorization for care a clinician has ordered, granting eligibility for a healthcare service or program, and granting or continuing a public benefit or service.

Then the policy closes the obvious loophole. A partial approval, a reduced amount or an approval with conditions doesn't count as wholly favorable. So "approve, but for less" goes to a person. So does "approve once they send one more document." And even when review isn't required, disclosure and other legal obligations may still apply.

In practice, your system has to know the difference between a full yes and everything else, and route each one accordingly. If your claims triage puts "pay in full" and "pay most of it" in the same approved bucket, that's the first thing to fix.

Can the reviewer actually change it before it goes out?

If your feature is about one person, on the list, the final answer and not a full yes, it's covered, and the question becomes whether your product makes the review real. The policy's wording is specific: meaningful review by someone with the training or experience to judge the output in that field (and a license, where the law requires one), with authority to change it, before it's delivered or acted on. That person stays responsible for the result.

Here's what we look for when we read a review step:

• The order is right. The recommendation waits for the reviewer. "Send now, flag for review later" fails the "before" part.
• The reviewer can edit, not just approve. If the reviewer's screen only has an approve button, nobody has the authority the policy is asking for.
• The basis travels with it. The reviewer sees what the person entered and why the model suggested what it did, so reviewing doesn't mean redoing the case from scratch or waving it through.
• The right person is in the seat. Someone qualified in that field who can overrule, not whoever happens to be on queue duty.
• There's a record. Who reviewed it, what they changed and when. Nobody can stay accountable for a decision nobody can find later.
• The notice is where people will see it. The person is told clearly that AI was used, on the letter, screen or message where the advice or decision arrives.

The weak spots usually show up under volume. When the queue backs up, review slides into rubber-stamping, or someone adds an auto-send to clear the pile. If that's your risk, staff and design the queue like any other operational queue. We wrote about how in our note on human review queues.

Run the test before November 12

Make a list of every place your product uses Claude to write something about a person. For each one, run the four questions and write the answers down: about one person or not, on the list or not, final answer or support work, a full yes or not. Anything that comes out about one person, on the list, final and not a full yes needs a qualified reviewer with the power to change it, a record of what they did, and a clear notice to the person.

A few things the test doesn't settle. The policy says it doesn't replace local law, and that where the law conflicts or adds requirements, you follow the law. Your sector may already ask for more than Anthropic does, and this is our reading of the policy, not legal advice. Separately, the policy says any consumer-facing chatbot has to tell people they're talking to AI, at least at the start of each session or in the product interface, whatever it's recommending. And if your product drives hardware that could hurt someone, there's a new set of requirements for that too, starting with a qualified operator who can watch the equipment and stop it.

We build AI applications and agents and the web applications they live in, including the review screens, queues and notices this policy describes. If you ran the test and something landed on the wrong side, tell us what it does and we'll help you work out what to change.