Large organizations with high design maturity often employ dedicated information architects. Everywhere else, which is most organizations, IA responsibility falls to whoever has the right mix of skills: UX designers, content strategists, technical writers, product managers. What matters is not the job title but the presence of core IA skills: systems thinking, UX research literacy, empathy for users, the ability to organize information logically, and strong language skills.
The IA process itself typically moves through four broad phases: Discovery, where you research users and business context; Strategy, where you define the structural approach; Design, where you build and test the actual architecture; and Implementation, where the structure gets built and maintained. These phases overlap and loop back on each other far more than the clean sequence suggests.
In most real organizations, nobody has "Information Architect" printed on their business card. The work still has to happen, it just falls to whoever has the clearest view of both the users and the content.
Sam is the closest fit to lead. The core IA skills that matter here, conducting user research, translating findings into structure, and thinking about how people will navigate a hierarchy, line up most directly with Sam's UX design background, even without formal IA training. The source material is explicit on this point: what matters is the presence of core IA skills, not the job title.
This doesn't mean Sam works alone. Priya must be consulted because the navigation structure has to reflect business priorities and the product roadmap, an IA that makes perfect sense to users but ignores where the business is headed will need to be redone in six months. Dmitri must be consulted because the categories and structure need to be technically feasible against the actual data model, a beautiful IA that can't be built efficiently against the underlying system creates friction downstream. Aisha is also a strong candidate to consult: she hears the actual words customers use when they're confused, which is directly relevant to labeling decisions.The deeper lesson here connects to what you learned in the previous chunk on information ecosystems: no single person holds the full picture. Business priorities, technical constraints, user language, and user behavior all live with different people. IA leadership means synthesizing those inputs, not possessing all of them personally.