After having worked in a few different regulated contexts, I find it difficult to believe that you can't automate at least portions of the work needed to satisfy your compliance requirements. In my experiences, the claim that you can't is based on reading too much into the regulations and standards and relying on common misinterpretations rather than actual definitions or intents.
That said, depending on what happens as part of a release process, perhaps an annual cadence is appropriate with respect to the cost of the release process and how often your customers and users are able to accept a new version of the system.
My suggestion is to create a demonstration or sandbox environment that is updated much more frequently than yearly. It should be updated to track against proposed changes such that the version of all components on it when the release process starts is the same set of versions that are going through the release process. Then, use this environment in two ways. You can invite customers to use it for non-production data and to ensure that integrations and processes won't be affected by upcoming changes. Your sales, marketing, and support teams can also use it to make sure that their material is up-to-date and they understand what they are selling and supporting well before it goes live. Since these people also know the users, they can offer feedback on how customers and users may respond to changes.
The frequency of updates may still differ from your Sprint cadence but should be related. Your Sprint cadence should be designed to align your development teams with the business and reduce risk. The same rules of Scrum would apply - each Sprint would have a fully working and integrated system and the Product Owner would make the decision to release or not. In this case, release would be to the sandbox environment.
