Artificial intelligence is quickly finding its place in the JD Edwards ecosystem, but successful adoption requires more than simply connecting an AI model to enterprise data.

At INFOCUS 2026, Rudolph Horn, Massimiliano Bartolozzi, Vishal Vishwakarma and Matt Sohrweide explored how organizations are approaching AI in JD Edwards today, from sales order automation and data analysis to governance, security and employee productivity. Their experiences revealed organizations at different stages of adoption, but also a common theme: AI delivers the most value when it is treated as one tool within a thoughtfully designed business process.

Different Paths to AI in JD Edwards

The panelists demonstrated that there is no single model for bringing AI into a JD Edwards environment.

Bartolozzi described two approaches his organization is already using. One involves using generative AI to build dashboards, converting the output to HTML and bringing it into JD Edwards through EnterpriseOne Page Composer. The other allows users to request JD Edwards information through Microsoft Teams and Copilot, with a gateway controlling access between the AI environment and JD Edwards.

Horn’s organization has taken a more cautious approach. Rather than directly integrating AI with JD Edwards, it currently uses AI as an “accessory” for tasks such as analyzing procurement data and maintaining a catalog containing roughly 180,000 SKUs. Before introducing deeper integration, Horn wants the underlying governance, infrastructure and security controls firmly established.

Vishwakarma shared examples of more direct automation, including using AI to process manual sales orders and automate customer chargeback claims. But even there, AI is not simply embedded into JD Edwards and given free rein. Analysis happens outside JD Edwards, middleware controls the exchange of information, and tools such as Orchestrator handle transactions within the ERP.

Keep JD Edwards as the System of Record

That architecture points to one of the panel’s most practical lessons: organizations do not necessarily need to put AI inside JD Edwards to gain value from it.

Vishwakarma’s sales order automation provides a useful example. AI extracts information from customer purchase orders, but the results first move through middleware into a separate audit or ledger table. Orchestrator then consumes the validated information and creates the transaction in JD Edwards.

That separation creates traceability. The team can see what AI originally extracted, compare it with what ultimately entered JD Edwards and investigate discrepancies. When the system cannot confidently interpret a purchase order, it alerts the appropriate employee to review the document and enter it manually.

This type of architecture also helps preserve existing security boundaries. Rather than giving an AI model unrestricted database access, organizations can use middleware and Orchestrator to tightly control which data and processes are exposed.

AI Governance Is a Business Responsibility

Technology, the panel argued, may actually be one of the easier parts of AI adoption. Governance, compliance, security and organizational responsibility are often harder.

Bartolozzi’s organization created a Digital Innovation Steering Committee that includes the CEO, CFO, HR, operations, compliance and IT. Proposed projects are evaluated for regulatory compliance, workforce implications, ROI and budget priority before moving forward.

Worthington Enterprises uses a two-level model. An AI Council oversees strategy, investments and approved technologies, while an Architecture Review Board examines individual solutions in greater technical detail, including responsible AI use, security and data policies.

Both approaches deliberately extend governance beyond IT. AI can affect financial decisions, employee workflows, sensitive information, customer data and operational processes, making cross-functional participation critical.

Governance can also reduce “shadow AI.” Bartolozzi described employees uploading company sales information into unauthorized public AI tools. His organization responded by blocking free AI tools on corporate systems while providing an approved enterprise Copilot environment. Horn described a similar strategy of establishing standards and warning employees against putting company information into unauthorized tools.

Human in the Loop Isn’t Enough — Humans Must Be Accountable

One of the panel’s most thought-provoking discussions centered on AI accuracy.

Horn challenged the idea that 90% accuracy should automatically be considered acceptable when AI is providing business information. If someone is asking for sales figures or using the output to make a financial decision, he argued, uncertainty matters.

The panel also went beyond the familiar phrase “human in the loop.” Horn suggested organizations should instead think in terms of a human accountable. Simply placing an employee somewhere in an automated workflow does little good if that person routinely accepts AI output without meaningful review.

Bartolozzi illustrated the point with an AI agent used to identify potentially incorrect production waste allocations. The system recognizes expected waste ranges and flags anomalies, even looking for another production batch that might explain an unusual allocation. But it does not make the final costing decision. A controller reviews the recommendation because an incorrect adjustment could materially affect product costs.

The appropriate amount of oversight should depend on the consequences of being wrong. Automating a low-risk productivity task is very different from allowing AI to create a purchase order, alter costing or expose payroll information.

Design for False Positives, Hallucinations and Incomplete Data

AI solutions also need to account for failures that may not be immediately obvious.

Vishwakarma offered a particularly useful example: imagine an AI agent expected to analyze a complete daily dataset. A server problem causes only 50% of the records to load, but the AI successfully analyzes that partial dataset and confidently returns a result.

Technically, the analysis may be correct. Operationally, the answer is wrong because the underlying data was incomplete.

A well-designed solution therefore needs the ability to return something equivalent to “unknown” rather than always producing an answer. Developers should explicitly account for incomplete inputs, false positives, hallucinations and model drift instead of assuming the AI will recognize those conditions itself.

This reinforces a broader point from the panel: AI projects still require the fundamentals of good solution design. Define the business problem, understand the required data, establish controls and determine what a successful output looks like before choosing the technology.

Use AI Where Intelligence Is Actually Needed

Another practical consideration is determining which portions of a workflow genuinely require AI.

Bartolozzi described an approach in which traditional programming handles data extraction, population and calls to Orchestrator. AI is reserved for the point where reasoning is required—for example, determining the likely correct allocation of production waste.

That distinction can reduce token costs while creating a more predictable architecture.

As Horn put it, organizations should not begin with, “We have AI. How can we use it?” They should begin with a business problem and determine the best tool to solve it. Sometimes that tool will be AI. Sometimes it will be Orchestrator, conventional automation, custom development or another established technology.

Start Small, Learn and Expect the Technology to Change

For organizations early in their AI journey, Vishwakarma recommended starting with low-risk use cases, learning the capabilities of approved tools and gradually progressing toward more complex processes.

That experimentation matters because the technology is changing remarkably quickly. Bartolozzi described beginning an automated sales order entry initiative three different times as the available technology evolved—from a customer portal, to a chatbot, to AI capable of interpreting orders arriving by email.

The lesson wasn’t to chase every new technology. It was the opposite: define the outcome first so that rapidly changing technology does not dictate the project.

The same principle applies to workforce strategy. Rather than viewing AI simply as a headcount-reduction mechanism, the panel discussed using it to support growth, increase capacity and shift employees toward higher-value responsibilities. Bartolozzi described reskilling employees as AI trainers who can provide the business knowledge models cannot learn reliably from the public web.

A Smarter Approach to AI Starts with the Problem

The panel’s experiences showed both the opportunity and the discipline required to successfully use AI in JD Edwards.

AI can interpret documents, analyze large datasets, assist developers, automate repetitive work and give users easier access to organizational knowledge. But those capabilities do not eliminate the need for strong architecture, security, governance or human judgment.

Perhaps Horn summarized the approach most effectively: AI is not the answer regardless of the question.

For JD Edwards organizations, the better starting point is the business problem. Understand the outcome, determine the acceptable level of risk, establish who is accountable and then decide whether AI is the right tool to help get there.

Want more?

Explore more content and resources to help you get the most from your JD Edwards investment:

• Visit the Quest Learn Library for blogs, how-to demos, and on-demand sessions.
• Connect with peers in one of our Quest JD Edwards Community User Groups to swap stories, ask questions, and share tips with other users facing the same challenges.
• Bookmark LearnJDE.com for updates from JD Edwards development.

Not a Quest member yet? Join today and tap into the ultimate Oracle customer network.