The regulatory clock, the Wrong Pocket problem, and why governing AI will require AI
Midnight is different for everyone.
An AI regulation can be enacted today, become effective months later, impose one obligation next year and another two years after that. Whether any of those dates matter to your company may depend on where you operate, what the AI does, what data it touches, whether you built or deployed it, who is affected by its output, and what decisions it is allowed to make. So asking, “When does the AI law take effect?” is increasingly the wrong question.
- The better question is: When does it take effect for us?
- Or, less formally: When do our AI agents turn into pumpkins?
The distinction is not semantic. California’s 2025 CCPA regulations addressing risk assessments, cybersecurity audits and automated decisionmaking took effect January 1, 2026, but the obligations do not all run on the same clock. Businesses subject to the risk-assessment requirements began compliance in 2026, requirements for covered uses of automated decisionmaking technology in significant decisions begin January 1, 2027, and initial cybersecurity-audit reporting deadlines phase in from 2028 through 2030 depending on the business. (California Privacy Protection Agency)
And California is only one example. Colorado’s original 2024 AI regime was subsequently repealed and reenacted with materially different automated-decisionmaking provisions that take effect January 1, 2027; as of October 2, 2026, the Attorney General is still conducting the required rulemaking. (Colorado Attorney General) In Europe, a 2026 amendment to the AI Act moved specified high-risk requirements to December 2, 2027 for systems classified under Article 6(2) and Annex III and August 2, 2028 for systems classified through Article 6(1) and Annex I. (Eur-Lex)
There is no useful enterprise answer called the AI regulatory date. An enacted date is not necessarily an effective date. An effective date is not necessarily the date a particular obligation applies. A compliance date may differ from a reporting date. An expiration or transition date may matter too. And none of those dates tells you, by itself, whether the requirement applies to your system.
Nor are all clocks started by dates alone. Some obligations become relevant because something changes: the system is deployed in another jurisdiction; its permissions expand; it begins touching different data; an advisory system starts taking actions; a vendor changes the underlying model; or a use crosses into a legally defined consequential category.
Those triggers still exist inside legal and policy regimes with temporal boundaries. Some clocks start because a date arrives. Others start because something about your system changes. Knowing what starts the clock is part of owning the clock.
That means every serious AI program needs a Regulatory Clock, even if, for a relatively simple and low-risk program, that initially means knowing which changes would make more explicit tracking necessary. It is not a static list of statutes. It is a living view of the organization’s actual uses: What applies to this system, in this jurisdiction, given our role? When? What conditions would change the answer? What must already have happened before the obligation arrives? What evidence will we need afterward?
A recent Ropes & Gray AI Outlook webinar helped crystallize this for me. Partners Rohan Massey and Maya D. Song ranged across the increasing overlap between AI and data protection; divergent U.S. and European regulatory approaches; automated decisionmaking; cybersecurity and vendor risk; data scraping and pseudonymization; and the practical mechanics of governance. Their subsequent recap reduced much of that complexity to a useful operating core: AI and data protection cannot be treated in silos; the regulatory landscape is dynamic; governance requires the right people, policies and procedures; and documentation, auditing and testing matter.
Regulation Eventually Becomes a Decision
Someone eventually has to decide whether a proposed AI use can proceed, under what conditions, with what controls, with whose approval, and subject to what continuing monitoring. Someone has to determine whether a change to the model, vendor, data, prompt architecture, permissions or workflow is immaterial or important enough to reopen the original decision. Someone has to decide whether an observed failure is tolerable, remediable or disqualifying.
Sometimes, of course, regulation removes that discretion. A legal prohibition is not merely another variable to weigh against the business case. Rights held by employees, consumers or other affected people do not become negotiable simply because violating them would create enterprise value. Governance therefore has to distinguish constraints from tradeoffs.
From an operating-model standpoint, not as a taxonomy of legal doctrine, I increasingly want legal advice translated into one of three actionable states:
- Prohibited. The proposed action is legally unavailable, violates a binding constraint, or falls outside an established policy boundary. The business does not get to accept that risk in exchange for more revenue or greater productivity.
- Material residual risk. The action is not categorically unavailable, but meaningful legal or regulatory uncertainty or exposure remains after appropriate controls. Legal should articulate the risk, the constraints and the consequences clearly. An appropriately authorized business leader then decides whether that residual risk is one the enterprise is willing and permitted to assume.
- Ordinary course. There is no unusual legal exposure beyond the organization’s established controls and normal operating practices. Proceed accordingly.
In much plainer English: No. Yes, but somebody with authority has to own the remaining risk. Yes, under normal controls.
That distinction matters because the lawyer who identifies a material legal risk should not automatically become the executive who owns the enterprise tradeoff merely because law is one of its inputs. Nor should “business ownership” become a euphemism for overriding an independent control function when the answer really is prohibited.
At enterprise scale, lawyers cannot personally gatekeep every prompt, model, agent and workflow, nor should they. Neither can an AI committee become the place every proposed use case goes to wait for permission. At sufficient scale, that architecture becomes a bottleneck. Organizations then risk two familiar failure modes: people route around governance because it is too slow, or governance suppresses adoption because stopping activity becomes much easier than evaluating it intelligently.
Nor should every use receive the same treatment. All else equal, using an approved AI system to summarize a routine, non-sensitive internal meeting is not the same thing as using an automated system to materially influence a consequential employment, lending or healthcare decision. A small change to an approved workflow should not necessarily trigger the same review as a new use of the same underlying model with different data, permissions, users or consequences.
Governance therefore has to be capable not only of making decisions, but of making different kinds of decisions proportionate to what the system is actually allowed to do. Good AI governance cannot principally be a collection of policies. It has to become an operating system for deciding when to say yes, when to say no, who gets to decide, who owns the consequences, and what evidence would justify changing the answer later.
AI Governance Has a Wrong Pocket Problem
I recently wrote about healthcare’s Wrong Pocket problem: the organization paying for an intervention may not be the organization receiving the economic benefit. (The Numbers Don’t Square) AI governance has an analogous Wrong Pocket problem inside the enterprise.
The business unit sponsoring an AI deployment may capture much of the visible upside: productivity, shorter cycle time, reduced operating cost, additional capacity, better customer experience or competitive advantage. Legal, risk, compliance, security and governance functions participate in those gains much more diffusely. Their experience of the downside can be far more immediate: a privacy failure, a discriminatory decision, an enforcement action, a security incident, a control failure, an embarrassing public example, or an executive being asked why the system was ever allowed to operate.
That asymmetry became particularly vivid late in the Ropes & Gray discussion. Maya Song argued, reasonably, that organizations using agentic AI should not merely register its use; they should make sure there is a person accountable if something goes rogue.
I agree with the accountability. But my immediate reaction was: what incentive have we just created for that person?
If I receive little credit when I say yes and the system works, but I own a disproportionate share of the consequences when I say yes and it fails, then saying no does not prove that I am obstructionist. It may simply be the rational decision produced by the incentives around me.
That is how accountability can become the Governance of No.
The problem is not too much accountability. It is accountability divorced from authority, benefit and risk-sharing. That does not mean Legal and Risk should be given a piece of the business-unit bonus pool so they become more enthusiastic approvers. Their independence has value precisely because the sponsor of an initiative may be systematically more optimistic about its benefits and less sensitive to harms that fall on employees, customers, patients, applicants or the public. Independent challenge is a feature, not a defect.
NIST’s voluntary AI Risk Management Framework Playbook makes much the same structural point from the other direction: it suggests separating development and testing functions, preventing conflicts of interest, empowering oversight, and counteracting incentives that can interfere with sound risk management. (NIST AI Resource Center)
So the answer is not to eliminate asymmetry. It is to put each kind of accountability in the right place. The people proposing the use need to own more than the business case; they need to own the obligations and foreseeable harms that come with deployment. Independent Legal, Risk, Compliance and Security functions need enough authority to challenge evidence, impose legitimate constraints, require remediation and escalate unresolved questions. That authority also has to include saying when there is no residual risk for the business to accept because the proposed action falls outside a legal, regulatory or established policy boundary. In those cases, the answer is simply no.
But where the action is legitimately available and material residual risk remains, the enterprise tradeoff should be made by management at a level with the authority to make it, not quietly pushed into the pocket of a control function that receives little of the benefit but can be held disproportionately responsible for the downside.
This is why exhorting Legal to “be more innovative” or telling a risk committee to “move faster” often misses the mechanism. If the company has allocated the economic benefit to one pocket and responsibility for the discretionary tradeoff to another, culture workshops will not repair the decision architecture.
The design problem is to make the accountability coherent. Otherwise the company has not really allocated accountability. It has merely identified whom to blame.
Agents make this harder because the relevant unit of risk is no longer simply a model generating an answer. An agent may have access to enterprise data, invoke other software, communicate externally, alter records or initiate transactions. Its risk depends not only on what model sits underneath it but on what permissions it has, what information it can retrieve, what actions it can take, which humans remain in the loop and how the surrounding workflow reacts to its output.
A relatively ordinary model attached to powerful tools may deserve more governance than a technically more capable model confined to a narrow sandbox. A system that drafts a recommendation for human review is not the same thing as one that acts on that recommendation. Even the same system’s risk profile, and potentially its internal governance tier, can change as its permissions and role change.
That is why governing “the AI” is becoming an inadequate abstraction. You have to govern the decision system around it.
Documentation Is Becoming an Evidence Problem
If organizations take that seriously, they are going to generate an extraordinary amount of governance evidence. The Ropes & Gray recap calls documentation, auditing and testing non-negotiable. The NIST AI RMF and its voluntary Playbook point in the same direction: applicable legal and regulatory requirements should be understood and documented; responsibilities should be clear; risk management should continue through the lifecycle; and governance practices should support testing, monitoring, incident management and auditability. NIST is explicit that the Playbook is voluntary and is neither a checklist nor a mandatory sequence of steps. (NIST AI Resource Center)
At small scale, those requirements can sound manageable. At enterprise scale, “documentation” stops meaning an AI policy, a spreadsheet and a signed approval form. It can mean evidence about the system inventory and changing configuration; use-case classification; applicable requirements; vendor diligence; model and software versions; relevant data sources; prompts or system instructions where appropriate; testing and red-team findings; approvals and exceptions; access rights; material overrides; incidents; monitoring; complaints; regulatory changes; remediation; and the rationale behind decisions to approve, constrain, pause or retire a system.
The objective is not documentation for documentation’s sake. It is reconstructability: the ability, months or years later, to understand what the organization knew, what it tested, what it decided, who decided it, what conditions were attached to that decision, and what happened when the underlying facts changed. Reconstructability does not require indiscriminate retention. More information is not automatically better governance. Prompts may themselves contain sensitive information. Red-team findings may expose vulnerabilities. Vendor materials may be proprietary. Privacy, security, privilege, contractual obligations, data-minimization requirements and retention policies still apply.
The objective is to preserve the right evidence for the appropriate period, with appropriate access, minimization and security controls, not to save everything forever. The test is whether that reconstruction remains possible.
Months or years after a material decision, could the organization answer: What did we know at the time? What did we test? What requirement did we believe applied? Who made the decision? What conditions did they impose? What evidence supported it? What subsequently changed? Did our controls actually operate? And when the facts changed, did we notice?
A governance system that cannot answer those questions has a problem even if its policy manual is excellent.
At sufficient scale, expecting humans to reconcile this evidence continuously by hand becomes implausible. The number of systems will grow. Their configurations will change. Regulations and guidance will change. Vendors will update models. Agents will gain or lose permissions. Testing and monitoring will create additional evidence. An incident in one part of the enterprise may reveal a control weakness relevant somewhere else.
The constraint eventually becomes not simply information volume, but qualified human attention, which creates an apparently recursive conclusion: we will almost certainly need AI to govern AI.
That does not mean letting a model mark its own homework. It means using AI where it is particularly valuable in the evidence layer while keeping the authority to make consequential judgments elsewhere.
There is a useful and narrower role for AI in the evidence layer. It can help ingest and organize authoritative, versioned regulatory and policy sources; reconcile those sources against inventories; surface systems that may be affected by a change; identify missing documentation; compare current configurations with approved ones; detect anomalies or drift; assemble candidate audit trails; and direct human attention toward exceptions that deserve judgment.
The distinction between surfacing possible applicability and becoming the legal authority is essential. An AI system can tell a qualified lawyer, compliance professional or domain expert, “These 73 systems may be affected by this change, and here is why.” It should not silently convert probabilistic interpretation into an enterprise legal conclusion.
And separation of functions matters. The system gathering evidence does not have to be the system being evaluated. The system surfacing an exception does not have to decide whether that exception is acceptable. The system drafting an audit trail does not have to certify its own completeness.
That raises an old governance problem in a new form: Who watches the watchers? The answer cannot be another AI, followed by another AI, followed by another. That is not governance; it is turtles all the way down. A workable assurance architecture has to terminate somewhere. AI can organize evidence, monitor change and surface exceptions. Deterministic code can enforce boundaries where the rule can actually be expressed deterministically. Independent testing can challenge system behavior. Qualified humans can interpret ambiguous evidence and make consequential judgments. Management can accept legitimate residual business risk. Boards can oversee material enterprise risk. Regulators and independent auditors can provide external challenge where appropriate.
Even within the automated layers, independence cannot simply mean “use another AI.” Two nominally separate systems may share the same underlying model family, source errors, provider dependencies, blind spots or failure modes. Depending on consequence, assurance may therefore require authoritative and versioned sources; deterministic controls where deterministic controls work better; independent test sets; sampling and human validation; explicit treatment of uncertainty and escalation; and enough technical diversity to reduce material correlated failure.
NIST’s voluntary Playbook similarly contemplates independent testing functions and assessing whether testing and oversight actors possess sufficient independence and authority to perform assurance effectively. (NIST AI Resource Center)
AI can make the governance system substantially more capable without becoming the institution that exercises consequential judgment. My bet is that, for large enterprises, the governance evidence layer will become too voluminous and dynamic to manage well without AI assistance.
There is something fitting about that. AI governance itself becomes another AI use case, and therefore another system that needs a defined purpose, an appropriate risk classification, controls, validation, monitoring and inclusion in the enterprise’s AI inventory.
Govern the Decision System
The Regulatory Clock tells you what obligations are approaching, what conditions may activate them and which systems may be affected. Decision rights determine who can authorize, constrain, stop or reopen a use. Incentives influence how those people exercise their authority. Documentation preserves enough evidence to make important decisions intelligible later. Monitoring tells you when the assumptions beneath those decisions have changed.
These are not separate governance topics. They are parts of the same system. That system includes models and agents, certainly, but also data, prompts, tools, vendors, access rights, people, policies, business incentives, technical controls and the consequences, inside and outside the enterprise, of getting the decision right or wrong.
This is why I am increasingly skeptical of questions such as, “Do we have an AI policy?” A policy may be necessary. It tells me very little about whether the enterprise can actually govern AI.
The same applies to board engagement. The board’s role is not to approve individual AI use cases or manage implementation. Management owns that work. But for material AI strategy and enterprise risk, meaningful board oversight should go beyond periodic assurance that a policy exists. Directors should be able to understand whether management has established coherent authority, accountability, escalation and risk boundaries, and whether management can demonstrate that the resulting governance system actually operates.
I would rather know whether an organization can tell when its regulatory clocks start; distinguish legal constraints from legitimate business tradeoffs; put decisions in the hands of people with the right authority; preserve independent challenge without making “no” the only rational answer; recognize when an approved system has materially changed; and reconstruct, later, why an important decision was reasonable.
Doing that well will require more than better tools and controls. It will require training, upskilling and empowering many more people across the enterprise. I have argued elsewhere that as AI capability and adoption accelerate, the answer is not to slow the technology but to speed up the rest of the stack. (LinkedIn Post) The rest of the stack includes people. Governance cannot remain the exclusive province of a small central committee. People throughout the enterprise need enough understanding to recognize when a use or system has changed, know which decisions they are empowered to make, distinguish ordinary-course activity from material risk, and know when to escalate. AI can help those people manage an evidence environment that might otherwise overwhelm them. It does not eliminate the need for their judgment; it makes the quality and distribution of that judgment more important.
That is harder than writing a policy. It is also much closer to the problem enterprises actually have to solve.
Midnight will not arrive on the same date, or under the same conditions, for every company, or even for every AI system inside the same company. Some obligations have already arrived. Others are approaching on different clocks. Meanwhile, the technology will change, the regulation will change, and organizations will change what their systems are allowed to do.
So the important question is no longer simply whether you are “ready for AI regulation.” It is whether you know when your clocks start, who owns the decisions they create, and whether you will still be able to explain those decisions after the world has changed around them.
Midnight is a terrible time to discover that nobody owned the clock.
-Marc d. Paradis
About the Author: Marc d. Paradis’ professional journey is a fusion of academic rigor with real-world impact. He began his career over 30 years ago as an academic molecular neurobiologist, instilling in him a deep respect for critical thinking and the scientific method.
Transitioning into industry, he held leadership roles that bridged data and healthcare: as Vice President of Data Strategy at Northwell Health, Marc leveraged one of the world’s most diverse clinical data sets to drive patient-centered innovation via a $100M partnership with Aegis Ventures, launching multiple AI-centered startups; and as Vice President & Dean of Data Science University at Optum, he spearheaded the training of thousands of professionals in practical, product-centric AI, data-driven decision making, and ethical data practices. In each role, he fostered cultures of curiosity, critical thinking, and collaboration – precursors to the Constructive Inquiry ethos.
About SIYOM Consulting: Founded by Marc d. Paradis, SIYOM Consulting is a boutique advisory specializing in Data and AI Strategy for Healthcare and Life Sciences. We help health-system executives, pharma innovators and investors identify, evaluate and execute on high-value data and AI opportunities.
Thank you to Rohan Massey and Maya D. Song for an excellent and thought-provoking discussion, and to Ropes & Gray for continuing to convene these conversations through its AI Outlook series.
Source note for review: Speaker remarks are paraphrased from personal notes, not presented as speaker- and/or audio-verified quotations.