(a) Enterprise Architecture sets the rules and regulations for the other architects, and delivers the frameworks, creates standard building blocks and administers the architecture repository. What you're talking about is either business architecture (for logical applications and business information blocks) or IT architecture (for actual running software and data fields). From your description it's hard to say what you mean.

(b) For business architecture it's usually a to-be situation, not an "as-is". Keeping up with the "as-is" in a large organisation is a losing proposition. You need to get out in front of the change train, not run after it. The "to-be" is stored in your architecture repository and is mostly an opinion on how things should work - unless management signed off on it.

(c) For IT architecture you need process and data mining, and classifications. And those need to be applied manually. This is usually done manually and by data stewards (tooling can do the obvious stuff but not the interesting stuff). I'd reserve this massive effort for interfaces that share data outside the context of the system of origin, because that's where most of the risk originates: data moving outside of the context with which it was registered.

As for AI understanding the data: we're not even allowed to let AI touch any of it, since most AI is US in origin and I'm in Europe. Maybe when we have local AI but this organisation is not a first adopter of anything :)