27.10.26

What Does 'AI Readiness' Actually Mean When Screening a Data Architect Candidate?

When a job spec says a data architect must make systems "AI ready," most hiring managers accept the phrase without unpacking it — and most recruiters let them, because interrogating it requires technical fluency most agencies simply don't have. We built this FAQ because we've sat on calls where a client phones with a brief that says little more than "they're migrating to Unity Catalog through Databricks" and expects a shortlist within the hour. Here's how we turn a vague AI-readiness requirement into something you can actually screen for.

What "AI Readiness" Actually Means in a Data Architecture Context

What does it mean when a job spec says a data architect needs to make a business "AI ready"?

"AI ready" means the architecture can support governed, reliable data flows into the models and reporting layers that AI and analytics depend on — not that the architect bolts AI features onto an existing stack. In practice this shows up as work on platforms like Databricks, where the architect is expected to operate across the full data lifecycle, from legacy migration through to governance layers like Unity Catalog. One senior data architect candidate we spoke with described being comfortable "in the weeds in delivery, especially lately with all the AI stuff," while also able to stand in front of the C-suite to talk technical footprint and cost-to-profit timelines. That dual fluency — hands-on platform work plus the ability to translate it for the business — is the real signal buyers should be screening for, not a checklist of AI buzzwords.

Is "AI readiness" just a rebrand of standard data architecture work?

No — standard data architecture and AI-readiness architecture overlap heavily but are not identical. Databricks itself has shifted from being purely an analytics platform into something closer to middleware, pulling the application layer and the analytical stack together, which means an AI-ready architect may be asked to support mobile app development or AI Genie-style tooling alongside traditional data modeling. A candidate who can only speak to classic ETL and reporting pipelines is solving yesterday's brief. The distinguishing question to ask in screening is whether the candidate has had to reconcile data architecture decisions with where AI and application layers are converging on the platform, not just where the data warehouse sits.

What should a hiring manager actually test for, beyond "Databricks experience" on a CV?

Test for depth across the full Databricks stack, not just name recognition. We've found candidates who list Databricks but, when pressed, can only speak to one narrow layer — so the screening conversation needs to probe:

• Whether they've built semantic models within Databricks, not just surface-level reporting

• Whether they've worked with Unity Catalog specifically, including its role as the governance layer within Databricks

• Whether they can speak to Medallion architecture in practice — bronze, silver, gold layers — and how long they've actually been using it

• Whether they've handled migration from a legacy system (SQL Server, for example) into a modern lakehouse, including the proportion of their time spent on each platform

A candidate who answers these with specifics — "75% of my job was on Azure, 25% on SQL Server," for instance — is giving you something screenable. A candidate who answers in platform jargon without project detail is not.

KPI Modeling as a Core AI-Readiness Skill

Having covered the architecture fundamentals, the next layer buyers consistently underweight is KPI modeling — the discipline that turns a messy multi-system estate into something an AI or BI layer can actually report on.

Why does KPI modeling matter so much for AI-readiness hiring?

KPI modeling is the work of defining which entities relate to which metrics across disparate systems, then aligning them into a conceptual and physical model before any integration roadmap can be built. One data architect we interviewed described exactly this process for a multi-region cinema operator: constructing a "group KPI matrix" to understand which business entities mapped to which KPIs across separate systems in Northern Europe, Southern Europe, and the UK and Ireland, then building a roadmap to integrate the underlying data. This is foundational AI-readiness work — without a clean, agreed KPI model, no amount of Databricks infrastructure will produce trustworthy outputs for an AI layer to consume. When briefing a recruiter, ask explicitly whether the candidate has built a KPI or metrics model across multiple source systems, not just within a single platform.

What does good KPI modeling experience actually look like on a CV?

It looks like evidence of translating business entities into a conceptual, logical, and physical data model, not just building dashboards. The cinema operator project involved exploring Azure data flows within Microsoft Fabric, Power BI reporting, and SQL Server exploration activity, alongside semantic modeling within Databricks — a spread across the stack that shows the candidate wasn't just reporting on data but architecting how it flowed. If a candidate's KPI modeling experience is confined to writing Power BI DAX measures against an already-clean dataset, that is not the same skill as designing the matrix and roadmap in the first place. Screen for the roadmap-building step specifically — it's the part of the job most CVs compress into a single bullet point.

How does KPI modeling connect to the governance side of AI readiness?

KPI modeling defines what gets measured; governance defines whether that data can be trusted and is defensible to regulators. In fintech and asset management environments specifically, we've seen briefs where a data governance consultant is expected to work alongside a data governance engineer to assess which data fields are critical, who owns them, how sensitive they are, and what good quality looks like — essentially writing the rulebook the KPI model then depends on. One candidate put it directly: "if you want to build a product that is scalable, and you want to build a product that is defensible to regulators, you need to plug in data governance". An AI-ready architecture without this governance layer underneath the KPI model is a reporting exercise, not an AI-readiness one.

Databricks Foundations: What to Screen For

KPI modeling tells you what a candidate can structure conceptually — but AI programmes live or die on the platform foundations underneath, which is where Databricks and Unity Catalog screening gets concrete.

What is Unity Catalog, and why do so many AI-readiness briefs mention it specifically?

Unity Catalog is the governance layer within Databricks, handling cataloging, lineage, data quality rules, classification, sensitivity, and access control in one place. Its prominence in AI-readiness briefs reflects a real pattern: multiple clients we've worked with have come to us with migrations specifically framed as "moving to Unity Catalog through Databricks," sometimes with nothing more than that single sentence as the brief. One candidate, working in a highly regulated housing association, described using Unity Catalog to do "everything from catalog, lineage, quality rules, dashboards within Databricks, classification, sensitivity, access control". If your job spec mentions Unity Catalog, the screening question is not "have you heard of it" but "which of those specific functions have you configured yourself."

Does AWS/GCP experience count, or does AI-readiness hiring require Azure specifically?

It depends on which cloud the client's Databricks environment sits on — AI-readiness screening should match the candidate's cloud background to the client's actual stack rather than treating "cloud experience" as interchangeable. We've placed candidates into Databricks-on-AWS environments for fintech asset managers and into Databricks-on-Azure environments for wealth management migrations, and the underlying skills — data pipeline construction, PySpark transformations, Medallion architecture — transfer across both. What doesn't transfer automatically is familiarity with the specific cloud-native tooling around Databricks, such as Azure Data Factory and Azure Data Lake Storage Gen2 versus AWS-native equivalents. Ask the candidate to walk through the proportion of their recent project time spent on each cloud, as a concrete gauge of current depth rather than historical exposure.

How do I tell a candidate who genuinely understands Medallion architecture from one who's just using the term?

Ask them how long they've actually been using the bronze-silver-gold pattern, independent of when they learned the name for it. One engineer with four years of Medallion architecture experience made the point directly: the practice itself long predates the branding, and "the name is getting popular, but it's been like a good practice which we are using from long back". A credible candidate should be able to describe the layers in terms of what actually happens to the data at each stage — raw/bronze data arriving from source systems, cleaning and de-identification into silver, and aggregated, curated metrics in gold — rather than reciting the three words. If a candidate can't explain what changes about the data between layers, the term is decoration, not depth.

What's the difference between hiring for AI-readiness architecture versus hiring a standard data engineer?

The difference sits in scope and stakeholder exposure, not tooling. A data engineer builds and debugs pipelines day to day — for example, constructing data pipelines using Azure Data Factory and Databricks with PySpark, and troubleshooting slowness or failures. An AI-readiness architect is expected to additionally translate that technical footprint for the business, take people on a journey to understand what the platform is doing, and speak to when the investment starts turning a profit. When briefing a recruiter for an AI-readiness architecture hire, be explicit that you need both the hands-on platform credibility and the stakeholder communication layer — the two don't always sit in the same person, and a spec that only lists tools will miss that distinction entirely.

Should I expect an AI-readiness data architect to also handle data governance, or is that a separate hire?

Treat them as closely related but distinct hires, best screened separately even when one person covers both. Architecture work focuses on conceptual, logical, and physical data models and how data flows between systems; governance work focuses on ownership, sensitivity classification, quality rules, and regulatory defensibility of that same data. The strongest candidates we've placed understand both: one governance specialist explicitly noted that data governance professionals who've previously worked as data architects — and who understand conceptual, logical, and physical modeling — are better equipped to work with engineers because "every transformation that they are making, there are standards that need to be followed". If your AI programme needs both functions, brief them as two connected but separately screened roles rather than assuming one hire covers both competently.

What questions should I give my recruiter to screen for real Unity Catalog experience, not CV keyword-matching?

Give your recruiter three specific prompts rather than a single yes/no question about Unity Catalog familiarity:

• "Walk me through which Unity Catalog functions you've configured yourself — catalog, lineage, quality rules, classification, access control — versus which you've only observed."

• "Describe a project where you used Unity Catalog as the governance layer specifically, not just Databricks generally."

• "What proportion of a recent project was spent on governance setup versus pipeline-building, and who owned which part?"

These questions mirror how we actually vet Databricks and Unity Catalog candidates on calls, pressing past the keyword and into the specific functions a candidate has touched. A recruiter who can't ask these questions is pattern-matching your job spec against a CV, not screening for AI readiness.

Briefing Your Recruiter: Concrete Language to Use

What should I actually put in the job spec if I want "AI ready" to mean something specific?

Replace "AI ready" with a short list of platform-specific, screenable requirements drawn from your actual migration or project context. At minimum, specify: the target platform (Databricks, Unity Catalog, specific cloud), whether the role is architecture-led or governance-led, the sector-specific regulatory context if relevant (fintech, asset management, wealth management), and whether KPI/metrics modeling across multiple source systems is in scope. We've taken briefs that arrived as a single phone call with almost no detail beyond "they're migrating to Unity Catalog through Databricks" and still had to extract candidate profile and tech stack requirements before a shortlist could go out. The more of that detail you supply upfront, the faster your recruiter can filter for genuine depth instead of keyword overlap.

Getting the brief right is the difference between a shortlist of people who can discuss Databricks in the abstract and a shortlist of people who've actually built the governance layer, the KPI matrix, and the migration roadmap your AI programme depends on. Engage us with the specifics above, and we'll translate them into a technical screen built for exactly this hire.