Early in my career I used a platform called PerTrac to analyze hedge fund returns. Most of the data I was entering came from reports other managers had generated — also using PerTrac. I was manually transferring numbers from one system's output into another system's input. This was the era of installed desktop software, not connected systems, but even then the solution was straightforward: a simple CSV or XML file would have made the entire process a few clicks. Instead I spent hours manually entering and double-checking returns from PDF documents, sitting between two systems doing the work of a wire.
I thought about that a lot when AI arrived because it was a complicated solution to a problem that didn’t need to exist in the first place.
Here is a pattern that is largely invisible inside the organizations producing it. Structured data gets converted into unstructured formats — databases become PDFs, reservation systems become phone calls, portfolio analytics become brokerage statements — and then we deploy enormously expensive AI to convert it back into structured data. We are burning massive amounts of energy and processing power to undo a problem we ourselves created.
Consider what happens when a financial advisor onboards a new client. The prospect's holdings exist in a database at their custodian or brokerage firm. That database exports a PDF statement. The advisor's team uploads the PDF to an AI platform—Powder, Hebbia, AlphaSense—which uses large language models to read the document, identify the relevant fields, and extract them back into structured data for analysis. This happens thousands of times a day across the wealth management industry. Every extraction draws on real processing power, and the energy cost of that compute appears in nobody's ESG report.
Not just an issue in the finance industry
The pattern extends well beyond finance. Insurance companies deploy AI to decode their Explanation of Benefits documents—structurally unreadable documents generated from structured claims data that could have been delivered as a feed. Mortgage processors run AI against pay stubs from ADP, which has a direct verification API that most lenders never configured. Law firms use AI to extract terms from contracts that originated in Word templates and could have been stored as structured databases. An entire industry of startups exists not because these problems are technically unsolvable, but because the underlying architecture was never addressed.
It is worth being precise about why this happens. Nobody in this system is behaving badly. When a client walks into a financial advisor's office, they bring their brokerage statements — because that is what they have and what they know how to produce. The advisor takes them and moves quickly, because speed signals competence and a proposal on the table is worth more than a conversation about file formats.
Custodians and brokerage firms rarely prioritize clean data exports for third-party advisors, because the statement was built for a human reader, not a downstream system, and nobody asked them to think about it differently. Each of these decisions is locally rational. But the energy cost of all of them combined is paid downstream, invisibly, by AI systems that nobody was asked to account for.
Where does this pattern lead?
When Google's Duplex assistant made headlines for calling a restaurant and booking a reservation by voice, offering an early glimpse of where this leads.
The logical next step is already underway: as more calls to businesses originate from AI agents on a customer's behalf, businesses start deploying their own AI to handle the call. Now two AI agents negotiate a reservation that an OpenTable API call would have completed in milliseconds, consuming orders of magnitude more energy in the process. Nobody on either side asked why the phone call needed to exist in the first place because the cost of that call never showed up on anyone's ledger.
The conversation about AI's energy footprint is almost entirely focused on inputs: where data centers source their power from, whether renewable energy credits reflect actual grid draw, how hardware efficiency is improving. These are legitimate questions. But they overlook a different category of waste generated not by the AI industry itself, but by the data architecture decisions of the organizations that rely on it.
The accounting standards we rely on to measure corporate environmental impact—Scope 1, 2, and 3 emissions—were built before AI inference at scale existed. The waste created by poor data architecture falls into a gap that no current standard requires anyone to measure, report, or justify. This is not a small gap. The AI document ingestion market alone—companies like AlphaSense, now valued at $7.5 billion, processing hundreds of millions of documents continuously—exists almost entirely to perform a translation that could be solved with better data architecture.
Meanwhile, the same institutions publishing sustainability commitments have cut business travel, reduced office footprints, and publicly collected credit for it. A CEO will congratulate the team that launches a recycling initiative, but the engineer who builds a structured data export—eliminating thousands of LLM inference calls a day—won’t hear a word of thanks.
I live in Reno, Nevada, a few miles from Switch's Citadel Campus — the largest colocation data center campus in the world, sitting on 2,000 acres next to the Tesla Gigafactory, designed for 650 megawatts of power at completion. AI compute isn't an abstraction to me. NV Energy, our regional utility, recently told the 49,000 residents on the California side of Lake Tahoe that it can no longer supply their power — citing data center demand in northern Nevada as driving what the utility itself called "unprecedented" growth in energy load. A place that most people think of as pristine and permanent is now competing with server racks for electricity, and the server racks are winning. The energy cost of the pattern I'm describing in this article isn't theoretical. From where I live, I can see exactly what it's displacing.
AI can also be the solution
The real question isn't whether ESG frameworks should evolve to capture this. It's why companies haven't already started thinking about data delivery as an environmental decision on their own.
What is now an environmental cost used to be paid in human hours: interns keying in numbers, advisors re-entering data by hand, analysts cross-checking PDFs against spreadsheets. It was bounded, which made it easy to ignore because nobody was measuring it as anything other than headcount.
There is a version of this story where AI is not the workaround but the fix. For decades, the honest answer to "why don't we offer a clean data export" was that it was too expensive and low priority to justify the engineering time. AI changes that calculus.
The same models being used to extract data from PDFs can be pointed upstream, at the legacy system itself, to map its structure, draft an export schema, and generate the integration code that turns a confusing internal API into something a smaller firm's engineering team can actually use.
That is a far better use of the technology than running inference on the same statement format millions of times a year. AI will keep getting better at reading PDFs. It will become faster, cheaper, and more accurate per extraction. What it won't do on its own is make the PDF unnecessary—someone still has to point it at the actual problem. That decision belongs to the organisations creating the PDFs in the first place.
A decision framework to avoid AI bloat
A few questions worth adding to any product review when data delivery is on the table:
- What are all the things this data will be used for — not just the immediate problem we're solving? A brokerage statement has an obvious primary use case: conveying accounting information to a client. But the same data serves a financial advisor building a proposal, and the IRS processing a tax filing. Operations two and three both benefit from structured, systematic output rather than stylized human-readable formatting. Optimizing for use case one while ignoring the others doesn't eliminate the downstream need — it just transfers the cost of conversion to someone else's budget, or increasingly, someone else's data center.
- How would we ingest our own output? If a client came to us holding our own contract, our own statement, our own EOB — what would we do with it? If the honest answer is "send it to an LLM to extract the fields and import them into our database," we have created a cost that we own. This question reframes the format decision as something with a measurable internal consequence, not just an external inconvenience.
- Is there a way to satisfy both use cases in the same file? This isn't a hypothetical. PDF/A-3, the archival variant of the PDF standard, was specifically designed to carry embedded file attachments alongside the human-readable document. ZUGFeRD, now mandated for business invoicing in Germany and gaining adoption across Europe, uses exactly this mechanism — a normal PDF invoice with an embedded XML data layer that accounting software can extract directly, no OCR required. The SEC already requires iXBRL for public company filings: human-readable financial statements with machine-readable tags embedded in the same document. The technology exists. It has regulatory precedent. It has simply never been pointed at a retail brokerage statement or a client-facing EOB.
- Are we assuming documents are the only available format when the source may offer something better? Before accepting that a PDF is the only way to receive this data, it is worth asking whether the originating system offers an API, a structured export, or a direct data feed that simply was never configured. Lenders routinely run AI against pay stubs to verify income — not because that is the only option, but because the direct verification API that ADP and similar payroll providers offer was never integrated into the lending workflow. The document is often a choice, not a constraint. Confirming which one it is before building around it costs almost nothing. Building around the wrong assumption costs a data center's worth of inference, indefinitely.
- Before building an AI ingestion pipeline, have we asked why this data isn't already structured — and whether fixing that upstream is cheaper than solving it downstream forever? An LLM ingestion service has ongoing compute costs that compound with every document processed, for as long as the pipeline runs. Fixing the upstream data format is a one-time engineering cost that eliminates the recurring one. The question is not whether AI can solve the ingestion problem — it almost certainly can. The question is whether solving it with AI is the right investment when the alternative is removing the need for ingestion entirely. That calculation should happen before the first line of pipeline code is written, not after the service is in production and the invoices are arriving.
The questions above won't slow a product team down. They take five minutes in a planning session and they cost nothing. What they might prevent is a pipeline that runs forever, an ingestion service that compounds its own cost with every document processed, and an environmental decision that nobody on the team knew they were making. Format decisions feel like implementation details. They aren't. They are architectural choices with consequences that outlast the product, the team, and in some cases the organization that shipped them. The data will keep flowing. The only question is whether the next system downstream has to fight to read it.
