If the ML component does not serve any operational purpose for the business, maybe there's minimal impact if it breaks or is unavailable, so it isn't worth having anyone on call, and support can be done within business hours.
If the ML component is heavily integrated into some operational production service that has a large business impact if it fails, someone is surely going to be scheduled to carry a pager to promptly restore service. That may or may not be an ML engineer.
Hypothetical example #1: the business has an automated sign up process for new customers. ML is integrated to try to record-match new customer details against details of existing customers (or whatever), to decide if this is actually a returning customer or a genuinely new one, which influences how user accounts are created. The ML component requests data from 6 other internal systems to define features in order to make decisions during the sign up process. One of the teams responsible for one of those internal systems releases a new version of their thing that causes it to start responding with data that breaks the ML component. The ML component can't handle this, becomes unavailable, and this breaks the business' ability to sign up new customers.
Hypothetical example #2: the business is a utility that sends out monthly invoices to customers, the product manager of customer invoicing (or whoever) decides to add a new table to their monthly invoice that contains both statistics about each customer's consumption but also ML-based forecasts of usage over the next quarter, as well as some ML-generated tips to reduce/increase consumption. This code gets run in batch mode every month as customer invoices are being generated. Suppose there's some issue that causes this customer-usage-forecast to fail, and due to how this is integrated, it fails in a way that prevents all customer invoices from being sent. Unsure if a team will be scheduled to provide out of hours support for a batch invoicing system, but this will generate a lot of attention once people see it has stopped working and is going to impact the business' cash flow.
In both of the above examples, there isn't necessarily anything ML specific -- it's roughly indistinguishable from being a backend engineer supporting some production system that's performing (or, er, complicating) some internal business process and is integrated with a bunch of other weird and wonderful internal or external production systems.