To build an ABA AI use case inventory and risk tiering system, identify every approved, proposed, experimental, embedded, and retired use of AI. Assign a practice-defined tier from the real workflow and possible consequences. Record purpose, people, data, model, vendor, outputs, actions, human authority, validation, monitoring, incidents, and stop conditions. Review the use case whenever those elements change.
Inventory every use of each product
Amara begins with the decision or action the system affects. One vendor may power drafting, search, scheduling, call summaries, claim review, and chat, and each use can carry a different risk. She creates a separate record for every workflow, including AI embedded in an existing product or enabled through a vendor update. The inventory includes experiments and prohibited uses so unapproved activity stays visible.
Record enough detail to reproduce the workflow
For each use case, record owner, purpose, users, affected people, input and output, data class, source of truth, model and version, prompt or configuration, retrieval sources, vendor and subprocessors, tools or downstream actions, human reviewer, decision authority, validation cohort, thresholds, accessibility, appeal or correction route, monitoring, incident link, stop condition, retention, and retirement evidence. A product name or "AI enabled" flag cannot support a risk decision.
Use a practice-defined risk tier
Amara uses four internal tiers. Tier 1 covers reversible assistance with no sensitive data and no external action. Tier 2 covers sensitive internal work or outputs that require review. Tier 3 covers clinical, safety, privacy, payer, employment, financial, or client-facing influence. Tier 4 covers autonomous, irreversible, high-impact, or currently prohibited action. These tiers are an editorial control, not a NIST or legal classification. The practice documents why the chosen tier fits the actual use.
Make consequences drive the tier
Consider who could be affected, what the output can change, whether protected or confidential data is used, how quickly an error spreads, whether a person can detect and correct it, and whether the action is reversible. Include foreseeable misuse, prompt injection, source failure, biased performance, inaccessible interaction, automation bias, vendor change, and loss of audit evidence. A low-cost tool can still be high risk when it influences care or exposes records.
Assign gates by tier
Every tier requires an owner, purpose, allowed users, data boundary, basic testing, and retirement route. Higher tiers add qualified domain review, representative evaluation, privacy and security approval, human authorization before consequential action, production monitoring, incident response, change control, independent acceptance, and narrower stop thresholds. A gate remains open until evidence is complete. A waiver identifies the accountable authority, duration, compensating control, and prohibited uses.
Discover uses through several evidence routes
Use procurement and expense records, single sign-on and application inventories, browser-extension reviews, vendor feature notices, integration and API logs, security findings, help-desk tickets, and a protected workforce disclosure route. Compare discoveries across routes and record the search period. Staff should be able to report an experiment or embedded feature without fear of punishment. The purpose is to bring unknown use into governance quickly. A survey alone can miss quiet vendor changes, shared accounts, personal subscriptions, and AI added inside a familiar product.
Keep legal and framework scope precise
NIST AI RMF 1.0 is voluntary and NIST says it is being revised. The AI RMF Core includes inventorying AI systems according to organizational risk priorities. The Playbook offers voluntary suggestions and is not a checklist. HHS now lists a third-party AI chatbot handling patient-portal PHI as a business-associate example, while actual HIPAA status still depends on entity and function. The inventory supports analysis; it does not decide legal status.
Work through a locked example
Amara locks 24 fictional AI use cases across intake, scheduling, documentation, authorization, billing, workforce, and client communication. Seventeen have complete purpose, data, authority, validation, monitoring, change, and retirement records: 17 of 24, or 70.8%. Three embedded features were absent from the original inventory, two lack a human approval boundary, one has no vendor data-use answer, and one has no stop owner. All seven remain visible and unavailable for routine release.
Measure inventory quality
Report inventoried uses divided by uses discovered through the defined discovery process; tiered uses divided by inventoried uses due for classification; release-ready uses divided by uses reviewed; and overdue reviews divided by uses due. Preserve counts by tier and unresolved reason. A 100% inventory score describes the discovery method and cutoff, not proof that shadow AI no longer exists or that every recorded use is safe.
Ask these approval questions
- What exact work changes because AI is present?
- Which people and records can be affected?
- Who owns the source facts and final decision?
- What errors, attacks, access barriers, or downstream actions matter?
- Which evidence must exist before release?
- What event pauses, revalidates, or retires the use?
Run the inventory as an operating cycle
An inventory becomes stale when it is treated as a one-time spreadsheet. Amara assigns an intake route for proposed tools, an owner attestation for existing uses, and a recurring reconciliation against procurement, single sign-on, integrations, browser extensions, expense records, and vendor release notices. Each review ends with a dated state such as proposed, testing, conditionally approved, approved, held, prohibited, retiring, or retired. The state links to the evidence that supports it and to any open condition with an owner and due date.
New capabilities receive their own review even when the vendor and contract are already approved. If a scheduling product adds a call-summary model, for example, the practice records the new inputs, affected people, retention, reviewer, possible actions, and failure consequences before enabling it. A previous security review cannot answer whether the new feature has an appropriate clinical, privacy, accessibility, or operational role.
Resolve ambiguous and incomplete uses
Some entries will resist a neat tier. A pilot may use fictional data today but be designed for PHI tomorrow. A drafting assistant may become consequential because staff routinely copy its output without opening the source record. An embedded classifier may influence queue priority even though it never displays a recommendation. Amara records the highest credible consequence, the uncertainty, and the evidence needed to narrow the tier. Missing information produces a hold or a restricted test state rather than a favorable assumption.
Before closing an entry, verify the named business owner, technical owner, qualified decision owner, data route, approved population, review method, monitoring signal, incident route, and exit procedure. Ask an affected user whether the description matches the workflow they actually perform. That final check often reveals shadow steps, manual workarounds, or downstream actions that the product diagram omitted.
Close each review with a usable decision record
The record should let a leader understand what may happen next without reopening every attachment. State the approved purpose and population, risk tier, allowed data, permitted users, prohibited actions, required reviewer, open conditions, monitoring cadence, stop triggers, revalidation events, and expiry. Link the vendor, security, privacy, clinical, accessibility, and operational evidence rather than collapsing their distinct conclusions into one approval flag.
Amara also records who was consulted and which concern remains unresolved. If a client-facing feature was evaluated without an affected-person or accessibility perspective, the missing review stays visible. Quarterly leadership review can then focus on high-tier uses, overdue evidence, exceptions, incidents, approaching expirations, and tools that no longer have an active owner. The inventory becomes a decision system instead of a passive catalog.
Related resources
- Validate an AI Model or Vendor Before ABA Production Use
- Respond to AI Errors, Data Exposure, and Unsafe Actions in ABA Practices
- Defend ABA AI Workflows Against Prompt Injection and Unsafe Tool Use
- Secure AI Agents and Autonomous Actions in ABA Operations
Sources
- Council of Autism Service Providers, Organizational Guidelines public overview
- National Institute of Standards and Technology, AI Risk Management Framework
- National Institute of Standards and Technology, AI RMF Core
- National Institute of Standards and Technology, AI RMF Playbook
- National Institute of Standards and Technology, Generative AI Profile
- U.S. Department of Health and Human Services, Business Associates
- U.S. Department of Health and Human Services, Guidance on Risk Analysis