Technology, AI and the Future of ABA should be evaluated through the clinical and operational decision a tool affects. A safe deployment names the purpose, users, data, source material, human approval boundary, validation cohort, access controls, audit evidence, monitoring, incident route, and stop condition. Software can organize information and surface inconsistencies. Qualified professionals retain clinical judgment, and the practice remains responsible for privacy, accuracy, access, client rights, and the deployed workflow.

Start with a bounded use case

Define the exact input, output, user, decision, and prohibited use. “Use AI for documentation” is too broad. “Flag missing dates and internal contradictions in a draft authorization packet before a qualified clinician and payer-operations reviewer approve it” gives the team something testable.

Classify the consequence of error. A scheduling suggestion, client safety alert, clinical recommendation, privacy classification, claim field, and staff evaluation carry different risks. Increase evidence, human review, access restriction, and monitoring as harm becomes more serious.

The NIST AI Risk Management Framework is voluntary guidance organized around Govern, Map, Measure, and Manage. The NIST Generative AI Profile is a companion resource for generative-AI risks. Neither document certifies a healthcare product or creates a general safe harbor.

Keep clinical and administrative authority separate

Software may extract, compare, summarize, draft, prioritize, or flag. It should not silently decide whether a goal, dosage, diagnosis, risk control, treatment procedure, or clinical rationale changes. Route those questions to the appropriately qualified clinician.

Administrative staff and software can verify required fields and source consistency. Privacy staff decide approved data routes. Coding and payer experts review claim and authorization representations. Each approval should identify the person, role, time, source version, and final artifact.

The current BACB Ethics Code addresses competence, confidentiality, records, assessment, intervention, risk, data, billing, and delegation for covered behavior analysts. Technology use stays within those duties and applicable law. BACB has no separate jurisdiction over organizations or corporations.

Map every data path before testing

Create a data-flow record for collection, upload, transmission, storage, retrieval, model processing, human review, export, logs, support access, backup, retention, deletion, and incident response. Record the entity, system, region, data classes, purpose, legal or contractual route, access roles, and downstream vendor.

HHS cloud-computing guidance states that a cloud provider creating, receiving, maintaining, or transmitting ePHI on behalf of a HIPAA covered entity or business associate is a business associate even if it holds encrypted data without the key. The regulated parties need a compliant BAA and must perform their own role-specific risk analysis and management. A BAA does not certify product accuracy, security, or fitness.

Classify HIPAA status by entity and activity. For work outside covered-entity or business-associate scope, assess other privacy and consumer-health laws. The FTC Health Breach Notification Rule guidance covers qualifying vendors of personal health records, PHR-related entities, and third-party service providers within its definitions. Mixed-role organizations may face different regimes for different activities.

Use safe test data and record provenance

Prefer purpose-built fictional cases that contain no real client information. When real data is needed for a justified test, verify authority, minimize fields, restrict access, and use the approved environment.

Removing a name does not establish HIPAA de-identification. HHS de-identification guidance describes Expert Determination and Safe Harbor methods and explains that properly de-identified data retains a very small residual identification risk. Record provenance, method, authority, residual risk, and restrictions under other laws or contracts.

Synthetic data derived from real records can retain sensitive information. Keep the generation method, source status, review, and reuse terms. Never paste protected information into an unapproved public tool for convenience.

Design the human approval boundary

The AI pre-submission review guide treats output as decision support. A useful review flow shows the flagged field, source, rule version, evidence, uncertainty, and suggested next step. The reviewer can accept, edit, reject, or escalate.

Define which outputs require clinical, payer, privacy, coding, security, or legal approval. Prevent automatic submission or record overwrite when a qualified decision is required. Preserve the original input, tool version, retrieved sources, draft output, reviewer changes, approval, and final artifact.

Never auto-rewrite clinical content to satisfy a payer rule. If a requirement conflicts with the record, surface the inconsistency and route it to the clinical author and payer owner.

Validate performance against the real workflow

Build a locked test set that represents relevant payers, document types, communication methods, client ages, settings, providers, edge cases, and known errors. Separate development, validation, and monitoring samples. Protect sensitive cases and maintain approved access.

Measure by decision unit: required fields correctly surfaced, false alerts, missed high-risk gaps, source citation accuracy, reviewer agreement, correction time, and downstream outcomes. A broad accuracy score can hide poor performance on rare safety or privacy conditions.

Compare the tool with the current human workflow and state limitations. Test whether users over-rely on confident language, miss absent evidence, or accept stale sources. Validation should include realistic time pressure and unavailable leaders.

Use AI documentation with attributable review

The safe AI clinical documentation guide requires an approved data route, defined purpose, source evidence, qualified review, and audit trail. The final author verifies identity, dates, time, participants, observations, procedures, client response, decisions, and follow-up.

A draft should distinguish recorded fact, client or caregiver report, retrieved policy, and generated suggestion. Prevent fabricated observations, inferred assent, invented quotations, copied diagnosis, unsupported code, and false representation of contemporaneous authorship.

Keep correction history. The author should be able to see what the tool proposed and what changed before signing. A signature does not cure missing source evidence.

Monitor, pause, and respond to incidents

Define thresholds for stale sources, rising false negatives, access errors, hallucinated content, workflow bypass, reviewer disagreement, privacy events, and harmful downstream outcomes. Assign an owner and automatic pause condition for each serious risk.

An alert is a signal. Triage suspected, confirmed, and false-positive states. Preserve evidence while addressing urgent safety and containment. Route security incidents, privacy incidents, clinical events, billing errors, and client complaints through their applicable processes because one event can trigger several.

Review vendor changes, model versions, prompts, integrations, user roles, and data flows before release. Revalidate material changes. Track unresolved monitoring findings with age, interim control, and stop authority.

Include clients and staff in governance

Explain technology use in accessible language when it affects care, communication, recording, or decisions. Provide a way to ask questions, correct information, decline optional uses, report harm, and request an alternative where applicable. Preserve AAC and other access needs.

Involve clinicians, frontline staff, privacy and security owners, payer experts, clients, and caregivers in use-case review. Monitor whether the tool shifts hidden work onto families or staff, narrows choice, or amplifies bias.

Maintain a public-facing plain-language description for material uses and an internal register with the owner, approved purpose, systems, data classes, vendors, model version, validation date, reviewers, incidents, open limitations, and next review. Retire access and integrations when a use ends.

Explore clinical roles or Finni AI Prior Auths. Confirm current product features, supported workflows, source coverage, validation, privacy and security terms, audit fields, and human-review controls during diligence.

Related resources

Sources