radar-beta
title CloudCore AI-readiness (current vs pilot-ready)
axis data["Data"], platform["Platform"], talent["Talent"], governance["Governance"], infra["Infrastructure"]
curve{Current state: [3, 3, 1.5, 2.5, 4]}
curve{Pilot-ready target: [4, 4, 3, 4, 4]}
max 5
Technology Landscape & AI-Readiness Gap
ISYS6020 — can we execute?
The opportunity pipeline answers “what could we do?” and the cost–benefit answers “is it worth it?”. This page answers the third question a board will ask before approving capital: do we actually have the capability to deliver it?
It maps directly to the five AI-readiness dimensions the CEO’s board memo (DOC-EXEC-012) asked an external assessor to grade — leadership & strategy, data, talent, technology, and culture — compressed here into the four dimensions that determine execution risk: data, platform, talent, governance.
1. CloudCore’s current stack
Before assessing readiness, an honest picture of what exists today.
Products & service lines. Three named products — DataVault (object storage & backup), Analytics Pro (BI / reporting) and CloudSync (file sync & share) — sold across three service lines: Cloud Hosting, Managed Services and Security & Compliance. DataVault is the revenue anchor (~$18.2M of ~$42M tracked in data/cloudcore_sales.csv).
Infrastructure. Two sites: a primary data centre in Perth (4 Millrose Drive, Malaga WA 6090) and a Sydney disaster-recovery site (Level 12, 100 Harris Street, Pyrmont NSW 2009). Australian sovereign hosting is itself a marketable asset for AI workloads with data-residency obligations.
Data assets. Seven governed datasets in data/: cloudcore_customers.csv (400 clients with MRR, churn label), cloudcore_sales.csv (180 quarterly records), cloudcore_support_tickets.csv (400 tickets with free-text), cloudcore_reviews.csv (250 reviews with free-text), plus budget_2026.csv, cost_analysis_2026.csv and financial_forecast_2026.csv (the latter carrying explicit breach-impact and remediation-spend columns).
Governance fabric. A library of 31 policies (docs/policies/), a risk register, an ISMS, framework mappings (NIST, ISO 27001, HIPAA, GDPR) and a defined document-numbering scheme. CloudCore is pursuing ISO 27001 certification.
People. Roughly 47 staff across engineering, IT/security, sales, operations and corporate functions under a CEO, CFO, CIO and COO (see the org chart).
2. AI-readiness assessment
Each dimension is rated on a four-point maturity scale and scored against a “ready to pilot” threshold — the minimum needed to deliver the opportunities in the pipeline without the organisational unreadiness the CEO warned against.
| Rating | Meaning |
|---|---|
| 🟢 Established | Sufficient to pilot today |
| 🟡 Developing | Usable with workaround or scoped pilot |
| 🔴 Nascent | Blocks delivery; remediate first |
2.1 Data — 🟡 Developing
Strengths. The customer dataset is unusually AI-friendly: a clean schema with a labelled churn_flag, MRR, tenure, satisfaction and support load — a supervised-learning problem that is already “model-shaped”. Free-text fields in the support and review datasets open NLP use-cases (triage, sentiment). The customer figures reconcile to company-level revenue (400 × ~$9,858 MRR × 12 ≈ $47M), so the data is plausibly real, not a toy.
Gaps.
- No single source of truth. Customer, sales, support and review data live in separate files with no published join key beyond
customer_id— fine for a teaching dataset, a friction point in production. - No infrastructure telemetry. The predictive-maintenance and capacity-forecasting opportunities (pipeline §3.5, §3.7) are blocked because there is no machine-readable utilisation, capacity or hardware-health dataset.
- Short horizons & coarse granularity. Financial datasets are quarterly/annual with few categories — adequate for cost-forecasting at a rough grade, not for precise margin modelling.
- Post-breach data-quality questions. The September 2025 breach (detected 12-09-2025, ~250,000 records) is itself a data-integrity finding: a company that could not detect unauthorised access for an extended period cannot yet assert its training data is clean and untampered.
To clear the “ready” bar: a governed data warehouse with a conformed customer_id, a data-quality SLA, and a decision on which datasets may train models.
2.2 Platform — 🟡 Developing
Strengths. Two owned data centres with sovereign AU residency give CloudCore somewhere to host inference and vector stores inside its own controls — a genuine advantage for governance-sensitive AI (see the RAG decision in cost–benefit §5). The product stack (DataVault storage, Analytics Pro BI) provides building blocks.
Gaps.
- No MLOps platform. There is no model registry, feature store, experiment tracking or monitoring pipeline. Every opportunity in the pipeline assumes one exists.
- No vector search / retrieval infrastructure for RAG.
- No CI/CD for models. Code deployment maturity is unclear; model deployment maturity is effectively zero.
- Log centralisation is incomplete. The log-anomaly opportunity (pipeline §3.5) is blocked until logs are aggregated, retained and correlatable — a gap the breach already exposed.
To clear the “ready” bar: a minimal MLOps stack (experiment tracking + registry + monitoring), a vector store, and centralised logging.
2.3 Talent — 🔴 Nascent
Strengths. A capable IT/security team running two data centres and an ISMS — strong on operations and security, which is exactly the discipline AI governance needs.
Gaps.
- No dedicated data science / ML engineering. The board memo states this plainly: “Our IT team is strong but lacks data science expertise.” None of the build paths in the cost–benefit can be delivered without acquiring or contracting this skill.
- No AI product / programme management. Delivering a churn model with a retention workflow (the gating dependency in cost–benefit §4) is a cross-functional programme, not a model.
- Thin bench. At ~47 staff, a single key-person dependency in any new AI role is a material continuity risk.
To clear the “ready” bar: at least one in-house or contracted ML engineer, an AI product owner, and a made-explicit training plan for existing staff (data literacy, prompt evaluation, responsible-AI basics).
2.4 Governance — 🟡 Developing (with a public/private credibility gap)
Strengths. A 31-policy library, an ISMS, framework mappings and a risk register are a stronger starting point than most SMEs. A model-risk / security-architecture policy already exists.
Gaps.
- The ISO 27001 overclaim. The public site states CloudCore is “ISO 27001 certified” while internally the company is only pursuing certification. This is a deliberate inconsistency — but for an AI strategy it is a credibility finding: a board cannot approve AI spend on the strength of controls that are marketed but not yet achieved.
- No AI-specific governance. No model-risk policy tuned for ML, no human-in-the-loop standard, no evaluation/acceptance criteria for AI outputs, no AI incident process. See the governance considerations page.
- Privacy posture under load. The breach tested — and found wanting — the controls that the Australian Privacy Principles require. AI that processes personal data inherits this exposure.
- No responsible-AI roles. No one owns “is this AI decision fair, lawful and explainable?”
To clear the “ready” bar: close the ISO gap honestly, stand up an AI-use approval process with human-in-the-loop requirements, and assign model-risk ownership.
3. Maturity at a glance
The gap is concentrated in talent (largest) and governance (highest-leverage to close), with data and platform at “usable for a scoped pilot”.
4. Prioritised remediation roadmap
Sequenced to unblock the highest-value opportunities first, not to achieve perfect readiness before starting.
| Priority | Action | Unblocks | Indicative effort |
|---|---|---|---|
| 1 | Stand up a minimal MLOps stack (tracking + registry + monitoring) on existing infrastructure | All build paths | 1–2 months, ~$40–60k |
| 2 | Hire/contract one ML engineer + name an AI product owner | Churn model, RAG, triage build option | 8–12 weeks to onboard |
| 3 | Conformed data warehouse with customer_id as join key + data-quality SLA |
Churn, lead scoring, cost forecasting | 2–3 months |
| 4 | Centralise & retain logs | Log-anomaly detection | 2–4 months |
| 5 | AI-use governance pack: model-risk policy, human-in-the-loop standard, approval process | All client-facing AI; closes the ISO credibility gap | 1–2 months |
| 6 | Pursue ISO 27001 to certified (honestly) | Compliance-evidence automation; marketing claim becomes true | 6–12 months |
| 7 | Instrument infrastructure telemetry | Predictive maintenance, capacity forecasting | 3–6 months |
The sequencing logic. Items 1–2 and 5 are enablers — they make every subsequent opportunity cheaper and safer. Items 3–4 and 7 unblock specific opportunities. Item 6 is strategic credibility. A board that funds only items 1, 2 and 5 (~$150–200k plus one hire) has bought the option to pursue the whole pipeline; everything else is pay-as-you-go per opportunity.
5. The honest conclusion
CloudCore is not AI-ready in aggregate, but is ready for a scoped pilot. The data for churn prediction and support triage is good enough today; the platform can host a buy-path triage tool today; and the governance fabric is strong enough to run an internal RAG pilot today — provided the human-in-the-loop and evaluation disciplines are added.
What is not ready is the talent to build, and the AI-specific governance to ship anything client-facing. The strategy that survives this analysis is therefore a staged one: start with the buy-path support triage and the internal RAG build (both governance-low, both build the muscle), use them to fund and de-risk the ML hire and the MLOps stack, and only then attempt the client-touching churn model and the compliance automation.
This is precisely the “honest assessment of where we actually stand” the board memo asked for — and it changes the answer to the cost–benefit from “all three, now” to “two, now; one, after we hire”.