From scattered data to a layer an AI can query

Summary

The visible ask was clear: "we want a chatbot that answers questions about our data". The real problem was not the chatbot. It was data scattered across several products, metrics with no single definition, and business rules that lived only in a few people's heads.

Before connecting any AI model, we had to build something more boring and more important: a trustworthy, curated, queryable data layer.

Context

The business ran several distinct products, each generating data in its own way: relational databases with transactions and states, document sources with semi-structured information, and a few external APIs. Each product had its own vocabulary and its own implicit rules.

The expectation, driven by market noise, was to jump straight to the chatbot. The reality was that there was not even a shared definition of the basic business metrics.

For confidentiality, this case is written in a sanitized way: no real data, product names or internal figures. The focus is on the approach and the decisions, not on client information.

Visible Problem

• Scattered sources: each product stored its data in different places and formats.
• Undefined metrics: the same word meant different things to different teams.
• Hidden business rules: critical logic that had never been written down.
• Sensitive data with no clear control over who can access what.
• The idea of a chatbot answering over data nobody fully trusted.

The symptom looked like "we are missing AI". The system problem was deeper: there was no trustworthy database for an AI to answer from.

Initial Hypotheses

Approach

Instead of starting with the chatbot, I started with the sources. The useful question was not "which model do we use", but "what would have to be true in the data for any answer to be trustworthy".

• Mapped every source: what it generates, how often, what quality it has and who owns it.
• Built ETLs to move relational, document and API sources into a common model.
• Landed the data in a curated PostgreSQL model, separating operational from analytical.
• Defined explicit metrics, with a single source of truth per concept.
• Made business rules explicit instead of leaving them in people's heads.

Architecture

Sensitive Data and Limits

Enabling AI-assisted queries over internal data forces you to take access control seriously. It is not enough for the model to answer; what matters is which data it can see and what it should never expose.

• Separated sensitive data from the general-purpose queryable layer.
• Defined which questions have a trustworthy answer and which are out of scope.
• Left the AI layer as a consumer of a curated model, not as direct access to raw sources.

Trade-offs

This approach adds a layer to maintain: pipelines, metric definitions, monitoring and documentation. And it is slower than wiring a chatbot to whatever already exists. But it avoids a worse problem: an AI that answers fast and confidently over data nobody validated.

Result

• A trustworthy, curated database, with metrics defined once.
• Business rules written down and reviewable, instead of scattered knowledge.
• A layer ready for dashboards, automation or AI-assisted queries.
• An AI that, when it arrives, answers over data you can actually trust.

Lessons Learned

The most visible part of an AI project is the chatbot, but it is rarely where the real work is. Useful AI starts earlier: in the sources, the metrics, the business rules and the control of sensitive data. If that base does not exist, AI does not solve the problem; it only makes it harder to spot.