AI built into your FP&A (financial planning and analysis) tool can work with the model, current screen and configured permissions. A general AI tool such as Claude or ChatGPT can reach other business sources when connected and authorized. The right mix depends on the work. The deciding factor is whether each tool uses the same governed definitions and respects the same access controls.
The short version
- Embedded AI can use planning-model context, while general AI can work across other sources when connected and authorized.
- If two AI tools use different metric definitions, they can return different answers to the same finance question.
- Lock-in risk depends on how easily you can move definitions and workflows, not only on which AI interface you use today.
What is the difference between AI built into an FP&A platform and AI you bring yourself?
Embedded AI runs inside your FP&A platform and can use its model and screen context. Bring-your-own AI means connecting a general tool, such as Claude, ChatGPT or Microsoft Copilot, to approved business sources. The distinction is where you work and which data each tool can access.
For example, an embedded assistant may use the department, version and period selected in a planning screen to explain a headcount variance. A general AI tool needs the same context through an authorized connection or information supplied by the analyst. Check what each tool receives before comparing its answers.
A general AI tool can help when a question crosses systems. A CFO preparing for a board call may want churn from Salesforce, payroll from Rippling and the latest forecast in one answer, plus a draft email to the audit committee. Which tool can handle that work depends on its authorized connections and available data.
General AI tools are already in place for most teams. Datarails’ 2026 CFO Sentiments Survey found the surveyed finance teams using an average of 2.5 general-purpose AI tools, with Microsoft Copilot, ChatGPT and Claude the most widely used. The practical question is how to make those tools and the planning tool agree.
My FP&A vendor is already adding AI features, so why would I need anything else?
You may still need general AI for work outside the planning platform, such as drafting a board memo from several approved sources. Embedded features improve work inside the product; their usefulness in another AI interface depends on the connections the vendor provides.
Consider an illustrative scenario. A software company’s embedded planning assistant reports net revenue retention (NRR) at 108 percent. The revenue operations lead asks ChatGPT the same question using a Salesforce export and gets 112 percent. Both calculations are arithmetically correct, but the planning model excludes a reseller channel the export includes. Without a shared definition, the board pre-read could go out with the wrong figure.
Embedded AI is limited to the data it can access, including authorized connected sources. If contract terms, bank balances or support tickets are unavailable to the assistant, it cannot use them, however capable the model is.
Adoption numbers explain why vendors are racing to add features. Gartner’s 2025 survey of 183 CFOs and senior finance leaders found 59 percent using AI in finance, with 91 percent reporting low or moderate impact at first (Gartner, 2025). When evaluating new features, test the data access and shared definitions underneath them as well.
Can FP&A software work with Claude, ChatGPT or an agent my team already uses?
Yes, if the vendor offers a governed connection rather than a data export. One route is the Model Context Protocol (MCP), an open standard Anthropic introduced in November 2024 that lets an AI tool call an outside data source in a structured way (Anthropic, 2024).
The protocol is only the plumbing. What matters is what the connection exposes. A connector that returns raw ledger tables leaves the model to work out what revenue means. A connector that exposes metric definitions, hierarchies and entity structures gives the model finance-specific context. That is why the layer beneath a finance MCP server matters alongside the model, prompt and validation.
Permissions matter as much as definitions. A department head who can see only marketing in the planning tool should see only marketing when asking Claude. If the connector relies only on a shared admin identity and does not enforce the requesting user’s permissions, it can expose data beyond that user’s authorized scope.
Test the connection before you buy:
- Ask the vendor to connect your preferred AI tool and sign in as a user with restricted access.
- Request data outside that user’s permissions. The tool should deny access or return only authorized data, clearly identifying any limits on the result.
- Ask for a metric your team defines differently from the textbook, such as gross margin with hosting in cost of revenue. Check that the answer uses your approved definition.
Is a finance AI vendor selling me a product or a consulting engagement?
Often some of both. A software product provides standard capabilities that customers configure for their needs. Consulting services add work designed for a particular customer, such as a custom AI workflow. Ask which capabilities your team can maintain and which changes require additional vendor services.
The test is what happens on the first change request. Ask whether a finance admin can add an entity to an AI workflow in the product or whether the vendor must scope additional services. That distinction affects ongoing maintenance and who you depend on when the original builder leaves.
Custom work has a place. Finance processes with unusual rules, such as a royalty calculation tied to territory and title, may need an agent built for them. At Datarails, that work is done by Forward-Deployed Financial Engineers (FDFEs), who build customer-specific agents on the same governed data and permissions the product uses. That keeps custom agents inside the product’s controls instead of beside them.
Ask three things during evaluation:
- Who maintains the agent after go-live, and what a change costs in time.
- Whether it runs on the vendor’s standard data layer or a separate pipeline.
- Whether your team can see what it did, step by step, in an activity log.
An agent on a separate pipeline is a second system to govern.
Does embedded AI or bring-your-own AI leave me less locked in three years from now?
Neither approach removes lock-in by itself. Your exposure depends on how easily you can move metric definitions, mappings and workflows to another tool. Definitions held only in one assistant or scattered across individual accounts can make that transition harder.
AI interfaces can change independently of finance systems. A gross margin definition stored only in a custom GPT’s instructions may need to be exported or recreated when the team changes tools. A shared governed source can reduce that migration work, provided the new tool can connect to it and enforce the required permissions.
Use the table below to identify what may need to move when you switch AI tools.
| Exposure test | Where it usually sits | Risk at switch |
|---|---|---|
| Metric definitions stored in prompts or custom instructions | Individual AI accounts | May need export or recreation |
| Account mappings inside one workbook or one tool | Analyst files or vendor model | May need remapping |
| AI workflows built in a vendor-only builder | Vendor platform | May need rebuilding |
| Permissions enforced per tool | Each AI tool separately | May need reimplementation |
| Audit trail kept only in chat history | AI tool logs | May be difficult to retain or export |
Any yes answer identifies something to check before switching tools. Review data portability, workflow migration, permission controls and audit-log retention separately.
Start with the first row. Move disputed metric definitions out of individual prompts and into a shared governed source. Before switching tools, check that definitions, permissions and workflows can be carried over.
How should I decide between embedded and bring-your-own AI?
Decide where the definitions live first, then let people use both. Embedded AI is the better fit for work inside the model, such as variance explanations and report building. General AI tools are the better fit for questions that cross systems and end in a document or an email.
That is how FinanceOS®, the foundation underneath Datarails, is designed. Definitions, mappings, entity structures and permissions sit in one governed layer. Inside the product, the AI Assistant and Inflow Agents such as Widget AI already know the screen and the filters. Outside it, the FinanceOS AI Connector gives Claude, ChatGPT and other MCP-compatible tools the same definitions and the same user permissions. Shared definitions give both tools the same basis for the NRR calculation, while the result still needs to be checked.
According to Datarails’ connector documentation, the FinanceOS AI Connector’s current tools read data for analysis without writing changes back to Datarails. Treat AI outputs as drafts to review before sharing. Data returned to an external AI platform follows your organization’s agreement with that provider, including its training and retention terms.
If your team is still deciding, start by writing down the five metrics people argue about. Wherever those definitions end up stored is the decision that matters.
How to test governed data across your AI tools
Pick one metric that came out differently in two tools this quarter and trace both answers to their sources. If your team already uses Claude or ChatGPT on finance data, a demo of the FinanceOS AI Connector shows what changes when the data underneath is governed.
