AI Governance Starts With Data, but It Does Not End There

AI governance starts with data because every AI system depends on information it can retrieve, infer from or act upon. If the organisation cannot explain which data an AI use case can access, who owns it, how reliable it is and what restrictions apply, the use case is not ready for production.

That is the starting point, not the whole job. Data controls cannot decide whether an AI use case is appropriate, whether its output is safe enough for the decision, or who must intervene when it fails. AI governance also covers models, vendors, prompts, human oversight, monitoring, incidents and business accountability.

Data governance and AI governance are related, not interchangeable

Data governance answers questions such as:

• What data do we hold, and where is it?
• Who owns the meaning, quality and permitted use of it?
• Which people, applications and agents may access it?
• How is sensitive data classified and protected?
• Can we trace data from source to report, model or AI response?

AI governance adds another set:

• Which AI systems and use cases are in operation?
• What decision or action can each system influence?
• Which model, provider, retrieval source and tool does it use?
• What harms could arise for customers, staff or the organisation?
• What testing and human review are proportionate to that risk?
• How will performance, misuse and incidents be detected?
• Who can pause or retire the system?

This wider scope is consistent with the NIST AI Risk Management Framework. Its core functions are Govern, Map, Measure and Manage. Data quality and management sit inside that system, alongside accountability, context, risk measurement and ongoing treatment. ISO/IEC 42001 similarly describes an organisational management system for developing, providing or using AI responsibly. Neither framework reduces AI governance to a data catalogue.

Why poor data controls become AI risks

The mechanism is practical.

Access becomes harder to see

A report normally exposes a defined set of fields and measures. An AI assistant may search documents, query a semantic model, combine sources and call actions on a user's behalf. The access path is less obvious to the user, even when the underlying permissions are enforced.

Before release, test the effective access of the user, service identity and agent. Do not assume that a well-written system prompt is an access control.

Weak definitions become confident answers

If revenue, active customer or service performance means different things across systems, an AI layer does not settle the dispute. It may select one definition without making the conflict visible.

The fix is not better prompt wording. Name an owner, agree the business definition, document the approved source and test the answer against known cases.

Unknown lineage weakens investigation

When an answer is wrong, the team needs to trace the source records, transformations, retrieval process, model version and response. Data lineage provides part of that evidence. AI logging and model or application telemetry provide the rest.

Sensitive data can travel into new contexts

An AI use case can make existing information easier to retrieve, summarise and redistribute. That changes practical exposure even when the source system has not changed. The Office of the Australian Information Commissioner's guidance on commercially available AI products is a useful reminder that Australian Privacy Act obligations continue to apply when organisations adopt AI products.

The minimum data foundation for a production AI use case

Do not wait for an enterprise-wide governance programme. Govern the data path for the first use case.

Microsoft Purview can support parts of this foundation. Microsoft describes Data Map and Unified Catalog as its main data-governance solutions for capturing metadata, curating data, managing data quality and health, and supporting discovery. Microsoft also states that the catalogue contains metadata, not the underlying data, and that catalogue roles do not themselves grant access to the underlying data.

That distinction matters. A catalogue can improve visibility and accountability. It does not replace source permissions, application controls or an approved operating model.

Add the controls that data governance cannot provide

Once the data path is controlled, add the AI-specific layer.

Keep an AI system register

Record each model and AI-enabled application, including embedded vendor features. Capture the owner, purpose, users, model or service, data sources, tools or actions, deployment status, vendor terms and risk rating. Shadow AI cannot be governed from a project register that only includes centrally funded builds.

Classify the use case by consequence

A tool that drafts an internal meeting summary does not need the same approval as a system that recommends credit, employment, health or customer-treatment decisions. Assess impact, reversibility, affected people, scale and the ability to detect error.

The classification should change the controls. Higher-consequence use cases need stronger testing, approval, human review, logging and fallback arrangements.

Define meaningful human oversight

"Human in the loop" is not enough. State what the reviewer can see, what they must check, how much time they have, and whether they can reject or reverse the action. A person clicking approve without source evidence or authority is ceremony, not control.

Test the system, not just the model

Test representative and difficult cases across retrieval, prompts, model behaviour, tool permissions and user experience. Include incorrect sources, ambiguous requests, prompt injection, excessive permissions, personal information and failure of connected services. Record acceptance thresholds before testing.

Monitor and prepare to stop

Track use, failure modes, complaints, overrides, access anomalies and material changes in models or sources. Give one owner authority to restrict, roll back or deactivate the system. NIST's Generative AI Profile provides additional risk-management considerations for generative AI.

A practical sequence for a mid-market organisation

1. Choose one bounded use case. Define the user, task, decision and acceptable consequence of error.
2. Map the complete data path. Include source systems, transformations, retrieval indexes, prompts, outputs and logs.
3. Name the owners. Separate business accountability, data stewardship, technical operation, security and risk review.
4. Fix the material data gaps. Do not attempt to cleanse every dataset. Fix what this use case depends on.
5. Apply identity and access controls. Test permitted and denied scenarios for people, applications and agents.
6. Assess AI-specific risks. Use a recognised framework, adapted to the organisation's actual context and obligations.
7. Pilot with acceptance criteria. Limit users and actions, collect evidence and define the conditions for wider release.
8. Operate the control loop. Review incidents, quality, use and change. Retire use cases that no longer justify their risk or cost.

If the required data is spread across systems, Microsoft Fabric can provide a shared foundation for engineering, analytics and AI workloads. Microsoft Purview can support discovery, classification and control. Neither platform assigns business accountability for you. Start with a practical data governance framework, not a licence purchase.

Decide what to do next

Proceed to a controlled pilot when the use case, data path, owner, access model, test plan and stop conditions are clear.

Pause for readiness work when the business purpose is vague, source data is disputed, access cannot be tested, or nobody can accept the operational risk. A Data & AI Readiness Assessment should resolve those decisions and produce a costed next step, not an open-ended AI strategy.

Book a free 30-minute Data & AI consultation if you need to determine whether the first AI priority is ready for a defined implementation sprint or needs focused readiness work first.