At a Glance
- An AI tool does not detect that the data environment it inherited is inconsistent. It learns that inconsistency as pattern and produces confident output anyway, which is a materially worse failure mode than an obvious error.
- Research from Secured Research finds that among equipment finance companies that conducted a data quality audit before an AI deployment, 39% discovered asset classification or exception-handling inconsistencies significant enough to require remediation before proceeding; firms that skipped the audit and proceeded directly to deployment reported model-output disputes or unexplained anomalies at more than double the rate within the first year.
- David Giller, Founder/CEO at Brainiate, built his October 8 Converge AI session, “Before You Automate the Workflow,” around exactly this inheritance problem — what AI absorbs from an organization’s existing data quality and informal processes before anyone has assessed whether that foundation is fit for the specific use case.
- The data audit is unglamorous and rarely gets scoped into a project timeline, which is precisely why it’s the step most often skipped.
The Failure Mode Nobody Names Correctly
A model trained on years of transaction data where equipment asset descriptions were entered inconsistently — the same category of construction attachment logged under four different free-text labels depending on which underwriter processed the file — does not flag that inconsistency as a problem. It learns the inconsistency as signal, because from the model’s perspective, that is simply the pattern present in the data it was given. The output looks confident. It is confidently built on a data foundation nobody checked, and the confidence itself is what makes the failure hard to catch, because a wrong answer that looks uncertain gets double-checked and a wrong answer that looks certain gets trusted.
What “Informal Process” Actually Means to a Model
Every equipment finance operation has informal processes that never made it into a written procedure — the underwriter who always calls a specific reference source for a specific equipment category, the exception that gets approved verbally and never logged in the system of record, the workaround for a system limitation that everyone on the team knows about and nobody documented. A human employee absorbs these informal processes through tenure and osmosis. An AI system automating that workflow has no access to any of it unless someone explicitly surfaces and documents it first, which means the automated version of the process is quietly missing exactly the judgment calls that made the human version work.
Why the Audit Has to Be Use-Case-Specific
Giller’s session frames this correctly as requiring a use-case-specific readiness assessment rather than a generic data-quality checklist, because the data quality bar that matters changes entirely depending on what the AI is being asked to do. Data good enough for a reporting dashboard is not automatically good enough for an automated decisioning workflow, and firms that ran one general data-quality pass years ago and consider that box checked are applying yesterday’s audit to a materially different and higher-stakes use case.
The Audit That Caught It Before Deployment
A funder preparing to deploy an AI tool for automated exception routing ran a use-case-specific audit first and discovered that a manual credit-analyst override had been logged under six different free-text reasons across the portfolio depending on which analyst entered it, none of them mapped to a consistent taxonomy. A credit operations manager at the funder described what would have happened without the audit: “The model would have learned that overrides were essentially random, because from a data standpoint they looked random even though every one of them had a real reason behind it that just never got captured consistently. We would have automated a workflow that couldn’t tell the difference between a legitimate override and noise, and we wouldn’t have found out until it started routing things wrong in production.”
The Gap Between a Reporting Audit and a Deployment Audit
Most equipment finance companies have run some version of a data quality initiative in the last several years, usually driven by a reporting or business-intelligence project — cleaning up asset categories for a dashboard, standardizing fields for a data warehouse migration. That work is real and often reasonably thorough for its purpose, and it is also frequently mistaken for having already cleared the bar an AI deployment requires. A dashboard tolerates a data field that is 90% consistent because a human analyst looking at an aggregate chart will not notice the 10% noise. An automated decisioning or routing workflow acting on every individual record does not get to average the noise away — it acts on each inconsistent entry as if it were clean, and the errors compound at the transaction level rather than smoothing out at the portfolio level the way they do on a dashboard.
This is the specific reason a use-case-specific audit cannot be satisfied by pointing to a data quality project that already happened for a different purpose. The question is not whether the data was ever cleaned. It is whether it is clean enough for the exact way this particular AI tool will use it, record by record, which is a higher and different bar than most prior data initiatives were built to clear.
Surfacing Institutional Knowledge Before It Gets Automated Around
Giller’s session addresses inheriting informal processes directly, and the practical version of fixing this is a structured knowledge-capture exercise before automation begins: interviewing the specific staff who currently handle the judgment calls a workflow is about to automate, and documenting what they actually do — including the parts that never made it into a written procedure — rather than automating against the written procedure alone. A written procedure describes what the organization intended the process to be. The staff member doing the job daily knows what the process actually is, including every workaround built to handle a case the written procedure never anticipated, and that gap between documented intent and lived practice is exactly what an AI tool inherits silently if nobody closes it first.
This exercise also tends to surface which informal processes are worth preserving and which are worth designing out entirely. Not every workaround reflects sound judgment; some exist because a legacy system never got fixed and staff built a habit around its limitation. A knowledge-capture pass before automation is the moment to make that distinction deliberately, rather than either baking a bad habit permanently into an automated workflow or losing a genuinely valuable judgment call because nobody thought to ask about it.
What To Do About It
- Run a use-case-specific data quality audit before any AI deployment, not a generic one — the bar that matters depends entirely on what the workflow is being asked to automate.
- Explicitly surface and document informal processes and undocumented exceptions before automating a workflow that currently relies on them, since a model has no access to institutional knowledge nobody wrote down.
- Treat a confident, plausible-looking AI output with the same scrutiny as an uncertain one — confidence is not evidence the underlying data foundation was sound.
- Send whoever owns your data governance function to Giller’s October 8 Converge AI session alongside whoever owns the AI project itself; the inheritance problem sits at the intersection of both roles.
The model will use whatever foundation it’s given, and it will not tell you the foundation was cracked. Giller’s October 8 Converge AI session is built for the audit most projects skip because it doesn’t show up as exciting on a project plan — and skipping it is exactly how confident, wrong output gets into production undetected. Bring your data and AI project leads and register at Converge AI.
Secured Research is a commercial capital research practice formed as a joint venture between Monitor/ABF Journal and Sawbux. Since 2010 its panels have surveyed more than 900 secured finance companies, 28,000 middle-market decision makers, 11,000 equipment and technology sellers, and 506,000 small businesses. Findings cited in Monitor Suite are drawn from the following always-on 2026 research programs:
- 2026 Annual Survey of Commercial Finance Decision Making — more than 6,200 equipment buyers, from small business through the upper middle market, across 38 SIC industry groups.
- 2026 Commercial Study of Indirect Asset Finance — 10,609 equipment vendors across 27 SIC industry groups, from local dealers to the largest global OEMs.
- 2026 Back Bench Operations Research — more than 600 finance companies across the capital stack, examining operations, leadership, customer experience, and go-to-market strategy.
