Michael Simonetti BSc BE MTE, is a AI expert witness based in Melbourne, instructed by firms across Australia and internationally, including but not limited to Sydney, Brisbane, Adelaide, Perth, Auckland and Singapore. A detailed list of the cases and firms he has represented is set out on his bio and profile page. As part of his expertise, Michael assesses artificial intelligence, machine learning and large language model systems in disputes preceding and up to the Federal Court of Australia and the State Supreme Courts.
Artificial intelligence matters turn on questions counsel cannot answer from the pleadings and statements of claim. For example; Whether a model produced the output attributed to it. Whether a system was built on another party’s model, data or work. Whether a capability claim matched what was actually deployed, and how any of that relates to intellectual property, misleading conduct, and the wider commercial, industry and market position.
A Artificial Intelligence Expert Witnesses for the courts’ role includes;
Forms part of pre-briefing sessions with a legal firm or firms representing applicants, respondents, plaintiffs or defendants in cases before the courts
Is briefed by one of the legal firms representing the party(s) to produce an expert report for the court.
Produces an independent expert report, in this field it would cover aspects of artificial intelligence, machine learning and software engineering and may cover a wider commercial scope if briefed.
Produce a joint expert report if instructed by the court.
Potentially be part of a mediation, and / or court appearance to be cross examined by the opposing barrister(s) either individually or together with the opposing expert (“Hot Tub” format).
Michael’s expert witness work has covered over 100 reports covering these tasks extensively. Michael opines in reports and provides testimony which are “judge ready”, which allows someone with no artificial intelligence or software engineering background to follow, without losing the technical precision that makes the answer both objective and proveable.
That is where the volume of work produced in the past and courtroom experience matters. Michael has been in court and worked through joint reports dozens of times, including conferences of experts, mediation, concurrent evidence sessions and cross examination. Over 2 decades of expert witness practice, he has built the legal acumen to hold a defensible technical position under pressure, which over and above writing the analysis in the first place.
An example challenge in an LLM expert witness matter is treating an AI output as though it were a document. Run the same prompt twice and a model will frequently produce two different answers. Run it a month later and the model behind the product name may have been replaced entirely. An output is a recorded event, not a reproducible artefact.
Material that has to be accounted for before an output means anything:
• Sampling behaviour, since most deployed systems are configured to produce varied output rather than identical output
• Silent version changes, where the model behind a stable product name is updated without notice to users
• System prompts and configuration set by the operator and never visible to the person using the product
• Retrieval and tool use, where the answer depends on documents or search results fetched at that moment
• Conversation context, because earlier turns materially change what the model produces later
• Regional variation and staged rollouts, which mean two users in different markets are not using the same system
What survives that filtering is the account of the output worth putting in front of a court. It rests on contemporaneous logs and version records rather than on reproduction, and it is far more difficult to challenge.
Two models trained on similar public data will behave similarly. That is the field working as intended. In machine learning expert witness work, the strongest indicators are the artifacts a model has no reason to carry unless it inherited them.
• Distinctive sequences reproduced verbatim, where the material is specific enough that reproduction is not explicable by general training
• Model lineage artifacts, including tokenizer configuration, vocabulary and architectural choices carried from a base model
• Behavioral fingerprints, where a system replicates the idiosyncratic failure modes of another named model
• Training data manifests and sourcing records inconsistent with the party’s account of how the system was built
• Internal evaluation results that differ materially from the capability represented to the market
• Guardrail configuration showing that known failure modes were identified internally and left unaddressed
A single one of these proves little. A cluster of them, in a data set that has already been filtered for ordinary convergence between models, is a finding that stands up under cross examination.
The categories below indicate the material typically sought in an artificial intelligence matter. The specific list is always shaped by the systems involved and the issues pleaded.
• Model documentation. Model cards, architecture documentation, training methodology and data sourcing records.
• Inference access. Read only access to the system with the version identifiers applicable to the relevant period.
• Configuration records. System prompts, parameter settings, guardrail configuration and any operator level instructions.
• Inference logs. Timestamped records of prompts and outputs, stamped with the model version that served them.
• Training and fine tuning data. Datasets or data set manifests, including provenance and licensing records for the material used.
• Evaluation records. Internal benchmarks, test results, red team findings and pre release assessments.
• Deployment history. Version change records establishing which model was live at which time and in which market.
• Representation material. Vendor documentation, marketing claims, sales material and capability statements made to the market.
Where a claim concerns what an AI system could do, the first technical question is which system was actually running. Products are marketed under a stable name while the model behind them is replaced repeatedly, so a capability demonstrated at launch may bear little relation to what a customer received six months later.
Testing a representation requires establishing the model version live during the relevant period, the configuration it ran under, and the internal evaluation results the vendor held at the time. Where a vendor’s own testing recorded a limitation that the marketing material did not, that gap is documentary rather than inferential.
Whether the representation was misleading is a matter for the court. The role here is to establish what the system was, what it did, and what the party knew about it, with the limitations of each finding stated.
Stating the limits is part of the job, and a report that overstates its reach damages the case it was written to support.
• Without contemporaneous logs, no analysis establishes that a specific output was produced on a specific date. Reproducing it later shows the system can produce it, not that it did.
• Outputs alone do not generally establish that a particular work was in the training data, and the absence of reproduction does not establish that it was not.
• Explainability and attribution methods are approximations of model behaviour. They are not causal accounts of why a model produced a given answer.
• No technical analysis establishes intent. Model behaviour reflects training and configuration, not a state of mind.
• Benchmark results measure performance on the benchmark. They are weak evidence of performance on the task actually in dispute.
Michael Simonetti has appeared in, or prepared expert reports and expert witness reports for, the courts below. These courts sit in multiple cities and regions across the country.
• Federal Court of Australia. Defamation, misleading and deceptive conduct, corporations, intellectual property, competition, insolvency and significant commercial disputes involving federal law.
• Supreme Court of Victoria. Major commercial litigation, large contractual disputes, shareholder and director disputes, injunctions and defamation.
• County Court of Victoria. Commercial disputes, contractual claims, damages claims and some defamation matters.
• Magistrates’ Court of Victoria. Lower value civil and commercial disputes.
Artificial intelligence matters pleaded as intellectual property, misleading and deceptive conduct or competition issues fall within the Federal Court of Australia’s jurisdiction. Where the dispute is contractual, over the delivery or performance of an AI system, it more often proceeds in the Supreme Court or County Court of Victoria.
Over the past two decades Michael has applied both software engineering and commercial business skillsets to this work. Understanding a matter beyond the statements of claim has proven valuable for firms responding to briefs, preparing cases, and defending a position through joint reports, concurrent evidence sessions and cross examination.
Michael Simonetti holds degrees from Melbourne University in Computer Science and Engineering, together with a Masters in Telecommunications Engineering. He has 30 years of experience in software engineering, internet marketing and digital, including 30 years working commercially as the head of his own digital agencies. Over the past 15 years he has built a client portfolio comprising hundreds of legal professionals.
Firms who have instructed him include King & Wood Mallesons, Gadens, Allens, Herbert Smith Freehills, Thomson Geer, Gilbert + Tobin, Cooper Mills, Buchanan, Sterling and Gilchrist Connell, among others. Applicants and respondents range from small businesses and SMEs through to multinational corporations, across real estate, legal, hospitality, professional services, medical, travel, B2B and B2C sectors.
Services range from initial advice through to reports, affidavits and court appearances.
Michael Simonetti has worked with clients and courts in New Zealand, Asia, Europe and the United States. Artificial intelligence disputes are inherently cross border, since the model, the training data, the operator and the affected party are frequently in four different jurisdictions.
He travels frequently for this work, although most briefings and meetings are held online, which keeps a AI expert witness instruction practical for firms in Sydney, Brisbane, Adelaide, Perth or overseas.
An initial call establishes the technical questions genuinely in dispute and clears any conflict. Where the matter is at an early stage, that call is also the point at which discovery categories and materials can be scoped so the evidence that matters is actually captured. AndMine coordinates the engagement, and can arrange contact with an expert witness reference on request. For more information, please contact Michael Simonetti at AndMine.