AI contracting systems: who should EU SMEs choose?

An SME does not need an AI to negotiate every contract. It needs to know which clause changed, which rule allowed it, who approved the fallback and whether an unintended action can be reversed. That is the buying test behind the European Commission’s new work on AI contracting.

The Commission says its Expert Group on AI Contracting starts work in July 2026. The evidence base explains why the subject has reached Brussels now: a May study estimates that only 0.7-1.5% of EU enterprises — roughly 235,000 to 475,000 firms — currently use AI solutions for contracting, while more than one-third of firms responding to an Enterprise Europe Network survey plan to adopt them.

The gap between those numbers is not mainly a shortage of contract chatbots. It is the work of fitting approved terms, data boundaries, escalation rules and evidence into the way a company already buys and sells.

The model terms are not here yet

The Commission’s current page is a work programme, not a finished safe harbour. The expert group will help develop horizontal model contract terms for AI contracting and guidance for choosing systems from the user’s perspective. Those outputs may give SMEs a better baseline for allocation of risk, but they do not select a product, map a workflow or approve a clause today.

The underlying study covers more than document summarisation. It defines AI-enabled contracting as tools supporting negotiation, drafting, review and execution. It also considers systems that can conclude or perform contracts with less human intervention.

That wider scope creates practical questions before a demo begins:

• Who defines the clauses and fallback positions the system may use?
• Which actions are suggestions, which are approvals and which can execute?
• What happens when the system takes an unexpected action?
• Can a reviewer trace an output to the contract, playbook and approval record?
• Where do confidential documents and extracted data go?
• Can the company export its contracts, rules and evidence?

The Commission study is blunt about implementation. AI contracting tools usually require substantial customisation, are not plug-and-play and still need human judgment for subjective terms and unstructured data. A product list is therefore the second decision. The first is the operating model.

Compare the operating model

A bespoke implementation, Juro, Ironclad and Icertis solve different versions of the same problem. Provider pages support the product descriptions below; they do not replace security review, a product demonstration or a written proposal.

• Bespoke implementation — one bounded workflow. An SME has one valuable flow to map, connect to existing tools and keep under human approval. Demand an approved playbook, source-linked outputs, named approval gates, test cases, activity log, export rights and handover. Compare at least two implementers against the same acceptance test.
• Juro — shared contracts workspace. A growing legal or commercial team wants repeatable review, redlining, approval, signing and repository queries in one product. Demand playbook coverage, redline accuracy, permissions, version history, export and integration tests.
• Ironclad — cross-functional lifecycle. Several departments need governed workflows across legal, sales, procurement and IT. Demand a role matrix, workflow ownership, tested business-system integrations, audit exports and portfolio reporting.
• Icertis — enterprise contract intelligence. A larger organisation needs high-volume portfolio and obligation management across enterprise systems. Demand a measured data migration, obligation extraction checks, approval controls, integration reconciliation and portfolio-level auditability.

Source: European Commission AI contracting page and final study; provider materials from Juro, Ironclad and Icertis. Last verified 2026-08-31.

Bespoke implementation: prove one workflow first

A bespoke route is relevant when the bottleneck sits between existing systems and does not yet justify moving contract work into a full lifecycle platform. That is an operating-model choice, not a recommendation for a particular supplier.

Require each candidate implementer to show how documents enter the workflow, how extracted clauses link back to source text, where approved fallback rules live, which steps require a named human, how logs and data can be exported, and who maintains the system after handover. Score every proposal against those same requirements.

A narrow pilot could take one recurring supplier agreement. The business and its counsel approve ten required clauses, five fallback positions and three mandatory escalation triggers. The workflow ingests the document, extracts the relevant text, links every finding to its source, proposes the allowed next step and stops at the named owner. The acceptance test is not whether the summary sounds fluent. It is whether all eighteen rules produce the expected evidence and approval path on a fixed sample.

This route can be the smaller first test when the company has a specific operational bottleneck and wants the implementation to fit its existing process. It is a poor fit when the business already needs a shared repository, standard redlining, signing, portfolio reporting and governed workflows across several departments; those requirements point towards a CLM product.

Juro: put routine contracts in one workspace

Juro presents a browser-based contracts platform with AI throughout the lifecycle. Its Operator page describes conversational queries across contract data, AI review and redlining, approvals, signing, extraction and workflow triggers. That makes it a credible route when the business wants a shared system of record as well as review assistance.

The useful pilot is one repeatable contract class such as an NDA, supplier agreement or standard sales agreement. Load the approved template and playbook, route it through the actual commercial and legal owners, then test a third-party version containing deliberate deviations. Measure whether the team can find each change, explain the proposed fallback, preserve the version trail and export the final record.

Juro is a product decision rather than a custom build. It fits when the desired process is already recognisable as contract lifecycle management and the team is ready to move drafting, review, approval and repository work into the same operating environment.

Ironclad: govern contracts across departments

Ironclad describes an enterprise-grade AI contract lifecycle platform spanning creation, review, approval, execution, fulfilment and analysis. Its public material positions the system across legal operations, general counsel, procurement, IT and sales, with integrations into existing business tools.

That breadth matters when contracts do not belong to one team. A sales agreement may start in a CRM, need finance approval for a commercial deviation, require security review, then create obligations for operations after signature. The procurement test should therefore follow one agreement across every owner and system, not stop after an AI redline.

Demand a role and permission matrix, the exact approval conditions, an export of the audit trail, and proof that data written back to the CRM or procurement system reconciles with the signed agreement. Ironclad becomes the relevant comparison when cross-functional governance is the purchase, not only faster document review.

Icertis: manage obligations at portfolio scale

Icertis describes its platform as contract intelligence for enterprise operations. Its product suite covers contract creation, automation, repository search, AI applications, obligation and performance insight, agentic workflows and native integrations with Microsoft, SAP, Salesforce and Workday.

That route is credible when the buyer needs to structure a large contract estate and connect terms to downstream activity. The test is not a single draft. It is whether the system can ingest representative legacy contracts, identify clauses and obligations consistently, assign owners, surface exceptions and keep records aligned with enterprise systems.

Use a stratified sample: active supplier agreements, customer agreements, amendments and one contract with a non-standard obligation. Have the legal and operational owners create the answer key before import. Compare extraction, relationships, reminders and system updates against that answer key. Icertis earns its place when portfolio intelligence and enterprise integration are already defined requirements.

Run one reversible procurement test

The Commission study identifies legal uncertainty, integration effort, unreliable outcomes and information gaps as barriers. A small acceptance test can expose all four without trying to automate the entire contract lifecycle.

1. Select one contract class and 20 representative documents, including amendments and known deviations.
2. Write the answer key first: required clauses, fallback positions, approval owners, prohibited actions and evidence fields.
3. Separate suggestion, approval and execution. No tool should cross those boundaries silently.
4. Test source links, version history, permissions, data export and reversal of a deliberately incorrect action.
5. Record every manual correction and decide whether the remaining volume justifies a custom workflow, shared CLM workspace or enterprise platform.

The number 20 is a procurement sample, not a statistical claim. Its purpose is to reveal missing document types and brittle rules while a change is still cheap to reverse.

Counsel should own legal interpretation and material fallback positions. The system should make the approved policy repeatable, visible and testable. If it cannot show why a clause moved or who authorised the next step, faster contracting has merely made the uncertainty faster.

Prepare for the Commission’s terms

Future horizontal model terms may give SMEs a useful starting point for issues such as system parameters, unexpected actions, disclosure and allocation of responsibility. The Commission study examines those themes and also notes that non-binding model terms or voluntary standards can support legal certainty while the technology matures.

An SME can prepare now without predicting the final text. Keep an inventory of contract flows, the approved clause playbook, system and data boundaries, human approval points, reversal procedure and an exportable decision log. Those artefacts can absorb future model language far more easily than a collection of prompts and vendor demos.

Start with the contract flow that causes the most repeated waiting, not the platform with the longest feature list. Run the 20-document test, keep every approval human and named, and buy the smallest operating model that passes.