Australia puts AI policy at the centre of government

Australia’s new AI machinery

Australia has moved AI policy into the centre of government—and put the power, water and land used by data centres squarely on the policy agenda.

On 15 July, the federal government established an Office of AI inside the Department of the Prime Minister and Cabinet. It’s effective immediately, and the location is significant: PM&C sits across portfolios, so the office is positioned to coordinate work that reaches well beyond the technology sector.

The government also committed to legislating national standards for AI training and large data centres. The proposed obligations would cover new electricity supply, the cost of connecting facilities to the grid, water efficiency and decisions about where data centres can be built.

There’s a separate commitment to protect creators’ control over the use of their work in AI training. That could eventually affect the consent or licensing arrangements used by model developers, although the announcement doesn’t settle what those arrangements will be.

The distinction between a commitment and a rule is important here. The material supplied for this episode includes no draft legislation, implementation date or compliance threshold. Companies don’t have a new checklist to follow yet, and creators haven’t been given a defined new right they can exercise today.

Still, the policy framing has changed. Australia is treating AI infrastructure as an electricity, water and planning issue, not only a question of software safety or economic opportunity. For operators, the unresolved issue is who will pay for the generation and grid capacity demanded by large facilities. For creators and model companies, it’s how control over training material will work in practice.

Those details will determine whether the standards materially shift costs and behaviour. For now, the Office of AI is real; most of the obligations it may coordinate remain proposals.

Thinking Machines releases Inkling

From government machinery to a new model supplier: Mira Murati’s Thinking Machines Lab released its first foundation model on 15 July.

It’s called Inkling. The company describes it as a 975-billion-parameter multimodal model supporting text, images and audio. It says organisations can download the model weights and customise the model using its Tinker training platform. Axios independently reported the release.

Open weights can give organisations more control than access through a hosted interface alone. Depending on the licence and technical requirements, teams may be able to customise a model, inspect its behaviour more closely and choose where it runs. That can matter for specialised workloads or sensitive data.

But the impressive-sounding parameter count tells us very little on its own about whether Inkling is useful or economical. The claims about its specifications, intended enterprise role and customisation come from Thinking Machines Lab. The supplied evidence includes no independent technical evaluation or deployment-cost information.

There are also several practical unknowns: the precise licence, hardware requirements, inference cost and performance outside demonstrations. A model with downloadable weights can still be prohibitively expensive to operate, and an open-weight release isn’t necessarily open in every sense that developers care about.

So Inkling adds a potentially important supplier to the foundation-model market, especially for organisations wanting more deployment control. Its real position will become clearer when independent testers can examine it and prospective users can calculate the full cost of running it.

India backs the chip supply chain

Meanwhile, India has approved an industrial programme that reaches across far more than chip fabrication alone.

On 15 July, India’s Cabinet approved Semicon 2.0 with an outlay of ₹1,27,500 crore—that’s ₹1.275 trillion. According to Indian government sources, the programme has six pillars: chip design; semiconductor equipment and materials; additional fabrication facilities; packaging and testing; research; and workforce development.

That breadth is worth noticing. A semiconductor industry needs specialist chemicals, manufacturing equipment, packaging capacity, reliable infrastructure and skilled workers, as well as the fabrication plants that tend to attract the headlines. Weakness in any one layer can constrain the rest.

India is targeting several points where global supply remains concentrated in a small number of countries. Building domestic capability across those layers could reduce strategic exposure and give international manufacturers another production base. But an approved funding envelope is the start of an industrial policy, not proof that manufacturing capacity now exists.

Results will depend on which projects receive support, how much private capital follows, whether construction stays on track and whether suppliers and specialist workers can be developed at the required scale. Semiconductor projects are technically demanding and take time to move from an announcement to dependable output.

Semicon 2.0 is therefore best read as a broad attempt to build an ecosystem. Its eventual weight in the global chip market will be measured in operating facilities, supplier depth and production—not the size of the allocation by itself.

Google closes a cloud isolation flaw

A more immediate issue emerged in Google Cloud, although Google says the underlying vulnerability has already been fixed.

In a bulletin disclosed on 13 July, Google classified CVE-2026-14934—also identified as GCP-2026-047—as critical. According to the company, a missing authorisation check during repository creation in BigQuery, Dataform and Colab Enterprise could have let an authenticated attacker escalate privileges and take control of another tenant’s repository.

A tenant is essentially one customer environment within a shared cloud service. Cross-tenant vulnerabilities are especially serious because cloud customers rely on the provider to keep separate organisations isolated, even when their workloads use the same underlying platform.

Google says it applied mitigations across all affected services and customers don’t need to take action. There’s no evidence in the supplied material establishing whether anyone exploited the flaw before it was remediated, so it would be wrong to infer that customer repositories were compromised.

For security teams, though, ‘no action required’ has a fairly specific meaning: Google handled the technical remediation. It doesn’t necessarily remove an organisation’s own audit, governance or incident-review responsibilities. Teams using the affected products may still want to record the bulletin, identify their exposure window and decide whether their internal policies require any review.

The useful conclusion is measured rather than dramatic. Google reports the vulnerability is closed, while the public evidence available here doesn’t answer whether it was exploited.

The UK reopens the data-rule debate

Over in the UK, the question is less about a known software flaw and more about whether existing data rules fit an AI-heavy economy.

On 15 July, the Department for Science, Innovation and Technology opened a call for evidence on how regulation of personal and non-personal data interacts with AI and other data-intensive technologies. Submissions close on 9 September 2026.

The consultation asks whether regulatory uncertainty or friction should be addressed through clearer guidance, targeted legislative amendments or more fundamental reform. That range leaves open everything from explaining the current system more clearly to reconsidering parts of the legal framework.

Access to data affects model training, evaluation and commercial deployment. Uncertainty can also impose a cost: organisations may avoid useful projects because the legal boundary is unclear, while overly permissive access can weaken privacy, ownership and public trust.

No UK law changed on 15 July. Businesses shouldn’t treat the consultation as a new permission to use data or a new compliance requirement. Its immediate significance is that the government is collecting evidence about where current rules create problems and how extensive any response should be.

The eventual consequences will depend on proposals that haven’t yet been written. For organisations with direct experience of regulatory friction, the firm date to note is the 9 September submission deadline.

Lambda lets customers hold the code

AWS has also changed a less glamorous but very practical part of serverless deployment: where Lambda code packages live.

As of 15 July, AWS Lambda functions and layers can reference deployment packages held directly in customer-owned Amazon S3 buckets. AWS says this removes the effective ceiling imposed by Lambda-managed code storage for deployments using the new approach, avoids an intermediate copying step and lets the customer’s bucket remain the source of truth.

AWS has separately increased the default Lambda-managed storage allowance from 75 gigabytes to 300 gigabytes per account and region. Teams can therefore stay with managed storage and gain more room, or use the S3-backed approach when they want direct control over larger collections of artefacts.

For organisations running many functions and layers, this could simplify deployment pipelines and make artefact provenance easier to manage. Retention rules and access policies can be centred on the bucket already used by the organisation, rather than a second managed copy.

That control also moves responsibility towards the customer. A deployment now depends on the bucket’s availability, permissions, lifecycle configuration and security. An aggressive deletion rule, a broken access policy or an incorrectly protected bucket could create operational or security problems.

The feature is most useful for teams already capable of treating S3 as production deployment infrastructure. The storage ceiling recedes, but sound artefact management becomes even more important.

What Changes for You

And for development teams, one new GitHub preview brings security findings into a place engineers already spend plenty of time: the pull request.

GitHub Code Scanning can now run an AI detection engine when a pull request is opened or updated, then show the results within that pull request. GitHub says the engine can detect some issues in languages and frameworks that CodeQL doesn’t currently cover, and the findings are explicitly labelled as AI-generated.

For eligible teams, that means a possible vulnerability can surface during ordinary code review instead of waiting for a separate security process. The public preview is available on GitHub.com to development teams using GitHub Code Security or Advanced Security, CodeQL default setup, and the required Copilot licensing or credits.

There are two important limits. Access depends on paid GitHub security and Copilot products, so many smaller teams and open-source projects won’t have it under their existing plans. More importantly, the AI findings are informational during the preview and can’t block a merge.

Treat them as leads for investigation, not proof that code is vulnerable—and not a replacement for CodeQL, testing or human security review. Used with that discipline, the feature can put an extra signal in front of reviewers at the moment they can still change the code.