How to Use ChatGPT to Review an IT Services Contract or SOW Before You Sign

The short answer: Upload the agreement and run a fixed question set over it instead of asking for a summary — what is in scope, what is explicitly excluded, how "response time" is defined, what a service credit actually pays, how the term ends, and who owns your configuration data on exit. Twenty minutes surfaces the gaps. It will not tell you whether the deal is worth signing.

An IT services agreement is not a document most SME buyers read carefully, and that is a rational decision made for bad reasons. It is fourteen pages of dense, generic-looking text, the salesperson has been helpful, the price is agreed, and the parts that look negotiable — rate, term, headcount — were negotiated weeks ago in email. What remains reads like boilerplate.

It is not boilerplate. The paragraphs that decide what happens when something goes wrong are the ones nobody reads, and they are written by the vendor's counsel, for the vendor. That is not a scandal; it is how contracts work. The asymmetry is simply that one side has read this document a hundred times and the other side is reading it once.

A language model closes some of that gap cheaply. It will not tell you whether an agreement is fair, and it is not a lawyer. What it does well is read fourteen pages against a checklist without getting bored on page nine — which is exactly the failure mode of a busy buyer reviewing a contract at 6pm.

The Clauses That Cost Money Later, and Why They Read as Boilerplate

The expensive clauses are rarely aggressive. They are usually just precise in a way the reader is not paying attention to.

"Response time" is almost never fix time. A four-hour response SLA typically means someone acknowledges the ticket within four hours. Whether the problem is resolved that day, that week, or at all is often unaddressed. This single definitional gap is the most common source of the "we have an SLA and it still took three days" conversation.

Exclusions do more work than the scope list. The scope section is what the salesperson showed you. The exclusion list — third-party software faults, anything involving a vendor's own support queue, cabling, "issues arising from customer-supplied equipment" — is what determines your actual bill. Anything excluded lands on a rate card, at a rate you probably never compared to anyone else's.

Service credits are usually smaller than the incident. A common structure caps credits at a percentage of one month's fee. If a day of downtime costs you materially more than that, the credit is not a remedy — it is a gesture. Worth knowing before, not after.

Auto-renewal plus a long notice window is a real cost. Twelve-month term, automatic renewal, ninety days' written notice to terminate: miss that window by a week and you have bought another year. Diarise the notice date when you sign.

Offboarding is a service, and services are charged. Who exports the documentation, hands over admin credentials, transfers the RMM tenancy, and provides the asset register — and at whose cost? If the agreement is silent, the answer at the point of a bad breakup is "at our standard rate, when we get to it."

Running a Structured Review Instead of "Summarise This Contract"

Asking for a summary produces a summary — a fluent, accurate, useless restatement of what the document says about itself. The value is in the interrogation, and it comes from two habits: ask fixed questions, and ask about what is absent.

The question set worth running every time

Give the model the document and a defined role: you are reviewing this on behalf of the customer, and your job is to find where the customer's expectations and the written terms diverge. Then work through the axes one at a time rather than all at once.

Scope and exclusions. Ask it to list every service explicitly included, every service explicitly excluded, and — the useful one — everything a reasonable buyer of managed IT might assume is included but which the document never mentions either way. Silence is where disputes live.

SLA mechanics. Ask it to quote the exact definition of response time, resolution time, severity levels, business hours, and what happens outside them. Ask what evidence determines whether an SLA was met, and who measures it. "The service provider's ticketing system" is a defensible answer, but you should know that is the answer.

Money. Ask for every circumstance in which you can be charged something that is not the monthly fee — out-of-scope work, minimum call-out, travel, after-hours multipliers, project work, annual uplift, currency clauses.

Term and exit. Ask for the term, renewal mechanism, notice period, termination-for-convenience rights on each side, and exactly what the provider must deliver on exit.

Data and access. Ask who owns the documentation, the asset register, the monitoring configuration, and the backups; what happens to your data when the contract ends; and what administrative access the provider holds over your tenancy.

Two techniques make the difference between a novelty and a working review. Ask it to quote, not characterise — every finding should come with the clause text, because a model paraphrasing a contract can drift, and a quote can be checked in seconds. And ask for the obligations you are taking on, not the vendor's. Buyers read the vendor's promises; the customer-obligations clause is where "customer shall maintain current manufacturer support on all in-scope hardware" quietly sits, next to a clause voiding the SLA if you do not.

Comparing two vendors on the same axes

This is where the method pays for itself. Two managed-services proposals are almost never comparable as written, because they use the same words for different things and structure their pricing differently on purpose.

Run the identical question set over each document separately, then ask for a side-by-side on the axes you extracted. Insist on flagging where the two agreements define the same term differently — one vendor's "P1" may require total service loss, the other's may include a single executive's laptop. That difference is worth more than a few dollars per seat, and it is invisible until someone lines up the definitions.

A Worked Example — Three Findings in a Standard Managed-Services Agreement

A 120-person manufacturer with a Hong Kong office and a Shenzhen plant is signing a regional managed-services agreement. The document is fifteen pages plus two annexes, and it is a normal, not-unreasonable contract from a competent provider.

Finding one: the response SLA is an acknowledgement SLA. Annex A defines P1 response as one hour and never defines resolution at all. Not unusual, and not necessarily a problem — but the buyer had been telling their board that critical issues would be "fixed within an hour." The fix is one line: a target resolution time for P1, or an explicit statement that resolution is best-effort. Either is fine. Believing the wrong one is not.

Finding two: onboarding is in scope, migration is not. The scope list includes "onboarding and transition." The exclusions annex excludes "data migration and any work arising from the previous provider's configuration." Those two clauses describe the same eight weeks of work, and the customer's mental model of what they had bought was formed entirely by the first one.

Finding three: the notice window is longer than the renewal reminder. Auto-renewal, ninety days' notice. The buyer's procurement calendar had a reminder set at sixty days out for annual vendor reviews. Missing the window was already scheduled.

None of the three is evidence of a bad vendor. All three are questions worth asking before signature rather than during an incident, and all three came out of a twenty-minute pass with a checklist. What the model did not do was tell them the price was reasonable, which vendor to choose, or whether the governing-law clause was enforceable across two jurisdictions. Those are different questions, with different answers.

AI-Assisted Contract Review vs a Commercial Lawyer vs Signing the Template

• Cost and turnaround — AI-assisted review wins decisively. A twenty-minute pass at effectively no marginal cost, available at the moment you actually have the document in front of you.
• Finding definitional gaps and internal inconsistencies — AI-assisted review wins. Comparing an SLA annex against the exclusions annex against the main body is mechanical work, and models are good at mechanical reading.
• Enforceability, jurisdiction, and liability caps — A commercial lawyer wins, and it is not close. Whether a limitation-of-liability clause survives in Hong Kong, Singapore or Mainland China is a legal question about a specific jurisdiction, not a reading-comprehension question.
• Negotiating leverage and market norms — A lawyer or an experienced IT advisor wins. Knowing which clauses providers routinely concede is knowledge from having negotiated many of these, and it is not in the document.
• Accountability if the advice is wrong — A lawyer wins absolutely. Professional advice comes with professional liability. A chat transcript comes with nothing.
• Signing the template unread — Wins on speed alone, and it is what most SMEs do. It is also why so many of these conversations happen after an incident rather than before one.

For most SME buyers the realistic sequence is not choosing between these. It is using the model to generate a short list of specific questions, resolving most of them with the vendor directly, and taking only what remains to a lawyer — a far cheaper instruction than "please review this contract."

This Is Not Legal Advice, and the Distinction Is Not a Disclaimer

It is worth being precise about what the difference actually is, because "not legal advice" is usually read as a formality.

A model reads the text in front of it. It can tell you that clause 11.3 caps liability at three months' fees, and that this is a meaningful cap given your exposure. It cannot tell you whether that cap holds up under the governing law named in clause 19, or whether the indemnity in clause 12 interacts with your insurance. Those depend on law and precedent outside the document.

It also has no view on leverage. Whether a clause can be changed depends on how much the provider wants the deal and what your alternatives are — neither of which is on the page.

Treat the output as a question list, not a verdict. That framing is not modesty; it is an accurate description of what you have.

Getting This Right — Commercial Confidentiality, NDAs, and When to Bring in IT

Three practical points before you upload anything.

Check whether the document forbids what you are about to do. Many draft agreements and nearly all NDAs restrict disclosure of their contents to third parties. Whether processing a document through an AI service counts depends on the wording and on the service's terms — a business or enterprise tier with contractual data-handling commitments is a materially different position from a consumer account. Read the confidentiality clause before you review the rest, and confirm the current data-retention and training terms for the tier you are actually on rather than assuming.

Strip what you do not need. The review works on structure and definitions, not identity. Vendor name, legal entity names, individual contacts and sometimes pricing can be placeholders without weakening a single finding.

The technical annexes are where non-technical buyers get caught. Patch windows, backup RPO and RTO, in-scope device counts and what happens when you exceed them, monitoring coverage, and the exclusion of "customer-supplied equipment" are commercial terms wearing technical clothing. Someone who runs IT estates should read them, and that discipline — explicit deliverables, explicit exclusions, measurable acceptance criteria — is exactly what a properly written IT scope of work is for. Our AI+ support practice and managed IT support sit either side of it. Brocent has been writing and delivering against these agreements across Asia since our founding in Beijing in 2007, with headquarters in Singapore and a Hong Kong office since 2016 — including, occasionally, having clients run this checklist over our own paperwork. The same document-interrogation pattern is worth reading alongside using AI to review a financial model.

Frequently Asked Questions

Is uploading a contract under NDA to an AI tool a breach of confidentiality?

It might be, and the answer is in the document. Confidentiality clauses typically restrict disclosure to third parties, sometimes with a carve-out for professional advisers and service providers under equivalent obligations. Whether an AI vendor fits that carve-out depends on the clause and on the vendor's contractual terms for your tier. If the agreement is sensitive, use a business or enterprise tier with data-handling commitments, redact identifying details, or ask the counterparty — asking is not a weak move.

Can AI catch a missing exit or termination clause?

Yes, and absence is where it is most useful, provided you ask for it directly. Models are much better at "does this document address X" than at spontaneously noticing that X is missing. Give it a list of what a complete agreement of this type normally covers and ask which items are unaddressed. That reframing turns a hard task into an easy one.

Does this replace a commercial lawyer?

No. It replaces the version of this review where nobody reads the contract at all, which is the realistic alternative for most SMEs. Used well, it makes a lawyer cheaper to use: instead of "review this agreement," you arrive with six specific clauses and a question about each.

What SLA definitions should we insist on?

At minimum, a written distinction between response and resolution, severity levels defined by business impact rather than by the provider's judgement, stated business hours with explicit out-of-hours handling, and a named measurement source. Whether you also need a resolution-time commitment depends on what downtime actually costs you — a number worth having before the negotiation.

How do we compare two MSP quotes fairly?

Extract the same axes from both — scope, exclusions, SLA definitions, chargeable events, term and exit, data ownership — then compare the axes rather than the proposals, paying particular attention to terms both documents use but define differently. Price per seat is the easiest thing to compare and rarely the thing that decides total cost.

Can it handle a scanned PDF or a contract in two languages?

Scanned documents need reliable text extraction first; a poor scan produces confident nonsense, so spot-check the extracted text against a few clauses. Bilingual agreements are common here and usually name one language as controlling. Have the model find that clause first, review the controlling version, and treat any discrepancy between the two as a question for the vendor rather than a conclusion.

Where to Start

Take the last agreement you signed, not the one in front of you. You already know how that relationship has gone, so you get a free accuracy check on the method — and if the review happens to surface the thing that has bothered you for a year, you will know what to raise at renewal. If the questions it produces are about scope and exclusions rather than legal risk, that is an IT conversation rather than a legal one — one we are happy to have: get in touch.