The DataRequester is actually the DataController

[GeertThijs]

Description
In both use case diagrams the Agents asking/getting Consent are (relation isProvidedToAgent) presented as DataRequesters are actually DataControllers. Both KBC and UZ Gent are the ones that "determine processing & purpose" of the data. Only when the Consent is a GivenConsent the processing can start, but at the moment of the request KBC and UZ already have determined that they want to do something with the data, providing they actually get the Consent.
Also it is possible that no data is requested at all, for example that by using their website you agree terms & conditions without any data exchange. So, not everyone asking for Consent can be considered a DataRequester.
Another issue here is that the term DataRequester is not used at all in the GDPR. There are other parties between the Controller and the Processor which are called ThirdParties (of which Recipient is a special case), but that's it. It would not be wise to introduce terms that are not mentioned in the GDPR, one could atmost consider to subclass DataController with DataRequester.

Solution
Not use the term DataRequester but stay with the legal GDPR term DataController.

[michaelgeamanu]

After cross-checking with GDPR specialists and showing the changes in the 4rd thematic workshop, this issue has been closed with the solution proposed by Geert.