What does AI-native mean?

Harvard Business School Online defines an AI-native business as one built from the ground up to leverage AI for value creation, with AI embedded at every stage from R&D to marketing to HR. They distinguish it from AI-first — a company that adds AI as a core capability to an existing business. By that definition AI-native is a birth condition only startups can meet. A more useful working definition for established companies is behavioural — AI-native means your people reach for AI by default when they hit a repetitive or ambiguous task, and the organisation can absorb what comes back.

Can an established company actually become AI-native?

Not in the strict architectural sense — you cannot un-build thirty years of systems. But the outcome people actually want is capability, not category membership. An established company can reach the point where AI is the default first move across most workflows, which is what delivers the value. The route runs through building capability in your existing staff, because the alternative — hiring it in — is currently unaffordable, unavailable, or both.

Should we hire AI talent or train our existing people?

Train, with selective hiring at the margins. The market for genuine AI capability is currently either overpriced or empty, and candidates who can credibly claim deep experience are scarce enough that you compete with well-funded technology companies for them. Meanwhile your existing staff hold the domain knowledge that makes AI useful in your specific business — which is the harder half to acquire. Teaching AI to someone who knows your operation beats teaching your operation to someone who knows AI.

How do you handle employees who resist AI?

First, work out which kind of resistance you are dealing with. Roughly 10% of people will push back, but that group contains two very different populations — low performers for whom AI exposes weak output, and genuine masters of their craft whose quality bar the tools do not yet clear. They look identical on an adoption dashboard and require opposite responses. The craftspeople are not blockers. They are your quality function, and the right move is to give them the job of holding AI accountable.

How to become an AI-native company when you weren't born one

Most definitions of "AI-native" are built so that your company cannot be one.

Harvard Business School Online's guide is the clearest example, and it is a good piece of work. It defines an AI-native business as "one built from the ground up to leverage AI for value creation and problem-solving", with AI embedded at every stage of the organisation. Then it draws the distinction sharply:

Business A: A 30-year-old firm systematically incorporating AI tools across its systems. This is an AI-first company. Business B: A startup built within the last year with AI embedded in every process from day one. This is an AI-native company.

If you are reading this, you are almost certainly Business A. And by that definition, the door is closed — you cannot retroactively be founded differently.

This is where I part company with the framing, though not with the analysis. The HBS pillars are sound: foundational data, cybersecurity and privacy, a machine learning ecosystem, and guardrails with feedback loops. Karim Lakhani's factory metaphor — data as raw material, algorithms as machinery, predictions as output — is genuinely useful for explaining the shape of the thing to a board.

But every one of those pillars is architectural. They describe a machine. None of them describe the organisation that has to operate it, and for an established company that is where the entire difficulty lives.

So here is the working definition I use instead, which is behavioural rather than architectural:

You are AI-native when your people reach for AI by default on repetitive or ambiguous work, and the business can absorb what comes back.

That is achievable for a 30-year-old firm. It is also, conveniently, the thing that actually produces value — nobody buys your category membership.

Why you cannot hire your way there

The instinct is to buy the capability. Hire a Head of AI, bring in a team, let them lead the transformation.

This does not work right now, for a boring market reason: AI capability is either overpriced or unavailable. The field is new enough that genuinely experienced people are scarce, and the ones who exist are being competed for by companies with far deeper pockets than yours. Below that tier, you are largely paying a premium for people who have read the same material your staff could read, with none of the context about how your business works.

That context is the part that matters. The hard problem in applying AI to your business is not knowing how transformers work. It is knowing which of your processes are genuinely stable, where the exceptions hide, which customer promises are non-negotiable, and why that workflow has a weird manual step that turns out to be load-bearing. Your existing staff know all of that. Teaching AI to someone who understands your operation is dramatically easier than teaching your operation to someone who understands AI.

McKinsey found 69% of companies had begun investing in AI before 2024, with 92% planning to increase investment by 2029. Almost all of that money is chasing the same thin talent pool. Building internally is not the frugal compromise. Right now it is the faster route.

The 20 / 70 / 10 distribution

Once you accept that this is a people problem, the useful question becomes: which people?

Across the organisations I have worked in and with, adoption sorts into roughly three groups. The proportions vary but the shape holds.

The 20% — champions

These people were already experimenting before you announced anything. They have a personal subscription, they have opinions about which model is better for what, and they have quietly automated part of their own job.

The mistake is to treat them as early adopters to be celebrated. They are not your marketing — they are your R&D. This group should be given explicit permission and time to build the tooling everyone else will use: the prompt libraries, the templates, the workflows, the internal guidance. They will do it anyway. The only question is whether they do it in the open, where it can be shared and reviewed, or in private, where it becomes shadow AI.

Give them a mandate, a small budget, and a route to publish what they build internally.

The 70% — the majority who want direction

This is the group that determines whether you become AI-native, and the group most programmes fail.

They are not resistant. They are busy. They will happily use a tool that makes their day better, and they have no interest whatsoever in learning to prompt-engineer, comparing models, or understanding the technology. They want to be told: use this, for this, like this, and here is what to check before you trust it.

Most AI enablement fails this group by teaching capability instead of providing direction. A session explaining what AI can do leaves them with a menu and no recipe. What works is the opposite — a small number of specific, pre-built workflows for tasks they already do, with the boundaries drawn clearly.

This is also why the champions matter so much. The 20% build the recipes the 70% follow. If you skip the first step, you are asking 70% of your workforce to invent their own approach in time they do not have.

The 10% — and the distinction that matters most

Roughly a tenth of people push back. Almost every AI programme treats this group as a single problem to be managed, and that is the most expensive mistake in the whole exercise.

There are two completely different populations in that 10%, and on an adoption dashboard they are indistinguishable.

The first is low performance wearing a principled objection. For some people, AI is threatening because it exposes that their output was never especially good — that the work they were protecting was mostly volume. Their objections tend to be vague, mobile, and unfalsifiable. Answer one and another appears.

The second is the craftsman. These are people who are genuinely excellent, who care deeply about the quality of what they produce, and whose standards the tools do not yet meet. Their objections are specific: this summary drops the qualifier that mattered, this draft is fluent and wrong, this code passes tests and will be unmaintainable in a year.

They are not resisting AI. They are refusing to lower their bar. And they are usually right about the specific instance they are objecting to.

Confusing these two groups causes damage in both directions. Steamroll the craftspeople as "resistors" and you lose your quality function precisely when you most need it — while the low performers, who are agreeable in meetings, sail through. Accommodate everyone equally and you let vague objection set the pace for the whole organisation.

The move that works is to make the craftspeople the accountability function. Formally. Give them the job of defining what "good enough to ship" means in their domain, of reviewing where AI output is and is not acceptable, and of setting the standard the champions have to build toward. They tend to take that role seriously, because it is the thing they already cared about.

Once a craftsman's standard is what AI has to clear, they stop being a blocker and become the reason the output is trustworthy. That is also how you tell the two groups apart: give both a quality-ownership role and watch what happens. The craftsman engages. The low performer does not want it.

Zero to hero, in the order that works

Stage 0 — Find the 20%. Do not appoint them. Ask who is already using AI and mean it, with an amnesty for anyone who has been doing it unofficially. You will find them faster than you expect, and you will surface your shadow AI exposure at the same time.

Stage 1 — Pick one workflow, not one department. Something repetitive, high-volume, and owned by a person who wants it fixed. Resist the urge to start with a strategy. One workflow that visibly improves does more for adoption than any all-hands.

Stage 2 — Let the champions build the recipe. Their output is a documented, repeatable workflow with the boundaries written down — not a demo. Have a craftsman from that domain set the quality bar before it ships.

Stage 3 — Give the 70% the recipe, not the technology. Train on the specific workflow with their real work. No model comparisons, no theory. Measure whether the task got faster or better at 30 days.

Stage 4 — Write the rules once it is real. Governance written before you have any AI in production is speculative. Written after the first workflow ships, it is grounded in decisions you have actually had to make. Risk tiers, a named owner, and an explicit prohibition list will cover most of it.

Stage 5 — Repeat, and only then invest in architecture. After three or four workflows you will know where your data is genuinely inadequate and where the integration pain is. That is the point to spend money on the HBS pillars — when you can point at the specific thing they unblock.

Most transformation programmes run this in reverse: architecture, then governance, then training, then a search for use cases. That order is why they take two years and produce a platform nobody uses.

What this actually costs you

Not much money, and quite a lot of management attention.

The expensive part is not tooling. It is giving the 20% real time to build, being honest enough to separate craftsmen from coasters, and accepting that the 70% will only move when someone hands them something specific.

An organisation that does that will end up meaningfully AI-native in behaviour within a year, without ever satisfying the strict definition. An organisation that buys a platform and runs an awareness campaign will satisfy neither.

If you want a view of where to start, that is what an AI Opportunity Sprint is for — and if the constraint is that your people need the capability rather than the plan, that is training built on your own workflows. The related failure modes are worth knowing too: why pilots stall before production, and why training that stops at vocabulary changes nothing.