At first, by employing tested-and-true implementation techniques, such as mature authentication/authorization frameworks and separating personal data from non-sensitive data in a manner that allows for more rigid security control, at all levels - datastore, caching, application in-memory-data, API methods and network.
Later, by requiring careful audit from experienced members of our project (in terms of information security), and actually enforcing the rigid security control mentioned above.
That is yet to be defined (I think)…
That too, at least speaking in precise terms - but, preliminarly, of course as few people as necessary: Maybe one sysadmin, one DB administrator… and one or two trusted developers, although these shouldn’t actually need to have real PII (as dummy or anonymized data should probably serve well for all purposes I can think of right now), and if they do, it should be on a case-by-case basis.
In terms of the software, whether moderators or site/instance admins will have access to these via the platform is something that hasn’t been discussed yet AFAIK (or has it?).
If it depends on me, I’d say no. Not until there’s a demonstrated need for some specific PII access anyway, at which point it could be implemented if the merits are deemed valid.