Token cost management is an important part of implementing AI systems within a business, and several viable strategies have emerged to help organisations keep expenses within budget. While these strategies are effective, they often come with legal implications which may easily be overlooked, writes Corrs Chambers Westgarth partners James North and Arvind Dixit.
As superannuation trustees and financial services organisations move AI from pilots into core workflows, the cost of running these tools has become a significant concern. Organisations are looking to contain spend, including by orchestrating workloads across multiple AI models, deploying cheaper open-weight models on their own infrastructure and implementing best practice procurement practices and contract clauses.
These strategies carry legal and regulatory risks that are easily overlooked when the focus is on cost savings.
How enterprise AI is priced
Unlike conventional software licensed for fixed fees, enterprise AI is usually charged per token (the unit of text a model reads or generates) – the more an organisation uses AI, the more it pays.
AI procurement is therefore less a licensing decision than an ongoing exercise in understanding consumption, much like managing a utility bill.
Although token prices continue to fall, total AI spend continues to rise. McKinsey reports that enterprise spending on large language models tripled by the end of 2025, and its May 2026 survey found 93 per cent of organisations exceeded their annual AI budgets. The issue is coming to a head as organisations move away from ‘all you can eat’ subscriptions for basic human-prompted AI services, AI developers reprice their services, and agentic tools multiply token consumption.
AI agents often run autonomously 24/7, for example a cyber defence agent continuously monitoring and responding to suspicious network traffic, making their consumption harder to oversee.
Cost management strategies
Three strategies to control consumption costs are gaining traction:
- Orchestration: Orchestration tools match a model to each request, using cheaper models for routine tasks and escalating to more capable models only where needed, reflecting a growing consensus that not every task requires “frontier intelligence”. Orchestration reduces provider concentration risk and can reduce cost but adds organisation and procurement complexity.
- Procurement and contract controls: Procurement terms and organisational processes are being utilised to manage token costs, rather than relying on internal and technical tools alone.
- Open-weight models: Unlike a closed model (e.g. Claude, ChatGPT), which is hosted by a third party and charged per token, open-weight models run on an organisation’s own infrastructure or cloud computing instance. The organisation instead bears the cost of the computing infrastructure to run the model but avoids token costs altogether. An open-weight model can also be modified to suit the organisations unique business objectives and corporate values.
Legal and regulatory concerns
At face value, each strategy is an attractive way to manage growing AI costs. However, each raises legal and regulatory issues that should carry real weight in decision-making.
Orchestration
An orchestration strategy routes requests across different AI providers and models – each with its own terms, data handling and hosting locations. This raises issues under CPS 230 (Operational Risk Management), which requires APRA-regulated entities to identify critical operations, set disruption tolerances and manage material service providers through formal agreements.
Many AI providers are likely to be material service providers under CPS 230, so regulated entities must assess each provider used in an orchestration arrangement, define the data that may be routed to it (particularly personal information of members) and ensure contracts address data use, retention, processing location and exit without loss of access to data.
Orchestration also presents business continuity risks, as losing access to any model in the arrangement may disrupt the critical operations that depend on it. APRA’s June 2026 geopolitical letter expects contingency plans for losing access to offshore dependencies, a real risk given that, earlier this year, the US Government imposed (and later lifted) export licensing requirements under the Export Administration Regulations restricting access to Anthropic’s models. The Remote Access Security Act, now before Congress, proposes to extend US export controls to remote access of US technology through cloud services, potentially including AI models used by Australian entities. Regulated entities should map which models support critical operations, test fallbacks and, where routing affects member outcomes, record which model handled a request so decisions can be explained to regulators.
Procurement and contract controls
Contract terms, such as seat-based or capped pricing, committed-spend arrangements, and discounted batch processing for non-urgent work, can help manage unpredictable consumption pricing. However, these arrangements should be negotiated with CPS 230 in mind, as spend commitments can create lock-in that cuts across exit and transition planning. Commitments should therefore be balanced against termination and switching rights. Usage reporting rights (such as token trackers, consumption analytics, and alerts when spend exceeds thresholds) should also be contractual, so spend visibility does not depend on the provider’s discretion.
Open-weight models
Open-weight models offer the largest potential savings but present the most significant legal and regulatory challenges.
Unlike closed models, where the provider monitors for vulnerabilities, patches the model and gives contractual assurances, an open-weight model is typically provided ‘as is’ and cannot be updated by the developer once downloaded. Responsibility for security shifts to the entity, which may be challenging under CPS 234 (Information Security) as regulated entities must maintain an information security capability commensurate with the threats they face – something they may be less equipped to do than large-scale AI providers.
Model files can also carry malicious code, and the Australian Signals Directorate has warned of “threats like poisoned data, backdoors and malicious code” in pre-trained models. Entities should treat models as information assets, verify their integrity, track vulnerabilities and be able to respond to incidents.
Explainability is another risk, as it is harder to defend a model’s use to ASIC and APRA where its training data, guardrails and biases are not transparent.
APRA-regulated entities face a threshold question of whether open-weight models should be used at all and, if so, what governance controls (e.g. independent testing, red-teaming, provenance verification and segregation from critical systems) would satisfy regulators. Those controls carry their own cost, which should be factored into comparisons with closed models.
Conclusion
Cheaper models need not be avoided, but price and technical capability should not be the only determining factors, as the cheapest option may create legal and regulatory exposure that outweighs savings. Several key takeaways emerge:
- Build legal and regulatory questions into evaluation frameworks: These decisions directly engage CPS 230 and CPS 234, so legal and regulatory questions belong in the initial evaluation, not an afterthought once the commercial decision is made.
- Negotiate cost controls: Pricing structures and reporting rights should be negotiated with vendors as part of cost management, not left to the organisation’s internal cost management tools alone.
- Secure continuity: Geopolitical and export control risks mean model access cannot be assumed, so dependencies should be mapped, fallbacks tested and contracts should preserve the ability to exit or switch.
- Recognise that open-weight models shift risks to the deployer: Because these models are typically provided “as is”, organisations should consider information security, model integrity and explainability implications before deployment and implement controls commensurate with the use case’s sensitivity.
- Align compliance workstreams: Organisations conducting CPS 230 supplier mapping should align this exercise with the automated decision-making mapping needed to meet the new Privacy Act 1988 (Cth) transparency obligations commencing on 10 December 2026, to avoid duplicating efforts.
