You're building an AI system for credit decisions, and your compliance team just asked: "Can you explain why the model declined this applicant?" This raises a crucial question: Do you invest in data lineage infrastructure before tackling model explainability, or can you build explainability tools and retrofit lineage later?
This isn't just theoretical. SR 11-7 requires documentation of data sources and transformations as part of model validation. The EU AI Act demands transparency about training data for high-risk systems. With limited resources, you need to decide where to start.
The Decision You're Facing
Your choice boils down to three paths:
Path A: Build comprehensive data lineage first, then layer explainability on top
Path B: Implement model-level explainability tools first, address lineage gaps as you find them
Path C: Run parallel workstreams for both capabilities
Each path has different risks, timelines, and resource requirements. Your decision depends on four key factors.
Key Factors That Affect Your Choice
Regulatory Timeline
If you're subject to the EU AI Act's high-risk provisions, you'll need to demonstrate data governance controls within specific timelines. Systems already in production face tighter deadlines than new projects. SR 11-7 validation requirements apply immediately to any model supporting a significant business decision.
Count backward from your compliance deadline. If you have less than six months, you can't afford to sequence these efforts. If you have 18 months or more, you can make strategic choices about ordering.
Current Data Infrastructure Maturity
Can you answer these questions right now:
- Where did this training record originate?
- When was this feature value last verified against a source system?
- What transformations occurred between source and model input?
If you can't answer all three for every data point, your lineage gaps are severe. If you can answer most but not all, you have partial infrastructure.
Model Complexity and Count
A single logistic regression model for fraud scoring has different lineage needs than an ensemble of gradient boosting models feeding a credit decision workflow. If you're running dozens of models across multiple business lines, lineage becomes infrastructure. If you're operating three models in a controlled environment, you might manage lineage through documentation.
Incident History
Have you faced a regulatory inquiry where you couldn't trace a data point's origin? Have auditors flagged data quality issues in model validation? Have you discovered training data contamination after deployment? Prior incidents reveal your weakest link.
Path A: Lineage-First Approach
Choose this path when:
- You're building new AI capabilities from scratch
- You have 12+ months before regulatory deadlines
- Your data comes from multiple source systems with varying quality
- You've experienced data quality incidents in existing models
- Your organization lacks centralized data governance
Implementation Sequence
Start by cataloging every data source that feeds or could feed AI models. Document the system of record, refresh frequency, and verification process for each source. Build metadata capture into your data pipelines so that every transformation creates an audit trail.
You'll need tools that track data lineage automatically. Manual documentation doesn't scale past three or four models. Look for solutions that integrate with your existing data platforms and version control systems.
Next, establish verification checkpoints. A bank must show where a data point came from, when it was last verified, and what changed since. Build these verification steps into your feature engineering pipelines.
Only after you can trace every input back to its source should you add model-level explainability. At that point, you'll be explaining decisions based on data you can defend.
Trade-offs
This path takes longer to deliver your first explainable model. You're building infrastructure before capability. But when you do deploy, your explanations carry weight because you can substantiate the underlying data.
You'll also discover data quality issues early, before they contaminate model training. Expect to find duplicates, stale records, and undocumented transformations. Fixing these problems delays model deployment but prevents validation failures later.
Path B: Explainability-First Approach
Choose this path when:
- You have models already in production that need explanation capabilities now
- Regulatory pressure focuses on model outputs rather than data provenance
- Your data comes from a small number of well-controlled sources
- You need to demonstrate progress on AI transparency within 3-6 months
- Your organization has mature data governance in other contexts
Implementation Sequence
Deploy model explainability tools (SHAP values, attention weights, counterfactual generators) for your highest-risk models first. Focus on generating explanations that satisfy immediate stakeholder needs: regulators, auditors, customers challenging decisions.
As you generate explanations, document every case where you can't verify an input feature. When SHAP analysis shows that "employment_length" drove a credit decision, can you confirm that value came from a verified source? Create a backlog of lineage gaps.
Prioritize lineage work based on feature importance. If a feature consistently appears in top-5 SHAP rankings across decisions, you need ironclad lineage for that data point. If a feature rarely influences decisions, lineage documentation can wait.
Trade-offs
You'll deliver explainability faster, but your explanations may not withstand deep scrutiny. When an auditor asks "How do you know this employment length is accurate?", you might not have an answer.
You're also building technical debt. Retrofitting lineage into existing pipelines is harder than building it from the start. Expect to refactor data flows as you discover gaps.
This path works if you're facing immediate explainability requirements but have flexibility on data governance timelines. It doesn't work if SR 11-7 validation or EU AI Act conformity assessment is imminent.
Path C: Parallel Workstreams
Choose this path when:
- You have sufficient team capacity to run concurrent efforts
- Your regulatory timeline is tight (6-12 months)
- You're deploying multiple models with varying risk levels
- You can assign dedicated resources to data infrastructure and model development
Implementation Sequence
Split your team. One group builds lineage infrastructure for all data sources. Another group implements explainability for models already in production or near deployment.
The two groups must communicate constantly. Model developers flag features they can't explain due to lineage gaps. Data engineers prioritize lineage work based on model feature importance.
Set integration milestones every 4-6 weeks where you assess: Can we now explain this model's decisions with verified data? If not, what's blocking us?
Trade-offs
This path demands more resources and coordination overhead. You'll need strong program management to prevent the workstreams from drifting apart. But you'll reach full capability (explainable models with verified data) faster than sequential approaches.
The risk is partial delivery. If either workstream falls behind, you end up with explainability without lineage or lineage without explainability. Neither state satisfies regulatory requirements.
Summary Matrix
| Factor | Path A (Lineage First) | Path B (Explainability First) | Path C (Parallel) |
|---|---|---|---|
| Timeline to first explainable model | 12-18 months | 3-6 months | 6-12 months |
| Resource intensity | Moderate | Low | High |
| Technical debt risk | Low | High | Moderate |
| Regulatory audit readiness | High (when complete) | Low (initially) | Moderate (throughout) |
| Best for | Greenfield AI programs | Existing models needing quick explainability | Tight deadlines with adequate resources |
| SR 11-7 validation support | Strong | Weak until lineage added | Moderate |
| EU AI Act conformity readiness | Strong | Weak for Technical Documentation (Annex IV) | Moderate |
Your choice isn't permanent. Many organizations start with Path B to address immediate needs, then transition to Path A as they mature. But understand what you're trading: speed now for validation risk later, or infrastructure investment now for defensible explanations later.
The wrong choice is doing neither. An AI system you can't explain, built on data you can't verify, won't survive regulatory scrutiny. Pick your path, commit resources, and execute.
