AI integration for FileMaker: the options

Almost every FileMaker team is asking the same question: how do we get an AI assistant to work with the data in our solution? There is more than one answer, and they suit different jobs. This guide sets out the four common ways, what each is good at, where each runs out, and how to choose.

The four approaches

1. Export the data and give it to an AI

You export records to a spreadsheet or CSV file and upload it to a chat, then ask questions about it.

Good for: a one-off question about a small, finished set of records, where nobody minds that the answer is a snapshot.

Runs out when: the data changes (the export is stale the moment you make it), the data is large (chat tools limit how much a file can hold), or the question comes up every week (someone has to repeat the export each time). Every export also copies whole records, including columns the question never needed, out of your solution and into a chat history.

2. AI inside FileMaker

Recent versions of FileMaker can call AI models from inside a solution, with script steps that send text to a model or search by meaning, so a layout or script can summarise, classify or draft something.

Good for: adding an AI feature to a solution for everyone who uses it, such as summarising a notes field or suggesting a category when a record is saved.

Runs out when: you want people to ask open questions of the data. A feature inside a solution does the one job someone built it for. It is not a way for a person to type "which trade customers are overdue and by how much?" and get an answer from several tables.

3. A custom integration you build

Your own developer, or a consultancy, writes a service that sits between an AI provider and FileMaker. It calls FileMaker's Data API or OData API, decides what the AI may see and sends back the results.

Good for: a specific, well-defined workflow that needs custom behaviour, and where you have people who will look after it.

Runs out when: you count the ongoing cost. Someone has to build the connection, host it, secure it, decide which fields are safe, keep it working as the solution changes and keep up with how AI providers connect to tools. It tends to start as a week's work and become a system to maintain.

4. An MCP server

The Model Context Protocol (MCP) is an open standard that lets an AI assistant call a set of tools. An MCP server for FileMaker turns the tables and scripts you choose into those tools. People then ask questions in an assistant they already use, such as Claude, and the assistant calls the tools to fetch live answers. For the details, see what an MCP server for FileMaker is.

Good for: open questions from many people, answered from live data, with you deciding what the assistant can reach.

Runs out when: you need the AI to be a feature of your own screens rather than a separate assistant (approach 2 is closer), or the workflow is so specific that a general set of tools is not enough (approach 3 is closer). It also needs a server to run on, which Ailimu provides as one Docker container.

Side by side

Five questions that decide it

1. Who is asking? One analyst with a one-off question can export. A team asking questions every day needs something live.
2. Is the answer a feature or a conversation? A button on a layout is a feature. "What changed in March?" is a conversation.
3. What must the AI never see? Whichever you pick, you need to be able to say which fields are out of reach, and to turn writes off. If you cannot, do not connect it yet.
4. Where does the data go? Any assistant that answers from your data has to read the rows it uses, so those rows reach the AI provider. Choose a provider whose terms you are comfortable with, and a setup that sends as little as the question needs. See what leaves your server.
5. Who looks after it? A tool nobody maintains eventually breaks. Prefer something small that you can update by pulling a new version.

What to look for in any setup

Whatever you choose, these are the things worth checking before real data goes near it:

• Read-only by default, with writes something you switch on deliberately.
• Field-level control, not just table-level, so a salary column or a notes field can stay out.
• It signs in as a FileMaker account, so the privilege set you already maintain still applies and still has the last word.
• A record of what happened: at least every change, and ideally what was read, so you can see who did what.
• It runs where you choose, on your own network or your own server, and not only as someone else's cloud service.

Ailimu is built around these five; its activity log records every change, and reads too if you switch that on. The guide Give your team AI access to FileMaker, safely explains how each works in practice.

A reasonable path

For most teams the simplest sequence is:

1. Try the question with an export, to find out whether it is a useful one.
2. If people keep asking, put an MCP server in front of the file, read-only, with a few tables, and let a handful of people use it for a week.
3. Add AI inside FileMaker later, for the specific features that deserve a place on your own screens.

Build a custom integration only when you have a workflow the first three cannot do.

Next

• Connect Claude to your FileMaker data
• What is an MCP server for FileMaker?
• AI data analysis for FileMaker: ask in plain English