There is a conversation happening in regulated businesses across Europe and North America that goes roughly the same way every time. The board has seen what AI can do and wants it in the organization’s core systems. The risk and compliance functions have one question that stops the conversation cold: where does our data go when we use it. For a bank, an insurer, a hospital, or a public body, that is not a technicality. It is the difference between a project that ships and a project that dies in review.
Oracle APEX 26.1, the May 2026 release of Oracle’s low-code platform, is relevant to that conversation for a specific reason. It makes it practical to add AI to enterprise applications while keeping sensitive data inside the organization’s own environment, rather than sending it to a commercial model in someone else’s cloud. That is the difference this article is about.
Does using AI in Oracle APEX 26.1 mean sending your data to OpenAI or another commercial provider? Only if you choose a configuration that does. By default, APEX connects to an external AI service that you select, and that can be a commercial model, in which case data is sent to that provider. But Oracle APEX 26.1 also supports running AI on models hosted inside your own infrastructure, so sensitive data does not have to leave your environment to benefit from AI. The privacy outcome is a design decision, not a fixed property of the platform, and that is exactly why how you set it up matters.
The tension is not new, and it has sharpened. The rules that govern sensitive data have become stricter and more specific in recent years. In the European Union, the General Data Protection Regulation sets firm expectations on how personal data is processed and where it travels, and for financial entities the Digital Operational Resilience Act, in force since January 2025, adds explicit obligations around managing technology and third-party risk. In the United States, sector rules such as the HIPAA Security Rule for healthcare and the expectations of financial regulators point in the same direction. The wording differs by jurisdiction. The underlying requirement is the same: an organization must be able to say, and prove, what happens to its data.
Sending that data to a commercial AI model makes the answer harder, not easier. The organization no longer fully controls where the data sits, who can access it, or how it might be used. For many ordinary tasks that is an acceptable trade. For the data that sits under a regulated business, it often is not.
Commercial AI models are genuinely useful, and for a great many purposes they are the right choice. The mistake is not using them. The mistake is reaching for them by default for sensitive workloads, without asking whether the data needs to leave the building at all.
When an organization wires a regulated system directly to a commercial model, every question a user asks, and often the data behind the answer, travels to a third party. That creates a chain of issues a compliance function has to work through: data residency, confidentiality, the terms under which the provider handles the information, and the simple fact that the organization can no longer give a complete account of where its data has been. None of this means AI is off the table. It means the default path is the wrong one for this class of data, and that a different path is needed.
This is where the release earns its place in the conversation. In Oracle APEX 26.1, AI features connect to the model through a configuration called a Generative AI Service. The important point for a regulated business is that this configuration is flexible about where the model lives.
APEX can connect to major commercial providers, which suits non-sensitive work. It can also connect to a model running inside the organization’s own infrastructure, through local model frameworks such as Ollama and vLLM, so that the data sent for processing goes to a model the organization controls rather than to an outside party. At the database layer, the most recent version of the Oracle Database, Oracle AI Database 26ai, adds further private options, including the ability to run certain AI processing and to generate the mathematical representations behind features like search directly inside the database, without sending the underlying data out at all. Some of these stronger options depend on running a current version of the database, which is part of why the starting point matters.
In practical terms, that gives a regulated organization a spectrum of choices rather than a single take-it-or-leave-it path. The table below sets out the main options and what each one means for data.
| AI deployment option in APEX 26.1 | Where the model runs | What happens to your data | When it fits |
| Commercial provider (for example a major hosted model) | A third-party cloud | Sent to the provider for processing | Non-sensitive tasks where convenience and capability matter most |
| Oracle cloud AI service | Oracle Cloud Infrastructure | Processed within Oracle’s cloud | Organizations standardized on Oracle Cloud that accept that boundary |
| Local or private model | Inside your own infrastructure (for example via Ollama or vLLM) | Stays within your environment | Sensitive and regulated workloads where data must not leave |
| In-database processing | Inside the Oracle Database itself | Does not leave the database for that task | The strictest cases, where keeping data in the database is the requirement |
Credentials for any of these services are stored securely on the server and are never exposed to the browser or to application code, which closes one of the more common gaps in homegrown integrations.
Choosing where the model runs is the first half of the picture. The second half is what the AI is allowed to touch, and here Oracle APEX 26.1 is built to respect the controls an organization already has.
Consider the most visible new feature, the ability to adjust reports using plain language. When a user asks to see a particular slice of data, APEX does not hand a commercial model free rein to write and run queries against the database. It interprets the request and applies standard, visible report settings, filters, groupings, and charts, within the data-access rules that already govern that report. The user gets a faster answer, and the boundary around the data does not move.
The same principle holds at the database level. Where the Oracle Database enforces row-level security, so that different users see only the records they are entitled to see, those rules continue to apply to AI-assisted access. Because the database enforces those rules regardless of how a query was produced, an AI feature does not become a side door to data a user was never allowed to see in the first place. This matters because the fear with AI in core systems is not only that data travels, but that it leaks across internal boundaries. Keeping the existing access controls in force addresses both.
“The question we hear from financial and healthcare clients is never just ‘can we use AI.’ It is ‘can we use AI without our data leaving our control and without breaking the access rules we already enforce.’ With this release, for the first time, the honest answer to both is yes, provided it is set up correctly.” Matt Mulvaney, Oracle ACE Director at Pretius
Controlling what AI is permitted to do, and proving it after the fact, is a broader topic in its own right. We cover the governance and audit side, including how Oracle APEX 26.1 keeps AI-assisted development inspectable, in a separate article [AI in Your Business, Without Losing Control: How Oracle APEX 26.1 Keeps AI Governed].
Consider an insurer whose claims team wants to ask a system to summarize the history of a complex claim in plain language. Sent to a commercial model, that claim data, some of the most sensitive information an insurer holds, would travel to a third party to produce the summary. With a private model running in the insurer’s own environment, the same summary is produced without the data leaving the building. The capability is identical. The data exposure is not. This is an illustrative example rather than a specific client, but the pattern is the point.
Once data can stay inside the environment, a set of use cases that were previously blocked becomes available.
In financial services, that can mean AI-assisted analysis and reporting over customer and transaction data without that data crossing a regulatory boundary, which keeps the work consistent with a DORA-aligned approach to technology and third-party risk. In insurance, it can mean applying AI to claims and policy information that is too sensitive to send to an outside model. In healthcare, it can mean using AI on patient-related data while staying within the confidentiality requirements that govern it. In the public sector, it can mean adopting AI without breaching data-residency obligations that require information to remain within a particular jurisdiction.
The common thread is that the value of AI no longer has to be weighed against the risk of exporting sensitive data, because the two have been separated. The organization gets the capability and keeps the data.
The reason this is a service and not a switch is that getting it right depends on decisions that sit outside the APEX application itself. A private deployment means standing up and running a model inside the organization’s infrastructure, sizing it for the workload, connecting it to APEX correctly, and confirming that the database, its version, and its security configuration support the features the organization wants to use. Some of the strongest private options depend on running a current version of the Oracle Database. Done well, the result is AI that the compliance function can sign off on. Done carelessly, it is a new set of risks wearing the label of a solution.
This is the work that turns the promise of Oracle APEX 26.1 into something a regulated business can actually deploy, and it is where a partner with both Oracle depth and security discipline matters. It also starts with an honest look at what an organization is running today, which is the subject of a separate article on readiness [Is Your Oracle APEX Estate Ready for 26.1 and AI? A Business Leader’s Starting Point. For the wider picture of what the release changes, see the overview [Oracle APEX 26.1: What It Means for Your Business — and Why It Is Not Just Another Update].
How do I stop Oracle APEX from sending data to a commercial AI provider? You point APEX at a model hosted in your own infrastructure instead of a commercial service. APEX connects to whichever AI service you configure, so to keep data in-house you select a private or local model, and the data is then processed there rather than sent to an outside provider such as OpenAI.
Can Oracle APEX 26.1 use a local or private LLM? Yes. Oracle APEX 26.1 supports connecting to models hosted in your own infrastructure through local model frameworks such as Ollama and vLLM, using the same secure configuration model APEX uses for any AI service. The Oracle Database that APEX runs on also offers in-database options for keeping certain AI processing entirely within the database.
Is AI in Oracle APEX 26.1 GDPR or DORA compliant? Compliance depends on how a system is designed and operated, not on a single product feature, so no platform can be “compliant” on its own. What Oracle APEX 26.1 provides is the ability to run AI without sending data to an outside party and while keeping existing access controls in force, which supports a GDPR and DORA-aligned approach. The surrounding architecture and processes are what determine compliance.
What is a Generative AI Service in Oracle APEX? A Generative AI Service is the configuration in APEX that defines which AI model an application uses and how it connects to it. It specifies the provider, the endpoint, and the credentials, which are stored securely on the server. It is the single place where an organization decides whether AI runs on a commercial model, an Oracle cloud service, or a private model in its own infrastructure.
Does Oracle APEX run AI-generated SQL on my database? For its natural-language reporting, no. APEX interprets the user’s request and applies standard, visible report settings within the existing data-access rules, rather than executing arbitrary AI-generated queries against the database. This keeps AI-assisted reporting within the same boundaries that govern the report itself.
Adding AI to a regulated system without sending data outside the organization is achievable with Oracle APEX 26.1, and the outcome depends on getting the architecture right. Pretius is an Oracle Partner with 5 Oracle ACEs and ISO 27001 certification, and has delivered Oracle APEX applications for financial institutions, insurers, and enterprises across Europe. If you want to understand what a private AI deployment would look like in your environment, and whether your current setup supports it, get in touch with our team for a conversation.
