Your Vendor Contracts Are Already Your AI Regulation
Many organisations are waiting for AI-specific legislation before building compliance programs. But existing vendor contracts, data processing agreements, and insurance policies already create binding obligations. The real regulatory framework is already in the fine print you signed. APP 8, CPS 230, and your DPA clauses don't wait for Parliament.
The "Wait and See" Posture Is Costing You
I hear it constantly. From procurement leads, from GCs, from CIOs sitting in board meetings: "We're monitoring the regulatory landscape. When there's actual legislation, we'll build a compliance program."
It sounds responsible. It's not.
While you've been watching Parliament for an AI Act that hasn't arrived, your organisation has been signing contracts that create binding compliance obligations right now. Your SaaS agreements. Your data processing addendums. Your cyber insurance policy. Every one of these documents contains clauses that don't wait for a regulator to act.
The real AI regulatory framework isn't coming from Canberra or Brussels. It's already in the fine print you approved last quarter. And if you haven't read it through an AI governance lens, you're already exposed.
Your DPAs Are Already Doing the Regulator's Job
Take a look at the Data Processing Addendum attached to your last enterprise AI subscription. If you're lucky enough to have one, it almost certainly contains clauses that function as de facto regulation. Many free-tier and consumer-grade AI tools don't offer DPAs at all. If your team is using one of those with customer data, the compliance gap predates any AI-specific legislation.
Model training commitments. Data deletion timelines. Subprocessor notification windows. Jurisdiction restrictions. These aren't abstract compliance concepts. They are contractual obligations that carry financial penalties for breach. They exist whether or not Parliament passes an AI Act this year.
Here's a concrete example. Under APP 8.1 of the Privacy Act 1988, an Australian entity must take "reasonable steps" to ensure an overseas recipient does not breach the Australian Privacy Principles before disclosing personal information cross-border. Section 16C makes your organisation accountable for what that overseas processor does. You don't need a new AI Act to trigger this obligation. It's been law since 2014.
Your DPA might say the vendor processes data in Virginia. But the model training pipeline runs through San Francisco, and the safety classifier sends inference metadata to Dublin. Which jurisdiction's privacy law applies? Your DPA probably doesn't say. That silence isn't a regulatory gap waiting for legislation. It's a contractual gap you already signed.
The Five Clauses Your Contract Checklist Is Missing
Most procurement teams run a standard security questionnaire. Those questionnaires weren't built for AI. They check for SOC 2 reports and encryption at rest. They don't ask the questions that matter for AI governance. If you're relying on your existing vendor security review to catch AI risks, you're using the wrong tool.
Here are five AI-specific clauses that should be in every vendor evaluation:
1. Model training commitment. Is it in the DPA, or only on the vendor's trust centre page? Trust centres change. Marketing promises shift. Only a contractual clause is durable. Anthropic flipped claude.ai to opt-in for training in October 2025, but without a DPA clause, that commitment vanishes if their terms change again.
2. Data deletion timelines. "We'll delete your data" means nothing without a timeline. You need to know: logical deletion versus physical deletion, backup purge windows, and whether Zero Data Retention is actually enabled. ZDR is offered by both Anthropic and OpenAI's enterprise tier, but it's approval-gated and not on by default.
3. Subprocessor notification. Anthropic became a subprocessor for Microsoft 365 Copilot in January 2026. Most enterprise customers found out from transparency docs, not from a notification clause. If your DPA doesn't capture indirect model providers, you won't know who's processing your data until someone publishes a blog post about it.
4. Jurisdiction and data sovereignty. A vendor incorporated in Dublin with inference endpoints in Virginia is a US processor for APP 8 purposes. Incorporation jurisdiction and processing location are different things. Most DPAs blur this distinction. For APRA-regulated entities, CPS 230 has required formal agreements for material service providers since July 2025. If your AI vendor qualifies as a material service provider and you haven't mapped its processing locations, you're behind.
5. Derived data. Inference metadata. Safety classifier results. Embedding cache patterns. Model telemetry. These aren't covered by standard "log files" clauses, yet they contain latent information about your usage patterns and, in some cases, your data. If the DPA doesn't define "derived data" explicitly, assume it's not covered.
Insurance Doesn't Know What AI Is Yet
Ask your broker whether your cyber insurance policy covers AI-related incidents. Specifically. Not "cyber incidents that happen to involve AI" but incidents where the root cause is a model hallucination, a prompt injection, or a training data poisoning attack.
Most policies haven't caught up. The language was written for data breaches and ransomware, not for a customer service chatbot that invents a refund policy and your team honours it. Or an internal HR tool that generates biased recommendations based on prompt engineering the vendor never tested for. If you're waiting for a regulator to tell you to check your insurance, you've already missed the window where checking would have helped.
What to Do Instead of Waiting
Stop treating AI compliance as something that starts when legislation passes. It started when you signed your first enterprise AI contract.
Pull every DPA and terms-of-service document for every AI tool your organisation uses. Include the ones individual teams signed up for without procurement knowing. Map the five clauses above against what you actually have. Where there's a gap, it's not a "we'll fix it when there's a law" problem. It's a contractual exposure problem right now.
Check your insurance. Ask the specific question about AI-caused incidents. If the answer is "we're not sure," you've just identified your highest-priority gap.
If you're an APRA-regulated entity, CPS 230 has been effective since July 2025. Your material service provider agreements for AI tools need formal contracts with specified content: service descriptions, performance standards, reporting obligations, exit provisions. If you haven't done this for your AI vendors, you're already behind.
And if you haven't already, look at what your board needs to know about AI governance. The conversation shouldn't start with "what's the law?" It should start with "what have we already signed?"
Parliament can take as long as it wants. Your contracts are already regulating you. The question isn't whether AI compliance is coming. It's whether you've read what you already agreed to.
Need help auditing your AI vendor contracts? Get in touch or see a sample audit report to understand what a proper AI governance review looks like.
Written by David Swan, reviewed and fact-checked against primary regulatory sources. AI-assisted but human-directed.
Frequently asked questions
Do I need to comply with AI regulations if there's no specific AI law yet?
Yes. Regulations like the Privacy Act 1988 (especially APP 8 on cross-border data disclosure) and APRA CPS 230 already apply to AI tools. Your vendor contracts and data processing agreements create binding obligations whether or not standalone AI legislation exists.
What are the most important clauses in an AI vendor DPA?
Five clauses matter most: model training commitments, data deletion timelines, subprocessor notification windows, jurisdiction and data sovereignty, and derived data handling. Most standard security questionnaires don't check any of these.
Does my cyber insurance cover AI-related incidents?
Most cyber insurance policies were written for data breaches and ransomware, not for AI-specific incidents like model hallucination, prompt injection, or training data poisoning. You should ask your broker specifically whether these are covered. The answer is often unclear.
What is APP 8 and how does it affect AI tool choices?
APP 8 of the Australian Privacy Act requires entities to take 'reasonable steps' before disclosing personal information to an overseas recipient. Under s16C, your organisation is accountable for the acts and practices of that overseas recipient. If your AI vendor processes data outside Australia, APP 8 applies.
Should I pause AI procurement until regulations are clearer?
No. Pausing doesn't reduce exposure. It just means you have less visibility into what you've already signed. Instead, audit existing contracts and DPAs against AI-specific clauses, check your insurance coverage, and build an AI vendor governance framework using existing standards like ISO 42001.
