By Tishkoff PLC, Ann Arbor, Michigan
From Ann Arbor to Detroit to Grand Rapids, Michigan’s technology economy increasingly runs on artificial intelligence. Startups are building generative tools; automakers and suppliers are integrating perception and planning models; hospitals and fintech’s are experimenting with decision support and anomaly detection. Into that moment steps House Bill 4668, the proposed Artificial Intelligence Safety and Security Transparency Act, which aims to put guardrails around the development and deployment of advanced “foundation models.” Although the bill is still moving through committee and could change before any final vote, its core structure already signals a notable shift: if you build large, general-purpose AI in Michigan or deploy such systems at scale the state wants you to formalize your risk management, document it publicly, and submit to third-party oversight.
Please note this blog post should be used for learning and illustrative purposes. It is not a substitute for consultation with an attorney with expertise in this area. If you have questions about a specific legal issue, we always recommend that you consult an attorney to discuss the particulars of your case.
This article unpacks what HB 4668 currently requires, where the thresholds sit, how “critical risk” is defined, what recurring transparency and audit obligations would look like, and how a practical compliance program might operate for both software companies and AI model developers. We also situate the proposal within the broader debate unfolding in Lansing and among Michigan’s business community. Our goal is not to litigate whether the bill is good or bad policy, but to give AI businesses an actionable picture of what to prepare for if some version of HB 4668 becomes law.
HB 4668 is tightly focused on “large developers” of “foundation models,” terms that are defined with unusual specificity for state legislation. A foundation model is an artificial intelligence model trained on a broad dataset, designed for general outputs, and adaptable to a wide range of tasks think systems that can be fine-tuned, tool-used, or integrated into downstream applications across domains. The “large developer” definition uses economic proxies rather than parameter counts or FLOP thresholds, anchoring coverage to the cost of compute. A company would be covered if it has developed at least one foundation model whose training compute cost is no less than five million dollars, and if within the previous twelve months it has developed one or more foundation models whose total compute cost is at least one hundred million dollars, measured against prevailing U.S. cloud prices when the compute was consumed. The effect is to capture the small number of organizations capable of training cutting-edge models while sparing most small and midsize developers who rely on fine-tuning or API consumption.
The bill also sets an effective date for the main obligations. As currently drafted, beginning January 1, 2026, covered companies must produce, implement, follow, and conspicuously publish a safety and security protocol; they must update and republish any material changes within thirty days; and they must publish recurring transparency reports. These timing provisions matter because they create a clear horizon for program design and resource allocation, even though the bill’s passage and final contours remain uncertain.
Regulatory schemes live or die on their scoping terms, and HB 4668’s is “critical risk.” The bill defines it as a foreseeable and material risk that a large developer’s development, storage, or deployment of a foundation model will result in death or serious injury to more than one hundred people or will cause over one billion dollars in damage to rights in money or property. It then lists illustrative incident types: the creation and release of chemical, biological, radiological, or nuclear weapons; cyberattacks conducted by or assisted by a foundation model; and conduct by a model that, with limited human intervention, would meet intent, recklessness, or gross-negligence standards if committed by a person, including solicitation or aiding and abetting. The definition also sweeps in harms inflicted by intervening human actors when the developer’s activities made the harm substantially easier or more likely. This definition is intentionally high stakes and catastrophic in scope, signaling that the bill targets the worst case, system level risks often described in frontier-model debates rather than routine product defects or consumer harms.
The bill’s centerpiece is a written safety and security protocol that must be produced, followed, and published by every covered developer. The protocol is not meant to be an empty policy document. It must concretely explain the developer’s testing and assessment procedures for critical risks, its thresholds for what is intolerable, and the decision framework it uses to determine whether and how to deploy a model when deployment poses critical risks. It must also detail physical, digital, and organizational safeguards designed to prevent insider or third-party access to models in ways that could create critical risks, and it must describe how the developer will respond if such a risk materializes or becomes imminent. In short, the protocol functions like a combined risk methodology, secure-by-design plan, deployment gate, incident response playbook, and disclosure framework.
One distinctive feature is the requirement to explain how the developer will exclude low risk models from coverage under the protocol, a nod to proportionality that acknowledges not every research artifact, or internal prototype needs the same treatment. Another notable element is a transparency-minded requirement to specify which parts of the protocol provide enough scientific detail to enable independent assessment of methods and evidence, and to identify the experts to whom any unredacted versions are made available. Together, those provisions encourage a culture where at least some risk-assessment detail leaves the black box of internal memos and reaches qualified external reviewers.
Because the bill requires public posting of the protocol and recurring reports on a prominent page of the developer’s website, companies naturally worry about trade secrets, model safety operational security, and national security-sensitive details. HB 4668 anticipates that tension by allowing redactions when reasonably necessary to protect trade secrets, public safety, or national security, or to comply with law. At the same time, it obligates the developer to retain unredacted versions for at least five years and to give the Attorney General access on request, while describing the character and justification of any redactions in the published documents. That balance pushes companies to share enough structure and outcome data to support accountability while limiting the disclosure of exploit-enabling technical detail.
Beyond the baseline protocol, HB 4668 demands a drumbeat of visibility. At least every ninety days, a large developer must publish a transparency report covering a window from 120 days before publication to 30 days before publication. These reports must summarize risk assessment conclusions, provide capability assessments by critical risk type for the highest-risk foundation model in the portfolio, and, when a newly deployed or modified model would pose a higher level of critical risk than any existing deployed model, explain the grounds and process for the deployment decision and the safeguards implemented. Developers must also record and retain for five years specific tests used and results obtained during critical-risk assessments with enough detail for qualified third parties to replicate the testing. The retention requirement is especially consequential for engineering teams, as it implies durable, version-controlled experiment records; auditable evaluation pipelines; and a robust chain of custody for artifacts.
In recognition that public transparency works only if documents are reliable, the bill prohibits knowingly false or materially misleading statements or omissions in protocol documents and transparency reports. That is more than a moral exhortation; it creates a compliance exposure akin to a securities-style anti-fraud obligation. Combined with the Attorney General’s inspection right and the audit regime, this provision raises the stakes for haphazard or aspirational policies that are not actually implemented on the ground.
Perhaps the most debated feature is the annual third-party audit. Beginning January 1, 2026, covered companies must retain a “reputable” independent auditor to assess whether the developer complied with its own safety and security protocol, to flag ambiguous protocol provisions that frustrate compliance determinations, and to identify any violations of the publication and redaction rules. The developer must provide access to all materials produced to comply with the act and other reasonably necessary materials, and the auditor must staff the engagement with both corporate-compliance expertise and technical expertise in the safety of foundation models. An audit report must be published within ninety days of completion. In practical terms, this will professionalize a nascent model-audit market and will force companies to engineer their safety and security controls to be evidence-generating and auditor-legible, not merely well-intentioned.
Business groups have already warned that audit requirements may outpace the emergence of accredited standards, which could raise costs or lead to inconsistent expectations. Those concerns, coupled with calls for a federal approach to avoid a fifty-state patchwork, are part of the political context in which the bill will live or die. But for companies contemplating compliance, the prudent move is to assume that some version of external assurance will be required and to start organizing safety-relevant evidence accordingly.
HB 4668 adds a layer of organizational accountability through whistleblower protections tailored to critical risk. Covered employers may not retaliate against employees who report information to an appropriate authority indicating that the company’s activities pose a critical risk, unless the employee knows the report is false. Employees may bring civil actions within ninety days, with remedies that include injunctive relief, damages, fees, and potential reinstatement and back pay. The bill further requires companies to post notices about these protections, to maintain an anonymous internal disclosure mechanism, and to provide monthly status updates to the disclosing employee, retaining the records for seven years and sharing them quarterly with disinterested officers and directors. Although the civil fine specified for violations of this section is nominal, the litigation exposure and the governance requirements are not, and they will affect how safety concerns are escalated and tracked within engineering organizations.
As of this writing, HB 4668 has moved out of House Judiciary with a recommendation for referral to the Communications and Technology Committee, and debate in Lansing remains active. The Michigan Advance has covered testimony voicing both urgency about catastrophic misuse and skepticism about implementation details, while tracking related bills aimed at AI misuse more broadly. The legislative record underscores that the proposal is evolving and that significant amendments are possible as it advances. For planning purposes, however, the published bill text and the House Fiscal Agency analysis provide the most concrete picture of what compliance would entail if the core framework survives.
For a Michigan company that trains or significantly modifies large, general-purpose models, compliance under HB 4668 would feel less like a one-time certification and more like building an ongoing safety management system.
At the program level, the first order of business is scoping. The company would need to map which models meet the “foundation model” definition and determine whether its training activities cross the compute-cost thresholds that trigger “large developer” status. That may require new internal accounting to estimate true training computes spent in dollar terms for each project and over rolling twelve-month windows. Engineering, finance, and procurement would need a shared rubric for what qualifies as “compute cost” under prevailing market prices and how to treat spot discounts, reserved instances, or on-prem equivalents. By tying applicability to compute cost rather than model size, the bill makes this financial scoping step foundational to compliance.
Once scoping is in hand, the company would build or adapt a model-safety risk framework centered on “critical risk” scenarios. That framework would likely inventory pathways by which a model could assist the creation or dissemination of weapons, enable or scale cyberattacks, or act with limited human intervention in ways that meet criminal-law standards. This is not the same as conventional information-security threat modeling or consumer-protection risk assessment. It asks highly technical teams to consider misuse and capability escalations, to test for dangerous affordances, and to reason about how fine-tuning, tool access, or increased compute at inference could change the risk surface. The protocol must explicitly contemplate the possibility that a foundation model could evade developer or user control, be misused or modified, or be used to create another model so the assessment must cover dual-use and proliferation risks, not just immediate outputs.
Testing and evaluation then become the engine of compliance. Because the law expects developers to retain “specific tests used and results obtained” with enough detail for replication, evaluation pipelines need to move from ad hoc notebooks to traceable experiment management. For critical-risk areas, companies will need curated red-team datasets, scenario-based evaluations that probe dangerous capabilities across the model lifecycle, and clearly documented thresholds for intolerability with decision rules for what happens when a threshold is crossed. Those thresholds cannot live only in policy prose; they must be wired into deployment gates and monitored throughout model updates, capability unlocks, and access expansions. Over time, the transparency report cadence will force organizations to summarize this work quarterly, creating a feedback loop in which the process of writing the report improves the rigor of the underlying testing.
Security controls will also assume a dual mandate: protecting IP and protecting the public. The bill calls out physical, digital, and organizational security to prevent insiders or third parties from accessing models in ways that could create critical risks. That language implicates privileged access management for model weights and training corpora, code-signing and artifact integrity for inference systems, environment hardening for training clusters, and segregation of duties around model release and escalation pathways. For organizations whose data-science stacks were built for speed rather than controlled change management, the shift will be culturally significant. Security teams will need to partner with ML platform engineers to make safety-critical systems auditable and to capture artifacts an external auditor would expect to see.
Governance and decision-making structures will have to evolve alongside the technical work. The protocol must describe “the procedure the developer will use to determine whether and how to deploy a foundation model when doing so poses critical risks,” which implies documented, cross-functional deployment committees; escalation criteria for when to seek outside expertise; and explicit authority for safety vetoes when intolerable thresholds are in play. Those procedures will sit uncomfortably with traditional product-roadmap pressures, which is precisely the point the bill seeks to address. By putting the decision process on paper and then out in public, it aims to ensure that cutting corners on safety becomes reputationally and legally costly.
Transparency reporting will require its own muscle. The quarterly report must cover risk-assessment conclusions and capability assessments by critical-risk type, not just aggregate “safety scores.” Producing a credible narrative will require teams who can translate technical artifacts into plain-English explanations without glossing over caveats. Because redactions are permitted but must be justified, companies will need a repeatable redaction-review workflow that balances trade secrets and public safety. They will also need to plan for Attorney General inspection of unredacted documents, which means ensuring those files are complete, precise, and stored with appropriate legal holds.
The external audit requirement will reshape internal documentation habits. A reputable third-party auditor with both compliance and technical safety expertise will expect to see evidence of control design and operating effectiveness. That could include role-based access logs for model artifacts, change-management tickets for model releases and safety mitigations, red-team and eval runbooks with repeatable seed data, signoffs from risk committees that tie to the defined intolerability thresholds, and proof that transparency reports match underlying records. Companies that treat the first audit as a gap-assessment opportunity rather than a pass/fail exam will be able to mature their systems and their credibility over several cycles.
Finally, whistleblower protections and required internal disclosure channels mean legal, and HR teams must collaborate with engineering leadership. Anonymous reporting must be truly anonymous, monthly updates to the reporter must be tracked, and the system must route concerns to disinterested officers and directors on a quarterly basis. If a company already operates an ethics hotline or compliance portal, it should be adapted to specifically flag “critical risk” reports and to integrate with model-safety incident response. For startups without such infrastructure, now is the time to build it before a rushed rollout under deadline.
Not every Michigan software business will cross the compute thresholds and become a “large developer.” Many teams consume third-party APIs or fine-tune vendor models with domain data, and some train smaller open-source models for targeted use cases. For those organizations, HB 4668 does not directly impose the protocol, reporting, or audit requirements. But the bill’s logic will likely cascade through contractual and market expectations. If major providers publish quarterly safety reports and enumerate safeguards, enterprise customers will start asking downstream integrators to evidence their own misuse mitigations and security practices. If auditors begin to formalize model-safety assurance methods at the frontier, those methods will drift into SOC-style questionnaires and vendor-risk programs. The prudent mid-market company will therefore adopt scaled versions of the same disciplines: document how the chosen models could be misused in your context; set and enforce internal deployment gates; monitor capability changes over time, especially as providers ship new tool use or context-length features; and maintain a concise safety memo that explains controls to customers and regulators if asked. That approach positions you to comply with contractual flow-downs and to answer board-level questions about AI risk even if the statute never applies directly.
Much of the compliance lift under HB 4668 will be determined by standard-setting, market practice, and the maturing craft of AI safety engineering. The bill requires the protocol to specify which portions contain enough scientific detail for independent assessment and to which experts unredacted versions are made available. That raises practical questions about who those experts are, what independence means in a still-forming field, and how competing developers avoid disclosing exploit-enabling detail while satisfying an external reviewer’s curiosity. The annual audit will similarly need scaffolding methodologies, competencies, and independence rules lest it devolve into a box-checking exercise. Business groups have already urged lawmakers to avoid creating a state-by-state patchwork that outpaces federal standard-setting; in response, developers should track both Lansing’s text and federal activity to design controls that generalize.
There are also engineering tradeoffs. Publishing any discussion of critical-risk capabilities invites adversarial learning by bad actors; redaction can blunt that risk but invites skepticism about the completeness of disclosure. Deep mitigations like weight watermarking, inference-time guardrails, and capability segmentation may reduce misuse but also complicate auditor replication and stress test design. Governance constructs, too, come with cultural costs: strong deployment gates and safety vetoes may add weeks to a release schedule. The organizations that thrive will be those that treat these frictions as design constraints, building platforms that make safe defaults easy and risky moves visible.
If you expect to cross the compute thresholds in the next eighteen months, the most sensible move is to build a safety and security protocol now, then iterate. Begin by establishing a cross-functional safety council with representation from ML engineering, security, product, legal, and operations. Have that council write the first version of your protocol clearly identifying your intolerability thresholds, decision gates, and incident response roles and test it against a real model release. Use that exercise to map what evaluation assets you need to collect and retain for five years. Start a quarterly safety report, even if you do not publish it yet; the practice will uncover gaps in your evidence and help you calibrate what level of detail you can make public without compromising trade secrets or public safety. Develop a vendor-neutral way to estimate compute cost for training runs so you know when you cross the bill’s thresholds. And stand up the internal whistleblower channel now, complete with monthly-update workflows and board-level reporting, so you can demonstrate good faith should the law pass in something like its current form.
For companies that do not meet the thresholds, this is still a moment to professionalize AI risk management. Your customers will take notice if your documentation reads like a thoughtful, scaled-down version of what HB 4668 would require of the giants. That stance not only reduces operational risk, it becomes a commercial advantage in enterprise sales cycles where AI governance is now a top five diligence topic.
House Bill 4668 attempts to thread the needle between innovation and catastrophe-prevention by regulating the small group of developers capable of training the most powerful general-purpose systems, then using transparency and audits to make their safety practices legible. It defines “critical risk” in catastrophic terms, sets compute-based thresholds to identify who is covered, and creates a continuous cycle of protocol design, reporting, and independent assurance. Whether the bill passes as written, is amended, or becomes a template for future efforts, the direction is clear: if you build or deploy frontier-scale AI in Michigan, the era of informal safety practices is ending, and the expectation of documented, externally reviewable controls is beginning. For the state’s AI businesses, the winners will be those who integrate safety engineering into their development pipelines with the same seriousness they bring to security and reliability.
About Tishkoff PLC
Tishkoff PLC is a business and litigation law firm based in Ann Arbor, Michigan. Our technology and commercial teams advise startups and established companies on contracts, regulatory strategy, risk management, and dispute resolution. If you’re building with AI and want to understand how emerging legislation like HB 4668 might affect your roadmap, governance, or partnership terms, we’re here to help.
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).
Sources:
- Michigan Legislature — “House Bill 4668 (2025): Artificial Intelligence Safety and Security Transparency Act,” bill text and status, introduced June 24, 2025. https://www.legislature.mi.gov/Bills/Bill?ObjectName=2025-HB-4668
- Michigan House Fiscal Agency — “Legislative Analysis: HB 4668 (Artificial Intelligence Safety and Security Transparency Act), complete to June 23, 2025.” https://www.legislature.mi.gov/Bills/Bill?ObjectName=2025-HB-4668
- Michigan Advance — “Michigan lawmakers consider AI safeguard bills to prevent technology from committing harm,” June 25, 2025. https://michiganadvance.com/2025/06/25/michigan-lawmakers-consider-ai-safeguard-bills-to-prevent-technology-from-committing-harm/
- Michigan Chamber of Commerce — “House panel considers sweeping bill to regulate AI,” Advocacy Update, September 11, 2025. https://www.michamber.com/news/house-panel-considers-sweeping-bill-to-regulate-ai/
- LegiScan — “MI HB 4668 (2025) — Summary and Status Overview,” 2025 session. https://legiscan.com/MI/text/HB4668/id/3258161
Citations used in this article: Michigan Legislature HB 4668 bill page; House Fiscal Agency analysis; HB 4668 introduced text (PDF); Michigan Advance coverage; LegiScan status; and Michigan Chamber commentary.
This publication is for general informational purposes and does not constitute legal advice. Reading it does not create an attorney-client relationship. You should consult counsel for advice on your specific circumstances.