The risk in "chat with your database"

In the usual setup, the AI reads the database structure, writes a query in SQL (the language databases use for questions) and runs it. Two things can go wrong.

First, the AI has to guess what the tables mean. Business systems rarely use plain names. A column called MT05_TRK_LNK tells a model almost nothing, so it guesses which tables to combine, and a wrong guess still comes back as a confident answer. Why AI gives wrong answers about your business data covers this in more detail.

Second, the AI can query anything its connection can reach. If it can write any query, it can read costs, margins and customer records that the person asking was never meant to see, and it can run queries slow enough to hold up the system everyone else is using. If the AI is a cloud service, the table structure and the query results also leave your network.

Illustration titled Two ways to answer a question. On the left, under AI writes its own query, a question bubble goes to an AI that reaches into a database with every drawer open, with the warnings Guesses what tables mean and Can reach every table. On the right, under AI picks an approved function, a question bubble goes to a short list of approved cards and then to a locked database inside an outline of the business, with the notes Crosswalk explains each name, Only approved queries run and Stays inside your network. A bar at the bottom reads: You decide what the AI can ask the database.
Figure 1. Letting the AI write queries against the whole database, compared with letting it choose from approved functions.

A real case: an ERP with more than 900 tables

Intelligence Factory's published aviation ERP case describes an aviation software vendor that wanted people to ask operational questions in everyday language. As reported in the original case, its Oracle database held more than 900 tables and thousands of columns, with names such as MT05_TRK_LNK, ORD_HDR_FLG_X and INV_RSRC_IDX. Teams needed answers about inventory, maintenance records and part tracking without opening the whole database and without sending sensitive industrial data to public cloud AI models.

The design had three parts, described in the next three sections.

Step 1: build a crosswalk from the documentation

A crosswalk links each cryptic database name to the business term people actually use. In the aviation case, training manuals and developer notes were read and matched against the live database structure, so the table and column names were linked to concepts such as purchase order, line item and vendor. The links were expressed as an ontology, a model of the business's concepts and how they relate, built with Buffaly. What an ontology is, explained for business owners explains the idea.

Look for the same raw material in your own business: the system's manuals, report definitions, old specifications and the notes of whoever maintains it.

Step 2: answer with approved functions, not free-form SQL

Instead of writing new SQL for every question, the system matched each question to one of a set of approved functions. A function here is a named query that has been written and tested in advance, with blanks for the details. In the case, "Show me purchase orders from last month" and "List everything we bought from Acme" both matched one function, purchase orders by vendor and date range, with the vendor and dates taken from the question. Each function called approved SQL, a stored procedure or an internal API.

This limits what the AI does. It reads the question and picks a function. It does not write a query, so it can reach only the data the functions expose. A question that matches no function gets no answer from the database, and that gap shows which function to add next. Can you trust an AI agent with orders, prices and invoices? applies the same idea to actions: the AI makes a request, and the system decides what is allowed.

Step 3: keep the query path inside your systems

In the aviation case, the query path stayed inside the business's own systems. The original case reports that operational data stayed local and that no general-purpose outside AI model was needed for this query path. Because questions were matched to functions, the system also did not need to load the enormous database structure into a model.

The published case does not report accuracy, response times, user numbers or savings, and it does not name the customer.

Start with the questions people actually ask

The aviation project did not try to cover the whole database at once. Its reported starting set was 10 to 15 function classes, chosen from customer interviews, searches of real usage logs and judgment, then expanded as real questions came in.

You can build the same starting list. Write down the questions people in your business ask most often. For each one, note who asks it, how often, and where the answer comes from today: a report, an export or a person. For a flooring wholesaler, the list might start like this:

  • What do we have in stock in this style and color?
  • Which purchase orders with this vendor are still open?
  • What did this customer order last year?
  • Which samples are out with customers?

One question can be asked many ways. "Do we have any of this style left?" and "What's on hand in this style?" ask the same thing, so they match the same function.

Illustration titled Many ways to ask, one approved function. Three question bubbles read What's on hand in this style?, Do we have any of this style left? and How much of this style is in stock? Arrows lead from all three to one card labeled Stock on hand by style, which leads to a locked database labeled Approved query runs locally. A bar at the bottom reads: Start with the questions your team already asks.
Figure 2. Several wordings of one question match one approved function. Example questions for a flooring wholesaler.

Questions to ask an AI vendor

  • When someone asks a question, does your AI write its own SQL, or choose from approved queries?
  • Which tables and fields can it reach, and who decides?
  • Does our data, or the structure of our database, leave our network? Which outside services see it?
  • What happens when a question matches nothing?
  • How is a new question added, and who tests it before people rely on it?
  • Can we see which query produced each answer?

Send us the questions your team asks

If your team waits on reports or exports to answer routine questions, send us the questions they ask most and tell us which system holds the data. We will tell you which ones can become approved functions and how the query path would stay inside your systems. Tell us about your current system, or read how full service works.