AI Readiness Assessment#

Executive Summary#

An AI Readiness Assessment determines whether a client organization has the data infrastructure, technical architecture, and organizational capacity to support a production AI deployment — before committing to a POC design or resource allocation. Skipping this step is the single most common cause of POC failures and stalled production migrations: teams discover mid-execution that the data is too sparse, the security review will block cloud AI calls, or no one owns the workflow change management. This chapter provides a structured assessment framework covering three dimensions — data maturity, infrastructure readiness, and organizational readiness — with scoring models, assessment templates, and specific adaptations for healthcare clients where regulatory constraints materially affect every dimension.

Learning Objectives#

• Conduct a structured AI readiness assessment across the three dimensions: data, infrastructure, and organization
• Score client readiness on a defined scale and map scores to recommended engagement approaches
• Identify blocking constraints that must be resolved before a POC can succeed
• Design an assessment report that communicates findings to both technical and executive audiences
• Adapt the assessment framework for healthcare clients with HIPAA, FHIR, and clinical workflow constraints

Business Problem#

Enterprise AI POCs fail for predictable reasons. A study of failed enterprise AI pilots reveals consistent root causes: insufficient data volume or quality for the target use case; integration paths that do not exist or are blocked by security policy; no internal owner for the AI-generated output; and organizational change management that was not planned.

All of these root causes are identifiable before the POC begins — but only if a structured readiness assessment is conducted. An FDE who proceeds directly from discovery to POC design without an assessment is accepting unnecessary risk. The assessment exists to convert unknown risks into known constraints that can be planned around or that justify recommending against a POC in its proposed form.

Conceptual Explanation#

Readiness has three independent dimensions. An organization can be highly mature on one dimension and poorly prepared on another:

Dimension 1 — Data Maturity: Can the AI system access the data it needs, at the quality level it requires, at the volume that will produce meaningful results?

Dimension 2 — Infrastructure Readiness: Can the AI system run within the client's technical environment, given their cloud posture, network architecture, and security requirements?

Dimension 3 — Organizational Readiness: Does the organization have the team capacity, governance structures, and change management capability to deploy and adopt an AI system?

Each dimension is assessed independently and scored. The overall readiness score determines which engagement approach is appropriate.

Core Architecture: The Assessment Framework#

Dimension 1 — Data Maturity#

Data maturity is assessed across four sub-dimensions: availability, quality, accessibility, and governance.

Data Availability: Does the data the AI needs actually exist in the client's systems?

Implementation code omitted in the Playbook edition. For complete code examples, production patterns, and advanced implementation details, see the Enterprise AI Technical Reference.

Data Quality: Is the data accurate, complete, and consistent enough to produce reliable AI output?

Common data quality issues in clinical AI:

• Conditions coded in free text rather than ICD-10 (not machine-parseable)
• Medications without dosing information
• Vital signs in non-standard units or with transcription errors
• Duplicate patient records (patient matching failures)
• Notes in scanned PDFs rather than structured text (requires OCR pipeline)

Data Accessibility: Can the AI system actually reach the data through approved integration paths?

Implementation code omitted in the Playbook edition. For complete code examples, production patterns, and advanced implementation details, see the Enterprise AI Technical Reference.

Data Governance: Who owns the data and can approve AI system access?

Data Maturity Score:

Dimension 2 — Infrastructure Readiness#

Infrastructure readiness covers cloud posture, network architecture, security, and integration capability.

Cloud and Network Architecture Assessment:

Implementation code omitted in the Playbook edition. For complete code examples, production patterns, and advanced implementation details, see the Enterprise AI Technical Reference.

Infrastructure Readiness Score:

Dimension 3 — Organizational Readiness#

Organizational readiness is the most frequently underestimated dimension. A technically ready organization with low organizational readiness will fail to adopt the AI system even if the POC is technically successful.

Team Capacity Assessment:

Governance Readiness:

Implementation code omitted in the Playbook edition. For complete code examples, production patterns, and advanced implementation details, see the Enterprise AI Technical Reference.

Organizational Readiness Score:

Overall Readiness Score and Engagement Recommendation#

Implementation code omitted in the Playbook edition. For complete code examples, production patterns, and advanced implementation details, see the Enterprise AI Technical Reference.

Architecture Diagram#

Executive Summary#

[3-sentence summary suitable for CIO/CMIO: overall readiness level, primary gaps identified, recommended next step]

Enterprise Considerations#

Portfolio-level readiness patterns: FDEs who have conducted assessments across many clients begin to recognize patterns in readiness gaps by organization type. Academic medical centers often have strong data maturity but slow compliance processes. Community hospitals often have infrastructure gaps but faster organizational decision-making. Building these patterns into assessment playbooks accelerates future assessments.

Readiness as a sales enablement input: The readiness assessment is not purely a technical tool. When shared with the client's executive sponsor, it communicates the FDE's depth of understanding of the client's environment and creates a credibility foundation that accelerates the rest of the engagement.

Remediation as an opportunity: When readiness gaps require remediation (data quality work, infrastructure provisioning, governance setup), the FDE can guide the remediation process — creating additional value and deepening the client relationship during what might otherwise be a waiting period.

Healthcare Example#

A Reference Healthcare Organization assessment reveals the following pattern, which is common in community hospital settings:

• Data Maturity: 4 — Epic FHIR R4 fully configured; SMART on FHIR available; data completeness exceeds thresholds for all required resources
• Infrastructure: 2 — PHI-in-cloud is not pre-approved; requires case-by-case CIO sign-off; no AI gateway in place; LLM connectivity not tested
• Organizational: 3 — CMIO sponsor confirmed; physician champion identified; no Model Review Board (reviews handled ad hoc)

Overall: 3.0 — POC with Parallel Remediation

The primary risk is infrastructure. The recommendation is a parallel track: IT team pursues PHI-in-cloud approval and AI gateway provisioning during the POC design phase. If this track is not completed in time, the POC falls back to a synthetic data environment that demonstrates the clinical quality of the AI output without requiring PHI connectivity — a meaningful alternative that can still inform the production decision.

Common Mistakes#

1. Skipping the data quality measurement. Self-reported data quality is almost always more optimistic than actual quality. The FDE must run sample queries and count completeness rates empirically.

2. Treating infrastructure readiness as binary. "We're on Azure so we're fine" is not an infrastructure assessment. The FDE must confirm that PHI-in-cloud is approved, that outbound connectivity to LLM APIs is permitted, and that the security review timeline is understood.

3. Not surfacing organizational blocking issues early. Discovering in week 6 of a POC that the compliance officer has not approved the integration is a failure of the assessment phase. Compliance review must be in the assessment scope.

4. Conflating score with recommendation. A score of 3/4 on organizational readiness does not mean "proceed without addressing the gap." The gap must be identified and a closure plan agreed before the POC begins.

5. Not documenting the remediation plan. When the recommendation is "POC with Parallel Remediation," the remediation plan must be specific: who does what, by when, and what is the POC start dependency.

Best Practices#

• Run data quality assessment against a minimum of 50 actual encounters before committing to a POC approach
• Test LLM API connectivity from within the client's network environment before the POC design session
• Include the compliance officer in the assessment — not at the end as a gate, but as a participant throughout
• Share the Assessment Report with the client for accuracy review before finalizing
• Define the remediation plan before the assessment report is delivered — not after
• Never start POC execution with a blocking gap unresolved

Trade-offs#

Assessment depth vs. time cost: A thorough assessment takes 1–2 weeks. Clients who want to start the POC immediately will push back. The FDE must hold the position that unknown blocking gaps discovered mid-POC are more expensive than a 2-week assessment.

Transparency about gaps: Sharing an honest assessment that reveals organizational or data gaps can create uncomfortable conversations. The alternative — proceeding without surfacing them — creates a failed POC that is harder to recover from.

Interview Questions#

Q: A client wants to skip the readiness assessment and go straight to POC execution. How do you respond?#

Category: Behavioral Difficulty: Senior Role: FDE

Answer Framework:

The response is to acknowledge the client's urgency, explain the concrete risk of proceeding without assessment, and propose a compressed assessment approach that addresses the most critical unknowns in the shortest possible time.

The concrete risk framing: the most common cause of POC failure and delay is a blocking constraint that was discoverable in week 1 but was only found in week 4 — a PHI-in-cloud policy that blocks LLM calls, a data quality issue that requires a different integration approach, or a missing BAA that prevents the POC from processing real patient data. These findings restart the POC from scratch and cost more time than the assessment would have taken.

The compressed alternative: if the client's constraint is real, propose a 1-week rapid assessment focused exclusively on the blocking items — data connectivity test, PHI-in-cloud policy confirmation, BAA status, and compliance officer meeting. This is not the full three-dimension assessment but it identifies the most dangerous unknowns before POC execution begins.

Key Points to Hit:

• Acknowledge the urgency rather than dismissing it
• Frame the risk in terms of POC restarts, not process compliance
• Propose a compressed alternative rather than a binary yes/no
• Hold on the non-negotiables (PHI policy, BAA, connectivity test)

Red Flags:

• Agreeing to skip assessment entirely
• Framing assessment as "our process" rather than the client's risk mitigation

Key Takeaways#

• AI readiness assessment covers three independent dimensions: data maturity, infrastructure readiness, and organizational readiness
• A single dimension at "Not Ready" (score 1) is a blocker regardless of overall score
• Data quality must be measured empirically — self-reported quality is unreliable
• Infrastructure readiness includes PHI-in-cloud policy, LLM API connectivity, AI gateway, and security review timeline
• Organizational readiness covers team capacity, governance, and change management — not just executive sponsorship
• The assessment produces a written report shared with the client — not an internal FDE document
• Remediation plans must be specific before the assessment is finalized

Further Reading#

• Client Discovery Framework — Discovery precedes assessment
• POC to Production — What happens after assessment
• HIPAA and AI — PHI handling requirements assessed in infrastructure dimension
• Enterprise AI Strategy — Organizational readiness in the broader enterprise AI strategy context