To protect PHI in ABA AI prompts, logs, and feedback, map every copy created from input through deletion. Use an approved purpose and data route, limit fields and access, verify business-associate and vendor terms, separate production records from evaluation feedback, control training and secondary use, preserve audit evidence, and test retention, export, deletion, incident, and termination procedures before real client information enters the workflow.

Map the complete data route

Keisha diagrams intake source, prompt builder, retrieval store, model provider, orchestration layer, output screen, application database, logs, analytics, support tickets, feedback queue, backups, and deletion service. She includes cached prompts, screenshots, traces, error payloads, human corrections, and vendor observability tools. A field omitted from the final output may still exist in an input, log, or backup. The map identifies owner, purpose, data class, location, access, retention, downstream recipient, and deletion method for every copy.

Determine entity and vendor roles by function

HHS business-associate guidance now includes a third-party AI chatbot handling portal PHI as an example, while actual status depends on the service performed and the parties involved. A vendor that creates, receives, maintains, or transmits ePHI on behalf of a covered entity or business associate may be a business associate even when the product is marketed as a general AI tool. Classify the practice, vendor, subcontractors, and any mixed direct-to-consumer function with privacy and legal owners before use.

Limit data for the approved purpose

HHS minimum-necessary guidance generally applies to uses, disclosures, and requests for PHI, with defined exceptions. It is not a blanket permission to place a full chart in an internal AI prompt. Keisha specifies which roles need which fields for each workflow and removes unrelated narrative, identifiers, attachments, metadata, and prior outputs. Treatment disclosures between providers have a rule-specific exception; that exception does not make every internal AI use or vendor disclosure necessary.

Separate production, testing, and feedback

Production output review, quality evaluation, vendor troubleshooting, product improvement, and model training are different purposes and data routes. Feedback may contain copied PHI, source text, reviewer identity, and a corrected answer. Route each purpose through its own approval, access, retention, and vendor-term decision. Use purpose-built fictional cases when they can answer the test. A toggle labeled "do not train" needs evidence about prompts, logs, support access, subprocessors, abuse monitoring, and retention, not a marketing assumption.

Verify contract and technical controls together

HHS cloud guidance explains that a cloud provider maintaining ePHI can be a business associate even if it lacks the encryption key. Confirm permitted uses and disclosures, safeguards, subcontractors, incident reporting, access, amendment support, return or destruction, training and secondary use, change notice, audit evidence, and termination. Then test tenant isolation, authentication, role access, encryption, key control, export, deletion, logging, and support access in the deployed configuration. A signed BAA cannot correct an overbroad prompt or an inaccessible deletion function.

Keep clinical and operational authority intact

The AI route may draft, extract, compare, or flag information within its approved scope. A qualified clinician retains clinical interpretation and authorship. Privacy, security, payer, coding, billing, workforce, and legal owners decide within their roles. Client consent to services does not automatically authorize every recording, vendor disclosure, model-training use, or secondary analysis. Preserve accessible communication and apply the actual representative, consent, authorization, contract, and law that governs the activity.

Test lifecycle controls

Run tests for wrong-client input, copied identifiers, prompt history, debug mode, staff export, support ticket attachment, model feedback, log search, backup recovery, vendor admin access, account closure, contract termination, and incident reconstruction. Test with each relevant role and environment. Deletion evidence should identify what was deleted, what remains, why it remains, who can access it, and when protection ends. The FTC staff article warns AI providers to honor privacy and confidentiality commitments, including statements about training and secondary use.

Work through a field-copy inventory

Keisha locks 30 fictional combinations of PHI field, system copy, and purpose. Twenty-four have an approved purpose, minimum field set, recipient, access rule, retention, vendor term, deletion path, and incident owner: 24 of 30, or 80%. Two feedback copies have no training answer, one support export lacks a deletion path, one log exposes more identifiers than needed, and two backup copies have no tested access owner. All six stay outside production approval.

Use a release checklist

  • Which exact fields enter every component and log?
  • What purpose and authority cover each copy?
  • Which vendor and subcontractor can access it?
  • Can staff, vendors, and models reuse it for feedback or training?
  • How are access, retention, export, deletion, and termination tested?
  • Which privacy, security, clinical, and incident owners can stop the route?

Trace one field through its full lifecycle

Choose a representative sensitive field and follow it from the source record into the prompt, model provider, retrieval layer, output, user interface, application log, analytics event, support ticket, feedback channel, backup, export, and deletion path. Record which system creates each copy, why it exists, who can access it, how long it remains, and which owner can verify removal. A vendor statement about prompt retention cannot answer what the practice stores in its own logs or downstream tools.

Repeat the trace for a failed request, user correction, copied output, and incident. Those paths often create additional records that the happy-path diagram omits. If the practice cannot identify a copy or its deletion authority, keep the use case restricted while privacy, security, records, and vendor owners resolve it.

Design prompts and feedback to minimize unnecessary exposure

Use structured fields, scoped retrieval, pseudonymous task identifiers, and deterministic redaction where they preserve the approved purpose. Prevent users from pasting entire records when the workflow needs only a defined excerpt. The interface should warn about the allowed data class, identify the target client and purpose, and provide an alternate route when the task requires information outside the approved template.

Treat thumbs-up, free-text corrections, screenshots, traces, and support attachments as new data flows. Decide whether they may contain PHI, whether the vendor may use them for training or quality review, who can inspect them, and how they are retained and deleted. Test that a user's correction does not silently enter an unapproved feedback dataset or a broadly accessible product log.

Close the release with accountable evidence

The final record should link the entity and vendor role analysis, permitted purpose, data map, minimum-necessary decision where applicable, agreement terms, subprocessors, regions, access controls, logging, retention, deletion, incident notice, export, testing result, and qualified approvals. List assumptions and expiration dates. Production holds when a required answer depends on a promise that has not been verified in the deployed configuration.

Begin the review with a simple field table rather than a product diagram alone. For every input and derived output, name the source, purpose, data class, destination, processor, authorized users, retention, deletion evidence, and incident owner. Include prompt templates and system-added context that users never see. This table gives privacy and security reviewers a concrete boundary and helps operators detect when a later feature quietly adds a new field or destination.

Related resources

Sources