No. You do not have to replace your core system to get real value from artificial intelligence. But you cannot ignore it either. The core sets a ceiling on what AI can do, and where that ceiling sits decides which work pays back and which stalls after the pilot.
The useful question is not replace or keep. It is which of your processes are already above the ceiling and which are under it.
Why you keep getting two opposite answers
Search this question and you will find two confident answers that contradict each other.
One says the core must be modernized first, because AI can only move as fast as the system underneath it. The other says a full replacement is unnecessary and you should connect AI to one high value process while modernizing at a sensible pace.
Both arguments are reasonable. Both are also published by companies that sell software. The first tends to come from firms that sell core systems. The second tends to come from firms that sell the platform you would connect instead. Neither is lying. Each is answering from where it stands.
This page is published by a book publisher. We do not sell you a system either way, which is the only reason we can say the thing that is actually true and slightly annoying: it depends, and it depends on something you can measure.
What the core actually limits
A policy administration system was built to do one thing extremely well: hold the record, and never lose it. Everything about it, the batch cycles, the fixed fields, the release calendar, comes from that job.
None of that stops AI from reading a document, drafting a summary, or checking a submission. What it stops is AI from acting on the result without a person in between.
So the limit is not intelligence. The limit is write access and speed of change. An AI can decide something in two seconds. If the system that has to record the decision only opens for changes once a fortnight, the two seconds bought you nothing.
Three tests that settle it for any given process
Take one process. Not your whole business. Ask these three questions about it and you will know whether you need to touch the core.
1. Does the answer have to be written back?
If the output is a recommendation a person reads, the core is not in the way. If the output must become a policy change, a payment, or a status, it has to be written back, and now the core is in the way.
2. Does the data the model needs already leave the core?
If it is already in a warehouse, a document store, or an email inbox, you can start today. If the only copy lives inside the core in a shape nothing else reads, your first job is a data one, not an AI one.
3. How often does this process need to change?
Some processes are stable for years. Those sit happily on an old core. Anything you expect to tune monthly is a poor fit for a system that releases twice a year, and no amount of AI changes that.
A process that answers no, yes, rarely is work you can do now. A process that answers yes, no, often is the one telling you the core is the real project.
The expensive mistake
The costly error is not picking the wrong answer. It is picking either answer for the whole business at once.
Replacing the core because you want AI turns a two year programme into the thing that has to finish before anything else starts. Refusing to touch the core forever means every AI result stops at a human who retypes it, and the saving you modelled never arrives.
A business of any size has both kinds of process running side by side. The work is to sort them, not to choose a side.
What to do this quarter
List your processes. Run the three tests on each one. You will get two piles.
Start the first pile now, because nothing is stopping it. For the second pile, you now have something you did not have before: a specific, costed list of what the core is blocking, in your own numbers. That is a far better case for a core decision than a vendor deck, and it is the same list that tells you what order to do the rest in.