AI in Genomics

What is AI in genomics?

AI in genomics is the use of trained models on sequence, expression and clinical data to answer questions a fixed rule cannot, such as how likely a missense variant is to cause disease or which of several hundred rare variants best explains a patient's symptoms. The output is evidence for a geneticist, not a diagnosis.

The models fall into two broad groups. Variant-level models score one variant at a time from its sequence context and protein structure. Patient-level and cohort-level models combine many variants with phenotype, family history or expression data.

Both groups depend on the pipeline upstream. A model that scores variants well is of little use if variant calls are noisy, so pipeline quality is a precondition, not a separate project.

Which genomic problems suit machine learning?

Machine learning suits genomic problems where the signal is spread across many weak features and labeled examples exist. It suits poorly the problems where a lab already has a clear rule or too few labeled cases.

• Variant effect prediction: Scoring how likely a missense, splice or noncoding variant is to disrupt function, from sequence and structure.
• Phenotype-driven prioritization: Ranking a patient's candidate variants by how well each gene matches the recorded symptoms, so reviewers start at the top of a short list.
• Polygenic scores: Combining many small-effect variants into a risk estimate for a common condition, with careful attention to the ancestry of the training cohort.
• Expression and splicing prediction: Estimating how a variant changes gene expression or splicing, where laboratory measurements are costly.
• Cohort discovery: Finding gene and disease links across large linked genomic and clinical datasets in research settings.
• Report support: Language models drafting plain-language summaries or pulling evidence from literature, with every statement checked by staff.

Start with one use case where the lab already spends reviewer time and where the result can be measured, such as time to a shortlist or the rank of the confirmed causal variant.

How does a model's score enter variant interpretation?

A model's score enters clinical variant interpretation as one piece of computational evidence within the ACMG and AMP framework, never as the classification itself. The geneticist weighs it with population, segregation, functional and clinical evidence.

• ACMG and AMP standards: The 2015 joint standards for interpreting sequence variants (Richards et al.) treat computational predictions as supporting evidence, through criterion PP3 for a predicted damaging effect and BP4 for a predicted benign one.
• AlphaMissense: Published in Science in 2023 by Cheng et al., AlphaMissense predicts the pathogenicity of possible single amino acid substitutions across the human proteome. Like any predictor, a lab has to validate its score ranges before applying them as PP3 or BP4 evidence.

For software teams, this sets the product shape. The model output belongs in the evidence panel next to population frequency and prior assertions, with its version, score and threshold visible, and the classification field stays under the geneticist's control.

Thresholds matter as much as scores. A lab should decide in its validation which score ranges it will apply as supporting evidence, record that decision, and show it in the interface rather than leaving each reviewer to judge a raw number.

What the evidence panel should show

• Score and range: The raw score, the lab's validated range it falls in, and whether that range counts toward PP3, BP4 or neither.
• Model identity: The model name, version and the date the lab approved that version for clinical use.
• Coverage note: A visible flag when the variant type, gene or transcript falls outside what the model was validated on.
• Other predictors: Scores from any other approved predictors, so the reviewer sees agreement or conflict at a glance.
• Audit link: A record of which reviewer saw the score and what classification they signed.

Building the panel this way keeps the geneticist in charge and gives an inspector a clear trail from each report back to the model output behind it.

Building a genomic model step by step

A genomic model is built in seven steps, and most of the effort sits in data and validation rather than in the model architecture.

• 1. Frame the question: Name the decision the model supports, the variant or patient type it covers, and the measure of success, such as rank of the causal variant.
• 2. Assemble labels: Collect labeled examples from curated databases and the lab's own signed-out cases, recording the source and date of each label.
• 3. Split with care: Hold out whole genes or families, not random variants, so the test set does not share information with training data.
• 4. Train and compare: Train the model and compare it against existing predictors on the same held-out set.
• 5. Validate locally: Test on the lab's own sample types, sequencing platforms and patient population, and report performance by ancestry group.
• 6. Calibrate and set thresholds: Turn raw scores into ranges the lab will use, and write them into the validation record.
• 7. Deploy as annotation and monitor: Run the model as a versioned annotation step, log every score it produces, and re-check performance when labels or inputs change.

Step 7 ties the model back to the pipeline without becoming part of it. The model reads variant calls and writes annotations, and its version is stored with every report that used it.

Where genomic AI models fail

The main risks in a genomic model come from the data it learns from. Check these failure points before any clinical use.

• Circular evaluation: The test variants were already used to train the predictor or to build the database the labels came from, which inflates accuracy.
• Gene leakage: Variants from the same gene sit in both training and test sets, so the model learns the gene rather than the variant.
• Ancestry gaps: Training data under-represents many populations, so performance drops for patients whose ancestry differs from the cohort.
• Label drift: Variant classifications in public databases change over time, and a model trained on old labels silently disagrees with current ones.
• Silent version changes: A predictor is updated in the annotation step without re-validation, and reports from the same week use different scores.
• Fluent but wrong text: A language model writes a plausible variant name or citation that does not exist.

Each failure point has a software control: frozen test sets, gene-level splits, stratified reporting, label snapshots with dates, version pinning and automated checks of variant nomenclature against reference data.

How should genomic AI be governed?

Genomic AI should be governed with a written risk framework, clear data rules and an audit trail that links every report to the model version behind it. The NIST AI Risk Management Framework (AI 100-1, January 2023) organizes this work into four functions: govern, map, measure and manage.

• Govern: Name the lab director or committee that approves a model for use and signs off each version change.
• Map: Record intended use, excluded uses, training data sources and known limits for each model.
• Measure: Keep validation results, ancestry-stratified performance and drift checks on file.
• Manage: Define what happens when a model underperforms, from raising a threshold to switching it off.

Data rules sit alongside the framework. Identifiable genomic results held by a covered entity or its business associate are protected health information, so any cloud service that stores or processes them needs a business associate agreement. Research data often carries extra terms from consent forms and data use agreements.

Genomic data also identifies relatives, who never consented. Restrict raw data access to named roles, log every export, and prefer sending models to the data over copying data to the model.

Whether a given model is a regulated medical device depends on its intended use and how its output is presented. Settle that with regulatory counsel before a clinical launch, not after.

Build, license or use a public model?

A lab should usually start with published or licensed models and build its own only where its data gives it an edge. The choice turns on data, validation effort and control.

• Public model: Fits variant effect scoring where published scores exist. Cost is local validation and threshold setting.
• Licensed tool: Fits phenotype-driven prioritization and report drafting when a vendor offers validation support and data terms the lab accepts.
• Fine-tuned model: Fits a lab with many signed-out cases in one disease area that public models handle poorly.
• Custom model: Fits research programs or large health systems with linked genomic and clinical data and a team to maintain it.

Whichever route you take, the platform around the model stays the same: versioned annotation, evidence display, validation records and audit logs.

How Agnotic can help

The model is often the smaller part of a genomic AI project. Agnotic Technologies builds the software around it for labs and precision medicine teams: the annotation service that runs models as versioned steps, evidence panels for geneticists, validation and drift dashboards, and secure data platforms with access controls and audit logs.

Your geneticists and lab directors own the clinical validation and the classification. Agnotic builds the tools that record their decisions and keep each report traceable to its evidence.

Sources

• Richards et al., Standards and guidelines for the interpretation of sequence variants, ACMG and AMP (2015)
• Cheng et al., Accurate proteome-wide missense variant effect prediction with AlphaMissense, Science (2023)
• NIST: AI Risk Management Framework (AI 100-1)