The pilot gets scoped before compliance is in the room
Here is how it usually goes. Operations finds a process to automate, IT confirms the systems can talk to each other, and a vendor demo looks good. Then someone remembers to ask compliance. By that point the use case, the data flow, and sometimes the vendor contract are already half-decided.
That order is backwards. If security and compliance sign-off comes last, you either delay the pilot while legal reworks the data flow, or worse, you don’t delay it and find the gap after go-live. Neither is a good place to be with PHI.
DoSystems built a 10-point AI Readiness Checklist for operations and IT teams to score themselves before a pilot starts. Four of those ten points belong on the compliance lead’s desk, not operations’. This post walks through which ones, and what “ready” looks like on paper for each.
Point 5: Security & compliance is yours, full stop
This is the one point on the checklist that is a blocker on its own if it scores zero. Not “nearly ready.” Not “proceed with caution.” A zero here means the pilot doesn’t start.
Ready looks like: data classification has been done for the specific process in question, hosting and model-access rules are agreed in writing, and HIPAA or contractual limits on where data can go are documented somewhere other than someone’s memory.
The red flag version: staff are already pasting patient data into public AI tools because nobody told them not to, or nobody in security or compliance has been asked about this project at all. Both happen more often than hospitals like to admit. If your answer is “we haven’t discussed it yet,” that’s a zero, not a partly.
This point should be scored by compliance, not estimated by IT or assumed by operations. It is the one place on the checklist where a self-assessment by the wrong person creates real risk.
Points 3 and 4: co-owned with IT, but compliance signs off
Point 3 asks whether the team can pull the data a process needs within a week, without a data project first. Point 4 asks whether you know which systems the AI output has to write back to, and whether those systems expose a supported integration path.
Both of these are technically IT’s job to answer. But in a hospital, the answer to “can we access this data” and “can we write results back to the EHR” is never purely technical. It’s also a question of who is authorized to grant that access, under what data-use agreement, and whether the target system’s audit trail satisfies your compliance requirements.
Ready looks like: you know exactly where the data lives, who owns it, and it’s current enough to use for this specific process, plus the EHR, ERP, or ticketing system in question has a named integration path that compliance has reviewed for how PHI moves through it.
Red flag: the data lives across PDFs, shared inboxes, and personal spreadsheets, or the AI tool would live in a separate chat window that staff copy and paste from. That copy-paste pattern is worth stopping to think about specifically, because it’s how PHI ends up outside your compliance boundary without anyone deciding it should.
Compliance doesn’t need to run the technical assessment on points 3 and 4. But signing off on the answer before the pilot is scoped is compliance’s job, jointly with IT.
Point 6: ownership, and why compliance needs a seat here too
Point 6 asks whether there’s one accountable business owner for the pilot, plus a technical counterpart. Ready looks like a named owner with actual time set aside each week, and an executive sponsor who can remove blockers when they come up.
The red flag is familiar in most health systems: the project belongs to “IT” or “innovation,” and operations was never really involved. What’s less obvious is that compliance often isn’t involved either, until an issue surfaces. If compliance isn’t part of the ownership structure from day one, you end up as the function that says no late, instead of the function that shaped the yes early.
Being named in the ownership structure isn’t about running the pilot. It’s about having standing to ask questions before the pilot is locked, not after.
What this looks like when it’s done well
The checklist scores each of the 10 points 0, 1, or 2, for a total out of 20. Seventeen to 20 means ready to pilot. Twelve to sixteen means nearly ready. Six to eleven means prepare first. Zero to five means not yet.
But the score isn’t really the point for a compliance lead. The point is that any single zero on data access, security and compliance, or ownership is enough to stop the pilot on its own, regardless of how well operations scored everything else. A hospital can be excited about a use case, have the budget lined up, and have frontline staff ready to adopt it, and still not be ready if point 5 is a zero.
The most useful way to run this is with the operations lead and IT lead in the room together, compliance included from the start, not consulted at the end. Score honestly. A “partly” that’s really a “we’re not sure” should be scored as a zero until someone checks.
Where to start
If your hospital is being pushed toward an AI pilot and you haven’t scored these 10 points yet, that’s the first move, before anyone talks about vendors or timelines. Download the AI Readiness Checklist, work through all 10 points with your operations and IT counterparts, and score point 5 yourself before the next pilot conversation happens without you in the room.
AI Readiness Checklist (10 points)
FAQ
Which parts of the AI readiness checklist should a compliance or HIPAA lead own?
Point 5 (security & compliance) should be owned directly by compliance. Points 3 (data access) and 4 (systems & integration) should be co-owned with IT. Point 6 (ownership) needs compliance sign-off as part of the ownership structure.
What happens if a hospital scores a zero on security and compliance?
A zero on security & compliance is a blocker on its own, regardless of the total score. The checklist treats it the same way as a zero on data access or ownership: the pilot shouldn’t proceed until it’s resolved.
Should compliance be involved before or after the pilot use case is chosen?
Before. Waiting until operations and IT have already picked a process and vendor means compliance is reacting to decisions instead of shaping them, which is how PHI exposure gets discovered after a pilot is already running.
Comments are closed