ABOUT AI, MCP & API LEGAL MATTERS

MCP Is AI's USB-C, But…On the contracts side, however, the chain has become more complex. This piece looks at what counts as new contractual practice when it comes to API agreements and AI integrations, and what is old wine in new bottles.

Everyone probably knows USB-C, but MCP may not be quite as familiar yet. It isn't a physical connector but a shared way of describing a piece of software's functions so that AI knows how to use them. Underneath it there is always an interface, or API, which is the software's service hatch through which it offers its functions to other software. Interfaces as such are nothing new, but their use and importance have grown sharply in recent years, and MCP gives them a common language: instead of every connection being coded separately, the AI can ask a service what it can do and then use it. Hence the nickname "AI's USB-C."

A Chain, Not a Connection

In my view, the key to understanding the whole picture is that AI integrations involve a chain, not a single connection.

A salesperson asks the assistant to prepare a quote, and the AI retrieves customer data from the CRM, reads the previous draft contract from cloud document storage, checks the pricing rules from an internal source, formats the quote, saves it to the cloud and sends a summary to the messaging platform. For the user, it's one request and one response. Legally, six transfers took place, each potentially involving a different counterparty, different terms and a different role.

Old Wine in New Bottles

Contract practice in this context, however, is largely the same as what has been seen in IT and software agreements for years. The supplier is not liable for components it does not control, and the terms for third-party components are agreed to separately. Third-party features enabled by the customer are not part of the delivery, and no warranties are given for third-party APIs. The customer warrants that it has the rights to the data it inputs.

The upshot is that attention should focus on the start of the chain: the customer's decision about what material it puts in at all.

In this context, I'd like to highlight a couple of fairly recent developments in contract practice.

Anonymisation and Its Documentation

When responsibility for the input data lies with the customer, the natural way to manage it is to limit the material going in, which is why anonymisation and pseudonymisation have entered the discussion around AI chains. The bar, however, is higher than often assumed, and it is moving: the European Data Protection Board is updating its guidance on anonymisation, and the direction appears to be towards relative identifiability. The same data can be personal data in one party's hands and anonymous in another's. In a chain, the assessment would then need to be made step by step. The key point is that documentation is part of the protection itself: a claim of anonymisation won't hold up in a contract or before a regulator if the method and the basis for the assessment haven't been recorded.

Risk Categories and a New Dimension to Terms of Use

A new layer comes from regulation. Under the AI Act, the risk category is determined mainly by the area of use rather than by the technology, and the high-risk category brings significant documentation requirements and process descriptions. What's interesting from the chain's perspective is that the category can change without anyone touching the contracts: a single new connector can quietly move a use case from one category to another. The same tool can be lightly regulated in one use and a high-risk system in another.

This has also led suppliers to impose additional requirements, such as review by a qualified professional before the output is used and informing the end user that AI has been used. Suppliers' terms of use therefore reach all the way into the customer's own work processes: they don't just say what you may not do, but how the work must be organised and who reviews it.

For example, for this article, the reader would be shown a notice: AI was used in preparing this text, and it was reviewed by a lawyer specialising in the subject.

If you'd like to discuss MCP, APIs or other AI-related legal matters further, send a message to Legaunsel.