In the standard model of hash functions there isn't a requirement that hash outputs not have properties that leak information about the input.
In the random oracle model of hash functions there isn't a relationship between input and output other than the input/output mapping you get from querying the oracle. The model says that for each input the corresponding output is assigned a value chosen randomly from a uniform distribution of all possible output values.
If a hash function behaves like a random oracle then the only way to learn about an input with just the output known to you is to try hashing inputs and look for matching results. (This is how password cracking works against defenders who use salts properly.)
How secure it would be to publish such a hash output depends on how unpredictable the input is. For low entropy (highly predictable) inputs, the number of hashes you need to compute in this guess-and-check method is small (or likely to be small). For high entropy inputs the number of evaluations is large.
If your input can be one of $2^{128}$ possible values and each possible value is equally probable, then the expected (or maximum) number of hashes that need to be tested is about $2^{127}$ (or $2^{128}$).
Your AES key is supposed to be unpredictable and come from a uniform distribution of all $2^{128}$ possible keys (or more for larger key sizes). Therefore if you publish only the hash of an AES key, people won't be able to learn anything about the key without on the order of $2^{127}$ brute-force-effort. The same amount of work it would take to guess an AES key by brute force attack.
People treat cryptographic hashes (like the SHA and Blake2 algorithms) like a random oracle in practice. (Information can still be leaked through side-channels of implementations, of course.) So publishing the SHA-2 hash of a secret key doesn't compromise security on it's own. Not anymore than publishing the cryptographic hash of any kind of secret with at least 128-bit entropy.
HOWEVER that doesn't mean your specific protocol or application won't use the hash of a secret key securely. As @RichieFrame said some other part of some software could be using the hash of the key differently, so it's risky. And as @MaartenBodewes says the key ID mechanism could be a security risk itself.
You also must not use a non-cryptographic hash.
I suggest you use a separate randomly generated key-ID instead of something derived from the key, if possible, to avoid potential errors.