I help organisations put AI to work, and the vendor relationship underneath that work is where I most often watch the governance quietly thin out — usually starting with a contract nobody can quite find.
It is not that the contract is unimportant. It is that it gets treated as a closed room. Legal has a version. Procurement has a renewal file. Technology remembers the commercial promise. Risk has a register entry. The business knows the product name. Then the vendor changes a model family, alters a feature, routes data through a new path, misses an incident window, or becomes the third critical workflow sitting on the same foundation-model provider.
At that point the question is not whether an agreement exists.
It is whether the enterprise can still see what it agreed to.
That is the centre of D8, Vendor and Third-Party Governance, in the framework. AI vendor governance is easy to misread as ordinary supplier management with a new appendix. It is not. The third-party surface now includes foundation-model providers, SaaS platforms with embedded AI, agent orchestration tools, retrieval platforms, AI-specialist consultancies, sub-processors, and cloud dependencies that may sit underneath all of them.
The first hard gate is D8.2: AI-specific contract terms and indemnification maintained as a system of record across the AI vendor estate. I am deliberately not turning this into a clause checklist. Specialist legal counsel determines which AI-specific terms are required per vendor, risk tier, and regulatory context. IP counsel determines training-data rights questions. Insurance counsel determines coverage interpretation. Privacy and regulatory counsel determine the applicable obligations and timing.
The operating-model question is different. Are the AI-specific terms captured per vendor in a live system of record, or scattered across legal repositories, email, PDF attachments, and renewal folders? Are they reconciled annually or under material change? Are they actually consumed downstream — by the people validating indemnification, running redress when a vendor’s agent affects a customer, enforcing the security perimeter, and responding to incidents — or do they just sit in the repository?
Many organisations can produce a master services agreement for a flagship AI vendor. Fewer can show the estate-wide record of which AI terms apply to which material use cases, when those terms were last reconciled, which vendor terms changed, and which residual gaps were accepted by a named officer. That difference matters. A contract that cannot be found, reconciled, and consumed is not an operating control. It is stored optimism.
The second hard gate is D8.3: vendor concentration risk discipline. In 2026, most enterprise AI capability is concentrated through two to four foundation-model providers, directly or through platforms that broker access to them. The SaaS layer concentrates the risk again. Microsoft 365 Copilot, Salesforce Einstein, ServiceNow, Workday, contact-centre tooling, hiring software, and analytics platforms can introduce AI dependency without a project ever calling itself an AI program.
Concentration risk is not solved by listing providers. A supplier list is a map of names, not a control. Mature concentration governance classifies concentration tiers, maps them to use-case criticality, sets named thresholds, gives the board or executive forum a visible posture, and tests mitigation through governed-portability drills. If three material decision classes depend on one provider, the board should not discover that from an incident review.
This is where APRA CPS 230 becomes concrete for APRA-regulated entities. CPS 230, in force since 1 July 2025, brings operational risk and material service provider obligations into a much sharper discipline. It is not an AI law. It is an operational-resilience standard that makes material third-party dependency hard to treat as background plumbing. Specialist regulatory counsel determines the entity-specific obligations. The operating model should make the facts visible enough for that counsel, and for accountable management, to act before the vendor estate becomes an unexamined concentration.
For Commonwealth non-corporate entities, the DTA hosting direction-of-travel may matter, with the 3 November 2025 registration-pause caveat for the Hosting Certification Framework and the distinction that those expectations are not general private-sector law. For company directors, Corporations Act s180 remains a useful discipline in plain terms: material vendor decisions should be made with an informed basis, not reconstructed afterwards from procurement memory.
D8.1 is the front door. AI vendor due diligence should happen before contract execution, not as a comfort exercise once the preferred product has already won. The assessment has to go beyond generic IT questionnaires. It should test model capability and limitations against intended use, training-data provenance and rights chain where relevant, model-update and deprecation history, security posture for AI-specific threats, AU presence and Privacy Act 1988 APP 8 cross-border disclosure implications, APP 11 protection of held personal information, sub-processor visibility, incident history, financial viability, and reverse-migration feasibility from day one.
The maturity signal is not a long form. It is a dated due-diligence record, signed off by named accountable functions, mapped to D2.3 criticality and the D2.4 build/buy/partner decision, and refreshed at renewal or material vendor change. Vendor-embedded AI needs the same discipline when it meets materiality thresholds. This is where many 2026 estates are most exposed. The foundation-model provider receives attention; the SaaS renewal quietly adds an AI feature that starts handling operational work.
That does not mean every vendor receives the same weight. A low-criticality internal tool and a material customer-impacting agent should not carry identical burden. L4 maturity shows graduated stringency across criticality tiers: lighter controls where the impact is genuinely low, stricter evidence where the use case is material, and no flagship-vendor theatre where the best-governed supplier is used to imply the estate is governed.
D8.4 then asks what happens when the vendor sees trouble first. For foundation-model providers and SaaS-embedded AI, the enterprise often has limited direct telemetry. If the runtime sits inside the vendor, the vendor incident-notification SLA may be the only early signal.
The maturity question is not whether there is an incident clause. It is whether the vendor’s clock lets the enterprise meet its own clock. OAIC’s Notifiable Data Breaches scheme under Privacy Act 1988 Part IIIC has assessment and notification consequences that privacy counsel determines for the entity and incident. APRA CPS 230 has material-incident notification considerations for APRA-regulated entities that regulatory counsel determines. ASIC obligations may matter for AFS or credit licensees. Commonwealth reporting pathways may matter for Commonwealth entities. The vendor SLA is only the cascade trigger. The enterprise obligation is the binding clock.
The operating discipline is specific: incident classification aligned to D10.3, timing earlier than the enterprise’s applicable obligation, evidence-package expectations, named operational handoff, 24/7 escalation for material-impact incidents, and post-incident learning handed back into D10.4. The evidence package may need affected model or agent identification, system-log extracts where the vendor controls the surface, scope of compromise, remediation status, and customer-communication guidance. Specialist counsel and security teams determine the required artefacts. The framework’s job is to make sure the handoff exists and fires early enough.
D8.5 closes the lifecycle because vendor relationships run for years. AI vendor risk does not stay frozen at onboarding. Model families are deprecated. Terms change. Product features are renamed. Sub-processors shift. Funding pressure or market consolidation changes viability. A vendor that looked tolerable at contract execution may become a concentration problem after three internal programs standardise on it.
Ongoing governance therefore has to monitor model-update notice compliance, regression evaluation outcomes, deprecation discipline, announced SLA performance, redress-SLA performance, reverse-migration drill cadence, concentration re-assessment, residual-risk acceptance, and exit readiness. D5.2 owns governed-portability design. D8.5 owns the vendor-estate discipline that says whether the drill cadence is being met and whether failed controls were remediated through closure.
The residual-risk register is important because not every gap will be closed by due diligence, contract terms, concentration mitigation, or incident SLAs. Some exposure will remain. D6.2 owns the internal accountability and funding substrate. D8.5 owns the vendor-estate surface that feeds it: which residual risk exists, who accepted it, when it is reviewed, and what vendor change would reopen the decision.
This is also where “integrate into existing committees” becomes too soft unless it is paired with hard accountability. A procurement forum can help. A technology risk committee can help. A legal or privacy review can help. A regulated three-lines model can help. None is sufficient unless named ownership, decision rights, gates, threshold breaches, and remediation closure are explicit. The accountability path could sit with a CAIO, an extended CIO/CDO/CTO mandate, a risk or operations-resilience executive, or CEO-direct sponsorship. The framework requires the accountable outcome, not a title.
The L4 buyer question for D8 is deliberately difficult: select an AI vendor at random from the D2.3-linked estate and show same-quarter live evidence across due diligence, AI-specific contract terms in the system of record, concentration tier, incident-SLA performance, ongoing performance, redress audit, residual-risk register, and exit readiness. Then show a reverse-migration drill within the rolling 12 months for a material-impact vendor, with recovery timing measured and failed controls remediated.
Random selection matters. Without it, the organisation will show the one vendor everyone already watches. Live evidence matters. Without it, the organisation will show reports assembled from different time periods and different suppliers. Vendor-embedded AI matters. Without it, the organisation will govern the obvious provider and miss the AI that arrived through the renewal path.
The Responsible and Agentic AI Governance pillar is not only about internal ethics, accountability, and risk. It is also about the fact that an enterprise can outsource capability without outsourcing accountability. A vendor can supply the model. A vendor can host the agent. A vendor can promise an indemnity, an SLA, a redress path, or a migration route. The enterprise still needs to know where those promises live, whether they match the use case, and whether they have been tested.
So the test I would actually apply is a small one. Take a single material AI-enabled workflow and ask the estate to remember it: the due-diligence record, the contract terms, the concentration tier, the incident clock, the last model change, the residual risk someone accepted, the way out. If those answers can be found, reconciled, and shown to a colleague who was not in the original room, the vendor estate has a memory worth trusting. If they cannot, the contract that looked like a control was only ever stored optimism.