Anything that you can break down into discrete rules is on the chopping block, especially if it is repetitious.
The safe places to be are areas where people are willing to pay a significant premium for human interaction (and there are fewer of those than you think), jobs that primarily deal in on-offs and unique circumstances (where the effort to define the rules / scenario each time is greater than the task itself), and where decisions are subjective and/or the factors are difficult to quantify.
UBI is going to be needed, as there will be more people than jobs.
The technology to do a lot of this exists today, the biggest obstacle is cost of implementation. People with the intelligence and mindset to design, configure, and maintain complex systems and automation are expensive today - increase the number of systems in use and the demand for those people goes even higher. The senior managers who decided to do the project don't understand how their company actually works and set it up for failure before it even starts.
These projects typically go like this:
System X can automate process Y, eliminating Z jobs.
Senior leadership gets all excited, signs a contract with an implementation partner and hires a few IT people to be the long term team.
Things go to shit right away. Implementation team immediately finds that the business process in place now is different from the workflow of System X, and poorly documented.
Project gets behind as the implementation team scrambles to interview dozens of mid level managers to find out what the actual process is, and document it. This is a nightmare as critical information is only in people's brains, and no one can remember why they do it that way.
System X can't be reconfigured to do the unique process the company actually follows. They have to choose between completely changing their internal process (which is painful and expensive) or only partially implementing the system. Almost every project I've been on chooses the latter when they hit this point.
The implementation team has kept the in-house IT folks as sidelined as possible - to hide their own struggles and also to limit knowledge transfer. The less the in-house IT team can do as maintenance, the more follow-up contracts they get.
End result is a system that can only do half of what it was supposed to, only eliminated half as many jobs as was promised, and is more expensive to maintain than budgeted.
= new reply since forum marked as read