A lot of us know audit rights. If you have done any vendor work, any data processing agreement, any outsourcing deal, you have negotiated one. They are standard, and they are standard for a good reason.

The logic is old and sound. When you are relying on someone else to hold your data, run your process, or meet a security standard, you do not just want their promise that they are doing it. You want the right to check. Financial services contracts have them. Data processing agreements require them. Outsourcing deals live and die on them. The audit right is how a customer keeps a supplier honest across a long relationship.

So when AI vendors started handing us contracts with audit rights already in them, most of us treated it as a solved problem. The clause is there. It looks like the ones we know. Move on.

Then you try to imagine exercising one against an AI vendor, and you realise the familiar clause is doing something very unfamiliar, and failing at it.

This is because AI breaks almost every assumption the traditional audit right was built on. The thing you are auditing changes between audits. The information you would most want to see is exactly what the vendor calls proprietary. And the stakes of not being able to look, discrimination exposure, privacy exposure, decisions being made about real people, are higher than anything a SaaS uptime audit was ever designed to catch.

Why AI Changes the Audit Question

A traditional SaaS audit right is about verifying fairly stable things: security controls, uptime records, data handling. The system does not change much between audits.

AI is different on every axis. The model changes. Performance drifts. Training data provenance is contested and litigation-sensitive. Outputs affect your customers and employees in ways that can trigger discrimination, privacy, and consumer protection exposure. And critically, you often cannot see any of this from the outside. The vendor holds all the information about how the system behaves.

That combination, high stakes plus low visibility, is the situation audit rights exist to address. Which is why a hollow audit right in an AI contract is worse than in ordinary software. You are relying more heavily on a mechanism that has been drafted to do less.

What to Demand, and How Far You Will Get

Work it as a sequence rather than a wish list.

Start With What Any Serious Vendor Can Hand Over Today

The workable core of AI audit rights is rarely your own auditors deep in the vendor’s systems. It is the right to receive what the vendor already produces: their third-party audit reports and security attestations, SOC 2 and ISO 27001 for the security layer, and increasingly ISO 42001 for the AI management system, where the vendor holds it. Treat each of these as evidence about defined controls, not as proof that the model itself is accurate or fair, that is a different question these reports were never designed to answer. Sharing them costs the vendor nothing. Alongside that, you want the audit right itself drafted on terms that survive contact with reality, proportionate notice rather than a flat ninety days, shorter still if you are responding to a live incident, the ability to act on cause rather than waiting for an annual window, and a scope defined by what you need to verify rather than by what the vendor is comfortable showing.

Push on What Your Specific Deployment Needs

If the system makes or influences decisions about people, your audit rights have to reach fairness, not just security. Bias and fairness audit results matter particularly where the tool touches hiring, lending, or other consequential decisions. In some cases this is not optional. New York City’s Local Law 144 requires covered employers and employment agencies, not the AI vendor, to commission an independent bias audit before using such a tool, together with a public summary. Because that obligation sits with you as the employer, your contract needs to secure the vendor’s cooperation and the underlying data required to run the audit, not just a promise that a right exists.

Your data and your risk also do not stop at the vendor’s boundary, so audit or attestation rights should extend to material subprocessors, or the vendor should flow those rights down and share the results. And audit rights work best alongside the two clauses they depend on: notice of material model changes, and disclosure of incidents. The audit right lets you verify. Change notice and incident disclosure tell you when to.

Be Clear-Eyed About What the Market Will Not Give You Yet

For high-stakes deployments, leading practice is now pushing toward the right to commission independent evaluation or red-teaming of the system as deployed for your use case. Against a domain-specific vendor competing hard for your deal, you may get it. Against a frontier provider on take-it-or-leave-it terms, you almost certainly will not, and a partial version, access to the vendor’s own red-team results, is the realistic win.

Why Your Own Compliance Depends on This

Regulation is increasingly placing obligations on you as the deployer of an AI system, not just on the vendor as the provider. Under the EU AI Act, deployers of high-risk systems carry their own obligations around oversight, monitoring, and documentation. Those obligations cannot be contracted away. And you cannot discharge a duty to oversee a system you have no contractual right to inspect. Your audit rights are part of how you demonstrate that you are meeting your own regulatory duties, not just checking on the vendor.

The insurance market is reinforcing the same point from a different direction. Some major carriers have begun excluding or narrowing AI-related liability in corporate policies through 2025 and 2026, though coverage still varies considerably by policy, insurer, and jurisdiction, so do not assume insurance will simply absorb the loss. Where that backstop is thin or absent, the exposure lands directly on the organisation, and the general counsel and CFO become the primary risk owners.

When Refusal Is Itself Information

When a vendor refuses any meaningful audit right or verification mechanism at all, and offers no credible substitute, independent assurance, regulator cooperation, controlled evaluation access, that refusal is itself information. A vendor whose safety, security, and fairness claims cannot be reviewed by anyone outside their own walls is asking you to take those claims entirely on trust.

You may still decide to proceed. Sometimes the tool is worth it and the leverage is not there. But you should proceed knowing that you accepted unverifiable claims, and you should price that risk accordingly.

This newsletter is for discussion and informational purposes only and is not legal advice for any specific situation or jurisdiction. Audit rights, deployer obligations, and regulatory requirements vary by jurisdiction, system, and role. Regulatory positions current as of mid-2026. Not exhaustive.

Until the next time,

- Anjola Ige

What AI Vendors Commit To, and Who Carries the Risk When It Goes Wrong

I negotiate AI contracts from the buyer’s side. When you sit across the table as the customer buying enterprise AI, you develop a particular skill: reading past what the vendor’s product page promises and into what the contract obliges them to deliver. The gap between those two things, in AI contracts specifically, is wider than in almost any other category of software I’ve negotiated.

The reason is structural. AI is probabilistic. It does not produce the same output twice, it cannot guarantee accuracy, and its performance drifts as models are updated. Vendors know this. So their contracts are drafted to promise as little as possible about the one thing you care about: whether the thing works.

What the Providers Warrant

Start with the warranty. This is where a vendor tells you, in binding language, what they’re standing behind.

According to Lawinsider, OpenAI’s business terms warrant that the services will conform in all material respects with the Documentation. Read that carefully. The warranty is not that the output will be accurate, useful, or fit for your purpose. It is that the service will behave the way the documentation says it behaves. If the documentation says the model generates text based on probability, and it generates text based on probability, the warranty is satisfied, even if the text is wrong.

Then comes the disclaimer, and this is where the real allocation happens. OpenAI’s terms state the services are provided “AS IS” and expressly disclaim warranties of merchantability, fitness for a particular use, or non-infringement. They go further, making no guarantee that the services will meet the customer’s requirements or that output will be accurate.

The accuracy risk is then transferred to you explicitly. OpenAI’s terms provide that the customer is solely responsible for evaluating the accuracy and appropriateness of output for its use case. Anthropic’s commercial terms make a similar acknowledgment, that outputs may contain material inaccuracies even if they appear accurate because of their detail or specificity.

None of this is unusual or exploitative. It is industry standard. But standard does not mean neutral. These disclaimers move a substantial share of the risk of the AI being wrong from the party that built it to the party that relies on it, though other terms in the same contract, security obligations, indemnities, confidentiality commitments, can allocate different risks back the other way. Still, on accuracy specifically, that is the deal you are signing.

The SLA Problem: What “Performance” Even Means for AI

A normal SaaS SLA measures things you can count: uptime, response latency, resolution time. If the service is down more than the agreed threshold, you get service credits. Clean, measurable, enforceable.

AI performance is different, because the thing you care about, the quality of the output, is exactly the thing vendors will not put a number against. You will find uptime commitments. You will not find accuracy commitments.

And even the uptime commitments deserve scrutiny. Anthropic announced a 99.99% enterprise SLA in March 2026, but reporting indicates it is negotiated case-by-case rather than published as a standard term, with service credits typically capped at 5 to 10% of monthly fees. That cap matters enormously. Worth doing the arithmetic: a 99.99% monthly commitment only tolerates around 4.3 minutes of downtime before it is breached, so a genuinely prolonged outage is already a serious breach in its own right, separate from whether the capped credit is an adequate remedy for it. A credit capped at 5 to 10% of monthly fees can be financially insignificant relative to what a serious, prolonged outage costs your operations. Independent monitoring has also reported gaps between claimed and actual uptime on some tiers.

So even where a metric exists, two questions follow: is it the metric that matters to you, and is the remedy for missing it worth anything?

Where the Accountability Negotiation Happens

Because vendors will not warrant accuracy, the negotiation over AI performance is really a negotiation over who carries the risk of the uncertainty. You are unlikely to get a vendor to guarantee output quality. That is not a realistic ask, and frankly, a vendor who promised it would be one to distrust. But there are specific, achievable moves that shift the risk allocation back toward something defensible.

Define Performance Against Your Benchmark, Not Their Documentation

If a vendor claims a capability, a given accuracy rate on a defined task, a reduction in processing time, get it into the order form as a specific, measured commitment against an agreed test set, not left to the general “conforms to documentation” warranty. If they will not commit to the number in the contract, treat the number on the sales deck as marketing, not a promise.

Negotiate an Acceptance Testing Period

Before the contract locks in, run the tool against your actual use case for a defined period, with the right to walk away or renegotiate if it does not hit an agreed performance threshold. This converts an unmeasurable promise into a tested reality before you are committed.

Make Material Model Changes a Trigger

AI performance drifts when the vendor updates the underlying model. Your contract should require notice of material model changes and give you rights, renegotiation, testing, or exit, if a change materially degrades performance for your use case. OpenAI’s own terms give customers a termination right if security measures are materially diminished. The same logic should apply to performance.

Size the SLA Credit to Your Actual Exposure

A credit capped at a fraction of monthly fees is not a remedy, it is a rounding error. Where the AI system is business-critical, push for credits that bear some relationship to the operational cost of failure, and consider whether a sustained performance failure should be a termination event rather than just a credit event.

Keep a Fallback and Never Build a Single Point of Failure

This is not a drafting point, it is a commercial one, but it is the most important. The strongest negotiating position with any AI vendor is the credible ability to leave. Multi-provider flexibility is leverage.

What This Looks Like in Practice

AI vendors are not going to warrant that their probabilistic systems produce accurate outputs, and it would be commercially naive to expect it. But that does not mean you accept the standard risk allocation as written.

The vendor’s default contract transfers essentially all performance risk to you. Your job as the buyer is to claw back the pieces that matter: measurable commitments where a real capability is being sold, testing rights before you commit, notice and exit rights when the model changes underneath you, and remedies that cost the vendor something when they fail.

You will not win all of these. On a genuinely one-sided market, and parts of the AI market are still one-sided, you may win a few of them. But the exercise of asking tells you something important before you sign: how confident the vendor is in the thing they are selling you.

Read the warranty. Read the disclaimer. Then decide who is really carrying the risk.

This newsletter is for discussion and informational purposes only and is not legal advice for any specific situation or jurisdiction. Contract terms cited are drawn from publicly available provider terms and reporting current as of mid-2026. Specific terms vary by product, tier, and negotiation, and change over time. Not exhaustive.

Until the next time,

- Anjola Ige

A company won $20 million at trial. Then lost all of it because of how one assignment clause was drafted.

In Rasmussen Instruments v. DePuy Synthes, decided by the Federal Circuit on 6 October 2025, a jury had awarded Rasmussen $20 million for patent infringement. The Federal Circuit vacated the judgment and ordered dismissal for lack of subject-matter jurisdiction. It did not decide infringement on the merits. The problem was standing: Rasmussen did not clearly own the patents at the time it filed suit, thanks to imprecise assignment language, and so had no standing to sue at all.

An earlier agreement had assigned the relevant patent rights to another company. When that relationship ended, the paperwork meant to move ownership back did not expressly reassign the patents before Rasmussen filed suit. Twenty million dollars turned on the drafting of who owned what, and when.

This is the clearest possible reminder of something counsel know in theory and underweight in practice: the distinction between assignment and licensing, and the precise terms of each, is not academic.

The Core Distinction

Assignment transfers ownership. After a valid assignment, the assignee owns the IP outright. The assignor has nothing left, unless the agreement carves something back.

Licensing grants permission to use. The licensor retains ownership and gives the licensee a defined right to use the IP within agreed limits. Ownership never moves.

That difference sounds obvious. The trouble is that contracts routinely blur it, use the words loosely, or fail to specify the terms that determine what the exact grant is. And the consequences of that imprecision could arise at the worst possible moment: in litigation, in a financing round, in an acquisition due diligence, or when a relationship ends and both sides discover they understood the arrangement differently.

Standing to Enforce

Rasmussen is the cautionary tale. If you do not clearly own the IP, you cannot sue to enforce it. A licensee generally cannot bring an infringement action alone unless the licence is effectively an exclusive one that transfers substantial rights. If enforcement matters to you, the ownership position should be unambiguous, in writing, and effective.

Revocable Versus Irrevocable Licences

This is the distinction within licensing that catches people out. A revocable licence can be terminated by the licensor, either at will or on defined conditions. An irrevocable licence cannot be, except as expressly stated in the termination provisions. If you are building your product, your service, or your business on top of licensed IP, and the licence is silent on revocability or expressly revocable, you are exposed. The licensor can pull the rug. Everything you built on that foundation is at risk. When you are the licensee relying on the IP, you want irrevocable, or at minimum a licence that cannot be terminated for convenience.

Perpetual Versus Term-Limited

A perpetual licence continues indefinitely. A term licence ends. These are separate from revocability, and both need to be specified. A licence that is irrevocable but term-limited still ends when the term does. A licence that is perpetual but revocable can still be pulled. You need to know which levers are in your agreement, because they interact.

Sub-Licensing and Assignment of the Licence Itself

Can the licensee sub-license the rights? Can the licence be assigned to a third party, for instance in an acquisition? If you are acquiring a company whose value depends on licensed IP, whether that licence survives the change of control is a due diligence question that can move the price or kill the deal.

Future Improvements and Derivatives

Rasmussen touched this too, and a related Federal Circuit line of cases makes the point as well: an assignment of a specific invention does not automatically carry future improvements unless the language says so. If you are assigning or taking an assignment, be explicit about whether improvements, derivatives, and related IP developed later are included.

The AI Dimension, Because It Is Unavoidable Now

The assignment versus licensing distinction has become newly complicated in AI contracts.

When an AI vendor’s terms say “you own the outputs,” look closely at what that means. In many cases it operates less like an assignment of ownership and more like a grant, because the vendor may be giving the same or similar outputs to other customers, and because the outputs may not be copyrightable in the first place if they lack sufficient human authorship. “You own the output” can be a weaker promise than it sounds. If your business model depends on owning and enforcing rights in AI-generated material, the gap between the language and the legal reality is something to map before you rely on it.

Similarly, when you feed your own proprietary content into an AI tool, check what rights you are granting the vendor over that input. You may be granting a broader licence than you intend.

Before You Sign Anything Involving IP

Get clear answers to a short set of questions. Is this an assignment or a licence? If it is an assignment, does it cover future improvements and related rights, and is the transfer effective and clean? If it is a licence, is it revocable or irrevocable, perpetual or term-limited, exclusive or non-exclusive, and can it be sub-licensed or assigned onward?

Rasmussen had a $20 million verdict in hand and lost it on the ownership question.

That’s assignment and licensing. The second piece of this issue is a different problem entirely: it looks into what Article 50 of the EU AI Act, now in force as of 2 August 2026, requires of your organisation, and why the regulatory floor is not the same as the transparency you should be demanding for yourself.

Article 50 Is Now in Force. The Regulatory Floor Is Not Enough.

Everyone spent the first half of 2026 hearing that EU AI Act enforcement got delayed. One of the most consequential obligations arrived exactly on schedule anyway.

The Digital Omnibus pushed the high-risk system deadlines back to 2027 and 2028. That got the headlines. What got lost is that the AI Act’s transparency obligations, the ones that touch everyday generative AI deployments, chatbots, image generators, AI writing assistants, were left untouched and took effect on 2 August 2026 as originally scheduled.

If you are a legal or governance professional dealing with AI, transparency is now operating on two levels at once: what vendors are legally required to disclose, and what you should be demanding they disclose regardless of what the law compels.

The Regulatory Floor: What Article 50 Requires

Article 50 of the EU AI Act sits outside the risk-tiered structure entirely. It does not attach to whether a system is high-risk. It attaches to what the system does. Four situations, each with a named party who has to speak up.

Chatbot disclosure. If an AI system interacts directly with people, the provider must design it so users know they are dealing with a machine, unless that is obvious from context. The practical standard is strict. The disclosure has to be at the start of the interaction, in the interface itself, something to the effect of “you are chatting with an AI assistant.” A line buried in your privacy policy does not meet the standard, and a disclosure that appears after the conversation is worthless.

Synthetic content marking. Providers of generative AI systems must mark outputs, audio, image, video, text, in a machine-readable format so the content is detectable as artificially generated. Watermark, metadata, C2PA-style provenance. This obligation sits with the provider supplying the tool, and the final Code of Practice expects at least two layers of marking where necessary, plus detection mechanisms.

Emotion recognition and biometric categorisation. If a system recognises emotions or categorises people biometrically, exposed individuals must be informed. And this one comes with a warning: screen the use case against the Article 5 prohibitions first, because some emotion recognition is banned outright, not merely subject to disclosure.

Deepfake labelling. Anyone deploying a system that produces deepfake image, audio, or video content must disclose that the content is artificially generated or manipulated.

The scope is broad and it reaches beyond the EU. The obligations follow the content and the users, not your headquarters. A UK or US company running a chatbot for EU customers, or publishing AI-generated campaigns to EU audiences, is in scope. Penalties run to €15 million or 3% of worldwide annual turnover, whichever is higher.

One timing nuance: the marking obligation for generative systems already on the market before 2 August 2026 has a grace period to 2 December 2026. The disclosure duties for chatbots and deepfakes did not get that grace period. They are live now.

Why the Regulatory Floor Is Not Enough

Article 50 tells vendors what they must disclose to end users. It says very little about what a vendor must disclose to you, the business customer procuring and deploying their system.

This is important for in-house counsel and governance teams, because when an AI system you deployed causes a problem, a biased output, a data exposure, a hallucination acted upon, the regulator and the affected parties will look to you, the deployer, not just the vendor. Your ability to demonstrate that you understood what you deployed depends entirely on what the vendor told you. So the transparency you need is contractual. It has to be built into the procurement process and written into the agreement.

What to Demand, and How Hard Each Is to Get

Not everything on this list is equally gettable. Your leverage, enterprise spend, a competitive deal, being the bigger name, determines how much you secure. Think in tiers rather than treating this as one list.

Table Stakes: You Should Get These, and Refusal Is a Red Flag

These cost the vendor almost nothing because they already exist. Asking is routine.

Existing third-party attestations. SOC 2 and ISO 27001 for the security layer, and increasingly ISO 42001 for the AI management system. You are asking to receive reports the vendor already commissions.

Published model and change documentation, and a subprocessor list with a commitment to notify you of changes. Again, this exists. You are asking for access and notice, not for the vendor to build something new.

Confirmation of their own Article 50 compliance. Since the marking and disclosure obligations sit substantially with providers, get contractual confirmation that the vendor meets them for the tool you are deploying, particularly machine-readable marking of synthetic content. If you are the deployer relying on their marking to meet your own disclosure duty, you need that in writing.

If a vendor will not share even these, that tells you something before you have signed anything.

Worth Pushing For: Achievable With Real Leverage, Often Via an Addendum

You will not always win these, and when you do it is frequently through a negotiated addendum rather than by redlining the vendor’s core terms. But they are realistic asks for a meaningful buyer.

Material model-change notification, with enough lead time to test and, if necessary, exit. AI performance drifts when the model is updated, and you need visibility before the change, not after.

Incident disclosure scoped to your use case or model class, on a defined timeline. Five business days is reasonable. Ninety is not. A quarterly incident log scoped to the vendor’s platform is a fair ask.

Bias and fairness audit access for consequential systems. If the AI influences decisions about people, your rights need to reach fairness, not just security. Where regulation already mandates a bias audit, New York City’s Local Law 144 for automated employment tools is the clearest example, your contract should guarantee you access to it.

Audit or attestation rights that flow down to material subprocessors. Your data and your risk do not stop at the vendor’s boundary, and neither should your visibility.

Only With Serious Leverage: Real Against Smaller Vendors, Largely Aspirational Against the Majors

Be clear-eyed here. A domain-specific vendor competing hard for your deal may grant these. A frontier provider on take-it-or-leave-it terms almost certainly will not, and pretending otherwise wastes everyone’s time.

Bespoke training-data provenance disclosure. You can ask what categories of data the model was trained on and what representations the vendor will make about lawfulness. Full provenance disclosure from a major provider is not realistic today, partly because they treat it as proprietary and partly because it is litigation-sensitive.

Your own auditors inside the vendor’s infrastructure, or independent red-team access to the deployed system. This is leading practice for critical deployments and worth pursuing where the stakes justify it, but against large vendors you will usually have to settle for their own third-party reports and red-team results rather than your own access.

Regulatory Transparency and Contractual Transparency Are Solving Different Problems

Article 50 protects the end user who interacts with AI. Your vendor contract protects you, the organisation that deployed it and carries the accountability for what it does.

The law is now setting a floor on what vendors disclose to the public. It is not setting the ceiling on what you should demand for yourself.

Ask. Get it in writing. Then decide.

This newsletter is for discussion and informational purposes only and is not legal advice for any specific situation or jurisdiction. IP assignment and licensing principles vary by jurisdiction and IP type. Case references are to publicly reported decisions. Article 50 obligations and timelines are current as of mid-2026 and subject to guidance and change. Scope depends on your role, system, and market. Not exhaustive.

Until the next time,

- Anjola Ige

Look who arrived on my desk this week. Contract Nerds sent me Clausey, their mascot, and I may be more delighted than a grown contracts lawyer should admit.

It came off the back of a piece I wrote for them on strengthening your Data Processing Agreement from the controller’s side, the terms most DPAs quietly tilt toward the processor, and how to pull them back. If DPAs are your thing, it is worth a read: How to Improve Your Data Privacy Addendum (Pro-Controller).

This is the perfect segway into my contract topic for this issue.

You see, that Contract Nerds piece was about getting one document right, the DPA. But a well-drafted DPA is worth very little if it is sitting in a folder next to a privacy policy that does not exist and a ToS that describes a company you are not yet.

Enterprise buyers do not review your documents one at a time. They review the folder. And the folder is where a surprising number of deals quietly stall.

The Documentation Gap That Stalls Enterprise Deals

A founder reached out to me recently. Excited. Pipeline full. One enterprise client ready to sign.

They just needed their legal documents reviewed before the client’s procurement team signed off.

I opened the folder. No Privacy Policy. A Data Processing Agreement that was four lines long, title, parties, date, and a blank where the obligations should have been. A Security Policy that described, in confident detail, the security posture the company intended to have. Not the one it had.

The enterprise client’s legal team had already flagged the DPA. Procurement was on hold. The deal, weeks in the making, was sitting on a documentation gap that would take a fraction of that time to fix properly. But nobody had built the foundation before the pipeline got full.

This is more common than founders think. And it almost always surfaces at the worst possible moment, when there’s a client ready to sign and a procurement team with a checklist.

The Pattern With Early-Stage Startups

The product gets built. The pitch gets refined. The sales motion gets developed. Legal documentation gets deferred, or assembled quickly from whatever is available. A competitor’s privacy policy, lightly edited. A terms of service template from a legal document website. A DPA generated by an AI tool and never reviewed against the actual data flows of the business.

The issue isn’t that founders don’t care about legal documentation. Most do. The issue is that standard terms feel like a compliance exercise, something to check off, rather than a commercial asset. And so they get treated accordingly: minimum viable, good enough for now, we’ll fix it when we need to.

Enterprise clients, however, often review your terms substantively, even where they also treat them partly as a compliance checklist. Their legal and procurement teams read them. They compare what your Privacy Policy says against what your product does. They look at your DPA and ask whether the data processing obligations are specific enough to satisfy their own regulatory requirements. They review your Security Policy and assess whether it reflects operational reality or aspirational thinking.

When there’s a gap between what your documents say and what your business does, or when the documents simply don’t exist, the deal stalls. Sometimes it dies.

What a Complete Suite of Standard Terms Needs to Cover

A proper foundation for a SaaS or legal tech company typically includes the following:

A Master Services Agreement or Terms of Service

One that reflects how the product works: how it’s licensed, what the service includes, what it doesn’t, how liability is allocated, and what happens when things go wrong. Not a generic software agreement. One that maps to the specific commercial model.

A Privacy Policy

One that accurately describes what data is collected, why, how it’s used, how long it’s retained, and what rights data subjects have. Not copied from a competitor whose data flows are different. Not generated and forgotten. One that reflects the product itself.

A Data Processing Agreement With Substance

Controller and processor obligations, sub-processor lists, security measures, breach notification timelines, data subject rights mechanisms, deletion and return provisions. Many enterprise clients in regulated sectors will reject a four-line DPA outright, and those whose own regulatory obligations require adequate contractual protections with their vendors will, at minimum, negotiate it, amend it, or replace it with their own form.

An Acceptable Use Policy

One that defines what the platform can and cannot be used for. Particularly important for AI-powered tools, the AUP is where you establish boundaries around use of outputs, prohibited inputs, and human oversight requirements. Without it, you may have a far less tailored contractual basis for terminating a client who is misusing the platform. General breach and termination provisions in the MSA or Terms of Service may still support termination, but they will rarely map cleanly onto misuse.

A Security Policy That Describes Current Operational Reality, Not Aspirations

Certifications held or in progress, access controls in place, incident response procedures, third-party audit cadence. Enterprise procurement teams cross-reference this against their own vendor risk assessments. Gaps are flagged.

The Commercial Case for Getting This Right Early

Standard terms are not just a legal risk management tool. For an early-stage company selling to enterprise clients, they are a sales asset.

A founder who can send a clean, complete document folder to a procurement team, and whose terms hold up under legal review without redlines that take weeks to negotiate, closes faster. The deal that stalled for my client over a documentation gap is a deal that a competitor with proper terms would have closed without friction.

The cost of building a proper foundation once, early, is a fraction of the cost of losing one enterprise deal, or of rebuilding terms under time pressure when the client is already in your pipeline and procurement is already asking questions.

Build the foundation before the pipeline gets full. It is considerably easier that way.

This newsletter is for discussion and informational purposes only and is not legal advice for any specific situation or jurisdiction. Documentation requirements vary by jurisdiction, sector, and applicable regulation. Not exhaustive.

Until the next time,

- Anjola Ige

When “Mutual” Doesn’t Mean Equal

Mutual indemnification sounds fair. It often isn’t.

The word “mutual” in contract negotiations signals reciprocity. It signals balance. It makes both sides feel like they’ve achieved something. And in indemnification clauses specifically, it is one of the most effective ways to create the appearance of parity while preserving significant asymmetry underneath.

This is not always intentional. Sometimes it’s just what happens when both parties agree to mirror language without mapping what each side is putting at risk.

A SaaS Example That Makes It Concrete

Take a standard SaaS vendor agreement. The indemnification clause reads: each party shall indemnify, defend, and hold harmless the other from and against any third-party claims arising out of or relating to that party’s breach of this agreement, including breach of its confidentiality obligations.

Mutual. Reciprocal. Balanced on its face. Now, let’s map whose assets are at stake.

The customer’s data, personal data, financial records, proprietary business information, sits inside the vendor’s platform. The vendor processes it, stores it, and controls the infrastructure it lives on. If there is a data breach, a leak, or an unauthorised disclosure, the exposure flows almost entirely in one direction: the customer’s data subjects, the customer’s regulators, the customer’s reputation.

The vendor’s exposure is not equivalent, though it may still have meaningful exposure from security incidents, subprocessors, employee access, or compliance failures, even where the customer’s data is hosted on the vendor platform. There is no customer data sitting in the customer’s systems that the vendor has anything to lose from. Depending on the contract and operating model, the vendor’s indemnity may be narrower or broader than the customer’s, but the risk it covers here is structurally smaller, not equivalent. The customer’s obligation covers a risk that is live, material, and sits entirely outside the customer’s direct control, because the data is on the vendor’s infrastructure.

Mutual structure. Entirely asymmetric exposure. And the customer signed it thinking they had achieved balance.

Where the Structural Asymmetry Concentrates

The structural asymmetry in mutual indemnification clauses tends to concentrate in three areas.

IP Indemnification Scope

A vendor typically indemnifies the customer for third-party claims that the vendor’s platform infringes intellectual property rights. The customer typically indemnifies the vendor for third-party claims arising from the customer’s content or data. On paper, both parties are indemnifying the other for IP-adjacent risk. In practice, the vendor’s obligation covers the platform itself, a defined, known asset the vendor controls. The customer’s obligation covers everything the customer puts into the platform, an open-ended category whose scope is determined by how broadly the customer uses the tool. The customer’s indemnification exposure is structurally wider than the vendor’s, even when the clause reads identically.

Negligence and Fault Allocation

Many mutual indemnification clauses cover claims “arising out of or relating to” each party’s breach or negligence. The problem is that in a SaaS context, the vendor controls the environment in which most breaches occur. A customer cannot negligently misconfigure the vendor’s infrastructure, only the vendor can do that. A customer can misuse the platform, but the categories of misuse are usually narrower and more predictable than the categories of vendor-side failure. “Mutual negligence” indemnification in a technology contract disproportionately benefits the vendor because the vendor controls more of the variables that determine when negligence occurs.

Consequential Loss Carve-Outs Applied Asymmetrically

Most SaaS contracts exclude consequential damages for both parties, mutual again. But consequential losses from a data breach flow almost entirely to the customer: regulatory fines, loss of customer trust, third-party litigation. The vendor’s consequential losses from the same event are typically limited to reputational damage and customer churn, neither of which is recoverable in litigation anyway. A mutual consequential loss exclusion sounds balanced. In a data-intensive contract, it disproportionately caps the customer’s recovery while capping very little of practical value for the vendor.

The AI Contract Version of the Same Problem

In AI contracts, mutual indemnification asymmetry has developed a new dimension, and it is one that not a lot of customers are scrutinising carefully enough.

A typical AI vendor agreement provides that the vendor will indemnify the customer for third-party IP infringement claims arising from the vendor’s model, meaning if the model’s training data included copyrighted material and a rights holder sues. The customer indemnifies the vendor for claims arising from the customer’s use of the model’s outputs.

The vendor’s obligation is bounded. It covers a specific, known risk, training data IP claims, that the vendor has already assessed and priced into its indemnification posture.

The customer’s obligation is open-ended. It covers everything the customer does with the outputs: decisions made, content published, advice given, actions taken. If a customer relies on an AI-generated output that turns out to be wrong, a hallucinated legal citation, an inaccurate financial figure, a flawed medical recommendation, and that output causes harm to a third party, the customer’s indemnification obligation to the vendor may be triggered. Where the customer has agreed to cover “use of outputs” without carving out outputs that were wrong because the model hallucinated, the risk of the model’s own failure can end up shifted to the customer, though this depends on the specific indemnity wording and any carve-outs for hallucinations, misuse, or reliance.

In that drafting scenario, the vendor’s indemnification covers a risk the vendor controls, while the customer’s indemnification covers a risk the vendor’s model created but the customer carried.

Negotiating Past the Appearance of Balance

Mutual indemnification is not inherently problematic. The structure is appropriate when both parties genuinely carry equivalent risk categories. The problem is accepting mutual language without mapping the actual risk exposure on each side.

Before agreeing to any mutual indemnification clause, map three things: whose assets are at stake in this contract, which party controls the environment in which failures are most likely to occur, and whose consequential losses are larger if the indemnified event materialises.

If the answers to all three questions point in the same direction, as they often do in SaaS and AI contracts, the indemnification clause is not mutual in any meaningful commercial sense. And the negotiation should reflect that.

Specific pushbacks worth making: scope the customer’s data indemnification to breaches caused by the customer’s own acts or omissions, not vendor-side infrastructure failures. Carve out AI output errors caused by model hallucination or vendor-side model changes from the customer’s “use of outputs” indemnification. And if the vendor insists on mutual consequential loss exclusion, consider whether the customer’s direct losses from a data breach, regulatory fines especially, which are direct, not consequential, are adequately protected by the direct loss carve-in.

Mutual is a structure. Equal is an outcome. They are not the same thing.

The second piece of this issue looks at a different matter: where the EU, the US, and the UK have each landed on AI regulation in mid-2026, and what the divergence means in practice.

Three Jurisdictions, Three Different Bets on AI Regulation

Three major economies. Three fundamentally different bets on how to regulate AI. Mid-2026 is a good moment to take stock of where each stands, and what it means for where AI development goes next.

The EU: Comprehensive, Ambitious, and Already Being Revised

The EU AI Act entered into force in August 2024, the world’s first comprehensive, horizontal regulatory framework for AI. Its architecture is risk-based: prohibited practices at the top, high-risk systems in the middle, general-purpose AI models with their own obligations, and minimal requirements for everything else.

The most consequential provisions, covering high-risk AI systems, were originally set to apply from August 2026. Under a provisional political agreement reached in May 2026, still subject to formal adoption, they are set to be delayed. On May 7, 2026, the Council of the EU and the European Parliament reached political agreement on the Digital Omnibus on AI, deferring high-risk obligations: standalone Annex III systems would comply by December 2027, and AI embedded in regulated products by August 2028.

The deferral reflects a pragmatic acknowledgment that the regulatory infrastructure needed to make those obligations operable has not materialised on schedule, but it is a deferral, not a dismantling. The fundamental architecture of the AI Act remains intact.

What is already in force matters: prohibited practices have applied since February 2025. Transparency obligations for chatbots are due to take effect in August 2026, subject to the final adopted text, and the deferral for AI-generated content labelling is only four months, to December 2026. General-purpose AI model obligations have applied since August 2025. The Act also has extraterritorial effect: placing an AI system on the EU market can bring an organisation into scope regardless of where it is based, though the precise scope depends on the organisation’s role and the type of system or output involved.

The EU’s bet: comprehensive rules create a trusted environment that attracts responsible AI development and protects citizens. The risk: that the compliance burden slows adoption, pushes development elsewhere, and the framework becomes obsolete faster than it can be enforced.

The US: A Patchwork at Scale

The US has no federal AI law. What it has is a rapidly expanding, deeply fragmented state-level legislative landscape, and a federal government actively pushing back against it.

In 2025, state lawmakers in all 50 states introduced AI-related bills for the first time, 1,208 bills in total, with 145 enacted into law. By one mid-2026 count (TechPolicy.Press, July 2026), 29 states had enacted AI legislation this year, totalling 109 AI laws, though exact counts vary by tracker and methodology.

The picture is not uniform. California enacted a frontier model safety law in 2025; New York followed with the RAISE Act, signed in December 2025. New York’s RAISE Act was amended in March 2026, shifting toward a transparency and reporting-based framework covering model-level obligations, with incident reporting timelines of 72 hours and penalties of up to $1 million for a first violation. In 2026, Colorado repealed its 2024 AI Act and replaced it with a narrower automated decision-making transparency regime, with compliance from January 2027. Texas has its own framework. The active legislative areas in 2026 are generative AI regulation, algorithmic accountability, AI in hiring, and expanded deepfake protections.

Meanwhile, the Trump administration issued an executive order in December 2025 creating an AI Litigation Task Force charged with challenging state AI laws that were not “minimally burdensome,” and directed the Department of Commerce to explore withholding federal broadband funding for states that enact “onerous” AI laws. The result: there is evidence that federal preemption efforts have shaped the types of laws states enacted in 2026, with a shift toward child safety, data centres, and consumer protection, categories the executive order signalled it would not target.

The US still lacks comprehensive federal AI legislation. What it has is a growing patchwork of state laws operating against the backdrop of an active federal preemption push.

The US bet: innovation moves fastest in a permissive environment, and market forces, combined with targeted intervention, can manage risks without a prescriptive framework. The risk: that 50 inconsistent compliance regimes create a compliance burden for multi-state operators that rivals, or exceeds, the EU’s, without any of the harmonisation benefits.

The UK: Principles First, Law Later and Still Waiting

As of mid-2026, reports indicate no standalone AI Bill has been introduced before Parliament. The UK’s approach since the 2023 AI White Paper has been deliberately sector-led: existing regulators, the ICO, FCA, Ofcom, MHRA, CMA, apply AI governance within their existing statutory remits, guided by five non-binding cross-sector principles: safety, transparency, fairness, accountability, and contestability.

The AI Opportunities Action Plan released in January 2025 shifted the focus of regulators toward promoting AI in their sectors rather than regulating it. The government renamed the AI Safety Institute the AI Security Institute, a signal about where its priorities lie. Ministerial signals through 2026 have confirmed the direction. The UK’s pitch is now about being the country that sets standards for how AI is deployed, working with like-minded nations on shared standards. The language has shifted from “safety” to “growth.”

What is in force: the Data (Use and Access) Act 2025, with phased implementation between 2025 and 2026, liberalised automated decision-making rules and introduced AI-friendly data reforms. Sector regulators are publishing AI-specific guidance within their existing frameworks. The AI Growth Lab, a national programme of regulatory sandboxes, is being stood up to allow controlled experimentation with regulatory flexibilities.

UK AI regulation in 2026 is not one law. It is five overlapping regimes with different rules, different risk thresholds, and different enforcement bodies. For a UK enterprise with EU customers, this means mapping both, because the EU AI Act’s extraterritorial reach pulls UK organisations into its scope regardless of what UK law says.

The UK bet: flexibility and sector expertise produce better outcomes than a comprehensive statute that becomes outdated before it’s fully implemented. The risk: that the absence of legal certainty makes the UK a less attractive destination for AI investment than it claims, and that the principles-based model produces inconsistent outcomes across sectors.

What This Divergence Means for AI Development

Three jurisdictions with three regulatory philosophies. The practical consequences for organisations operating across all three are significant, and still unfolding.

Compliance is becoming a competitive variable. For AI companies deciding where to develop, deploy, and scale, the regulatory environment is now a material factor in that decision. The EU’s comprehensive framework creates barriers to entry that disadvantage smaller providers but may create trust signals that advantage enterprise-grade providers. The US patchwork creates uncertainty that disadvantages organisations operating across multiple states. The UK’s flexibility is an advantage until a contract requires demonstrable compliance with a specific framework, at which point the absence of a clear standard becomes a gap.

The fragmentation problem is real and growing. An AI company operating globally in 2026 must navigate the EU AI Act, a substantial and growing body of US state AI laws with different requirements, and the UK’s multi-regulator framework, simultaneously. The compliance cost of this fragmentation is not trivial. It disproportionately affects smaller organisations without dedicated regulatory teams, and it creates a structural advantage for large incumbents who can absorb the cost.

The EU is exporting its framework whether others adopt it or not. The AI Act’s extraterritorial scope means that organisations with EU users, EU customers, or EU-affecting outputs may be in scope, regardless of where they are based. UK organisations with EU market exposure are de facto subject to EU AI Act obligations. US organisations with European operations face the same. The Brussels Effect, the EU’s ability to set global standards through market size, is operating in AI regulation as it did in data protection.

The UK’s window for differentiation is narrowing. The pro-innovation, principles-first approach works as a competitive advantage while the EU’s framework is still being implemented and the US patchwork is still fragmenting. As the EU framework matures and US federal legislation becomes more likely, the UK’s third way becomes less distinctive. The absence of a statutory framework that can be pointed to, for procurement, for investment, for enterprise sales, is a gap that eventually costs something.

The race is not just regulatory. Underlying all three approaches is a geopolitical competition for AI leadership, in talent, in compute, in model development, in deployment infrastructure. Regulation is one variable in that competition. Any jurisdiction that gets the balance right, enough governance to build trust, enough flexibility to move fast, will be better positioned than jurisdictions that overcorrect in either direction. Mid-2026, none of the three has demonstrably got there yet.

This newsletter is for discussion and informational purposes only and is not legal advice for any specific situation or jurisdiction. Indemnification law varies by jurisdiction and governing law. Regulatory positions described are current as of July 2026 and subject to change. Not exhaustive.

Until the next time,

- Anjola Ige

“AS IS” and What It Doesn’t Cover Anymore

“AS IS.” Two words. They can carry enormous consequences when the drafting is right, and significant exposure when it is not.

The challenge is that warranty disclaimers get treated as boilerplate that operates automatically once inserted into a contract. Drop in the standard language and move on. The problem is that standard language was written for a world of static, predictable software, and is now being applied to AI-driven services that are a different animal.

What a Warranty Disclaimer Does

Unless you exclude them, the law reads implied warranties into commercial contracts that you never wrote and may never have intended. Under the Uniform Commercial Code (UCC, a set of US statutory rules governing commercial transactions for goods) and analogous common law doctrines applied to SaaS:

The implied warranty of merchantability, meaning that the product is fit for the ordinary purposes for which it is used. In a software context, this means the product works as a reasonable user would expect it to.

The implied warranty of fitness for a particular purpose, meaning that the product is suitable for the specific purpose the customer communicated to the vendor at the point of sale.

The implied warranty of non-infringement, meaning that use of the product will not infringe third-party intellectual property rights.

A warranty disclaimer is an attempt to exclude these implied warranties, to say: whatever the law would otherwise read into this contract, we are not promising those things. The disclaimer has to be explicit and, critically conspicuous. In most jurisdictions, a disclaimer buried in the middle of paragraph fourteen of your terms of service, in the same font as everything else, is at risk of being found unenforceable because the customer could not reasonably have been expected to notice it.

Where Standard Disclaimers Start to Fail

Even a properly drafted, conspicuous disclaimer can fail to disclaim what you think it disclaims, if it has not been built for the type of service being provided.

Traditional SaaS contracts were drafted for stable, predictable systems. The software had defined features, known limitations, and consistent behaviour. An “AS IS” disclaimer in that context was excluding liability for known categories of software imperfection: bugs, compatibility issues, integration failures.

AI-driven services are different. They are probabilistic. The same input can produce different outputs. They hallucinate, generating confident, plausible, wrong answers. They degrade as underlying models are updated. They produce outputs that are shaped by training data the customer had no visibility into. A blanket “AS IS” clause does not map cleanly onto these failure modes.

Enterprise and regulatory enforcement actions in 2025 and 2026 have established an emerging principle: disclosures that appear only in terms of service receive less legal weight than disclosures that appear at the point of use.

The implication for AI products is considerable. A disclaimer that adequately covers a static SaaS tool may not adequately cover an AI feature producing consequential outputs, if that disclaimer does not specifically address how AI fails, and if it is not surfaced at the moment the output is generated.

The AI Output Problem

This is where warranty disclaimers are most exposed and most urgently need rethinking. When a customer uses an AI-powered feature to produce a legal summary, a financial analysis, a medical recommendation, or a contract redline, and that output is wrong in a way that causes harm, the question of who bears that risk depends on how the contract allocates it. A generic warranty disclaimer does not automatically answer that question.

Hallucination risk should be addressed by name in any AI disclaimer worth the paper it’s on: an acknowledgment that outputs may be wrong despite appearing confident, a contractual human-review requirement, and exclusion of reliance damages through the consequential damages waiver in the limitation of liability clause. The disclaimer, the acceptable use policy, and the liability cap work together, and no single clause carries hallucination risk alone.

There are four things a warranty disclaimer for AI outputs needs to do that a standard software disclaimer does not.

Name the Specific Failure Modes

Hallucination, bias, model drift, output variability. Generic “AS IS” language is not specific enough to put a sophisticated customer on notice of these risks. Name them.

Impose a Human Review Obligation Contractually

The disclaimer should not just say outputs may be inaccurate, it should require the customer to verify outputs before consequential reliance. This shifts the risk allocation in a documented, defensible way.

Address Beta and Preview Features Separately

Beta, preview, and early-access features should be expressly excluded from the limited warranty, the SLA, and indemnification provisions, mirroring the exclusions in upstream model providers’ own terms. Extending full warranties to features running on beta endpoints means promising customers more than the upstream provider promises the vendor.

Align With What the Company Is Saying Publicly

A disclaimer holds up when it is conspicuous, specific to how AI fails, consistent with what the company tells the market, and paired with a narrow express warranty the vendor genuinely stands behind. It becomes fragile when any one of those four elements is missing.

A Note for the Customer Side

If you are reviewing contracts that include AI-powered features, as a customer rather than a vendor, the warranty disclaimer section deserves more scrutiny than it typically gets. Specifically: does the disclaimer address AI outputs explicitly, or is it generic software boilerplate? Does it impose human review obligations on you, and have you operationalised those? Does it exclude beta features from warranty coverage, and do you know which features you are relying on are in beta?

The standard low-cap and broad-disclaimer approach is under pressure because AI errors can lead to regulatory fines, reputational damage, and mass litigation. Specific carve-out clauses for AI-related risks, discriminatory outputs, hallucinations, third-party IP infringement, are increasingly expected by sophisticated enterprise customers.

That’s warranty disclaimers. The second piece of this issue focuses on how organisations end up with a fragmented AI tool stack that nobody fully owns, and what to do about it.

The AI Tool Problem Nobody Mapped

In my work on AI governance in-house, I’m understanding more and more about AI tooling failures.

The sales team adopts an AI tool for outreach. The procurement team buys a procurement tool with an in-built contract management platform with AI-powered review built in. The legal team has already procured its own contract review tool, because the procurement platform was not designed with legal workflows in mind and legal was not consulted before purchase. The finance team is using a separate AI tool for invoice processing that partially overlaps with what the procurement platform already does. Nobody has mapped any of this. Nobody knows what data each tool is processing, where it’s going, or whether the tools can talk to each other.

By the time someone tries to connect the stack, they discover the integrations are either non-existent, require expensive custom development, or rely on a third-party connector, which itself introduces another data flow nobody has assessed.

How It Happens

The pattern is consistent. A team identifies a pain point. Someone finds a tool that solves it. The tool is procured, sometimes with IT’s involvement, sometimes without, and sometimes without legal as well. The tool gets adopted. The pain point is partially addressed. Then another team has another pain point, and the cycle repeats.

What nobody is doing at any stage is asking: do we already have a tool that does this, or could be configured to do this? What data will this tool process, and does that create a compliance obligation? How will this tool integrate with what we already have? Who owns this tool from a governance perspective once it’s deployed?

These are questions that a centralised AI procurement framework answers before the buying starts.

When Organisational Structure Compounds the Problem

The individual tool accumulation problem is compounded when you add organisational structure to it.

In a mid-sized organisation, it is entirely possible, and surprisingly common, for the procurement team to buy a contract management tool, deploy it, and then expect the legal team to perform contract reviews inside that tool. The legal team, meanwhile, has its own contract review platform, one that was selected because it integrates with their existing workflows, meets their security requirements, and produces output in a format that works for them.

Now you have two contract tools. Duplication of function. Duplication of cost. And a conflict, because someone has to decide which tool governs, and that decision will create friction with whichever team loses.

What a Better Approach Looks Like

This is not an argument against AI tools. It is an argument for buying them in the right order, with the right people involved, for the right reasons.

Start With the Need, Not the Tool

Before any AI tool is procured, the question should be: what specific inefficiency are we solving, and how do we know this tool solves it? “Everyone is using AI” is not a business case. A defined workflow gap, with a measurable outcome, is.

Map What You Already Have

Before buying anything new, audit the existing stack. What tools are currently in use across the organisation? What do they do? Where do they overlap? What are they not doing that they could? In some organisations, this audit surfaces significant duplication because tools were bought at team level without organisational visibility.

Define the Integration Requirement Upfront

Any new tool should be evaluated not just on its own functionality, but on how it connects to what already exists. A tool that solves a problem in isolation but creates an integration headache is solving one problem and creating another. The integration question should be part of the procurement criteria.

Involve the Right Stakeholders Before Purchase, Not After

If a tool will touch legal workflows, legal should be involved before it is procured. If it will process personal data, the DPO or privacy counsel should assess it. If it will integrate with core systems, IT should evaluate the architecture. Cross-functional sign-off is not bureaucracy. It is what prevents buying the same thing twice.

Designate Ownership

Every AI tool in the stack should have a named owner, a person or team responsible for its governance, its integration, its data flows, and its renewal decision. Tools without owners accumulate, go unused, and create compliance exposure.

Buying AI tools deliberately, within an established framework, is not a constraint on innovation. It is the difference between a stack that works and one that slowly fragments.

This newsletter is for discussion and informational purposes only and is not legal advice for any specific situation or jurisdiction. Warranty law varies by jurisdiction. UCC principles referenced apply primarily in US commercial contexts. AI governance frameworks vary by organisation size, sector, and regulatory context. Not exhaustive.

Until the next time,

- Anjola Ige

What Rios v. H&R Block Means for Your Arbitration Clause

H&R Block had an arbitration clause. A federal judge called it a “systemic failure of justice” and refused to enforce it.

That’s the story behind Rios v. HRB Digital LLC, decided by the Northern District of California in October 2025. Two consumers sued H&R Block alleging it had unlawfully shared their private taxpayer data with Meta and Google via tracking pixels embedded in its online tax preparation platform. H&R Block moved to compel arbitration. The court denied it, finding that unconscionability “permeates” the entirety of the arbitration agreement.

Arbitration and Litigation: What You’re Choosing Between

Arbitration and litigation are not just different procedural paths to the same destination. They allocate risk in different ways, and the choice between them ought to be deliberate.

Litigation means courts, public proceedings, established procedural rules, broader discovery rights, and the ability to appeal. Judgments are enforceable across jurisdictions without significant friction. The process is slower and more expensive, but it is transparent, appealable, and operates within a well-understood framework.

Arbitration means a private tribunal, typically faster, confidential, with limited discovery and very limited appeal rights. The arbitrator’s decision is almost final. If the arbitrator gets it wrong, your options are narrow. Arbitration decisions are much harder to overturn. Courts generally give arbitrators broad authority, even if one side strongly disagrees with the outcome. For businesses, a bad arbitration result can be difficult to fix later.

The conventional wisdom that arbitration is cheaper, faster, and more private is not universally true. In many commercial disputes, arbitration makes a dispute more expensive, not less. Arbitration bodies charge discretionary fees borne by both parties, and arbitrators’ fees can run into hundreds of thousands for complex commercial matters. For high-value disputes, the cost differential often favours litigation.

What the Court Found in Rios

H&R Block included an arbitration agreement in its Online Services Agreement containing a bellwether protocol, a mechanism intended to manage mass arbitration claims by resolving a small number of test cases first. Judge Edward M. Chen denied the motion to compel arbitration, finding that the bellwether protocol created a “systemic failure” of justice because it provided no mechanism for relief when unreasonable delays occur.

The court found the agreement unconscionable on two grounds.

On procedural unconscionability: the arbitration agreement was part of a standard-form, non-negotiable contract presented during tax season, leaving consumers with little practical ability to reject it. Although H&R Block included a 30-day opt-out, the court held this did not cure the gap in bargaining power because the opt-out provision was buried in a lengthy agreement and required repeated annual action.

On substantive unconscionability: the bellwether protocol meant individual claimants could wait indefinitely for their claims to be heard. The clause was effectively designed to exhaust plaintiffs rather than resolve disputes.

Courts are now performing a functional analysis. If your protocol is a genuine attempt to streamline wide-scale dispute resolution, it may survive. If it’s a thinly veiled attempt to prevent claims from ever being heard, it will be struck down.

Arbitration clauses that use procedural complexity as a shield are increasingly unenforceable.

What a Defensible Dispute Resolution Clause Requires

Whether you’re opting for arbitration or litigation, the clause needs to be built for the disputes it will face.

If You’re Including an Arbitration Clause

Conspicuousness and genuine opt-out. Rios is a warning that burying an arbitration agreement in standard terms, with an opt-out that requires repeated annual action buried equally deep, invites an unconscionability challenge.

Specify the rules and the seat. Which arbitration body, AAA, JAMS, ICC, LCIA? Under which rules? In which city? Generic “arbitration” language without these details produces satellite disputes before the substantive claim is ever heard.

Mass arbitration provisions. To withstand challenges, mass arbitration provisions should avoid two things: unreasonable delay and binding precedential effect on non-parties. Provisions that only allow a few disputes to proceed at a time while holding the rest in procedural limbo indefinitely are unconscionable because they can deter consumers from pursuing legitimate claims. If you need a batching or bellwether mechanism, build in a genuine safety valve, a mechanism for relief when delays become unreasonable.

Limited discovery. Arbitration typically restricts discovery significantly. For disputes involving fraud, financial misconduct, or complex data privacy claims, that restriction may work against you as much as the other side. Think about the disputes you’re most likely to face before you accept this constraint.

Appeal rights. An arbitral award can be challenged on very narrow grounds: arbitrator misconduct, fraud, excess of authority. If the arbitrator makes a substantive legal error, you almost certainly cannot appeal it. For high-value or complex commercial disputes, that finality is a material risk.

If You’re Opting for Litigation

Governing law and jurisdiction. Be specific. A clause that says “disputes shall be governed by the laws of England and Wales and subject to the exclusive jurisdiction of the English courts” is complete. A clause that says “disputes shall be resolved in accordance with applicable law” is incomplete at best, because it is simply relocating the argument to where and under what law the dispute should be heard before the substantive dispute begins.

Tiered dispute resolution. Many commercial contracts now include a pre-litigation escalation step: senior management negotiation, then mediation, then litigation or arbitration.

Injunctive relief carve-outs. Even in arbitration-first contracts, parties frequently carve out the right to seek interim injunctive relief from a court, particularly for IP, confidentiality, and data breaches where urgency outweighs procedural sequencing.

Rios illustrates what happens when a clause is designed to avoid disputes rather than genuinely resolve them. That gap does not survive judicial scrutiny.

That’s it on dispute resolution. The second piece on this issue looks at a different problem entirely: where the legal AI market has landed in mid-2026, and why the picture is considerably more interesting than the narrative a year ago suggested.

Where the Legal AI Market Stands

Some years ago, the legal tech market had a clear narrative. Build a legal AI agent. Raise money. Win. Mid-2026, the picture is considerably more interesting.

The market hasn’t consolidated the way people predicted. It has fractured into at least four distinct camps, each making a different bet on where legal value sits. If you’re a legal professional trying to decide what to use, or a founder trying to decide what to build, which camp you’re watching determines what conclusion you draw.

The Legal-Specific Tool Buyers

This camp never really bought the “general LLMs are enough” argument, and the market has largely validated their instinct for certain use cases. Legal-native platforms like Westlaw AI and Lexis+ AI rely on curated legal data and deliver accurate, citable results from authoritative sources, with stronger security and compliance features than general purpose tools.

The in-house and law firm buyers with established legal ops budgets are still largely here. Harvey is now valued at $11 billion after raising $200 million in March 2026. Legora raised $600 million in its Series D, including a $50 million extension in April 2026, valuing the Stockholm-based company at $5.6 billion; the company says it has surpassed $100 million in ARR, putting it in a very small cohort of post-genAI enterprise software businesses scaling at exceptional speed. GC AI and others continue to attract serious enterprise spend for the same reason: these platforms offer something general LLMs structurally cannot; verified citations, playbook context, team templates, and audit trails built for legal workflows.

The budget is here. The purchasing decision is made. This camp is not going away.

The General LLM Users

Outside formal legal tech buying processes, and often without much visibility from legal ops teams, a significant portion of legal professionals are doing serious work inside Claude, ChatGPT, and Gemini. Not for verified case law, they know better, but for everything else. Contract issue-spotting. Clause drafting. Translating dense regulatory text into plain English. Memo outlines. Second opinions on arguments they’ve already formed.

The capabilities that make Claude relevant for in-house legal work are long context, writing quality, and reasoning across documents. Current models including Claude Opus 4.7, Opus 4.8, and Sonnet 4.6 offer a one-million-token context window through the API and certain enterprise tiers. Anthropic also launched a legal plugin in February 2026, designed specifically for corporate and in-house legal teams handling contracts, compliance, and NDA review.

The honest position on this camp: the tools are genuinely capable for the work that doesn’t require verified legal databases or jurisdiction-specific playbooks. The risk is that people are using them for work that does, without realising the difference.

The AI-Native Legal Service Providers

This is the camp nobody was fully predicting a few years ago, and it is forcing a more fundamental question: whether the future of legal services is about better tools for lawyers, or entirely different ways of delivering legal work.

Crosby, backed by Sequoia, Bain Capital Ventures, Lux Capital, and Index Ventures, operates as an AI-powered law firm delivering contract reviews through Slack, with a median turnaround of under an hour. It has negotiated contracts worth more than $1 billion for clients since emerging from stealth less than a year ago. It is not a software tool. It is a law firm, with licensed attorneys, malpractice insurance, and fixed per-document pricing, that happens to be built on AI infrastructure.

NormAI, backed by Blackstone, Bain Capital, and Vanguard, launched Norm Law LLP, described as the first AI-native full-service law firm for global institutional clients, serving clients collectively managing over $30 trillion in assets.

These are not legal tech startups selling software to lawyers. They are competing directly with law firms for legal work.

The Build-Your-Own

Kirkland & Ellis, the first law firm in history to break $10 billion in revenue, announced a $500 million investment to build its own proprietary AI platform, starting with $100 million in 2026, designed based on input from 250 Kirkland lawyers and over 180 technology professionals. Kirkland’s chair noted that while widely available AI tools are raising standards across the legal industry, that bar isn’t high enough for a firm like Kirkland, whose clients expect more than whatever any competitor armed with off-the-shelf tools can offer.

Freshfields separately announced it will work with Anthropic’s legal team to develop AI applications for legal services. Clifford Chance and Crowell & Moring have built on top of OpenAI’s GPT.

The thesis here is that institutional legal knowledge, decades of deal structures, negotiating positions, and outcome data, is a competitive asset that should not be handed to a third-party platform. Firms with the scale and financial capacity to build internally are choosing to make that investment rather than rely entirely on external platforms.

What This Means if You’re Thinking About Building in This Space

A year ago, “build a legal AI tool” was a relatively clear product thesis. Find a workflow. Automate it. Sell it to law firms or legal ops teams.

The thesis still exists, but with fundamentally different assumptions. You are now competing not just with other legal tech startups, but with general purpose frontier models that are improving faster than vertical tools can differentiate, AI-native law firms that have collapsed the software and services distinction, and the largest law firms in the world building proprietary platforms with nine-figure budgets.

The legal AI market stood at $1.45 billion in 2024, projected to reach $3.9 billion by 2030, and AI contract analysis tools alone are projected to grow from $4.3 billion in 2026 to $12 billion by 2030. The opportunity is clearly there. The harder question is identifying where a new entrant can build an advantage that the existing players cannot easily replicate.

This newsletter is for discussion and informational purposes only and is not legal advice for any specific situation or jurisdiction. Enforceability of arbitration clauses varies significantly by jurisdiction, governing law, and applicable consumer protection legislation. Market positions and valuations are current as of June 2026 and subject to change. Not exhaustive.

Until the next time,

- Anjola Ige

Notice Periods That Run the Show

Notice provisions are easy to overlook because they look administrative, but the number of days in a notice period goes beyond being a drafting choice and can be quite determinative.

It determines how much time a business has to react, replace, remediate, renegotiate, or absorb the consequences of a decision already set in motion.

I saw this play out in a software agreement with an enterprise client. There was a thirty days’ price change notice period, nobody had pushed back on it at signing. What nobody had mapped at the time was that the same thirty-day window coincided with the client’s contract renewal decision date and their invoice payment deadline. The day we issued the price change notice was effectively the day we told them: accept the new price, renew, and pay, simultaneously. There was no decision window. It was take it or leave it, by accident.

In that situation, the notice period became a commercial constraint.

Termination Notices

The termination notice period determines how much runway each party has between the decision to exit and the exit becoming effective. The number of days should be a function of what has to happen during that window, not what feels standard.

For the party giving notice, a longer period means continued exposure to a relationship they’ve already decided to end. For the party receiving notice, a shorter period may not be enough time to operationally absorb the exit.

The domino effects to map before settling on a number:

Data migration and handover. If the contract involves data processing, storage, or integration, the termination notice period needs to be long enough to complete a clean data return or deletion. Thirty days is rarely sufficient for complex data environments. If your data protection obligations under GDPR or equivalent require specific deletion and confirmation processes, that timeline needs to feed directly into the notice period.

Replacement procurement. How long does it realistically take to identify, procure, and onboard a replacement vendor or service? If the answer is ninety days and your notice period is thirty, the receiving party is already in breach of their own operational obligations before the notice period expires.

Third-party dependencies. If the contract sits inside a broader supplier or technology stack, termination of one agreement can trigger obligations or gaps in others. The party receiving notice may need to renegotiate or exit parallel contracts, and that takes time the notice period may not accommodate.

Regulatory notification obligations. In regulated sectors, financial services, healthcare, anything involving critical infrastructure, switching a material vendor may require regulatory notification or approval. If that process takes sixty days and the notice period is thirty, the receiving party is operationally trapped.

The practical point: termination notice periods should be agreed after someone has mapped the wind-down process.

Breach Notices and Cure Periods

Before a party can usually terminate for breach, the contract will require notice of the breach and give the breaching party an opportunity to fix it within a defined cure period. The length of that cure period is a notice provision, and it carries its own set of downstream consequences.

A cure period that is too short creates a different problem: it may not give the breaching party enough time to remedy, which means the termination that follows may be contested. Courts have been willing to look at whether a cure period was genuinely adequate for the type of breach in question. A thirty-day cure period for a data security breach involving ongoing system vulnerabilities may not survive scrutiny if remediation demonstrably required longer.

Consider a realistic scenario. A SaaS vendor experiences a material service outage, SLA breach, customer data temporarily inaccessible, regulatory implications live. The customer serves a breach notice with a thirty-day cure period. The vendor’s remediation involves a full infrastructure audit, third-party forensic review, and regulator notification, none of which can be completed in thirty days. The customer terminates at day thirty-one. The vendor contests the termination on the basis that the cure period was not adequate for the nature of the breach. The contract is silent on what “adequate” means. That silence is now a dispute.

The domino effects to map:

Nature of the breach versus length of the cure period. A payment default can be cured in days. A systemic performance failure or data breach may require weeks or months of remediation. The cure period should reflect the category of breach it is designed to address, and contracts dealing with complex technology or data obligations should consider tiered cure periods rather than a single fixed number.

Repeated breaches. Many contracts include a carve-out allowing immediate termination for repeated breaches of the same type within a defined period, without a further cure period. If yours doesn’t, a counterparty can breach, cure, breach again, and the notice and cure cycle restarts each time.

Interaction with service credits. In SaaS contracts especially, SLA breaches often trigger service credits before termination rights arise. If the contract provides service credits for the first thirty days of underperformance and then a breach notice period of a further thirty days, you may be sixty days into a failing relationship before you can exit. Map the full timeline before you negotiate either provision in isolation.

Change Notices

Change notices, covering price changes, material changes to service terms, policy updates, or product modifications, are the notice type most frequently underweighted at the drafting stage and most frequently consequential in practice.

The price change example at the opening of this piece is the clearest illustration. But the domino effects run wider than that.

Renewal decision windows. If a contract has an auto-renewal clause and a change notice period that is shorter than the renewal opt-out window, a client can receive a price change notice after their window to opt out of renewal has already closed. They are now locked into a renewed contract at a price they haven’t agreed to. Whether that holds legally depends on jurisdiction and contract terms, but the commercial and reputational damage is immediate.

Budget cycles. Enterprise clients operate on annual budget cycles. A price change notice of thirty days issued in November may land after a client’s budget has already been set for the following year. Even a willing client may be operationally unable to absorb the change without a longer runway. Sixty or ninety days, timed to land before typical budget-setting periods, is a more commercially intelligent default.

Regulatory price change obligations. In certain regulated sectors, price changes to end customers require advance notice of a minimum period under consumer protection or sector-specific regulation. If your contract’s change notice period is shorter than the applicable regulatory minimum, the contractual provision is ineffective regardless of what it says. Know the regulatory floor before you draft the clause.

Material versus non-material changes. Not all changes carry the same commercial weight. A change notice provision that applies the same period to a minor UI update and a fundamental change in data processing terms is not fit for purpose. Consider whether your change notice clause should distinguish between categories of change, and apply different notice periods accordingly.

Notice periods interact with renewal clauses, payment terms, regulatory obligations, procurement timelines, and data obligations. The consequences become apparent when the notice clause is considered alongside the rest of the contract and the business.

That’s on the notice provisions. The second piece of this issue is a different problem entirely: what happens when an AI system causes harm, who is responsible for responding, and why the answer is no longer just an internal question.

When an AI Incident Becomes a Compliance Problem

AI hallucinations are costing businesses.

Gordon Rees Scully Mansukhani, a law firm generating $759 million in gross revenue, was forced to apologise to a judge after submitting a bankruptcy filing riddled with inaccurate and non-existent AI-generated citations. The firm promised updated AI policies and a new citation-checking process. Air Canada’s chatbot hallucinated a bereavement fare policy, and lost in court when the company tried to disclaim responsibility for what its own AI had told a customer. Since mid-2023, legal researchers have documented over 120 cases of AI-generated legal hallucinations, and the number has continued to grow.

Defining an AI Incident

Before you can respond to an AI incident, you need to define one. An AI incident is not limited to a dramatic failure. It includes:

A hallucination that was acted upon before anyone caught it, a contract redline accepted, a legal citation filed, a financial figure relied upon in a decision.

An AI output that caused harm to a third party, a customer given wrong information, a candidate screened out by a biased model, a patient given incorrect clinical guidance.

A data exposure caused by an AI tool, inputs containing personal or confidential data being used to train a model, or outputs inadvertently revealing data from other users.

A model behaving unexpectedly after an update, outputs degrading in quality or changing in character after a vendor pushes a model change you weren’t notified about.

A near-miss, an output that was wrong but caught before it caused harm. Near-miss reporting has prevented more incidents than post-accident analysis in aviation safety culture, and the same principle applies directly to AI operations. If you are not logging near-misses, you are missing your best early-warning signal.

The Regulatory Dimension

In the EU, AI incident response has moved out of best practice territory. For many organisations, it is now a formal compliance requirement.

Under Article 73 of the EU AI Act, for high-risk AI systems, providers must notify the competent national market surveillance authority of serious incidents. Reporting timelines are tight: within 15 days of becoming aware of a serious incident, 10 days if a death may have been caused, and two days for widespread infringements.

A serious incident includes an indirect causal link between the AI system and the harm, meaning you do not need to prove the AI directly caused the outcome. A reasonable likelihood of a causal link is sufficient to trigger the reporting obligation.

Deployers and providers alike are affected. As a deployer, you have your own obligations under the AI Act, regardless of whether you developed the system yourself or purchased it from a provider. If you are using a third-party AI tool that causes a serious incident, the reporting obligation may still be within your remit, and your contracts with AI vendors need to reflect that.

What an AI Incident Response Plan Requires

A severity classification framework. Not every AI failure is a crisis. A tiered model, from near-miss through to critical, gives your team a consistent way to triage what has happened, what response it requires, and how quickly. The classification determines whether this is a logging exercise, an internal investigation, a customer notification, or a regulatory report.

Named ownership. Designating a specific individual or team as responsible for overseeing the AI incident response plan, a chief risk officer, an AI ethics board, or a dedicated AI governance committee, should be the starting point. In practice, this means knowing who picks up the phone when something goes wrong at 6am. If nobody has been named, the answer is nobody.

A cross-functional response team. AI incidents sit at the intersection of technology, legal, communications, and the business. Interdisciplinary teams, with risk managers coordinating among technologists and legal professionals, are best practice for managing the complex risks AI presents.

Defined investigation procedures. After an incident is identified, what happens next? The investigation needs to distinguish between failure categories: was this a model-level failure, a data quality issue, a human oversight gap, or an integration problem? The root cause determines the remediation.

A regulatory notification workflow. For organisations in scope of the EU AI Act, the 15-day notification window starts from when you become aware of the incident, not when you finish investigating it. You need a documented workflow that identifies who assesses whether the incident meets the threshold, who prepares the notification, and to which authority it goes.

Vendor notification and cooperation obligations. If the incident involves a third-party AI tool, your contract needs to require the vendor to notify you promptly of incidents on their side that affect your systems, and to cooperate with your investigation. Review your AI vendor contracts against this requirement.

A near-miss log. Require teams to report AI outputs that were wrong but caught before harm occurred. Log them, review them quarterly, and use them to update guardrails. This is the cheapest risk management tool available.

This newsletter is for discussion and informational purposes only and is not legal advice for any specific situation or jurisdiction. EU AI Act obligations apply to providers and deployers of high-risk AI systems as defined under the Act. Scope, thresholds, and notice period requirements vary by contract type, jurisdiction, sector, and applicable regulation. Not exhaustive.

Until the next time,

- Anjola Ige

Force Majeure Clauses Are Not Boilerplate

The last three years proved this.

Courts have been busy. Sanctions, pandemics, supply chain disruption, and government-imposed trade restrictions have made force majeure clauses far more important than many counsel once assumed.

A few recent examples are worth noting. In RTI Ltd v MUR Shipping BV, the UK Supreme Court held in May 2024 that a reasonable endeavours obligation in a force majeure clause does not require a party to accept non-contractual performance. In that case, MUR was not required to accept euros instead of the contractually agreed US dollars.

During COVID-19, outcomes often turned on the wording of the clause itself. Contracts that referred to pandemics, epidemics, or government restrictions were better placed to support force majeure arguments, while others were left to fight over causation, impossibility, and risk allocation.

More recently, tariff-related disputes have shown the same pattern: courts do not automatically treat government action as a force majeure trigger. The question is always what the clause says, how the contract allocates risk, and whether performance was truly prevented rather than simply made more expensive.

The pattern across all of these is that courts interpret force majeure clauses narrowly. The clause is only as strong as the language inside it.

What a Complete, Defensible Force Majeure Clause Requires

A Trigger List That Is Defined and Broad Enough

The clause must name the events that qualify. “Acts of God” alone will not carry you far in 2026. A defensible trigger list should cover natural disasters such as flood, earthquake, and fire; pandemic, epidemic, or public health emergency; war, invasion, armed conflict, and terrorism; government action, including sanctions, trade restrictions, import or export bans, and regulatory prohibitions; labour disputes and strikes, where you decide whether to include your own workforce or only third parties; and infrastructure failures affecting the power grid, internet, or critical systems.

The question to ask at the drafting stage is what the realistic macro-risks are that could disrupt performance of this specific contract. Draft to those risks, not to a generic list carried over from a precedent.

Causation Language, Direct or Indirect

In practice, this is one of the areas that creates the most difficulty when a force majeure claim is tested. Standard drafting requires the force majeure event to “prevent” performance. Simply because performance has become more burdensome or less profitable does not necessarily mean it has been prevented. Consider whether your clause should also cover events that “hinder” or “delay” performance, and draft accordingly.

The Reasonable Endeavours Proviso

Most force majeure clauses require the invoking party to use reasonable endeavours to overcome the event. The UK Supreme Court has now confirmed that this does not require a party to accept non-contractual performance from the counterparty. But if you want to expand or restrict that standard, or if you want to permit alternative performance or require a specific workaround before the clause activates, that must be in the clause, in clear words.

Notice Mechanics

Force majeure clauses typically require notice within a specified period of the triggering event. Miss that window and you may lose the right to rely on the clause entirely. The notice provision should state to whom, in what form, within how long, and what information must be included. Vague notice requirements become disputes.

Consequences: Suspension, Termination, or Renegotiation

Many clauses spend considerable time defining the trigger event but far less time dealing with what happens afterwards. A force majeure clause needs to address both triggering events and the remedies that flow from them. Worth addressing: whether the clause suspends obligations for a defined period, after what period either party can terminate, what happens to payments made, work in progress, or third-party commitments during the suspension, and whether there is a renegotiation obligation if the event is prolonged.

A clause that excuses performance but says nothing about what comes next is half a clause.

A Practical Point on Sanctions Specifically

Geopolitical risk is now a standard feature of commercial contracting. If your contracts have any cross-border dimension, whether in counterparties, payment flows, supply chains, or data routing, your force majeure clause should expressly address sanctions and government-imposed trade restrictions.

Given the frequency with which force majeure clauses are being invoked as world events cause supply chain disruption and the imposition of sanctions, clarity on scope matters more than it used to.

“Acts of God” was always a placeholder. What matters now is what risks you actually named, and what you said happens when they arrive.

That’s force majeure. The second piece in this issue looks at a different kind of risk naming exercise: AI governance, and the certification standard progressively catching up with what good practice already requires.

The Governance Work You’re Already Doing Without Calling It That

Working in-house at a SaaS company, I’ve spent time this year collaborating with IT on an AI acceptable use policy.

This has been standard work on its face. But as we built it out, mapping our AI systems, defining oversight requirements, documenting vendor controls, it became clear we were doing something else at the same time: methodically laying the groundwork for ISO/IEC 42001 certification, whether or not that was the stated objective.

That experience is what prompted this piece.

In conversations I’ve had this year, ISO/IEC 42001 still tends to sit in the “we’ll get to it eventually” category. What I’ve come to think, having been inside the process, is that later is more expensive than now. The foundational work required for certification is the same work responsible AI governance demands regardless. Much of the effort is the same either way.

What Is It?

ISO/IEC 42001 is an international standard specifying requirements for establishing, implementing, maintaining, and continually improving an artificial intelligence management system within organisations, designed for entities providing or utilising AI-based products or services.

The easiest reference point for anyone who has worked with compliance: think of it as the AI equivalent of ISO 27001. Where 27001 provides a certifiable management system for information security, 42001 applies that same logic to AI, covering governance, risk management, transparency, bias mitigation, human oversight, and lifecycle monitoring.

Organisations already certified to ISO 27001 will find the delta meaningfully smaller than going in cold. The audit discipline, internal review processes, and certification body relationships transfer directly. The AI-specific half, covering model risk and AI system impact assessments, is a separate competency, but the management system foundation is the same.

Who Is Getting Certified, and Why

A wide variety of organisations have already pursued or are considering certification: model providers, cloud and platform providers, SaaS companies, law firms, and advertising technology providers.

The drivers are stakeholder trust, enhanced risk management, competitive differentiation, and regulatory positioning. For organisations operating in or adjacent to the EU, ISO/IEC 42001 provides the audit-ready structure that complements EU AI Act compliance. Many organisations are pursuing both: signing the EU AI Code of Practice for regulatory alignment, and certifying to ISO 42001 to institutionalise controls and evidence for audits.

Enterprise procurement is also sharpening the signal. Microsoft has obtained ISO 42001 certification for its AI systems. When large technology providers hold the certification, it becomes an expectation for organisations in their supply chains.

What the Audit Process Looks Like

Certification involves several phases: identifying AI systems, services, and relevant legal contexts; evaluating technical, ethical, and legal risks and defining mitigation controls; assessing internal controls and alignment with the standard; confirming implementation, stakeholder roles, and system effectiveness; and applying corrective actions.

Certification is typically valid for three years, with annual or semi-annual surveillance audits. The process requires demonstrating controls across all clauses and annexes, and it is resource-intensive, demanding long-term maturity rather than a one-time alignment exercise.

If an organisation leaves this work until the certification process begins, it is likely to face a longer and more resource-intensive exercise.

What to Build Now, Even if Certification Isn’t Imminent

The gap between “we use AI responsibly” and “we can prove it to an auditor” is significant. The work that closes it is the same work that should be happening regardless of whether a certificate is the end goal.

An AI systems inventory. Document every AI system in use, whether internally built, vendor-provided, or embedded in third-party tools. For each: what it does, what data it processes, who owns it, and what decisions it influences. This is the foundation everything else is built on.

An AI use policy. A written policy governing how AI may and may not be used, by whom, and under what oversight conditions, addressing generative AI specifically. Without a policy, there is no governance baseline to audit against.

A risk assessment process. For each system in your inventory, a documented assessment of the risks it presents: bias, data quality, opacity, third-party dependency, regulatory exposure. This is required for certification. More importantly, required for defensible AI adoption decisions.

Vendor AI governance requirements. Your contracts and vendor assessments should address AI governance explicitly: what standards the vendor meets, how model changes are communicated, and who carries liability when AI outputs cause harm. Build this into procurement now.

Human oversight mechanisms. Document where AI supports decisions and what human review is required before those decisions are acted upon. The documentation of oversight is as important as the oversight itself.

An AI incident response protocol. What happens when an AI system produces a harmful or materially incorrect output? Who is notified, how is it investigated, and what triggers remediation? Even a simple protocol signals governance maturity.

In my view, certification becomes significantly easier when these governance processes are first built for operational reasons and later for audit purposes.

Governance infrastructure built under operational conditions holds up better than governance built for an audit. And when the audit comes, whether driven by regulation, procurement pressure, or strategic choice, most of the work will already be done.

This newsletter is for discussion and informational purposes only and is not legal advice for any specific situation or jurisdiction. Requirements vary by organisation size, AI use case, jurisdiction, and applicable regulation, and the list above is not exhaustive.

Until the next time,

- Anjola Ige

Having said that, I have two exciting topics for this issue. The first is termination for convenience, and where people drop their guard on it in fixed-term contracts. The second is a personal automation build I put together about a year ago, and what’s changed since. Let’s get into it!

Termination for Convenience: Where People Drop Their Guard

I walked into a situation early in my in-house career where the relationship with a vendor had reached the point where neither side was able to work effectively with the other. The business wanted to move on, but the contract only allowed an early exit if specific grounds for termination existed.

Termination was available only on specific, enumerated grounds. None of those grounds quite fit the circumstances we were dealing with. So the options were: manufacture a breach, negotiate an exit at a cost, or ride out the remaining term with a vendor the business no longer trusted.

So I thought I would talk about termination architecture in contracts, particularly termination for convenience in fixed-term contracts, where quite a few people drop their guard.

First, a quick map of the termination landscape.

Most commercial contracts carry some version of these:

• Termination for breach, where the other side has materially failed, usually with a cure period attached.

• Termination for insolvency, where a party becomes insolvent, enters administration, or equivalent.

• Termination for convenience, where either party, or one party, can exit without cause, on notice.

• Automatic expiry, where the contract simply ends at the fixed term, with no action required.

The problem is that counsel, and business teams, often treat automatic expiry as a substitute for termination for convenience on short or fixed-term contracts. The logic is: it’s only six months, it’s only a year, why do we need an early exit right?

That reasoning works only until something changes before the contract expires, and this happens more often than people expect. A defensible, functional termination for convenience clause needs to address notice mechanics, accrued obligations, wind-down, survival, and, where applicable, a termination fee.

Notice Period and Mechanics

How long the notice period runs, who it goes to, and in what form matters more than people assume. Thirty days work for simple service agreements. Nonetheless, a longer period may be more appropriate where transition is complex or the vendor needs runway to wind down operations. The notice mechanics, whether it’s email, registered post, or delivery to a named officer, are critical because uncertainty around the process is often the beginning of termination disputes.

Accrued Obligations as at Termination

What has been earned versus what has been paid needs to be addressed. Spell out how you treat fees paid in advance, milestones partially completed, and expenses already incurred.

Wind-Down Obligations

What each party must do during and after the notice period needs to be spelled out. Is performance expected to continue to standard during the notice period? Is there transition assistance, data return or deletion, or a handover of work product? The absence of a wind-down framework turns a clean exit into a protracted negotiation.

Survival Provisions

Which clauses survive termination, and for how long, needs to be addressed explicitly: confidentiality, IP ownership, indemnities, and dispute resolution all warrant a look. If your termination for convenience clause doesn’t cross-reference your survival clause, or if you don’t have one, you may be inadvertently releasing obligations you intended to keep.

When the Exit Right Comes With a Price Tag

On fixed-term contracts especially, vendors will often resist unconditional termination for convenience, or they’ll price it in. Sometimes a break fee is the commercial compromise that gets you the exit right. Know your walk-away position before you negotiate.

Where a Termination for Convenience Clause Creates Ripple Effects

Including a termination for convenience clause, particularly in a fixed-term contract, creates ripple effects across the agreement.

Minimum commitment clauses. If the contract has a minimum purchase obligation or a volume commitment over the fixed term, termination for convenience creates a tension. Can you exit before meeting that commitment without liability? This needs explicit carve-out language.

Auto-renewal provisions. If the contract auto-renews and you exercise termination for convenience mid-term after a renewal has triggered, which term governs the notice period? The interaction between your termination mechanics and your renewal clause needs to be checked.

Liability caps. Some contracts cap liability at fees paid or payable under the agreement. On a termination for convenience exit, “fees payable” could be read to include the balance of the fixed term, which is an unintended exposure most parties don’t see coming. Cap language should be reviewed alongside termination drafting.

Data and IP provisions. Return or deletion of data, ownership of work product developed during the term, these obligations don’t automatically resolve on an early exit. If those provisions don’t clearly address it, the parties often end up trying to resolve them at the point when commercial tensions are highest.

That’s termination architecture. The next section is a different problem entirely: a personal automation build I put together about a year ago, and what’s changed since.

What I Built to Stop Reading Regulatory Updates Manually

I built an automated regulatory update workflow about a year ago. It took me about two weekends, and more debugging than I care to remember.

A Make.com scenario chaining Inoreader RSS feeds to OpenAI’s API to a Notion database to my inbox. Every morning, a personalised AI regulation digest arrived in my email, summarised through a regulatory lens, archived and searchable. Built once. Ran daily. It costs almost nothing.

I was proud of it. I still am.

But I’m revisiting it now because the landscape has shifted, and I wanted to think through what’s changed and what hasn’t.

What the Build Involved

Getting five tools to talk to each other in a reliable sequence required understanding HTTP POST requests, JSON body formatting, API authentication headers, and array aggregators. The logic had to be right at every module, or it didn’t work.

The debugging was where it got real. A few things I ran into:

OpenAI kept returning raw JSON blobs to my inbox instead of clean summaries. The fix was extracting choices[0].message.content correctly from the HTTP response and mapping it properly in Make. Straightforward in hindsight, not obvious at 11pm.

The JSON body itself kept failing to parse. That came down to strict formatting requirements, where one misplaced bracket or unescaped character could break the request.

SMTP threw SSL errors that took longer to resolve than the entire rest of the build combined.

Here’s what I’d say to anyone building something similar today: AI tools have made a lot of those problems easier, especially the drafting, validation, and debugging steps. What has changed is the nature of the work. I spend less time fighting syntax and more time thinking about workflow design and reliability.

The Autonomy Question Hasn’t Changed

What I built is a true autonomous pipeline. No human trigger. No prompt to type. No app to open. The scenario fires on a schedule, fetches articles, runs them through GPT, archives to Notion, and delivers to my inbox, without me being in the loop at any point. I wake up and it’s already done.

Most of what passes for “AI research assistance” in 2026 still requires a human to initiate it. Fully scheduled or background-run workflows are increasingly possible, including Claude Code’s scheduled tasks feature, which is documented as supporting cron-style runs. The automation itself isn’t the new part. What’s changed is the quality of the outputs and how little effort it now takes to keep these workflows running.

What has improved is the summarisation quality, the contextual depth, and the cost per run. What has not changed is the need to design the workflow carefully if you want it to be reliable.

This newsletter is for discussion and informational purposes only and is not legal advice for any specific situation or jurisdiction.

Until the next time,

- Anjola Ige

Before the two main topics, there is something interesting that happened this week. On Wednesday last week, the EU announced it has reached a political agreement on the EU AI Act amendments. Oliver Patel, Head of Enterprise AI Governance at AstraZeneca and one of the clearest voices on EU AI Act compliance, posted a summary of the key elements of the provisional agreement. Here is what he identified:

• Enforcement of high-risk AI systems delayed: from 2 August 2026 (current law) to 2 December 2027 for Annex III systems, and 2 August 2028 for Annex I systems. These dates are fixed regardless of when technical standards are finalised.

• AI systems capable of generating non-consensual sexual content or CSAM added to the list of prohibited AI practices.

• Registration in the EU public database remains mandatory for providers of “exempted” systems deemed not to be high-risk, though with lighter information requirements.

• Enforcement of the generative AI output detection and watermarking obligation (Article 50(2)) postponed to 2 December 2026.

• Broader scope for organisations to process sensitive personal data for bias detection and correction, provided it is strictly necessary and limited to specific bias types.

• Some of the Commission’s simplification proposals on registration have been curtailed by the European Parliament and Council. On AI literacy, no agreement was disclosed: the Commission and Council wanted to remove or significantly reduce the obligation; Parliament disagreed.

The timeline changes are headline-grabbing, but the core structure and logic of the Act remains broadly intact. Organisations should not use the delays as a reason to deprioritise. (His summary is based on official reports from the EU institutions and is non-exhaustive, as the full text of the political agreement is not yet available.). You can also visit his LinkedIn profile to read more.

That’s the regulatory shift. But here’s what’s happening in practice: organisations are discovering that the contracts they signed years ago don’t actually protect them the way they thought. Start with this one.

MSA Liability Caps: What the Drax v Wipro Decision Actually Tells You

Every MSA negotiation has a moment where someone says “the liability cap is market standard” and the room moves on.

Market standard for whom? When Drax Energy’s MSA with Wipro ended in litigation, the court did not ask what was standard. It asked what the clause actually said. What it said was ambiguous enough that the judge chose the interpretation with, in his words, the “least bizarre” consequences. That interpretation was not Drax’s.

A few of the patterns that surface most often in SaaS and technology MSAs:

The Aggregate Cap Trap

The clause in Drax v Wipro said the supplier’s “total liability shall be limited to” a rolling 12-month fee calculation. Drax read “claim” to mean each individual cause of action, which would have made the cap substantially higher. Wipro read it as one cap covering all claims globally. The drafter probably did not think carefully about which reading would apply. Neither party did, until litigation.

If you intend multiple caps (per claim, per event, per contract year), say so expressly and define each term. If you intend a single aggregate cap, specify what resets it, whether each Statement of Work carries its own sub-cap, and whether the rolling period runs per claim or per calendar year. Ambiguity in these clauses is never neutral. It resolves against the party that needed clarity most.

The 12-Month Fee Formula

The most common SaaS liability cap: “Vendor’s liability shall not exceed fees paid in the 12 months preceding the claim.”

For a $50,000/year SaaS contract, this caps the vendor at $50,000, regardless of the scale of data loss, system failure, or operational disruption. The point is not that this structure is inherently wrong. It is that counsel often accept it without stress-testing what actual exposure looks like. A $50k SaaS tool embedded in your core operations can cause a $5 million problem.

Tie the cap to your actual risk exposure, not the contract value. For data-sensitive or operationally critical SaaS, push for a minimum floor (3x annual fees is a defensible starting position) or a separate, higher cap for data breach events specifically. Some vendors will accept a tiered structure: a lower cap for general service failures, a higher cap for breach of data protection obligations. The tier signals to the vendor that you understand what the real risks are.

The Carve-Out List, and What Is Missing From It

Every MSA includes a list of what falls outside the liability cap: typically gross negligence, wilful misconduct, death and personal injury, IP indemnities. These are the standard carve-outs, and they are worth having.

What counsel routinely miss: carve-outs operate both ways. If a vendor seeks uncapped customer-side liability for IP infringement arising from content the customer uploads to the platform, that asymmetry needs to be interrogated. It is a standard vendor position. It is not a balanced one.

The other gap in most carve-out lists: regulatory fines and third-party claims flowing from the vendor’s breach. If the vendor loses your data and a regulator fines you, your ability to recover that fine from the vendor depends entirely on whether your contract addresses it. Most do not. At minimum, carve out: data breach (including notification and remediation costs), breach of confidentiality, and wilful misconduct or fraud.

The Consequential Damages Exclusion as a One-Way Door

Most MSAs exclude consequential damages: loss of profits, loss of revenue, loss of business opportunity. Vendors draft this to protect themselves, and customers accept it without working through the implication. In a serious service failure, the bulk of what you would actually lose is almost always consequential.

A $50,000 contract where consequential damages are excluded and direct damages are capped at 12 months’ fees gives you a maximum recovery of $50,000 for a failure that could cost you multiples of that. Check two things before you sign: first, whether the exclusion is mutual (vendors often draft it to apply only to their own liability while leaving the customer’s payment obligations fully exposed); second, whether you have carved out data breach, breach of confidentiality, and wilful misconduct, because those are where your real losses sit.

Drax v Wipro is a reminder that ambiguity in these clauses is not resolved by what the parties intended. It is resolved by courts reading the language and choosing the interpretation with the “least bizarre” consequences. That interpretation may not be yours.

That’s what happens when liability caps are vague. The next issue is the flip side: when documentation obligations are crystal clear but nobody knows how to implement them.

If a Regulator Asked You Tomorrow: AI Documentation Obligations for Legal Teams

If a regulator asked you tomorrow to demonstrate how an AI-assisted decision in your practice was made, what would you show them? For most legal teams currently deploying AI tools, the honest answer is: the output, and nothing else.

That answer will not be sufficient for much longer. The EU AI Act is now in force. Documentation obligations for high-risk AI systems are live. And legal services, wherever AI is being used to inform decisions that affect legal rights, obligations, or outcomes, sit closer to the high-risk category than most legal teams are currently treating them.

This is not about whether the EU AI Act applies to your practice. It devolves on jurisdiction, system classification, and deployment context. It is also about the documentation discipline that good AI governance requires regardless of whether you are in scope, because the internal practice is the same whether compliance is mandatory or prudent.

What the EU AI Act Actually Requires on Documentation

For high-risk AI systems, the Act requires technical documentation sufficient to demonstrate compliance before the system is placed on the market or put into service. For deployers, organisations using AI tools rather than building them, the obligations focus on: maintaining logs of system operation, conducting fundamental rights impact assessments where required, ensuring human oversight is in place and documented, and keeping records of monitoring and incident management.

The practical translation for legal teams: if you are using an AI tool to assist with legal research, contract review, due diligence, or any process where the output informs a decision with legal consequences, you need to be able to show, not just assert, that a qualified human reviewed and took responsibility for that output. The log is the proof.

What Internal Documentation Should Actually Capture

Regulatory compliance sets the floor. Good practice sits above it. At minimum, internal AI documentation for legal use cases should capture:

The tool used and the version. AI models are updated continuously and outputs can differ between versions. If a decision is challenged six months from now, you need to know which version of the tool was used to inform it.

The prompt or input provided, not just the output. The input shapes the output. A poorly constructed prompt that produces a flawed analysis is a process failure, not just a technology failure. Documenting inputs creates accountability and enables improvement.

The human review step. Who reviewed the output, what they checked, and what judgment they applied. This is the record that demonstrates the AI supported the decision rather than made it. Without it, the audit trail ends at the tool.

Any material divergence between the AI output and the final work product. Where a reviewer corrected, supplemented, or rejected the output and why. This is where the value of human judgment becomes visible and documentable.

The Client-Facing Dimension

Increasingly, sophisticated clients are asking whether and how AI is being used in the delivery of legal services. Some are requiring disclosure as a matter of policy. Some are prohibiting use of certain tools on confidentiality grounds. Some are silent, which creates its own risk if AI use is not disclosed and a problem later emerges.

The documentation question here is straightforward: does your engagement letter or matter management process address AI use, client consent, and data handling? If not, that is the gap to close first. A client who later discovers their confidential matter information was processed through a third-party AI tool without disclosure has a legitimate complaint, irrespective of whether the output was good.

The Governance Structure Behind the Documentation

Documentation without a governance structure behind it is a paper exercise. Someone in the organisation needs to own the AI tool inventory: what tools are approved, for what use cases, under what conditions. Someone needs to own the review of that inventory as tools change and regulations develop. And someone needs to own the incident process, what happens when an AI output causes a problem, who is notified, and what is recorded.

In smaller legal teams this is often one person wearing multiple hats. That is workable. What is not workable is no one owning it, which is the current position in most legal teams deploying AI tools at pace.

The documentation requirement is not bureaucracy for its own sake. It is the mechanism by which human judgment remains accountable in an environment where AI is doing more of the analytical work. Any team building this discipline will be well positioned when regulators, clients, or courts ask the question that is coming: show me how this decision was made.

This newsletter is for discussion and informational purposes only and is not legal advice for any specific situation or jurisdiction.

Until the next time,

– Anjola Ige

NDAs: Criminal Liability, IP Risks, and Monetary Penalties

When you negotiate NDAs, you shouldn’t be checking for disclosure risks alone. The NDA I reviewed recently had cumulative minimum penalties of up to €100,000 per breach, criminal liability acknowledgements, unlimited confidentiality on personal data, and automatic IP assignment of anything the recipient created.

Disclosure was the least of the recipient’s problems.

The criminal liability acknowledgement

The NDA included an express acknowledgement by the recipient that unauthorised disclosure of confidential information constituted a criminal offence under applicable law.

This isn’t standard. Most NDAs stick to civil remedies: damages, injunctions, account of profits. Importing a criminal liability acknowledgement into the agreement is a deliberate drafting choice. It’s designed to do two things: signal the disclosing party’s seriousness, and put the recipient on notice in a way that could be relevant if criminal proceedings ever became a live question.

If you’re the recipient signing this, you’re not just agreeing to keep information confidential. You’re expressly acknowledging the criminal dimension of a breach. That’s a different kind of commitment.

Cumulative Minimum Penalties: €50k–€100k Per Breach

The NDA didn’t just provide for damages. It specified minimum liquidated damages of €50,000–€100,000 per breach, cumulative, in addition to actual damages and injunctive relief.

Per breach. Cumulative. On top of proven damages.

The practical effect: a recipient who makes three disclosures, even inadvertent ones, is potentially looking at €150k–€300k in minimum penalties before a court has assessed actual loss. Enforceability of liquidated damages clauses varies by jurisdiction (and courts will scrutinise whether the figures are a genuine pre-estimate of loss or a penalty), but the commercial pressure that clause creates is immediate and real regardless.

If you’re negotiating this as the recipient, this is not a clause to initial past. The floor, the cumulative structure, and the stacking on top of other remedies all need to come back to the table.

Unlimited Confidentiality on Personal Data and IP Assignment of Derivative Materials

Two things bundled together that don’t always get read as a pair.

The NDA imposed confidentiality obligations on personal data with no time limit. Most NDAs have a confidentiality term, three years, five years, sometimes tied to the purpose of the disclosure. Unlimited confidentiality on personal data creates obligations that effectively run indefinitely, which has implications for how the recipient manages, stores, and eventually deletes that data. It also sits in tension with data protection law in a number of jurisdictions, where retention limitations apply regardless of what a contract says.

The IP clause assigned ownership of all derivative materials, anything the recipient created that drew on the confidential information, to the disclosing party. Derivative materials clauses are common. Automatic assignment of ownership (rather than a licence or a use restriction) is more aggressive. If the recipient is doing any work that touches the confidential information, they could find that outputs of that work belong to someone else.

Together, these two clauses are the kind of thing that gets missed on a fast read because neither looks unusual in isolation.

Five Pressure Points in Aggressive NDAs

When reviewing an NDA under time pressure, these are the clauses worth going to first.

Remedy stacking. Does the NDA layer liquidated damages on top of actual damages on top of injunctive relief? Each remedy alone is standard. All three together, with minimum floors, is aggressive. Check whether the liquidated damages clause specifies a genuine pre-estimate of loss or reads more like a penalty.

Criminal liability language. Is there any acknowledgement of criminal exposure? If yes, flag it. Understand what law it’s referencing and whether that framing is accurate in the governing jurisdiction.

Confidentiality term by category. Most NDAs have a general term. Look at whether personal data, trade secrets, or specific categories have different terms, including unlimited ones, and what that means operationally for your client.

IP and derivative materials. Does the NDA touch IP? If so, is it a use restriction, a licence, or an assignment? Assignment language is the most consequential and the easiest to miss when it’s buried in definitions or schedules.

Definition of confidential information. Broad definitions aren’t inherently problematic, but an NDA that defines confidential information to include anything the recipient learns, observes, or infers during the relationship is a different creature from a standard NDA. The definition is where the scope of everything else is set.

None of this is legal advice, and enforceability always depends on governing law and commercial context. But these are the five places where aggressive NDAs tend to hide the most consequential obligations.

That’s the NDA. The second section looks at a different kind of risk exposure, one that is becoming harder to ignore for anyone managing vendor contracts in the AI space.

Singapore’s Agentic AI Governance Framework

In January, Singapore released the world’s first governance framework specifically designed for agentic AI.

If you’re not deep in the AI space, agentic AI refers to AI systems that don’t just generate content or answer questions. They act. They can process payments, update databases, send emails, book meetings, and execute multi-step tasks on your behalf, without a human pressing “go” at each stage.

Think of it this way: most AI tools today are like a very smart intern who drafts a memo and hands it to you for review. Agentic AI is the intern who drafts the memo, sends it to the client, schedules the follow-up call, and updates the CRM, all before you’ve finished your coffee.

The potential is enormous. The risk profile is also very different from anything we’ve governed before.

Singapore’s framework (launched at the World Economic Forum in January 2026 by the Infocomm Media Development Authority) addresses this by organising governance around four dimensions:

Assess and bound risks upfront. Before deploying an AI agent, evaluate what it can access and how independently it can act. An agent with read-only access to a database is a different risk proposition from one that can write to it, delete records, or trigger transactions. The framework pushes organisations to define those boundaries before deployment, not after something goes wrong.

Make humans meaningfully accountable. Accountability needs to be specific, not diffuse. The framework recommends defining clear checkpoints where human approval is required, particularly for high-stakes or irreversible actions (payments, deletions, communications to external parties). It also distributes responsibility across leadership, product teams, cybersecurity, and end-users. No single team owns this.

Implement technical controls across the lifecycle. This includes baseline testing before deployment, restricting agents to whitelisted services, assigning each agent a verifiable identity with time-bound permissions, and continuous monitoring in production. If an agent starts behaving outside its defined scope, there should be mechanisms to detect that and intervene.

Enable end-user responsibility. Users interacting with agentic AI need to understand what the agent can and cannot do, and how to escalate when something doesn’t look right. This requires transparency from the deploying organisation and, in many cases, training, particularly to guard against automation bias (the tendency to over-trust AI outputs simply because they come from a system that usually gets things right).

The framework is voluntary. It doesn’t carry penalties. But it signals where regulation is heading, and it’s already being positioned as the benchmark for responsible agentic AI deployment in the APAC region.

One detail that is extremely important for anyone working in contracts and vendor management: the framework explicitly recommends reinforcing accountability through contractual provisions with AI system providers, model developers, and tool vendors. So if your organisation is procuring agentic AI tools, your vendor agreements need to reflect these governance expectations, on boundaries, oversight, identity management, and incident response.

We’re still early. But the direction of travel is clear: as AI moves from generating to doing, governance has to move with it.

This newsletter is for discussion and informational purposes only and is not legal advice for any specific situation or jurisdiction.

Until the next time,

– Anjola Ige

Building an AI Oversight Committee That Actually Works

If I had to build an AI oversight committee from scratch today—after studying how IBM, Microsoft, and OpenAI structure theirs—here’s exactly how I’d do it.

IBM’s AI Ethics Board reviews use cases for trust and transparency. Microsoft’s Aether Committee embeds oversight into development with experts from engineering, law, and philosophy. OpenAI created an independent Board Oversight Committee with authority to delay model launches over safety concerns.

What they all have in common: clear decision-making authority, cross-functional membership, and fast processes.

Most companies are discovering the same problem: creating a committee is easy. Making it effective is hard. 40% of Fortune 100 companies now assign AI oversight to board-level committees—up from 11% in 2024 (EY research). But many meet monthly, discuss strategy conceptually, and risk employees bypassing them with unapproved tools.

Here’s the framework that separates functional committees from discussion groups:

Two Committees, Not One

Board committee (quarterly): Sets strategy, reviews major deployments, ensures regulatory compliance, like OpenAI’s Board Oversight Committee.
Management committee (bi-weekly): Approves tools, conducts risk assessments, implements policies, like IBM’s AI Ethics Project Office.

Boards set direction; management executes. One without the other fails.

Keep It Small (4–6 Core Members)

Microsoft’s Aether model relies on cross-disciplinary experts who can actually make decisions.

Core: Legal or Compliance, IT or Security, Chief Risk Officer, Business representative
Advisory (as needed): HR, Finance, Product

Twelve-person committees where everyone has veto power make zero decisions.

Define What the Committee Decides

Not “oversee AI governance.” That is meaningless.

The committee approves or denies:

• AI tool purchases (vendor review, data handling, cost)

• Use case deployments (bias assessment, human oversight)

• Vendor AI features (whether existing vendors can add AI)

• Policy exceptions (time-limited, with monitoring)

• Incident response (investigation, remediation, board escalation)

Build a Fast Approval Process

IBM’s approach embeds review into workflows so oversight does not bottleneck innovation.

Workflow:

• Low-risk: Reviewer approval, no meeting required

• Medium-risk: Email vote or sub-committee

• High-risk: Full committee discussion

Target timelines matter. Under five days for low-risk requests. Under ten days for high-risk ones.

Measure What Matters

Track velocity: days from request to decision, approval rates, backlog.
Track coverage: percentage of tools reviewed, percentage with human oversight, percentage of vendors with updated contracts.
Track incidents: AI failures, audit findings, near-misses.

If your committee is not making five to ten decisions per month, you have a discussion group, not oversight.

Effective committees decide which tools get approved, which use cases are too risky, and which vendors need contract amendments.
The ones that work answer requests in days, not “we’ll discuss it next month.”

That’s AI oversight. The next section is a different problem, but one that tends to surface just as painfully in practice: IP ownership when contractors and employees come on board.

IP Ownership: The Q1 Audit That Prevents Due Diligence Disasters

If I had to audit IP ownership for a company bringing on contractors and employees in Q1—after seeing what breaks during M&A due diligence—here’s exactly what I’d check.

I’ve seen this disaster too many times: a designer gets paid $45K to create a brand identity. Six months later, a cease-and-desist.
“You don’t own any of this. Stop using my work or pay me a licensing fee.”

The contract said they’d deliver the work. It never said the client would own it.

The result: $45K paid for unusable work, $80K to redo everything, a three-month delay, and a threatened lawsuit.

In most jurisdictions, the creator owns the work unless the contract explicitly assigns IP. Paying for work does not equal owning the work.

Here’s the Q1 IP ownership audit that prevents expensive do-overs and diligence disasters.

The Criticality of the Q1 Audit

Q1 hiring surge: Contractors for projects, agencies for campaigns, new employees. Each relationship creates IP, but who owns it depends entirely on your contracts.

Budget season: If you don’t own what you’re paying for, you’re renting, not buying.

Project kickoffs: Get IP ownership right before work begins, or spend Q2 fighting over it.

How IP Ownership Actually Works in Practice

Employees: You generally own what they create within the scope of employment, but local laws vary and some protect employee side projects.

Contractors: They own everything unless your contract explicitly assigns IP to you. This is the default in most legal systems.

Agencies: They often retain IP and grant you a license, which they can revoke, restrict, or reuse elsewhere.

Where IP Ownership Quietly Breaks Down

“Deliverables” Without Assignment

Contract:
“Contractor shall deliver logo design, website mockups.”

What this actually means:
The contractor delivers files but owns the IP. You cannot modify or reuse freely.

What the contract needs to say:
“Contractor hereby assigns, transfers, and conveys to Client all right, title, and interest, including all intellectual property rights, in all Deliverables and Work Product created under this Agreement.”

Why “hereby assigns” matters: present-tense creates immediate assignment. “Will assign” usually requires a separate document later.

Pre-Existing IP That Creates Landmines

A developer builds your app using their proprietary framework. You never address pre-existing IP. Now you cannot modify or maintain the app without them.

How this is usually corrected:
“Pre-Existing IP owned by Contractor is not assigned to Client, provided Contractor grants Client a perpetual, irrevocable, worldwide, royalty-free license to use Pre-Existing IP to the extent incorporated in the Work Product.”

When Agencies Retain Ownership

Agency language:
“We grant you a non-exclusive license to use the Deliverables.”

What this means:
The agency owns the IP, can license it to competitors, the license may terminate if you stop paying, and you may not be able to modify the work.

Standard correction:
“Agency assigns all IP in the Deliverables to Client. Agency retains a non-exclusive license solely for portfolio purposes, provided Agency does not license the work to any Client competitor.”

Moral Rights and Cross-Border Contractors

You hire a European designer. You modify their work. They claim a moral rights violation under local law, including the right to be credited or to object to modifications.

What contracts need to address:
“To the extent permitted by law, Contractor waives moral rights. Where moral rights cannot be waived, Contractor agrees not to exercise them in ways that interfere with Client’s use.”

Employee Side Projects and Founder IP

Many jurisdictions protect employee inventions created entirely on personal time, without employer equipment, and unrelated to the employer’s business.

Founder problem:
Three founders build a prototype before incorporation. One leaves. Due diligence later reveals that one-third of the core IP is personally owned.

What needs to happen:
Employment agreements must include IP assignment consistent with local law. Every founder should sign an IP assignment at incorporation covering all pre-incorporation IP.

Where Things Commonly Go Wrong

• Work starts before contracts are signed

• IP agreements are verbal

• Old contracts are assumed to cover new work

• Contractors hired years ago continue working without updated assignments

How This Shows Up in Due Diligence

That $45K disaster happened because the client assumed paying meant owning.

Most legal systems say the opposite: the creator owns the work unless there is explicit assignment.

The early conversation is simple:
“We need IP assignment. All work created will be assigned to us. Anything you bring in stays yours, but we get a license. Does that work?”

Most contractors say yes. The ones who don’t are telling you they plan to own what you’re paying them to create.

Start this week. By the end of February, every Q1 contractor should have proper IP assignment, and you should own what you’re paying for.

This newsletter is for discussion and informational purposes only and is not legal advice for any specific situation or jurisdiction.

Until the next time,
- Anjola Ige

Thank you for staying with this brief. This issue returns to first principles: what contracts actually allow you to do when the relationship stops working.

Termination Rights: Before You Renew, Check This

When Elon Musk took over Twitter, several vendors discovered that a signed contract does not guarantee smooth payment when the counterparty decides to stop performing. Twitter/X stopped paying multiple vendors and took aggressive positions on its obligations under existing agreements.

Imply Data Inc. sued for over $8 million in unpaid fees. They were not alone. The episode exposed a hard truth many companies only learn too late: if your termination rights are weak, enforcement becomes slow, expensive, and uncertain, even when you believe the contract is “clear.”

That is why I run a termination-rights audit before renewal season. The best time to negotiate an exit is before you need one.

The Termination Rights Audit Checklist

Part 1: Identify What Termination Rights You Actually Have

Pull every active contract and document:

☐ Termination for convenience (can you exit at any time, for any reason?)
☐ Termination for cause (what qualifies as “cause”?)
☐ Required notice periods
☐ Financial penalties for early termination
☐ Survival clauses (what obligations continue after termination?)
☐ Dispute resolution requirements before termination

What most companies discover:

• No termination rights at all. A good number of vendor contracts have no termination-for-convenience clause. You are locked in for the full term.

• “Material breach” without definition. The contract allows termination for “material breach” but never defines it. You end up litigating what “material” means.

• Notice periods that exceed the contract term. A 90-day notice period on a one-year auto-renewing contract means deciding three months before year-end whether to renew for another full year.

• Survival clauses that trap you post-termination. Confidentiality, non-compete, and indemnification obligations often survive termination, sometimes indefinitely.

Part 2: Five Types of Termination Rights (and When Each Matters)

Type 1: Termination for Convenience

What it is:
The right to terminate at any time, for any reason, with notice.

Sample language:
“Either party may terminate this Agreement for any reason upon [60/90] days’ prior written notice to the other party.”

When you need it:

• Testing new vendors or pilot programs

• Uncertain service needs

• High vendor risk or unproven technology

• Rapidly evolving markets

The catch:
Vendors often resist this or charge premium pricing to include it. For high-risk or high-value contracts, it is still worth negotiating.

Type 2: Termination for Cause

What it is:
The right to terminate if the other party materially breaches the contract.

Standard (problematic) language:
“Either party may terminate for material breach.”

Problems:

• “Material breach” is undefined

• No cure period is specified

• No process exists for determining breach

• Dispute resolution is often triggered before termination

More effective language:
“Customer may terminate immediately upon written notice if Provider:
(a) fails to meet Service Level Agreements for [3] consecutive months;
(b) experiences a data security breach affecting Customer data;
(c) materially breaches confidentiality obligations;
(d) becomes insolvent or files for bankruptcy; or
(e) fails to cure any other material breach within [30] days of receiving written notice specifying the breach.”

Specific triggers and defined cure periods reduce uncertainty and delay.

Type 3: Termination for Non-Payment

What it is:
The vendor can terminate if you do not pay. You can terminate if the vendor does not perform.

Vendor-protective language:
“Provider may terminate immediately if Customer fails to pay any undisputed invoice within [30] days of the due date.”

Customer-protective language:
“Customer may terminate immediately if Provider fails to deliver Services for [15] consecutive days or [30] days in any [90]-day period.”

Type 4: Termination for Regulatory or Legal Changes

What it is:
Either party may terminate if laws change and make performance illegal or impossible.

Sample language:
“Either party may terminate this Agreement upon [30] days’ notice if:
(a) a change in law makes performance of this Agreement illegal or impossible;
(b) regulatory requirements would require material modifications to the Services that fundamentally change the Agreement’s economics; or
(c) data protection laws prohibit the data processing contemplated by this Agreement.”

When this matters:
Cross-border data processing, regulated industries, and AI services where regulatory obligations are evolving.

Type 5: Termination Upon Change of Control

What it is:
The right to terminate if the vendor is acquired by a competitor or another unacceptable entity.

Sample language:
“Customer may terminate this Agreement upon [60] days’ notice if Provider undergoes a change of control, defined as the transfer of more than 50% ownership or voting rights, to an entity that competes with Customer or is subject to sanctions or export restrictions.”

Without this clause, you may be forced to continue working with your biggest competitor.

Part 3: The Hidden Termination Traps

Trap #1: Notice Periods Longer Than Reasonable

A 180-day notice period on a one-year contract means deciding halfway through Year 1 whether to renew for Year 2.

Fix:

• Contracts under one year: 30 days maximum

• One to three years: 60–90 days

• Three years or more: 90–120 days

Trap #2: Auto-Renewal with Short Opt-Out Windows

Miss the renewal window by one day and you are locked in for another full term.

Fixes:

• Replace auto-renewal with affirmative renewal

• Extend opt-out windows so notice can be given closer to the renewal date

Trap #3: Termination Penalties That Exceed Value

An early termination fee equal to 100% of remaining contract value means paying for services you will never receive.

Fix:
Cap early termination fees at the lesser of a defined percentage of remaining fees or the provider’s documented unwind costs.

Trap #4: Survival Clauses That Never End

Indefinite confidentiality obligations can restrict normal business operations long after termination.

Better approach:
Specify survival periods by clause type and tie them to statutes of limitation where appropriate.

Trap #5: Dispute Resolution Before Termination

Mandatory mediation or arbitration before termination can delay exit by six to twelve months.

Fix:
Allow termination to take effect immediately after cure periods expire, with dispute resolution addressing only post-termination obligations.

Part 4: The Vendor Negotiation Reality

What vendors will resist:

• Termination for convenience

• Broad termination-for-cause triggers

• Short notice periods

What vendors may accept in exchange:

• Longer initial terms

• Higher pricing

• Volume commitments

• Notice coupled with payment through the notice period

Understanding these trade-offs allows termination rights to be negotiated without derailing the commercial relationship.

Common Mistakes That Leave Companies Trapped

1. Skimming termination clauses at signing

2. Accepting “industry standard” language without scrutiny

3. Missing auto-renewal deadlines

4. Failing to calendar notice periods

5. Ignoring the vendor’s termination rights

Why This Matters Before Renewal Season

That client trapped in an underperforming vendor contract did not have a legal problem. They had a negotiation problem.

They signed an agreement without meaningful termination rights, assuming they could always exit if things went badly. By the time they needed out, their only option was expensive litigation to prove “material breach.”

A January / Q1 audit is not about planning to terminate everyone. It is about ensuring you can terminate if you need to.

The best termination rights are the ones you never use. But having them changes the relationship, because both sides know the arrangement continues by choice, not because one party is trapped.

Start this week. By the end of February, you will know which contracts give you flexibility and which ones quietly lock you in. That knowledge puts you in a very different position when renewal season arrives.

— Anjola Ige

This edition looks at a problem that shows up repeatedly in AI-related work: documents that look familiar but no longer do what we assume they do. Contract clauses drafted for one operational reality are now being asked to govern another. Governance policies written to signal intent are expected to control systems that evolve continuously.

The result is not usually immediate failure. It is misalignment. Risk shifts covertly, often without anyone consciously agreeing to take it on.

I’ll start with contracts, because this is where the mismatch tends to surface first.

When AI Contracts Still Look Like SaaS Contracts

I have learned that if an AI contract looks like a traditional SaaS contract, risk is probably being misallocated.

Conventional SaaS language is built on determinism. The same input produces the same output. Performance is measurable. Failure is usually about uptime, bugs, or security incidents. AI breaks those assumptions, and with them, many of the foundations of standard contract frameworks.

As AI systems become probabilistic, adaptive, and continuously updated, familiar clauses start to behave very differently in practice. Below are the provisions that most often look unchanged on the page, but operate differently once AI is involved.

Service Levels and Performance Warranties

Traditional SaaS
Performance is defined by uptime, response times, and availability. These are objective and verifiable.

AI systems
Performance becomes contextual. Accuracy fluctuates depending on input quality, data distribution, and retraining cycles. A commitment to “99 percent accuracy” raises immediate questions: accuracy against which dataset, under what conditions, and for how long? What happens when retraining improves outcomes for some use cases but degrades them for others?

AI outputs cannot be warranted in the same way as system availability. At the same time, customers still need assurance that systems will perform within acceptable bounds. The contractual challenge is defining performance in a way that reflects probabilistic behavior rather than deterministic output.

Data Security and Confidentiality

Traditional SaaS
Confidentiality focuses on access control and storage. Data is protected, segregated, and returned or deleted at termination.

AI systems
Data is not just stored. It may be used to train, fine-tune, or optimize models. This raises questions that standard confidentiality clauses do not answer. Does confidentiality extend to patterns learned from data? Can a model trained on one customer’s data generate outputs that indirectly reflect that information to others?

Embeddings, model weights, and fine-tuned versions complicate the analysis further. Confidentiality in an AI context is no longer just about who can access data. It is about whether insights derived from data persist beyond the relationship.

Warranty Disclaimers and “Use at Your Own Risk”

Traditional SaaS
Broad disclaimers are common and generally accepted. Customers understand that software is provided “as is.”

AI systems
The position becomes more fragile when customers rely on AI outputs for hiring, medical, financial, or operational decisions. Courts and regulators are increasingly skeptical of blanket disclaimers where AI materially influences outcomes.

The practical question is not whether to disclaim warranties entirely, but how to distinguish between what the provider warrants, such as security, uptime, and data handling, and what the customer remains responsible for validating, such as the suitability of outputs for specific use cases.

Acceptable Use Policies

Traditional SaaS
Acceptable use provisions tend to be high-level and lightly enforced.

AI systems
The scope expands quickly. Can customers use outputs to train competing models? Are there restrictions on high-risk decision-making without human oversight? Can AI-generated content be used in ways that expose intellectual property or regulatory risk?

Emerging regulations increasingly mandate human involvement and transparency for certain applications. Acceptable use provisions may need to prohibit activities that were never contemplated in legacy agreements, or impose safeguards that the provider does not directly control.

Intellectual Property Ownership

Traditional SaaS
Ownership is typically split cleanly. Customers own their data. Providers own the platform.

AI systems
Inputs from customers combined with provider models produce outputs that sit somewhere in between. Ownership of those outputs is rarely clear. The situation becomes more complex at termination, when customers expect access not just to raw data, but to the outputs and workflows they relied on, while providers retain the trained systems that incorporate those interactions.

Traditional IP clauses do not address this three-way relationship between inputs, outputs, and model learning.

Limitation of Liability

Traditional SaaS
Liability caps and exclusions are calibrated around service outages or software defects.

AI systems
Failures are different. Harm may arise from bias, hallucination, or inaccurate outputs that function exactly as designed. A capped liability framework that makes sense for availability risk may be misaligned where downstream harm is the primary exposure.

As responsibility for validating outputs shifts toward customers, contracts often fail to reflect how risk is actually distributed.

Change Management and Model Updates

Traditional SaaS
Change clauses are typically broad and rarely negotiated.

AI systems
Model updates are continuous and can materially affect behavior. Improvements for one customer may degrade performance for another. The question of what constitutes a material change, and what notice or consent is required, becomes far more significant.

This is emerging as a central negotiation point, and one that legacy language was never designed to address.

These are not theoretical issues. They are active fault lines in current AI contract negotiations. The market has not settled on standard answers, and outcomes vary widely depending on leverage, use case, and risk tolerance.

Setting Up AI Governance for 2026

Contracts alone cannot carry this weight. Governance frameworks are increasingly expected to absorb what contractual language cannot fully control.

A well-known example illustrates the point. In 2023, Samsung discovered that engineers had inadvertently shared sensitive internal data with public generative AI tools. The incident exposed gaps in internal controls and prompted restrictions on external AI use while safer processes were developed.

More recent data suggests this is not an isolated problem. A 2025 LayerX Security report found that 18 percent of enterprise employees regularly paste data into generative AI tools, and more than half of those uploads include confidential corporate information.

Against that backdrop, the question for 2026 is not whether to govern AI, but how quickly governance needs to move from policy statements to operational controls.

Below is a minimum viable framework designed to do exactly that.

1. AI Usage Inventory

Document every AI system in use across the organization, including employee productivity tools, customer-facing systems, operational AI, and vendor tools that process company data.

This step is foundational. Governance cannot function where visibility is incomplete.

2. Risk Classification

Classify each AI system by risk level and business impact. Systems affecting hiring, pricing, or critical operations warrant a different level of scrutiny than internal productivity tools.

Risk classification drives compliance obligations, budget allocation, and control design.

3. Vendor AI Assessment

Vendor contracts should explicitly address AI use. Key questions include whether AI processes company data, what data retention guarantees apply, who owns outputs, what liability applies if AI fails, and what human oversight exists.

Governance without vendor transparency is largely symbolic.

4. Internal AI Usage Policy

Policies should clearly distinguish between prohibited and permitted uses, and require human review of AI outputs where decisions carry real consequences. They should also establish incident reporting and training obligations.

The objective is not to ban AI, but to define safe and accountable use.

5. Ongoing Monitoring

AI governance is not static. Monitoring should track usage patterns, vendor changes, regulatory developments, and compliance with internal policies.

Ownership must be assigned clearly, whether to legal, compliance, IT, or a cross-functional group.

Immediate Action Items

• Inventory AI tools across departments

• Classify systems by risk

• Draft or update AI usage policies

• Add AI disclosure requirements to vendor contracts

• Assign governance ownership

• Schedule regular governance reviews

AI governance in 2026 is not about slowing innovation. It is about ensuring that adoption does not outpace control.

Closing Thoughts

Across both contracts and governance, the issue is less about novelty, but more about familiarity. Old language carries assumptions that no longer hold, and governance structures built for static systems struggle with tools that evolve continuously.

If this raised questions you are currently dealing with, you are welcome to reply. I read every message.

— Anjola Ige

So let’s begin with contracts, and what a proper Q1 audit actually tells you.

The Q1 Contract Audit Every Business Should Do

By February, you already know which contracts will cause problems in July.

After working on M&A, finance, and commercial transactions in law firms and in-house roles, I have seen the same pattern repeat itself. Disputes, revenue leakage, and compliance failures almost never come out of nowhere. They are already visible early in the year, if you know where to look.

A Q1 contract audit is not about rereading templates or refreshing boilerplate. It is about stress-testing how contracts interact with the business as it actually operates today, not how it operated when the deal was signed.

What you act on will depend on leverage, value, risk profile, and operational reality. Ignoring these categories, however, almost guarantees unpleasant surprises later in the year.

Category 1: Vendor and Commercial Agreements (Cost Control)

What to audit

• SaaS subscriptions and software licenses

• Professional services agreements (legal, accounting, consulting)

• Marketing and agency contracts

• Cloud infrastructure and hosting agreements

• Office services (facilities, security, cleaning)

What to look for

Auto-renewal provisions remain one of the most consistent sources of unnecessary spend. Many software contracts include 30 to 90 day notice windows. If those dates are not tracked now, the opportunity to renegotiate will pass quietly.

Unused or underused licenses are another common issue. Contracts are often priced for growth assumptions that did not materialize. Paying for capacity you no longer need is rarely defensible once it is identified.

Overlapping tools tend to proliferate as teams make independent purchasing decisions. Consolidation is not always possible, but the audit should at least surface where redundancy exists.

Price escalation clauses also deserve early attention. Automatic annual increases of three to five percent compound quickly. Renegotiation leverage is highest before increases take effect.

Finally, volume or spend commitments that are no longer being met should be flagged. Underutilization can trigger true-up payments or place the business in breach, even where the commercial relationship feels stable.

Category 2: Employment Agreements (Compliance and Retention Risk)

What to audit

• Executive employment agreements

• Equity and stock option documentation

• Non-compete and non-solicitation provisions

• Bonus and commission plans

• Consultant and contractor agreements

What to look for

Vesting schedules often create risk windows in the first half of the year. Founders or executives approaching cliffs may be reassessing their position. Whether the terms remain competitive is a strategic question, not just a legal one.

Non-compete enforceability continues to evolve. Restrictions that were enforceable when drafted may no longer be defensible. An audit should identify where assumptions no longer align with current law.

Contractor misclassification remains a persistent exposure. Full-time hours, company equipment, and operational integration can undermine independent contractor status, regardless of how the agreement is labeled.

Equity documentation is another frequent pressure point. Missing board approvals or incomplete grant records can turn incentive plans into dispute magnets.

Expired background checks, certifications, or regulatory clearances are easy to miss and expensive to fix after the fact.

Category 3: Customer Agreements (Revenue Protection)

What to audit

• Master service agreements with key customers

• Subscription and renewal terms

• Payment terms and receivables aging

• SLA commitments and tracking

• Termination and suspension rights

What to look for

Payment terms often drift in practice. Net-30 on paper becomes Net-90 in reality. Contracts frequently provide remedies that are simply not enforced.

Service level agreements are another blind spot. If performance is not measured, credits and refunds can accumulate unnoticed or disputes can arise without supporting data.

Pricing terms in older agreements may no longer reflect current value. Contracts signed years ago without escalation mechanisms quietly cap revenue.

Termination rights are also underused. Continued non-payment beyond contractual cure periods should trigger action, not tolerance.

Revenue leakage often appears where services are delivered outside agreed scope. Over time, these concessions become expectations.

Category 4: Insurance and Indemnification (Risk Containment)

What to audit

• Vendor insurance obligations

• Certificates of insurance on file

• Indemnities given and received

• Cyber and D&O coverage adequacy

What to look for

Contractual insurance requirements are meaningless if coverage has lapsed or never existed. Limits that once felt adequate may no longer reflect current exposure.

Certificates naming the business as an additional insured should be collected and verified, not assumed.

Indemnities unsupported by sufficient insurance shift risk directly onto the balance sheet. A ten million indemnity backed by two million in coverage is not neutral.

Growth changes risk. Headcount, data volume, and regulatory exposure may have increased while insurance limits stayed static.

Category 5: Regulatory and Compliance Agreements (Avoidable Exposure)

What to audit

• Data processing agreements

• Vendor due diligence records

• Privacy policies and terms of service

• Industry-specific compliance contracts

What to look for

Outdated DPAs, particularly those drafted before GDPR enforcement or without AI considerations, create real regulatory exposure.

Vendor assessments become stale quickly. A SOC 2 report from 2021 says little about current controls.

Misalignment between written policies and operational reality is increasingly visible to regulators. If policies prohibit AI use while teams actively deploy AI tools, that inconsistency becomes a liability.

Acquisitions often bring inherited contractual and compliance gaps. Those liabilities transfer whether they are audited or not.

Contracts are not static artifacts. They are ongoing commitments that require active management. A Q1 audit creates visibility into what the business is paying for, what it is exposed to, and where action is still possible.

Switching gears, here’s what changed in AI regulation in December.

December 2025 AI Regulatory Updates (At a Glance)

Below are two visual summaries covering the most relevant AI regulatory developments from December 2025, across key jurisdictions.

A brief interpretive note is worth adding here. December marked a shift away from headline lawmaking and toward implementation, institutional alignment, and enforcement posture. Governments appear less focused on defining AI in the abstract and more focused on how existing frameworks will be applied in practice. For teams deploying or procuring AI systems, this means expectations are becoming operational, not theoretical.

Looking Ahead

The connective tissue across this issue is not contracts or AI in isolation. It is how quietly risk accumulates when documents, systems, and practices drift out of alignment.

If there is a topic you would like explored, or a scenario you are currently grappling with, you are welcome to reply directly. I read every message.

Thank you for being here.

— Anjola Ige

This article breaks down the nine core documentation components required by Annex IV of the AI Act, offers real-world examples from industry leaders, and provides strategic advice to treat documentation as a valuable asset rather than a burden.

A Guide to EU Compliance Categories

The EU AI Act classifies AI systems into four risk levels: unacceptable, high, limited, and minimal. High-risk AI systems are those that pose significant threats to health, safety, or fundamental rights. Examples include AI used in:

• Biometric identification and categorization of natural persons

• Management and operation of critical infrastructure

• Education and vocational training

• Employment, worker management, and access to self-employment

• Access to and enjoyment of essential private services and public services and benefits

• Law enforcement

• Migration, asylum, and border control management

• Administration of justice and democratic processes

These systems are subject to stringent requirements to ensure their safety and compliance.

Your AI's Paper Trail Is as Important as Its Algorithm

High-risk AI systems used in healthcare, recruitment, critical infrastructure, and more, face strict documentation obligations to ensure safety and legal conformity. The EU AI Act requires providers to prepare detailed technical documentation demonstrating compliance with all legal requirements. This documentation must be clear, comprehensive, and continuously updated.

The Act’s documentation requirements phase in starting 2025, with full obligations by 2026. Startups and SMEs benefit from a simplified format provided by the European Commission, but critical elements remain mandatory. Providers must retain documentation for at least ten years after market placement, making this a long-term commitment.

The Essential 9: Documentation Pillars for High-Risk AI

1. General Description of the AI System

Begin with a clear overview of your AI system’s identity and environment:

• Intended Purpose & Version: What the AI does, its intended use, provider name, and version.

• Interaction with Other Systems: How it integrates with hardware/software or APIs.

• Software/Firmware Details: Required software versions and update policies.

• Forms of Distribution: Cloud service, on-premise software, embedded modules, APIs.

• Hardware Description: Specific hardware requirements if applicable.

• Product Images/Diagrams: Visuals illustrating the AI system or its physical integration.

• User Interface and Instructions: How deployers interact with the system and operate it safely.

This section orients regulators and users to the AI’s function and deployment context.

2. Detailed Description of Development and Design

Document how your AI was built and designed:

• Development Methods & Tools: Use of pre-trained models, open-source libraries, AutoML, etc.

• Design Specifications & Key Choices: Model architecture, optimization goals, trade-offs (e.g., accuracy vs. explainability).

• System Architecture: Diagrams showing components, data flow, and computational resources.

• Data Requirements and Datasets: Data provenance, labeling, cleaning, representativeness, and bias mitigation.

• Human Oversight Measures: Mechanisms enabling human intervention and explainability.

• Foreseeable Changes: Planned updates, retraining, or module replacements with compliance controls.

• Validation and Testing Procedures: Test data, metrics, results, and signed test logs.

• Cybersecurity Measures: Protections against tampering, data poisoning, and other threats.

Capture these details during development to ensure accuracy and traceability.

3. Monitoring, Functioning, and Control Information

Describe the AI’s operational behavior and oversight:

• Capabilities and Limitations: Expected accuracy overall and for specific groups or conditions.

• Foreseeable Unintended Outcomes & Risks: Potential false positives, biases, or safety risks.

• Human Oversight in Operation: Real-time monitoring, kill switches, and operator instructions.

• Input Data Specifications: Constraints on input data quality and format.

This user-manual style section clarifies AI reliability and safe operation parameters.

4. Risk Management System

Outline your safety and ethics framework:

• Risk Assessment Methods: Techniques like Failure Mode and Effects Analysis (FMEA).

• Known Risks and Mitigations: Bias, cybersecurity, misclassification, and other risks.

• Responsible Roles: Who manages risk reviews and their frequency.

This system supports ongoing risk identification and mitigation as required by Article 9.

5. Performance and Testing Logs

Provide evidence of thorough evaluation:

• Metrics: Accuracy, robustness, fairness, and other relevant measures.

• Validation Records: Testing environments, procedures, and outcomes.

• Metric Justifications: Why selected metrics fit your use case.

• Signed Logs: Validation by responsible personnel.

These logs demonstrate due diligence and system reliability.

6. Change Management Log

Maintain traceability of updates:

• Version Control History: What changed, why, and how compliance was maintained.

• Update Triggers: Events like post-market monitoring revealing new risks.

A living changelog ensures transparency over the AI’s lifecycle.

7. Standards and Declarations

Confirm compliance with recognized norms:

• Harmonized Standards: Such as ISO/IEC 23894 (risk management) or IEEE transparency standards.

• Alternative Approaches: Document internal best practices if no standard applies.

• EU Declaration of Conformity: The formal legal declaration under Annex V.

This affirms your alignment with legal and technical standards.

8. Post-Market Monitoring Plan

Commit to ongoing safety:

• Monitoring Procedures: How the AI will be observed after launch.

• Trigger Metrics: Incidents or data patterns prompting review.

• Response Plans: How issues or performance drift will be addressed.

This proves compliance is continuous, not one-time.

9. Conformity Assessment and CE Marking

Before placing a high-risk AI system on the market, providers must conduct a conformity assessment to ensure compliance with the AI Act. This process may involve internal checks or third-party evaluations, depending on the system's nature. Upon successful assessment, the AI system must bear the CE marking, indicating it meets EU standards. This marking is essential for legal market placement and demonstrates adherence to safety and performance requirements.

Leading by Example: How Top Companies Tackle AI Compliance

• SAP has centralized AI compliance teams integrating Annex IV documentation into their software lifecycle, especially for high-risk HR AI tools.

• Microsoft develops “Transparency Notes” aligned with Annex IV to build trust internally and externally.

• Siemens uses its Polarion ALM tool to create audit-ready documentation linking code to compliance for industrial AI.

These leaders treat documentation as a design discipline integral to product development, not just a regulatory task.

Your First Steps: Navigating AI Compliance as a Startup

Starting documentation early, integrating it into your development workflow, and viewing it as a strategic asset will position your AI system for success in a regulated world. As first steps:

• Prepare a clear general system description.

• Document development methods, design decisions, and architecture.

• Maintain detailed data governance and bias mitigation records.

• Define human oversight provisions and explainability.

• Keep rigorous performance testing logs with signed approvals.

• Establish a risk management system with clear roles.

• Track all changes with version control and compliance notes.

• Align with harmonized standards and prepare the EU Declaration of Conformity.

• Develop a robust post-market monitoring plan.

• Conduct a conformity assessment and affix the CE marking.

This condensed guide equips AI providers with a clear roadmap to meet EU AI Act documentation requirements effectively, turning compliance into a foundation for trust and innovation.

Note: This article was generated with the assistance of artificial intelligence. The content is provided for informational purposes only and does not constitute legal advice.

“What if my AI system isn’t banned but still impacts people’s rights or safety?”

The answer lies in the “high-risk” classification, a pivotal determination for AI providers. If your system falls into this category, stringent compliance obligations apply before market entry. Let’s clarify how to assess your AI’s risk level under the EU AI Act.

Understanding High-Risk AI: Legal Foundations

The EU AI Act defines high-risk systems in Article 6 and Annex III, with Article 7 outlining updates to these categories. A system is high-risk if it:

1. Serves as a safety component in regulated products (e.g., medical devices, vehicles).

2. Operates in one of eight critical areas where AI could significantly harm health, safety, fundamental rights, or access to essential services.

The 8 High-Risk Domains

Per Annex III, these areas include:

1. Biometric Identification: Systems categorizing individuals via facial recognition or voiceprints.

2. Education/Vocational Training: Tools influencing admissions, grading, or career pathways.

3. Employment/Worker Management: AI used in hiring, performance evaluations, or termination decisions.

4. Access to Essential Services: Algorithms determining eligibility for loans, healthcare, housing, or social benefits.

5. Law Enforcement: Predictive policing tools or forensic evidence analyzers.

6. Border Control/Migration: Visa/passport screening systems.

7. Justice/Democratic Processes: AI assisting judicial rulings or electoral processes.

8. Safety Components in Regulated Products: AI embedded in medical devices, aviation systems, or industrial machinery.

Key Exemption: Systems in these areas may avoid classification if their impact is deemed non-significant (e.g., an HR tool suggesting non-critical workflow adjustments).

Real-World Examples

High-Risk AI:

• A university admissions algorithm prioritizing applicants based on historical data.

• A recruitment chatbot filtering resumes without human intervention.

• A credit-scoring model denying microloans to small businesses.

• A judicial tool recommending sentencing ranges for criminal cases.

Non-High-Risk AI:

• Grammar-checking software for bloggers.

• NPC dialogue generators in video games.

Self-Assessment Checklist

Ask these questions to gauge your system’s risk level:

1. Decision Impact: Does it influence critical outcomes in employment, education, law enforcement, or financial access?

2. Essential Services: Could it deny someone housing, healthcare, or social benefits?

3. Regulated Products: Is it part of a product requiring EU safety certification?

4. Significance Threshold: Is its impact substantial enough to affect rights or safety?

A “yes” to any question suggests high-risk classification.

The Whole Point of Compliance

High-risk AI triggers legally mandated steps:

• Conformity Assessments: Third-party audits for certain systems (e.g., medical devices).

• Technical Documentation: Detailed records of data sources, design choices, and risk mitigation.

• Transparency: Clear user notifications when interacting with AI.

• Human Oversight: Mechanisms to override automated decisions.

• CE Marking: Regulatory approval for EU market access.

Penalties: Non-compliance risks fines up to €20 million or 4% of global turnover, whichever is higher.

Timeline to Prepare

While banned AI systems have been illegal since February 2025, high-risk obligations take effect on August 2, 2026. Most organizations need 12–18 months to build compliant systems, making early action critical.

Next Steps

If your AI isn’t prohibited but affects rights or safety:

1. Conduct a risk assessment using Annex III criteria.

2. Engage legal/technical experts to interpret ambiguities.

3. Prioritize documentation, it’s the backbone of compliance.

In my next post, I’ll break down the operational steps for meeting high-risk requirements, from conformity assessments to post-market monitoring.

Need clarity? Reach out for a no-nonsense discussion about your system’s status. Let’s navigate compliance together, without jargon or gatekeeping.

The Legal Basis for Prohibited AI Practices

Unacceptable Risk Classification

Article 5 of the EU AI Act prohibits AI systems that manipulate human behavior, exploit vulnerabilities, or threaten democratic principles. These prohibitions apply irrespective of technical safeguards, reflecting the EU’s stance that such technologies are fundamentally incompatible with its Charter of Fundamental Rights. The classification hinges on two criteria:

1. Material distortion of behavior: Systems designed to subconsciously influence decisions in ways users cannot perceive or resist.

2. Systemic harm potential: Technologies likely to cause physical, psychological, or societal damage at scale.

Banned Practices and Their Scope

The Act explicitly prohibits seven categories of AI applications:

• Subliminal Manipulation

AI systems deploying subliminal techniques, such as imperceptible visual/auditory cues to distort behavior in ways causing harm. Example: Retail algorithms using micro-expressions to influence purchasing decisions.

• Exploitation of Vulnerabilities

AI targeting individuals based on age, disability, or socioeconomic status to manipulate choices detrimentally. This includes algorithms capitalizing on cognitive decline in elderly users or financial desperation in low-income groups.

• Social Scoring

General-purpose systems assigning scores to individuals or groups that lead to unjustified differential treatment. While China’s social credit system is a prime example, the ban also covers private-sector applications like employer reputation scoring.

• Real-Time Biometric Identification

Real-time remote biometric identification (RBI) in public spaces by law enforcement, except for narrowly defined scenarios. Permitted uses include locating victims of trafficking or preventing imminent terrorist attacks, subject to judicial authorization.

• Emotion Recognition

AI claiming to infer emotional states in educational or workplace settings. While the Act broadly bans emotion inference systems, its specific prohibition in schools and workplaces addresses concerns about pseudoscientific mental state profiling.

• Predictive Policing

Systems predicting criminal activity based solely on profiling (e.g., ethnicity) or geographical data without individualized behavioral evidence. This targets practices like predictive patrol allocation in neighborhoods with high minority populations.

• Biometric Categorization

AI classifying individuals by sensitive attributes (race, religion, political affiliation) to infer characteristics like criminal propensity or sexual orientation.

Case Studies: Prohibited AI Systems in Context

Education Sector

During the pandemic, some EdTech solutions explored AI systems that analyzed student webcam footage to assess attention or emotional engagement.

Under Article 5(1)(e) of the EU AI Act, these systems are now banned in educational institutions, given their reliance on emotion recognition.

Retail Industry

Hypothetically, a retailer using inaudible AI-driven audio cues in fitting rooms to influence shoppers' behavior would now be in breach of the Act.

Article 5(1)(a) prohibits AI that uses subliminal techniques to materially distort behavior without the person’s awareness.

Law Enforcement

Spanish police have piloted real-time facial recognition in metro systems for surveillance.

As of February 2025, such systems are prohibited unless they meet narrow law enforcement exemptions (e.g., searching for a missing person) and have judicial approval, as outlined in Article 5(1)(d).

Enforcement Dynamics and Penalties

Compliance Deadlines

The prohibition regime became enforceable on 2 February 2025, six months after the AI Act’s entry into force. Subsequent deadlines include:

Penalty Structure

Violations of Article 5 incur fines up to €35 million or 7% of global annual turnover, the highest tier under the Act’s graduated penalty system. Enforcement authority resides with national market surveillance bodies, which must report annually on prohibited system usage.

Exceptions and Safeguards

Real-time RBI exceptions require:

• Temporal and geographical limits: Deployments restricted to specific locations and timeframes.

• Judicial oversight: Prior authorization from independent administrative or judicial bodies.

• Proportionality: Use only when strictly necessary to achieve defined objectives.

Practical Implications for Stakeholders

Business Risks

1. Third-party liability: Companies using prohibited AI tools developed externally remain liable as "deployers".

2. Global reach: The ban applies to any system affecting EU residents, regardless of developer location.

3. Dynamic regulations: The European Commission must review and potentially expand prohibited practices biannually, requiring continuous monitoring.

Compliance Strategies

1. Audit existing systems: Identify tools using emotion recognition, biometric categorization, or behavioral prediction.

2. Revise procurement contracts: Ensure third-party AI vendors comply with Article 5.

3. Train staff: Implement AI literacy programs focusing on prohibited practices.

Future Regulatory Trajectory

The European Commission’s AI Office will:

• Publish guidelines interpreting Article 5’s prohibitions.

• Establish a stakeholder forum for reporting emerging risks.

• Propose new bans, such as AI-generated deepfakes in political campaigns, by 2026.

Conclusion

The EU AI Act’s prohibited practices regime represents a decisive shift toward preemptive AI governance. By outlawing technologies deemed irredeemably harmful, the EU prioritizes fundamental rights over innovation in contested domains. Businesses must treat these prohibitions as non-negotiable compliance thresholds, integrating Article 5 due diligence into all AI-related activities. As the Commission expands the banned list, proactive monitoring of regulatory updates becomes essential to avoid severe financial and reputational repercussions.

The AI ecosystem is once again alive with regulatory momentum as the European Union, in collaboration with various stakeholders and working groups, pushes to finalize the General-Purpose AI (GPAI) Code of Practice (the GPAI Code or the Code). With its expected finalization in May 2025 and applicability beginning August 2, 2025, the Code remains a moving target, with potential last-minute refinements before it takes full effect. Yet, despite its evolving nature, businesses and AI providers cannot afford to wait, compliance obligations are taking shape, and the regulatory train is not slowing down.

This article takes a critical look at the key updates in the 3rd Draft of the GPAI Code, assessing what has changed, what remains ambiguous, and how businesses should be positioning themselves. In light of growing concerns around systemic risks, AI transparency, copyright compliance, and security, this analysis aims to break down the Code’s real-world implications and highlight areas where uncertainty persists, or as I like to call it, the 'reasonable effort' conundrum.

Why Was the GPAI Code Created?

The Code was developed to help AI providers meet the expectations set out in Articles 53 & 55 of the AI Act, particularly those offering General-Purpose AI models with Systemic Risk (GPAISR). The Code is intended to flesh out and refine the AI Act’s requirements, particularly in areas where risk, accountability, and enforcement mechanisms were previously unclear. The Code serves as a guiding document for demonstrating compliance with the AI Act, however, adherence to the Code does not constitute conclusive evidence of compliance with the AI Act. Specifically, it focuses on helping GPAI and GPAISR providers (as applicable):

• Maintain model transparency by documenting data sources, capabilities, and limitations.

• Adhere to copyright and intellectual property safeguards, particularly in training data usage.

• Implement robust safety and security measures to mitigate systemic risks associated with powerful AI models.

AI Regulation: A Moving Target

Comprehensive AI regulation at this scale is still evolving, and enforcement remains largely untested. Policymakers are in a continuous balancing act, creating rules that are enforceable yet flexible enough to accommodate rapid technological shifts. Much like the AI Act during its drafting phase, the GPAI Code has undergone multiple revisions, each iteration reflecting stakeholder negotiations, industry pushback, and emerging AI risks. The goal? To produce a compliance framework that is practical, enforceable, and actually addresses the real issues in AI safety and governance.

While some revisions bring much-needed clarity, others raise new questions about feasibility, enforcement, and potential loopholes. As we move forward, the critical issue remains: Does this Code get us closer to a functional AI regulatory framework, or are we simply building another layer of bureaucratic complexity?

Overall Impact of the 3rd Draft: What Has Changed and What Remains Unclear

Some changes in the latest draft have been significant. There have been bold additions that introduce new compliance expectations for Signatories, which in this context refers to AI providers and developers who voluntarily commit to adhering to the GPAI Code. Alongside these additions, the draft also brings much-needed clarifications, addressing key concerns raised by stakeholders about the previous version. However, not everything is clear. Some areas remain vague, leaving room for interpretation. Or like I said I like to call it earlier, the reasonable effort conundrum.

Transparency: Key Changes

Transparency expectations under the Code vary depending on factors such as whether the model is proprietary or open-source and whether it falls under systemic risk classification. However, providers of GPAISR and those seeking to integrate their models into AI systems are encouraged to follow stricter transparency practices.

The most notable updates in the third draft include:

• The introduction of a Model Documentation Form, standardizing the way providers disclose model details.

• Documentation retention for at least 10 years after the model is withdrawn from the market, ensuring long-term traceability and regulatory compliance.

• Public transparency obligations, requiring providers to publish key contact details and certain documentation on their website so downstream AI system developers can access relevant compliance information.

• Stricter guidelines on disclosure obligations to AI system developers integrating these models, clarifying what information must be shared with downstream users versus regulators.

• Trade secret protection, which allows providers to withhold certain proprietary details while still meeting transparency requirements.

Copyright: Key Changes

Copyright compliance here applies to GPAI providers using publicly available or proprietary datasets for model training. The most significant changes in the latest draft are:

• Compliance obligation for signatories to respect machine-readable rights reservations (e.g., robots.txt), requiring providers to ensure their web crawlers comply with content restrictions.

• Stronger obligations to prevent AI models from memorizing and reproducing copyrighted content, reducing the risk of legal challenges.

• Requirement to maintain records of dataset sources, ensuring companies can prove lawful data collection if audited.

• Obligation to establish a structured complaint mechanism for rightsholders, making it easier for copyright owners to report potential infringements.

• Clearer guidelines on exceptions for open-source models, reducing compliance burdens for non-commercial AI development.

Safety and Security: Key Changes

Safety and security measures apply to GPAI models with systemic risk and have seen the most extensive revisions. Some of the most substantial updates include:

• Risk assessment obligations now linked to capability-based evaluations, requiring providers to assess whether their models can develop unforeseen harmful capabilities.

• Proportionate model evaluation requirements, allowing lower-risk models to undergo less intensive compliance testing.

• Requirement for post-market monitoring mechanisms, ensuring AI providers track and respond to emerging risks after deployment.

• Security standards for AI models raised to at least RAND SL3, setting a new industry baseline for protecting model integrity.

• New guidelines for handling confidential security information, ensuring AI providers balance transparency with cybersecurity best practices.

These changes represent a mix of progress, clarification, and ongoing uncertainty. While some additions provide clearer compliance pathways, others leave open-ended questions that could complicate enforcement.

The Code’s Most Debated Issues

With every iteration of the Code, opinions have only grown stronger. Some see progress, others see added complexity, and some believe we are still missing the mark entirely. While there is general agreement that AI governance is necessary, the real battle is over how much regulation is too much, and whether these obligations are realistic in practice.

Transparency vs. Protection of Trade Secrets

The Code takes steps toward balancing both interests, but practical challenges remain. If companies are required to disclose too much, it could discourage innovation or push AI development into jurisdictions with weaker transparency obligations. A recurring debate is how the Code balances transparency obligations with the protection of proprietary information. While transparency is essential for accountability, excessive disclosure could force companies to reveal sensitive data, undermining their competitive advantage.

Taylor Wessing’s legal analysts have acknowledged that the new structured transparency obligations (e.g., public contact details and compliance documentation) enhance accountability. However, they stress that enforcement will determine whether this measure is effective or just another compliance burden. On the other hand, The Future Society supports the Model Documentation Form as a compliance enabler but warns that if confidentiality protections are not well-defined, companies may still hesitate to disclose key details.

Compliance Burdens and Feasibility for AI Providers

The Code introduces significant compliance obligations, particularly regarding documentation and ongoing risk assessments. While these requirements aim to ensure accountability, they also place a heavy administrative burden on AI providers. Notably, the 3rd draft expressly offers flexibility for SMEs—through explicit exemptions or simplified compliance approaches—recognizing that startups and mid-sized developers may have limited resources. However, many critical obligations, such as maintaining comprehensive documentation and conducting rigorous risk assessments, still apply.

A major concern is whether these obligations will disproportionately impact startups and mid-sized AI developers. CDT Europe has warned that excessive compliance costs could stifle innovation, making it harder for smaller players to compete. Legal experts agree that while structured obligations help prevent legal gray areas, the requirements must remain practical to avoid discouraging responsible AI development.

Copyright Protection and AI Model Training

The Code strengthens obligations around copyright compliance, but rightsholders continue to push for stricter controls, fearing unauthorized use of their works in AI training datasets. On the other side, AI developers argue that compliance expectations remain unclear, particularly regarding how models should prevent memorization of copyrighted material.

Copyright advocacy groups support stricter adherence to machine-readable rights reservations but question whether AI providers will fully comply without strong enforcement. The legal landscape remains complex, with some calling for more guidance on balancing copyright protection with AI innovation.

The Future of Compliance: Meaningful Accountability or Just Guidelines?

Since the Code is voluntary, questions arise about how much real impact it will have if enforcement mechanisms remain weak. Without binding legal obligations, compliance may be inconsistent across the industry.

Governance groups like The Future Society argue that voluntary compliance is a necessary step before legal enforcement frameworks can be developed. However, some industry leaders express skepticism, noting that voluntary codes alone may not be enough to ensure AI accountability, especially for high-risk applications.

The Road Ahead: Unresolved Questions and Next Steps

While the 3rd Draft of the Code clarifies many issues, it also raises new questions. How strictly will transparency be enforced? Will compliance obligations create an uneven playing field? And will companies follow voluntary rules without legal consequences?

Time to Act: Preparing for a New Regulatory Landscape

Businesses should take action today rather than waiting for the final version of the Code. They need to assess their current compliance frameworks to determine whether their documentation and risk management practices align with evolving expectations. Internal policies should be established or updated to track model performance, risk assessments, and data sourcing methods. Businesses should also engage with legal and technical experts to interpret the nuances of the Code and consider joining industry groups that share best practices. Investing in training and automating compliance procedures will help reduce the administrative burden.

Looking Ahead: Balancing Regulation with Innovation

The GPAISR Code represents a bold step toward regulating one of the fastest evolving sectors of technology. While significant progress has been made in clarifying obligations around transparency, copyright, and safety, practical challenges remain, particularly for smaller players. As the regulatory framework continues to evolve, businesses that begin preparing now will be better positioned to navigate compliance challenges and seize competitive advantages. Ultimately, responsible AI development hinges on finding the right balance between rigorous oversight and innovation-friendly practices. The conversation is just beginning, and the industry’s future will be shaped by proactive adaptation and open dialogue among all stakeholders.