Picture a software engineer working on your production system. They open their laptop, load the task, and run the problem through an AI coding assistant. The output is clean, efficient, and correctly structured. What you may not know is which AI tool processed your business logic, whose infrastructure it ran on, or whether your proprietary code has just passed through a model whose data handling you have never reviewed.
Australian technology leaders are asking more rigorous questions of their vendors than they were three years ago. One question is still rarely on the assessment list: which AI tools are your engineers using on our code, and what governance standard applies? For organisations working with offshore engineering partners, this is becoming a core offshore vendor governance question.
AI adoption inside engineering teams moved faster than procurement did
The widespread adoption of AI coding tools by software engineers has been one of the quieter but more significant shifts in how software is built. Engineers adopt these tools individually and enthusiastically, for the same reason any professional adopts something that makes their work faster and better. Procurement processes, vendor assessments, and security reviews were largely designed before these tools existed at scale, and most have not yet caught up.
Recent research puts the gap in concrete terms. The Josys 2025 Shadow AI Report, which surveyed 500 Australian technology decision makers, found that 70 per cent of organisations have moderate-to-no visibility into what AI tools are being used, and more than one in three Australian professionals regularly upload sensitive company data to AI platforms without formal oversight. These figures describe behaviour inside organisations. Applied to vendor engineering teams building your systems, the dynamics are similar but the visibility is lower and the correction mechanisms are fewer. That creates a specific offshore vendor governance gap when AI tooling is adopted outside agreed client controls.
Offshore vendor governance and the visibility gap
In a well-governed offshore engagement, the standards applied to the vendor team are defined explicitly: security requirements are documented, tooling is agreed, and the client has meaningful oversight of how the team operates. Effective offshore vendor governance depends on those standards being explicit rather than assumed. That structure requires deliberate effort to establish, and it requires the right questions to be asked before the engagement begins.
Vendor contracts, even thorough ones, rarely address specifically which AI tools individual engineers may use in their development environments. Standard non-disclosure agreements were written for a world where the main risk was a developer copying code to a personal device. The scenario where a developer runs client architecture through a third-party AI model introduces a different category of exposure, one that sits below the threshold most existing agreements were designed to address.
Distance compounds this. The feedback loops that might surface a governance gap in a co-located team are naturally reduced across time zones and organisational boundaries. An issue that would be visible and correctable early in a domestic engagement can go unnoticed for considerably longer in an offshore vendor relationship.
For organisations building a longer-term capability, these controls should be designed into the dedicated offshore development center from the outset.
Where regulation is heading
Australia’s regulatory environment is converging on this question. The National AI Centre’s guidance calls for organisations to maintain a register of AI systems in use, explicitly including vendor-supplied tools. For APRA-regulated entities, CPS 230 already extends third-party governance obligations to technology service providers. From December 2026, Privacy Act amendments will require transparency around automated decision-making in client-facing systems.
Organisations that have not yet addressed AI tool governance with their vendors are accumulating an exposure the regulatory environment is increasingly likely to surface. As expectations tighten, offshore vendor governance will increasingly need to account for AI tooling alongside security, access controls, and third-party risk.
Four questions worth raising with every vendor engineering team
A practical offshore vendor governance approach does not need to be complex. Four questions cover the material ground:
- Which AI tools are your engineers using on client code?
- What certification or governance standard applies to that use?
- Is client code processed exclusively within client-approved environments?
- Is security compliance built into the engagement from the start?
A vendor that cannot answer the first question specifically does not have the internal visibility to govern it. The second question matters because individual engineers adopting tools without a shared, externally validated standard produces inconsistent practice with no audit trail the client can rely on. The third addresses IP exposure directly: most standard NDAs were not written for AI tools that process code through external inference endpoints. The fourth distinguishes vendors who have designed governance in from those who treat it as a retrospective audit.
Vendors that can answer all four clearly, and demonstrate it through external certification, ISO 27001-certified operations, and documented AI tooling policies, are operating at the standard that due diligence and regulatory expectations are converging on. These controls are increasingly becoming part of mature offshore vendor governance as AI becomes embedded in software development workflows.
Beyond engineering controls, the broader challenge is how AI moves from technical output into governed enterprise workflow, where outputs still need to be reviewed, challenged and acted on.
Raising the question
Australian technology leaders are thoughtful about vendor risk. The gap identified here is specific: vendor assessments rarely cover which AI tools individual engineers are using on client code, and most offshore vendor contracts were not written to address it.
For technology leaders with offshore engineering vendors already engaged, asking the four questions above surfaces any gap while it is still manageable. For organisations reviewing offshore vendor governance, these questions provide a practical way to test whether AI use is visible, controlled, and aligned with client expectations.
CBTW’s engineering teams operate at this standard: more than 330 APAC engineers completing Anthropic’s Claude Code certification, ISO 27001-certified operations, and a documented policy requiring client code to be processed exclusively within client-approved environments.
