Most procurement processes still treat an AI agent as another software subscription. The supplier provides access, the organisation pays a recurring fee, IT checks security documentation, legal reviews data-processing terms, and the business team starts using the product.
That model is too shallow.
An AI agent is not simply an application with a stable feature set. It is an operating dependency assembled from models, prompts, retrieval sources, connectors, orchestration logic, hosted infrastructure, external tools and sub-processors. Each layer can change the behaviour, cost profile, security posture and reliability of the service your teams rely on.
For a DACH mid-market organisation, the practical question is not whether an AI supplier has an attractive interface. It is whether the contract gives the organisation enough control when that supplier changes the system, suffers an incident, alters pricing, removes a capability or becomes impossible to use.
The procurement team is not buying a licence alone. It is appointing a supplier to participate in an operational process.
The SaaS contract assumption breaks down with AI agents
A conventional SaaS tool normally changes at a visible product level. A new module appears, an integration is deprecated, or a service-level commitment is amended at renewal. Those changes still matter, but the core process often remains understandable: users enter data, the software applies known logic, and the organisation receives a predictable output.
AI agents introduce a different kind of variability. A supplier may replace the underlying model, alter the system instructions, adjust retrieval settings, introduce a new tool call, modify filtering behaviour or route workloads to a different provider. The user experience can look unchanged while the behaviour underneath has materially shifted.
That matters when the agent supports sales qualification, customer service, document review, knowledge access, internal support or operational decisions. A small change in how the agent interprets a request can affect response quality. A new connector can widen the data the agent can access. A modified model-routing rule can affect latency, cost and the geographic or contractual path through which information is processed.
The procurement mistake is to contract for access rather than behaviour. A generic AI addendum, especially one copied from a conventional software agreement, rarely resolves the questions that emerge after deployment. It may mention responsible use and security in broad terms, but say little about what happens when the supplier changes the system that makes the agent useful.
The right objective is not to freeze every component forever. That would be commercially unrealistic and technically counterproductive. The objective is to distinguish ordinary maintenance from changes that require notice, review or approval.
Define what counts as a material model change
Suppliers need room to maintain and improve their services. Organisations need protection against unannounced changes that alter their risk position. Those interests can coexist if the contract defines change categories with enough precision.
A useful notification clause is based on operational impact, not brand names. It should cover changes to the model provider or model family where those changes can alter output characteristics, data handling, security controls, availability, pricing logic or the agent’s ability to use tools and connected systems. It should also cover meaningful changes to system prompts, retrieval configurations, autonomy boundaries and sub-processors.
The point is not to demand a notification every time a supplier optimises an internal parameter. That creates noise and encourages everyone to ignore the notices. Instead, procurement should ask for a threshold: changes that reasonably affect the agreed use case, the data categories involved, the control environment, expected service performance or the organisation’s documented risk assessment.
This shifts the conversation from “Can the supplier update its AI?” to “Which updates change the service we have assessed and approved?”
For business-critical workflows, notice alone may be insufficient. The organisation may need a period to test the revised behaviour in a controlled environment before production use. That is particularly important where an agent drafts externally visible communications, retrieves confidential information, initiates actions in other systems or supports regulated internal processes.
A supplier that cannot explain how it manages model changes is signalling a deeper problem. It may have no reliable internal record of which version was active, which configurations changed or which customer environments were affected. That makes incident investigation and governance far harder than it needs to be.
Incident clauses need evidence, not reassurance
When an AI-enabled process fails, the first challenge is usually reconstruction. What did the user ask? Which version of the workflow processed the request? Which knowledge source was retrieved? Which tools were called? Was an external model involved? What output was generated, and what action followed?
A contract that merely requires the supplier to “notify the customer of incidents” is not enough. Notification tells you that something happened. It does not give your organisation the evidence required to assess impact, inform stakeholders, correct the process or decide whether to continue using the service.
Incident evidence should be a contractual deliverable. The agreement should establish what information the supplier can provide after a relevant event, subject to legitimate protections for other customers and its own intellectual property. In practice, this may include relevant event records, configuration history, system status information, access information, a description of affected components and the supplier’s remediation record.
This is not an argument for demanding unrestricted access to a supplier’s production environment. Most mid-market buyers neither need nor can operationally use that access. The aim is narrower: the ability to understand whether the agent’s behaviour, data access or service continuity was affected, and to retain evidence suitable for the organisation’s own internal review.
The same principle applies to security incidents and quality failures. An agent can create a material operational problem without a conventional security breach. It may produce systematically misleading responses after a model update, expose outdated knowledge due to a retrieval failure, or trigger inappropriate actions through a connected system. Supplier-management processes must recognise these as incidents worth investigating, not merely product imperfections.
Portability is more than exporting documents
Many organisations assume they can leave an AI supplier by downloading their documents. That is only part of the exit problem.
The value of an agent often sits in the operational design around it: prompts, workflow logic, approval steps, knowledge-source mappings, evaluation cases, tool configurations, policies, conversation templates and the rules that determine when a human takes over. If these elements cannot be exported in a usable form, changing supplier means rebuilding the process under pressure.
An AI exit strategy should protect the assets that make the workflow work. Procurement should identify which artefacts belong to the organisation and which must be returned or made available at termination. The answer should not be limited to uploaded files. It should include the configuration and workflow state necessary to recreate the service elsewhere, as far as technically feasible.
There is an important distinction here. A supplier is not obliged to hand over its proprietary platform or model weights. But the customer should not be trapped because it cannot obtain its own prompts, its own evaluation data, its own process configurations or a usable record of how its workflow was assembled.
This is where vendor due diligence needs to become practical. Ask the supplier to demonstrate the export process before contract signature, not simply confirm that portability exists. Can the organisation retrieve its knowledge-base content with metadata? Can it export prompts and orchestration rules? Are conversation records available where required and appropriate? Can tool permissions and workflow configurations be documented clearly enough for a replacement team to rebuild them?
A vague promise of “data export on request” is not an exit plan.
Service continuity must include the transition period
Exit rights are only credible if the organisation can continue operating while it migrates. A supplier may terminate a service, change a commercial model, withdraw a feature or become unsuitable after a material incident. In each case, the organisation needs an orderly transition rather than an abrupt loss of capability.
For a DACH mid-market business, this does not necessarily mean duplicating every AI system or maintaining an expensive standby platform. It means identifying the workflows where interruption would damage customer service, revenue operations, internal productivity or compliance. Those workflows deserve a transition arrangement proportionate to their importance.
The contract should clarify what support is available during a planned exit, how long the organisation can access its data and configurations, and what happens to integrations and connected systems. It should also address secure deletion after the agreed transition, while allowing the organisation to retain the records it legitimately needs.
The most credible exit path is one that has been tested. A short exercise during onboarding can reveal whether exports are complete, whether the organisation has documented its prompts and workflows, and whether another platform could realistically take over. This is not pessimism. It is basic supplier discipline.
Procurement needs a seat in AI operating governance
AI supplier management cannot sit entirely with procurement, legal or IT. Each sees part of the risk. Procurement manages commercial leverage and contract structure. Legal assesses obligations and data terms. IT evaluates integration, identity, security and operational resilience. Business owners understand the consequences when outputs change. The people responsible for AI governance must connect those perspectives.
That is why contracts should reflect the actual operating model. If business teams can create agents independently, the organisation needs clear rules for who may approve suppliers, connectors and higher-risk use cases. If a central platform team operates shared AI services, it needs visibility into model changes, incident evidence and exit dependencies across the portfolio.
The organisation should also avoid the opposite mistake: trying to negotiate enterprise-grade control language for a low-risk experiment that has no sensitive data, no external action and no production dependency. Governance should be proportionate. But once an AI agent enters a meaningful business process, supplier terms must catch up with reality.
The strongest AI procurement contract is not the longest one. It is the one that makes responsibilities visible before a problem arises: what may change, what evidence is available, what the customer can take with it, and how the organisation remains operational if it must leave.
A Diagnostic maps your AI supplier dependencies, contract gaps and practical exit requirements before a changing vendor becomes an operational lock-in.
Context note: This article provides practical procurement and operating guidance and does not constitute legal advice.