Many software vendors, both within and outside the IBM i ecosystem, currently claim their platforms make data ‘AI-ready’.
For an IBM i shop, that phrase needs a bit of a translation.
A recent Fresche Talks session, “IBM i Data to AI-Ready Analytics: Where Your Growth Comes Next”, brought together Fresche’s analytics and data leads to answer the question directly.
It’s a useful reference point for anyone running RPG, COBOL or Synon applications on IBM i and wondering what to do next with AI.
We work with IBM i teams every day on support, development, modernisation and integration projects and the conversation in that session mirrors what we hear from clients: the interest in AI is real, but so is the caution.
Nobody wants to put decades of business-critical code and data at risk just to chase a trend.
Below, we’ve pulled out the four questions IBM i leaders ask most often, answered using what was actually said in the session.
What does AI-ready data actually mean for IBM i?
Db2 for i holds decades of accumulated business data. The vast majority of that business data was never designed with AI in mind.
Traditional IBM i system object and column names were often limited to ten characters, resulting in abbreviated names that can be difficult to interpret outside the original application.
That combination means raw Db2 for i data may not be sufficiently documented, contextualised, integrated or governed to be used directly by an AI application.
Making data AI-ready means addressing that gap on three fronts: cleaning and organising the data, making it readily and securely accessible to external analytics and AI platforms.
In practice, that context takes the form of longer, descriptive field and table names and column descriptions layered on top of the existing database, plus governance so the data can be trusted once it’s in use. It also usually means bringing in data from outside IBM i, such as CRM systems, and combining it with the IBM i data in one place.
How do you modernise IBM i data access without risking what already works?
The instinct with any modernisation conversation is to assume it means migrating off IBM i.
That has the potential to be an expensive project with real business risk attached.
That’s not the starting point the Fresche Talk session described.
The approach discussed is augmentation rather than migration: adding or mapping descriptive SQL table and column names, aliases, views and column descriptions without altering the underlying data or core application logic that already runs the business.
From there, journal-based replication captures inserts, updates and deletes from the IBM i journal and applies those changes to a connected data platform.
That’s where the metadata, additional data sources and AI access controls get added. The production system carries on exactly as it did before. Several vendors already run a replication tool for disaster recovery or high availability, and the session made the point that AI-focused replication adds no more overhead, and no more risk, than that existing tooling.
How does an MCP server actually expose IBM i data and code to AI tools?
Model Context Protocol (MCP) servers came up repeatedly in the session as the practical mechanism for connecting IBM i data and code to AI agents, whether that’s a GPT-based agent, Copilot, Claude, or something else.
Once IBM i data is replicated into a governed data warehouse with metadata attached, an MCP server reads that structure and exposes it to chat agents directly, which is what lets a business move from producing static reports to letting people ask direct questions of governed, authoritative data.
The productised MCP server described in the session is read-only by design.
Write-back is possible, but it requires more than the standard product: it needs its own governance layer, and in most cases it has to pass through the existing application logic that already validates the data, rather than writing to Db2 for i directly.
That matters on IBM i specifically, because validation rules are often built into the RPG, COBOL or Java program layer rather than the database itself, so bypassing that layer on a write-back path would bypass the checks that keep the data reliable in the first place.
MCP capability also now extends to code and job data.
X-Analysis, Fresche’s application analysis and documentation tool for IBM i, has added MCP capability, exposing program structure, logic and business rules so they’re consumable in tools like VS Code.
Presto, Fresche’s browser-based UI modernisation tool, can add a chat or reporting layer on top of green-screen applications using the same approach.
At Proximity, we deliver both X-Analysis and Presto to IBM i clients across many managed services and modernisation projects, so this shift toward AI-connected tooling builds directly on capability many teams already have in place.
How do you protect personal and sensitive data once IBM i data is exposed to AI??
Governance was treated as a first-order requirement, not an afterthought.
This includes personal and special category data under UK GDPR, as well as PII and PHI in jurisdictions where those terms apply too.
Two controls came up specifically: logging every tool call made against an MCP server, so there’s a full record of who accessed what data, and assigning clear ownership of governance, whether that’s a dedicated chief data officer in a larger organisation or a shared finance function in a smaller one.
The alternative, without a governed access layer, is what the session called out directly: users export data to Excel and share or analyse it outside any oversight, or turn to publicly hosted AI tools because no approved option exists, feeding company data into models with no control over where it ends up.
US healthcare organisations subject to HIPAA were highlighted as being particularly exposed to this risk.. Building the governed access layer first, before AI tools are rolled out more broadly, is what prevents that shadow IT problem rather than reacting to it after the fact.
What the result looks like in practice
Put together, this doesn’t require replacing the production IBM i applications.
RPG and COBOL programs, and the validation logic inside them, stay exactly as they are.
Replication overhead sits in line with disaster recovery tooling most businesses are already running. And the outcome for the business is a move away from static, IT-produced reports toward direct question-and-answer access to trusted data, delivered through a governed MCP layer with a full audit trail behind it.
That’s a meaningfully different starting point from “replace the platform” or “just plug an AI model into the database,” and it’s why the session is worth watching in full if you’re weighing up where to start.
Watch the full session:
If your team is looking at what it would take to make your own IBM i data AI-ready, without a migration project and without exposing personal or sensitive data in the process, get in touch with Proximity.
We support, develop, modernise and integrate IBM i applications for UK businesses through a team of 40+ IBM i application specialists.
As a Fresche Solutions partner, we can also talk you through where X-Analysis, Presto or a governed data layer would fit your IBM i estate specifically.
Learn more about Fresche Solutions
