AI governance

Govern use cases instead of product labels

One product can support several uses with different risks. Summarizing a public policy, drafting a family message, predicting missed visits, and proposing clinical content each need a separate record. Name the users, affected people, data, output, decision, consequences, and prohibited uses.

The CASP AI practice-parameters page describes ABA-sector guidance covering organizational oversight, selection, deployment, change management, monitoring, and auditing. It does not establish legal authority or validate a particular tool.

Give every decision an owner

An owner or governing body can approve resources and risk tolerance. Qualified clinicians retain clinical judgment. Privacy, security, legal, payer, workforce, and operations leaders decide within their domains. Software may draft, sort, or flag within its approved role; it cannot acquire a credential or assume accountability.

Record who may approve a use, change its scope, pause it, investigate an incident, and return it to service. Provide a route for clients, families, and workers to question an output or report harm.

Keep a build-ready AI register

For each use case, record:

• purpose, owner, vendor, model or service version, and effective dates
• input sources, data classifications, permitted uses, retention, and deletion
• intended users, affected groups, workflow placement, and human approval point
• validation cohort, measures, limitations, thresholds, and known failure modes
• access, logging, security, vendor, incident, continuity, and exit controls
• monitoring schedule, change triggers, stop conditions, and open issues

NIST AI RMF 1.0 organizes voluntary risk management around Govern, Map, Measure, and Manage. Its outcomes provide a useful structure, while applicable legal and professional requirements still control.

Validate the deployed workflow

Vendor benchmarks rarely match an ABA practice’s users, data, settings, and consequences. Test the actual workflow with authorized data and predeclared acceptance criteria. Measure clinically or operationally important errors, subgroup performance where appropriate, reviewer agreement, abstentions, overrides, latency, and failed integrations.

Human review needs five actions: access the source evidence, recognize AI-originated content, change or reject the output, understand the decision criteria, and retain the final author’s identity. A nominal approval button supplies little protection when the reviewer lacks time or evidence.

A fictional governance gate

Maya’s practice reviews 15 proposed AI uses. Twelve have complete purpose, data, authority, validation, human-review, and incident records: 12 of 15, or 80%. Three remain open with owners and due dates.

Of the 12 completed reviews, nine meet their release criteria: 9 of 12, or 75%. Original-queue release yield is 9 of 15, or 60%. The three incomplete and three held uses remain visible. These measures show governance progress, not safety or benefit.

Privacy and security follow the data

If a cloud vendor creates, receives, maintains, or transmits ePHI for a HIPAA covered entity or business associate, HHS cloud guidance explains that business-associate status can apply even when the vendor lacks the decryption key. A contract, BAA, or encryption feature covers only part of the analysis.

Map prompts, retrieved documents, outputs, logs, feedback, model training, support access, subprocessors, and deletion. Test whether product settings and vendor terms match the approved use.

Generative AI adds distinct risks

The NIST Generative AI Profile identifies risks that can be novel or intensified in generative systems and proposes actions across the lifecycle. In practice, owners should plan for fabricated content, sensitive-data leakage, harmful bias, automation overreliance, changing models, unclear provenance, and misleadingly fluent output.

Monitor production evidence and reassess after model, prompt, data, vendor, workflow, law, or population changes. A stop rule should trigger a safe manual path. Retirement includes access removal, data disposition, open-case handling, record preservation, vendor obligations, and communication to affected users.

Use a release gate for every pilot

Before a pilot starts, confirm the approved purpose, test-data authority, users, vendor terms, security configuration, reviewer qualifications, success measures, and stop condition. Give the test a fixed start, end, version, and owner. Keep pilot output away from live care, claims, employment, or family communication unless that real-world use has its own approval and safeguards.

Release requires evidence that the workflow met its declared criteria and that unresolved risks fall within the practice’s approved tolerance. Record limitations in language users can apply. Train them on permitted uses, source checking, escalation, incident reporting, and the manual alternative.

After launch, review a due cohort rather than a convenient sample. Useful measures include use cases reviewed by date divided by reviews due, monitored outputs divided by outputs due for sampling, and incidents closed by target divided by incidents due. Pair counts with severity, affected people, corrective action, and feedback. Governance activity alone cannot establish a beneficial or safe outcome.