DATA, AI & AUTOMATION
Moving from AI pilots to operational deployment
Most AI pilots prove that a model can work. Few prove that an organisation can run it. What separates the pilots that reach production from the ones that stall — and how to design for deployment from day one.
The pilot trap
Organisations across Australia have run AI pilots: document classification, demand forecasting, defect detection, generative AI assistants for staff. Many produced impressive demonstrations. Far fewer are running in production with measurable benefit.
The evidence is consistent:
- In 2024, Gartner forecast that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025, citing poor data quality, inadequate risk controls, escalating costs and unclear business value.
- A preliminary 2025 report associated with MIT Project NANDA — based on reviews of public initiatives, 52 interviews and a survey of 153 senior leaders — reported that most organisations in its sample could not identify measurable P&L impact from generative-AI initiatives. Its widely repeated 95% figure is directional rather than a controlled failure rate: the report was preliminary, survey-based and not peer reviewed. It highlighted workflow integration, organisational learning and operating-model fit as recurring differences between stalled and successful initiatives.
Why pilots stall
| Pilot conditions | Production reality |
|---|---|
| Curated, one-off data extract | Live, messy, changing data feeds |
| Data scientist runs the model | Operations staff rely on it without seeing inside |
| Success = accuracy on a test set | Success = a better business outcome, measured |
| Risk accepted informally | Privacy, security, safety and legal sign-off required |
| Runs on a laptop or sandbox | Integrated with core systems, monitored, supported 24/7 |
| Sponsor is enthusiastic | Budget owner needs a business case and a run cost |
None of these are exotic. They are simply deferred — and a pilot designed without them has to be largely rebuilt before it can go live.
Five gates to design for from day one
1. Value — a decision, a baseline and a measure
Define the decision or process the AI will change, the current baseline (time, cost, error rate, risk) and how improvement will be measured in production. If the benefit cannot be measured, it cannot be defended at budget time.
2. Data — reliable pipelines, not extracts
Production AI needs repeatable data flows with quality checks, lineage and ownership. Plan early for data drift: the world changes, and a model trained on last year's data can degrade silently unless monitored.
3. Risk — governance proportional to consequence
Classify the use case by impact. Australia's Guidance for AI Adoption (National AI Centre, October 2025) streamlined the earlier Voluntary AI Safety Standard into six essential practices:
- Decide who is accountable
- Understand impacts and plan accordingly
- Measure and manage risks
- Share essential information
- Test and monitor
- Maintain human control
For non-corporate Commonwealth entities, subject to the policy's scope and exclusions, the Digital Transformation Agency's Policy for responsible use of AI in government, Version 2.0 requires accountable officials, transparency statements, strategic governance and use-case impact assessment. ISO/IEC 42001:2023 provides a certifiable AI management system, and ISO/IEC 23894:2023 offers AI-specific risk-management guidance aligned to ISO 31000.
4. Integration — inside the workflow, not beside it
AI that requires staff to open a separate tool, copy outputs and paste them elsewhere will be abandoned. Outputs must appear where work happens — the EAM, the case-management system, the inspection app — with clear indication of confidence and an easy way to override.
5. Ownership — someone runs it after the project ends
Name the business owner, the technical owner and the support model. Agree who monitors performance, who retrains, who handles incidents and who decides to retire the model. Without this, AI becomes orphaned the day the project team disbands.
The human side is the hardest
Deployment changes jobs. Staff need to understand what the system does, when to trust it and when to challenge it. Research on automation shows a well-known risk of automation bias — people over-relying on automated advice, especially under time pressure (Parasuraman & Manzey, 2010). Good deployment designs for appropriate trust: explaining outputs, surfacing uncertainty and keeping humans meaningfully in control of consequential decisions.
A practical checklist before scaling
- A measured baseline and target benefit agreed with the budget owner
- Production data pipeline with quality checks and drift monitoring
- Risk assessment and sign-off proportional to impact
- Integration into the system where the decision is made
- Human oversight and override defined for consequential outputs
- Named business and technical owners and a support model
- Run-cost estimate (compute, licences, people) within the business case
- Post-deployment review scheduled at 3 and 12 months
Frame
Start with the operational decision and the production constraints, before the model.
Equip
Build the pilot on production-like data and architecture so it can scale without a rebuild.
Validate
Specialists test performance, risk and usability with the people who will use it.
Deliver
Transition into operations with governance, monitoring, training and clear ownership in place.
A successful pilot is one designed to be deployed. Everything else is a demonstration.
References
- Gartner (2024), forecast on generative-AI projects after proof of concept.
- MIT Project NANDA (2025), The GenAI Divide: State of AI in Business 2025, preliminary report.
- Australian Government, Guidance for AI Adoption.
- Digital Transformation Agency, Policy for responsible use of AI in government, Version 2.0.
- ISO, ISO/IEC 42001:2023 — AI management systems and ISO/IEC 23894:2023 — AI risk management.
- Parasuraman and Manzey (2010), Complacency and bias in human use of automation, Human Factors 52(3), 381–410.