Every software vendor on Earth currently has an AI story, and most of those stories are 80% press release. So here's ours, calibrated for honesty: we build AI features into FileMaker systems for real clients, using Claude and other large language model APIs, and some of it is genuinely transformative — while some of what gets promised in this space is nonsense. This guide separates the two.
What actually works today
These are things we can build into a FileMaker system now, that work reliably enough to put in front of staff:
Summarisation. You have a customer record with 40 emails, 12 call notes, and 3 complaints attached. An LLM can produce a two-paragraph "state of this customer" summary on demand. This is the least glamorous AI feature and possibly the most loved, because it turns ten minutes of reading into ten seconds.
Extraction. Unstructured text in, structured fields out. Paste in an enquiry email and have the system pull out the name, company, phone number, and what they're asking for — into proper fields, ready to work with. Same trick for supplier confirmations, delivery notes, CVs. This was previously the job of a human with a highlighter.
Drafting into fields. Generate a first draft of a quote covering letter, a chase-up email, or a job description from the data already in the record — in your house style, because the prompt includes examples of it. Staff edit rather than compose from scratch. Nobody sends the draft unread (more on that below).
Semantic search. Traditional search finds records containing the word "leak." Semantic search finds records about leaks — including the ones that say "water coming through the ceiling." FileMaker's recent versions support the underlying machinery (storing text as embeddings and finding similar records), and Claris documents this in its official help. For any business with years of free-text notes, this is quietly a big deal.
Classification and triage. Incoming enquiries sorted by type, urgency, or department. Support tickets flagged as "this one sounds like a cancellation risk." The model does the first pass; humans handle the exceptions.
What's hype
"AI will build your system for you." AI tools genuinely accelerate development — we use them daily and they've made us faster. But a business system is mostly decisions, not typing: what the workflow should be, what happens to the edge cases, what the VAT treatment is. AI doesn't attend your operations meeting. Someone still has to understand the business, and generated-but-not-understood software is a liability with a friendly interface.
"Fully autonomous agents will run your operations." The demos are impressive. The reality in 2026 is that letting a language model take unsupervised actions on live business data — issuing refunds, changing prices, emailing customers — is not something we'd deploy, and we're the ones selling this stuff. The reliable pattern is AI proposes, human disposes: the model drafts, flags, and suggests; a person approves. That pattern works brilliantly. Skipping the person does not, yet.
"It's a magic button." LLMs are confidently wrong a small percentage of the time. A well-designed feature accounts for this — extraction results land in a review screen, not straight into your invoicing. Any vendor who doesn't mention error rates is selling you the press release.
Data privacy — the questions to ask
Sending business data to an AI API means sending it to someone else's server, so the questions are the same as for any cloud service, plus one new one:
- Is the data used to train models? The serious API providers (Anthropic among them) offer commercial terms where your API data is not used for training. This is the new question, and it has a good answer — but check the terms, not the marketing page.
- What actually needs to be sent? Good design minimises exposure. Summarising a customer's history doesn't require their bank details; the integration should send only the fields the task needs, and can redact identifiers before anything leaves the building.
- Where does it go, and is that acceptable to you? For most UK businesses under UK GDPR, using an AI API is like using any processor: understand the data flow, cover it in your records, and don't send special-category data without proper thought. If you handle genuinely sensitive data, that shapes the design — sometimes the answer is "AI for these fields, never for those."
- Is anything stored? API calls can be configured so prompts aren't retained long-term. Again: check, don't assume.
None of this is a reason to avoid AI features. It's a reason to build them deliberately rather than bolting a chatbot onto everything.
How integration actually happens
No magic. An LLM is reached the same way as Xero or any other modern service — an HTTPS API call. FileMaker makes the call (from a script, or server-side so the heavy lifting never touches the user's machine), sends a prompt built from record data, gets a response back, usually as JSON, and writes it into fields. The craft is in the unglamorous parts: prompt design that produces consistent output, telling the model to return structured JSON so results parse reliably, handling the occasional failure gracefully, and keeping keys and costs under control.
It's the same discipline as any API integration — which is why an AI feature from a team that's been doing integrations for years tends to behave better than one from a team that's been doing AI demos for months. We've been building FileMaker systems since 1998; the AI parts are new, the engineering habits aren't.
Where to start
Not with a strategy document. Pick one narrow, boring, high-volume task — summarising records, extracting enquiry details, drafting one type of email — and build that. It'll be live in weeks, staff will judge it on results, and you'll learn more from one real feature than from any amount of AI theatre.
We offer a free initial consultation, and we're happy to tell you which parts of your wishlist are real and which are still hype — see AI in FileMaker for more on what we build.
Call 0330 113 0958 or email info@flaresoftware.co.uk.