There is an interesting change happening in the conversation around Artificial Intelligence. For the last few years, the question has mostly been: “What can AI do?”
Now enterprises are beginning to ask a different question: “Where is the AI running, and what exactly are we giving it access to?”
That is a particularly important question for the mainframe.
At the end of September, IBM announced that IBM Bob was becoming available for self-hosted deployment, including its IBM Bob Premium Package for Z.
At first sight, this may look like another product announcement. I think it represents something considerably more important. It is another indication that AI sovereignty is becoming an enterprise requirement. And mainframe organisations should be paying attention.
Your Source Code Is Data
When we discuss AI security, we tend to focus on customer information, financial records, personal data and other obviously sensitive information. But what about source code?
A large mainframe application may contain decades of accumulated business knowledge. COBOL and PL/I programs don’t simply contain code. They contain:
- Business rules.
- Pricing calculations.
- Payment processes.
- Risk models.
- Customer processes.
- Interfaces.
- Database structures.
- Security controls.
And sometimes the only accurate documentation of how a critical business process actually works. In other words, source code can be some of the most valuable intellectual property an organisation owns.
Now consider what happens when we introduce an AI coding assistant.
To explain the code, the AI needs access to it. To understand dependencies, it needs context. To assist with modernisation, it may need information from multiple programs, copybooks, JCL and other application artefacts.
Suddenly the security question isn’t simply: “Can this AI understand COBOL?”
It becomes: “What are we giving this AI access to, where is that information going, and who ultimately controls it?”
That is a much more interesting question.
The Cloud Isn’t Always the Answer
Cloud-hosted AI services have obvious advantages. They are easy to consume. They provide access to extremely capable models. They can be updated rapidly. And organisations don’t need to operate the underlying infrastructure. For many workloads, that model makes perfect sense. But not necessarily for everything.
Banks, insurers, governments and other highly regulated organisations may have very different requirements when dealing with mission-critical applications.
Source code may be commercially sensitive. Application information may reveal internal architecture and business processes. Development artefacts may contain sensitive information if controls are poor. Regulatory or organisational policies may restrict where information can be processed. Some environments may even be deliberately isolated from external networks. This creates an interesting problem.
We want AI to understand our most important applications. But those may be precisely the applications we are least comfortable exposing to externally hosted AI services.
Bringing AI Inside the Boundary
This is what makes IBM’s latest announcement interesting.
IBM Bob can now be deployed on a Red Hat OpenShift cluster operated by the organisation itself, either on-premises or within its own cloud environment.
But there is an important distinction.
Self-hosting the AI application doesn’t necessarily mean self-hosting the AI model.
Organisations can use Bob with external frontier models through their own cloud-model services. In that configuration, the Bob backend, identity services, audit logs and other components remain within the organisation’s environment, but requests sent to the model can include code context.
Alternatively, organisations can run supported open-weight models on their own GPU infrastructure.
For environments without outbound connectivity, that creates the possibility of keeping both Bob and model inference within infrastructure controlled by the organisation.
That distinction matters. Because AI sovereignty isn’t simply about where an application is installed. It is about understanding where your information goes.
AI Needs Mainframe Context
There is another problem with applying general-purpose AI to mainframe applications: context.
Ask a sufficiently capable Large Language Model to explain a piece of COBOL and it will probably produce something useful. But understanding syntax isn’t the same as understanding an application.
A production mainframe application may consist of thousands of programs with dependencies across COBOL, PL/I, Assembler, JCL, Db2, CICS, IMS, MQ and many other technologies. Understanding one program in isolation may tell you very little. You need to understand what calls it. What it calls. Which data it accesses. Which transactions use it. Which business rules it implements. And what might break if you change it.
This is an area IBM is attempting to address with IBM Bob Premium Package for Z.
Rather than relying solely on an AI model to interpret source code, Bob for Z combines AI with IBM Z-specific context, structured application information, static code analysis and deterministic application analysis.
Capabilities such as Z Understand can analyse relationships beyond the individual source files available in a developer’s workspace, while zContext supplies relevant IBM Z knowledge to the AI interaction.
IBM has also started combining static analysis with runtime profiling information to help developers identify code paths where optimisation may have the greatest effect.
This is important because mainframe modernisation has never really been just a code conversion problem. It is an understanding problem.
There Is Still a Catch
Running AI inside your own environment doesn’t automatically make it secure. That would be a dangerous assumption.
An AI agent with access to sensitive source code is still potentially a highly privileged entity.
And as these tools become capable of doing more than simply answering questions, the security implications become considerably more interesting:
- What can the agent access?
- What tools can it use?
- Under whose authority?
- Are its actions logged?
- Can they be audited?
- Can it access production information?
- Can it execute commands?
- Can it modify source code?
- And where does human approval sit in that process?
These are variations of security questions mainframe professionals have been dealing with for decades:
- Authentication.
- Authorisation.
- Least privilege.
- Separation of duties.
- Auditability.
- Change control.
The technology may be new. The security principles aren’t.
And This Is Where the Mainframe Gets Interesting
For years, centralised computing was sometimes portrayed as old-fashioned.
The future was supposed to be completely distributed. Applications everywhere. Data everywhere. Processing everywhere.
Now AI is forcing organisations to think seriously about where their most valuable information is stored, where processing takes place and who controls the infrastructure.
Suddenly centralisation doesn’t sound quite so old-fashioned. Neither does keeping sensitive data close to the applications that use it. Neither does strict access control. Neither does comprehensive auditing. Neither does knowing exactly where your workload is running.
These have been fundamental mainframe principles for decades.
Modernisation Without Losing Control
I have written before that mainframe modernisation should not automatically mean moving applications away from the mainframe.
Modernisation can mean improving how we develop, operate, integrate and secure the applications we already have.
AI creates another opportunity to do exactly that:
- It can help organisations understand decades-old applications.
- It can help explain unfamiliar code.
- It can identify dependencies.
- It can assist developers who don’t have decades of mainframe experience.
- It can help preserve knowledge as experienced specialists retire.
- And it can potentially accelerate modernisation.
But none of those benefits justify losing control of the very information we are trying to protect. The objective shouldn’t be: Use AI everywhere. It should be: Use AI where it creates value, under conditions we understand and control.
Perhaps We Had It Right All Along
The next phase of enterprise AI won’t simply be about having the most powerful model. It will also be about trust:
- Where does the model run?
- Where does the data go?
- Who can access it?
- What can the AI do?
- Can its actions be audited?
- And can the organisation remain in control?
For mainframe environments, these aren’t new concerns. They are simply established security principles being applied to a new technology. Perhaps that is one of the more interesting ironies of the AI revolution.
After years of being told that computing needed to become increasingly distributed, organisations are rediscovering the value of keeping their most important data, applications and processing within environments they actually control.
The technology has changed. The principle hasn’t. Sometimes keeping control is the modern thing to do.
Be the first to comment