Enterprise AI Activation Readiness: The Complete Guide

1. The MIT finding Workday cited at Rising 2025

At Workday Rising 2025, Workday cited MIT research showing that despite billions spent on enterprise AI in 2024, only 5% of organisations saw measurable return. The reason was not the model. It was that AI was deployed in piecemeal pilots, disconnected from how work actually gets done, and layered on top of foundational data and process problems that nobody had cleaned up first.

The tenant underneath the AI was never ready.

2. The a16z analysis (May 2026)

a16z noted in May 2026 that 'most organisations have no idea these [Workday Illuminate] capabilities exist, let alone how to activate them.' Long-time Workday admins describe Illuminate as 'the same manual admin work with a chat surface bolted on' — because the underlying configuration was never cleaned up before AI was layered on top.

Signing Flex Credits is a procurement transaction. It is not a tenant readiness solution.

3. The five universal AI activation blockers

• Foundational data quality — worker records with missing positions, supervisory orgs pointing to terminated managers, job profiles with no skills.
• Role and skill structure — incomplete job profiles and skill taxonomies mean AI agents have no structured context to reason over.
• Process and routing health — broken business process approval chains mean every agent action routes to a dead end.
• Security and data exposure — agents inherit the security model. Unconstrained groups mean the agent surfaces compensation data to managers who should not see it.
• Integration trust — failing payroll integrations mean agent-generated payroll data corrupts downstream systems silently.

4. Platform specifics

Workday Illuminate runs an 800B-parameter LLM trained on 1T+ annual transactions across 11,000+ customers. It requires clean job profiles, healthy BP routing, scoped security, and ISU credential hygiene before any agent works in production.

SAP Joule requires SuccessFactors integrated to IAS, Employee Central Quick Actions configured, the correct BTP subaccount in an allowed region (EU10, EU30, US10, AP10), and an unbroken IAS trust chain — three to five places where a multi-year deployment will have drifted.

Oracle AI Agents inherit fast formula errors, broken approval rules, and value set validation gaps. OTBI reports the agent queries must not error. HCM Extracts the agent reads from must not reference deprecated data groups.

5. When to scan for AI readiness

• Before signing the Illuminate / Joule / Oracle AI contract.
• Before any AI proof of concept.
• After tenant cleanup but before agent activation.
• Before each new agent or use case goes live.
• After every major Workday / SAP / Oracle release.
• Continuously on a quarterly cadence as part of AI governance.

Why 'clean data' is a necessary but not sufficient condition

Most enterprise AI readiness conversations start and end with data quality — are job profiles complete, are skills tagged, is worker data accurate. This is necessary, but it dramatically understates the problem. An AI agent operating inside Workday, SAP or Oracle doesn't just read data; it takes actions through business processes and respects (or inherits the flaws of) the existing security model. An agent can have perfectly clean data to reason over and still fail, or worse, cause harm, if the business process it needs to route an action through has a broken approval chain, or if the security context it inherits grants it visibility into data it shouldn't expose in its output.

The organisations that get burned by early AI activation attempts are frequently the ones that invested heavily in data cleansing while treating security and process health as someone else's problem. Readiness has to be assessed across all three layers simultaneously — data, process and security — because a gap in any one of them can undermine an otherwise well-prepared AI initiative.

The specific data quality checks that matter most for HCM AI agents

• Job profile completeness — missing job families, missing management level, or missing job classification data means the agent has no structured taxonomy to reason within when answering questions about roles or making recommendations.
• Skills data coverage and freshness — skills tagged once during a talent project and never updated give the agent a stale, misleading picture of workforce capability.
• Supervisory organisation integrity — orphaned positions, managers who have left the organisation but remain listed as the supervisory organisation head, and circular reporting structures all confuse agent reasoning about organisational context.
• Position management consistency — organisations mixing position management and job management approaches inconsistently across business units create a data model the agent cannot reliably generalise across.
• Historical data integrity — agents trained or prompted with historical context (tenure, prior roles, compensation history) will surface errors accumulated over years of data migrations and manual corrections if that history was never cleaned.

Process readiness: why broken business processes are worse for AI than for humans

A human employee encountering a broken business process — an approval step routing to someone who left the company — will usually notice something is wrong, escalate, and get a manual workaround. An AI agent attempting the same action typically has none of that judgement. It either fails silently, retries indefinitely, or in worse cases, takes an unintended fallback action because the process definition technically allowed it even though the outcome makes no business sense.

This is why process readiness assessment for AI activation needs to go further than a standard business process audit: it needs to specifically test what happens when an agent-initiated transaction hits an edge case that a human would catch by exercising judgement but that a literal rules engine will not. Organisations preparing for agent activation should run their business process audit with this specific lens — 'what happens if there's no human in the loop to catch this' — rather than assuming a process audit performed for other purposes automatically covers agent readiness.

Security implications of giving an AI agent a service identity

Most AI agent activations require creating a new type of technical identity in the tenant — distinct from a human worker account and distinct from a traditional integration system user — that the agent operates through. This service identity typically needs read access across a wide swath of the tenant to be useful (an HR chatbot needs to read policy documents, worker records, and organisational data to answer questions usefully) which makes it, almost by definition, one of the highest-privilege identities in the tenant.

Organisations should treat the security review of this agent identity with at least the same rigour applied to a privileged human administrator account: scoped to the minimum domains actually required for the agent's use cases, monitored for unusual access patterns, and reviewed on the same cadence as other privileged accounts — not treated as a one-time setup step during activation and then forgotten.

A phased activation approach that limits blast radius

• Phase 1 — read-only, internal-facing use cases: agent answers questions and surfaces information but takes no write actions and is scoped to a limited worker population (e.g., a single business unit) for initial testing.
• Phase 2 — supervised write actions: agent proposes actions (a compensation change draft, a BP initiation) that still require human approval before execution, building an audit trail of proposed-versus-approved actions to evaluate accuracy.
• Phase 3 — limited autonomous actions in low-risk domains: agent executes fully autonomously only in domains with low financial or compliance impact (e.g., FAQ responses, scheduling) while higher-risk domains (payroll, compensation, terminations) remain in the supervised tier indefinitely or for a much longer trial period.
• Phase 4 — expanded autonomy, only after a sustained period (typically two to three full quarters) of clean audit results in the supervised tier, and only with continuous monitoring rather than a one-time readiness check.

Vendor claims versus tenant reality — a due diligence checklist before signing

• Ask the vendor for the specific, named prerequisites their AI capability requires (not marketing language) and cross-reference each one against your own tenant's current state before signing.
• Request a reference customer of comparable size and industry who has actually activated the capability in production, not merely piloted it.
• Ask what percentage of the vendor's existing customer base has successfully activated the AI capability beyond initial pilot, since this figure (when vendors will share it) is usually far lower than the sales narrative implies.
• Run an independent tenant readiness scan before finalising the contract, so the negotiation reflects the actual remediation work required rather than an assumption that the tenant is 'probably fine.'
• Clarify who is responsible for the pre-activation remediation work — the vendor's professional services team, an AMS partner, or the internal team — and get that responsibility written into the statement of work, not left implicit.

Frequently asked questions

Continue reading

• Workday Illuminate Readiness
• SAP Joule Activation
• Oracle AI Agents Readiness
• 50-Point AI Readiness Checklist
• State of HR Tenant Health 2025 Report
• AI Activation Readiness product page
• Run a free AI readiness scan