As we have detailed in numerous posts on this site, Artificial Intelligence (AI) is an important area of emerging corporate risk. AI also represents an important corporate governance challenge for companies and their boards. In the following guest post, Patrick Meson takes a detailed look at the nature of AI-related corporate risks and considers the corporate governance implications. Patrick is a Corporate Counsel at a New York Investment Bank. Our thanks to Patrick for allowing us to publish his article on this site. Here is Patrick’s article.
*************************
For boards and the officers who advise them, the decision to deploy or build AI is a Caremark event. This piece traces the Delaware oversight chain from Caremark to McDonald’s and explains why personal, loyalty-based exposure attaches before the tool is ever switched on.
Abstract
U.S. corporations considering the adoption of a third-party AI tool, or the development of an internal AI application built on a third-party foundation model, face a legal landscape that is simultaneously unregulated at the federal level and densely governed by existing law. No federal statute prescribes how a company must govern its AI systems. Yet Delaware corporate law, sector-specific regulatory guidance, emerging state legislation, and commercial counterparty expectations jointly impose obligations that attach before a contract is signed and persist throughout the system’s operational life. This piece explains why the decision to deploy or develop AI is a governance event, not merely a procurement event; how the deploying company retains legal accountability for outputs it did not build and cannot fully inspect; and why the NIST AI Risk Management Framework, though formally voluntary, has become the operational standard against which corporate AI governance is assessed in litigation, regulatory examination, and enterprise procurement.
The Problem Arrives Before the Contract
When a company decides to deploy an AI tool within the organization, the decision may look like routine business at first. A request comes from HR, legal, finance, IT, or the business team. The paperwork looks like a standard software subscription. The vendor is reputable. The use case is clear. It is, by all appearances, a procurement event.
Except that it is not. The legal relationships created when a company deploys a third-party AI tool, or uses a third-party foundation model to build its own, are materially different from those created by conventional software procurement. The liability that attaches to getting those relationships wrong does not flow to the vendor; it flows to the company, and more specifically, under Delaware corporate law, to the directors and officers responsible for overseeing the company’s systems and controls. A board that treats an AI deployment as a standard procurement event, without the governance process that Delaware law now requires for mission-critical systems, could create a director and officer liability problem before the tool is ever turned on.
Three distinct legal exposure vectors make the AI adoption decision a governance event rather than a procurement one. The first is Delaware corporate law. It imposes a personal duty of oversight on directors and officers that attaches when the company deploys AI, which is itself a source of legal, operational, and compliance risk that requires board-level oversight. The second is the structure of the AI vendor market, in which contracts are systematically drafted to leave liability with the deploying company rather than the vendor. The third is a rapidly expanding patchwork of federal regulatory expectations and state legislation that attaches based on what the AI system does, where the company operates, and who is affected. The NIST AI Risk Management Framework is the practical answer to all three simultaneously.
First Exposure Vector: Delaware’s Duty of Oversight
Congress has not passed comprehensive AI legislation. No federal statute tells a U.S. company how to evaluate, procure, or govern an AI system. The executive orders issued by both the Biden and Trump administrations operate primarily on federal agencies, not private companies. Sector regulators have signaled expectations through examination guidance and enforcement posture, but their authority runs through existing statutes: the FTC Act, Title VII of the Civil Rights Act of 1964, the Equal Credit Opportunity Act, SEC disclosure rules. There is no AI statute that maps cleanly onto what a company must do when it decides to use an AI tool.
Delaware corporate law fills that gap. For the roughly two-thirds of Fortune 500 companies incorporated in Delaware, the fiduciary duty of oversight requires directors and officers to make a good-faith effort to implement and monitor the systems through which the company manages its material risks. When AI becomes one of those systems, the duty attaches.
The doctrinal foundation rests on five cases that together define what the oversight duty requires.
- In re Caremark International Inc. Derivative Litigation, 698 A.2d 959 (Del. Ch. 1996), established the original framework. Directors may face liability either for failing entirely to implement a reporting and information system, or for consciously disregarding red flags produced by a system they did implement. Both require bad faith, not mere negligence.
- Stone v. Ritter, 911 A.2d 362 (Del. 2006), confirmed that the Caremark duty is grounded in the duty of loyalty, not the duty of care. That distinction has direct practical significance: Delaware corporations routinely include provisions in their charters, authorized by DGCL § 102(b)(7), that exculpate directors from personal liability for duty-of-care violations. Those provisions do not protect against loyalty-based claims. A director who consciously disregards the need for an oversight system cannot hide behind an exculpatory charter provision.
- Marchand v. Barnhill, 212 A.3d 805 (Del. 2019), sharpened the standard considerably. Where a risk is mission-critical to the company’s business or compliance obligations, the board must install board-level oversight of that risk and cannot rely on management’s discretionary reporting as a substitute. When a listeria outbreak at the company killed three people, derivative plaintiffs sued the board for failing to oversee food safety. The Delaware Supreme Court held that the complete absence of any board-level committee or reporting process dedicated to food safety was sufficient to allow the claim to proceed past a motion to dismiss, even though the board had not been shown to have received and ignored a specific warning.
- In re Boeing Co. Derivative Litigation, 2021 WL 4059934 (Del. Ch. 2021), applied the same logic as Marchand to airplane safety. Boeing’s board had no committee responsible for it, received no regular safety reports, and failed to act after a fatal crash in 2018 provided an unmistakable warning.
- In re McDonald’s Corp. Stockholder Derivative Litigation, 289 A.3d 343 (Del. Ch. 2023), extended Caremark liability beyond directors to corporate officers within their respective areas of responsibility, substantially widening the personal exposure surface for senior executives.
Three features of the post-Marchand doctrine bear directly on AI adoption decisions.
First, the duty scales with criticality. Where a risk is mission-critical to the company’s business or compliance obligations, the board must install a board-level structure for monitoring it, not merely rely on management’s discretionary reporting. Whether that standard applies is a company-specific inquiry: AML monitoring is mission-critical to a bank; content-moderation algorithms are mission-critical to a social media or digital marketplace platform. The question is whether the AI system materially bears on a risk that is core to its business or compliance obligations, not merely whether the system could produce a harmful output. For companies where AI performs functions of that character, including credit decisioning, AML monitoring, hiring, insurance underwriting, or the handling of sensitive, confidential, or privacy-protected data at scale, the board-level oversight obligation almost certainly applies.
Second, the duty now extends to officers. McDonald’s confirmed that officers carry a Caremark duty of oversight within their areas of responsibility, scoped to their functional domain. Under the first Caremark prong, an officer must implement adequate oversight systems within that domain — the general counsel cannot discharge the obligation by approving a vendor contract without supervising what the vendor actually does; the chief compliance officer cannot discharge it by certifying that a monitoring program exists without verifying that it functions. Under the second prong, an officer who receives red flags indicating that existing oversight is failing and does nothing has consciously disregarded those warnings. The board’s oversight structure does not absorb either obligation; it supplements them.
Third, the standard is procedural, not technical. Directors are not required to understand how a large language model generates an output or what a transformer architecture does. What they are required to do is make a good-faith effort to design, validate, and supervise the company’s reliance on the system in light of its intrinsic opacity. As Pierluigi Matera’s recent paper frames it, AI does not change the Caremark standard; it changes the evidentiary terrain on which good faith is shown. (From Red Flags to Black Boxes, CLS Blue Sky Blog, Mar. 10, 2026; SSRN 6161886.) The inquiry is into process and documentation, not technical mastery.
Second Exposure Vector: Liability Does Not Travel With the Vendor Contract
The first thing corporate counsel should communicate clearly when a business unit arrives with an AI procurement request is this: legal accountability for what the system does does not transfer to the vendor when the contract is signed.
This is not intuitive. The assumption embedded in most procurement processes is that the vendor, who built and controls the model, bears the legal exposure for its behavior. In the AI context, that assumption is wrong in two distinct ways.
The first is contractual. AI vendor agreements, as a class, are structured to minimize vendor exposure and maximize deployer accountability. A recent market analysis found that 88% of AI vendors cap their own liability at the monthly subscription fee, while imposing broad indemnification obligations requiring the customer to hold the vendor harmless against discrimination claims, IP infringement claims, and regulatory actions arising from use of the tool. (Jones Walker, AI Vendor Liability Squeeze, 2026.) A procurement team that accepts vendor-drafted AI terms as standard boilerplate, without negotiating AI-specific liability and data-use provisions, will find that the resulting agreement transfers all meaningful risk to the company.
The second is regulatory and legal. Regulators have stated unambiguously that deploying a third-party AI tool does not transfer the deploying company’s compliance obligations. The Equal Employment Opportunity Commission (EEOC), the federal agency responsible for enforcing employment discrimination law, has confirmed that employers remain fully liable under Title VII when an AI screening tool produces discriminatory outcomes, regardless of whether the tool was built in-house or procured from a vendor. (Lexology, AI Use in Employment Decisions, Jan. 2026.) The same principle applies in financial services. The Consumer Financial Protection Bureau (CFPB) has stated explicitly that “there are no exceptions to the federal consumer financial protection laws for new technologies” and has required lenders using AI credit models to provide substantive, model-specific reasons for adverse actions rather than generic checklist responses, an obligation that falls on the deploying institution regardless of whether the underlying model was built by a third-party vendor. (CFPB Circular 2023-03; Skadden, Aug. 2024.) In July 2025, the Massachusetts Attorney General settled a fair lending action against a student loan company whose AI underwriting models produced disparate impact on the basis of race and immigration status, with liability attaching to the deploying institution for outcomes generated by its AI system. (Massachusetts AG Settlement, July 2025.) The FTC’s enforcement action against Rite Aid, arising from inadequate oversight, testing, and monitoring of a third-party AI facial recognition system, reinforces the same logic across sectors: the gap between what an AI system does and what the deploying company can demonstrate it understood, monitored, and controlled is the regulator’s target. (Cleary Gottlieb, Managing AI Risk, Jan. 2026.) Courts are developing the same logic through agency theory: in Mobley v. Workday, Inc., No. 23-cv-00770-RFL (N.D. Cal.), the court denied Workday’s motion to dismiss and, in May 2025, conditionally certified a nationwide ADEA collective action, allowing the case to proceed on the theory that Workday may be held directly liable as an agent of the employers who used its AI screening software to make hiring decisions. Under that theory, the vendor itself, not only the deploying employer, could bear liability for discriminatory screening outcomes.
The practical consequence is that a company acquiring a third-party AI tool acquires its outputs, its flaws, its biases, and its regulatory exposure along with its capabilities. Contractual provisions can partially mitigate that exposure: restrictions on the vendor’s use of company data for model training, audit rights, meaningful indemnification, and defined performance standards with remediation obligations each shift some risk back toward the vendor. But no contract eliminates the deploying company’s underlying regulatory and fiduciary obligations. The governance program built before deployment is what provides that foundation; the contract governs the vendor relationship within it.
The accountability analysis is sharpest for companies that go further than subscribing to a third-party tool and instead use a foundation model API from providers such as Anthropic, OpenAI, Google, or Meta to build their own internal application. That company is simultaneously a deployer and a functional developer: it makes design choices about the application’s structure, guardrails, data inputs, and human oversight requirements. Those design choices are the company’s own decisions, and the compliance obligation for their consequences belongs to the company accordingly. A pure subscriber exercises no control over the model’s training data, architecture, or update cycle; a company building on a foundation model API controls the application layer entirely. The greater the control, the greater the accountability, and the more important it is that the governance program reflect the company’s own design decisions, not merely its vendor management practices.
Third Exposure Vector: No Federal AI Law Does Not Mean No Law
The absence of a federal AI statute does not mean the absence of applicable law. Existing federal statutes govern AI-enabled conduct directly, and sector regulators have issued guidance, examination priorities, and enforcement positions that impose additional obligations on companies deploying AI in regulated contexts. Companies must account for both layers.
A few examples convey the texture of what companies face, though the landscape is considerably broader. The SEC has identified AI-based systems as a 2026 examination priority for registered advisers and broker-dealers, with examiners directed to assess whether automated tools operate consistently with regulatory expectations, specifically whether governance and validation structures exist. (SEC 2026 Examination Priorities.) The OCC, Federal Reserve, and FDIC apply model risk management guidance (SR 11-7) to AI and machine learning in banking, requiring documented validation, independent review, and board-level visibility for critical models.
At the state level, the legislative landscape has moved quickly, if unevenly. Texas’s Responsible AI Governance Act (TRAIGA), effective January 1, 2026, imposes risk assessment and transparency obligations on deployers of high-risk AI systems and provides an affirmative defense for organizations demonstrating alignment with a recognized governance framework such as the NIST AI RMF. California has enacted multiple AI-specific statutes imposing training data transparency requirements, mandatory disclosure and detection tools for AI-generated content, and impact assessment and opt-out rights for consequential automated decisions. New York City Local Law 144 requires independent bias audits for automated employment decision tools. More than thirty states introduced or passed AI-related legislation in 2025 alone. While the scope and approach vary, the legislation generally falls into two categories: liability-oriented statutes that assign responsibility for discriminatory or harmful AI outputs to the deploying company regardless of who built the model, and prescriptive governance statutes that impose affirmative obligations, including impact assessments, consumer disclosures, human review requirements, and incident reporting, on companies that deploy AI in high-risk contexts. The result is a patchwork of obligations triggered by use case, geography, and sector. There is no federal floor, but there is no regulatory silence either.
The Answer to All Three: Standards in the Absence of Statutes
The three exposure vectors described above share a common problem: none of them comes with a prescribed governance architecture. Delaware law requires a good-faith oversight system but does not specify what one looks like for AI. The vendor contract structure leaves liability with the deployer but does not tell the deployer how to govern what it has bought. The regulatory patchwork creates obligations triggered by use case and geography but provides no unified compliance framework.
The gap has been filled, not by legislation, but by the emergence of non-governmental and quasi-governmental standards that are quietly fashioning the unwritten rules of AI governance in the United States. The most significant of these is the NIST AI Risk Management Framework, but it operates alongside ISO/IEC 42001 (the international certifiable management system standard for AI), sector-specific adaptations developed by industry bodies such as the Bank Policy Institute and the Cyber Risk Institute in financial services, and a growing body of technical standards from the Institute of Electrical and Electronics Engineers (IEEE) and other standards development organizations. These instruments were designed as guidance, not law. But in a market where courts, regulators, investors, and customers all need some reference point for what responsible AI governance looks like, voluntary standards tend to acquire the authority that statutes have not yet supplied.
The NIST AI RMF: Voluntary in Name, Mandatory in Effect
The National Institute of Standards and Technology published the AI Risk Management Framework (NIST AI RMF) on January 26, 2023, under a congressional mandate in the National Artificial Intelligence Initiative Act of 2020. (NIST AI RMF.) Its operational companion, the AI RMF Playbook, maps each of the framework’s 72 subcategories to specific suggested actions and provides implementation guidance organized by role and context. Both are publicly available at no cost. Neither carries enforcement authority.
But in the absence of a federal AI statute, the NIST AI RMF has quietly become the closest thing the United States has to an authoritative standard for how companies should govern AI. Courts reference it to define reasonable conduct. Federal regulators use it as an assessment benchmark. State legislatures cite it as a compliance safe harbor. Enterprise customers demand alignment with it in procurement questionnaires. It was not designed to fill this role, and NIST did not claim it for one. But in a regulatory vacuum, a well-constructed voluntary framework developed by a credible federal agency, built with industry input, and aligned to international standards tends to become the default measure of what responsible governance looks like. The NIST AI RMF is now that measure, and organizations that cannot demonstrate alignment with it face an increasingly difficult question when things go wrong: if not this, then what?
The relevant question is not whether NIST can enforce the AI RMF. It cannot. The question is what happens to a company that cannot demonstrate alignment with it when its AI governance practices are examined.
There is a precedent that sheds light on how the NIST AI RMF is likely to be used and interpreted over time. The NIST Cybersecurity Framework, also voluntary, was introduced in 2014. Over the following decade it became the operational definition of reasonable cybersecurity practice: regulators cited it when assessing whether organizations had taken adequate precautions before a breach; courts used it to define the standard of care in negligence cases; insurers used it as an underwriting criterion. The AI RMF is following the same trajectory. (Jones Walker, 2026.) Three forces are driving that convergence.
- Litigation. Courts have not yet issued a body of decisions expressly citing the NIST AI RMF by name, but the trajectory is established. Under longstanding negligence and product liability doctrine, courts look to industry standards and voluntary frameworks to define the standard of reasonable care — and legal scholars and practitioners now widely expect the NIST AI RMF to fill that role for AI governance, following the same path as the NIST Cybersecurity Framework before it. (FPF, Incentives or Obligations, Mar. 2026; Harvard JOLT, Redefining the Standard of Human Oversight for AI Negligence, Feb. 2026.) A company that cannot demonstrate NIST-aligned processes faces an inference gap in litigation: it had no structured approach to governing a technology deployed into consequential decisions. In the Delaware Caremark context specifically, the NIST AI RMF Govern function maps directly onto the “information and reporting system” that directors must design in good faith. Undocumented adoption amplifies the appearance of abdication in discovery. (Matera, SSRN 6161886.)
- Regulatory benchmarking. The Treasury Department’s February 2026 release of the Financial Services AI RMF, developed with over a hundred financial institutions and providing 230 mapped control objectives with explicit “effective evidence” guidance for examiners, signals that examination readiness in financial services now means NIST-aligned documentation. (Treasury FS AI RMF, Feb. 19, 2026.) Texas’s TRAIGA provides an affirmative defense for NIST alignment. California and several other states reference NIST and ISO/IEC 42001 as compliance benchmarks.
- Commercial and contractual pressure. Enterprise procurement teams now routinely include AI governance sections in vendor due diligence questionnaires, asking specifically for AI inventories, documented approval workflows, framework alignment, and performance monitoring evidence. IBM’s research found that 63% of organizations either have no AI governance policy or are still developing one — precisely the gap that counterparties are now probing. Cyber insurers are adding AI-specific risk questions to renewal applications, with premium and coverage implications for organizations that cannot demonstrate governance maturity. A company that cannot produce governance documentation on demand faces deal friction that its competitors with structured programs do not.
The AI RMF is organized around four functions that apply across the AI system lifecycle. They are not post-deployment housekeeping. They describe a process that should be engaged before deployment and maintained throughout the system’s operational life, and they map directly onto the governance obligations that Delaware corporate law, federal regulators, and state legislatures are each, in their own ways, demanding.
Govern is the foundational function, and the one most directly implicated by Caremark. It requires the organization to establish the policies, roles, accountability structures, and decision-making processes that make risk management possible across all AI activities. In practice, this means defining who has authority to approve AI deployments, who owns each system once deployed, how AI risk is reported to senior management and the board, what the organization’s risk tolerance is for different categories of AI use, and what the incident response playbook requires when an AI system fails or produces harmful outputs. Without a functioning Govern structure, the other three functions have no organizational substrate to operate in, and a board cannot demonstrate the good-faith oversight system that Caremark requires. The AI inventory sits within Govern: a maintained catalog of every AI system in use, including shadow AI and AI features embedded in licensed platforms, is the prerequisite artifact for everything that follows.
Map requires the organization to identify and categorize the risk profile of each AI system before it is deployed. This means understanding the system’s intended use and the populations it affects; identifying the potential harms if it fails, produces biased outputs, or is used outside its intended scope; assessing external risks arising from the supply chain, including the developer’s own governance practices, the provenance and quality of training data, and dependencies on third-party foundation models or APIs; and determining which legal and regulatory obligations attach given the system’s function and the jurisdictions in which it operates. A company that deploys an AI hiring tool without first mapping its exposure under the EEOC’s Title VII guidance, NYC Local Law 144, and TRAIGA has not completed the Map function and has not made the threshold determination that Caremark requires before relying on a system for a mission-critical function. Map is also where the developer/deployer distinction becomes operational: a company building on a foundation model API must map not only the risks of the underlying model but the additional risks introduced by its own application layer design choices.
Measure addresses how the organization evaluates and monitors AI risk on an ongoing basis. Pre-deployment, this means testing the system’s performance against defined metrics, evaluating for bias and fairness across relevant demographic groups, assessing robustness against adversarial inputs, and documenting the results. Post-deployment, it means continuous monitoring for model drift (degradation in performance as real-world data diverges from the training distribution) and for emerging harms that were not apparent at launch. The Measure function is what makes the Caremark “secondary red flag” analysis operational: declining alert rates, anomalous performance on outcome metrics, and divergence between model outputs and external signals such as regulatory inquiries or whistleblower complaints are each measurable events. A governance program that defines the thresholds that trigger escalation, and documents its response when they are crossed, demonstrates the engagement that distinguishes oversight from abdication.
Manage covers the decisions the organization makes in response to identified and measured risks, and the ongoing operational disciplines that keep those decisions current. It includes the determination of how to respond to each risk: mitigate through system redesign or human oversight, transfer through contractual allocation, accept with documented rationale, or avoid by declining to deploy, as well as the incident response plan for when AI systems produce harmful outputs, the vendor governance processes that ensure third-party systems remain within their approved parameters, and the record-keeping that makes the entire program auditable. The Manage function is where vendor contract obligations become internal governance requirements: audit rights negotiated in the contract are only valuable if the organization has a Manage-function process for exercising them and acting on what it finds.
The International Dimension: EU AI Act Exposure for U.S. Companies
The four NIST functions align closely, in some respects nearly one-for-one, with the obligations imposed by the European Union’s AI Act (Regulation (EU) 2024/1689), the world’s first comprehensive binding AI law. That alignment matters for U.S. companies because the EU AI Act has explicit extraterritorial reach. Under Article 2, the Act applies to three categories of non-EU companies: providers that place AI systems on the EU market or make them available to EU users, regardless of where the provider is incorporated; deployers that have an establishment or are located in the EU (including a U.S. company’s EU subsidiary or office); and, most broadly, any provider or deployer established outside the EU where the output of the AI system is used in the EU. That last trigger is the one most U.S. companies underestimate: if a U.S. company’s AI system generates a decision, score, recommendation, or piece of content that affects a person located in the EU, the Act reaches the company regardless of where its servers or headquarters sit. (Baker McKenzie, EU AI Act scope; William Fry, Extraterritorial Reach of the AI Act.) The prohibitions on unacceptable-risk AI practices have applied since February 2, 2025. High-risk system obligations, covering AI used in employment, credit, healthcare, education, and critical infrastructure, were scheduled for full effect on August 2, 2026; a European Commission proposal currently in legislative process would push certain deadlines to December 2027, though that revision is not yet final.
For U.S. companies within the Act’s scope, the practical benefit of NIST AI RMF alignment is direct: the EU AI Act’s core obligations for high-risk systems, including risk management systems, data governance, technical documentation, human oversight, accuracy and robustness requirements, and conformity assessments, map onto the Govern, Map, Measure, and Manage functions respectively. A company that has built its governance program against the NIST AI RMF will have addressed most of the substantive requirements the EU AI Act imposes, and will be significantly better positioned for the conformity assessment and documentation obligations the Act requires than a company starting from scratch. The inverse is also true: a U.S. company that has deferred AI governance on the assumption that domestic law does not yet require it may find that its EU market exposure has already made compliance non-optional.
Conclusion: Where the Law Leaves a Corporation Today
Return to the question this piece opened with. A company decides to deploy an enterprise AI assistant across its workforce, or to build an internal application on a foundation model API. The business case is clear. The procurement process is underway. What does the law require?
The honest answer is that the law requires more than most companies currently do, and less than a fully mature AI governance program eventually demands. The obligations are real, they attach before deployment, and they flow from multiple directions simultaneously.
From a Delaware corporate law perspective, the board and responsible officers face a duty of oversight that is personal, grounded in loyalty rather than care, and not exculpable by charter provision. That duty requires a good-faith effort to put in place an information and reporting system adequate to the risk that AI creates, and to monitor it once deployed. For companies where AI is mission-critical to operations, compliance, or safety, the bar is higher: the board must have an express oversight structure, not merely rely on management’s discretionary reporting. The failure to build that structure before an AI-related harm occurs is, under the doctrine established across Caremark, Stone, Marchand, Boeing, and McDonald’s, the bad-faith fact that exposes directors and officers to personal liability.
From existing federal and state law, the obligations are sector-specific but pervasive. Employment law, fair lending law, consumer protection law, model risk management guidance, and securities regulation all apply to AI-enabled conduct through their existing authority. They do not create a unified AI compliance regime, but they create a dense web of exposure that attaches based on what the AI system does, where the company operates, and who is affected. A company deploying AI in hiring, credit, insurance, healthcare, or any function that generates consequential decisions affecting individuals is operating in a regulated environment whether or not it has analyzed that environment before deployment.
From the contractual structure of the AI market, the company retains liability that its vendor agreements will not absorb. Vendor contracts are structured to transfer risk to the deployer. The company that signs without negotiating AI-specific terms, without restricting data use, without securing audit rights, and without establishing performance obligations has accepted a contractual structure that places the regulatory, litigation, and reputational exposure squarely on itself.
The path forward runs through the NIST AI Risk Management Framework, not because it is mandatory, but because it has become the operational answer to the question that Delaware courts, federal regulators, and state legislatures are all asking in different ways: did this organization make a good-faith effort to govern its AI? A company that can demonstrate alignment with the four functions of the NIST AI RMF, that has built the governance program the checklist below describes, and that has maintained the documentary record that reflects genuine engagement, has given itself the strongest available defense in litigation, the clearest evidence of good faith in regulatory examination, and the most credible posture in commercial relationships that increasingly demand it.
The law of the land is not yet settled. But its direction is clear.
Practical Checklist: What Boards, Management, and Counsel Must Do
The following checklist organizes the governance obligations described in this piece into sequential steps, moving from board-level accountability through operational implementation and ongoing monitoring. It is not exhaustive; specific industries carry additional obligations not reflected here. Its purpose is to provide initial referential guidance to U.S. companies considering deploying or developing AI tools.
Step 1: The Board Accepts and Takes Ownership of AI Risk
The starting point is a formal board-level decision to treat AI governance as a fiduciary obligation, not a matter left to management’s discretion. This means the board, with the advice of counsel, acknowledges that AI deployments within the company’s operations create oversight duties under Delaware law, and that those duties attach to the board and to responsible officers personally. The board should ensure its charter, or the charter of the relevant committee, expressly assigns AI oversight responsibility. The choice of committee (audit, risk, technology, or a dedicated AI committee) is discretionary; the absence of any assignment is not. Marchand and Boeing together establish that structural absence of responsible oversight is itself the bad-faith fact derivative plaintiffs use to survive a motion to dismiss.
Step 2: Appoint an Owner of AI Risk
The board, with management, should designate a named senior officer as the accountable owner of the company’s AI risk management program. In larger organizations this may be a Chief AI Officer (CAIO); in others it may be the Chief Risk Officer, Chief Compliance Officer, or General Counsel, depending on how AI is deployed and where the greatest risk exposure lies. What matters is that accountability is assigned to a specific individual, documented, and reflected in that officer’s mandate and reporting obligations. Accountability distributed across multiple functions without a named owner is, in practice, accountability belonging to no one, which is precisely the organizational failure pattern that the extension of Caremark liability to officers under McDonald’s is designed to address.
Step 3: Constitute an AI Governance Committee
The designated AI risk owner should chair a cross-functional AI governance committee with decision-making authority over AI deployments across the organization. The committee should draw from legal and compliance, risk management, technology and information security, data science or engineering, and relevant business-line owners. The NIST AI RMF places particular emphasis on technical competence within the governance structure: committee members responsible for risk assessment, validation, and monitoring must have sufficient technical literacy to evaluate AI system performance, understand model limitations, and assess the adequacy of controls — not merely receive and forward management reports. Its mandate should cover the full AI lifecycle: intake and approval of new deployments, ongoing oversight of deployed systems, vendor governance, policy development, and escalation to the board committee. The committee’s composition, charter, and reporting cadence should be documented; its deliberations should generate a record that demonstrates the substantive engagement Caremark requires.
Step 4: Conduct a Jurisdictional Legal Survey
Before any deployment decision is made, counsel should conduct a legal survey of the applicable federal and state obligations. At the federal level, this means identifying which sector-specific regimes attach to the proposed AI system’s function: EEOC guidance and Title VII for employment-related tools; CFPB and fair lending rules for credit decisioning; SEC model risk and disclosure obligations for investment-related systems; OCC and Federal Reserve model risk management guidance (SR 11-7) for banking applications. At the state level, this survey must account for where the company is incorporated, where its employees work, where its customers are located, and what decisions the AI system makes or influences. A hiring tool deployed across Texas, California, and New York City may trigger TRAIGA, California’s automated decision-making regulations, and NYC Local Law 144 concurrently, each with different obligations and enforcement mechanisms. For companies with EU market exposure or EU-based operations, the EU AI Act applicability analysis should also be part of this survey: the Act reaches non-EU companies that place AI systems on the EU market, operate EU-based subsidiaries or offices, or generate AI outputs used by persons in the EU, as discussed in the NIST section of this piece. This jurisdictional survey should be treated as a standing obligation updated at least annually, given the pace of state-level legislative activity.
Step 5: Develop Policies, Procedures, and an Incident Response Playbook
The AI governance committee, with counsel, should develop and adopt the core policy instruments that govern AI use across the organization, aligned to the NIST AI RMF Govern function. These include: an AI acceptable-use policy defining permitted and prohibited uses; an AI intake and approval process with defined risk-tiering criteria; data governance standards governing what information may be inputted into AI systems (with specific attention to confidential, proprietary, and personally identifiable data); vendor selection and oversight standards; and an AI incident response playbook defining what constitutes a reportable AI incident, who is notified, what the investigation and remediation process is, and how the board committee is informed. The incident response playbook is not optional. Under TRAIGA, Colorado SB 26-189, and the EU AI Act’s Article 73, incident reporting obligations attach to deployers of high-risk AI systems. Under Caremark, the failure to respond to a known AI system failure is the conscious disregard that creates personal director and officer liability.
Step 6: Build and Maintain the AI Inventory
The AI governance committee should direct management to build and maintain a complete, current catalog of every AI system in use across the enterprise, including shadow AI (employees using consumer tools such as ChatGPT or Claude without formal approval), AI features activated within licensed SaaS platforms, and legacy statistical or machine learning models. The inventory is the foundational artifact of the entire governance program. Every downstream obligation, including risk classification, validation, monitoring, and vendor oversight, presupposes knowing what systems the company has. A board cannot demonstrate the good-faith information and reporting system Caremark requires when it cannot identify what AI the company is running.
Step 7: Negotiate AI-Specific Vendor Contracts
For each AI system sourced from a third-party vendor, counsel should negotiate terms that reflect the deployer’s legal accountability, not merely accept vendor-drafted boilerplate. At minimum, AI vendor agreements should address: explicit prohibition on using company data to train the vendor’s models without consent; notification obligations when the model is materially updated or its behavior changes; audit rights or third-party attestation (SOC 2, ISO/IEC 42001); indemnification coverage that is substantively meaningful (not capped at the monthly subscription fee) for IP infringement, data breaches, and regulatory violations attributable to the vendor’s system; and defined performance metrics with remediation obligations. For companies building on foundation model APIs, the analysis must also cover the provider’s terms of service governing permitted uses, data retention, and IP ownership of outputs. The DGCL § 141(e) protection for good-faith reliance on experts depends on the quality of that reliance; blind acceptance of vendor terms does not qualify.
Step 8: Train Users and Communicate Policies
The AI governance committee should implement a training and communication program ensuring that employees who use AI systems understand the applicable policies, the limits of permitted use, the data handling requirements, and the escalation pathway when something goes wrong. AI literacy is not only a governance best practice; it is an explicit obligation under the EU AI Act’s Article 4 (which has applied since February 2, 2025 and reaches EU-market-exposed U.S. companies) and is increasingly reflected in domestic regulatory expectations. Policies that exist on paper but have not been communicated or trained provide little protection: the documentary record of training and acknowledgment is part of what a court or regulator examines when assessing whether governance was substantive or merely nominal.
Step 9: Monitor, Measure, and Escalate
Post-deployment oversight must be continuous, not episodic. The AI governance committee should implement performance monitoring aligned to the NIST AI RMF Measure function: tracking against defined baseline metrics, scheduled bias and accuracy reviews, and defined thresholds that trigger escalation when performance degrades. AI models are not static; drift is a governance event, not a technical nuisance. Declining alert rates, anomalous outcome patterns, divergence between model outputs and external signals such as regulatory inquiries or employee complaints, and any known model updates by the vendor are each events that require documented response. The failure to act after such signals is the conscious disregard that Stone v. Ritter and Boeing describe. The board committee should receive AI risk reports on a regular cadence, quarterly at minimum for companies with material deployments, with substantive discussion documented in the minutes.