Sorry to disappoint you, but your security model doesnt work in reality. Let me explain by using an example workflow of a user editing his profile.
- The user logs in, browses to his profile page and enters his data to be saved.
- When saving, you need your symmetrical key for AES. This can be
either a global password, in use for all private data on your server
or a user-owned password that contains his password at some point (as all other data is publicly available / stored)
2a: Global Password
Using a global password, no matter where you store it, will always be easy to compromise. Lets assume your server requests the global password from a second server (that can be compromised itself too anyways) whenever a user (admin or not) accesses it. This can easily be sniffed as an attacker knows your internal endpoint. If you hardcode it, it can easily be read.
2b: User-owned Password
This has to contain an information so secret no one with access to the server can read it, like the password (as its supposed to be only stored inside a hash). This way the user would be able to read & save his private data but you as an admin, having the same opportunity as an attacker, wouldnt be able to read or edit them.
So what now?
Its as simple as disappointing - an attacker always has the same amount of possibilities as you (the admin) so there is no way to keep the data perfectly save from either one. What should be done instead as a matter of best-practice is the need-to-know concept - only save data you really need for your service to be available at all time like his email, name and birthdate. All other data can be saved and encrypted by a user-owned token and be used at runtime (only!) to decrypt data to offer it to the user like his address for a purchase process. This will reduce your possibilities regarding data analysis by far, but data security and broad analysis never like each other anyways.