How to know which key was used for an AES encryption? I am starting a project where several categories of sensitive data have to be accessed within a table. Based on his role, a user can see clear text columns (not encrypted), accessible columns (decrypted for his role), and can't see the content of other columns (encrypted).
This implements segregation of duty (for example) :

Database administrator can only see clear text columns
Person A can only see person's details to validate data
Person B can only see revenue details to build statistics

Role management rules dictate which role uses which key, and keys are highly protected. But after a few years of people moving and roles adapting, how can I make sure the system still knows which key was used when?
I can imagine two solutions:

Build a solid log of keys usage
The key signature hash is present in the cryptogram

Even though I don't think one can guess the key from the hash, I'm afraid this would introduce a weakness...
How would you proceed?
I agree with your solution. Log that stores info about who and when is active with a particular role. You could use ID or name, but password hash seems ideal, to see when user changed the password, to not to show him his old data that he will try to decode with a new password. SHA3 is considered secure. If user makes a password and then sends SHA3(password) - there is no way for you to get the password out without brute force.
Could use SHA3(company name + password) to avoid easy guessing of known password hashes from the table. If someone gets the table, makes pre-calculated table with values like sha(12345) and scans the whole database, he is likely to find some matches.
Could also use SHA3(username + password), to avoid search for dublicates if the whole database is leaked or to show that even you cant search for dublicates. In addition to the previous bonus.
Could go further and use SHA3(your own secret + SHA3(username + password) to protect from all sides, leaked database and your own actions against the users. That is, user sends SHA3(username+password), but on your server you make SHA3(your secret+what user has sent you), and only that becomes public and is written in the database. One more way to make it better is a long generation time on the user side, like 100 or 100k steps of SHA3. But this is questionable for weak devices. Reason for this is mainly to prevent you to quickly crack users passwords with a dictionary, since you know how their response is calculated and what is there. One step further is to use algorithms that are hard to speed up on asics or GPU. https://en.m.wikipedia.org/wiki/Argon2
TLDR: use SHA3(your secret + 1000 chained steps of SHA3(username+password)), OR SHA3(your secret + argon2(SHA3(username + password)). Check if mobile device can handle it under 1 second.