From RFC 5246, section 220.127.116.11: AEAD Ciphers:
AEAD ciphers take as input a single key, a nonce, a plaintext, and
"additional data" to be included in the authentication check, as
described in Section 2.1 of [AEAD]. The key is either the
client_write_key or the server_write_key. No MAC key is used.
However in RFC 5246, section 5: HMAC and the Pseudorandom Function:
In addition, a construction is required to do expansion of secrets
into blocks of data for the purposes of key generation or validation.
This pseudorandom function (PRF) takes as input a secret, a seed, and
an identifying label and produces an output of arbitrary length.
In this section, we define one PRF, based on HMAC. This PRF with the
SHA-256 hash function is used for all cipher suites defined in this
document and in TLS documents published prior to this document when
TLS 1.2 is negotiated. New cipher suites MUST explicitly specify a
PRF and, in general, SHOULD use the TLS PRF with SHA-256 or a
stronger standard hash function.
Finally, in the hash function of the HMAC is also used to authenticate the handshake in the Finished message using the master key; see RFC 5246, section 7.4.9: Finished:
Hash denotes a Hash of the handshake messages. For the PRF
defined in Section 5, the Hash MUST be the Hash used as the basis
for the PRF. Any cipher suite which defines a different PRF MUST
also define the Hash to use in the Finished computation.
So it is used for key derivation and authentication and for a final confirmation that the handshake succeeded, not for generating the MAC over the data messages.