AI Governance and Compliance

Three problems, and most organisations have all three at once.

AI is already in use and nobody has counted it. Clinicians paste notes into general purpose chatbots, a department has trialled a scribe on a departmental card, a billing team uses a coding assistant that arrived inside a product you already own. None of that is in a register, some of it touches protected health information, and the first time anyone finds out is during an incident.

Approval has no framework. When a deployment reaches compliance, there is often nothing to approve it against, so the answer is either a blanket no or an uneasy yes. Both are bad. A written risk tiering and a standing assessment process turn that into a decision that takes days rather than quarters.

The rules are multiplying and they are not the same everywhere. Federal privacy and security obligations are the floor. On top of them sit device rules where a product makes a clinical claim, and a growing set of state statutes covering disclosure, utilization review and automated decision making. A multi state organisation now needs a framework that can express different obligations in different places without maintaining separate policies.

It is for organisations that are running AI, or are about to, and need the compliance side to keep pace. That includes health systems with formal committee structures and mid sized practices with one compliance officer who already has a full workload. The framework scales down without becoming a template.

It is particularly useful before something forces the issue: an audit, a payer or partner assessment, an accreditation cycle, or a board that has started asking who is responsible for this. Building the framework under that pressure is possible but expensive and it shows.

It is not for organisations that want a policy document to file. We will write the policy, but the value is in the inventory, the risk process and the oversight standard, and a client who wants only the document is buying the least useful part. It is also not a substitute for legal advice: we are not lawyers, and your counsel should review anything with contractual or statutory consequences. If AI is not yet in use anywhere and the real question is whether to start, the AI readiness audit is the earlier engagement.

Weeks one and two, discovery and inventory. We find what is running. That means system and procurement records, interviews with department leads, a look at what has been bought on expense claims, and a review of AI features inside products you already license, which is where most unregistered AI turns out to be. Each entry gets an owner, a data flow and a first pass risk tier.

Week three, gap analysis. The current position is mapped against the HIPAA Security Rule, the NIST AI Risk Management Framework and the state rules that apply where you operate. The output is a gap list ordered by exposure rather than by ease, with the quick wins marked separately so they can start immediately.

Week four, policy and controls. We draft the AI use policy, the risk tiering, the human oversight standard and the vendor due diligence checklist. Drafting happens with your compliance owner rather than for them, because a policy handed over finished is a policy nobody defends in a meeting.

Week five, process and incident. The risk assessment process, the monitoring plan and the incident procedure, each tested against a real case from your inventory. An incident procedure that has never been walked through is a document, not a procedure.

Week six, handover and committee. Charter, meeting pack template, training for whoever will run it, and a presentation to the board or committee that has to adopt it. The framework is yours, in editable form, with no dependency on us to maintain it.

The full list is above. Four components carry most of the weight.

The inventory. Every AI system in use, its owner, what data it touches, whether a business associate agreement is in place, its risk tier and its review date. This is the single most useful artefact of the engagement, and it is the one most organisations do not have.

The risk tiering. A short rule set that sorts a use case into a tier and attaches the approval path and the oversight requirement to the tier rather than to the individual case. This is what stops every deployment becoming a bespoke negotiation.

The human oversight standard. What a person must review, in which workflow, and what evidence that review leaves behind. Oversight that leaves no trace cannot be audited, and oversight that requires reviewing everything decays within weeks of go live. Both failure modes are common and both are designed out here.

The incident procedure. What counts as an AI incident, who is notified, how it is contained and documented, and how it connects to your existing breach notification obligations. AI incidents are frequently not privacy breaches, and a procedure that only knows how to handle breaches will mishandle them.

CARE is our four step method: Chart, Architect, Run, Evaluate. Governance is the only one of our services that runs across all four, which is deliberate: governance bolted on at the end is the most expensive kind.

Chart surfaces the inventory and the current compliance gaps, which is where this engagement starts. In many organisations the inventory alone changes what the first project should be.

Architect is where controls are designed into the deployment rather than around it. Access scope, audit logging detail and oversight points are integration decisions, so they belong beside the deployment roadmap and the vendor evaluation, not after them.

Run is where the oversight standard meets a busy clinic. This is the step where governance most often fails in practice, and the mitigation is training rather than policy, which is why role based training is usually scheduled alongside go live.

Evaluate is the monitoring plan and the review cycle: named metrics, named owners, fixed dates, and a documented decision each time. That is what turns governance from an annual document into a live process.

You can write this yourself, and a short policy your staff have read beats a long one they have not. Nine sections cover the ground.

1. Scope. Which systems count as AI for the purposes of this policy, stated broadly enough to catch AI features inside products you already own.
2. Permitted and prohibited uses. Be specific. Naming general purpose consumer chatbots and stating plainly that no patient information goes into them prevents more incidents than any other sentence in the document.
3. Risk tiering and approval. The tiers, what lands in each, and who approves each tier. Keep the low tier path short enough that people use it.
4. Human oversight. What must be reviewed, by whom, and what record the review leaves.
5. Data handling. What may be sent to which systems, retention, de-identification standards, and the rule on training on your data.
6. Vendor requirements. Business associate agreement, subprocessor disclosure, audit logging, notification timelines, and exit terms.
7. Disclosure to patients. When patients are told AI was involved and in what words. Several states now legislate this directly, so this section has to be checked against the places you operate.
8. Incidents. Definition, reporting route, containment and documentation.
9. Review. Who owns the policy, how often it is reviewed, and what triggers an off cycle review.

A workable risk tiering looks like this. Adjust the thresholds, keep the shape.

The prohibited row is not rhetorical. Software that makes a diagnostic or treatment claim can fall within FDA device regulation, and running it without clearance is a different category of problem from a governance gap.

Almost every organisation we work with underestimates this, usually by a factor of several. Six places to look, in the order that finds the most.

Inside software you already own. EHR modules, patient communication platforms, transcription services, coding tools and payer portals have all acquired AI features by upgrade rather than by purchase. Nobody made a decision, so nothing was registered. Start with your top twenty vendors and ask each one directly, in writing, what AI functionality is enabled in your instance and what data it processes.

Expense claims and departmental cards. Search the last twelve months for the obvious subscription names. Small recurring charges are where clinician led trials live.

Network and identity logs. Where your security team can see it, outbound traffic and single sign on records will show consumer AI services in use, and the volume is usually the surprise.

Ask, without consequences attached. An amnesty framed as we need to know what is helping you works far better than an audit. People conceal tools they find useful when disclosure sounds like an accusation, and a concealed tool is the one that causes the incident.

Your own website and patient channels. Chat widgets, scheduling assistants and intake forms frequently include vendor AI, and these are patient facing, which raises the tier immediately. The patient intake and phone agent pages set out what those systems typically touch.

Research and quality improvement. Projects run under a research or improvement banner often use AI tooling outside normal procurement, and they usually touch data.

Record each finding with an owner, a data flow and a tier, then work the high tier entries first. An inventory nobody maintains is a snapshot, so attach it to an existing process, usually procurement and the annual security risk analysis, rather than creating a new one that will lapse.

A fixed fee stated in a written proposal before the work starts, scaled to the size and complexity of the organisation rather than billed hourly. A single site practice and a multi state system need very different amounts of work. The strategy call that produces the proposal is free.

We take no vendor commissions, and your framework is not built around anyone's product. That matters more here than anywhere else in our work, because governance tooling is a category with an obvious conflict of interest, and a framework designed by someone who also sells the platform to run it is not independent.

After handover the framework is yours and your compliance function owns it. Some clients take an annual review, which is a short engagement to check the framework against the year's regulatory movement and against what actually happened in the inventory. Many do not need one. If the immediate next step is getting a specific deployment live under the new framework, that is the deployment roadmap, and if the binding constraint is that staff do not yet know what the oversight standard requires of them, it is staff training. To see where your gaps sit before commissioning anything, the readiness assessment scores governance as one of its four categories and costs nothing.