An AI system that can read a contract and prepare a notice in minutes has an obvious appeal to a busy project team. It can find provisions, organise supporting records and reduce the time spent preparing documents.
I am not against using AI in contract administration. Used carefully and for the right tasks, it can give experienced people more time to manage the project. My concern is with treating a reduction in administrative work as proof that the people responsible for administering the contract can safely be replaced.
A demonstration can show how quickly the software produces an answer. It tells the contractor much less about whether the documents can lawfully be uploaded, whether the service will be available before a deadline or who bears the loss if the answer is wrong.
There is a risk that enthusiasm for what AI contract administration can do is outpacing the commercial, legal and operational arrangements needed to provide the service responsibly.
The consequences depend on how much the project relies on the system. An occasional interruption to a drafting assistant may be inconvenient. If the platform holds the only accessible record of pending notices, payment assessments and deadlines, the same interruption may prevent the team from meeting its obligations.
What is being handed over
Contract administration starts with recognising that something needs attention. Consider an obstruction encountered during excavation. The supervisor records it in a daily report, discusses it with the client's site representative and changes the working sequence. The work continues, but nobody refers the event to the commercial team. A system capable of drafting an excellent notice achieves little if it never receives the information or nobody asks it whether action is required.
Connecting the software to daily reports and correspondence may help, provided it can identify matters needing further investigation. It still needs enough information to reach a useful answer. A report that the contractor has encountered rock may need to be read alongside the site investigation information, tender assumptions, correspondence and amendments. Without that context, the software can produce a well-written explanation of a position that does not apply to the project.
The response also extends beyond a notice. The excavation team may need further investigation, an alternative working method and an assessment of programme and cost effects. Someone must obtain the missing facts, speak to the people involved and decide what can be done while the contractual process continues. Much of that work takes place before it appears in a formal record.
Before handing over the function, the contractor needs to establish exactly what the system will do. Preparing a draft after a person identifies an event is different from monitoring the project for events requiring action. Calculating a deadline does not ensure that an authorised person serves the right document in time. Each remaining responsibility needs an owner. Otherwise, site personnel may assume that the system is monitoring everything while the commercial team waits for the site to report a problem.
Recognising the errors that matter
Suppose a system selects and drafts the correct notice in 95 out of 100 test cases. The usefulness of that result depends heavily on the five failures. Incorrect advice that no notice is required can be particularly difficult to detect: nothing is produced for approval, so a reviewer checking only generated documents may never see the omission before the deadline passes.
The same event may trigger more than one notice under a contract. A warning about a developing problem does not necessarily satisfy a separate requirement to notify a claim for additional payment or time. The software needs to apply the project's actual provisions and amendments. Recognition of familiar standard clauses is not enough if the signed contract has changed them.
A human approval step helps only if the reviewer has the knowledge and information to identify a mistake. The review needs to examine the facts, applicable provisions, assumptions and missing information, including the basis for advice that no action is needed. Otherwise, a confident explanation with convincing clause references may receive approval without meaningful scrutiny.
Payment claims and schedules
Payment administration brings those risks into a regular assessment cycle. Suppose the records support a $500,000 claim, but the system omits an eligible $40,000 variation and prepares a claim for $460,000. The arithmetic may be correct while the amount being claimed is incomplete. Whether the omission can be recovered later depends on the contract, legislation and circumstances.
An error in value must also be distinguished from a defect affecting the claim's legal effectiveness. An incorrect amount does not necessarily invalidate a claim, while an accurate valuation may not cure ineffective service or a missed statutory time limit. The recipient's identity and the permitted method of giving the claim need to be established independently of the assessment. A system intended for Australian projects must also identify the applicable security of payment legislation and transitional provisions, rather than assume that one template or timetable works nationally. The NSW guidance on changes to payment claim requirements and Queensland guidance illustrate the differences that need checking.
The calendar can be just as consequential for the party responding. In a separate example, a head contractor receives a valid $500,000 subcontractor payment claim governed by the NSW Act. No earlier contractual deadline applies, so the payment schedule must be served within ten business days after service of the claim. The system instead uses the company's shutdown calendar and excludes two days that count as business days under the Act. A schedule proposing $350,000 is served two business days late. No payment has been made.
The head contractor may have sound reasons for its $350,000 assessment, but it has not served a payment schedule within time. It becomes liable to pay the full $500,000 on the payment due date, and the late schedule does not retrospectively cure that failure. This is an interim statutory payment liability, not a final determination that the work is worth $500,000. The NSW Government's guidance on payment schedules explains the consequence of missing the response deadline.
The system therefore needs to apply the correct calendar to each contractual and statutory obligation, including any shorter contractual response period. A company shutdown or project working calendar cannot simply be substituted for the statutory definition of business day.
Permission to upload the documents
Some contracts already expressly restrict AI use and prohibit uploading contract documents or other protected information. Essential Energy's standard procurement terms, for example, prohibit suppliers from uploading or inputting its broadly defined data into any AI system. Tasmania's technology contract conditions also contain an express upload prohibition, alongside a requirement for prior written consent to AI use in performing the contract.
Even without an AI-specific clause, the contract's ordinary confidentiality provisions are still likely to apply to the information being uploaded. A restriction on disclosure to third parties can extend to providing confidential documents to an external AI service. The Commonwealth's model confidentiality clause, for example, restricts disclosure without prior written approval, subject to stated exceptions, without needing to mention AI. Whether a particular upload is permitted depends on the wording, any permitted recipients and purposes, and the service's actual data arrangements. A supplier's promise to keep information confidential or not use it for training does not itself authorise disclosure.
The review needs to take place before the proposed upload. Tender undertakings may impose restrictions before the construction contract has even been signed. Asking the AI system whether the contract permits its use may mean making the very disclosure being examined. An authorised person should first establish whether consent, an approved environment or limits on the material processed are needed. Descriptions such as private, enterprise or Australian do not establish that a product is authorised for the project.
Permission also needs to cover the records actually used. Drawings, subcontract quotations, pricing and personal information may carry obligations different from those applying to the contract conditions. Approval to process one document is not approval to upload the entire project record. The software terms must be checked against those obligations. If the contractor has promised its client that project information will not be used for model training, accepting software terms that permit that use creates a conflict. Any permissions needed from the client or other rights holders must be resolved before use.
Nor should a contractor assume that its use of AI will remain undetected. Some systems embed statistical watermarks in generated wording that may help identify AI involvement. Such a watermark does not establish which documents were uploaded or whether their use was authorised, but it may prompt questions about how a notice was prepared and what information was supplied to the system. The contractor should be able to explain and justify that use, rather than rely on it passing unnoticed.
The business behind the software
Providing software as a service, or SaaS, requires continuing investment in hosting, cybersecurity, support, testing, insurance and compliance. Those costs continue after the application has been built, even when no new features are being developed. The supplier also needs people available to investigate defects and make urgent corrections.
The contractor should understand how the business will sustain those obligations and what happens if key personnel are absent or leave. Size alone provides little assurance: a small provider may have sound cover arrangements, while a larger one may still depend on a single specialist. A consultancy with useful software needs the operational capacity to run the service on which customers will depend.
Those arrangements need to be reflected in the customer agreement. A software subscription does not necessarily carry the professional duties or remedies available under a consultant's appointment. Assurances about confidentiality, data residency, security and the use of customer information should be read alongside the supplier's contractual terms. The protections described in marketing material may differ from the obligations undertaken in the agreement. The contractor's IT, security and legal advisers may need to help establish what is binding and whether the technical documentation supports it.
Liability under the service agreement
If the contractor loses an entitlement or incurs a payment liability because the software gets a deadline wrong, relying on that software will not ordinarily excuse the failure under the construction contract. Recovery from the supplier is a separate matter, governed by the service agreement and applicable law. The two agreements need to be compared. Verification requirements, excluded accuracy warranties or liability limited to subscription fees may leave the contractor bearing a loss it cannot recover from the supplier.
Insurance needs the same scrutiny. Professional indemnity, technology errors and omissions, and cyber liability cover address different exposures, although policies may combine them. A consultancy's professional indemnity cover should not be assumed to extend to a separately operated software product. The insured activities, relevant exclusions, limits and excesses need to be examined against the platform and the contractual recommendations it provides.
There are three amounts to consider: the loss that could occur, the amount the supplier is legally obliged to pay and the amount it is financially able to meet. Insurance does not automatically increase a contractual liability cap, and accepting a liability is of limited comfort if the supplier lacks the resources or cover to meet it. Australian Consumer Law protections, including those for qualifying standard-form small business contracts, may be relevant, but should not be assumed to remove every exclusion or provide an adequate remedy. The ACCC's guidance on contracts explains their application.
What has the software replaced?
A supplier may promise substantial reductions in administrative effort while its terms require the customer to obtain independent professional advice, verify outputs and retain responsibility for consequential decisions.
Those requirements may be entirely appropriate given the consequences of an incorrect contractual recommendation. But if the contractor must retain experienced personnel to identify the issues, check the advice, approve the notices and accept responsibility for the consequences, what exactly has the software replaced?
The savings need to be assessed against the whole cost of using the service, including implementation, training, professional verification and technical support, as well as the risks that remain with the contractor. Faster document preparation is valuable, but it does not establish that the remaining work or its cost has disappeared.
Questions to ask before adopting an AI powered system
1. What uptime is promised and what does it cover?
An availability commitment is useful only when its scope and exclusions are understood. A dashboard may remain accessible while document retrieval or notice generation is unavailable. Scheduled maintenance and failures at an external model provider may also be excluded from the calculation, allowing the service to meet its monthly uptime target despite being unavailable when a notice is due.
The service agreement should explain how availability is measured, how incidents are recorded and how customers receive updates. The remedies deserve equal attention. Subscription credits may compensate for lost access to the software, but they are unlikely to match the value of a contractual entitlement lost during the interruption.
2. Where is the data stored, processed and accessed?
An Australian supplier may use overseas infrastructure, external AI models or support staff in other countries. Even where the uploaded documents remain in Australia, extracts may be sent elsewhere for processing. The explanation needs to identify the organisations involved, the models used and the locations of processing, backups and support access. If different tasks use different models or providers, those arrangements should be disclosed too.
Prompts, extracted text, generated documents and logs may have retention arrangements different from those for the original files. The contractor needs to know what is retained, for how long and what rights it has if the supplier later changes the arrangements. Where the Australian Privacy Principles apply, the OAIC's guidance on commercially available AI products supports examining suitability, access, privacy risks and human oversight before adoption. Commercially confidential material needs protection whether or not it contains personal information.
3. Is the information encrypted and who can access it?
Encryption during transmission and storage is important, but the contractor also needs to understand who controls the keys and who can decrypt the information for processing. Access arrangements should cover multifactor authentication, user permissions, privileged staff accounts, access logs and separation between customers. Independent assessments can provide assurance, provided their scope includes the systems and services being used.
AI systems reading external documents need protection against instructions embedded in that material. The supplier should be able to explain how it prevents a retrieved document from being treated as authority to disclose information or take an unauthorised action. The contractor also retains responsibilities for its own accounts and permissions, as the Australian Cyber Security Centre's cloud guidance explains.
Those arrangements need to extend to a security incident. The agreement should specify how quickly the supplier must notify the contractor, what information it must provide and who investigates, preserves evidence and pays recovery costs. A breach within the supplier's infrastructure may still leave the contractor with obligations to its client or under privacy law. The OAIC's guidance on breaches involving more than one entity explains the need to allocate responsibilities between the organisations involved.
4. What support is available when something goes wrong?
A payment claim that will not generate or a deadline calculated incorrectly needs more than an acknowledgement from a contact email address. The contractor needs to know when support operates, how urgent issues are classified and what response and restoration targets apply. A managed ticket system should give each issue a reference number and retain its history, including who is responsible, how it was escalated and what resolved it.
The available expertise matters as much as the hours of operation. Technical support may resolve a fault without being able to assess an incorrect contractual recommendation. The supplier should explain how those cases reach competent specialists and how customers are notified if a defect has affected earlier outputs. Correcting the software may leave the project team needing to review notices or assessments it has already issued.
5. What happens during an outage or loss of data?
Backup arrangements need to be understood through to recovery. The supplier should explain what is copied, how frequently, where the copies are held and whether a complete recovery has been tested. The recovery time objective describes the targeted time to restore service; the recovery point objective describes the targeted limit on data loss, measured in time. A 24-hour recovery point objective could leave the team reconstructing a day's records. Neither target should be treated as a guarantee without examining the agreement and the arrangements supporting it.
The contractor also needs a fallback independent of the platform. That means access to the contract, recipient details, pending notices and deadlines, together with a permitted alternative route for preparing and serving communications. A procedure accessible only through the unavailable application will not help the person trying to meet a deadline.
6. Can the supplier use your information for anything else?
The project record may reveal tender strategies, rates, margins and the positions taken in a dispute. Removing names does not necessarily remove its commercial sensitivity. Processing that information to provide the agreed service should therefore be distinguished from using it for model training, benchmarking, product development or advice to other customers.
The agreement needs to address ownership and rights to access, use and export original documents, generated outputs and derived information. Ownership of the uploaded files does not settle every right over what is produced from them. The contractor should establish whether secondary use can be refused and what happens to information already incorporated into another system. Where the supplier also provides consultancy services, separation of customer information and management of conflicts need particular attention.
A promise that the customer owns an output does not establish that copyright exists or clear third-party rights. IP Australia's guidance on AI and IP rights explains the distinction. The terms should permit the intended use and explain what the supplier will do if an infringement claim arises, including who handles the claim and pays the costs, subject to any exclusions.
7. How is contractual accuracy tested?
Testing should reflect the work the system is being purchased to do. Relevant evidence includes who established the correct answers, whether the cases include amended contracts and how the system responds to incomplete or conflicting facts. A demonstration based entirely on questions selected by the supplier gives the contractor little opportunity to examine its limitations.
The results should identify missed obligations, when the system seeks more information and when it refers a matter for expert review. Testing needs to examine confident but incorrect advice, including advice that no action is required, as well as answers the system declines to give.
8. What changes when the software or underlying model is updated?
A system can start producing different answers after a change to its model, instructions, document retrieval or external services, even though the application appears to work normally. The supplier needs a process for testing releases, recording which versions produced an output and communicating material changes or defects. Where a release is defective, its ability to restore a working version should be understood.
An external provider may control model updates or withdrawals, leaving the supplier unable to retain the version it previously tested. Its arrangements should explain how it manages that dependency and checks the replacement before relying on it. The National AI Centre's implementation guidance addresses continuing testing, monitoring, supply-chain accountability and human oversight throughout use.
9. Can it complete the contractual communication process?
A saved draft, an approved document and a notice received by the other party have different contractual significance. The system needs to identify the authorised sender and recipient, apply the required method of communication and retain evidence of issue or receipt where needed. Attachments and approval permissions belong in that assessment as well as the wording of the document.
An integration with email or a correspondence platform should be tested against the actual contract. Successful transmission alone does not establish that the communication was effective, particularly if it went to the wrong entity or used a method the contract does not permit.
10. Who bears the loss and can you leave with your records?
The supplier should identify the legal entity accepting responsibility and the insurance supporting its obligations. The agreement also needs to explain what assistance remains available if the relationship ends, including after a payment dispute or an unexpected closure of the service.
Export should be tested before the platform becomes the project's principal record. If advice is disputed, the contractor needs to establish what documents and instructions the system received, which model version it used, what it produced, and what people amended, approved and sent. Notices, attachments, registers, timestamps and service records need to remain connected to that history. The agreement should provide for preservation and usable access after termination, including during a dispute with the supplier. This concerns records of the work performed, not a model's private internal reasoning. Claims may arise years later, when maintaining a subscription simply to interpret the record is no longer practical.
Using AI in contract administration
A sensible starting point is to use the system for defined tasks and compare its work with experienced review. Wider use should follow evidence that it performs reliably on the project's documents and procedures, with clear responsibility for reporting issues and making decisions.
The standard for demonstrating that an AI application is technically impressive is very different from the standard for establishing that customers can safely rely upon it in practice.
References and further reading
Office of the Australian Information Commissioner (2025) Guidance on privacy and the use of commercially available AI products. Updated 17 January 2025.
Australian Signals Directorate's Australian Cyber Security Centre (2025) Cloud shared responsibility model: Guidance for individuals and small and medium businesses. Published 20 October 2025.
National AI Centre (2026) Guidance for AI adoption: implementation guidance. Published 5 May 2026.
Australian Competition and Consumer Commission (n.d.) Contracts.
NSW Government (n.d.) Changes to Security of Payment laws.
Queensland Building and Construction Commission (2021) Request payment. Last reviewed 31 August 2021.
Office of the Australian Information Commissioner (n.d.) Part 4 Notifiable Data Breach Scheme, Data breach preparation and response.
Chubb (n.d.) Technology Industry.
Coalition (n.d.) Technology Errors and Omissions insurance.
NSW Government (n.d.) Security of payment frequently asked questions.
IP Australia (n.d.) AI and IP rights.
Essential Energy (2026) Standard terms and conditions for supply of goods and services. Version 9 January 2026, clauses 1.1(y) and 35(d).
Tasmanian Government (2026) TTCC General Contract Conditions. Version 2026-01, clauses 4(cc)(a) and 4(cc)(b).
Australian Government Department of Finance (n.d.) Disclosure of information. Commonwealth ClauseBank, model clause X.2.
Google AI for Developers (2025) SynthID Tools for watermarking and detecting LLM-generated Text. Updated 9 April 2025.
Anthropic (2026) How Claude's text watermark works. Published 14 August 2026; updated 1 September 2026.
All references accessed 24 October 2026.
