Buying and selling IT services in the age of AI: the new brief

An IT engagement can now produce more with less visible human work. Even so, the buyer can't simply demand a discount "because there's AI involved", and the provider can no longer treat its automation as a black box. The contract needs to shift its centre of gravity: less about controlling the resources deployed, more about defining the expected proof, the evaluations, decision rights, technology costs, accountability, and exit terms.

The question becomes especially concrete for IT services firms. According to the Numeum-Xerfi Observatory published in July 2026, 49% of the firms surveyed cite pricing pressure among their top headwinds, and 58% say they're repositioning through automation and AI. At the same time, the study estimates AI-linked productivity gains at 15% in 2025 and 22.3% in 2027 at IT services firms, but Numeum stresses they remain hard to convert into margin.

That's the new contractual problem: who benefits from the productivity gain, who bears the new costs, and who's on the hook when the automation gets it wrong?

In brief

The real question isn't how much AI the provider uses

The temptation is understandable.

A buyer discovers an IT services firm uses agents to generate code, write tests, produce documentation, or prepare analysis. They conclude the engagement should cost less. The provider, for its part, worries every productivity gain will be immediately turned into a commercial discount.

This tension already exists on the consulting side: an excessive focus on the day rate can push buyers and providers into a sterile negotiation, while value shifts toward proof, governance, assets, and the capability actually transferred to the client. The new spec sheet benefits from building in fast proof, AI governance, the human's role, and deliverables usable beyond the engagement.

Transposing this to IT services firms, though, needs care. An IT engagement doesn't just produce a recommendation: it can change a production system, handle data, introduce a vulnerability, or trigger an incident. So testing, observability, operational accountability, model costs and reversibility all need to be added to the economic criteria.

The right contract shouldn't ban automation, nor accept it as a black box. It should make the consequences of that automation explicit.

This shift profoundly changes the spec sheet.

Start with a baseline, not a productivity promise

"We'll be 30% faster thanks to AI" is a poor contractual starting point.

First, because there's no universal AI productivity rate that applies to every engagement. Results differ by task type, codebase quality, test maturity, the context given to the agents, team experience, and how long verification takes. Numeum's sector figures are aggregate estimates and self-reported statements, not a guarantee that applies to any specific contract.

Second, because productivity isn't necessarily the value being sought. On an application-maintenance contract, the client may want fewer incidents. On a migration, a shorter timeline. On a critical application, better reliability first. On a service centre, absorbing more volume without higher costs.

The first appendix of an AI-augmented contract should therefore document the starting state: full cost, volumes, lead times, defect rate, rework, availability, incidents, human workload, and debt wherever it can be measured.

It's this baseline that will later let you say whether the engagement genuinely improved.

As human effort becomes less observable, the baseline becomes more important than staffing for objectively assessing value.

Demand a fast proof point before negotiating the big promise

The second shift is cutting the time between the sales promise and the first piece of proof.

Not necessarily a spectacular POC. Useful proof can be far more modest: a workflow run end-to-end on a real sample, around fifty tickets replayed, a batch of migrated code with its tests, an agent running in shadow mode, or an eval set run against historical cases.

Several signals point this way. At Qonto, LLM evals are built into CI to test AI products whenever code changes. At Alan, opening up contribution to non-engineers still comes with a final merge decision on the engineering side. At Roundtable, automation lets only a small fraction of problem cases surface to a human on a regulated flow. These three cases show different forms of the same logic:

automating doesn't remove the need for a proof criterion and a control point.

They don't, however, prove a single model applies everywhere: these cases still come from a panel of thirty companies selected for their organisational signals, not a representative one.

A fast proof point, then, should be used to test the contract's assumptions, not to manufacture an artificial sales win.

Ask for transparency on the automation, without demanding the whole kitchen be thrown open

Does a buyer need to know whether the code was written by a human or an agent?

In some cases, yes. In others, the relevant question is less who authored the code than the conditions under which it was produced, tested and validated.

Useful contractual transparency should, at minimum, make it possible to understand where AI is involved (analysis, code, testing, documentation, support, decisions, actions on the IT system), its level of autonomy (suggestion, production under review, execution after approval, limited autonomous execution), which third-party vendors are involved (models, clouds, agent platforms and structural components), what data they can access, what gets logged, and who validates the result.

That doesn't mean the client should automatically receive every prompt, every system instruction, or the entirety of the provider's proprietary know-how.

It's advisable to identify the relevant contractual structure and the terms imposed by third-party components and models, which can weigh on the system's usage rights.

Relevant transparency is about risk, accountability and dependencies. It shouldn't turn into a blanket obligation to reveal all of the provider's intellectual property.

Evals need to enter the contract

Traditional acceptance testing readily relies on a binary logic: a function either does what was planned or it doesn't.

A system using a generative model introduces an extra difficulty: two runs can produce different results, and certain defects only show up on particular categories of cases.

It's advisable to adapt the acceptance procedure: keep traceability of tests and their results, agree on acceptable performance levels, define tolerance thresholds, and document deviations along with corrective measures.

That's what evals are for: reproducible tests that measure a system's or an agent's behaviour across a relevant set of cases.

A contractual appendix could specify the reference corpus, the critical cases, the minimum thresholds, the tolerated error rate, human sampling arrangements, regression tests, and the procedure that applies when a model change degrades results.

This also changes the commercial relationship.

The seller no longer just says: "our agent works".

The buyer can ask: "what cases did you test it on, at what result level, and what happens when that level isn't met anymore?"

Spell out, in black and white, what the human still needs to decide

"Human-in-the-loop" has become an easy phrase. Contractually, it's worth almost nothing unless you specify exactly where the human actually sits.

Do they validate a sample? Every production deployment? Only low-confidence cases? Irreversible actions? Security operations? Can they stop the agent?

Several models exist for splitting work between humans and agents. The "human on exceptions" model, in particular, requires tracking the exception rate, the error rate and rework. The agentic-development model also keeps a human sign-off step after production and an initial automated review.

Cybersecurity calls for extra vigilance. ANSSI, the French cybersecurity agency, recommends that critical interactions between an AI system and the IT system be controllable by a human, and that AI assistance in developing sensitive components be subject to regular checks and tests. In 2026, CERT-FR tightened this message further for certain agentic tools on workstations: when a system command or an action with side effects is contemplated, it recommends mandatory human validation and isolated execution.

The contract, then, needs a genuine authority matrix: what the agent can propose, produce or execute; what the provider has to approve; what needs the client's authorisation; and who ultimately bears responsibility.

Treat model costs as an economic component of the service

Automation isn't free.

On top of human costs, depending on the architecture, there's now inference, subscriptions, context storage, orchestration platforms, observability, testing, and sometimes several models used in parallel.

This economics creates new negotiation questions.

Does the price include a usage allowance? Is an overage rebilled? At what rate? Can the provider switch models to cut its cost? Can the client mandate a more expensive model for sovereignty or quality reasons? What happens if a third-party vendor suddenly changes its prices or terms?

The right metric, in fact, isn't necessarily the token count. A buyer generally isn't buying tokens: they're buying a service.

The relevant tracking will probably shift toward a technology cost per outcome — per ticket resolved, change delivered, file processed, or compliant transaction — backed by guardrails on consumption.

This question matters all the more since Numeum observes, at the same time, productivity gains rising and their difficulty converting into margin at IT services firms.

Redraw accountability around a chain of vendors

An IT contract rarely had a single party to begin with. AI amplifies this.

An IT services firm can assemble a model from one vendor, a cloud platform, a vector database, an agent framework, client data, and its own assets.

Who, then, is accountable for a defect?

It's advisable to explicitly address this contractual architecture: a separate contract between client, integrator and model vendor, or overall accountability carried by one provider; accounting for third-party terms; and allocating responsibility for data, testing and operations.

This clarification has become even more important since 2 August 2026, when the European Commission, together with national authorities, began enforcing new AI Act provisions, including certain transparency obligations.

That doesn't mean every IT engagement using an LLM falls under the same obligations: each party's role, the nature of the system, and its risk level all remain decisive. The contractual framework should be precisely what lets you know who is what in the value chain.

France's data-protection authority, the CNIL, also points out that models and systems using personal data can fall under GDPR, and stresses the security and documentation of processing activities.

An AI contract, then, isn't just a performance contract. It's also a risk-allocation contract.

Intellectual property can no longer fit into a generic three-line clause

An AI-augmented project can contain assets the provider already owns, client-specific code, client data, prompts and configurations, eval sets, context data, generated outputs, a model or platform owned by a third party, and generic improvements discovered during the engagement.

It's advisable to clarify the rights that apply, notably, to training data, input data, generated outputs, and the customised system. Third-party components can also impose their own licensing restrictions.

Reaching for a simple principle — "everything belongs to the client" or "the whole platform stays with the provider" — is often insufficient, then.

A more robust structure at least distinguishes the provider's pre-existing assets, the elements developed specifically for the client, and the data or configurations that belong to the client.

The commercial stakes are major: if an IT services firm has to hand over every asset it industrialises on every engagement, it will struggle to move past the day-based model. But if it locks the client into an asset that can't be taken back, it turns its own edge into a purchasing risk.

Reversibility needs to be designed before day one, not at the moment of a breakup

Reversibility becomes harder when the service depends on a whole set of models, agents, corpora, evals, connectors and orchestration rules.

When the contract ends, several questions need answers: can the client keep using the system, hand it to a third party, retrieve its data, and get certain elements erased at the provider?

For an AI-augmented IT engagement, you need to go further and identify what's essential for an effective handover: architecture documentation, data and export formats, relevant configurations, tests and evals, a dependency inventory, operating procedures, component versions, and the conditions letting another provider take over the service.

Reversibility doesn't necessarily mean handing the client all of the provider's proprietary know-how. It means switching providers shouldn't cause the loss of the service or of the client's specific knowledge.

That's an essential difference.

The counter-example worth keeping in mind: more automated doesn't automatically mean better

One mistake would be to turn the automation rate into the main contractual KPI.

The Klarna case is instructive precisely because it resists this reading. The company heavily automated its support and cut its headcount before moving back toward a more hybrid model for certain service moments. Both efficiency gains and the CEO's later acknowledgment that the drive to cut costs had gone too far, at quality's expense, can be observed there.

This case doesn't prove a high automation rate necessarily degrades the service. It proves something else: the automation rate isn't, on its own, a client outcome.

For an IT engagement, the same caution applies.

An agent able to resolve 70% of tickets can be an excellent solution if quality stays high and exceptions are handled properly. It can also simply shift the load toward more complex incidents, rework, or an overloaded oversight team.

The spec sheet, then, needs to measure the whole system.

What the available data doesn't let us claim

We don't currently have a solid basis for decreeing that an engagement using AI should cost 15%, 20% or 30% less.

Nor can we conclude that the client must always know the exact percentage of work generated by AI, that every agentic system needs the same human validation, or that an outcome-based model is always preferable to a fixed price or staff augmentation.

The available data describes a transition.

Numeum observes both productivity gains and strong pricing pressure, together with difficulty converting those gains into margin. A panel of companies documents highly agentic organisations, but also companies like Lucca, where AI is integrated with no fundamental overhaul of the teams.

The reasonable conclusion, then, is less dramatic: AI isn't creating one new universal contract. It's making certain traditional contracts incomplete.

Buying differently also means selling differently

The new spec sheet shouldn't become a list of demands imposed by procurement on a defensive IT services firm.

The provider, too, has an interest in clarifying the rules of the game.

Rather than promise abstract productivity, it can offer a baseline and proof. Rather than hide its agents to protect its margin, it can explain their role and the controls around them. Rather than rebill technology costs indiscriminately, it can make the service's economics legible. Rather than hand over all its IP to win a bid, it can clearly separate what makes up its industrial asset from what needs to stay under the client's control.

The contract then becomes less an instrument of distrust than a design of the delivery system.

That's probably the most important change.

Contract checklist: twenty questions before signing

This grid is meant to frame the discussion for buyers, sales, delivery, CIOs, CISOs and legal teams. It doesn't replace the contract's own legal analysis.

• •Do we have a quantified baseline of cost, lead times, quality and volume before the transformation?
• •Is the expected outcome framed as something other than a number of days or FTEs?
• •Is a fast proof point planned before full industrialisation or commitment?
• •Is the scope where AI or agents operate explicitly documented?
• •Are the model vendors and structural third-party components identified?
• •Are the rules that apply if the model or vendor changes spelled out?
• •Are the data accessible to the models, its location, its retention and any potential reuse defined?
• •Are the evals, edge cases and test sets defined before acceptance testing?
• •Are performance and tolerance thresholds written into the contract?
• •Is there a regression-testing mechanism for when the model, prompt or architecture changes?
• •Are the decisions the agent can make alone distinguished from those requiring human validation?
• •Do critical actions have appropriate approval, logging, and a stop or rollback mechanism?
• •Are the respective responsibilities of the client, the IT services firm and third-party vendors explicit?
• •Are model, compute, licensing and overage costs built into an understandable economic rule?
• •Does the contract cover what happens if a third-party vendor sharply raises its prices or changes its terms?
• •Are the provider's pre-existing assets, the client-specific work, the client data, the inputs and the outputs distinguished for IP purposes?
• •Does the client hold the rights it will actually need to operate the solution after the engagement?
• •Does reversibility cover data, documentation, dependencies, tests, evals, and the terms for a third party to take over?
• •Do the metrics track quality, errors, exceptions and rework, not just automated volume or speed?
• •Do buyer and provider know how productivity gains will be shared if the engagement becomes significantly more efficient?

The conviction

In the age of AI, the buyer shouldn't be trying to find out how many human days it can cut. And the IT services firm shouldn't be trying to artificially hold on to the same number of days while using automation behind the scenes.

The contract needs to organise an explicit sharing of productivity, risk and accountability.

The most mature engagement, then, isn't the one that automates the most. It's the one where both parties can clearly answer seven questions: where are we starting from? What needs to be proven? How will the result be evaluated? What does the AI actually do? Where does the human keep authority? Who pays for and owns the technology dependencies? How can the client take back control?

The spec sheet becomes, in a sense, the first act of the hybrid human-plus-agent organisation.