# HIPAA AI audit readiness scorecard | RankShieldMD > Rate your clinical-AI HIPAA audit readiness in 7 questions. Map gaps to audit controls (164.312(b)) and accounting of disclosures (164.528). Free, PHI-free. > > Source: https://rankshieldmd.com/tools/hipaa-ai-audit-readiness/ · RankShieldMD (verifiable AI & post-quantum security for healthcare) Interactive tool · HIPAA AI audit readiness # How audit-ready is your clinical AI under HIPAA? **HIPAA AI audit readiness is how well a practice can prove, after the fact, what its clinical-AI systems did with protected health information.** It maps to two HIPAA requirements: audit controls at 164.312(b) and accounting of disclosures at 164.528. This scorecard rates your posture in seven questions and shows exactly which control each gap touches. It is guidance, not legal, clinical, or FDA advice. Start the scorecard → What it measures 7 questions 164.312(b) · 164.528 PHI-free Non-device The scorecard ## Rate your clinical-AI audit posture. Answer honestly for the environment as it runs today, not as you hope it runs. Your grade and the specific gaps update as you go. Nothing you select leaves your browser, and no protected health information is requested or stored. HIPAA AI audit-readiness scorecard 0 of 7 answered 01 When a clinical-AI system reads or writes ePHI, is a tamper-evident audit record created every time? Yes, every AI access is logged to a tamper-evident record Some AI access is logged, but coverage is partial No, or we are not sure AI access is captured at all Supports: 164.312(b) audit controls 02 After the fact, can you identify which specific model and version produced a given AI output? Yes, model and version are recorded for each decision Partly, we know the vendor but not the exact version or state No, we cannot reconstruct which model ran Supports: 164.312(b) audit controls 03 When an AI system discloses PHI outside your organization, is that disclosure captured in your accounting of disclosures? Yes, AI-driven disclosures are tracked with purpose and recipient We track human disclosures, but AI-driven ones are unclear No, AI disclosures are not in our accounting process Supports: 164.528 accounting of disclosures 04 Are your audit records protected against silent edit or deletion, for example append-only or integrity-sealed? Yes, records are append-only or cryptographically sealed Logs exist but an administrator could alter them No, we rely on editable application logs Supports: 164.312(b) audit controls 05 Is each AI access bound to a verified actor identity rather than a shared service account? Yes, every access carries a verified, attributable identity Mostly, but some AI runs under shared or service accounts No, AI access is not individually attributable Supports: 164.312(a) access control and 164.312(b) 06 Do you review AI and record-access logs on a regular, documented cadence? Yes, we review on a defined schedule and document it We review only when something is questioned No regular review of AI access takes place Supports: 164.312(b) audit controls 07 Could an external auditor verify your audit records independently, without trusting your dashboard? Yes, records can be independently recomputed and checked An auditor would have to take our system output on trust No, we could not produce independently verifiable records Supports: 164.312(b) audit controls · Answer all seven questions to see your readiness grade and where each gap maps. This scorecard is guidance, not legal, clinical, or FDA advice, and not a HIPAA compliance determination. RankShieldMD produces evidence that supports HIPAA obligations; it is PHI-free, non-device, and does not by itself make an organization compliant. What it measures ## What does HIPAA audit readiness mean when clinical AI is involved? **It means being able to prove, not just assert, what your clinical-AI systems did with ePHI: which model ran, who accessed a record, and whether any AI-driven disclosure was accounted for.** The HIPAA Security Rule has always required audit controls, the hardware, software, and procedural mechanisms that record and examine activity in systems that contain or use electronic protected health information, at 45 CFR 164.312(b). For years that meant human access to charts. Clinical AI changes the surface: a model now reads records, drafts notes, flags images, and in some workflows routes or shares data. Each of those is activity in a system that uses ePHI, so each falls inside the audit-controls standard. Readiness is the degree to which you can reconstruct that activity credibly, with attribution to a verified identity and integrity you can defend, rather than a log an administrator could quietly change. The second requirement this tool weighs is the accounting of disclosures right at 164.528, which lets a patient ask for an accounting of certain disclosures of their PHI. When an AI system moves data outside your organization, that can be a disclosure that must be captured. If your accounting process only sees human actions, AI-driven disclosures become a blind spot. A ready practice closes that gap so the accounting is complete. ## How do the scorecard questions map to 164.312(b) and 164.528? Each question corresponds to a concrete capability an auditor or a patient request would test. The table below shows the mapping so you can see why a gap matters, not just that it exists. | Readiness question | HIPAA control it supports | | --- | --- | | Tamper-evident record of every AI access to ePHI | 164.312(b) audit controls | | Which model and version produced each output | 164.312(b) audit controls | | AI-driven disclosures captured in the accounting | 164.528 accounting of disclosures | | Records protected against silent edit or deletion | 164.312(b) audit controls | | Each access bound to a verified actor identity | 164.312(a) access control and 164.312(b) | | Regular, documented review of AI access logs | 164.312(b) audit controls | | Records an external auditor can verify independently | 164.312(b) audit controls | Control citations are to the HIPAA Security Rule at 45 CFR Part 164. Mapping is for readiness guidance and does not constitute a legal opinion. ## Why is an independently verifiable record the hardest gap to close? Most practices can produce some kind of log. The gap that separates a good grade from a weak one is whether that log can be trusted by someone who does not trust you. Ordinary application logs are editable, frequently by the same administrators whose activity they record, and they usually live beside the data they are meant to protect. When an AI output is questioned months later, an editable log lets you say what happened; it does not let an auditor confirm it. Records that are append-only or cryptographically sealed, and that an outside party can recompute, convert an assertion into a checkable fact. This is the layer RankShieldMD occupies: it seals PHI-free digests of the model, inputs, and output, binds each access to a verified identity, and anchors the record so it can be verified without exposing patient data and without trusting the vendor. It attests the decision; it never renders it, and it is not a medical device. Honest by design ## What this tool is careful never to claim. ### Guidance, not a compliance verdict This scorecard is a self-assessment aid. It is not legal, clinical, or FDA advice, and it is not a HIPAA compliance determination. Your program, risk analysis, and qualified counsel decide compliance. ### It never sees PHI RankShieldMD is PHI-free by construction. It seals digests and verified identities, never names or medical record numbers. Adopting it shrinks your PHI footprint rather than growing it. ### Attests, does not decide RankShieldMD proves that an AI decision or access was genuine and un-tampered. It does not render clinical judgments and it is not a medical device. Answer engine ## HIPAA AI audit readiness: questions, answered. Straight answers about verifiable healthcare AI. Tap a question, or type your own. Jamie Kloncz, founder verified human ✓ Ask me anything about proving your clinical AI. I built RankShieldMD so a small practice can prove its AI, not just be asked to trust it. What is HIPAA AI audit readiness? HIPAA AI audit readiness is how prepared a practice is to prove, after the fact, what its clinical-AI systems did with protected health information: which model ran, who accessed a record, and whether an AI-driven disclosure was accounted for. It maps to two HIPAA requirements in particular, the audit controls standard at 164.312(b) and the accounting of disclosures right at 164.528. A ready practice can produce a tamper-evident, attributable, independently checkable record of every AI touch on ePHI, rather than asking an auditor to trust a dashboard. Which HIPAA rules does clinical AI most directly implicate? Two stand out. The audit controls standard, 164.312(b), requires mechanisms that record and examine activity in systems that contain or use ePHI, which now includes AI reads and writes. The accounting of disclosures provision, 164.528, gives patients the right to an accounting of certain disclosures of their PHI, and AI systems that route or share data can create disclosures that must be captured. Access control at 164.312(a) also matters, because audit evidence is only useful when each access is attributable to a verified identity. Is this scorecard a HIPAA compliance determination? No. It is a self-assessment aid that helps you see where your clinical-AI audit posture is strong and where gaps map to 164.312(b) and 164.528. It is not legal advice, not a clinical judgment, and not a compliance certification. HIPAA compliance depends on your full program, your risk analysis, and, where required, review by qualified counsel or a compliance officer. RankShieldMD produces evidence that supports these obligations; it does not by itself make an organization compliant. Does RankShieldMD see protected health information to do this? No. RankShieldMD is PHI-free by construction. It seals digests of the model, the inputs, and the output, and binds each access to a verified identity, without ingesting names, medical record numbers, or other identifiers, which are rejected at the guard. It attests that an AI decision or access was genuine and un-tampered; it does not render the clinical decision and it is not a medical device. Adopting it shrinks your PHI footprint rather than adding another store of protected data to defend. Why do editable logs fall short for AI audit controls? The audit controls standard is about being able to record and examine activity credibly. Ordinary application logs can be edited or deleted, often by the same administrators whose actions they record, and they usually sit beside the data they are meant to protect. When an AI output is questioned months later, an editable log lets you assert what happened but not prove it. Append-only, integrity-sealed records that an outside party can recompute turn that assertion into something checkable, which is what an audit or an accounting of disclosures ultimately needs. How can a small practice improve its score quickly? Start with attribution and integrity. Make sure every clinical-AI access is bound to a verified identity rather than a shared service account, and move AI access records into an append-only or integrity-sealed store so they cannot be silently changed. Then extend your accounting of disclosures process to cover AI-driven disclosures, and put AI logs on the same regular review cadence you use for human access. Those steps map directly to 164.312(b) and 164.528 and lift both your readiness and your ability to prove it independently. Early access ## Turn your weakest answer into provable evidence. Bring a clinical-AI or record-access flow from your environment. We will bind a verified identity to every access and seal a tamper-evident, PHI-free record that supports 164.312(b) audit controls and 164.528 accounting of disclosures, and your team will verify it without trusting us. A readiness aid, not legal advice. Request early access → The PHI-free access audit