Connecting an AI assistant to your company's systems used to be a project, and it still is for most companies running older systems. For others, it is now a setting. Claude, OpenAI and others offer connectors for ERPs, CRMs, accounting and project management tools. In a few minutes, anyone can ask for revenue by month and get a working dashboard back. That is real, and it is useful.
It also raises a fair question for every leadership team: if AI can reach every system and build the dashboard, where should these tools live?
I use Claude every day, connected to our own accounting, billing and CRM, and I build data platforms for a living. So this is not an argument against connecting AI to your tools. It is about the difference between asking a question once and running a company on the answer: what it costs, whether you can prove the number, and what happens to the people who will never open a chat window.
1. Every person needs a paid seat, whether they build or only look
Claude's connectors work on every plan, including Free. The controls a company needs around them do not. Admin control over connectors and single sign-on start with the Team plan, at US$20 per seat per month billed annually (US$25 monthly), for 2 to 150 seats. Beyond 150 people, you move to Enterprise (20-seat minimum). Audit logs are on Enterprise only, at US$20 per seat plus usage billed at API rates. For a 200-person company, that is US$48,000 a year in seats alone, before usage.
Connectors also work person by person. On Airtable, an admin may need to approve the integration, then each user connects with their own account, and Claude only reaches the data that user can already see. That is the right security model. It also means everyone who needs a number through Claude needs a Claude seat, a seat in the source system, and their own connection.
Usage is rarely even. In most companies we work with, a minority of people use AI every day and most use it a few times a month. Fewer still build. For a 40-person company on Team Standard, seats cost US$9,600 a year. That is a good deal if 40 people build with it. It is an expensive way to give 34 people read access to a monthly report.
Seats also have limits: a rolling five-hour usage window plus weekly caps. Data work is heavy, and past those limits you wait or pay for extra usage at API rates.
2. An AI model is the most expensive calculator you own
Every question asked through a connector is computed from scratch. Claude calls the source system, reads what comes back, reasons over it and writes the answer. When a colleague asks the same question tomorrow, it all happens again.
Take one of our clients: more than 15 million transaction lines a year. Exported as JSON, a line with ten fields is about 80 tokens, so a single year of raw data is roughly 1.2 billion tokens. At Opus 5.5's list price of US$4 per million input tokens, reading it once costs about US$4,800, before any reasoning or output. It would not fit anyway: that is 1,200 times the largest context window Claude offers (section 4).
A SQL engine sums the same 15 million rows in a few seconds, for a few cents at most. Plan around that gap.
The better pattern uses AI where it is strong and keeps it out of the loop that runs every day:
- Build with AI, once. Claude writes the extraction, the joins and the margin calculation. Someone who knows the business reviews them.
- Run without AI, on a schedule. A pipeline loads only what changed into a data lake or warehouse and refreshes the finished tables.
- Read the result. Dashboards, reports and AI assistants query the finished tables, not the raw source.
The calculation is then paid once per refresh, not once per question per person.
3. Can you prove how the number was calculated?
A connector gives Claude access to your data, not to your definition of the metric. Ask for gross margin and the AI has to decide for you:
- Revenue invoiced, recognized or collected?
- Credit notes netted in the month issued, or in the month of the original invoice?
- Which accounts count as cost of sales?
- Intercompany transactions eliminated or not?
- Fiscal months or calendar months?
Each choice is defensible, and each gives a different number. Your business rules are what make the number yours.
Language models are also not deterministic. The same question asked twice can produce two different calculations. On current Claude models, developers can no longer even set the temperature parameter that used to make answers more repeatable. Models are retired, too: Claude Sonnet 4 and Opus 4, released in May 2025, were retired on June 15, 2026. The model that built this year's report may not exist when you rebuild it next year.
Skills and project instructions help. You can write the margin rule down and tell Claude to apply it. But an instruction guides the model, it does not bind the user. Anyone can still ask to “leave credit notes out this time”, and the result looks just as official as the governed one.
Then comes the auditor, the lender or the board: how did you calculate this year's margin, and is it calculated the same way as last year's? A defensible answer has three parts:
- the data as it stood at the time;
- the exact logic applied to it;
- a record of who changed that logic, and when.
A chat history gives you part of the second, at best. Transformations written as versioned code, in a pipeline that runs the same way every time, give you all three. The AI can still write that code. It just should not reinvent it for every question.
4. A summary fits in a context window. Your ERP does not.
Claude's largest context window is 1 million tokens. That is a lot of text, several long books. It is not a lot of transactions: at 80 tokens per line, about 12,000 invoice lines, minus what the conversation itself uses.
Connectors are designed around that limit. They return small answers: a report, a page of records, a total the source system already calculated. Revenue by month for the last 24 months is 24 numbers, and it works well.
The trouble starts with the questions that make analytics worth doing. Which customers are drifting toward churn? How does margin move with volume? What does next quarter's cash look like? These need the full history at transaction level, often joined across systems. That does not fit in any context window.
At that point the AI should not read the data, it should query it. The data sits in a data lake or warehouse. Claude writes SQL, the engine runs it over millions of rows, and only the result comes back. Nobody on your team needs to write SQL. But SQL, or something like it, is how AI will access, transform and model your data at scale.
Two practical limits apply before any of this:
- Many systems have no connector. Older on-premise ERPs and databases, file shares and custom applications are out of reach.
- Source systems ration their APIs. QuickBooks Online, for example, allows 500 requests per minute per company, and its MCP server is still not available in Canada at the time of writing. Pulling full history through an API every time someone asks a question is slow, and it competes with the integrations your operations depend on.
5. Four risks that get less attention
Permissions do not travel with the data
Good connectors respect the user's permissions in the source system. Airtable, for example, says users only reach the data they are already allowed to see or edit. But once numbers leave the source, in an artifact, an export or a pasted table, those permissions no longer apply. A controller who can see salaries builds a cost dashboard and shares the link. Everyone who opens it now sees what the controller sees. In a data warehouse, row and column security applies to every tool that reads the table.
Source systems keep the present, not the past
Most operational systems store the current state. When a deal changes stage, a customer moves to another rep or a budget is revised, the old value is overwritten. A connector can only ask about now. “Revenue by rep last year, as we reported it then” needs snapshots taken at the time. That history exists only if something was recording it.
The real questions span several systems
Each connector sees one system. The property system knows the building, the project tool knows the work order, the accounting system knows the cost. Joining them needs matching keys, and they rarely match: “Tour Est”, “TOUR-EST-01” and property 1042 can all be the same building. Resolving that in every conversation is fragile. A mapping table in a warehouse resolves it once.
Privacy is a decision, not a setting
Data pulled through a connector is sent to the AI provider for processing. On Anthropic's own platform, inference runs in the United States or globally, and data at rest is stored in the US. On Claude's Free, Pro and Max plans, whether chats can train future models is each user's own setting. In Québec, Law 25 requires a privacy impact assessment before personal information is communicated outside the province (section 17 of the private sector act). A connector that reads tenant, employee or customer records falls squarely in scope.
6. When everyone can build, every tool needs an owner
Until recently, a dashboard, a tracker or a small internal app took technical skills, so a handful of people built them. That bottleneck was frustrating. It also worked as governance. AI removes it: anyone can now build their own CRM, their own financial analysis, their own commission calculator.
That is good, up to a point. Ten departments with ten definitions of “active customer” is the old spreadsheet problem, at higher speed and with a nicer interface. Every tool also raises the same questions:
- Who fixes it when a source system renames a field?
- Where does the data it creates live, and is it backed up?
- What happens to the tool when the person who built it leaves?
- Who trains the other users, and where is the documentation?
- How is access shared securely, with audit logs?
- How do we make sure it meets our cybersecurity standards?
Analytics has always needed governance. The answer has not changed, it just matters more than ever:
- A shared foundation. The company provides validated datasets: documented sources, clearly defined transformations, tested business rules, monitored refreshes, permissions applied.
- Freedom on top. Anyone can build and explore with AI on those datasets, not on raw extracts.
- Publish what works. The best tools get a review and an owner, then go to everyone, instead of living in one person's account.
7. Not everyone wants to “prompt”
Some of our clients' employees tell us plainly that they do not want to “prompt”. They do not know what to ask, how to phrase it, or how to tell whether the answer is right. An empty prompt box is a blank page, and a blank page is hard.
Every company has builders and consumers, and builders are the minority: the people who enjoy it, understand the data and have the time. They thrive with a prompt: they know the question and can judge the answer. Consumers need a screen that opens on the right numbers, buttons that do the obvious thing, and training that fits in an hour.
A dashboard also shows everyone the same number, which is the point of a shared number. A chat gives each person their own version.
AI has changed how tools get built. It has not removed the need for a clear interface. Not everything needs to be a prompt.
8. Keep the freedom to switch models
The model you use today will not stay the best or the cheapest for long. Anthropic's own deprecation table lists six Opus models released since November 2025. Prices within one vendor's lineup also vary widely: per million input tokens, Claude Haiku 5.5 costs US$0.10, Opus 5.5 US$4 and Fable 5.1 US$10.
That spread is an opportunity. Categorizing 10,000 expense lines does not need the same model as building a cash-flow forecast. Sending routine tasks to Haiku 5.5 instead of Opus 5.5 costs 40 times less, and the next release may change which model is right for which job. The same logic applies across vendors.
Most assistants now offer some model choice. Microsoft 365 Copilot added Anthropic models next to OpenAI's in September 2025. The real lock-in is where the work lives. A dashboard built as a Claude artifact, a custom GPT or a Copilot agent lives inside that product, with its logic in prompts and chat history. Moving it means rebuilding it.
To stay free, keep what matters outside the assistant: data in your own storage, business rules as SQL, and tools that read from both. Open standards help. The Model Context Protocol (MCP), which Claude's connectors use, has been adopted by ChatGPT, Gemini and Microsoft Copilot, and now sits in a Linux Foundation fund co-founded by Anthropic, Block and OpenAI. When every model plugs into the same governed tables, switching models becomes a setting, not a migration.
A setup that holds up
Separate building from running. Use AI to build, with every connector it needs. Run the numbers the company depends on from a governed data layer, refreshed on a schedule, and let people and AI read the same tables.
AI belongs in the build loop, not the run loop. Once the logic is written and reviewed, refreshes need no model. The exception: enrichments and analyses an agent produces from the governed tables, such as categorizing expenses or explaining a variance right in a report. The agent then runs on a schedule, its results are stored like any other table, and every tool reads the same numbers.
Questions to answer before connecting everything
- Who needs to build, and who only needs to see the numbers?
- Which metrics need one official definition, and where is that definition written as code?
- Could we reproduce last year's numbers today, with the logic used at the time?
- Do we keep history, or only what our source systems hold today?
- What personal information would leave Québec, and has the privacy impact assessment been done?
- Who owns each tool people build, and where do the good ones get published?
- If a better or cheaper model ships next month, what would it take to switch?
Connectors are a real step forward. Use them to explore, to prototype and to answer one-off questions, and use AI to build. Then put the numbers your company runs on somewhere they are calculated once, kept over time and calculated the same way for everyone.
Disclosure: I am the founder of BEEM, a data and AI platform built for that foundation layer. I spend my days orchestrating agents directly in Claude, our whole team uses it heavily, and as a small company we live these issues every day. I don't only see them at our larger clients: they apply just as much to smaller companies. So I encourage you to do the same: create and explore, but think from the start about putting it into production across the organization. That is where the real gain is. The points above hold whatever platform you choose.
