Your Data Is the Foundation: How Implementation Sets Up (or Kills) Your AI Strategy


The number-one topic on every lending program manager’s desk right now is artificial intelligence. Specifically, how to get institutional data structured so they can layer AI on top of it. The urgency is real: Gartner reported in July 2024 that 30% of generative AI (GenAI) projects are abandoned after proof of concept due to poor data quality. The projects do not fail because the models are wrong. They fail because the data feeding them is incomplete, inconsistent, or trapped in disconnected systems.
Here is the direct answer: your AI strategy starts during implementation, not after it. The way your lending platform is configured, the way data flows into it, and the way workflows are structured during onboarding determine whether AI will work for you 12 months from now. A rushed or shallow implementation creates a data foundation that limits everything built on top of it. A thoughtful one creates a foundation that compounds in value over time.
The Real Tax of a Half-Baked Implementation
Dryden Neilson, Director of Implementations at Built Technologies, uses an analogy that captures this perfectly: “An iPhone without iCloud is technically implemented. It’s also borderline worthless.”
A lending platform can be “live” in the sense that users can log in, enter data, and generate reports. But if the implementation did not restructure how data is captured, validated, and organized, the platform is just a more expensive version of the spreadsheets it replaced. The data is still siloed. The workflows still depend on manual handoffs. The reports still require someone to reconcile numbers across systems before they can be trusted.
This is where most implementations go sideways. The vendor installs the software, migrates historical data, trains the team, and declares the project complete. But if that vendor is not suggesting meaningful changes to process and organizational structure during implementation, the lender finishes the rollout without getting what they made the business case for. BCG found that 74% of organizations cite data infrastructure as the number-one barrier to scaling AI. That infrastructure is not a separate project. It is what implementation is supposed to deliver.
Andrew Ng, one of the most cited voices in applied AI, has made this point repeatedly: “Improving data quality yields better results than improving algorithms.” The implication for lenders is clear. The most sophisticated AI model in the world cannot compensate for a data layer that was assembled carelessly during a rushed onboarding.
Build vs. Buy and the Data Layer
The temptation, especially at larger institutions, is to build internal tools that consolidate data across systems. A project management layer here, a reporting dashboard there, a custom integration between the loan origination system (LOS) and the draw management platform. It feels productive. It also creates a maintenance burden that compounds over time.
To avoid this trap, Dryden Neilson frames the challenge as a discipline question: “Let every software do what it’s best at, and you become the connective tissue.” The lender’s job is not to build a data warehouse. It is to select platforms that capture data in structured, interoperable formats and then connect them through standardized integrations. “Don’t spend free time spinning up a project management tool just because you can.”
This is the build-vs.-buy decision applied to the data layer. Building custom tools creates institutional knowledge dependencies, maintenance overhead, and fragile integrations that break when any upstream system changes. Buying purpose-built platforms that already structure data according to industry standards creates a foundation that is maintainable, auditable, and ready for AI.
Built Technologies approaches this as a core implementation principle. Its platform organizes construction and real estate finance data into a predictable, structured model from day one. That structure is not an afterthought. It is the product of managing $317B+ in real estate dollars across 300+ lenders. When data enters the platform, it enters in a format that is immediately usable for reporting, compliance, and AI applications.
This matters because large language models (LLMs) are only as good as the data backing them. An LLM trained on or connected to clean, structured lending data can surface portfolio risk patterns, flag draw discrepancies, and automate inspection scheduling. The same LLM connected to fragmented data spread across spreadsheets, emails, and disconnected systems produces unreliable outputs that no risk officer would trust.
What AI-Ready Data Looks Like
The NIST AI Risk Management Framework and the Financial Stability AI Risk Management Framework (February 2026) both emphasize data readiness as a prerequisite for responsible AI deployment. For lenders, AI-ready data has four characteristics.
- Structured at the source: Data enters the system in a defined format with required fields, validation rules, and consistent taxonomies. No free-text fields where structured data should exist. No inconsistent naming conventions across branches or teams.
- Connected across workflows: Draw data, inspection data, loan data, and borrower data are linked in a single data model, not scattered across disconnected systems. When an AI agent reviews a draw request, it can access the inspection history, the budget, the lien waiver status, and the loan terms in one query.
- Auditable and versioned: Every data point has a clear provenance: who entered it, when, and through what workflow. This is not just a compliance requirement. It is what allows AI outputs to be explained and defended when a regulator or auditor asks how a decision was made.
- Continuously enriched: The data model improves with every transaction. Each draw processed, each inspection completed, and each loan administered adds to the dataset that AI systems use to improve accuracy and surface new patterns. Implementation is not a one-time data load. It is the beginning of a compounding data asset.
Lenders that treat implementation as a data strategy exercise, not just a software installation, position themselves to adopt AI capabilities as they mature. Those that treat it as a checkbox end up circling back 18 months later to re-implement the data foundation they should have built the first time.
Start With the Data Foundation
Your AI roadmap is decided during implementation, not after it. Every shortcut taken during onboarding becomes a constraint on what AI can do for you a year later, and every structural decision made deliberately becomes an asset that compounds.
Before you sign an implementation plan, ask the vendor one question: what changes to our process and data model are you recommending, and why? If the answer is “none, we’ll configure it the way you work today,” you are buying a more expensive spreadsheet.
Built’s implementation team treats data structure as the deliverable, not the byproduct. See what that looks like for your portfolio.
Talk to our implementation team
Data Readiness FAQs
Why do most AI projects in lending fail after proof of concept?
Most AI projects fail after proof of concept because the underlying data is incomplete, inconsistent, or siloed. Gartner reported in 2024 that 30% of GenAI projects are abandoned after POC specifically due to poor data quality. The models work fine. The data does not support them at scale.
How does implementation affect long-term AI readiness?
Implementation determines how data is captured, structured, and connected across workflows. A thoughtful implementation creates a structured data foundation that AI systems can immediately use. A rushed one creates fragmented data that requires expensive remediation before any AI application can be trusted.
What is the difference between “live” and “AI-ready” data?
A platform can be live (users logging in, entering data) without being AI-ready. AI-ready data is structured at the source, connected across workflows, auditable with clear provenance, and continuously enriched through ongoing transactions. Most platforms that are technically “live” fail on at least two of these criteria.
Should lenders build or buy their data infrastructure for AI?
Buy purpose-built platforms that structure data according to industry standards and connect them through standardized integrations. Building custom tools creates maintenance overhead, institutional knowledge dependencies, and fragile integrations. BCG found that 74% of organizations cite data infrastructure as their top AI scaling barrier, and custom-built infrastructure is a primary contributor.

Dryden Neilson is the Director of Implementations at Built, where she leads the team that takes lenders, developers, and general contractors from signed contract to live on the platform. Since joining in 2020, she has grown from Implementation Manager to Director, building the playbooks, stage gates, and AI-powered internal tools that make delivery predictable rather than hopeful. She works where product, engineering, and customer operations meet.
She came to fintech by way of the life sciences. After studying biomedical sciences at Auburn University, Dryden spent six years at Ramsey Solutions turning messy operational problems into repeatable systems and learning that most projects fail on unclear expectations long before they fail on software. She now applies that to implementation, where her mandate for the team is a single line: if a human does it twice, automate it once. She is based in Nashville and writes about implementation, AI-native operations, and what it takes to make new software pay off quickly.


