The AI Refused to Build Their Target List

Two people asked me the same question a few weeks apart.

Both had tried to build a physician target list with Claude. Both got refused. The model would not do it, and the reason it gave was some version of "I can't produce personal information about individuals." One of them assumed the tool was broken. The other assumed he had prompted it wrong and was about to go buy a database seat over it.

Both asked me the same follow-up. Is that normal, or did I screw something up?

It is normal. They did not screw anything up. I use that same model most weeks to build exactly the thing it refused to build for them, and it does not refuse me.

Same tool. Different driver. Different outcome.

That gap is worth explaining, because the refusal reads like a verdict on the work. It may be a model responding to an ambiguous request, or refusing work it could reasonably help with.

A refusal does not necessarily mean the work is prohibited. Anthropic's usage policy prohibits unauthorized collection or misuse of private information, including non-public contact details, health data, and biometric data. It separately prohibits targeting or tracking a person's physical location, emotional state, or communications without consent. Those restrictions do not mean every request for public professional information must be refused.

Here is the part people miss. The model responds using the context available in the conversation and any connected tools. Unless you provide them, it does not know your client, buy box, or sourcing rules. A real engagement gives the work a business purpose, but it does not make every data request appropriate.

Consider a request like this:

"Build me a list of physicians in this metro with names, practice addresses, and contact information."

That could describe a Tuesday morning at any corp dev shop in the country. But it leaves out the sources and whether "contact information" means a published office number or a personal cell. That ambiguity can contribute to a refusal.

A refusal alone does not establish its cause. Missing context is one possible explanation. An overly cautious response is another.

The second thing worth understanding: much of the foundation for a legitimate physician target list is publicly disclosed professional information. Provider identifiers, specialties, business locations, license records, and aggregated utilization data. Public availability still requires judgment about which fields belong in a sourcing file.

CMS has been disclosing FOIA-disclosable provider records out of the National Plan and Provider Enumeration System since 2007, through the query-only NPI Registry and through full downloadable files. The dissemination program is free. The full replacement file refreshes monthly, with weekly incremental updates in between. The full file is too large to load into a single Excel worksheet.

Sitting next to that is the Medicare Physician and Other Practitioners By Provider and Service file, which reports utilization, submitted charges, and allowed amounts organized by NPI, procedure code, and facility or non-facility setting. These are historical Medicare Part B fee-for-service figures, not the practice's complete volume or revenue. Medicare Advantage and other payers are excluded, and records involving ten or fewer beneficiaries are suppressed. Then there are state medical board license lookups, secretary of state corporate filings, property records and recorded lease documents where available, and the practice's own website.

Those public sources are scattered across systems and formats. Pulling them together, checking what they actually establish, and filling the gaps is why a usable ranked list takes work.

Here is the split that matters, and it is the split you should be able to say out loud before you build anything:

The left column combines public professional records and business information that still need verification. The right column contains private information or intrusive or unsupported profiling that I exclude. State that distinction in the prompt, then enforce it in the file.

There is a real privacy issue inside the public file that shows why those judgment calls matter.

Some practice location addresses in NPPES are somebody's house. A solo provider with no separate office had to put something in a required field. CMS addressed this in a March 2024 Federal Register notice, effective April 3, 2024, which lets individual, Type 1 providers use a post office box or a private mailbox as the practice location when their home is their only physical location.

The change also lets eligible existing providers replace their home address. It does not require them to update it, so home addresses can remain in the public data. Deciding what belongs in your sourcing file still lands on you.

The test I use is simple. Is this relevant professional information from a public source, and is it appropriate for the business purpose? Public availability alone is not enough. A home address, personal contact detail, or speculative personal inference stays out, whether or not I could technically go get it.

That is a judgment you remain responsible for. A model can help flag concerns, but it cannot take that responsibility off your hands.

An unnecessary refusal is the loud failure. You know instantly that you got nothing, so you can clarify the request or ask someone.

The quiet failure is the expensive one. Ask a model for a physician target list without naming a market, a source, or a definition, and sometimes it will not stop. It will hand you forty names that look completely credible. Clean formatting. Plausible practice names. Confident tier rankings.

I have worked the verification pass on lists like that. Practices coded under a taxonomy that has nothing to do with what they actually do. A group carried as five physicians where three bill primarily out of other states. A partner who died in 2023 still listed on the site. I wrote about one of those crosswalks in detail in an earlier issue on the judgment layer. A generated list does not reliably flag any of it. The rows that are wrong look exactly like the rows that are right.

You catch that by checking primary records and knowing which inconsistencies deserve another look. Which is the uncomfortable part of the whole AI sourcing conversation: the tool compresses the work for people who could already do the work, and it manufactures confidence for everyone else.

Practical version. For the corp dev associates, the bankers, and the physician owners who read this and want to run at it anyway, four things change the outcome.

1. Scope the market before you open the tool. Specialty, geography, ownership status, size floor, exclusions. If you cannot write the buy box in two sentences, the model is not your problem yet.

2. Name your sources in the prompt. Tell it you are working from NPPES provider records, CMS utilization files, state license lookups, and corporate filings. Naming public sources helps clarify the request. Requiring a source link and date for each material claim makes the output auditable later.

3. Start with ten rows and check them by hand against the primary records. That is an initial diagnostic, not validation of the whole list. Investigate errors and verify the identity, fit, contact details, and material ranking claims for each target before outreach.

4. Decide your privacy line before you build, and write it down. Which fields you keep, which you drop, what happens when a practice address is obviously a house. Deciding that under deadline pressure with a list already built is how firms end up somewhere they did not intend to be. Tailor this as you see fit

And then the honest caveat. Setting up the sources, screening rules, and verification workflow can take days the first time. The faster repeat build depends on that groundwork. I have made this point from a different angle before, in an earlier issue on the intelligence layer. Teams are rarely short on target names. They are short on the ownership, fit, and timing read that turns names into a call order. That read is not in any file you can download.

Both of these guys hit the same wall and read it as a technology problem. The refusal alone does not tell us whether the problem was the prompt, the model, or both. But scope, sources, and a verification standard are things the operator can control. No tool removes that responsibility. I wrote a version of this argument two weeks ago in a piece on what a hundred target names actually cost. The assumption underneath both is the same one: that the hard part is the pull.

If a target list is the wall you hit trying to do this yourself, that is usually the beginning of a conversation with an operator. Not a dead end, and not a reason to go sign a database contract you will use twice.

If you are further along and want the list built rather than taught, book a call and tell me the buy box.

-Shawn

This newsletter is for informational purposes only and does not constitute investment, legal, or financial advice.