Michigan founders who build, fine-tune, deploy, or commercialize advanced AI systems should be paying close attention to House Bill 4668, even if they assume the bill is aimed only at the largest model developers. As of March 9, 2026, HB 4668 remains a proposed bill rather than enacted Michigan law, and the latest publicly available legislative history shows it was introduced in June 2025 and later referred to the House Committee on Regulatory Reform in September 2025.¹ That status matters because founders should not treat the bill as binding law today. What matters even more, however, is what the bill reveals about the direction of travel. HB 4668 is a serious attempt to convert AI safety from a voluntary governance slogan into a documented, reviewable, litigation-adjacent compliance regime. ¹²³
For founders, that means the bill should be read less as a distant political curiosity and more as a live preview of the standards sophisticated regulators, enterprise customers, investors, insurers, and eventually courts may expect from companies building powerful models. A startup that waits to think about risk management until a regulator sends a letter will already be behind. The deeper lesson of HB 4668 is that AI liability is shifting away from abstract debates about innovation versus regulation and toward a practical question: can the company prove it took foreseeable catastrophic risks seriously before those risks became someone else’s injury, data loss,
or crisis? ²³
The first thing founders need to understand is that HB 4668 is not written as a general-purpose AI law for every software company in Michigan. In its introduced form, it targets “large developers” of foundation models, and the bill defines that category using compute-cost thresholds rather than revenue, headcount, or hype. A covered company would be one that has developed a foundation model using at least $5 million in computing power and, within the prior twelve months, has developed one or more foundation models with aggregate computing costs of at least $100 million. ²³ That is a very high threshold. Most early-stage founders will read that and conclude, correctly, that the bill does not directly regulate them today.
That conclusion is only half right. Direct coverage and practical exposure are not the same thing. Even founders below the statutory thresholds should assume that the governance logic of HB 4668 will trickle downstream through commercial diligence and contractual allocation of risk. The reason is straightforward. If a state bill, a legislative analysis, and a national policy debate are all converging on the idea that frontier AI development should be documented, audited, and monitored for catastrophic risk, then startups that build on top of advanced models will increasingly be asked to explain their own safety posture in similar terms.³⁵ In other words, many founders will encounter HB 4668 first through procurement questionnaires, board discussions, and indemnity negotiations long before they ever encounter it in a courtroom.
The bill’s central concept is “critical risk,” and that phrase is where the legal and strategic stakes become clear. HB 4668 does not regulate every hallucination, every product bug, or every ordinary negligence scenario. Instead, it focuses on foreseeable and material risks that a large developer’s development, storage, or deployment of a foundation model could lead to death or serious injury to more than 100 people, or more than $1 billion in property damage, through specific categories of incidents. Those categories include the creation and release of a chemical, biological, radiological, or nuclear weapon, a cyberattack conducted by or assisted by a foundation model, or a model engaging in certain criminal or quasi-criminal conduct with limited human intervention. ² That is not ordinary consumer-protection language. It is catastrophic-risk language.
For founders, that definition does two important things at once. On the one hand, it narrows the bill to extreme scenarios, which may reassure companies that are building less capable or more narrowly scoped systems. On the other hand, it sharply raises the seriousness of the governance obligations for any company that is covered. When lawmakers frame the relevant risk in terms of mass casualty events, major cyberattacks, and billion-dollar losses, they are telling founders that ad hoc governance will not be enough. The company’s safety controls, deployment decisions, and internal escalation procedures must be mature enough to withstand scrutiny after the fact. ²³ That is why HB 4668 should be read as a documentation and accountability bill as much as an AI bill.
The heart of the bill is the required “safety and security protocol.” In the introduced text, that protocol is not a one-page ethics statement or a generic promise to use AI responsibly. It must describe, in detail, how the developer identifies which models are covered, what risk thresholds are considered intolerable, how testing and assessment are performed, how deployment decisions are made when critical risks are present, what physical, digital, and organizational security measures protect the models, what safeguards mitigate those risks, how the company will respond if a critical risk becomes imminent or materializes, when additional assessments are triggered by modifications or expanded access, when incidents will be reported, and when the protocol itself will be revised.² In practical terms, the bill is asking for a living operating manual for catastrophic-risk governance.
That should sound familiar to anyone who has worked with serious security, privacy, or model-governance frameworks. It is also why founders should look to the NIST AI Risk Management Framework and the NIST generative AI profile as useful planning tools even outside a legal mandate. NIST’s framework is voluntary, but it is designed to help organizations incorporate trustworthiness and risk-management considerations into the design, development, use, and evaluation of AI systems, and NIST’s generative AI profile is specifically aimed at identifying unique risks presented by generative systems.⁵ If a founder wants to know what “good faith” AI governance may eventually look like when translated into evidence, NIST is one of the best places to start because it helps turn abstract principles into repeatable process.
What founders should notice next is that HB 4668 is obsessed with publication, not merely internal compliance. Beginning January 1, 2026 in the introduced text, a covered developer would have to produce, implement, follow, and conspicuously publish its safety and security protocol, publish material modifications within thirty days, and publish a transparency report at least every ninety days covering a defined reporting window.² Because the bill has not been enacted, those dates are not active legal deadlines today.¹² But the draft date still reveals the legislature’s posture: the burden is not only to build controls but also to disclose enough about them that outsiders can evaluate whether the company is managing risk responsibly.
That is a major shift in the legal environment for AI companies. Founders are used to thinking about internal memos as privileged strategy, engineering process, or confidential product material. HB 4668 pushes in the opposite direction by treating at least part of the company’s risk architecture as something that must be visible, explainable, and periodically updated. The bill does allow redactions to protect trade secrets, public safety, national security, or compliance with applicable law, but it also requires unredacted versions to be retained for at least five years and made available to the attorney general upon request, with the character and justification of the redactions described in the published version.² That means founders should not assume that “we kept it confidential” will be a durable shield if the state decides to look behind the curtain.
The transparency-report obligation is equally important because it turns risk management into a recurring discipline rather than a one-time policy exercise. The introduced text calls for disclosure of the conclusions of risk assessments, periodic assessment of the model most capable of creating each category of critical risk, and, if the developer deployed or modified a model that would pose a higher level of critical risk than existing deployed models absent safeguards, the grounds for deployment and the protections implemented to mitigate that risk.² This is exactly the kind of record a plaintiff, regulator, or investigative reporter would want to see after an incident. It can help the company if it shows rigor, but it can hurt the company if it shows corners were cut, concerns were ignored, or deployment went forward without a serious basis.
The bill also imposes a retention requirement that founders should not overlook. Covered developers would have to record and keep for five years the specific tests used and results obtained in assessing critical risk, with enough detail for qualified third parties to replicate the testing. ² In litigation terms, this is not just about internal learning. It is about reproducibility, discoverability, and auditability. A founder who understands that point early will design testing programs differently. Teams will version prompts, datasets, red-team scripts, evaluation criteria, and escalation decisions more carefully if they know the question later may not be whether testing occurred, but whether a qualified outsider could reconstruct what was done and whether it was enough.
Annual third-party audits raise the stakes further. HB 4668 would require a reputable third-party auditor to assess whether the developer complied with its own safety and security protocol, identify noncompliance, identify ambiguity in the protocol itself, and identify any apparent violations of the bill’s publication and redaction provisions. The company would have to give the auditor access to materials reasonably necessary for the assessment, and the report would have to be published within ninety days after completion. ² This is not a cosmetic certification regime. It is a structure that creates an external witness to whether the company’s governance system actually functions. For founders, that means AI risk management would no longer be judged solely by internal leadership, but by someone outside the company with both compliance and technical expertise.
That audit feature is especially significant because it changes how a founder should think about operational maturity. In many startups, safety review is diffuse. Engineers own one part, product owns another, legal writes a policy, and leadership assumes alignment exists because everyone attended the same meeting. A third-party audit does not reward that kind of ambiguity. It rewards ownership, traceability, and decision records. A founder preparing for an HB 4668-style world should already be asking whether the company can show, in one coherent evidentiary package, who approved deployment, what tests were run, what thresholds triggered escalation, what mitigation was adopted, and what happened when personnel raised concerns. ²⁵
The whistleblower provisions may be the most underestimated part of the bill for startup leadership. HB 4668 would prohibit a large developer from discharging, threatening, or otherwise discriminating against an employee because the employee, or someone acting on the employee’s behalf, reports or is about to report to an appropriate federal or state authority information indicating that the developer’s activities pose a critical risk, unless the employee knows the report is false.² The statute’s definition of “employee” is broad and includes not only conventional employees but also contractors, subcontractors, unpaid advisors involved in critical-risk work, and corporate officers.² Founders should sit with that for a moment. In a startup, the people most likely to see a problem early are often exactly the people leadership informally assumes are outside the core HR framework.
The bill goes further than a simple anti-retaliation rule. It would require covered developers to post notices informing workers of their protections and obligations, and to provide a reasonable internal process through which an employee may anonymously disclose information in good faith if the employee believes the company’s activities present a critical risk. The company would then have to give the employee a monthly update on the status of the investigation and any responsive actions taken. ² Disclosures and updates would need to be preserved for at least seven years and shared quarterly with officers and directors who do not have a conflict of interest. ² That is a remarkably specific governance mandate. It pushes whistleblowers handling out of the realm of informal culture and into auditable board-level process.
From a founder’s perspective, this is where legal exposure and culture risk converge. Retaliation claims often do not begin with a clean admission like “we fired her because she raised an AI safety issue.” They arise from patterns that look defensible in isolation and incriminating in sequence: exclusion from meetings, a sudden performance critique, narrowed responsibilities, relocation pressure, a lost bonus, or a termination justified as “fit” shortly after internal escalation. HB 4668’s language expressly reaches threats and other discrimination affecting compensation, terms, conditions, location, or privileges of employment. ² That breadth means startup leaders should not assume the risk is limited to formal termination decisions. In a small company where roles shift quickly and communication is informal; retaliation evidence can accumulate faster than leadership expects.
Founders also need to notice that HB 4668 does not replace Michigan’s existing Whistleblowers’ Protection Act. The bill expressly states that it does not invalidate or limit any protection afforded to an employee or any obligation imposed on an employer under the WPA.² Michigan’s WPA already protects employees who report or are about to report suspected legal violations to public bodies, and it defines employee and employer in conventional employment-law terms.⁴ The practical takeaway is that an AI company could face a layered whistleblower problem rather than a single clean claim. A worker may invoke the AI-specific statute, existing Michigan whistleblower law, and potentially other employment or tort theories depending on the facts. ²⁴ For founders, that means the safest approach is not technical compliance with one statute, but a broader anti-retaliation architecture that treats protected reporting as part of enterprise risk management.
Civil liability under HB 4668 comes from more than one direction. An employee who alleges retaliation could bring a civil action within ninety days seeking injunctive relief, actual damages, attorney fees, witness fees, court costs, reinstatement, back wages, fringe benefits, and seniority restoration, among other relief the court finds appropriate.² The employee would have to show by clear and convincing evidence that the employee was about to make a protected report, which is a meaningful burden, but not one founders should treat lightly. In real disputes, timing, emails, Slack messages, changes in access, and meeting notes often do much of the evidentiary work. A company that has strong reporting procedures and disciplined documentation will be in a much better position than a company that relies on memory and interpersonal trust.
Separate from private employee actions, the Michigan attorney general would have substantial enforcement authority. If a large developer violated the bill’s publication and audit provisions, the attorney general could bring a civil action seeking a fine of up to $1 million per violation, injunctive relief, or declaratory relief.² If the developer’s activities present an imminent critical risk, the attorney general could also seek injunctive relief.² That is one of the most important founder-facing signals in the bill. The state is not merely threatening backward-looking penalties after catastrophic harm occurs. It is reserving the power to go to court to stop conduct that appears to create imminent extreme risk. For any company close to the statutory thresholds, that possibility should alter how leadership thinks about launch speed, model access, and public claims about safety.
There is also an underappreciated liability concept embedded in the structure of the bill: process can become evidence. The more the law requires safety protocols, transparency reports, retained tests, auditor review, board-level disclosure handling, and public statements, the more future liability disputes will focus on whether those materials were complete, truthful, and internally consistent. HB 4668 expressly bars knowingly false or materially misleading statements or omissions in required documents. ² That means founders should stop viewing governance paperwork as separate from litigation exposure. In an AI company, the policy memo, the model card, the board packet, the red-team report, the incident log, and the public safety statement may all become pieces of the same story. If they conflict, the conflict itself can become a problem.
Even founders who remain comfortably below the bill’s current thresholds should take note of how the proposed law treats deployment. HB 4668 requires a documented procedure for deciding whether and how to deploy a model when doing so poses critical risks, and it requires additional assessment when access is expanded, models are modified, or models are combined with other software. ² This is crucial because some of the most serious AI risks do not arise at initial model release. They arise at integration, tooling, agentic enablement, plug-in access, post-training optimization, or when a previously controlled model is exposed to a larger user base. A startup that thinks safety is finished once the model clears an internal benchmark is thinking too narrowly. The real legal question increasingly becomes whether the company treated deployment as a continuing risk decision rather than a one-time engineering milestone.
This is why founders should read HB 4668 as a governance checklist even when they are not legally required to follow it. The company should know which systems qualify as foundational versus feature-level tools, which uses could materially increase misuse potential, which failure modes are unacceptable, and which decisions require escalation beyond the product team.⁵ It should know who can approve expanded access, who owns incident response, how model weights or sensitive capabilities are secured, and how the board is informed when the company is making a meaningful risk tradeoff. None of that is bureaucratic excess. It is the infrastructure that separates a company with an explainable safety posture from a company whose risk decisions exist only in scattered chats and fading memory.
Founders should also think carefully about what kind of culture their current operating model creates. In fast-moving AI companies, leadership often says it wants employees to raise concerns, but the surrounding incentives send the opposite message. If the people who question deployment are treated as blockers, if deadlines matter more than escalation, or if dissent is tolerated only when it stays private and non-disruptive, then the company is training employees to go elsewhere with their concerns when the issue is serious enough. HB 4668’s whistleblower design assumes exactly that risk and attempts to formalize a safer alternative by requiring anonymous internal channels and regular updates. ² The founders who learn from that premise now will build more resilient teams than the founders who treat reporting structures as a concession rather than an asset.
There is another reason this matters: external stakeholders are getting more sophisticated. Investors increasingly ask about model governance, enterprise customers ask about security and testing, insurers ask about controls and incident response, and counterparties are more willing to push compliance obligations downstream by contract. While HB 4668 would directly cover only certain large developers, its vocabulary of protocols, testing, publication, audit, record retention, and internal reporting is exactly the kind of vocabulary that tends to migrate into diligence and contractual representations.³⁵ A founder who cannot explain the company’s AI risk management program in those terms may soon sound underprepared even if the company is technically outside the statute.
So what should a prudent founder do now, before Michigan adopts anything like HB 4668 in final form? The answer is not to mimic every line of the bill regardless of company size. The smarter move is to adopt the bill’s operating logic in proportion to actual capability and actual risk. That means identifying the handful of model-related scenarios that could seriously harm people, critical systems, or property; assigning ownership over those risks; documenting testing and deployment criteria; preserving evidence of the company’s evaluations; and building an internal channel that allows people to raise concerns without fear of retaliation or career damage. ²⁵ The goal is not theatrical compliance. The goal is to be able to demonstrate, if challenged, that the company understood the foreseeable risks of what it was building and acted like that understanding mattered.
Founders should be especially careful not to confuse model capability with company maturity. A startup can access frontier-level capabilities through APIs, fine-tuning, orchestration layers, open-weight models, and third-party tooling long before it has the governance maturity of a company that truly understands what it has built. HB 4668 is a reminder that the law’s attention is shifting toward the consequences of capability, not merely the glamour of invention. If your company’s product can materially expand attack surfaces, reduce meaningful human control, or create plausible pathways to extreme misuse, then governance is not overhead. It is part of the product. ²³⁵
The best way to summarize HB 4668 for founders is this: the bill treats AI risk management as an evidentiary discipline. It is not enough to have good intentions, strong engineers, or a sincere commitment to responsible innovation. In the world this bill anticipates, a company must be able to show its work. It must show how it defined intolerable risk, how it tested for it, how it decided to deploy, how it secured access, how it responded to warnings, how it documented dissent, and how it corrected course when necessary. ²³ For founders in Michigan, that is the real checklist. It is a checklist written not in bullet points, but in governance habits that will either protect the company later or expose it.
If HB 4668 eventually becomes law in some amended form, the companies that fare best will not be the ones that begin scrambling on the effective date. They will be the companies that already built a credible record of thoughtful AI governance before the law forced them to. And if the bill does not pass in its current form, the lesson remains the same. State lawmakers, policy analysts, and standards bodies are all moving toward a world in which powerful AI systems are expected to be governed with traceable rigor rather than aspiration alone. ¹²³⁵ Michigan founders should plan accordingly.
Contact Tishkoff
Tishkoff PLC specializes in business law and litigation. For inquiries, contact us at www.tish.law/contact/. & check out Tishkoff PLC’s Website (www.Tish.Law/), eBooks (www.Tish.Law/e-books), Blogs (www.Tish.Law/blog) and References (www.Tish.Law/resources).
Footnoted Sources
1. Michigan Legislature, House Bill 4668 of 2025, bill status and legislative history, showing introduction on June 24, 2025, and later referral to the House Committee on Regulatory Reform on September 18, 2025. https://legislature.mi.gov/Bills/Bill?ObjectName=2025-HB-4668
2. Michigan House Bill No. 4668, introduced text of the Artificial Intelligence Safety and Security Transparency Act, including definitions of critical risk, large developer, safety and security protocol requirements, transparency reports, audit requirements, whistleblower protections, and attorney general enforcement. www.legislature.mi.gov/documents/2025-2026/billintroduced/House/pdf/2025-HIB-4668.pdf
3. Michigan House Fiscal Agency, Legislative Analysis, Artificial Intelligence Safety and Security Transparency Act, Summary as Introduced, June 25, 2025. https://legislature.mi.gov/documents/2025-2026/billanalysis/House/pdf/2025-HLA-4668-90TQ
4. Michigan Compiled Laws, The Whistleblowers’ Protection Act, Act 469 of 1980, MCL 15.361 et seq. https://law.justia.com/codes/michigan/chapter-15/statute-act-469-of-1980/#:~:text=AN%20ACT%20to%20provide%20protection,to%20prescribe%20remedies%20and%20penalties.
5. National Institute of Standards and Technology, AI Risk Management Framework, including AI RMF 1.0 and the Generative Artificial Intelligence Profile. https://www.nist.gov/itl/ai-risk-management-framework