Keeping requirements up to date during project

The test plans, which are based on the requirements and contain all the test cases are good for tracking the requirements. Furthermore, the test cases can be linked to the PBIs on the Product Backlog. The list of passing test cases shows the coverage of the requirements. 

To be more specific, I mean the case that some User Story is implemented, and later the functionality is changed. Now, according to standards, the original User Story should be modified (or replaced) to reflect the modification.

This certainly does not hold when team is using yellow notes that are scrapped after Done :) Unfortunately this is not possible in all projects.

I may be wrong but I don't believe there are any standards that the original product backlog has to be modified.  Going back to the days of waterfall and requirements documents, the original documents were never modified.  They were changed via addendums, much like laws are done in the United States.  You always preserve the original and modify by attaching documentation that explains the modifications. 

In the instances you (or should is say ChatGPT) suggested you would still need a record of the original requirements. So, instead of modifying the original text, you would modify by attaching new text that explains the modifications.  If you are using some electronic system to manage your backlog, you would just link the modification to the original.  If you are using yellow notes, that are thrown away, then you have no record of the original and you are already out of compliance with those standards so your problem is much bigger.

There are several standards that require keeping requirements (like User Stories) up to date and traceable

There's your problem. A user story isn't a requirement. It's a placeholder for a conversation about a potential requirement. That's not the same thing.

Tests which assure compliance with an evolved requirement are, indeed, more likely to be worth tracing. Business tests trace to unit tests for example. If the business requirements change, we have a direct follow through and the ability to leverage automation support. This is far more specific than a shoebox of sticky notes.

Ian is 100% correct. Although user stories may look like requirements, especially when they are fully refined and ready for development, they aren't. When a user story is added to a backlog, it's a placeholder for a conversation (or, likely, multiple conversations) with key stakeholders. When it's fully refined, it describes a change in state of the system to enable a user to perform a valuable activity.

Tests are what you want to look at for tracing.

Standards such as IEC 62304 and ISO 26262 don't have (as far as I'm aware) any product requirements in them, but do specify process requirements and the types of information to capture and provide to stakeholders, at least as far as I'm aware. I'm only tangentially familiar with these standards, but I'm familiar with similar standards from other industries. Sources of requirements that you would want to trace to would be things like the US FDA's 21 CFR Part 11 or the EU's Annex 11 for electronic records and computerized systems in the pharmaceutical space, SOX requirements in the finance space, and similar regulations. Although these requirements still have procedural requirements, depending on the nature of the system, you can highlight test cases that demonstrate that your system conforms to these requirements in the same manner that you can trace a test case that demonstrates conformance to user requirements.

Specifically in the software space, it would be worthwhile to look into specification by example, which is sometimes called "executable requirements" or "executable specification". By taking this collaborative, iterative, and incremental approach to capturing requirements as automated tests, you not only have traceability to requirements, but you can actually use your requirements specification to perform verification of the system.