A practical AI policy for ABA practice use should approve specific use cases, define which data can enter each system, assign a qualified human owner, require validation before launch and after material changes, preserve an audit trail, and set incident procedures. High-risk clinical, safety, billing, authorization, employment, and privacy decisions need stronger controls. Some uses should remain prohibited when a human cannot independently verify the input, output, and final action.

An AI vendor approval alone is too broad. The same tool might summarize a public policy safely, expose protected health information (PHI) through an unapproved account, and produce an unreliable clinical recommendation. Governance should approve a defined combination of purpose, users, data, workflow, model, human decision, and jurisdiction.

Build the AI policy for ABA practice around each use case

Start with a live use-case register. One accountable owner should be able to pause every entry. A policy committee can set standards, while the clinical, privacy, security, revenue-cycle, human-resources, and legal owners approve the parts within their competence.

Register fieldWhat to record
Use-case ID and purposeOne narrow job, the user problem, and an excluded-purpose statement
Workflow and usersWhere AI enters, who sees the output, and who makes the final decision
Data mapInput fields, PHI or other sensitive data, source systems, output destinations, retention, and deletion
TechnologyVendor, product, model, version, prompt or template version, retrieval sources, and subprocessors
Risk tierPotential clinical, safety, privacy, financial, legal, employment, access, and reputational effects
Human ownerNamed role with competence, time, source access, authority to reject, and escalation route
ValidationTest set, acceptance criteria, results, known limits, approvers, and next review date
Governing sourcesLaws, payer rules, contracts, professional standards, policies, and source-check dates
StatusProposed, testing, approved, limited release, paused, retired, or prohibited

The NIST AI Risk Management Framework is voluntary and organizes AI risk work around Govern, Map, Measure, and Manage. As of August 13, 2026, NIST says AI RMF 1.0 is being revised. A practice can use its structure without claiming that framework use proves legal compliance, clinical safety, or model accuracy.

Use four tiers to match controls to harm

Risk tiering prevents a low-stakes writing aid from receiving the same review as a treatment or billing decision. The table below is a Finni editorial framework, not a legal classification.

TierABA practice exampleMinimum direction
1. Public or internal low impactSummarize a public manual; draft an agenda using no client, employee, or confidential dataApproved tool, user training, source check, and ordinary security controls
2. Operational supportDraft scheduling options or categorize an internal task using approved, limited dataData map, vendor approval, access control, human confirmation, and sampled monitoring
3. Consequential supportDraft clinical documentation, identify authorization packet gaps, suggest a code for review, prepare a client message, or rank a workforce queueQualified human decision owner, formal validation, subgroup and edge-case tests, traceable sources, override, audit log, and scheduled reapproval
4. Prohibited or exceptionalAutonomous diagnosis, treatment change, crisis action, restrictive-procedure choice, claim or authorization submission, employment decision, or denial of service without meaningful human controlProhibit by default; any proposed exception requires executive, clinical, privacy, security, and legal review plus a documented lawful and safe basis

Other prohibited uses should include inventing session events or measurements, signing another person's record, generating false citations, placing PHI in an unapproved consumer account, concealing AI involvement from the responsible reviewer, and allowing a vendor to train on client data outside approved terms. A practice can add stricter boundaries based on its clients, contracts, states, and risk tolerance.

The current BACB Ethics Code for Behavior Analysts applies to BCBA and BCaBA certificants and applicants. It addresses truthfulness, competence, confidentiality, accurate service billing and reporting, understandable communication, assessment and intervention responsibilities, documentation, and client interests in third-party contracts. AI can assist a task while the certificant retains those duties. BACB states that it has no separate jurisdiction over organizations or corporations, so the practice must define policy duties for every workforce role.

Define meaningful human review

“Human in the loop” has little value when a rushed reviewer clicks approve without the source record, competence, or authority to reject. A meaningful reviewer can perform five actions:

  1. Confirm context. Match the client, provider, payer, service, date range, jurisdiction, and intended purpose.
  2. Inspect evidence. Open the underlying record, current rule, or clinical data instead of trusting a generated citation or explanation.
  3. Find material errors. Check omissions, unsupported additions, conflicts, bias, unsafe language, and effects on access or care.
  4. Change the outcome. Edit, reject, rerun under approved conditions, escalate, or complete the task without AI.
  5. Own the decision. Record who reviewed what, which changes were made, and why the final action was appropriate.

This five-action test is an editorial control. No cited authority creates a general human-review safe harbor, and the accountable professional retains applicable duties.

Set protected review time and monitor override behavior. A near-zero rejection rate can mean excellent performance, an easy test set, weak sampling, automation bias, or rubber-stamping. Review edits and downstream corrections alongside approval counts.

NIST's Generative AI Profile identifies risks that include confabulation, data privacy, harmful bias, human-AI configuration, information integrity, and information security. It emphasizes governance, content provenance, predeployment testing, and incident disclosure. These cross-sector suggestions need translation into each ABA workflow.

Map PHI before selecting a vendor

First determine whether the practice is a HIPAA covered entity or business associate and which data and activities fall under the HIPAA Rules. The HHS HIPAA for Professionals portal is the federal source hub. Practices outside a HIPAA role may still face state health-data, consumer-protection, contract, education, employment, and other privacy duties.

For every AI data path, record:

  • The minimum fields needed for the approved purpose
  • Whether data include PHI, personally identifiable information, employee data, payer confidential material, or licensed content
  • Where prompts, files, embeddings, logs, feedback, outputs, backups, and support tickets are stored
  • Which vendor and subprocessor can create, receive, maintain, or transmit the data
  • Whether data can train, fine-tune, evaluate, or improve any model, including through feedback features
  • Geographic processing, retention, deletion, export, legal-hold, and account-termination terms
  • Authentication, roles, encryption, monitoring, recovery, and incident responsibilities

HHS cloud-computing guidance states that a cloud service provider creating, receiving, maintaining, or transmitting ePHI on behalf of a covered entity or business associate is itself a business associate, even if it holds encrypted data without the key. The regulated customer and cloud service provider must enter a HIPAA-compliant BAA. Each regulated party must conduct the risk analysis and risk management required for its role. The practice must also document a permissible basis for the underlying use or disclosure and apply the minimum necessary standard when it applies. A BAA limits the business associate's permitted uses and disclosures. OCR does not certify a product's security, accuracy, or fitness for a use case.

Removing a name does not de-identify PHI under HIPAA. HHS recognizes two methods: a qualified expert's documented determination that identification risk is very small, or Safe Harbor removal of the specified identifiers plus the covered entity's lack of actual knowledge that the remaining information can identify the person. Properly de-identified data retains a very small, nonzero identification risk, and other laws or contracts may still restrict it.

Make vendor review evidence based

Request documents and test contract language. A security certification can inform diligence. It does not replace the practice's responsibility for its selected use and configuration or the vendor's independent duties under contract and applicable law.

Vendor questionEvidence to request
What exactly is the product and model?Architecture and data-flow description, model/version notice, intended and excluded uses
How are customer data used?Contract terms for service delivery, training, evaluation, support, feedback, and secondary use
Who else receives data?Current subprocessor list, purpose, location, change-notice process, and flow-down duties
How is access protected?Security architecture, independent assessments, access controls, encryption, logging, vulnerability and patch process
What happens during an incident?Definition, reporting clock, contacts, cooperation, evidence preservation, containment, and notification allocation that preserves each party's legal duties
Can the practice leave?Export format, deletion method and timing, backup treatment, certification, and continuity plan
Will performance or terms change?Release notes, advance notice, version pinning when available, revalidation support, and termination rights
Can the practice verify claims?Test environment, limitations, metric definitions, customer references, and rights to request assurance or audit material

FTC staff has warned AI companies to honor privacy and confidentiality commitments, including promises about using customer data for model training. Read the FTC's AI privacy and confidentiality discussion. Marketing statements belong in the diligence record, yet the signed contract and observed product behavior need to agree with them.

Validate the workflow, not a demo

Validation should reproduce the real decision path. Freeze the model, prompt, retrieval corpus, configuration, and test set long enough to interpret a result.

  1. Define the intended output and every material failure before testing.
  2. Build a representative set across payer, state, age, service, document quality, language, provider type, and edge cases relevant to the use.
  3. Keep a separate challenge set for rare, high-consequence conditions and adversarial or malformed input.
  4. Have qualified reviewers establish the reference result and adjudicate disagreements.
  5. Measure each error separately. For packet review, track missed required items, false flags, unsupported additions, source-version errors, and reviewer time.
  6. Set acceptance, limited-release, rollback, and retest criteria before seeing the final scores.
  7. Monitor live overrides, corrections, incidents, subgroup patterns, payer or law changes, drift, and user workarounds.

A single “accuracy” percentage can hide the error that matters. Report numerator, denominator, exclusions, uncertainty, and the harm attached to each failure type. Revalidate after material changes to the model, prompts, source corpus, vendor terms, input population, workflow, law, payer rule, or integration.

Preserve an audit trail without creating a second data leak

The audit record should reconstruct the decision while limiting duplicated sensitive data. Store references or controlled snapshots when a full prompt or output would spread PHI unnecessarily.

Capture the use-case ID, user, client or record reference, timestamp, tool and model version, prompt or template version, source-corpus version, input provenance, output reference, automated flags, reviewer, edits, override reason, final action, submission identifier when relevant, and later correction or incident link. Define retention, access, legal hold, and deletion with privacy and records counsel.

HHS's current Security Rule risk-analysis guidance says the analysis must encompass potential risks and vulnerabilities to the confidentiality, integrity, and availability of all electronic PHI an organization creates, receives, maintains, or transmits. NIST's Cybersecurity Framework 2.0 offers a voluntary structure for governing, identifying, protecting, detecting, responding to, and recovering from cybersecurity risk.

Route incidents through one controlled process

Treat a wrong clinical suggestion, impermissible disclosure, fabricated record, stale payer rule, biased queue, unauthorized model change, and unavailable audit log as different incident types with one coordinated intake.

  1. Protect people and active care first; use established clinical, safety, and continuity routes.
  2. Pause the affected use case and contain access without destroying evidence.
  3. Preserve versions, logs, records, vendor communications, and the known time window.
  4. Identify affected clients, records, claims, authorizations, employees, payers, and downstream systems.
  5. Correct clinical, billing, payer, or employment records through their governed amendment process.
  6. Have privacy and counsel determine which breach, contract, regulator, payer, client, or workforce notices apply.
  7. Find root causes across model, data, workflow, human review, access, training, and vendor controls.
  8. Revalidate controls and obtain the original approval roles before restart.

The HIPAA Breach Notification Rule applies to breaches of unsecured PHI. Classify security incidents, wrong outputs, and impermissible uses or disclosures before treating them as reportable breaches. A covered entity or business associate applies the rule's definition and three exceptions. Unless it elects to notify, it documents whether there is a low probability that PHI was compromised using at least the four required factors.

The FTC Health Breach Notification Rule separately covers qualifying vendors of personal health records, PHR-related entities, and their third-party service providers. Under the FTC's compliance guidance, a qualifying PHR is an electronic record of identifiable health information with the technical capacity to draw from multiple sources and managed, shared, or controlled by or primarily for the individual. HIPAA covered entities and entities acting solely as HIPAA business associates are excluded. An entity with separate business-associate and direct-to-consumer PHR activities may have duties under both federal rules. Operations should escalate the facts promptly for qualified review.

Synthetic example: governing prior-authorization packet review

This fictional example tests a workflow and makes no Finni product claim. An ABA practice proposes AI that compares an authorization packet with a payer-requirements library and highlights possible gaps. The approved purpose excludes medical-necessity decisions, treatment recommendations, final narratives, submission, and payer communication.

The clinical director owns clinical content. The authorization lead owns payer-rule verification. Privacy and security approve the data path and vendor terms. Testing uses purpose-built fictional cases that contain no real client information and cases de-identified through the practice's documented HIPAA method. The data owner records provenance, de-identification authority, residual reidentification risk, and restrictions under other laws or contracts. The team tests five payer-rule patterns and records missed requirements, false flags, stale sources, unsupported text, reviewer edits, and time. A limited release begins only after predefined criteria are met.

Two weeks later, a payer revises a form. The monitoring log shows more reviewer overrides for that payer. Operations pauses the affected rule set, preserves cases and versions, updates the dated source, tests the change against old and new cases, and obtains authorization-lead approval before restart. The audit trail shows which packets were reviewed under each source version, allowing targeted rechecks.

A one-page policy skeleton

Every approved AI policy should name:

  • Purpose, scope, definitions, and excluded uses
  • Governance committee, accountable owners, approval authority, and pause authority
  • Use-case register and risk-tier method
  • Data classification, allowed systems, PHI rules, retention, and vendor requirements
  • Human-review duties, competence, workload, source access, and override rights
  • Validation, monitoring, change control, review cadence, and retirement rules
  • Audit fields, records ownership, access, and correction procedures
  • Incident reporting, containment, investigation, notification review, remediation, and restart
  • Workforce training, reporting without retaliation, sanctions, and policy exceptions
  • Jurisdiction, payer, contract, professional-standard, and source-update register

The SBA Business Guide is a general small-business resource, not health-care AI guidance. Practice-specific policy still needs qualified clinical, privacy, security, employment, and legal review in every operating state.

Related resources

Sources