Artificial intelligence tools are moving into Southeast Michigan workplaces more quickly than many organizations can fully assess their legal, operational, and cybersecurity implications. Manufacturers are adopting predictive-maintenance platforms, automotive suppliers are testing AI-assisted quality controls, healthcare organizations are exploring automated documentation and patient communications, and professional firms are using generative AI to review records, prepare drafts, analyze information, and organize client materials. Employers are also considering software that screens applicants, evaluates performance, and supports personnel decisions.
This article is provided for educational and illustrative purposes. It is not a substitute for advice from an attorney familiar with the particular technology, industry, contract, and proposed use. Questions involving a specific transaction or legal issue should be evaluated based on the relevant facts and circumstances.
Many organizations acquire AI products through the same purchasing process used for ordinary software. A department identifies a promising tool, the vendor provides a demonstration, the company receives a standard subscription agreement, and approval follows after a review of price and implementation timing. That process may be adequate for stable software that performs predictable functions. It deserves closer scrutiny when the product analyzes sensitive company information, produces probabilistic results, relies on third-party models, changes over time, or influences decisions affecting employees, customers, patients, suppliers, or regulated activities.
An AI vendor agreement is more than a license to access technology. It allocates responsibility for inaccurate outputs, compromised data, intellectual-property disputes, regulatory inquiries, biased recommendations, security incidents, service changes, and business interruption. The language may decide whether the vendor must participate meaningfully when the system fails or whether the customer is left to absorb nearly every resulting expense and disruption.
Before signing, a Southeast Michigan business should evaluate whether the proposed agreement addresses the risks created by the product’s actual use. Relevant subjects commonly include the system’s intended function, measurable performance, data rights, model training, confidentiality, cybersecurity, legal compliance, audit access, indemnification, insurance, change management, and termination. The National Institute of Standards and Technology’s Artificial Intelligence Risk Management Framework explains that AI risk should be governed, measured, and managed throughout the system’s lifecycle, not evaluated only at the point of purchase. 1 A sound contract should support that continuing approach.
The first question is not whether the product is described as artificial intelligence. The first question is what the business expects the product to do, what information it will receive, and what consequences may follow from an error. A drafting assistant used only with public information creates a different risk profile from a system that receives privileged client files, recommends personnel decisions, controls manufacturing equipment, or communicates directly with patients or customers.
AI agreements often describe the service with broad phrases such as an AI-powered platform, machine-learning solution, or generative AI service. Those expressions may be effective marketing language, but they do not create a usable performance obligation. They usually do not identify the model involved, the information processed, the tasks the tool will perform, the role of human review, or the product’s known limitations.
The agreement and its exhibits should identify the specific service, its intended uses, and any prohibited or unsupported uses. A predictive-maintenance contract should describe the equipment, data sources, operating conditions, and outputs covered by the service. A contract-review tool should distinguish between extracting information, suggesting language, drawing legal conclusions, and assisting a human reviewer. An applicant-screening product should explain the factors considered, the recommendations generated, and the authority retained by human decision-makers.
The description should address limitations as well as capabilities. Generative AI can provide inaccurate information, invent sources, omit important facts, or answer similar prompts inconsistently. Predictive systems may perform well on data resembling their training information but become less dependable as customer conditions change. NIST’s Generative Artificial Intelligence Profile identifies risks that include confabulation, privacy concerns, harmful bias, information-security threats, intellectual-property issues, and excessive reliance on generated
content. 2 An agreement that provides access to the platform while disclaiming all responsibility for foreseeable limitations offers little practical protection.
A customer should ask which models and providers make the service possible. The platform may use a proprietary model, an open-weight model, a commercial foundation model supplied by another company, or several models working together. That information matters because the contracting vendor may not control the underlying model, training practices, security environment, pricing, or long-term availability. A seemingly simple application may depend on multiple upstream providers that the customer never selected.
The contract should identify material subprocessors and describe their functions. The customer should receive notice before a new material subprocessor is added, particularly when the provider will receive sensitive information or perform an important part of the service. For higher-risk uses, an objection right may be appropriate when a proposed provider creates reasonable concerns involving security, privacy, regulatory compliance, geographic location, or competition.
The primary vendor should remain responsible for the conduct of its subprocessors. A customer should not be required to pursue a cloud provider, model developer, or data-labeling company with which it has no contract. The primary vendor selected the upstream services, controls the customer relationship, and is generally in the best position to impose obligations, monitor performance, and seek relief from its own providers.
Material technological dependencies should also be disclosed. If the product relies on a particular commercial model, the customer should understand what will happen if that model is discontinued, restricted, materially changed, or repriced. The vendor should maintain a reasonable continuity plan and should not replace the underlying model with a materially different option without notice, appropriate testing, and consideration of the effect on performance and compliance.
AI demonstrations can be persuasive because they use selected examples and controlled conditions. A successful demonstration does not establish that the product will perform reliably with the customer’s data, personnel, workflow, integrations, or technical environment. Important sales statements should be incorporated into the agreement, statement of work, or acceptance criteria rather than left as informal representations outside the contract.
The appropriate measurements will depend on the system. A document-extraction tool may be evaluated by field-level accuracy, processing time, error rates, and its ability to recognize designated document types. A manufacturing system may be measured by false-positive and false-negative rates, equipment coverage, detection time, or improvement over the existing process. A customer-service system may be assessed through response accuracy, escalation frequency, prohibited statements, customer satisfaction, and the amount of employee correction required.
The customer should examine how the vendor calculated advertised performance statistics. A statement that a product is ninety-five percent accurate has little meaning unless the supporting documentation explains what was measured, what data was used, how mistakes were classified, and whether the test conditions resemble the customer’s environment. Results may differ across industries, facilities, demographic groups, languages, document types, and operating conditions. The Federal Trade Commission has pursued businesses that made unsupported claims about AI capabilities, reinforcing the importance of substantiating material performance representations. 3
For significant implementations, the agreement should provide a pilot, testing, or acceptance period using representative customer data. Payment milestones may appropriately depend on successful acceptance when the product will be integrated into important operations or used to support consequential decisions. If the product does not satisfy agreed criteria, the contract should identify workable remedies, such as correction, replacement, additional implementation services, fee reduction, termination, or a refund.
A service-level agreement should address availability, response times, technical support, backup procedures, disaster recovery, and restoration of service. The parties should distinguish ordinary downtime from outages affecting essential operations. A tool used to draft internal marketing content presents a different continuity risk from a system connected to automotive production, healthcare functions, financial approvals, or supply-chain management.
Performance should not be evaluated only on the implementation date. AI models can experience drift when real-world data, user behavior, or operating conditions change. The agreement should address continuing monitoring and require notice when measured performance materially deteriorates. A multiyear contract that contains no process for detecting or correcting declining performance may leave the customer with a product that no longer meets the business need that justified the purchase.
Data provisions may be the most important part of an AI agreement. A platform may receive confidential communications, engineering drawings, customer records, financial information, employee data, production statistics, contracts, medical information, or proprietary processes. Without clear restrictions, transferring that information to a vendor can reduce the business’s practical control over some of its most valuable assets.
The definition of customer data should reflect how the service actually operates. It may need to cover information uploaded directly, information obtained through integrations, employee prompts, system logs, files accessed from customer networks, feedback provided to the vendor, and information generated from the customer’s use of the product. The definition should not be limited to material formally uploaded through one interface when the vendor will receive information through other channels.
The agreement should confirm that the customer retains its rights in customer data and that the vendor receives only the limited permission necessary to provide the contracted service. The license should be examined for language allowing unrelated product development, advertising, profiling, resale, generalized benchmarking, or commercialization. A broad license may provide the vendor with rights that exceed what the customer intended to grant.
One of the central questions is whether the vendor may use customer information to train, fine-tune, test, evaluate, or improve AI models. Vendors sometimes describe all of these activities as necessary to improve the service, but that phrase can authorize more than the customer expects. Configuring a private system for one customer is materially different from using that customer’s information to improve a general model available to others.
A Southeast Michigan business should ordinarily prohibit the use of confidential or personal customer data to train a model that benefits other customers. When limited improvement rights are appropriate, the contract should define the information involved, require de-identification where suitable, prohibit reconstruction or re-identification, and prevent customer content from being incorporated into a model in a way that could later reproduce or expose the information.
The vendor should explain how prompts, outputs, and related logs are retained. Some services store conversations for security monitoring, abuse prevention, analytics, or quality review even when they do not use the content for model training. The agreement should address retention periods, deletion practices, access controls, and exceptions. A statement that information is not used for training does not resolve whether it is stored, reviewed by people, shared with subprocessors, or maintained in system logs.
Southeast Michigan businesses often possess sensitive commercial information that extends well beyond traditional personal data. Automotive suppliers may hold specifications, prices, test results, tooling designs, production methods, customer requirements, and future-product information. Technology companies may have source code, algorithms, research, or unreleased products. Professional firms may hold privileged or confidential client materials and strategic analyses.
Michigan’s Uniform Trade Secrets Act protects qualifying information that derives economic value from not being generally known when reasonable measures are taken to preserve its secrecy. 5 Providing trade-secret information to an AI vendor without appropriate contractual safeguards may make it more difficult to demonstrate that the business used reasonable protective measures. The vendor agreement should therefore be considered part of the company’s broader trade-secret protection program.
The confidentiality provision should cover all nonpublic customer information, not merely information marked with a particular label. Disclosure should be limited to vendor personnel and approved subcontractors who need the information to provide the service and who are bound by obligations at least as protective as those in the customer contract. The restriction should address unauthorized use as well as unauthorized disclosure.
The agreement should prohibit vendor personnel from placing customer information into public or consumer AI platforms. Customer data should not be used for experimentation, demonstrations, internal projects, or employee convenience outside the contracted service. Access should be limited by job responsibility, supported by appropriate controls, and logged so that the vendor can investigate misuse or unauthorized access.
When personal information is involved, the customer should understand where the information will be stored, whether it may leave the United States, how it will be encrypted, and which personnel or subcontractors can access it. Michigan’s Identity Theft Protection Act imposes duties concerning certain security breaches involving personal information. 6 The vendor’s contractual obligations should provide enough information and cooperation for the customer to investigate an incident and satisfy any applicable notification duties.
The vendor should provide notice of subpoenas, government demands, or other legal requests for customer information unless applicable law prohibits notice. It should also provide reasonable assistance so the customer can seek confidential treatment, narrow the request, or pursue an appropriate challenge. At the end of the relationship, the vendor should return or securely delete confidential information, including copies held by subprocessors, subject only to narrowly defined legal retention requirements.
AI services present familiar cybersecurity risks and additional risks associated with models, training data, prompts, integrations, and automated actions. Threats may include unauthorized access, prompt injection, data poisoning, model theft, insecure plugins, compromised application-programming interfaces, malicious outputs, excessive permissions, and the disclosure of confidential information through generated responses.
A general promise to use commercially reasonable security may not provide enough detail for a system handling sensitive information or supporting important operations. The contract should require a documented security program proportionate to the data and use case. Joint guidance from cybersecurity authorities emphasizes secure design, secure development, secure deployment, and secure operation throughout the AI lifecycle. 4 NIST’s secure-development profile for generative AI likewise recognizes that AI model producers, system producers, and acquirers may share responsibility and that agreements can identify which party is responsible for particular security practices. 9
Depending on the risk, the vendor may be expected to use encryption in transit and at rest, multifactor authentication, role-based access controls, vulnerability management, secure development methods, monitoring, logging, backup systems, and tested incident-response procedures. The agreement should also address model interfaces, integrations, software dependencies, administrative accounts, and any tools that can cause the system to take actions in other applications.
Independent reports such as the current SOC 2 Type II examination can provide useful information, but the existence of a report should not be treated as conclusive proof of security. The customer should examine the scope of the review, the systems included, any exceptions, and the vendor’s remediation. A high-risk system may justify additional penetration testing, model-focused security testing, or assessments tailored to the customer’s industry and information.
The vendor should provide prompt notice of an actual or reasonably suspected security incident affecting customer data, credentials, systems, or service availability. Notice should not wait until the vendor completes every aspect of its investigation or decides that statutory notification is required. The customer may have independent duties to preserve evidence, notify insurers, communicate with clients, investigate the event, or meet legal deadlines.
The agreement should identify the information expected in the initial notice, the frequency of updates, and the process for coordinating communications. The vendor should preserve relevant evidence, provide logs, identify affected systems and information, assist with forensic analysis, and cooperate with regulators or law enforcement when appropriate. To the extent an incident results from the vendor’s failure to meet its contractual obligations, the allocation of costs should address forensic investigation, required notices, restoration, regulatory response, legal expenses, and remediation.
The agreement should establish the parties’ rights in outputs produced through the customer’s use of the system. Some contracts assign outputs to the customer to the extent ownership can legally exist, while others provide only a license. Vendors may also reserve rights to reuse outputs by characterizing them as feedback or product-improvement information. Those provisions should be reviewed in light of how the business intends to use the resulting work.
The customer should generally seek the broadest legally available rights to use, reproduce, modify, distribute, display, and commercialize outputs created for its business. The vendor should not use identifiable customer outputs for demonstrations, marketing, model training, or delivery to other customers without permission. These restrictions can be especially important when the output reveals confidential strategy, product plans, client information, or proprietary workflows.
The contract should distinguish customer-specific deliverables from the vendor’s preexisting platform and technology. A customer usually does not need ownership of the vendor’s model, software, or general tools. It may, however, need durable rights in reports, configurations, templates, workflows, and other materials created specifically for the customer so those materials remain usable after the relationship ends.
Copyright protection for AI-generated material depends on human authorship and the circumstances in which the work is created. The U.S. Copyright Office has concluded that purely AI-generated material is not protected by copyright, while human-authored expression, creative arrangements, and sufficiently creative modifications may qualify on a case-by-case basis. 7 A vendor should not promise ownership or copyright protection that the law may not recognize, but it should disclose known limitations and avoid shifting every legal risk to the customer while promoting the system as suitable for commercial content.
AI vendor forms often state that the customer alone is responsible for complying with all laws. The customer remains responsible for how it chooses to use the product, but it should not accept responsibility for development practices, model design, security controls, marketing statements, data processing, or other facts controlled by the vendor. Compliance obligations should be allocated according to each party’s role and access to information.
The vendor should represent that its development, marketing, licensing, and operation of the service comply with laws applicable to the vendor. It should also provide documentation and reasonable cooperation that the customer needs to evaluate laws applicable to the customer’s use. Depending on the product, that information may include data sources, testing, security, accessibility, retention, decision logic, and material changes.
The necessary provisions will depend on the use case. A healthcare organization may need terms addressing protected health information, patient communications, clinical support, human review, and vendor access. A financial business may focus on customer information, fraud detection, lending, recordkeeping, and adverse-action decisions. A public-sector customer may need provisions concerning accessibility, transparency, public records, procurement rules, retention, and constitutional protections.
Employment-related systems require particular care because federal and Michigan civil-rights laws continue to apply when an employer uses a vendor’s algorithm to screen applicants, evaluate workers, recommend promotions, or support terminations. Federal guidance has warned that employers can violate the Americans with Disabilities Act when algorithmic tools screen out qualified individuals with disabilities or fail to provide a reasonable accommodation. 8 An employment vendor should not be permitted to market a product as objective or bias-reducing while withholding meaningful validation information or disclaiming responsibility for the system’s design.
The agreement should support audits, investigations, accommodations, recordkeeping, and the customer’s ability to review and override recommendations. The vendor should provide information sufficient to evaluate whether the tool is job-related for the position and appropriately validated for the relevant population. A disclaimer stating that the system does not make the final decision should not end the inquiry when the system effectively determines which applicants or employees receive meaningful consideration.
Michigan businesses should also plan for changing legal requirements. Michigan lawmakers have considered House Bill 4668, a proposal addressing safety and transparency obligations for certain advanced AI systems. 10 Regardless of the ultimate treatment of any one proposal, state and federal expectations concerning AI governance continue to develop. The contract should address how the vendor will monitor applicable changes, update the service, and allocate the cost of maintaining basic legal compliance.
A business cannot oversee a system effectively if the contract prevents any meaningful examination. Vendors may properly protect source code, model weights, trade secrets, and security-sensitive information, but those interests do not require the customer to operate without documentation, testing information, or a practical way to investigate material concerns.
The customer should receive documentation describing the product’s intended purpose, data sources, known limitations, testing procedures, performance measurements, security controls, change-management process, and escalation methods. Higher-risk uses may justify more detailed information about model evaluation, bias testing, human oversight, failure scenarios, and the circumstances in which the vendor advises against relying on an output.
The agreement should allow the customer to request relevant reports and to conduct a reasonable audit when justified by a security incident, regulatory inquiry, material performance issue, or credible compliance concern. Audit rights can be structured to protect vendor trade secrets through confidentiality restrictions, independent reviewers, controlled access, or summary findings. The objective is meaningful verification without unnecessary exposure of proprietary technology.
The vendor should maintain records sufficient to reconstruct significant system activity. For a tool that influences consequential decisions, logs may need to identify the model version, relevant inputs, material outputs, automated actions, user changes, and human overrides. Without those records, the business may be unable to investigate a complaint, explain a decision, respond to discovery, or determine why the product failed.
Explainability should be matched to the use. A customer may not need a complete technical explanation of every mathematical operation, but it does need enough information to understand the factors that materially influenced an output, evaluate whether the system is being used appropriately, and communicate the basis of a consequential decision when legal or business circumstances require an explanation.
Vendors frequently state that outputs are only recommendations and must be reviewed by people. Human review is important, but the phrase should not substitute for product quality, reliable information, or appropriate safeguards. The workflow must give the reviewer enough time, authority, and information to disagree with the system. Depending on the product, useful features may include source references, confidence indicators, warnings, escalation paths, version histories, comparison tools, and the ability to correct or override an output.
The agreement and implementation plan should identify actions that require human approval. An AI system should not autonomously send legally significant communications, approve payments, modify critical production settings, reject applicants, issue discipline, provide medical instructions, or bind the company to contractual terms unless the business has expressly authorized that function and implemented safeguards appropriate to the consequences.
Many standard agreements provide intellectual-property indemnification subject to extensive exclusions. The vendor may exclude claims involving prompts, customer data, modifications, combinations with other systems, continued use after notice, or outputs that resemble third-party content. Some exclusions may be reasonable, but they should be examined collectively because they can eliminate protection for the ordinary use that the vendor encouraged.
The customer should consider seeking defense and indemnification for third-party claims alleging that the platform, vendor-supplied training materials, underlying technology, or authorized use of the service infringes intellectual-property rights. The protection should address defense costs, covered settlements, judgments, and reasonable costs of replacing or modifying the product. Control of the defense and settlement approval should also be stated clearly.
If an infringement claim prevents continued use, the vendor should have practical obligations beyond simply ending the subscription. Appropriate options may include obtaining the right to continue the service, modifying the product without materially reducing functionality, providing a substantially equivalent replacement, or refunding appropriate fees and transition costs. A refund of a small amount of subscription fees may be inadequate after the system has been integrated into operations.
A standard vendor form may cap all liability at the fees paid during the preceding three or twelve months. For a relatively inexpensive subscription, that amount may be small compared with the potential cost of a security breach, production shutdown, regulatory inquiry, discrimination claim, or intellectual-property lawsuit. The customer should compare the cap with the foreseeable harm associated with the actual use rather than treating it as an ordinary software term.
A general cap may be reasonable for routine contract disputes, while higher caps or exclusions from the cap may be appropriate for confidentiality breaches, security incidents, prohibited data use, infringement claims, fraud, gross negligence, willful misconduct, and indemnification obligations. The exclusion of consequential damages also deserves attention because vendor forms may classify business interruption, loss of data, replacement expenses, reputational harm, and regulatory losses as consequential even when those are the losses most likely to follow the vendor’s failure.
The vendor should maintain insurance appropriate to the technology, services, and information involved. Relevant coverage may include technology errors and omissions, cyber liability, commercial general liability, professional liability, and crime or fidelity coverage. Insurance does not replace indemnification or adequate liability language. It is a source of financial support for those obligations, and the customer should consider policy limits, exclusions, claims-made requirements, subcontractor coverage, and the types of incidents the policy is designed to address.
AI products may change more frequently and more substantially than conventional software. A vendor can replace the underlying model, modify safety filters, change retention practices, add autonomous functions, revise integrations, or alter acceptable-use restrictions. A system approved after careful review can therefore become a materially different product during the contract term.
The contract should address advance notice of material changes affecting functionality, performance, security, privacy, data use, legal compliance, or the underlying model. Significant changes should be tested before they reach the customer’s production environment. For important applications, the customer may need a right to delay an update while validation occurs, except when an immediate security correction is reasonably necessary.
The vendor should maintain version information and document significant changes. The customer should be able to determine which model or product version produced a particular output, recommendation, or automated action. That information may become important in an internal investigation, regulatory inquiry, insurance claim, employment dispute, or lawsuit.
The vendor should not be able to alter contractual data rights or material risk allocations through an online policy that it may revise unilaterally. The signed agreement should control over inconsistent website terms, documentation, and click-through conditions. Material contractual changes should require mutual written agreement or provide the customer with a meaningful right to reject the change and terminate without penalty.
Termination provisions are often overlooked during implementation. By the time a serious problem appears, the product may be embedded in workflows, connected to other systems, and populated with years of operational data. The business should evaluate exit rights before it becomes dependent on the vendor and before switching costs become difficult to manage.
The agreement should permit termination for material breach, repeated service failures, serious security concerns, prohibited data use, loss of required insurance, insolvency, or material regulatory risk. A reasonable termination-for-convenience right may also be worth considering because AI technology, business needs, and legal requirements can change rapidly. Fees and notice periods should not make a negotiated termination right impractical.
At termination, the vendor should provide customer data and relevant outputs in a commonly usable format. The contract should identify what will be exported, how it will be delivered, the timing, and any transition support. The vendor should not hold customer information pending resolution of a disputed invoice or impose unexpected extraction charges after the customer has become dependent on the service.
Not every AI purchase requires extensive negotiation. The appropriate level of diligence depends on the information involved, the decisions affected, the degree of automation, the foreseeable cost of error, the vendor’s access to company systems, and the difficulty of replacing the product. A proportionate process allows the business to focus resources where contractual protection matters most.
Industry context should guide the review. Automotive and manufacturing companies may emphasize reliability, integration risk, production continuity, engineering confidentiality, safety, model drift, and responsibility for defective recommendations. Healthcare organizations may focus on patient privacy, clinical limitations, human review, accuracy, and security. Employers may prioritize validation, accessibility, bias testing, recordkeeping, and cooperation with investigations. Professional firms may place particular weight on privilege, confidentiality, source verification, output accuracy, intellectual-property rights, and restrictions on training.
A sound contracting process begins before the vendor sends its form. The business should identify what information the tool will receive, what systems it will access, which decisions it will influence, who will rely on its outputs, how errors will be detected, and what would happen if the product became unavailable. The agreement can then be evaluated against actual operational risks rather than a generic checklist.
AI vendors often describe their agreements as standardized and nonnegotiable. A Southeast Michigan business should still ask focused questions when the technology will receive valuable information or influence important operations. Even when the vendor will not revise its form, the responses may reveal whether the product is suitable, whether alternative providers should be considered, or whether internal safeguards and limited deployment are necessary.
The guiding principle is that responsibility should follow control. A vendor that controls the model, security environment, subprocessors, product updates, and data architecture should accept appropriate responsibility for failures in those areas. The customer should remain responsible for its business judgments, employee conduct, and final use of the outputs. A contract that assigns nearly every material risk to the customer while preserving broad vendor control does not reflect a balanced allocation.
Before signing, the business should understand what the system does, how performance will be measured, how information will be used, which third parties will receive it, how material changes will be handled, and who will bear the cost when something goes wrong. Those questions do not prevent innovation. They support the responsible, defensible, and sustainable use of AI in Southeast Michigan businesses.
AI vendor contracts should be treated as operating documents, not merely purchasing forms. The contract should reflect the system’s real use, the information it will receive, the decisions it will influence, and the harm that could follow from failure. It should also create a workable relationship in which the vendor provides continuing information, supports oversight, responds to incidents, and remains accountable for the aspects of the technology it controls.
The most effective review is neither reflexively hostile to AI nor satisfied with broad assurances. It asks practical questions, converts important answers into enforceable terms, and scales the level of protection to the risk. For Southeast Michigan businesses seeking the benefits of AI without surrendering control of their data, operations, and legal position, careful contracting is one of the most important forms of risk management available.
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
- 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
2. 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
3. Federal Trade Commission, Operation AI Comply enforcement materials concerning deceptive AI claims and schemes, September 2024; Federal Trade Commission Act Section 5, 15 U.S.C. Section 45. https://www.ftc.gov/news-events/news/press-releases/2024/09/ftc-announces-crackdown-deceptive-ai-claims-schemes
4. Cybersecurity and Infrastructure Security Agency, National Security Agency, United Kingdom National Cyber Security Centre, and international partners, Guidelines for Secure AI System Development, November 2023. https://www.ncsc.gov.uk/files/Guidelines-for-secure-AI-system-development.pdf
5. Michigan Uniform Trade Secrets Act, MCL 445.1901 et seq. https://www.legislature.mi.gov/Laws/MCL?objectName=mcl-445-1901
6. Michigan Identity Theft Protection Act, MCL 445.61 et seq., including MCL 445.72. https://law.justia.com/codes/michigan/chapter-445/statute-act-452-of-2004/
7. U.S. Copyright Office, Copyright and Artificial Intelligence, Part 2: Copyrightability,
Report of the Register of Copyrights, January 2025. https://www.copyright.gov/ai/Copyright-and-Artificial-Intelligence-Part-2-Copyrightability-Report.pdf
8. U.S. Equal Employment Opportunity Commission, The Americans with Disabilities Act and the Use of Software, Algorithms, and Artificial Intelligence to Assess Job Applicants and Employees, May 2022. https://www.naacpldf.org/wp-content/uploads/EEOC-ADA-and-Software-Algorithms-and-AI-to-Assess-Job-Applicants.pdf
9. National Institute of Standards and Technology, Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile, NIST SP 800-218A, July 2024. https://www.nist.gov/publications/secure-software-development-practices-generative-ai-and-dual-use-foundation-models-ssdf
10. Michigan House Bill 4668 of 2025, proposed Artificial Intelligence Safety and Security Transparency Act, as introduced. https://fastdemocracy.com/bill-search/mi/2025-2026/bills/MIB00027205/