Data Is the Architecture

Every serious AI architecture interview eventually arrives at the same truth: the model is a commodity; your data is the moat. Any competitor can call the same Azure OpenAI endpoint you can. What they cannot call is your case history, your policy manuals, your ticket archive, your domain expertise encoded in twenty years of documents. The architect's real job is rarely "pick a model" — it is designing how the organisation's data becomes usable, trustworthy fuel for AI. Get the data architecture right and models are swappable; get it wrong and no model can save you.

Where enterprise data actually lives

An enterprise's knowledge is scattered across systems that were never designed to feed an AI:

• Operational databases — SQL Server, Postgres: structured records, the freshest facts.
• Content management systems — SharePoint, intranets, a CMS: policies, procedures, pages.
• Document stores — file shares and blob storage full of Word, PDF, and scanned paper.
• Logs and telemetry — what the systems actually did, as opposed to what the docs claim.
• Tickets and case systems — support history, resolutions, the tacit knowledge of the org.

Each source has a different shape, freshness, access model, and owner. A data architecture for AI is largely the discipline of turning that sprawl into a coherent, governed corpus.

Ownership and data contracts

Every source needs a named data owner — the person or team accountable for its accuracy and allowed to say yes to new uses. Between the owner and your AI pipeline sits a data contract: an explicit agreement on schema, meaning, quality expectations, update cadence, and notification when the shape changes. Without a contract, the upstream team renames a column or restructures the CMS and your ingestion silently breaks — or worse, silently ingests garbage. In the public sector this is doubly important: the owning agency, not the AI team, carries the legal accountability for the data's use.

The architect's first questions

Before any RAG or fine-tuning discussion, an architect interrogates the data. Four questions do most of the work:

1. Where does it live? System, format, and how you would extract it repeatedly, not once.
2. Who owns it? Who signs off on AI use, and who do you call when it changes?
3. How fresh is it? Real-time, nightly, or a folder last touched in 2019 — staleness determines whether answers can be trusted.
4. Can we use it? Licensing, privacy law, classification level, and citizen consent. "It's on the file share" is not authorisation.

If an exam question asks where an AI initiative should start, the answer is almost never "choose the model." It is: inventory the sources, secure the owners, and write the contracts. Data is the architecture — the rest of this module builds on that foundation.