Library · Data Practice OS
AI readiness assessment
Reference guide · Published · Source reviewed
The answer: readiness belongs to one named AI use in one business process, not to a platform or an organisation. Score the observable controls from 0 to 4 to get a maturity profile. Then decide readiness separately, through five gates. A high score never makes up for a failed gate.
Source and status. AI-Ready Data and Context Lifecycle: Taxonomy and Assessment Model, draft, revised 4 Nov 2026. This page adopts its method as the practice's proposed assessment approach. It is not an agreed decision. The control IDs, lifecycle stages, gate links and suggested tests below are this practice's reading of the draft's prose. The consultancy packaging in the draft (fixed price, retainer) is not adopted. Neither is its private-sector classification scheme: the organisation keeps its mandated classification scheme (Governance, security and trust).
Use What AI-ready means for a five-minute triage of a dataset. Use this page when an AI use is heading for a pilot or production, and score it in AI readiness scorecard (workbook v2).
1. Fix the scope first
Agree the outcome, users, process stages, source systems, processing environment and the consequences of error before anyone scans anything. The scope and its version go on the scorecard. Change the scope and the score is no longer comparable.
| Element | What to record |
|---|---|
| Boundary | CRM, ERP, workflow and knowledge systems, tables, documents, email, external services and derived assets, including sources outside the warehouse or lakehouse. Record exclusions and inaccessible systems. Tier 1 means the dependencies whose failure would compromise the outcome or a mandatory control |
| Required context | For each decision or task: the required facts, definitions, relationships, rule versions, process state and approval authority. Map each to its authoritative source, access method, freshness limit and fallback when it is unavailable or conflicting |
| Acceptance | Measurable thresholds for quality, freshness, task performance and access isolation. The business owner, data owner and approval authority. Licensing, contractual, privacy and jurisdictional obligations |
| Evidence plan | Sampling by source, sensitivity and important user groups; the observation period; access to logs, policies and representative content. Metadata-only access limits what the assessment can conclude |
The intake fields for this live in AI use case intake and risk triage (Part E).
2. Four lifecycle stages
Every control records its stage and its owner.
- Discover, connect and classify
- Govern and quality-gate
- Prepare and assemble context: features, retrieval, rules and live facts
- Monitor and retire
3. The taxonomy: three layers
- Layer 1: five dimensions, 20 points each: Discoverability, Quality, Governance, AI fitness, Lifecycle discipline.
- Layer 2: 20 capabilities, four per dimension.
- Layer 3: scored controls, each a single testable requirement. Only Layer 3 is scored; Layers 1 and 2 roll up from it.
The outcome a control requires stays the same whatever the estate. A small team may evidence it through a documented process that demonstrably works. A large estate may need automation to meet the same coverage, frequency and response requirements.
Profile codes: Baseline always applies. The other codes apply only when that use profile is in scope (section 4). The Gate column names the readiness gate the control evidences (section 5).
| ID | Capability | Control | Stage | Profile | Gate |
|---|---|---|---|---|---|
| Discoverability | |||||
| DIS-CAT-01 | Cataloguing | Assets, APIs, knowledge bases, glossaries and rule repositories in scope are inventoried with purpose, source, version and access route. | 1 | Baseline | |
| DIS-CAT-02 | Cataloguing | Inventory coverage is measured against the use-case dependencies, including sources outside the analytics platforms. | 1 | Baseline | |
| DIS-OWN-01 | Ownership | Each in-scope data asset, knowledge source, definition, rule and business process has a named owner. | 1 | Baseline | |
| DIS-OWN-02 | Ownership | Owner contacts and decision rights resolve from the inventory, and owners confirm them. | 1 | Baseline | |
| DIS-LIN-01 | Lineage | Tier 1 sources and transformations are traced through assembled context to decisions and actions. | 2 | Baseline | |
| DIS-LIN-02 | Lineage | External handoffs and lineage capture gaps are recorded explicitly. | 2 | Baseline | |
| DIS-SEM-01 | Search and semantics | Definitions, units, entity identifiers and relationships are mapped across systems. | 1 | Baseline | |
| DIS-SEM-02 | Search and semantics | Source precedence is agreed for each required fact. | 3 | Baseline | Context sufficiency |
| DIS-SEM-03 | Search and semantics | Approved facts are distinguished from drafts, inferred relationships and superseded knowledge. | 3 | Baseline | |
| Quality | |||||
| QUA-CMP-01 | Completeness and validity | Critical fields and the required decision context are checked for completeness and accuracy against authoritative evidence. | 2 | Baseline | |
| QUA-CMP-02 | Completeness and validity | Missing prerequisites block the decision or trigger an approved escalation. | 3 | Baseline | Context sufficiency |
| QUA-CMP-03 | Completeness and validity | Mandatory data failures block promotion or enter quarantine. | 2 | Baseline | Fitness for purpose |
| QUA-FRS-01 | Freshness | Freshness limits are set for each source, rule and decision. | 2 | Baseline | |
| QUA-FRS-02 | Freshness | Live-query and index refresh failures, effective dates and event ordering are checked. | 4 | Baseline | |
| QUA-FRS-03 | Freshness | Volatile facts are revalidated before action; stale or unavailable context triggers the agreed stop, qualify or escalate behaviour. | 3 | Baseline | Context sufficiency |
| QUA-CON-01 | Consistency | Keys, units and entity relationships are reconciled across systems. | 2 | Baseline | |
| QUA-CON-02 | Consistency | Facts and rules are confirmed to apply to the same customer, product, jurisdiction and time. | 3 | Baseline | |
| QUA-CON-03 | Consistency | Document extraction preserves tables and context; OCR errors and unresolved contradictions are measured. | 3 | RAG | |
| QUA-OPS-01 | Control operation | Checks run at the required frequency. | 4 | Baseline | |
| QUA-OPS-02 | Control operation | There is evidence of the actual response to check failures, not only that a check exists. | 4 | Baseline | Operational control |
| Governance | |||||
| GOV-CLS-01 | Classification | Security classification, privacy and content tags, and AI permissions are recorded as separate attributes. | 1 | Baseline | Rights and handling |
| GOV-CLS-02 | Classification | Classification coverage and tag accuracy are measured by sampling assets, columns, records and documents, including missed sensitive content. | 1 | Baseline | |
| GOV-CLS-03 | Classification | Uncertain classifications are reviewed before use. | 2 | Baseline | |
| GOV-ACC-01 | Access and use rights | Least-privilege access is enforced across source systems, connectors and AI services. | 2 | Baseline | Access isolation |
| GOV-ACC-02 | Access and use rights | User and tenant isolation is tested, including through derived assets and outputs. | 2 | Baseline | Access isolation |
| GOV-ACC-03 | Access and use rights | Read, recommend, approve and execute permissions are separate. | 3 | Decision | Context sufficiency |
| GOV-ACC-04 | Access and use rights | Rule owners authorise business logic; data rights and provider handling cover the whole workflow. | 2 | Baseline | Rights and handling |
| GOV-PLN-01 | Lineage for governance | Restrictions follow transformations into features, chunks, embeddings, indexes, prompts, logs and outputs. | 3 | Baseline | Access isolation |
| GOV-PLN-02 | Lineage for governance | Policy changes and revocations reach consumers. | 4 | Baseline | Operational control |
| GOV-PLN-03 | Lineage for governance | Joins, inferred content and masking changes trigger reassessment where needed. | 2 | Baseline | |
| GOV-AUD-01 | Audit and review | Source identities, fact timestamps, policy and rule versions, process state, approvals and action outcomes are recorded under a retention policy. | 3 | Baseline | |
| GOV-AUD-02 | Audit and review | Exceptions and overrides are reviewed. | 4 | Baseline | |
| GOV-AUD-03 | Audit and review | Classification changes and inferred rules are approved by an authorised person before operational use. | 2 | Baseline | |
| AI fitness | |||||
| AIF-MLM-01 | Modelling for ML | Feature definitions and point-in-time correctness are verified. | 3 | ML | |
| AIF-MLM-02 | Modelling for ML | Population coverage, label quality, missingness and performance across important groups are assessed against the intended decision. | 3 | ML | Fitness for purpose |
| AIF-RET-01 | Retrieval and context readiness | Extraction and indexing preserve provenance and permissions. | 3 | RAG | Access isolation |
| AIF-RET-02 | Retrieval and context readiness | Retrieval, entity matching, live-source joins, source precedence and context selection are tested against representative tasks. | 3 | RAG, Decision | Fitness for purpose |
| AIF-RET-03 | Retrieval and context readiness | Tests include insufficient context, conflicting rules, malicious source instructions and appropriate abstention. | 3 | RAG, Decision | Context sufficiency |
| AIF-TRN-01 | Training data hygiene | Training, validation and test sets are reproducible and separated by entity and time. | 3 | Training | |
| AIF-TRN-02 | Training data hygiene | Labels and datasets are versioned; leakage and evaluation contamination are checked. | 3 | Training | |
| AIF-TRN-03 | Training data hygiene | Data rights cover the proposed training or fine-tuning use. | 1 | Training | Rights and handling |
| AIF-EVL-01 | Evaluation and decision lifecycle | Models, prompts, context assembly and evaluations are versioned. | 3 | Baseline | |
| AIF-EVL-02 | Evaluation and decision lifecycle | Complete process scenarios, exception paths and human handoffs are tested against approved outcomes. | 3 | Baseline | Fitness for purpose |
| AIF-EVL-03 | Evaluation and decision lifecycle | Deterministic rules are evaluated explicitly, and the facts and rule versions supporting each decision are recorded. | 3 | Baseline | |
| Lifecycle discipline | |||||
| LIF-RET-01 | Retention | Retention and legal-hold rules are declared for source and derived assets. | 4 | Baseline | |
| LIF-RET-02 | Retention | Deletion, correction and access revocation are tested through indexes, embeddings and caches. | 4 | Baseline | Operational control |
| LIF-RET-03 | Retention | Backup handling and restoration controls are documented; previously trained models have a separate impact decision. | 4 | Baseline | |
| LIF-ARC-01 | Archival and tiering | Storage tiers and archival schedules match access needs and retention obligations. | 4 | Baseline | |
| LIF-ARC-02 | Archival and tiering | Archived content cannot silently re-enter active retrieval. | 4 | Baseline | |
| LIF-CST-01 | Cost control | Storage, pipeline, indexing and inference costs are attributed to owners. | 4 | Baseline | |
| LIF-CST-02 | Cost control | Budgets, alerts and expected cost per use are recorded. | 4 | Baseline | |
| LIF-MON-01 | Monitoring and decommissioning | Source, API, ontology, policy and workflow changes trigger impact analysis and the affected scenario tests. | 4 | Baseline | Operational control |
| LIF-MON-02 | Monitoring and decommissioning | Drift and connector failures are monitored, with stop, rollback and revalidation actions assigned. | 4 | Baseline | Operational control |
| LIF-MON-03 | Monitoring and decommissioning | Dependent indexes, mappings, rules and access routes are retired with consumer notification. | 4 | Baseline |
4. Four axes select the controls
Four cross-cutting axes decide which controls are mandatory for which data and which use:
| Axis | What it captures | Typical treatment (Australian government example) |
|---|---|---|
| Classification | The security or business classification | The mandated scheme, for example OFFICIAL, OFFICIAL: Sensitive, PROTECTED in Australian government. Keep the scheme and the marking as metadata, and don't map them to private-sector labels (Governance, security and trust) |
| Privacy and obligations | Personal, health, payment and employee information, legal privilege, use and retention restrictions | Separate tags. In Australia, sensitive information is a defined subset of personal information. It is not a protective marking |
| AI use | Analytics, retrieval, ML, training, decision support and actions | Selects the use profiles below |
| Decision impact | Who relies on the output, the consequences of error, reversibility, human review | Higher impact needs stronger evidence and approval thresholds, even when the data is unclassified public information. Autonomous actions also need a separate system-level assessment |
Use profiles. Apply a common baseline (source access, ownership, provenance, semantics, classification, rights, quality and lifecycle) plus each relevant profile. Profiles are not cumulative: a RAG assistant doesn't inherit the ML controls. A combined workflow can need several profiles. Any baseline control that doesn't apply needs a recorded rationale.
| Profile | Additional evidence |
|---|---|
| Analytics and AI-assisted querying | Agreed metric definitions, correct joins and units, source accuracy, permission-aware queries |
| Predictive ML and features | Point-in-time correctness, feature definitions, population coverage, task performance across important groups |
| Retrieval (RAG) | Extraction quality, source and version provenance, retrieval and answer evaluation, current permissions, content-injection tests |
| Training and fine-tuning | Permitted training rights, label quality, versioned splits, leakage checks, held-out evaluation |
| Decision support and actions | Complete context, approved rules, current process state, delegated authority, exception handling, a decision-to-outcome trace |
AI permissions are a third record, separate from classification and privacy tags: which purposes, services and environments are approved, under what conditions, by whom and until when. The record and its rules are in Governance, security and trust.
5. Five readiness gates
Agree the mandatory controls before scoring. For each applicable gate, keep a test result and an approval.
| Gate | Passes when |
|---|---|
| Rights and handling | The intended use, provider, processing location and retention are authorised; classification and privacy restrictions are satisfied |
| Access isolation | Unauthorised users and tenants can't retrieve or receive protected content, including through derived assets and outputs |
| Context sufficiency | Required facts, meanings, applicable rules and process state are current and authorised. Source precedence and unresolved conflicts are explicit. Missing context triggers a tested stop or escalation. Recommendation and execution authority are verified separately |
| Fitness for purpose | Critical data-quality checks and representative task evaluations meet the agreed thresholds; known limitations are acceptable for the intended use |
| Operational control | A named owner can detect failures, stop or restrict use, apply corrections and revocations, and revalidate after material changes |
The decision:
- Ready for the defined use: every mandatory gate passes.
- Conditional: limited to an explicitly approved pilot boundary, with that boundary's own gates passed and the non-blocking actions dated.
- Not ready: any gate failed.
- Not assessed: any gate unverified.
The more restrictive result governs. Gate evidence must be verified and current. A partial or stale result leaves the gate not assessed, not passed.
6. Scoring
Maturity scale (per control):
| Score | Control maturity |
|---|---|
| 0 | Absent or demonstrably ineffective |
| 1 | Ad hoc, person-dependent operation |
| 2 | Defined and partly operating; material execution gaps remain |
| 3 | Operating across the agreed scope, with current evidence that the outcome is achieved |
| 4 | Sustained operation, monitored effectiveness and demonstrated corrective improvement over the agreed observation period |
Rules:
- Capability = the mean of its applicable controls. Dimension = 5 × the mean of its applicable capabilities (so 20 at most). Total = the sum of the five dimensions (100 at most).
- Unknown is not zero, but it counts as zero. An unknown control contributes 0 and stays in the denominator, so the score is a provisional lower bound. Report the number of unknowns beside it.
- Not applicable needs a rationale. Approved N/A controls are excluded; a capability with no applicable controls is excluded. If a whole dimension is inapplicable, report a profile of dimension scores, not a total out of 100.
- Evidence status caps the score. Each control records its ID, requirement, stage, scope, owner, test, threshold, result, evidence link and date, and assessor. Partial evidence caps the control at
- Unverified evidence leaves it unknown.
- No fixed source weighting. Scans, interviews, sampled records and observed behaviour all support the same control. Resolve conflicting evidence explicitly. (The v1 template's 60/40 scan/interview split is withdrawn.)
Coverage and confidence. Report the assets assessed against the agreed inventory, with Tier 1 coverage shown separately. Report the counts of verified, partial and unverified evidence across the applicable controls.
Calibration. Fix the scope, controls, evidence window and method version before scoring. Pilot with two assessors, reconcile their differences, and check the bands against what was actually delivered. Disclose any scope change before comparing scores.
Bands. These are provisional maturity bands. They are not production approval. Publish the readiness decision separately.
| Band | Total | Indicative practice level (Roadmap and maturity) |
|---|---|---|
| Foundational | 0-39 | 1-2 Fragmented, Consolidating |
| Emerging | 40-69 | 2-3 Consolidating, Productised |
| Established | 70-89 | 3-4 Productised, AI-enabled |
| Optimising | 90-100 | 4-5 AI-enabled, AI-native |
The level mapping is this practice's indicative reading, not the source draft's. A band describes one assessed scope; a level describes the whole practice. A practice can't reach level 4 while its production AI uses sit in Foundational.
Output. A scorecard, the gate decision, an evidence register, the unknowns and a roadmap. Prioritise the mandatory blockers first, then risk reduction, business value, dependencies and effort. Every action has an owner, an acceptance test, an estimate and a date.
7. Systems and context: warehouse coverage is not context coverage
Follow the business scenario across its source, knowledge and decision systems. Information can stay in the application that owns it. The question is whether the AI can obtain it, and use it correctly, through approved routes.
| System function | Assessment evidence |
|---|---|
| Operational sources (CRM, ERP, transaction systems) | Authoritative facts, entity identifiers, current state, responsible owners |
| Knowledge sources (knowledge bases, document stores, email, external services) | Approved content, provenance, applicability, versions, retrieval permissions |
| Semantics and ontology (glossaries, semantic layers, knowledge graphs) | Shared definitions, entity relationships, cross-system mappings, validated assertions |
| Rules and decisions (policies, contracts, decision tables, rules engines) | Approved logic, effective dates, precedence, exceptions, test cases |
| Processes and workflow | Current stage, prerequisites, responsible role, approval limits, permitted next actions, human handoffs |
| Integration and evidence (APIs, connectors, queries, indexes) | Identity propagation, freshness, failure behaviour, traces from source facts to outcomes |
- Access pattern. Use indexed retrieval for suitable knowledge, live queries for changing facts, and events where timely updates matter. Record refresh and cache limits, API availability, rate limits, schema changes and revoked access. Service credentials must preserve the requesting user's permitted scope (Identity propagation).
- Meaning and authority. An ontology defines concepts and relationships. A knowledge base supplies content. Rules express approved logic. Workflow supplies process state. Assess only the functions the use case needs: a maintained glossary and a decision table may be enough. A graph database is not a prerequisite.
8. Rule authority
Text extracted from a policy is evidence, not executable business logic. Before you encode a rule, record its approval, applicability, effective dates and exception precedence. Model-generated rules and relationships stay proposals until the responsible owner validates them. This matches the rule-of-record approach in Where business rules run after migration.
9. Decision provenance
Link each decision to the information that supported it, the processing activities and the responsible people or systems. Keep enough versioned evidence to review the decision later, without duplicating sensitive content unnecessarily. W3C PROV provides the vocabulary: entities (the customer record, the rule version), activities (retrieval, the rule evaluation) and agents (the officer, the AI service).
10. Worked example: "Can this licence be renewed?"
Illustrative, rewritten from the draft's refund example. Not an assessed use case.
A customer-service assistant recommends whether a driver licence can be renewed today. It recommends; the officer approves. To do that it needs:
| Context | Source function | Authority |
|---|---|---|
| The customer record: identity, licence class, current status, medical conditions affecting licensing | Operational source | Licensing system of record |
| The applicable rule version: eligibility, fees, medical and suspension rules as at today | Rules and decisions | Rule card with effective_from (Where business rules run after migration) |
| The case state: documents received, checks outstanding, previous attempts | Process and workflow | Case management |
| The officer's delegation: what this officer may approve | Process and workflow | Delegations register |
Tests to run before the context sufficiency and fitness for purpose gates can pass:
- Missing data. The medical-condition field is unavailable. The assistant must stop and escalate, not recommend renewal.
- Conflicting rules. A superseded procedure document and the current rule card disagree. The assistant must apply the agreed source precedence, cite the rule version, and flag the conflict.
- Above delegation. The renewal needs an approval above this officer's delegation. The assistant may recommend, but must route the approval to an officer who holds the delegation.
Record the facts used, the rule version, the approval and the outcome. Retrieving a policy paragraph alone is not enough. Classification gives no permission here: the record is OFFICIAL: Sensitive and contains personal information, so AI use rests on an explicit AI-permission record for this purpose, service and environment.
11. Implementation variants
The controls stay the same; only the evidence sources change. Use cases determine applicability and thresholds; vendor choice does not. The features below were checked against vendor docs on 6 Nov 2026.
| Estate | Where the evidence comes from | Watch for |
|---|---|---|
| Databricks | Unity Catalog for catalog, lineage, tags and policies; Lakeflow pipeline expectations for quality checks; MLflow model and evaluation records (expectations, updated 26 Oct 2026; lineage, updated 4 Nov 2026) | Lineage gaps: renamed objects lose lineage, and runs-submit or spark-submit jobs, path-referenced tables (in Catalog Explorer and the API), UDF bodies, RDDs and global temp views are not fully captured. The configured response to invalid data: warn, drop and fail are different controls |
| Snowflake | Snowflake Horizon Catalog catalog and policy evidence; data metric functions, with expectations that turn a metric into a pass/fail check (Enterprise Edition; data quality, expectations, checked 6 Nov 2026); AI and retrieval configuration | Monitoring reports a violation. Prove downstream blocking or quarantine separately |
| Other and mixed estates | Source APIs, knowledge platforms, semantic layers, rule services and workflow tools | Assess an equivalent outcome once, with cross-system mappings and policy propagation tested |
External knowledge, rules and workflows stay in scope on every platform.
Later: running the assessment as an agent
From an earlier source draft, AI-Ready Data Lifecycle Taxonomy and Assessment Model (superseded by the 4 Nov revision). Recorded as a possible later step, not a plan.
Most of the assessment is tool-shaped: scans are catalog and policy queries, and scoring is arithmetic. Build the scan and score functions first, and prove them against AI readiness scorecard (workbook v2) on a real workspace. Wrap them in an agent second (Agents and MCP). Keep the rubric and control definitions as data, not prompt text. Interview scores, effort estimates and the gate decisions stay human: an agent can surface them for approval, but it doesn't make them. The earlier draft's platform specifics, checked 6 Nov 2026:
- Databricks Apps is GA and available in Sydney, and agents can run on it (agents on Apps, updated 7 Oct 2026). Databricks now calls that the legacy agent server, and recommends the Agent Bricks CLI and Agent Runtime, which are in beta, for new agents (deploy agents, updated 13 Oct 2026).
- Snowflake Native Apps can create Cortex Agents and MCP servers, GA since 7 Aug 2026 (release note, docs). The draft's second date, 12 Aug, matches no such release note.
- Restricted caller's rights let an app act with the caller's privileges, limited to what an
administrator grants with
GRANT CALLER. GA for Native Apps since 29 Aug 2025 (docs).
Re-scoring
Re-score quarterly for every AI use in production, and also after any material change to a source, API, ontology, policy, workflow or provider. Report context coverage, gate status and evidence confidence alongside maturity. The cadence is in Roadmap and maturity.
References
The draft's reference notes, all accessed 4 Nov 2026 by the author: NIST AI RMF (business context and intended use); W3C PROV-O (provenance); OAIC, what is personal information (personal and sensitive information); Australian Government protective markings (the organisation applies its own mandated scheme, see Governance, security and trust).
Related: Governance, security and trust, Evaluating AI systems, AI-native patterns, Security foundations, the first 90 days, Decision register.