What is an AI data analyst?
It is not a chatbot bolted onto a dashboard. It takes a question in plain English, finds the right tables, writes the SQL, runs it against a read-only copy of your database, and hands back the answer with the query attached so anyone can check it.
The people who need one are the people currently waiting. Every company has a queue of questions sitting in front of the one or two engineers who can write SQL. How many trial users from the June cohort converted is fifteen minutes of work and a three-day wait for whoever asked. The wait is the cost, not the fifteen minutes.
Why do text to sql tools get the answer wrong?
Because the model is allowed to guess. Most text to sql products paste a schema dump into the prompt and hope it gets read. On a large schema the dump is truncated, and the model fills the gap with a column name that sounds plausible. It asks for a signup date column that does not exist, the query fails, it tries again, and eventually it lands on something that runs. A query that runs is not a query that is right.
The second failure is quieter and worse. The join is valid SQL and returns a believable number from the wrong relationship. Almost every production database has a legacy column kept for backward compatibility, and anybody who was not told will keep joining on it for years. Nobody notices, because the number looks like a number.
Neither problem is solved by a better model. They are solved by not letting the model near the query until it has read the schema.
How does natural language to SQL stay correct on a real schema?
By removing the ability to guess rather than asking politely. The build runs a three-stage sequence. Stage one returns your business context and a short-lived signed token. Stage two takes that token and returns the exact table definitions for the tables named, issuing a second token scoped to each individual table. Stage three refuses to execute anything unless it is handed a valid token for a table in that query, and the tokens expire after fifteen minutes.
The effect is easy to state. The model physically cannot run a query against a table whose schema it has not just read. That is not an instruction it might ignore under pressure. It is a signature check in code, and it fails closed.
Result size is capped too, which sounds like a limit and works as a correctness feature. A query returning more than a few kilobytes is rejected, so the aggregation has to happen in SQL where it is verifiable, rather than the model pulling ten thousand rows and doing arithmetic on them out of sight.
Where does it run, and who holds the database credentials?
Inside your infrastructure. The service is deployed in your own cloud account, pointed at a read-only replica you create, using a role your team grants. We never hold a credential to your database. In practice that is the sentence that ends a security review rather than starting one.
The role matters more than most teams expect. A blanket read-only grant can read every column in the database, including compensation, contact details and anything regulated. So part of the engagement is writing the grant list: the specific tables and columns the analyst may see, approved by whoever owns data protection at your company, and nothing outside it. A question about data that is not on the list fails at the database rather than being caught by a filter somewhere upstream.
Every question is logged with the SQL it generated, the tables it touched, how long it took and whether it errored. When somebody asks where a number came from, the answer is a row in a table rather than a memory.
What does the semantic layer actually contain?
The part that makes answers correct rather than merely valid. A schema tells the model that a column exists. It does not tell it which filter your company means by a free-tier user, or that two tables describe colleges and only one of them is the source of truth, or that a name field on a legacy table has meant nothing since 2024.
So the engagement writes that down: your glossary in your own words, the joins that are correct as against the joins that merely run, the filter behind each business term, and the tables to ignore entirely. Every company's version is different, which is exactly why this is an engagement and not a signup form. It is also where the accuracy comes from, so it is the part that gets the most attention.
How is this different from a BI tool or an AI analytics tool?
A dashboard answers the question somebody already anticipated. This answers the ones nobody did, which is most of them, and it answers them in the ninety seconds before the person gives up and guesses instead.
A vendor AI analytics tool wants your data in their cloud, or at the very least your credentials in their vault. This runs in yours, and the difference shows up the first time your largest customer sends a security questionnaire.
It also connects to the assistant your team already pays for. The analyst is exposed over MCP, so it appears as a tool inside Claude or ChatGPT in your organisation's workspace, behind your existing Google sign in. Nobody has to learn a new interface or remember another password, which is usually the difference between a tool that gets used and one that gets demoed once.
Can it query several databases at once, including different types?
Yes, and that is usually the reason a team calls in the first place. PostgreSQL, MySQL, MariaDB, SQL Server, Oracle, Amazon Aurora and CockroachDB on the relational side. Snowflake, BigQuery, Amazon Redshift, Databricks and ClickHouse for the warehouse layer. MongoDB, Cassandra, ScyllaDB, DynamoDB and Elasticsearch where the events and documents ended up.
They get federated into one queryable surface, so a join between a table in Postgres and a table in ClickHouse is a single statement rather than two exports and a lost afternoon. Where the databases sit in different VPCs or different cloud accounts, a private read path is built between them, peered or through a private endpoint, and neither database is ever exposed to the internet.
Spreadsheets, CSV exports and Parquet files sitting in a bucket are registered as tables alongside the real ones. That is the part teams assume they need a data lake for, and it is very often the part holding the number they actually wanted. Structured and unstructured, queried together, without buying a lake or hiring somebody to run it.
Can the whole pipeline run on a private LLM instead?
Yes, and for some buyers it is the only version that ever gets approved. In the default deployment the only things that leave your network are the question text and the table definitions. The rows never do: the SQL executes inside your infrastructure and the result set is rendered there. For a lot of teams that is already inside policy, and it is worth checking before assuming otherwise.
Where it is not, the entire pipeline moves onto a model running on hardware you own. vLLM serving on your own GPU or a dedicated instance in your own cloud account, the analyst reaching it over a private network path with no public exposure, and nothing at all crossing your perimeter. Not the question, not the schema, not the answer. A fully air-gapped deployment with no outbound network access is supported too.
This is the same private LLM infrastructure work Axionry already does as a standalone engagement, so it is a configuration of this build rather than a second project with a second bill. Regulated healthcare, financial services and public-sector teams usually start here instead of arriving at it after a failed security review.
Can it find correlations nobody thought to look for?
This is where a single setup pays for itself the second time. Once the databases are federated and the glossary is written, the useful questions stop being the ones somebody planned a chart for. Which acquisition channel produces users still active in month six. Whether support volume moves ahead of churn or behind it. Which onboarding variant correlates with a second purchase rather than a first.
None of those have a dashboard, because nobody knew to build one, and they are usually the questions that move revenue. The analyst can hold both sides at once because both sides now live on the same surface. It writes the query, runs it, and shows you the SQL, so your team argues with the method rather than trusting a number on faith.
What it will not do is tell you a correlation is a cause. It returns the relationship and the query that found it. The judgement stays with your people, which is the correct place for it.
What does this actually replace?
The queue, first. Every company has two or three people who can write SQL, and a line of colleagues waiting on them. Those engineers stop being a help desk and go back to building, which is usually worth more than the analytics itself.
Then the seat sprawl. Most business intelligence licences are paid for people who open the tool twice a quarter, and the seat exists only because that person occasionally needs an answer. That is precisely the use case that should never have needed a seat.
It does not replace your dashboards, and it should not try to. Standing numbers belong on a chart somebody designed deliberately. What changes is everything that is not a standing number, which in most companies is the large majority of what actually gets asked.
Has this been built before, or would we be the first?
It runs in production at AccioJob, where Neeraj is head of engineering. Two Postgres databases, the full table definitions for both held in the knowledge base, and cross-database joins handled through Postgres foreign data wrappers so a single question can span both products in one statement.
The proof chain, the grant scoping and the audit log described on this page are the ones in that system. They are not a design sketch waiting for a first client to fund them.
How an engagement runs
| Stage | What happens | Timeline |
|---|---|---|
| Assessment | Read-only access to one replica. Schema inventoried, the questions your team actually asks classified as answerable or not, the grant list drafted with your data owner, and acceptance criteria written as testable statements | Five business days from access |
| Build | Deployed in your cloud account, connected to your replica and to your Claude or ChatGPT workspace, with the semantic layer written for the first domain. Delivered as separately accepted checkpoints, each invoiced only after you accept it | About three weeks |
| Upkeep, optional | The semantic layer maintained as your schema moves, further domains added, and the generated queries reviewed each month | Monthly, cancel any time |
Builds start at $6,000 and most land between $6,000 and $18,000, set by how many databases are in scope and how much of the schema the first domain has to cover. Optional upkeep from $1,200 a month. The assessment is a fixed fee credited in full against the build, and nothing is payable before a checkpoint is delivered and accepted. Thirty days of defect correction is included.