Adding AI contract review without replacing your existing system

Integrations rarely stall on technical grounds. In the projects we have run, wiring up the open API has mostly taken a week or two. What costs time is leaving these three questions open until joint testing, when both sides discover they assumed different answers and the fix is a process change rather than a code change.

Where review is triggered

The two common positions are the moment a file is uploaded and the moment it is submitted for approval. Triggering on upload covers more ground, at the cost of reviewing a large number of drafts that are never used, which drives up both call volume and noise. Triggering at submission saves calls but surfaces risk at the end of the process, when changing anything is already expensive. A practical compromise is to trigger at submission and add an upload-time pass for contracts above a value or type threshold.

It is also worth deciding whether inbound third-party papers and your own templated drafts run the same ruleset. Inbound papers concentrate risk in payment, breach and jurisdiction clauses drafted by the other side. Templated drafts are mostly about field completeness and whether the right template version was used. One ruleset covering both usually ends up too lenient on inbound papers and too noisy on your own.

Across revision rounds, re-reviewing every version multiplies cost while most rounds only move a figure or a delivery date. Re-reviewing only versions with substantive changes is the better trade: run version comparison first to classify the change, then decide whether a fresh review is warranted.

Where the result lands

Writing results into fields on the contract record, versus attaching them as a file, is the choice that determines how useful this is a year later. Fields make risk levels and flagged clauses reportable and searchable. Attachments are the smaller change, but when someone asks how many contracts had their payment terms flagged last year, the only way to answer is to open files by hand.

Whether the risk list belongs in the approver's comment panel depends on who approves. If the chain includes non-legal roles, pushing a graded list in front of them tends to produce a rubber stamp rather than a judgement. Putting legal's confirmed conclusion in the approval panel, and leaving the raw list in legal's own view, holds up better.

Extracted structured fields are the part most often dropped. If parties, amounts, terms and payment milestones do not flow back into the existing register, renewal alerts, payment schedules and reporting still depend on someone keying the data in again, and the time saved on review is given straight back.

Who signs off

Adding AI introduces a class of decision that did not exist before: accept or reject a given machine-generated comment. If that action has no named owner and leaves no record, audits become harder than they were before integration, because a new grey area appears in which the system flagged something and nobody acted. This is the question most often skipped at kickoff and the one most likely to cause trouble six months after go-live.

Concretely, settle whether legal works through every item or the business team triages first, which assessment prevails when the machine and the reviewer disagree, and where the record of who accepted what and when is kept. Those answers belong in the process documentation rather than in each reviewer's habits.

The open API, iframe embedding and webhook event notifications are all currently available, and they are not mutually exclusive. Most projects combine them: an API call starts the review, a webhook signals completion, and an iframe gives reviewers the detail. Using the API alone, with no visible surface for the reviewer to work through, tends to end with legal comparing exported documents by hand, which gives back much of the benefit.

7

Zico AI surfaces callable over the API: review, quick review, version comparison, translation, extraction, summary, meeting minutesSource: capability list on the Zico AI page, all seven marked available

2

Collaboration entry points running in customer production: Lark and internal OA; others connected on requestSource: Zico customers page

What to pin down about the iframe before you commit

Identity comes first. The usual approach is to exchange your own user reference for a short-lived session, so neither side maintains a second account directory. If you already run a single sign-on, connecting to it is less work, but check that permission granularity survives the trip: if a salesperson may only see contracts they raised, that restriction has to hold inside the embed too.

Next, decide whether actions inside the iframe are returned. If a reviewer accepts several items and that does not sync back, the audit trail breaks between the two systems. On styling, white-label normally covers colour and marks rather than arbitrary redesign, so look at the interface before promising anything to the business. Finally, agree which functions stay closed in embedded mode, or reviewers will bounce between two entry points and end up worse off than before.

Take the common case: the business receives an inbound third-party paper and starts an approval in the existing system.

1. 1The business uploads the inbound paper in the existing system and starts contract approval.
2. 2At the submission step, that system calls the open API with the document and your ruleset reference.
3. 3Zico AI scans parties, payment, breach, jurisdiction and IP clauses from your side's position and returns a graded risk list, each item anchored to its location in the source text.
4. 4A webhook notifies your system on completion, and your system collects the result.
5. 5The risk list is written back to the contract record, or shown item by item through the white-label iframe in your own page.
6. 6Legal accepts, rejects or edits each item, and the action is recorded in your system's audit trail.
7. 7When the response goes out, the comment set is exported, optionally with verbatim redlines stripped.
8. 8Extracted parties, amounts, terms and payment milestones flow back to your existing register over the API.

The items below are either marked as not yet released on the product pages or fall outside what an AI integration addresses at all. Writing them into acceptance criteria is a reliable way to get stuck at sign-off.

• Automatic revision hand-back: producing a marked-up or tracked-changes file once a human accepts a change, for downstream systems to collect, is marked as coming soon, so for now someone still applies the conclusions to the document.
• Private LLM deployment: needed when inference must also stay inside the corporate network; currently marked as rolling out, with status per the Zico AI page, and worth confirming in writing before purchase.
• Running approvals for you: routing, permissions and the register stay in your system, and adding AI does not touch that layer, so slow approvals will stay slow.
• Blanket accuracy claims: without a test set and an evaluation method no overall accuracy figure is given, and acceptance should rest on checkable specifics instead, which the next section sets out.

One further boundary is easy to misread. Negotiation recordings can be attached for cross-reference, and a summary will read the transcript alongside the document and flag where the two disagree. The conclusion still rests on the contract text. The recording is there to remind both sides what was discussed, not to override or supplement what the signed document says.

The common failure in integration projects is that every metric reads as met while the team quietly reverts: nobody opens the risk list, and legal still reads the document from the top in Word. That failure is invisible at sign-off, because acceptance criteria usually sit on the AI rather than on the process around it.

The sample set does not need to be large. Twenty or thirty documents is enough to see a trend, but they must be your own contracts in redacted form, and the set should include at least one document that caused a problem in the past. That one tests whether the system finds a risk you already know about, which carries more weight than any headline accuracy figure. Results from a vendor-supplied sample contract are not a basis for acceptance, because such samples tend to be built backwards from the capability list.