Privacy by Design
Building data protection into the architecture from the first design decision rather than adding controls to a system already built.
The phrase is a legal obligation in several jurisdictions rather than a philosophy, and it is enforceable — which is worth knowing when it is dismissed as aspirational.
Its practical content for an architect is a set of design questions asked before the schema exists. What personal data does this genuinely need, and what is being collected because it might be useful later — the second category being the one that creates liability without value. Where does it live, and how many copies will exist once analytics, search, caching and backups have their versions. How long is it kept and what mechanism deletes it. Who can see it, and is the default access closed. Can the purpose be achieved with pseudonymised or aggregated data instead.
The reason it must be early is that retrofitting is disproportionately expensive. Adding deletion to a system that never modelled it means finding personal data across a dozen stores that were designed to copy freely. Adding purpose limitation to a warehouse where everything was joined into one table means unpicking it. Adding residency to a system replicated globally by default can mean rebuilding the data layer.
The architect's leverage is highest in the first fortnight and falls sharply thereafter, which is exactly when privacy is usually considered a compliance step scheduled before launch.