In my last piece, I covered what AI-native architecture actually means — data readiness, feedback loops, evaluation layers, observability, and clear human-in-the-loop boundaries, as opposed to just bolting an LLM onto whatever already exists.
The question I get most often after that conversation isn’t “what should we build.”
It’s “how do we know if we’re even ready to start.”
Fair question — and it deserves a real answer, not a vendor pitch disguised as one.
The Question Teams Skip
Most AI initiatives start with a tool decision: which model, which vendor, which platform. That’s the wrong first question. The right first question is whether your existing architecture can actually support what you’re about to build — because if it can’t, the model you choose is almost irrelevant. A great model sitting on top of broken foundations produces confidently wrong answers faster, not better answers.
Readiness isn’t a nice-to-have step before the “real work” starts. It is the real work. Everything downstream — cost, reliability, trust, speed to production — is shaped by decisions made here.
Here’s the honest audit, across five dimensions.
1. Data Readiness
The question isn’t “do we have data.” Almost everyone does. The question is whether that data is in a state a model can actually use.
- Accessible — can it be retrieved in real time, or does it live in a warehouse built for nightly batch reporting?
- Current — is it fresh enough to be trustworthy, or does “data as of last quarter” quietly become “the model’s answer as of last quarter”?
- Permissioned correctly — does your access control model extend to AI retrieval, or does a retrieval layer risk surfacing data to people who shouldn’t see it?
- Structured for retrieval — is it chunked, tagged, and indexed in a way that supports meaningful search, or is it a pile of PDFs and wiki pages with no real structure?
A common trap: data that’s perfectly fine for BI dashboards and quarterly reports is often unusable for real-time retrieval. Different use case, different requirements — and nobody discovers the gap until the pilot starts producing stale or nonsensical answers.
2. System Integration Readiness
AI doesn’t operate in a vacuum. It has to plug into whatever your business already runs on — CRM, ticketing, ERP, internal tools, customer-facing products.
The readiness question here: do those systems expose clean APIs and interfaces an AI layer can call reliably, or does every integration require custom, brittle glue code held together by one engineer’s tribal knowledge?
Legacy systems with no clean integration points aren’t just inconvenient — they’re a hidden cost multiplier. Teams routinely underestimate this cost because it doesn’t show up until integration work actually starts, well after the model has already been chosen and the budget approved.
3. Process and Ownership Readiness
Every AI initiative I’ve seen fail wasn’t a model failure — it was an ownership failure. Ask directly: who owns this when it works, and — more importantly — who owns it when it doesn’t?
Readiness here means:
- A named owner accountable for outcomes, not just for the initial build
- A defined escalation path for when the system produces a wrong or harmful output
- A change-management process that can absorb probabilistic behavior — because “it worked yesterday and not today” is a normal state for these systems, not a bug report
If every AI-related decision currently lives in one person’s head, or nobody can say who signs off when something goes wrong, that’s not a training gap — it’s an architecture gap. Fix the ownership model before you fix the tech stack.
4. Team and Skill Readiness
Building with GenAI requires a skill set most engineering teams haven’t needed before: evaluating probabilistic outputs, owning prompt and retrieval pipeline changes, reading observability signals that don’t look like traditional error logs.
The honest question: do you have people who can do this today, or a real plan to build that capability — or is the assumption simply “our engineers are smart, they’ll figure it out”?
That assumption isn’t wrong about your engineers’ intelligence. It’s wrong about the timeline. Figuring it out under production pressure, after launch, is a far more expensive way to build this skill than investing in it deliberately beforehand.
5. Governance and Risk Readiness
This is the dimension most often skipped entirely — right up until it becomes the reason a project stalls in legal review.
- Do existing data privacy and compliance policies explicitly cover AI-generated outputs, or is that an open question?
- Is there an acceptable-use policy for what the system should and shouldn’t be allowed to do?
- Has anyone mapped what happens if the model discloses something it shouldn’t, or makes a decision that should have required human sign-off?
If the answer to these is “we haven’t thought about it yet,” the first GenAI feature you ship becomes your organization’s de facto AI governance policy — by accident, under deadline pressure, with no one having actually decided that’s how it should work.
A Simple Way to Self-Assess
Score yourself, honestly, across the five dimensions above: data, integration, process/ownership, team, and governance. For each one, ask whether you’re ready now, ready in roughly six months with focused effort, or not ready — foundational work needed first.
Most organizations aren’t uniformly ready or unready. It’s common to be strong on data and weak on governance, or strong on team skill and weak on integration. The value of the assessment isn’t a single score — it’s knowing which dimension will actually constrain you, so you can fix the real bottleneck instead of the comfortable one.
I’ll follow this piece up separately with a scorecard you can use to walk through this with your own team.
Why This Matters More Than Model Selection
Here’s the uncomfortable truth: the model is rarely the constraint. Data readiness, integration debt, unclear ownership, skill gaps, and missing governance are what actually determine whether an AI initiative succeeds — and every one of those is an architecture and organizational decision, not a vendor decision.
Skip this assessment, and you don’t avoid the work. You just do it later, under worse conditions — after the pilot has already been oversold to leadership, after the model has already been chosen and budgeted, after the team has already built on a foundation that can’t hold what they’re asking it to do.
That’s exactly the scenario I’ll walk through next: what actually breaks once a demo that worked perfectly meets real users, real data, and real traffic.