Artificial intelligence is rapidly moving from an experimental business tool to an essential component of commercial operations. Michigan companies now use artificial intelligence to review contracts, communicate with customers, evaluate job applicants, forecast demand, monitor manufacturing equipment, detect fraud, design products, generate software code, and automate decisions that were previously made by employees. As these systems become more capable and autonomous, lawmakers are beginning to focus not merely on how artificial intelligence affects individual consumers, but also on whether the development and deployment of advanced models could create risks to cybersecurity, public safety, critical infrastructure, and the broader economy.
Michigan House Bill 4668, introduced as the Artificial Intelligence Safety and Security Transparency Act, represents one attempt to establish a formal governance framework for the most powerful artificial intelligence models. As of July 16, 2026, the bill remains pending and has not been enacted. The Michigan Legislature’s most recent recorded action occurred on March 19, 2026, when the bill was re-referred to the House Committee on Communications and
Technology. ¹ Consequently, Michigan businesses are not presently required to comply with House Bill 4668 merely because it was introduced.
Nevertheless, the proposal deserves careful attention. House Bill 4668 illustrates the type of documented risk management, transparency, testing, auditing, security, and whistleblower protections that lawmakers may increasingly expect from developers of advanced artificial intelligence. Similar concepts are already appearing in enacted legislation, international standards, government guidance, procurement requirements, insurance questionnaires, investor diligence, and contracts between artificial intelligence providers and their enterprise customers.
For Michigan businesses, the correct approach is not to assume that House Bill 4668 will necessarily become law in its introduced form. Nor should companies wait until a final statute takes effect before creating an artificial intelligence governance program. A business can prepare for emerging legislation without committing itself to every detail of a pending bill. The most effective strategy is to establish a flexible compliance system that can be adjusted as definitions, thresholds, reporting deadlines, and enforcement provisions develop.
House Bill 4668 is directed primarily at entities that develop expensive, general-purpose foundation models rather than ordinary businesses that merely license commercially available artificial intelligence tools. The introduced bill defines a foundation model as an artificial intelligence model that is trained on a broad dataset, designed for generality of output, and adaptable to a wide range of distinctive tasks. ² This definition is intended to distinguish broadly capable models from narrower systems designed to perform a specific function.
The proposed law would apply to a “large developer.” Under the introduced language, an organization would qualify as a large developer only if it developed both a foundation model for which the computing power cost at least $5 million and, during the immediately preceding twelve months, one or more foundation models for which the aggregate computing power cost at least $100 million. ² These are substantial thresholds. Most Michigan manufacturers, professional firms, retailers, health care organizations, financial institutions, and technology startups would not satisfy them merely by purchasing subscriptions to external artificial intelligence services.
The threshold analysis may nevertheless become complicated for companies developing proprietary models, fine-tuning open models, operating through affiliated entities, or combining their technology with models developed by other organizations. The introduced bill does not comprehensively answer every question that could arise concerning affiliated companies, shared infrastructure, valuation of internal computing resources, or the distinction between developing, modifying, and deploying a model. Those issues may be clarified through amendments, administrative interpretation, enforcement actions, or later legislation.
Businesses should therefore avoid relying on labels such as “software company,” “user,” “vendor,” or “startup” without examining what the organization actually does. A company that begins as a user of an external model can gradually become a developer by fine-tuning the model, adding proprietary layers, creating autonomous capabilities, or providing the resulting system to customers. The relevant analysis should consider the company’s technical activities, contractual rights, access to model weights, computing expenditures, and role in determining how the model operates.
House Bill 4668 does not attempt to regulate every inaccurate response, biased recommendation, privacy violation, or employment decision involving artificial intelligence. Its central concept is “critical risk,” which the bill defines as a foreseeable and material risk that the development, storage, or deployment of a foundation model will cause death or serious injury to more than one hundred people or more than $1 billion in damage to rights in money or property through certain specified incidents. ²
The listed incidents include the creation and release of chemical, biological, radiological, or nuclear weapons, cyberattacks conducted or assisted by a foundation model, and certain criminal conduct performed by a model with limited human intervention. The definition can also encompass harm inflicted by an intervening person when the developer’s activities made the harm substantially easier or more likely.
This focus places House Bill 4668 within an emerging category of frontier-model safety legislation. Rather than regulating routine commercial uses of artificial intelligence, these proposals address models whose capabilities could materially amplify cyber operations, weapons development, autonomous misconduct, or other large-scale harms.
The narrow definition of critical risk does not mean that other artificial intelligence risks can be ignored. A business may remain exposed under consumer-protection laws, privacy laws, employment laws, civil-rights laws, contract principles, negligence theories, intellectual-property law, professional obligations, or sector-specific regulations even when its technology presents no catastrophic risk. A sound governance program should therefore treat House Bill 4668 as one component of a larger legal and operational framework.
The primary obligation contemplated by House Bill 4668 is the creation and implementation of a written safety and security protocol. The protocol would not be a general statement that the developer takes safety seriously. It would need to describe the developer’s actual technical and organizational procedures for identifying, evaluating, reducing, and responding to critical risks.
The proposed protocol would have to explain how the developer determines that certain models present only limited critical risk and therefore may be excluded from particular requirements. It would identify the thresholds at which risks become intolerable, explain the basis for those thresholds, and describe what the developer will do when a threshold is exceeded. ² This would effectively require the developer to define in advance the circumstances under which a model may not be released, may require additional safeguards, or must be withdrawn or restricted.
The protocol would also describe testing and assessment procedures. Those procedures would need to consider not only the model’s operation under normal conditions, but also the possibility that the model could evade developer or user controls, be misused, be modified, be operated with greater computing resources, or be used to create another model. ² This language reflects an important principle of artificial intelligence safety: testing a model only for its intended use is insufficient when foreseeable misuse, circumvention, modification, or scaling may materially change the risk.
Physical, digital, and organizational security would also form part of the protocol. The developer would be expected to protect models from unauthorized access by insiders and third parties when such access could create a critical risk. The protocol would describe safeguards, risk-mitigation measures, incident-response procedures, reassessment triggers, reporting conditions, and the circumstances under which the protocol itself must be modified.
The introduced bill additionally contemplates a role for independent assessment. A developer would identify which portions of its protocol provide enough scientific detail to permit experts to evaluate its methodology, evidence, and analysis. It would also describe any role performed by a financially disinterested third party.
For businesses preparing now, the key lesson is that a policy document cannot be separated from operational reality. A company should not publish a detailed artificial intelligence safety policy unless its personnel, systems, records, and decision-making practices can support the representations in that policy. A protocol that describes controls the company does not consistently follow could become more damaging than having no public protocol at all.
The introduced version of House Bill 4668 would require a covered developer to conspicuously publish its safety and security protocol and to publish material modifications within thirty days. It would also require a transparency report at least once every ninety days. ² The report would address conclusions reached through risk assessments, changes in model capabilities, decisions to deploy models presenting higher levels of critical risk, and safeguards used to mitigate those risks.
The bill states that a developer could not knowingly make false or materially misleading statements or omissions in documents produced under the proposed act. ² This language would make the preparation of transparency reports a legal and compliance function rather than an assignment that should be delegated exclusively to marketing or public-relations personnel.
Public artificial intelligence disclosures should be supported by documented evidence. When a company claims that it tested a model, implemented a safeguard, restricted access, or responded to identified risks, it should be able to produce records showing what was tested, who conducted the work, which version of the model was evaluated, what standards were applied, what limitations were identified, and how decision-makers responded.
House Bill 4668 recognizes that transparency must be balanced against legitimate confidentiality and security concerns. The introduced bill would permit redactions reasonably necessary to protect trade secrets, public safety, national security, or compliance with other laws. The developer would still have to retain an unredacted version for at least five years, permit the Michigan Attorney General to inspect it upon request, and describe the character and justification of its redactions in the public version. ²
This proposed structure should inform how companies manage disclosure today. A business should establish a review process involving technical personnel, information-security professionals, legal counsel, and appropriate business leaders before publishing artificial intelligence safety claims. The process should identify statements that could reveal vulnerabilities, proprietary methods, protected personal information, confidential customer information, or security-sensitive data. At the same time, confidentiality should not become a justification for vague or misleading public statements.
House Bill 4668 would require large developers to record and retain for five years the specific tests used and the results obtained during critical-risk assessments. The records would need to contain sufficient detail for qualified third parties to replicate the testing. ²
Reproducibility is particularly challenging in artificial intelligence because model outputs may vary based on model version, system instructions, prompts, temperature settings, tool access, retrieval sources, permissions, external data, and other configuration choices. A result obtained from one version of a model may not be reproducible after the model, surrounding software, or underlying data changes.
An audit-ready testing program should therefore preserve more than a summary conclusion. The record should identify the model and version, testing date, personnel involved, purpose of the test, test environment, configuration settings, prompts or evaluation datasets, scoring criteria, results, exceptions, and subsequent remediation. When tests involve sensitive cybersecurity or weapons-related capabilities, the company should impose strict access controls and appropriate handling restrictions.
The National Institute of Standards and Technology’s Artificial Intelligence Risk Management Framework provides a useful structure for organizing this work. The framework centers on the functions of governing, mapping, measuring, and managing artificial intelligence risk. ³ The NIST Generative Artificial Intelligence Profile supplements that framework by identifying risks and suggested actions that are particularly relevant to generative systems.⁴ Although these resources are voluntary, their terminology can help businesses create a defensible and repeatable assessment process.
The introduced bill would require a large developer to retain a reputable third-party auditor at least once each year. The auditor would assess whether the developer complied with its safety and security protocol, identify instances of noncompliance, determine whether provisions of the protocol were too unclear to evaluate, and examine potential violations of the transparency and recordkeeping requirements. ² The developer would generally be required to publish the audit report within ninety days after completion.
The auditor would need access to the materials produced to comply with the act and any other materials reasonably necessary to conduct the assessment. The audit team would have to include expertise in both corporate compliance and the technical safety of foundation models. ² This multidisciplinary requirement reflects the reality that artificial intelligence governance cannot be evaluated solely as a software-engineering issue or solely as a legal issue.
Businesses should begin developing an audit trail before an audit is required. Auditors cannot reliably reconstruct governance decisions when testing records, approvals, model inventories, incident reports, access logs, and policy revisions were not preserved when the underlying events occurred.
Companies should also consider auditor independence. The same vendor that designed a safety program, selected testing criteria, or implemented controls may not be viewed as fully disinterested when later asked to evaluate those decisions. Although the final requirements of any Michigan law may differ, separating implementation assistance from independent assurance can strengthen the credibility of the process.
House Bill 4668 would prohibit a large developer from discharging, threatening, or discriminating against an employee because the employee reports or is about to report information indicating that the developer’s activities pose a critical risk to an appropriate state or federal authority, unless the employee knows the report is false. ² The proposed definition of employee includes certain contractors, subcontractors, unpaid advisors, and corporate officers involved in assessing, managing, or addressing critical risks.
An employee alleging retaliation could bring a civil action within ninety days after the alleged violation. Potential relief would include an injunction, actual damages, reasonable attorney fees, witness fees, court costs, reinstatement, back wages, fringe benefits, seniority rights, and other relief deemed appropriate by the court. ² The bill would not displace protections otherwise available under Michigan’s Whistleblowers’ Protection Act or collective-bargaining agreements.
The proposed act would also require an internal process through which employees could anonymously report information they believe in good faith indicates a critical risk. The developer would have to provide monthly updates concerning the status of the investigation and actions taken. Disclosures and updates would be retained for seven years and shared at least quarterly with officers and directors who did not have a conflict of interest. ²
These provisions demonstrate why human-resources personnel must be integrated into artificial intelligence governance. A technically sophisticated safety program can fail if employees fear retaliation, do not know where to report concerns, or believe that management will disregard uncomfortable findings.
Companies preparing for emerging regulation should adopt a clear reporting channel, define escalation procedures, protect the identity of reporters to the extent reasonably possible, document investigations, and monitor later employment decisions affecting reporting employees. Managers should be trained that retaliation can include more than termination. Threats, exclusion from projects, changes in assignments, reduced opportunities, unfavorable evaluations, or other adverse treatment may create legal and evidentiary problems.
Internal reporting systems should also distinguish good-faith disagreement from misconduct. Artificial intelligence risk assessments frequently involve uncertainty and competing professional judgments. Employees should be able to raise concerns, challenge testing assumptions, and recommend additional safeguards without being treated as disloyal.
Under the introduced bill, the Michigan Attorney General could bring a civil action for violations of the safety protocol, transparency, recordkeeping, or audit requirements and seek a civil fine of up to $1 million per violation, injunctive relief, declaratory relief, or a combination of those remedies. ² In determining the appropriate relief, a court could consider the severity of the violation and whether the violation caused or could have caused a critical risk to materialize. The Attorney General could also seek injunctive relief when a large developer’s activities present an imminent critical risk.
The phrase “per violation” could become especially significant if multiple reports, models, testing failures, misleading statements, or periods of noncompliance are treated as separate violations. The proposed statute does not resolve every question concerning how violations would be counted. Businesses should not assume that the maximum exposure would be limited to a single $1 million penalty.
Enforcement risk could also extend beyond the proposed statute. A public safety protocol, audit report, customer certification, or investor representation may become evidence in litigation concerning negligence, breach of contract, fraud, securities disclosures, insurance coverage, or corporate oversight. A company’s internal documents may be compared with its public statements to determine whether it recognized risks that it failed to disclose or address.
Most Michigan companies will not meet House Bill 4668’s proposed definition of a large developer. That does not make artificial intelligence governance irrelevant to them.
Enterprise customers increasingly request information concerning model security, training data, privacy, intellectual property, bias testing, incident response, subcontractors, and regulatory compliance. Insurers may examine artificial intelligence controls when underwriting cyber, technology-errors-and-omissions, directors-and-officers, or professional-liability coverage. Investors and lenders may consider whether a company’s artificial intelligence practices create undisclosed liabilities. Government and health care contracts may impose obligations that are more demanding than generally applicable law.
A company using an external model may also assume contractual responsibilities to its customers. For example, a software provider may represent that its artificial intelligence features are secure, monitored, tested, explainable, or compliant with applicable law even though the underlying model is provided by another company. The software provider remains responsible for the accuracy of its own contractual promises.
The regulatory trend also suggests that today’s voluntary practices may become tomorrow’s baseline. California enacted the Transparency in Frontier Artificial Intelligence Act in 2025, establishing safety-transparency and related requirements for certain large frontier-model developers. ¹⁰ The European Union’s Artificial Intelligence Act establishes a broader risk-based system addressing prohibited uses, high-risk systems, transparency, and general-purpose artificial intelligence models.⁹ Although these laws differ from House Bill 4668, they reflect a common movement toward documented governance, risk assessment, transparency, security, and accountability.
The first step in preparing for artificial intelligence regulation is identifying where artificial intelligence exists within the organization. Many companies cannot produce a complete inventory because departments obtain tools independently, employees use public services without formal approval, vendors add artificial intelligence features to existing products, and software updates activate new capabilities.
An inventory should identify each artificial intelligence system, its owner, provider, purpose, users, affected individuals, data inputs, outputs, integrations, decision-making role, geographic reach, contractual restrictions, and risk classification. It should indicate whether the company developed the system, modified an external model, fine-tuned a model, or merely accesses a hosted service.
The inventory should also distinguish systems that generate recommendations from systems authorized to take action. An application that drafts an internal memorandum presents different risks from an agent that can access customer accounts, alter production settings, initiate payments, send external communications, or execute software code.
The inventory must be maintained as a continuing process rather than a one-time spreadsheet. Procurement, information technology, security, legal, human resources, and operating departments should be required to report new uses and material modifications. Unapproved tools should be addressed through realistic controls and employee education rather than policies that are impossible to enforce.
Artificial intelligence risk cannot be assigned exclusively to the information-technology department. Responsibility should be distributed among personnel with appropriate legal, technical, security, privacy, human-resources, compliance, and business expertise.
The organization should identify a senior executive or committee responsible for artificial intelligence governance. The governing body should approve risk tolerances, review high-risk deployments, receive significant incident reports, and ensure that identified concerns are addressed. The board of directors should receive information proportionate to the importance of artificial intelligence to the company’s operations and risk profile.
Decision-making authority should be documented. Employees should know who may approve a new system, who may suspend it, who determines whether testing is sufficient, who decides whether an incident must be reported, and who authorizes public disclosures. Emergency authority should be established before a crisis occurs.
The NIST Artificial Intelligence Risk Management Framework can provide the structure for this governance system. ³ ISO/IEC 42001:2023 offers another management-system approach for establishing, implementing, maintaining, and continually improving artificial intelligence governance.⁸ A company need not pursue formal certification to use the standard’s central concept: artificial intelligence risk should be managed through defined responsibilities, documented processes, internal review, corrective action, and continuous improvement.
House Bill 4668 would require covered developers to identify thresholds at which critical risks become intolerable and describe what happens when a threshold is crossed. ² Businesses can apply the same principle to other artificial intelligence risks.
The organization should define circumstances in which an artificial intelligence system may not be deployed, may be used only with additional safeguards, or may be used only under human supervision. Relevant considerations may include the sensitivity of the data, potential harm from an incorrect output, ability to reverse a decision, degree of autonomy, number of affected people, susceptibility to misuse, and availability of effective monitoring.
Deployment gates translate abstract policy into operational decisions. Before release, the responsible team should confirm that testing has been completed, identified risks have been addressed, required approvals have been obtained, documentation is sufficient, users have been trained, and incident-response procedures are in place.
Material modifications should trigger reassessment. A model may become riskier when connected to new data, provided with tools, allowed to execute actions, exposed to additional users, integrated into critical systems, or modified to improve its capabilities. The fact that an earlier version passed testing does not establish that the modified system remains safe.
Testing should reflect the system’s actual capabilities and foreseeable misuse. A company should evaluate not merely whether the system performs its intended function, but also how it behaves when users provide malicious instructions, attempt to bypass restrictions, submit corrupted data, seek confidential information, or induce the system to take actions outside its assigned role.
Testing should be proportionate to risk. Low-risk administrative tools may require basic evaluation and access controls. Systems affecting employment, credit, health care, legal rights, safety, financial transactions, or critical infrastructure require more demanding review.
Red-teaming can help identify ways in which a model or integrated system may be manipulated. Effective red-teaming should not be treated as an isolated demonstration designed to produce favorable results. It should use documented objectives, realistic scenarios, qualified personnel, reproducible methods, and a process for correcting identified weaknesses.
Post-deployment monitoring is equally important. Artificial intelligence behavior can change when users interact with the system in unexpected ways, data distributions shift, vendors update models, external tools change, or attackers develop new techniques. Monitoring should therefore examine incidents, user complaints, abnormal activity, failed safeguards, unexpected outputs, access patterns, and performance changes.
The NIST Generative Artificial Intelligence Profile provides a useful reference for identifying generative-model risks and possible risk-management actions.⁴ Companies should adapt those concepts to their particular technology rather than treating the framework as a checklist that automatically establishes compliance.
House Bill 4668 would require covered developers to address physical, digital, and organizational protections against unauthorized access to models when that access could create a critical risk. ² This obligation aligns with broader cybersecurity principles.
Artificial intelligence security begins with controlling access to model weights, source code, training data, evaluation data, prompts, system instructions, credentials, plugins, tools, and deployment infrastructure. Access should be limited according to job responsibilities, protected through strong authentication, logged, periodically reviewed, and promptly revoked when no longer necessary.
Developers should consider threats from both external attackers and insiders. Employees or contractors with privileged access may be able to copy models, alter safeguards, manipulate training data, expose confidential information, or conceal testing results. Segregation of duties, code review, approval requirements, monitoring, and protected reporting channels can reduce those risks.
The NIST Cybersecurity Framework 2.0 organizes cybersecurity outcomes around governance, identification, protection, detection, response, and recovery.⁵ These functions can be applied to artificial intelligence infrastructure. The Cybersecurity and Infrastructure Security Agency’s Guidelines for Secure AI System Development similarly encourage security throughout system design, development, deployment, and operation.⁶ CISA and its partners have also issued guidance addressing security for data used to train and operate artificial intelligence systems.⁷
Businesses should integrate artificial intelligence into existing cybersecurity and incident-response programs rather than creating an entirely separate security structure. At the same time, incident plans should account for risks that are distinctive to artificial intelligence, such as model theft, prompt injection, training-data poisoning, unsafe tool use, unauthorized fine-tuning, disclosure of system instructions, and manipulation of autonomous agents.
A compliance program is difficult to prove when decisions are undocumented. Companies should preserve model inventories, risk classifications, testing records, approvals, meeting materials, access reviews, incident reports, investigation files, policy versions, employee training, vendor diligence, and corrective actions.
Retention periods should be established deliberately. House Bill 4668 proposes five-year retention for certain testing and disclosure records and seven-year retention for internal whistleblower disclosures and updates. ² Even companies outside the bill’s scope may find those periods useful as planning benchmarks, subject to their existing retention policies and legal obligations.
Documentation should be accurate and understandable. Excessive technical detail can obscure the actual decision, while oversimplified summaries may omit important limitations. Records should identify what was known at the time, what assumptions were used, what uncertainty remained, who approved the decision, and what monitoring was required.
Legal counsel should assist in distinguishing ordinary business records from communications seeking legal advice. Merely copying an attorney does not automatically make an operational document privileged. Companies should not use privilege as a substitute for sound governance, and they should anticipate that many safety records may eventually be reviewed by regulators, auditors, customers, insurers, or litigants.
Most businesses obtain artificial intelligence technology through vendors. Vendor diligence should address the model provider, hosting arrangements, training-data practices, security controls, testing, subcontractors, incident history, regulatory obligations, and the provider’s ability to modify or discontinue the service.
Contracts should allocate responsibility for compliance, security, privacy, intellectual property, testing, documentation, incident notification, cooperation with investigations, and changes to the model. The customer should understand whether the provider may use customer information to train its models and whether the customer can prohibit or control that use.
Audit rights should be realistic. A contractual right to conduct an unlimited inspection may have little value when the provider will not permit access to sensitive systems or model weights. Alternatives may include independent audit reports, certifications, testing summaries, regulatory disclosures, or narrowly defined access to supporting records.
Indemnification and liability limitations should be evaluated in light of the actual risks. A broad limitation of liability may leave a customer with little recourse after a significant artificial intelligence incident. Conversely, an unlimited indemnity may be commercially unrealistic for a smaller provider. Insurance requirements should be coordinated with the scope of contractual responsibility.
Companies developing artificial intelligence products should also review their customer-facing statements. Sales personnel should not promise that a system is unbiased, error-free, fully secure, compliant with all laws, or capable of replacing professional judgment unless those statements can be substantiated.
Employees frequently determine whether an artificial intelligence governance program succeeds. Training should explain approved and prohibited uses, confidential-data restrictions, human-review requirements, incident reporting, documentation expectations, and the consequences of bypassing safeguards.
Managers should receive additional instruction concerning employee concerns and anti-retaliation obligations. Reports about artificial intelligence risk should be routed to personnel capable of evaluating both the technical issue and the employment implications.
Training should be role-specific. Software developers need guidance concerning secure design, testing, documentation, and escalation. Human-resources personnel need guidance concerning employment decisions and employee reporting. Sales and marketing personnel need guidance concerning public representations. Executives and directors need information sufficient to exercise meaningful oversight.
The objective is not to turn every employee into an artificial intelligence specialist. It is to ensure that employees understand the risks connected to their responsibilities and know when to seek assistance.
A company can begin with a focused assessment during the first thirty days. Management should identify the systems currently in use, designate responsibility for governance, prohibit the most clearly unacceptable practices, and determine which deployments present the highest legal, security, or operational risk.
During the following sixty to ninety days, the company should formalize its artificial intelligence policy, establish approval and escalation procedures, conduct risk assessments for priority systems, review vendor contracts, and create an incident-reporting process. Existing cybersecurity, privacy, records-retention, procurement, and whistleblower policies should be updated to address artificial intelligence where appropriate.
Over the next several months, the company should conduct testing, document deployment decisions, implement monitoring, train employees, and remediate weaknesses. Businesses developing advanced models should begin preparing the type of safety protocol, transparency records, reproducible testing documentation, and independent-audit materials contemplated by House Bill 4668.
The program should then move into continuing review. Artificial intelligence inventories should be updated, incidents should be analyzed, policies should be revised, model changes should be reassessed, and significant information should be presented to management and the board. The company should monitor legislative developments rather than assuming that the introduced version of House Bill 4668 will remain unchanged.
House Bill 4668 was introduced in June 2025 and states that certain obligations would begin on January 1, 2026.² That date has passed while the bill remains pending. Businesses should not interpret the expired date as creating a current legal obligation. Because the proposal was not enacted before January 1, 2026, lawmakers would likely need to reconsider its implementation schedule or address how the timing provisions would operate if the bill advances.
The outdated date also demonstrates the danger of building a compliance program around a single legislative draft. Definitions, thresholds, effective dates, enforcement authority, and disclosure obligations can change substantially during the legislative process.
A durable governance program should therefore be modular. The company should be able to adjust its scope, reporting schedule, retention periods, risk classifications, and approval requirements without rebuilding the program from the beginning.
Michigan House Bill 4668 is not yet law, and its requirements would apply directly only to a limited category of large foundation-model developers if enacted in its introduced form. Its broader significance lies in the regulatory model it presents.
Lawmakers, regulators, standards organizations, and commercial counterparties are converging on several expectations. Organizations should know which artificial intelligence systems they develop or use. They should assign responsibility for managing those systems. They should assess foreseeable risks before deployment, test safeguards, protect models and data, monitor performance, preserve records, respond to incidents, provide channels for employee concerns, and ensure that public statements are accurate.
The details will vary across Michigan legislation, federal guidance, California law, the European Union’s Artificial Intelligence Act, NIST frameworks, CISA guidance, and ISO standards. The underlying business discipline is remarkably consistent.
Companies that begin this work now will be better positioned to respond when customers request documentation, insurers evaluate risk, regulators ask questions, investors conduct diligence, or new laws take effect. They will also be more capable of using artificial intelligence productively because they will understand where the technology is operating, what risks it presents, and who is responsible for controlling those risks.
Preparing for artificial intelligence legislation is therefore not simply a defensive legal exercise. It is an opportunity to build a more reliable, secure, and commercially credible approach to artificial intelligence. Michigan businesses that establish that foundation now can adapt to future regulation without allowing each new statute, contractual demand, or technological development to become an organizational crisis.
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:
1- Michigan Legislature, House Bill 4668 of 2025, bill history and legislative status, 103rd Legislature, 2025–2026 Regular Session. https://legislature.mi.gov/Bills/Bill?ObjectName=2025-HB-4668
2- Michigan House of Representatives, House Bill No. 4668, Artificial Intelligence Safety and Security Transparency Act, introduced June 24, 2025. https://www.legislature.mi.gov/documents/2025-2026/billintroduced/House/pdf/2025-HIB-4668.pdf
3- National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1, January 2023. https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf
4- National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, July 2024. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
5- National Institute of Standards and Technology, The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29, February 2024. https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
6- Cybersecurity and Infrastructure Security Agency and United Kingdom National Cyber Security Centre, Guidelines for Secure AI System Development, November 2023. https://www.ncsc.gov.uk/collection/guidelines-secure-ai-system-development
7- Cybersecurity and Infrastructure Security Agency, National Security Agency, Federal Bureau of Investigation, and International Partners, AI Data Security: Best Practices for Securing Data Used to Train and Operate AI Systems, May 2025. https://media.defense.gov/2025/May/22/2003720601/-1/-1/0/CSI_AI_DATA_SECURITY.PDF
8- International Organization for Standardization and International Electrotechnical Commission, ISO/IEC 42001:2023, Information Technology—Artificial Intelligence—Management System, December 2023. https://www.iso.org/obp/ui/en/#iso:std:iso-iec:42001:ed-1:v1:en
9- European Parliament and Council of the European Union, Regulation (EU) 2024/1689 Laying Down Harmonised Rules on Artificial Intelligence, Artificial Intelligence Act, June 13, 2024. https://www.cambridge.org/core/journals/international-legal-materials/article/regulation-20241689-of-the-eur-parl-council-of-june-13-2024-eu-artificial-intelligence-act/64F1F6734F8C66CA3EEA149C9759194E
10- State of California, Office of Governor Gavin Newsom, Governor Newsom Signs Senate Bill 53, the Transparency in Frontier Artificial Intelligence Act, September 29, 2025. https://www.gov.ca.gov/2025/09/29/governor-newsom-signs-sb-53-advancing-californias-world-leading-artificial-intelligence-industry/