Posted
By

The recent surge in data center financing has typically encompassed both physical data center facilities and the graphics processing unit (GPU) systems housed within them. However, the debt markets for AI infrastructure are beginning to move beyond this integrated model, and GPU systems are increasingly being financed separately from the longer-lived data center assets that support their operation.

In “Financing Compute: Legal Risks and Opportunities in the Emerging GPU Asset Class,” colleague Philip Tendler explores how, as AI infrastructure finance evolves and GPU systems become separately financeable, new opportunities and new questions emerge about collateral, cash-flow separation and interdependent project risk.

Posted
By and

Key Takeaways

  • Creating an effective contract structure is a critical part of the infrastructure GPUaaS providers need to scale, helping them monetize different forms of capacity without assuming risks beyond their control.
  • GPUaaS offerings now range from interruptible, on-demand capacity to reserved servers, dedicated clusters, and managed endpoints. Service levels, billing rules and remedies should reflect the unique nature of the particular offering and measure performance at the level at which a failure actually affects the customer.
  • Customer-facing commitments should be tested against the host, data center, power, fiber and platform arrangements supporting the service, so providers understand where they may be taking on risk controlled by others.

GettyImages-1358735631-300x193GPU-as-a-Service is moving beyond arrangements focused on large, dedicated clusters. Customers can increasingly rent individual GPUs or servers on demand, reserve capacity for a defined period, purchase interruptible compute at a discount, or consume inference through a managed endpoint.

Continue reading

Posted
By , , and

The European Union’s AI Act entered a new phase on August 2, 2026, marking two years since its entry into force. Most immediately, the transparency obligations in Article 50 now apply to a broad range of AI systems and their providers and deployers, and the AI Act’s enforcement machinery is operational for obligations that are already in force.

August 2, 2026, was also the date on which the core requirements for “high-risk” AI systems were due to become applicable. That did not happen, however. Following political agreement reached by the EU institutions and the later publication of the Digital Omnibus Regulation on AI (“AI Omnibus Regulation”), those requirements have been postponed until December 2, 2027, for Annex III standalone use cases and August 2, 2028, for most product-related systems.

Continue reading

Posted
By

A talent and knowledge gap in the AI space means many organizations are outsourcing the development and management of their agentic architecture.1

The structure of these engagements is as follows: Company A partners with Company B to use Company B’s skills, talent and know-how to create and manage a technological tool or set of tools, with varying degrees of customization and capability. Company B may sweeten the deal with their own unique methodology, platforms or proprietary pieces of the software stack. Company B may go away once the tools are developed, or they may be retained for managed services or lifecycle management and support. As a result of the transaction, Company A has a production-deployed tool poised to do a specific task or to function broadly throughout their IT environment.

Continue reading

Posted
By , , and

As of June 19, 2026, the Data (Use and Access) Act 2025 (DUAA) has brought into force new complaints-handling requirements for controllers under the UK data protection regime. (See our previous post on the DUAA here.) While many businesses already operate customer complaint or data subject rights processes, the DUAA now places specific statutory obligations on controllers to receive, acknowledge, investigate and respond to data protection complaints received on or after June 19, 2026.

Continue reading

Posted
By and

As a stakeholder considering the implementation of an MCP connector, it may be difficult to glean from product documentation or marketing materials alone how the tool is functioning, and what must be done to manage its implementation.

MCP connectors provide a standardized way to connect AI models to external systems, allowing for easier proliferation of agentic AI. However, these connections also introduce new risks, including data access and privacy liability; unauthorized or erroneous actions; security vulnerabilities; accountability and governance; and third-party mismanagement.

Continue reading

Posted
By and

Before reading the first three installments of Pillsbury’s MCP connector series, you may have thought MCP-connected agentic architecture was too complicated to understand. But now that you have wrapped your mind around what MCP connectors are, what legal and operational risks they pose, and how to practically mitigate those risks, you may feel ready to deploy them in your organization. But not so fast…

Continue reading

Posted
By , , and

Under Directive (EU) 2023/2673, online traders must provide a dedicated, user‑friendly withdrawal function—often described as a “cancel contract” or “withdrawal” button—allowing consumers to exercise their 14‑day right of withdrawal as easily as they entered into the contract. (Please see our earlier article on the issue.)

Continue reading

Posted
By , and

In the most recent installment of our series on Model Context Protocol (MCP) connectors, we closed with this observation: Organizations that will manage MCP connector technology effectively are those that treat deployment as an enterprise risk concern. We promised a practical starting framework for how to think about mitigating those enterprise risks.

In this installment, we provide that framework through a hypothetical (and associated risk incidents) that illustrate how the risks may manifest in practice, annotated with suggested mitigants that may have prevented—or meaningfully limited—each issue.

Continue reading

Posted
By and

Providers have recently moved towards enabling AI agents to maintain persistent context and memory across interactions rather than treating each request as an isolated event. The environment makes it easier for enterprise AI systems to be designed to remember data and materials input and output from the tool.

Continue reading