Self-serve finance answers, without breaking permissions

Delivered by 1AYM

A PE-backed firm

A question about client or financial performance used to take around two hours to come back from the finance team. It is now answered in the meeting where it is asked, and nobody gained access they did not already have: the connector carries each person's existing Looker entitlements. Connecting the data took an afternoon. The week that followed went on agreeing, with the finance director, the definitions that make an answer correct, and that week was the real work.

~2 hrs → in the meetingTime to a governed finance answer
1 afternoonTo connect the data
1 weekTo make the numbers trustworthy
UnchangedExisting permission model
Diagram: a question travels from the user through the AI workspace to a connector, which checks the user's existing Looker entitlements before resolving against the semantic model and the warehouse. Data outside the user's entitlement is never returned.

The problem

Financial information sat behind the finance team. Anyone elsewhere in the business who needed a figure, for a client conversation or a meeting or a decision, raised a request and waited, typically a couple of hours. The finance team spent a meaningful share of its week answering questions that were, in principle, already answered by data the company held.

The obvious fix, letting people query the data directly, ran straight into the reason the gate existed: financial data is not uniformly shareable. Some of it is open to the business, some of it is privileged, and any solution that flattened that distinction was worse than the queue.

What was built

A connector between the company's AI workspace and its existing Looker setup, so questions asked in natural language resolved against the same governed model the business already used for reporting.

Permission inheritance
The connector carries the user's own Looker entitlements. Someone with privileged access keeps it; someone without sees only what was already open to them. No parallel permission model was created, because a second model is a second thing to get wrong.
Grounded in the existing model
Answers resolve against the company's canonical metrics rather than against raw tables, so the figures match the ones finance would have given.
Semantic layer
The definitions that make an answer correct (what counts as a client, a period, a booked figure), expressed once so every question inherits them.

The hard part was not the integration

Connecting the data took a single afternoon. That speed was itself the problem: it confirmed a belief held across the business that this kind of work is plug-and-play.

It is not. A connector that returns a number is trivial. A connector that returns the *same* number the finance director would have given you is a week of work, and that week is the entire value. We spent it with the finance director, rapidly iterating the semantic layer and checking the agent's answers against his, until the two agreed on definitions the business actually uses.

Had the project stopped after the afternoon, it would have shipped something that looked finished and quietly disagreed with finance, which is worse than the queue it replaced, because the queue was at least right.

Outcome

People pull the figures they need in the meeting where the question comes up, rather than preparing a request and waiting on someone else's queue. The finance team stopped being a lookup service for questions the data could answer on its own.

The wider result was a corrected assumption. The engagement demonstrated to leadership that the gap between a working connection and a trustworthy one is where the actual engineering lives, which changed how subsequent AI work at the business was scoped.

Inheriting permissions is only as safe as the permissions being inherited. Microsoft 365 Copilot works the same way across SharePoint and OneDrive, answering from whatever each person can already open, which is why our checklist for Copilot oversharing fixes the access before Copilot goes live for everyone.

The same checks apply to any source an AI system will read. Our guide to preparing data for AI, listed at the end of this page, sets them out: access, quality, ownership, definitions and personal data.

AI on an ERP or CRM has the same gap between a working connection and a trustworthy one, and our guide to the vendor's built-in AI or a layer of your own, listed at the end of this page, compares the two routes.

Once a business asks an AI workspace for figures every day, the workspace becomes a line on the finance team's own budget. Seats are easy to forecast and usage beyond them is not, which is why our guide to budgeting for AI seats, tokens and agent runs gives every meter an owner and a limit.

The lesson carries to any AI plan measured against a finance-owned number. Our guide to AI in private equity portfolio companies makes the same point about value creation: if the baseline does not match finance, no saving measured against it will stand up.

Checking an agent's answers against a person the business already trusts is what a bank's model risk team calls outcomes analysis, and our guide to generative AI under SR 26-2 shows where that check fits now the US banking agencies leave language models to each bank's own governance.

Looker · Semantic layer · AI workspace connector · Permission inheritance

Frequently asked questions

How long did it take to get governed finance answers into meetings?

Connecting the data took an afternoon. The week that followed went on agreeing the definitions that make an answer correct with the finance director. A question that used to take around two hours to come back from the finance team is now answered in the meeting where it is asked.

Who can help us give staff governed access to finance data through AI?

1AYM. We built this connector, which carries each person's existing Looker entitlements, so nobody gained access they did not already have. Book a 30-minute call or email enquiries@1aym.com.

Last reviewed