Category: Decision Drag

  • Why your CFO will ask about AI lineage before they ask about AI accuracy

    Why your CFO will ask about AI lineage before they ask about AI accuracy

    Accuracy is the wrong first question about enterprise AI, and finance leaders are the first to figure this out. Not because accuracy is unimportant, but because accuracy is a claim, and CFOs are professionally trained to distrust claims they cannot verify. A vendor asserting 95 percent accuracy is telling the CFO nothing actionable. A vendor showing exactly how any individual answer was produced, from the question asked to the data read to the number returned, is telling the CFO something they can build a control around. The first is marketing. The second is lineage.

    Finance runs on traceability, not on averages

    Consider how a finance organisation already treats numbers. No controller accepts a figure into the close because the person who produced it is usually right. Every material number must tie back: to a ledger entry, to a reconciliation, to a documented source. The entire apparatus of financial control, from journal entry approval to SOX testing, is built on the principle that a number’s origin must be demonstrable, not merely trusted. Auditability is not a feature of financial reporting. It is the substance of it.

    An AI agent that produces analysis for finance is entering that apparatus, and the apparatus does not bend for new technology. When an agent’s output feeds a forecast, a close package, or a board deck, the CFO’s question is the same question finance asks of every number: show me where this came from. An aggregate accuracy statistic cannot answer it. The statistic says the system is right most of the time. The CFO needs to know whether it was right this time, and the only way to know is to trace this specific answer back through this specific chain.

    Accuracy without lineage is unverifiable, lineage makes accuracy testable

    Here is the asymmetry that puts lineage first. An accurate system with no lineage gives you correct answers you cannot prove are correct, which in a regulated finance context is nearly as unusable as wrong answers. A system with full lineage gives you something better than a promise: it gives you the means of verification. When every answer carries its question, its resolved metric definitions, its generated SQL, and its source tables, then accuracy stops being a vendor claim and becomes a property your own team can test, continuously, on your own data.

    Lineage is also what makes errors survivable. Every analytical system, human or machine, produces occasional wrong answers. In a lineage-complete system, a wrong answer is diagnosable: the reviewer finds the step where the chain went wrong, whether a misresolved definition or a flawed join, and the fix improves every subsequent answer. In a lineage-free system, a wrong answer is just a mystery that erodes trust, and there is nothing to fix because there is nothing to inspect. CFOs understand this instinctively, because it is exactly why finance documents its own work.

    The CFO is answerable for the number, so the CFO sets the bar

    There is a structural reason this question lands on the CFO’s desk with particular weight. When a figure reaches investors, the board, or a regulator, the CFO is personally accountable for it. Certification regimes in financial reporting attach executive names to reported numbers. An executive who signs numbers does not get to say the AI produced them. So before any AI-assisted analysis gets near external reporting, the CFO will require the same evidentiary standard applied to everything else in the reporting chain: complete, reviewable, retained documentation of origin. That standard has a name in this context, and it is lineage.

    The practical consequence for anyone selecting an analytics platform is that the finance organisation’s requirements will arrive whether or not they were in the original evaluation. Teams that select on demo quality and accuracy claims alone often discover the lineage requirement at the worst moment, when a number is already in circulation and someone senior asks for its provenance. Teams that select for lineage from the start never have that meeting.

    What to be able to show when the question comes

    The test is concrete. Take any single answer the platform has produced and demonstrate, from stored records rather than reconstruction, five things: who asked the question and under what permissions, the exact question asked, the certified definitions the question resolved against, the SQL executed and the tables it read, and the result returned. A platform built for governed agentic analytics produces this chain automatically on every query. Based on QuaerisAI customer deployments and published materials, this is the operating model behind results like a reduction from 170 hours to 70 hours on a standard audit engagement: when every answer arrives with its own evidence, the verification work that consumes senior hours collapses, because the proof was generated with the answer.

    Accuracy will always matter. But accuracy is what the system claims about itself, and lineage is what lets your CFO check. In finance, the checkable thing wins every time.

    Frequently asked questions

    What does AI lineage mean in analytics?

    AI lineage is the complete, recorded chain from a user’s question to the system’s answer: the identity and permissions of the asker, the question as phrased, the metric definitions it was resolved against, the query the system generated, the data sources that query read, the model that produced the reasoning, and the returned result. Data lineage traces where data came from. AI lineage extends the trace through the reasoning and generation steps as well.

    Is high accuracy enough for AI in financial reporting workflows?

    No. Financial reporting standards require that material numbers be supportable with documentation, not merely correct. An accurate answer with no reconstructible origin fails that test, because there is no evidence to review. In practice, lineage is the entry requirement and accuracy is what lineage lets you continuously verify.

    How should a finance team evaluate lineage in a vendor demo?

    Ask the vendor to pull the full record for one specific past query, live, without preparation. The record should show the asker, the prompt, the resolved definitions, the generated SQL, the tables touched, and the result, as one linked chain retrieved from storage. If producing it requires stitching together separate logs or engineering effort, the platform does not have lineage. It has logs.

  • Why teams don’t trust the data and what to do about it

    Why teams don’t trust the data and what to do about it

    Someone presents a number in a meeting. Before anyone reacts to what the number means, someone else asks, “Where did this come from?” The meeting stalls while two people compare it against a different report, find a small mismatch, and spend the next ten minutes debating whose version is right. Nobody has questioned the strategy yet. They are still arguing about the input.

    This scene repeats often enough that it shows up in industry research, not just anecdotes. Precisely and Drexel University’s 2025 Data Integrity Trends report found that 67% of organizations don’t completely trust their data for decision-making, up from 55% the year before. A widely cited KPMG and Forrester Consulting study of data and analytics leaders found only 38% had high confidence in their customer insights, and only about a third trusted the analytics generated from their own business operations.

    Trust is going down even as spending on data and analytics goes up. That gap is worth understanding before trying to close it.

    The problem is rarely the data itself

    When trust breaks down, the instinct is to blame data quality. Sometimes that is the cause, but more often the data is fine and the problem is what happens to it after it is collected.

    • The same metric has more than one definition. Finance calculates “active customers” one way, product calculates it another way, and both dashboards are technically correct by their own logic.
    • Nobody can trace a number back to its source. A figure shows up in a deck with no visible path to the table, query, or transformation that produced it, so verifying it means asking around instead of looking it up.
    • Spreadsheets fill the gaps dashboards leave. When a dashboard cannot answer a specific question, someone builds a manual workaround, and that workaround quietly becomes the real source of truth for one team while the official dashboard stays untouched by everyone else.
    • Access is inconsistent. If two people with different roles can see different slices of the same report without knowing it, they will eventually compare numbers that were never meant to match.

    What low trust actually costs

    The TheyDo 2025 survey of senior decision-makers across the US, UK, and Netherlands found that 77% of executives admit they only sometimes or rarely question the data they rely on daily, even though 67% worry that leaning on static dashboards risks missing real opportunities. That is the quiet cost of a trust gap. People do not necessarily stop using the data. They stop questioning it, which is arguably worse, because bad numbers stop getting caught before they turn into bad decisions.

    The louder cost is the one every data team already feels: meetings that turn into reconciliation exercises, decisions that wait on someone to manually confirm a figure, and a data team that spends more time defending numbers than producing new ones.

    What actually rebuilds trust

    More dashboards do not fix this. Neither does a data quality initiative on its own, if the underlying definitions and lineage stay scattered. What closes the gap is making three things true at once:

    • One certified definition per metric. “Active customer” should mean exactly one thing, owned by one team, used everywhere it appears.
    • Visible lineage on every number. Anyone looking at a figure should be able to trace it back to the table and logic behind it without filing a request.
    • Access enforced at the point of the question. Role-based permissions applied at query time, not just at the report level, so what someone sees is consistent with what they are allowed to see.

    This is the architecture QuaerisAI is built around. Every answer maps to a certified metric definition, comes with a source citation, and is logged in a full audit trail, so a number can be traced back to the table and query that produced it in one click. Access is enforced at the moment a question is asked, based on role, not after the fact. None of this requires moving your data. QuaerisAI connects to Snowflake, BigQuery, Databricks, Redshift, and other sources in place.

    Teams that move to this model tend to stop treating “where did this come from” as a rhetorical question. Self-serve adoption has climbed from roughly 30% to 60% of business users in QuaerisAI deployments, largely because people no longer need to double-check a number with the data team before they can act on it.

    A starting checklist, regardless of platform

    If a full platform change is not on the table yet, these are worth doing on their own:

    • Name one owner for every metric that appears in more than one report
    • Require a visible source and definition next to any number in a board deck
    • Find the shadow spreadsheets your team already relies on and ask why the official dashboard doesn’t cover that case
    • Check whether access controls are enforced at the data layer or only at the report layer

    Trust in data is not restored by asking people to believe harder. It is restored by making it possible to check. Talk to us to see how QuaerisAI builds that checking in by default.