You're less likely to miss requirements if you work backwards from outcomes such as 'I want to be able to find & monitor resources that store sensitive data', versus jumping straight to a solution like 'I want a tag for resources that store sensitive data'. When you get your team together, start by thinking about the outcomes you'd like, as opposed to the tags you want. Think about who has sufficient technical experience and could provide valuable input from areas such as: Realistically, in most organizations, you'll have stakeholders with requirements from a cross-section of teams.
Nail this stage and everything after becomes easier.
Who should I contact about a problem with this resource?.Which team owns the most high-risk resources?.How much does it cost to support this project?.Quickly answer common questions from other people/teams in your organization, e.g.If you're subject to audits, no matter internal or external, tag the relevant resources to save swathes of time processing auditor requests (not to mention managing the day-to-day operational risk of those resources).Tag business-critical resources to improve operational focus and clarity, and adhere to SLAs.
AWS tags are labels that can be applied (optionally) to resources, including EC2 instances, S3 buckets, AMIs, and lots more.