Bad Data Now Moves at AI Speed
Why “garbage in, garbage out” has become an enterprise-scale business risk rather than an old technical warning
Article 2 of the six-part series, One Job, Not Three: The New Reality of Data Leadership in the Age of AI.
This article is adapted from One Job, Not Three: How AI Collapsed Data Governance, Data Strategy, and Data Quality Into a Single Discipline.
Bad data used to wait for someone to use it.
Now it acts.
It approves.
It rejects.
It recommends.
It ranks.
It prices.
It communicates.
It initiates the next workflow before anyone has confirmed whether the first decision was correct.
The underlying data defect may still look small.
A missing field.
An outdated customer status.
A duplicated account.
A product code mapped to the wrong category.
A definition interpreted differently by two business units.
But the consequences no longer remain inside a report waiting for an analyst to notice them.
AI gives the defect speed.
Automation gives it scale.
And the confidence of a machine-generated response can make the result appear more reliable than the data supporting it.
That is what has changed.
The old warning was simple:
Garbage in, garbage out.
The new reality is more dangerous:
Garbage in, decisions out.
One field, eighteen thousand decisions
Imagine a financial-services company introducing an AI-supported system to identify customers who may benefit from a new product.
The pilot performs well.
The model identifies promising segments.
The presentation to senior leadership is clear.
The estimated revenue opportunity is significant.
The team receives approval to move forward.
Within several weeks, thousands of customers receive personalized recommendations.
The messages are polished.
The timing appears deliberate.
The offers seem individually selected.
But one of the customer-status fields feeding the system has not been updated reliably.
Some customers marked as active are no longer active.
Some customers marked as eligible do not meet the current requirements.
Several records belong to people who previously asked not to receive promotional communications.
A small number belong to customers whose circumstances make the offer inappropriate.
The AI system did not create the original data defect.
It did exactly what it was designed to do.
It processed the available records.
It identified patterns.
It applied the business rules it had been given.
It produced recommendations at a volume no human marketing team could have achieved manually.
That is the problem.
The system did not merely inherit the defect.
It industrialized it.
A human employee working through the same customer list might have noticed inconsistencies.
She might have recognized a familiar account.
He might have paused when two fields contradicted each other.
A supervisor might have reviewed a sample before the campaign expanded.
The process would have been slower.
But slowness sometimes created an accidental control.
Automation removes that control.
By the time the first customer complains, eighteen thousand decisions may already have been made.
The old warning assumed a human was still in the loop
“Garbage in, garbage out” came from an era when flawed data usually produced a flawed output.
A report contained the wrong total.
A forecast missed its target.
A mailing list included duplicate names.
A dashboard displayed inconsistent numbers.
These problems mattered.
They could lead to poor decisions, wasted spending, regulatory exposure, or customer frustration.
But the output often reached a human being before it produced an action.
Someone still had to read the report.
Someone still had to approve the forecast.
Someone still had to authorize the campaign.
Someone still had to decide what the number meant.
The data defect and the business consequence were separated by a person.
That person was not a perfect safeguard.
Human beings miss errors.
They accept familiar numbers.
They rush.
They defer to authority.
They sometimes ignore warnings because the result supports what they already wanted to do.
But the human step created time.
It created friction.
It created another opportunity for the inconsistency to become visible.
AI compresses the distance between information and action.
The system reads the data and produces the decision.
In more advanced environments, it may also execute that decision.
The flawed output is no longer the end of the process.
It becomes the beginning of another automated process.
One incorrect classification influences a recommendation.
The recommendation triggers a message.
The message changes customer behavior.
The customer response updates another system.
That new record becomes training or operational data for the next decision.
The original defect does not remain isolated.
It enters a loop.
AI does not merely consume data
Many organizations still discuss data quality as though AI were another reporting tool.
The assumption is that the model sits at the end of the data pipeline, receives a prepared dataset, and produces an output for someone to evaluate.
That model is already outdated.
AI systems increasingly operate inside business processes rather than at the edge of them.
They retrieve information.
They generate content.
They classify requests.
They prioritize cases.
They recommend actions.
They call other systems.
They update records.
They initiate transactions.
They influence the data that future systems will use.
This means AI does not simply consume the organization’s data environment.
It participates in it.
A recommendation engine changes what customers see.
What customers see changes what they select.
Those selections become new behavioral data.
That behavioral data influences the next recommendation.
The system is no longer standing outside the process and analyzing it.
It is shaping the process it will later analyze.
When the original data is reliable, this loop can improve performance.
When the original data is distorted, incomplete, or biased, the loop can reinforce the distortion.
The system becomes increasingly confident in a reality it helped create.
The velocity multiplier
Data quality risk has traditionally been evaluated by asking questions such as:
How many records are affected?
Which fields are incorrect?
Which reports use them?
What financial or regulatory impact could result?
Those questions remain important.
But AI introduces another variable:
How quickly can the defect become a decision?
A quality problem affecting one hundred records may be manageable when those records are reviewed manually over several weeks.
The same problem becomes more serious when an automated system processes all one hundred records in a minute.
The defect did not become larger.
Its decision velocity increased.
This is the multiplier many organizations have not yet incorporated into their risk models.
A defect with low volume but high decision velocity may be more dangerous than a high-volume defect sitting inside an archived reporting system.
A stale customer status used once in a quarterly analysis is a problem.
The same stale status used by a real-time service agent is an operational risk.
A mismatched product code in a monthly spreadsheet is inconvenient.
The same code used by an automated pricing engine can affect thousands of transactions before the mismatch is detected.
A missing consent indicator in a static database is a governance issue.
The same missing indicator inside an AI-driven communication platform can become a customer, legal, and reputational event.
The meaning of data quality now depends not only on what is wrong.
It depends on what the system is allowed to do with it.
The defect-to-decision distance
Every automated use case has a distance between the source defect and the business consequence.
In some processes, that distance remains long.
The data enters an analytical environment.
A report is produced.
A business leader reviews it.
A meeting is scheduled.
A decision is debated.
An action is approved.
There are several opportunities for questions to surface.
In other processes, the distance is almost zero.
The data enters the system.
The system decides.
The system acts.
The difference between those two environments should determine the level of data assurance required.
But many organizations apply the same quality controls to both.
They validate the pipeline.
They check whether the fields arrived.
They confirm that the job completed.
They monitor whether the model is running.
Those controls can prove that the system is operating as designed.
They cannot prove that the underlying business meaning is correct.
A pipeline can complete successfully while delivering the wrong customer status.
A model can perform within its technical thresholds while acting on outdated eligibility rules.
An AI agent can execute every required step while using a definition that one business unit interprets differently from another.
Technical success is not the same as decision reliability.
The closer the defect is to the decision, the less tolerance the organization should have for ambiguity.
Accuracy is only one part of trust
When executives hear “data quality,” they often think about accuracy.
Is the value correct?
That is necessary.
It is not sufficient.
AI systems can fail because the data is incomplete.
A customer profile may be technically accurate but missing the information needed to understand the full situation.
They can fail because the data is late.
A status was correct yesterday but changed this morning.
They can fail because the data is inconsistent.
Two systems may contain valid values that represent different versions of the same business event.
They can fail because the definition is unclear.
“Active customer,” “qualified lead,” “high-risk account,” and “successful outcome” may mean different things across departments.
They can fail because the context has been removed.
A value may be correct inside the process that created it but misleading when reused for another purpose.
They can fail because lineage is incomplete.
The organization may know the current value without knowing where it originated, how it was transformed, or which controls were applied along the way.
A model can produce a technically sophisticated answer from data that is accurate but inappropriate for the decision being made.
That answer may still be wrong.
Not computationally wrong.
Organizationally wrong.
The danger of polished output
Bad data rarely announces itself.
It does not arrive with a warning label.
It often arrives inside a polished dashboard, a professionally written summary, or a confident recommendation.
Generative AI intensifies this problem because it can transform weak inputs into strong-sounding language.
The grammar is correct.
The structure is clear.
The recommendation appears reasoned.
The explanation includes details.
The tone resembles expertise.
The output may look more credible than the underlying evidence deserves.
This creates a new kind of organizational vulnerability.
People may question a messy spreadsheet.
They may challenge a report with visible gaps.
They may ask where an analyst found an unusual number.
They are less likely to challenge a coherent response delivered instantly by a system presented as intelligent.
The output does not have to be correct to feel authoritative.
It only has to be fluent.
The organization may begin treating presentation quality as evidence quality.
Those are not the same thing.
A system can communicate a weak conclusion exceptionally well.
When confidence becomes part of the risk
Human decision-makers usually communicate uncertainty through behavior.
They hesitate.
They qualify their statements.
They say they need more information.
They ask someone to confirm the number.
AI systems do not always expose uncertainty in ways business users understand.
A recommendation may appear in the same format whether the supporting data is complete or fragmented.
A summary may use the same confident language whether the source records agree or contradict one another.
A classification may be delivered as a category even when the underlying evidence barely supports the threshold.
This produces a dangerous mismatch.
The organization sees certainty.
The system may only have probability.
The user sees a recommendation.
The data may only support a hypothesis.
The executive sees an answer.
The sources may contain unresolved conflicts.
When data quality is weak, confidence presentation becomes part of the control environment.
It is not enough to ask whether the system produced the correct answer during testing.
Leaders must also ask:
How will the system communicate that the evidence is weak?
When will it abstain from deciding?
When will it request human review?
What happens when two trusted sources disagree?
Which decisions require explanation before action?
What evidence will be preserved after the decision is made?
An AI system that never says “I do not know” may appear productive.
It may also be operating without a safe boundary.
The false comfort of model accuracy
Organizations often focus heavily on model performance.
Accuracy.
Precision.
Recall.
Error rates.
Benchmark results.
These measures matter.
But they can create false confidence when separated from data quality.
A model may perform well against the dataset used to test it.
That does not guarantee that production data will have the same quality, context, or distribution.
The test environment may contain carefully prepared records.
The production environment may contain duplicates, delayed updates, conflicting identifiers, and undocumented exceptions.
The model may be technically sound.
The operational data may not be.
When outcomes deteriorate, teams may respond by tuning the model.
They adjust parameters.
They change prompts.
They add examples.
They compare vendors.
They introduce another review layer.
Those interventions may improve performance.
But they may also treat a data problem as a model problem.
No amount of prompt engineering can make a missing business event appear.
No algorithm can reconcile two definitions the organization has never resolved.
No model can determine which source is authoritative when leadership has avoided making that decision.
No technical optimization can replace ownership.
The model may be the visible component.
The data operating beneath it determines what the model is capable of knowing.
The quality problem moves beyond the data team
In a traditional reporting environment, data quality failures were often contained within technical or analytical teams.
A report failed.
A reconciliation broke.
A business analyst opened a ticket.
A data engineer traced the issue.
A source-system owner was contacted.
The process might have been slow and frustrating, but the defect still had an identifiable home.
AI moves data quality into customer service, operations, pricing, hiring, fraud detection, sales, supply chains, healthcare administration, and employee management.
The data defect now appears as a business action.
A customer receives the wrong offer.
A candidate is ranked lower.
A claim is routed incorrectly.
A legitimate transaction is flagged.
A vulnerable account is overlooked.
An employee is assigned the wrong risk category.
A supplier is deprioritized.
By the time the organization recognizes the issue, it may no longer look like a data problem.
It looks like a customer complaint.
A revenue decline.
A compliance incident.
An employee-relations matter.
A reputational event.
An AI ethics concern.
A model-performance failure.
The cause may still begin with data.
But the consequences are distributed across the enterprise.
This is why data quality can no longer be treated as a technical service the business calls after something goes wrong.
It has become part of operational risk management.
The first error may not be the largest one
AI systems can amplify defects through repetition.
But they can also amplify them through learning.
Suppose a system begins with incomplete information about which customer inquiries are urgent.
It prioritizes certain categories.
Employees respond faster to those cases.
Those cases therefore generate better outcomes.
The system later interprets those improved outcomes as evidence that its original prioritization was correct.
Meanwhile, lower-priority cases receive slower responses.
Their outcomes decline.
That decline appears to confirm that they were lower-value cases.
The system is no longer merely reflecting the original data.
It is producing the evidence that will validate its next decision.
A weak assumption becomes a workflow.
The workflow becomes an outcome.
The outcome becomes new data.
The new data strengthens the original assumption.
This is how small quality problems become structural.
The first incorrect decision may affect one person.
The larger risk is the pattern the system learns from that decision.
Governance after deployment is too late
Many organizations review AI risk at specific approval points.
The use case is proposed.
A committee reviews it.
Legal and compliance provide input.
The model is tested.
The initiative receives approval.
This process creates the impression that governance occurs before deployment and monitoring occurs afterward.
But AI risk does not remain fixed after approval.
Source systems change.
Definitions change.
Business rules change.
Customer behavior changes.
Vendors update models.
New data is introduced.
Workflows are modified.
Employees find unanticipated uses for the system.
A use case that was appropriate six months ago may behave differently today even if no one formally changed its purpose.
The original approval was based on a specific combination of data, technology, controls, assumptions, and business context.
When that combination changes, the risk changes.
Governance must therefore operate continuously.
Not as a policy document stored beside the project charter.
Not as a quarterly committee discussion.
Not as a one-time checklist completed before launch.
The controls must live close to the decision.
Quality thresholds.
Data-contract enforcement.
Lineage visibility.
Change detection.
Exception routing.
Human-review requirements.
Decision logs.
Automatic stop conditions.
The organization cannot govern AI solely by approving its beginning.
It must govern what the system becomes.
The temptation to scale the pilot
AI pilots often succeed because they operate inside controlled conditions.
The use case is narrow.
The data is selected carefully.
The participants are motivated.
The volume is manageable.
Subject-matter experts remain close to the work.
Exceptions receive immediate attention.
The pilot may genuinely demonstrate value.
The danger begins when leadership assumes that scaling means doing the same thing with more records.
It does not.
Scale changes the quality problem.
Rare exceptions become frequent in absolute numbers.
Small error rates affect more people.
Source-system differences become visible.
Manual corrections become unsustainable.
Informal knowledge held by the pilot team does not transfer automatically.
The system encounters customer situations, regional variations, product combinations, and process histories that were not represented during testing.
A model that performs well across one thousand carefully selected cases may behave differently across ten million operational records.
The question is not simply:
Did the pilot work?
The better questions are:
What protected the pilot from the organization’s normal data conditions?
Which manual interventions were required?
Which exceptions were resolved by people who will not be available at scale?
Which source systems were excluded?
What data preparation occurred before the model received the information?
Which assumptions become unsafe when volume increases?
A successful pilot proves that value may be possible.
It does not prove that the enterprise is ready to industrialize the decision.
The quiet tradeoff nobody approved
When organizations move quickly, they often accept data risk without naming it.
The team knows that customer identifiers are inconsistent.
The business knows that ownership is unclear.
The data leader knows that lineage is incomplete.
The project team knows that several source fields are not reliable.
But the launch date has already been announced.
The executive sponsor expects a demonstration.
The budget depends on visible progress.
So the organization moves forward.
The risk is described as manageable.
A later phase will resolve it.
A human will remain involved.
The model will only make recommendations.
The affected records represent a small percentage.
The team will monitor performance.
Each statement may be reasonable.
But together they can conceal an unmade decision.
How much data uncertainty is the organization willing to accept in exchange for speed?
Someone is already answering that question through the project timeline.
The answer simply has not been stated as an executive risk decision.
This matters because unnamed tradeoffs are difficult to govern.
If the initiative succeeds, the unresolved issue may be ignored.
If it fails, the data team may be blamed for not resolving a risk everyone knew existed.
The purpose of data leadership is not to eliminate every imperfection before the organization acts.
That would be impossible.
The purpose is to make the tradeoff visible enough that the right people consciously accept it.
Not all data requires the same level of perfection
The response to AI risk cannot be that all enterprise data must be flawless.
No organization can achieve that.
Not every data element carries equal business consequence.
A formatting inconsistency in an internal reference field is not equivalent to an incorrect eligibility status.
A delayed marketing preference is not equivalent to a delayed fraud indicator.
A duplicated test record is not equivalent to a duplicated customer identity used in a credit decision.
The goal is not universal perfection.
The goal is decision-appropriate reliability.
Data leaders must distinguish between data that is useful and data that is safe to automate.
Useful data may support exploration.
It may help identify patterns.
It may guide a conversation.
It may generate hypotheses.
Decision-grade data carries a higher burden.
Its ownership must be known.
Its meaning must be stable.
Its lineage must be visible.
Its limitations must be understood.
Its quality must be monitored at the speed of the process using it.
The organization does not need every field to meet the same standard.
It needs the most consequential fields to meet the standard required by the decision.
The decision-critical data map
Before scaling an AI use case, leaders should identify the data elements capable of changing the outcome.
Not every field entering the system is decision-critical.
Some provide context.
Some improve personalization.
Some are operationally convenient.
Others determine whether the system approves, rejects, prioritizes, escalates, prices, communicates, or acts.
Those fields deserve special treatment.
For each decision-critical element, the organization should be able to answer:
Who owns its business meaning?
Which system is authoritative?
How quickly must it be updated?
What quality threshold must it meet?
What happens when it is missing?
What happens when two sources disagree?
Which decisions depend on it?
How will the organization know when its quality deteriorates?
Who has authority to stop the automated process?
These questions convert data quality from a broad aspiration into an operational control.
They also expose gaps that traditional project plans may hide.
A field may exist.
A pipeline may deliver it.
A model may use it.
But no one may have authority to decide what it officially means.
That is not a technical detail.
It is an unresolved business decision sitting inside an automated system.
The stop condition
Most AI strategies focus on how the system will begin operating.
Fewer define the conditions under which it must stop.
What level of missing data is unacceptable?
How much source delay invalidates the decision?
Which drift pattern triggers review?
How many contradictory records can the system tolerate?
Which customer, financial, regulatory, or safety impact requires immediate suspension?
Who can activate the stop?
Can the process be paused automatically, or must someone request executive approval while the system continues running?
A mature AI environment does not assume that monitoring alone is sufficient.
A dashboard may show that quality has declined.
Someone still has to decide what happens next.
If the response requires several meetings, the organization does not have a real-time control.
It has real-time visibility into a problem it cannot stop.
The ability to halt an automated decision is part of data governance.
Without it, the organization has monitoring without authority.
The first question before scaling AI
Before approving the next AI initiative, ask:
What happens when the data is wrong?
Not whether the data could be wrong.
It will be.
Not whether the team has quality checks.
It should.
Ask what the system will actually do when a decision-critical field is missing, stale, contradictory, misclassified, or outside its expected range.
Will it continue?
Will it estimate?
Will it substitute another source?
Will it warn the user?
Will it route the case to a human?
Will it preserve the evidence used?
Will anyone know that the decision was made under uncertainty?
Then ask the question organizations often avoid:
How many wrong decisions can this process make before we notice?
The answer may be one.
It may be one hundred.
It may be eighteen thousand.
That number tells you more about the real risk than a general statement that the organization takes data quality seriously.
Data quality has become decision quality
AI has not made data quality newly important.
Data quality was always important.
AI has changed the speed, scale, visibility, and consequences of getting it wrong.
The defect no longer waits inside a table.
It travels.
It enters a recommendation.
It becomes a workflow.
It reaches a customer.
It changes behavior.
It creates new data.
It influences the next decision.
The old model treated data quality as a condition to improve.
The new model must treat it as a control over enterprise action.
This is why governance, strategy, and quality can no longer operate as separate disciplines.
Strategy selects the decisions the organization wants to automate.
Governance establishes which uses are permitted and who is accountable.
Quality determines whether the available data is reliable enough for the system to act.
Remove any one of the three and the organization becomes unstable.
Strategy without governance scales exposure.
Governance without quality creates policies the data cannot support.
Quality without strategy improves information without knowing which business decisions matter most.
AI forces the three functions into the same moment.
The moment the machine acts.
The organization does not merely need better data.
It needs to know which data can safely become a decision.
Because bad data no longer produces a bad report that someone may eventually correct.
Bad data now moves at AI speed.
And by the time the organization sees the first visible error, the system may already be using that error to decide what happens next.
In Article 3, we will examine why traditional data governance cannot keep pace with this environment—and why governance must move out of the committee room and into the operating systems where decisions are actually made.
Read the book: One Job, Not Three: How AI Collapsed Data Governance, Data Strategy, and Data Quality Into a Single Discipline
For data leaders: Which data element in your organization could create the greatest harm if an AI system acted on it before a human discovered it was wrong?
About the Author
Byron K. Veasey is a career strategist and leader in data quality engineering focused on helping professionals navigate job searches, burnout, and career reinvention.
He writes Career Strategies, a Substack newsletter read by over 4,900 professionals navigating today’s evolving job market.
👉 Subscribe to Career Strategies