The AI Vision Gap: What Job Descriptions Don't Tell You

• Tags: medical-ai mlops data-governance hiring startup

You’re looking at an AI job posting.

The company description sounds exciting — personalized medicine, autonomous systems, data-driven everything. You picture a team doing real ML work. Infrastructure. Real data problems.

Then you read the requirements.

Three years of Python. Some PyTorch experience. Git.

Something feels off, but you can’t quite name it.

That gap — between what the company says it’s building and what the job description actually asks for — is one of the most useful signals you can learn to read early in your career.

It’s not just a red flag. It’s a diagnostic tool.

And once you know how to use it, you’ll never read a job posting the same way again.

The Pattern: Vision First, Reality Later

Startups operate on vision. That’s not a criticism — it’s a survival mechanism.

You raise money on vision.
You recruit talent on vision.
You close partnerships on vision.

The problem isn’t that vision exists.

The problem is when vision becomes a substitute for understanding what execution actually requires.

In hardware-first companies, this often works. Build a prototype, show that it functions, iterate. The feedback loop is short, and the failure mode is visible.

In AI, the failure mode is invisible — until it isn’t.

A 3D printer either prints or it doesn’t.

A model trained on improperly consented, poorly annotated, or ungoverned data looks perfectly fine in a demo.
It breaks the moment a serious partner asks for your IRB number.

IRB (Institutional Review Board) — an independent committee that reviews and approves research involving human subjects or their data. In medical AI, IRB approval is required before patient data can legally be used to train models. Without it, the entire dataset is off-limits for training purposes.

What “We’re Doing AI” Actually Means

In practice, companies fall somewhere along a spectrum.

Level 1 — Feature AI

A single model embedded inside a product.

Take a photo, output a measurement.
This can be useful and shippable.

But it is not a platform.
It is not a moat.
It is not an AI company.

Level 2 — AI Narrative

The word “AI” appears in every press release.

The product contains a Level 1 feature.
The roadmap promises a Level 4 future.

The team consists of two engineers.

Level 3 — AI Infrastructure

This is where real AI actually begins.

  • Data pipelines exist
  • Annotation protocols exist
  • IRB coverage exists
  • Models are versioned and monitored
  • Retraining pipelines are defined

The organization understands that models are the smallest part of the system.

Level 4 — AI Compound

At this stage, the company is not just building models.

It is building a data flywheel — a self-reinforcing cycle where more usage generates more data, which trains better models, which drives more usage.

Data governance turns clinical usage into a compounding asset.
Each case improves the next model.
Partners want access to the data infrastructure, not just the software.

The moat is no longer the model.

The moat is the governed dataset.

Most companies that say “AI” are operating at Level 1 or Level 2, while describing a Level 4 future.

The job description is where this gap becomes visible.

If a company is truly building Level 4 AI, the JD will ask about data governance, MLOps architecture, regulatory strategy, system ownership, and team building.

If the JD mostly asks for Python experience and Git familiarity, you’re probably looking at Level 1.

Why MLOps and Data Governance Are Not Optional

This is where most AI roadmaps quietly die.

MLOps (Machine Learning Operations) is not just DevOps for models. It is the operational infrastructure that turns machine learning from a research artifact into a real product — the systems that keep models working after deployment, not just during demos.

Without it, every model update becomes a fire drill.

Core components include:

  • Data versioning — Which data trained this model? Can you reproduce the result six months from now?
  • Model registry — What is deployed right now? What was deployed last month, and why did it change?
  • Monitoring — Is the model performing differently on new data than it did on training data?
  • Retraining pipelines — When performance degrades, can you fix it without an emergency?

Without these systems, regulatory questions become unanswerable and serious partnerships stall before they start.

Upstream of MLOps sits the harder problem: data governance.

In medical AI, the gap between having patient data and being allowed to train on it is enormous — and most companies don’t realize it until it’s too late.

Patient data collected for treatment cannot automatically be used for model training.

Training requires:

  • IRB approval for the specific research use case
  • Explicit informed consent from patients
  • Documented annotation protocols (who labeled the data, with what expertise, using what criteria)
  • Auditable data provenance (where did this data come from, and can you prove it?)

A company claiming to have patient data across 40+ countries is not describing an advantage.

It is describing 40+ regulatory environments — each with its own legal constraints.

GDPR (EU), HIPAA (US), PDPA (Southeast Asia), and local equivalents each introduce requirements that must be designed into the data architecture from the beginning.

This is not a minor technical detail.

It is a multi-year infrastructure problem.

Companies that do not understand this yet usually learn it at the worst possible moment — when they try to submit to the FDA or close a serious clinical partnership.

The Job Market Signal

Once you understand the infrastructure required for real AI systems, hiring conversations start to reveal useful signals.

You can ask these questions in any interview. The answers will tell you more than the job description ever will.

The JD Test

Does the job description match the vision?

If a company claims to build AI-powered personalized medicine but the JD asks only for basic PyTorch experience, there is a theory–practice gap.

Either leadership does not understand the execution requirements, or they are hiring someone to maintain a feature — not build a platform.

The Data Question

Ask: “How is your training data collected, consented, and governed?”

“We have a lot of data” is a Level 2 answer.

A discussion of IRB protocols, consent structures, and annotation governance is a Level 3 answer.

The Regulatory Question

Ask: “What is your FDA or CE Mark strategy for AI features?”

FDA clearance and CE Mark are regulatory approvals required to sell medical software in the US and EU respectively. AI features in medical products face especially strict requirements around data provenance and model validation.

If the answer is specific and operational, the company has thought about it.

If the answer pivots immediately to market opportunity and TAM, they probably haven’t.

The Ownership Question

Ask: “Who owns data quality?”

In mature AI organizations, this has a clear and immediate answer.

In most startups, no one does — which means everyone does — which ultimately means no one does.

Technical Due Diligence Without Being Inside

Multiple hiring processes create an unusual perspective.

You start to see companies from the outside while they are still telling their internal story.

That allows a kind of informal technical due diligence — even as a junior engineer, before you have access to internal systems.

Public filings and investor materials

Capital allocation reveals what a company actually believes.

If 70% of spending goes to marketing while 10–20% goes to technology, the “AI company” narrative becomes easier to interpret.

Job descriptions

The aggregate of open roles reveals actual team structure and real capability gaps — not just the one role you’re applying for.

Partnership announcements

Real AI partnerships require data-sharing agreements, IRB coverage, and regulatory alignment.

Announcements that omit these details often signal the work has not yet started.

Regulatory filings

What has the company actually submitted or received approval for?

SaMD (Software as a Medical Device) — a regulatory classification for software that performs a medical function independently, without being part of a hardware device. AI diagnostic tools are typically classified as SaMD, and face stricter regulatory requirements than AI features embedded inside approved hardware.

AI features integrated into existing hardware approvals face entirely different regulatory pathways than standalone SaMD systems.

This type of analysis won’t catch every issue. But it reliably reveals the most common failure mode: the gap between the story and the infrastructure.

The Real Question

The companies that will close the gap between AI vision and AI reality are not the ones with the most ambitious roadmaps.

They are the ones that understand — before hiring a single AI engineer — that data governance is infrastructure, not a compliance checkbox. That training data is a fundamentally different problem than product data. That regulatory submission requires provenance, annotation quality, and governance designed from day one.

And that the person they actually need is not a PyTorch engineer.

It is a system architect who can connect research, clinical practice, regulation, and engineering into a coherent pipeline.

The vision is often real.
The founders often mean what they say.

But AI companies are not built on vision.

They are built on data pipelines, annotation protocols, IRB approvals, and MLOps infrastructure.

The difference between an AI demo and an AI company is infrastructure.

And the job description is where the vision finally meets the ground.

Read it carefully.

And the job description is often the first place that truth leaks out.