What might be the intuition for this scheme to be AEAD and what is the problem with this? There is a plaintext message $M$, and a key $K \:\stackrel{{\scriptscriptstyle \hspace{0.2em}\$}} {\leftarrow}\ \{0,1\}^{128}$ which we will use for AES, we can extract a ciphertext $C \gets \mathrm{CBC}[\mathrm{AES}_K](0^n,M)$, i.e., CBC
mode encryption under IV $0^n$ of the message. 

The master keys $L1,L2$ are shared between the sender and receiver. 
Sender creates a header (associated data) $H$ that contains various
things including a ciphertext $W \gets \mathrm{AES}_{L1}(K)$, the
enciphering of the per-message key $K$ under master key $L1$. Sender also computes a tag $T \gets F_{L2}(H)$ for some function family $F$ that
we assume is a good PRF. Then the sender transmits $(H,T,C)$ to the
receiver.
A critical part of any AEAD scheme is that it ensures the authenticity of the header data and the ciphertext. Your scheme only protects the header data, leaving the ciphertext vulnerable. Protecting the key is not enough. 

CBC mode is affected by certain bit-flipping attacks, that allows an attacker to change part of the message. This results in one block being completely garbled, and the next block having the exact bits flipped that were flipped in the attack. The rest of the decrypted message is untouched. If you don't authenticate the ciphertext, you will be vulnerable to this attack. This attack also extends to certain padding oracle attacks. 

As for the IV and key: using a static IV with a unique per-message key may be secure, but it's a non-standard way of implementing CBC. Best case, it doesn't gain you anything over the standard way of implementing CBC. In the spirit of "Don't roll your own", it would be best to use CBC the standard way, with a random, unique and unpredictable IV.