AI Act, CMMC, and HIPAA Timelines Slipped. The Duty to Act Did Not.
Three regulatory timelines moved this summer. As I sat down to write about the HIPAA final rule movement, I kept noticing that several regulations have met the same fate. Are they related? What does it mean for compliance strategy? I came up with this: Regulatory deadlines may move, but enforcement expectations do not. Organizations must act on identified AI and security risks and maintain evidence showing who owned the risk, what was decided, and what was done.
The EU delayed its high-risk AI requirements. Regulation (EU) 2026/1744, the Digital Omnibus on AI, was adopted July 8 and entered into force July 27. The affected requirements for standalone Annex III high-risk systems now apply from December 2, 2027, and those for AI embedded in regulated products under Annex I from August 2, 2028.
The Department of War suspended CMMC Phase II requirements on July 13, four months before their scheduled November 10 start, and initiated a 60-day review of the program. Phase I self-assessment requirements remain in place.
And the Unified Agenda moved the projected final-action date for the proposed HIPAA Security Rule to July 2027 and placed the rulemaking in Long-Term Actions. No final rule exists. What moved is a projection.
None of that changes the question that keeps recurring across major AI and security enforcement actions: once an organization identifies a material risk, who owns it, what was decided, and where is the evidence that the decision was carried out?
Most organizations can answer the first part. The files tend to go quiet after that.
The anatomy of a failure-to-act case
FTC v. Rite Aid remains the clearest illustration.
Rite Aid deployed facial recognition across hundreds of stores from 2012 to 2020 to flag suspected shoplifters. According to the FTC's complaint, the system produced thousands of false positives and was more likely to do so in stores located in plurality-Black and Asian communities. Employees followed customers, searched them, called police, and accused people of theft in front of their families.
Read the FTC's list of what Rite Aid allegedly failed to do. Each item concerns action, not simply assessment.
The company allegedly failed to consider and mitigate risks from misidentification, including heightened risks by race and gender. It failed to test or assess accuracy before deployment, or even to ask its vendors what testing they had performed. It failed to monitor accuracy after deployment, including tracking false-positive rates and what employees did in response to false matches.
Then there is the allegation worth reading twice.
Rite Aid eventually switched to a system that allowed employees to report a "bad match" and required them to use it. According to the complaint, the company "did not take action to ensure employees followed this policy."
They built the control. They mandated it. They never checked whether it ran.
The stipulated order that followed imposed a five-year ban on facial recognition for surveillance, deletion of the images and of algorithms or other products developed from them, and an annual compliance certification signed by the CEO.
A smaller detail in the same complaint deserves attention from privacy and security teams. Rite Aid allegedly conducted many of its vendor security assessments orally and kept no supporting documentation, including for vendors it had classified as high risk.
The assessment may have happened. It left no evidence, which for enforcement purposes lands in nearly the same place.
The same expectation across regimes
This is not one agency's theory or one framework's vocabulary.
OCR pairs risk analysis with risk management in its corrective action plans, and has for some time. Its April 2025 Northeast Radiology settlement required the organization to conduct a risk analysis and to develop and implement a risk management plan addressing the risks the analysis identified.
OCR's July 29, 2026 settlement with OSF Healthcare System carries the same two obligations, stated separately. OSF agreed to pay $552,250 and operate under a two-year corrective action plan.
The EU wrote the expectation into law. Article 9 of the AI Act defines the required risk management system for high-risk AI as a "continuous iterative process" planned and run throughout the system's lifecycle, with regular systematic review and updating.
For the affected Annex III systems, that requirement now applies from December 2027 rather than August 2026. But the statutory expectation is already clear: identify the risk, evaluate it, take targeted measures, and continue reviewing the result.
NIST reached the same operating model without enforcement authority.
The current AI Risk Management Framework has four functions: Govern, Map, Measure, and Manage. Manage covers prioritizing and treating identified risks, monitoring deployed systems, responding to incidents, providing appeal and override mechanisms, managing changes, and deactivating systems whose performance is inconsistent with their intended use.
Many programs have invested significantly in governance, mapping, and measurement. Manage is where identified findings too often become intentions rather than completed work.
Why this is harder for AI
Many conventional security controls are comparatively concrete and testable. An assessor can examine MFA coverage, encryption configuration and key management, access rules, and system logs, and reach a defensible conclusion about whether a control is operating.
AI risk is more dynamic.
Performance can drift. The affected population can change. A vendor may modify a model or the surrounding system, sometimes without notice. An output that performs acceptably in one context may fail in another. For many models, full mechanism-level explainability remains limited, which puts more weight on outcome monitoring, incident review, and change control.
That makes follow-through more demanding for AI, not less.
A defensible record is not a one-time validation. It shows that the organization kept looking: what it monitored, what it found, who made the decision, what changed, and what would trigger another review.
What a defensible AI risk decision looks like
Every material finding in an AI program should carry five things. The framework works for both open and closed findings, which is the point.
The specific finding and affected use case. Not "potential bias risk." Something closer to: "The false-positive rate was 3.1 times higher for applicants over 50 in the June sample for the resume-screening tool."
A named owner and a named approver. Identify the person responsible for completing the work and the person authorized to approve the disposition or accept the residual risk. Where the same person fills both roles, say so.
The disposition, rationale, target date, and any interim safeguards. Mitigate the risk, accept it, transfer it, or stop the use. If the organization accepts the risk, the record should explain why the residual risk is reasonable for this use, in this context, and during what period. A bare "accepted" status does little to demonstrate how the organization reached that conclusion.
Dated evidence that the decision was implemented. The configuration change. The model replacement. The added human-review step. The revised workflow. The contract amendment. A completion date without supporting evidence is another assertion, not a closed finding.
A re-evaluation trigger. A date, a performance threshold, an incident, a vendor change, or a defined change in the system, use case, or affected population that requires another review.
Pull your three highest-risk AI use cases and try to produce those five elements for each.
Where you can produce the finding but cannot produce the evidence, that is the exposure. It is the failure-to-act pattern the Rite Aid complaint illustrates.
Deadlines will keep moving. Existing enforcement authority does not.
The FTC did not need an AI-specific statute to pursue Rite Aid. OCR does not need a final HIPAA Security Rule to require both risk analysis and risk management. And organizations do not need to wait for a future compliance date to create a record showing that identified risks were assigned, decided, addressed, and reviewed.
The defensible record is short: what you found, who owned it, what was decided, when it was done, and what will force another look.