For years “AI in the enterprise” has meant one specific thing: a chatbot for a specific case. A department picks its problem, a vendor builds the solution, six months later the thing works — more or less. For the next department, you start over.
PaLoMa was born because a client asked us for exactly that. A year later we’d realised the right answer wasn’t a chatbot — it was a product.
This is the honest account of how we got there.
The setup: a large automotive client
The client is a large automotive company FITEC had been working with for some time on other perimeters. Not a first contact, not a speculative POC. A conversation that started because they had already seen, in practice, how we work.
The initial request was specific: an AI assistant to support work in a particular technical area. Not an experiment — something to be put into production with real users, soon.
Three things we figured out in the first week
When you dig under the surface of a request like this in a large company, three constraints surface quickly that you can’t ignore.
Compliance and data residency. The technical data of an automotive company cannot leave the corporate perimeter. A solution running on a third-party service with your data in transit somewhere else is simply ruled out — not out of paranoia but as a matter of policy.
Lock-in to a single model. Tying yourself to a single LLM provider is a bigger strategic decision than it looks. The best model today isn’t the one from six months ago, and almost certainly isn’t the one six months from now. On top of that, some use cases want a local model for latency or privacy, others a model hosted on the client tenant, others still a premium foundation model on a cloud pipeline. A single model rules all of these out.
Internal fragmentation. In a company of this size there are dozens of Business Units, each with its own documentation, its own systems and — most importantly — its own technical lexicon. Building an assistant for one of those BUs means building something that will struggle to escape that perimeter.
At that point the question wasn’t “how do we build this chatbot” anymore. It was: “does it make sense to build a chatbot for one case, knowing that in six months we’ll be back here for the next BU, with a new set of documents and a new set of systems?”
The decision: a product, not a chatbot
The answer was to build a product designed to be parameterised. The same tool, configured differently, must work for different BUs — with different docs, different systems, different models.
Stated like that it sounds obvious. In practice it means every design decision has to be taken for reusability, not for the specific case in front of you. It’s slower, it’s harder, and it introduces a lot of problems a one-off chatbot doesn’t have. But building a chatbot for every BU is a promise you can’t keep — at least not at the commercial margin a healthy client expects.
In the market at the time, little covered these three constraints together. Microsoft Copilot — already a reference — had significant problems with data segregation and multi-user ACLs in the real enterprise scenario. The other consumer-grade tools didn’t even come close. Building was the only path.
Challenge 1: niche technical terminology
The first wall came early. Foundation models are extremely powerful on general lexicon, mediocre on vertical technical lexicon. In an automotive area with ten years of internal terminology, the base model failed in a subtle way: it didn’t err with confidence, it erred appearing to have understood.
The solution that worked wasn’t fine-tuning. It was the introduction of purpose-built support documents — glossaries, synonym mappings, explicit descriptions of internal terms — that the RAG system traverses before answering. It’s not romantically intelligent, but it’s surgical and it’s verifiable: whoever maintains the glossary controls what the model “knows”.
This is an important lesson for anyone building AI on a vertical technical domain: the hard part isn’t the model, it’s understanding where the linguistic delta between the general public and your domain causes errors, and bridging it deliberately.
Challenge 2: fragmented data
The second wall was architectural. The company’s knowledge didn’t live in one place — it lived spread across different systems that didn’t talk to each other. A useful answer required interpolating information from heterogeneous sources.
Initially we used function calling — the classic way an LLM can call external tools. It works, but it scales badly when every new system requires rethinking prompts, schemas and error handling. The more the integrations grew, the more the surrounding code became unwieldy.
The move to MCP (Model Context Protocol) changed the project’s shape. MCP standardises the way tools are exposed to the model: each system becomes an MCP server, each new integration is the sum of declared tools, not a rewrite. The exposed surface grows by addition, not by refactoring.
Obviously, for each client we still build custom integrations on request — not a magic generic connector. The difference is that complexity now lives in the individual MCP servers, not in a monolithic blob in the centre.
A technical decision we had to correct
Not everything worked on the first try. It’s worth telling one case where we had to stop and change course.
We had integrated the corporate ticketing system with the idea of extracting resolution patterns from closed tickets. The intuition was: there are years of problem-solving documented in there, let’s use it as a knowledge base.
The problem surfaced fast. The closing comments on tickets were not exhaustive — often a single line, “resolved”, or an implicit reference to a conversation outside the system. The signal was too noisy to extract reliable patterns.
We changed approach: instead of trying to reconstruct knowledge from tickets, we focused on the system’s daily reporting. There the data was structured, exhaustive, fresh. Usefulness came from a different angle than the one we had imagined.
The lesson is simple and hard to accept: upstream data quality determines everything. When you realise the source is poor, don’t insist on extracting value from it — reconfigure the use case around a rich source.
The moment we knew we’d made it
There was a precise point at which the project stopped being “something we’re trying” and became a tool in the daily flow. It happened when we integrated different systems — not one, several at once — and users started spontaneously asking for features that weren’t on the roadmap.
They weren’t waiting for the next release. They were proposing them: “if you add X, I can also do Y”. It’s the most reliable sign of product-market fit you can get in an enterprise context: it stops being your product and becomes their tool.
One of the use cases that generated the most value — more than we expected — was querying technical documentation with image handling. The ability to show visual context in answers had a disproportionate impact relative to the implementation complexity. PaLoMa today digests virtually all the document types in the company — manuals, specs, presentations, component images — with one explicit exception: actual CAD technical drawings, which remain for now outside the perimeter.
Governance: access via SSO
There’s a detail that often goes unnoticed in demos but makes the difference in production. Access to PaLoMa is managed by the client’s admin on the basis of the existing corporate SSO — we don’t duplicate identity, we don’t manage passwords, we don’t create a second authorisation perimeter.
In practice: every user sees only what their SSO profile allows them to see. When a consumer-grade vendor tells you they “support SSO” and then you discover content segregation is handled with tags and approximate rules, you’ve understood this can open a hole in the system.
The chain reaction
The product’s usefulness spread internally in a way we hadn’t planned. Interest expanded to other Business Units of the same company — not through commercial push on our part, but through internal word of mouth.
This happened because the product worked for the original use case, but — and here the initial decision comes back — it had been designed to be reconfigurable. The next BU wasn’t waiting for a six-month project: it was waiting for an ingestion of different documents and a new set of integrations. The unit cost per additional BU collapsed.
What we’d do again, what we’d change
We’d make the same strategic choice: start from a real need of a real client. Building an enterprise product in a lab leads to elegant solutions in search of a problem. Building it inside a real case, with the pressure of putting something into production, forces you to throw away everything that isn’t really needed — and to find, almost by accident, the things that are needed but you hadn’t thought of.
We’d change our online positioning. On almost every enterprise killer feature — real user segregation, multi-LLM, custom MCP, governance, multimodal ingestion, no-code admin — we are on par or ahead of much more visible tools. But potential clients aren’t noticing, because on the communication side we under-invested. We’re catching up.
The advice for anyone starting a similar enterprise AI project: start from a real need, not from a product vision. Simplify internal processes and the learning before the model. The LLM is the easy part — fitting it to the corporate fabric, the terminology, the permissions, the documentation you actually have, is the real work.
PaLoMa exists because a client asked us to build a chatbot but then had the vision to consider the more complete and flexible product.
