Messy data is normal in midsized companies. It’s what happens when teams buy tools at different times, processes change faster than documentation, and “we’ll clean it later” quietly becomes a habit.
But GenAI doesn’t wait for your data to behave.
People start using it anyway. They paste customer tickets into public tools. They summarize internal docs in browser extensions. It feels harmless—until it isn’t. Now you have a data exposure problem and an output trust problem, both at once.
So the real question isn’t, “Is our data perfect?”
It’s: How do we ship GenAI without turning messy data into messy decisions?
A practical answer is simple: minimum required data + one workflow + phased connections + guardrails. At Amazatic, this is the only approach that survives real delivery pressure—because it’s built around how companies actually operate, not how they wish they operated.
The “clean everything first” trap
“Fix the data first” sounds responsible. It also tends to turn into a multi-quarter program with unclear finish lines.
A few numbers make the problem concrete:
- One survey found data professionals spend about 40% of their time evaluating or checking data quality.
- Another reported 70% of time going into prepping external datasets and only 30% into analysis.
- Data downtime has been reported as doubling year over year, costing roughly two days per week per engineer in firefighting in one survey context.
So if your GenAI plan depends on “cleaning everything,” you’re betting your timeline on the hardest work your teams already struggle to make time for.
And poor data quality carries real business cost:
- A commonly cited Gartner estimate puts it at $12.9M per year in rework and lost productivity (average organization).
- Other findings frame impact as revenue loss or revenue impact in the 15–25% band in some contexts, and 31% average revenue impact in another.
Different sources measure this differently, but the direction is consistent: bad data quietly taxes every team.
So yes, data matters. But “clean it all first” is often a polite way to delay shipping.
GenAI needs less data than your data lake suggests
GenAI doesn’t need “all enterprise data.” It needs the right context for a specific decision inside a specific workflow.
That’s where Minimum Viable Data (MVD) helps. MVD is not a new platform. It’s a shortlist: the smallest set of sources and fields required to make GenAI useful and safe in one workflow.
A simple analogy: if your car has a flat tire, you don’t rebuild the whole car. You swap the tire, tighten the bolts, and get moving. Then you decide what else needs work. Same idea.
“Minimum viable” sounds vague. Here’s how to make it specific.
Start with one workflow that repeats weekly (or daily). Then identify the “decision moment” where people get stuck.
Most MVD lists fall into six buckets:
- System of record
Where the work is tracked. Tickets, CRM, ERP, service desk. If GenAI can’t see the work item, it can’t help. - Stable identifiers
Ticket ID, customer ID, order ID, SKU, asset ID. Without stable IDs, connecting context becomes guesswork. - A small truth set
The approved docs people already trust: SOPs, policies, product notes, troubleshooting steps, pricing rules. - A few context fields that drive action
Priority, SLA, product, entitlement, region, account tier. Not everything. Just what changes the next step. - A feedback signal
Accepted vs edited, resolved vs reopened, escalated vs closed, time-to-close. Without feedback, quality doesn’t improve. - Access boundaries
Who can retrieve what. Where PII exists. What must be masked. What must never leave the boundary.
This list is boring on purpose. Boring ships.
One workflow example: Support ticket assist (without connecting “everything”)
Let’s use a workflow almost every midsized company recognizes: customer support.
The use case: draft a response, summarize history, and pull the right troubleshooting steps.
If your data is messy, you don’t start by connecting every system. You start with the minimum.
Minimum sources to start (for this workflow)
- Ticketing system (ServiceNow, Zendesk, Freshdesk, Jira Service Management)
Ticket text, category, priority, SLA, product, customer ID, status history. - Knowledge base (Confluence, SharePoint, Notion)
Approved troubleshooting steps, known issues, standard replies, policy language. - Entitlement / plan table (CRM, billing, subscription DB)
Support tier, exclusions, what’s allowed.
That’s enough to deliver value because the output is grounded in the same materials your best agents already use—just faster and more consistent.
In real support deployments, reported outcome bands include 25–30% drops in cost per ticket in some cases, along with strong improvements in resolution speed in others.
The point is not to chase the biggest dataset. The point is to reduce human back-and-forth inside the workflow.
Phase it, or you’ll regret it later
Phasing is the difference between a demo and something people rely on. This is the rollout plan that helps you ship safely and expand without breaking trust.
Phase 0: Prove the workflow setup
- Connect tickets + KB as read-only.
- Pick a metric leadership will respect: time-to-first-response, time-to-resolution, reopen rate.
- Log what was retrieved and what was suggested.
Phase 1: Make it safe before you make it broad
This is where teams slip.
Ungrounded answers are a trust killer. Comparative tests across multiple LLMs have shown hallucination rates spanning roughly 15–52% depending on the model and query type.
So Phase 1 is about control:
- Mask PII before prompts.
- Enforce retrieval access (RBAC/ABAC) so people only see what they’re allowed to see.
- Require “show your sources” in outputs (no source, no send).
- Block obvious prompt-injection patterns in retrieved text.
Phase 2: Add only the missing joins (one at a time)
Bring in the next dataset only if it changes the outcome:
- Entitlements, if tier mistakes cause escalations
- Past resolved tickets (last 6–12 months), filtered by product and issue type
- Asset registry or product version table, if troubleshooting depends on configuration
A useful rule: if a dataset doesn’t change the next action, it’s not “minimum.”
Phase 3: Close the loop with feedback
If the system can’t learn from real use, trust won’t grow.
- Track edits agents make
- Track outcomes (resolved, escalated, reopened)
- Build a small evaluation set from real tickets and expected good replies
Phase 4: Expand sideways
Only after the workflow is stable:
- Refund approvals
- Warranty checks
- Renewals and plan changes
Same pattern. Same controls. Same measurement.
And here’s the twist: data quality work gets easier after this. Now you’re not cleaning data “in general.” You’re fixing specific fields that block a proven workflow.
Quick tangent: shadow AI is already in your building
Even if you don’t “officially” ship GenAI, people use it.
There are stats showing 223 average monthly policy violations per organization tied to AI-related data security incidents in one reporting context.
Another finding notes 15% of employees routinely access GenAI on corporate devices, which increases leak risk when sensitive content goes into external tools.
So the choice isn’t “GenAI or no GenAI.” It’s “controlled GenAI or uncontrolled GenAI.”
That’s why guardrails are not “extra.” They’re the base:
- Retrieval access control
- PII masking
- Audit logs you can review
- Output traceability to sources
- Human review where the blast radius is high (contracts, payouts, compliance)
A more realistic way to lead GenAI in a midsized company
If there’s one takeaway here, it’s this: GenAI doesn’t require perfect data. It requires responsible design.
In a midsized company, you won’t get the luxury of cleaning every dataset, reconciling every definition, and standardizing every tool before shipping. And pushing that ideal too hard can create its own risk—because teams still use GenAI in unofficial ways while leadership waits for the “right time.”
So the practical move is to make GenAI official in one place, inside one workflow, with the minimum data it needs, and with clear rules around access, logging, and safety. That’s how you replace shadow AI with something controlled and useful.
This approach also turns data work into something value-driven. Instead of debating “data quality” in general, you’ll see exactly what breaks the workflow. Maybe it’s missing product IDs. Maybe the KB is outdated. Maybe entitlement data is scattered across two systems. Whatever it is, you’ll fix it because the business impact is visible.
If you’re deciding what to do next, keep it simple:
- Pick one workflow where outcomes matter and decisions repeat.
- Define one metric that leadership will respect.
- Identify the minimum sources needed to support that metric.
- Add guardrails before you add more data.
- Expand only when the workflow proves it deserves expansion.
GenAI programs don’t fail because data is messy. They fail because scope is fuzzy, or the output can’t be trusted.
Start with trust. Build from there.
