At a minimum, I recommend running these tests whenever the Supplier side of the contract changes. If we can directly detect that situation, then we know to run the contract tests at that time. In this case, we try to detect whether the Supplier implementation has changed, so that we can judge that change as a mistake or intentional, then we can coordinate with the Consumers to publish the change and control the resulting disruption.
In large organizations we often don't achieve that level of precision. Instead, we run those tests periodically and regularly hoping that they help us detect breaking changes so that we can recover from the disruption. In this case, I fall back to the typical advice: as disruption increases, we run these tests more often.
In many organizations, the Consumers start bearing the responsibility for running these tests, in part because a cultural rule has developed that allows Suppliers to change their contracts unilaterally and without advance notice. In this case, I advise Consumers to run these tests whenever they fear that a breaking change might have occurred, whenever they notice that something might have changed, or periodically and regularly as a defence mechanism. With patience and good communication, Consumers can gradually share this responsibility with the Suppliers. This becomes an ongoing negotiation and, in many large organizations, that never ends.
When the Supplier lives outside the organization, the Consumers typically run these tests as classical acceptance tests: I won't accept your upgrade until your new version passes these tests. Of course, that works better when the Consumer decides whether to upgrade; if the Supplier merely deploys new versions at their discretion, then the Consumer needs to treat the relationship more like the ones I described above.
When a programmer tells me that this seems like too much work, I ask them "Compared to what?" :)