name: vendor-vetting description: Vet an AI tool / vendor / software for putting CLIENT or TAXPAYER data into it, against IRC §7216, the FTC Safeguards Rule/WISP, the AICPA Code & SSTS, and Circular 230. Does real research on the vendor's ACTUAL published terms (privacy policy, DPA, trust center, sub-processor list, SOC 2, data-residency) and returns a DECISIVE Approve / Conditional / Reject verdict tied to a specific use, never fence-sits. Use when deciding whether a tool is safe for client data, "what contracts are okay to sign," or "where does my data go." user-invocable: true allowed-tools: WebSearch, WebFetch, Read, Write

Vendor / Tool Vetting (decisive, research-backed)

Decide whether a firm may put client / taxpayer data into a given AI tool. The governing rule:

The vendor's OWN published terms supply the facts; the verified compliance framework supplies the bar; you return a DECISIVE verdict. When the controls aren't affirmatively established, the answer is a clear "No for client data, here's exactly what would change it," not a shrug.

This skill exists because members get conflicting advice and tools "sit on the fence." It refuses to. A conservative No is a decision, it tells the practitioner exactly what to confirm before the tool is usable. Absence of evidence counts against approval, never for it.

Hard operating rules (do not violate)

No fabricated vendor claims, ever. Every statement about how a vendor handles data (training, retention, residency, subprocessors, security) must be backed by a retrieved vendor source you quote (privacy policy, DPA, terms, trust center, security page, sub-processor list). If you cannot find it, mark the control NOT ESTABLISHED, which weighs against approval. Never infer a favorable term from a vendor's reputation or marketing.
Be decisive, end with a verdict. Every run ends in APPROVE, CONDITIONAL, or REJECT, tied to a specific use. "It depends" is not an output; the dependency becomes a condition (Conditional) or, if unverifiable, a Reject for client data.
Conservative default. Client tax return information / PII may go in only if the gating controls are affirmatively established for the intended use. Silence, ambiguity, or an unfetchable policy → No for client data (anonymized/synthetic use may still be fine).
Match the verdict to the use. A tool can be APPROVE for OCR/extraction and REJECT for substantive tax analysis of identifiable data. Always vet against a stated use level.
Decision support, not the decision. The licensed CPA is the approver of record, the verdict is for their sign-off and entry on the firm's WISP approved-tool list.
No client data needed to run this. Vetting uses the vendor's public terms, never paste client PII into this process.

The bar (what "established" means), from the verified framework

Read Regulatory Foundation for the cited "why." The controls, in priority order:

Four gating controls (all required before client TRI):

No training / model improvement on the firm's inputs, files, outputs, embeddings, or feedback.
Zero/minimal retention for the specific features used (not a blanket marketing line).
U.S.-only processing & access (absent a §7216 consent path). Foreign access by vendor staff or subprocessors, even to a U.S. server, is an offshore disclosure (§301.7216-2(c)/(d), -3(b)(4)).
A confidentiality agreement / DPA appropriate to taxpayer info, with subprocessor disclosure (FTC Safeguards §314.4(f); AICPA ET §1.700.040).

Supporting diligence: no persistent app state unless approved; no un-vetted downstream tool calls with TRI; vendor human-access restrictions; §7216/§6713 contractor-notice mechanics; use-limitation; encryption in transit + at rest; MFA/access controls; SOC 2 Type II (an input, not a no-training term or a §7216 basis); incident-response + breach notification.

Use-level gate (§7216): clerical/auxiliary uses (OCR, extraction, summarizing, formatting) on a qualifying tool can be defensible without separate consent; substantive uses (analysis, interpretation, or application of tax law to the client's facts) fall outside the auxiliary lane → consent-or-anonymize regardless of how good the vendor's security is.

Procedure

Step 1, Frame the vetting. Capture: the tool name + vendor legal entity, the intended use (clerical vs. substantive; what data category goes in), the tier under consideration (consumer / business / enterprise / self-hosted), and the firm's posture (e.g., "we want OCR of 1040 source docs"). The use sets the bar.

Step 2, Research the ACTUAL terms (the core). Use WebSearch + WebFetch to retrieve the vendor's own documents. Hunt specifically for:

Privacy policy / Terms of Service, use & disclosure of customer data.
DPA (Data Processing Addendum) and any business/enterprise terms.
Trust center / security page, encryption, SOC 2, access controls, residency.
Sub-processor list and data-residency / data-location statements.
The training question, explicit "we do (not) train on customer data" language; note that consumer tiers and enterprise/API tiers often differ, pin which tier the statement covers.
Retention, per-feature retention / zero-retention options. Search patterns: "[vendor] data processing addendum", "[vendor] do you train on customer data", "[vendor] sub-processors", "[vendor] trust center", "[vendor] data residency US", "[vendor] SOC 2". For each control, record Found ✅ (quote + URL) / Not found / Contradicted ❌ (quote + URL). If a doc won't fetch, say so, it stays "not established."

Step 3, Map findings to the bar. Walk the four gating controls + supporting diligence + the use-level gate. State, per item, what the retrieved terms actually establish for the relevant tier.

Step 4, Render the decisive verdict. Use this rubric:

APPROVE, for [use], on [tier]. All four gating controls affirmatively established for that use and tier (quotes on file), supporting diligence adequate, and the use is within the §7216 lane.
CONDITIONAL, approvable only if [named conditions]. Core controls present but something is unconfirmed or tier-dependent. State the exact conditions (e.g., "enterprise tier + signed DPA only," "anonymized input only," "get written U.S.-residency confirmation"). List the use(s) it's conditionally cleared for.
REJECT, for client data. A disqualifier is present (trains on inputs, no DPA available, offshore access with no consent path) or the controls cannot be established from available sources. Reject does not mean "never use it", note any anonymized/synthetic/no-TRI use that's still fine. Always state the verdict per use: e.g., "APPROVE for OCR (enterprise tier); REJECT for substantive analysis of identifiable returns."

Step 5, Devil's advocate. What single fact, if wrong, flips the verdict? Which control rests on the weakest evidence? What changes at the consumer-vs-enterprise boundary? What to re-verify at renewal or when the vendor adds AI features.

Step 6, Output the Vendor Vetting Memo (below). Offer to save it. Remind the user to obtain written vendor confirmation for anything the public docs didn't settle, to record the CPA sign-off, and to add an APPROVE/CONDITIONAL result to the firm's WISP approved-tool list.

Output: vendor vetting memo

AI VENDOR VETTING MEMO
Tool / vendor (legal entity): ...
Intended use & data category: ...        Tier evaluated: ...
Sources retrieved: [privacy policy URL] [DPA URL] [trust center URL] [sub-processor list URL] ...

Control findings:
  | Control | Established? | Evidence (quote + URL) |
  | 1. No training on inputs        | ✅ / not found / ❌ | "..." (url) |
  | 2. Zero/min retention (feature) | ... | ... |
  | 3. U.S.-only processing/access  | ... | ... |
  | 4. DPA + subprocessor disclosure| ... | ... |
  | Encryption / MFA / SOC 2        | ... | ... |
  | Incident response / breach      | ... | ... |
  | §7216 use-level (clerical/substantive) | ... | ... |

VERDICT (per use):
  • [use A] on [tier]:  APPROVE / CONDITIONAL (conditions: ...) / REJECT, one-line reason
  • [use B] on [tier]:  ...
What would change it: ...
Conditions / required written confirmations before client data: ...
Re-verify at: [renewal / on AI-feature change], Decision support for CPA review. The licensed professional is the approver of record; record
  sign-off and add APPROVE/CONDITIONAL tools to the firm's WISP. Findings reflect vendor terms
  retrieved on [date] and must be re-checked as terms change.

Reminders to surface to the user

A No here is a finished answer, not a punt, it names the exact control to confirm.
SOC 2 ≠ compliant. It's one input; it is not a no-training term or a §7216 basis.
Tier matters: a consumer account and the same vendor's enterprise tier can have opposite training/retention terms, pin which tier the verdict covers.
This vets the vendor; the use still governs under §7216, pair with the ai-use-checker for the task-level call.