Maybe you have a list of service providers, member businesses, or partner locations, the kind of database that grows for years, pulled in from old spreadsheets, partner submissions, and whatever your predecessor had time to type in. Every record has the basics. Almost none of them have everything. One listing has a capacity number and no age restriction. Another has neither, and nobody currently on staff remembers where the data would even come from.
Going through thousands of records by hand to fill those gaps isn't realistic for most teams. AI data enrichment, using an AI tool to look up and fill in missing fields automatically, can do this work at scale, but only if you give it clear rules for what to trust, what to estimate, and when to just leave a field blank instead of guessing. Here's how that actually gets built, field by field.
Start with what you're actually trying to fill in
Not every missing field deserves the same approach. A field like a business's phone number or email either exists publicly and is easy to verify, or it doesn't, and there's little risk in having AI look it up directly. A field like venue capacity or an age restriction is softer: it might not be published anywhere, and a wrong guess looks exactly as confident as a right one unless you build in a way to tell the difference.
For a directory of event venues missing capacity, genre, and age-restriction data, the approach ended up different for each field, because each one had a different realistic path to an answer.
How do you decide what AI should trust versus guess?
This is the actual design question, and it matters more than which AI tool you use. For this project, each field got its own fallback chain:
Capacity. First choice: whatever number the venue's own website publishes. If that's not available, fall back to public records that exist for a different reason but happen to include a number, like a liquor license or fire occupancy certificate filed with a local authority. If neither exists, the system estimates based on the physical footprint of the building itself, which isn't exact but tends to land close enough to be useful, and it's clearly logged as an estimate rather than a confirmed figure.
Genre. This one is less about data availability and more about avoiding a mess. Left alone, an AI tool will happily generate a dozen near-duplicate tags, "indie rock," "alternative rock," "indie," all describing roughly the same thing. The fix was to constrain it to a fixed, limited list of approved genre tags and have it match each venue to the closest ones on that list, so "indie rock" consistently becomes "indie" and "rock" rather than its own new tag nobody else uses.
Age restriction. The hardest of the three, because there's rarely a single authoritative source to check. Instead of trying to look this one up directly, the logic leans on a reasonable signal that's already available: a location's general business type. A venue classified as a bar defaults toward a 21-plus assumption; one classified as a restaurant defaults toward all ages. It's a heuristic, not a lookup, and it's treated that way in how confidently the result gets presented.
Notice the pattern across all three: real data first, a reasonable and clearly-labeled estimate second, and never a confident-sounding guess dressed up as a fact.
Building in a safety net before you trust it with live records
The other piece that matters as much as the field logic is what happens to the record once AI has an answer for it. This project drew a hard line between two situations. For a brand-new, unpublished listing still in a suggested or pending state, the AI-generated fields get applied directly, since nothing live is at risk yet. For a record that's already active and public, the same AI output instead gets created as a suggested edit for someone to review and approve, rather than silently overwriting a field that might already be correct.
That distinction is also where a field-level control is worth building in from the start: the ability to enable AI enrichment for genre but not age restriction, for example, if your team trusts one field's logic more than another's. Treating "turn on AI enrichment" as one global switch tends to mean you either apply it everywhere, including fields you're not confident about, or nowhere, including fields that would have been perfectly safe to automate.
What this actually costs to run
For a tool like this, a single record typically costs well under a cent to process, since it's a scoped, narrow task per field rather than an open-ended conversation. At that cost, running it across a few thousand records is genuinely cheap compared to the staff hours it would take to look each one up by hand. The upfront cost is in building the fallback logic correctly for each field, not in running it afterward.
Does this apply outside of a venue directory?
The same approach works for any directory where the gaps are inconsistent across records: nonprofit resource listings, member business directories, service provider databases, or program rosters pulled together from multiple sources over time. The specific fields and fallback sources will differ, but the underlying method doesn't: figure out what real, verifiable source exists for each field, decide what a reasonable fallback estimate looks like when that source is missing, and never let the system present an estimate with the same confidence as a confirmed fact.
Tapp Network builds practical AI tools that fill real operational gaps, not demos. Reach out if your organization has a directory, database, or list that's been accumulating gaps for years and could use a real plan to close them.
