Natural Language Query on Oracle E-Business Suite 12.2: How It Actually Works

What this actually is

The feature lets a user type something like “which purchase orders are pending approval?” and get a result set back, without writing SQL and without knowing which of EBS's thousands of tables holds the answer. Oracle documents the approach in My Oracle Support note 3059877.1.

It is worth being precise about what is doing the work, because the marketing shorthand — “AI on EBS” — hides the design. Four components are involved, and only one of them is a language model:

• An Oracle APEX interface — the “Ask Oracle E-Business Suite” screen where the question is typed.
• Select AI in Oracle Autonomous Database — the orchestrator. It takes the question, enriches it with schema metadata, calls the model, and can run the SQL that comes back.
• The OCI Generative AI service — a large language model that turns the enriched prompt into a SQL statement.
• The EBS database itself — where that SQL executes, under EBS's own security.

Note what that ordering implies. The language model is not connected to your ERP. It is handed a question and a description of the schema, and it replies with text that happens to be SQL. Everything that touches real data happens on your side of the line.

The architecture, end to end

The diagram below traces a single question from a user's screen to the rows that come back.

1. The user asks a question in plain language in the APEX interface.
2. The question is passed to Select AI in Autonomous Database.
3. Select AI enriches the prompt with schema metadata — table names, column names, descriptions — and sends only that to the OCI Generative AI service.
4. The model returns a SQL statement written against the EBS schema.
5. The SQL executes inside the EBS database, under a restricted schema.
6. Only the rows the user is entitled to see come back.
7. The interface renders them as a table, a summary or a chart.

The security model is the whole story

Every serious evaluation of this feature collapses into one question, usually asked by someone in risk or security within the first ten minutes: does our financial data get sent to a language model?

Per Oracle's published design, no. The prompt and the schema metadata go to the model. The business rows do not. The model's output — SQL — is executed in your own database. That is a meaningful architectural distinction, and it is the reason the answer survives a security review rather than dying in one.

Underneath that, three mechanisms do the enforcing:

• A dedicated XX_NLQ schema with minimum grants. Generated SQL runs here, under least-privilege, not as APPS.
• Secured views that restrict which tables and columns are reachable at all, based on role.
• Virtual Private Database (VPD) policies that apply row filters at runtime, so existing EBS access control is honoured.

The practical consequence is worth stating plainly: a generated query is not trusted because the model is clever. It is constrained because the schema it runs under cannot reach anything the user was not already allowed to reach. If the model hallucinates a query against a table the user has no rights to, the database refuses it. The security does not depend on the AI behaving.

What it requires

That last row matters more than it looks. A common assumption is that anything AI-flavoured forces a full migration to cloud first. It does not. The Autonomous Database component must live on OCI, but EBS itself can stay where it is. For an organisation with a heavily customised on-premises 12.2 estate and no appetite for a migration this year, that changes the conversation from “re-platform everything” to “stand up one managed component and connect it”.

Where it fits, and where it does not

Set expectations honestly before anyone demos this to a CFO:

• It is for questions, not transactions. This is a read path. It answers; it does not approve, post or update.
• It does not replace your reports. Standard and BI reports remain the system of record for anything audited or recurring. This is for the ad-hoc question that would otherwise become a request to IT and a three-day wait.
• Metadata quality drives answer quality. Select AI enriches prompts with table and column descriptions. Schemas where those descriptions are thin — which, after twenty years of customisation, describes a lot of EBS estates — give the model less to work with.
• It is not a substitute for knowing your data. A confidently-worded wrong answer is still a wrong answer. Results still deserve the scepticism any new report would get.

What to evaluate before you commit

If you are weighing this up, the questions that actually decide it are less about AI and more about your estate:

• How much OCI footprint do you already have, and what does adding an Autonomous Database do to your run cost?
• How clean is the metadata on the modules you would point it at first? Procurement and Payables are usually better documented than a decade of custom extensions.
• Which responsibilities would get access, and does your VPD and secured-view configuration genuinely reflect the segregation of duties you think it does? This feature will find out.
• What is the actual question backlog? If nobody is waiting on ad-hoc data, the value is theoretical.

The honest summary

Natural language query on EBS 12.2 is not a reason to be excited about AI. It is a reasonable piece of engineering that solves a specific, real irritation: business users cannot get answers out of an ERP without going through someone technical. Oracle's design keeps your data on your side of the boundary and leans on database security you already have, rather than asking you to trust a model.

That is a lower ceiling than the hype suggests, and a much more solid floor.

This article is part of the ROSTAN Oracle Knowledge Hub — our engineering guidance on Oracle EBS, Fusion Cloud, APEX, Database 23ai and OCI, organised by topic.