Skip to content

Library · Data Practice OS

Governance, security and trust

Reference guide · Published · Source reviewed

Governance that depends on people remembering does not survive contact with AI. An agent issues thousands of queries a day. The only governance that keeps up is policy enforced by the platform, driven by metadata, defined in code.

The model in one line

Classify every column → tag it → policies act on tags → identities carry attributes → every access is logged → lineage explains every output.

1. Classification

Use the confidentiality labels your jurisdiction or organisation mandates. Australian government schemes, for example the QGISCF used by one state, use OFFICIAL (low or negligible impact), SENSITIVE (medium) and PROTECTED (high); enterprises often use Public, Internal, Confidential and Restricted. Keep the scheme you have, and map each level to its protection baseline (for example the ISM level). Add data-type tags such as pii:name, pii:dob, pii:licence_no, pii:address and health.

  • Apply tags at bronze, on landing, using automated classification (both platforms classify automatically) and confirmed by the data owner.
  • Tags propagate through lineage to silver and gold. If a downstream column drops a tag, that needs an explicit, reviewed declassification.

2. Access by attribute, not by table

Per-table grants do not scale to hundreds of products and agents. Use Attribute-based access control:

3. Privacy by design

Most agencies and enterprises hold a great deal of Personal information: customers, licence or account holders, addresses, health information. Under the privacy law that applies to you (for example a national or state privacy act and its privacy principles, or the GDPR):

  • Run a privacy impact assessment for any new use of personal information, and for every AI use case touching it.
  • Purpose limitation: tag datasets with permitted purposes, and check them in access policies.
  • Minimisation: gold products expose only the attributes the use case needs. Analytical products use pseudonymised keys by default.
  • Retention: retention and deletion are pipelines too, tested and monitored.

4. AI-specific controls

Control What it means here
Use-case assessment Assess every AI use case against the AI policy that applies to you. Government AI policies typically require a risk assessment (for example the FAIRA required by one state's AI governance policy), often with a lighter form for low-risk use cases, proofs of concept and trials. Enterprises can use ISO/IEC 42001 or the NIST AI RMF. See AI use case intake and risk triage
Runs as the user Agents and assistants query with the end user's identity or a narrowly scoped role, never a shared superuser
Model access through a gateway Approved models only, in-region, with logging and cost limits (AI gateway and model access)
Guardrails PII redaction in prompts and logs where needed, topic limits, output validation
Human in the loop Mandatory for any output that affects a decision about a person (licensing, compliance, enforcement)
Evaluation evidence Accuracy, groundedness and safety measured before release and monitored after (Evaluating AI systems)
Transparency Users know when they are dealing with AI output; answers cite sources

Classification, privacy and AI permission are three separate records

Adopted from the source draft AI-Ready Data and Context Lifecycle (revised 4 Nov 2026). Proposed practice, not an agreed decision. The full method is in AI readiness assessment.

Record the security classification, the privacy tags and the AI permissions separately. They describe different things. A dataset can be OFFICIAL: Sensitive without personal information, or unclassified public information that still contains it. Classification never grants AI use, and neither does public availability.

An AI-permission record holds:

Field What to record
Allowed purposes The named AI uses this data may support
Approved services and environments Which model routes, platforms and environments (for example, internal retrieval in prod only)
Redaction What must be removed or masked before processing
Training restrictions Whether training or fine-tuning is permitted
Approver and basis Who approved it, and on what basis (PIA, FAIRA, contract, licence)
Review date When the permission lapses unless renewed
Status approved, prohibited or not assessed. Not assessed means no

The rules that make the record mean something:

  • Restrictions follow the data into features, chunks, embeddings, indexes, prompts, logs and outputs. A derived asset carries the most restrictive permission of its inputs.
  • Test deletion and revocation through indexes and caches, not just at the source. A deleted record that a vector index still returns has not been deleted.
  • Archived content must not silently re-enter retrieval. Test that archiving removes it from active indexes.
  • An AI use passes the rights and handling Readiness gate only when its permission record is approved for that purpose, service and environment.

5. Audit and lineage

  • Access history and query logs retained to the organisation's records requirements and exported to the SIEM.
  • Column-level Lineage from source to report and AI answer. Use the platforms' native lineage, plus OpenLineage for anything outside them.
  • An AI answer must be traceable to the query or documents it used, which the agent's trace records.

6. Residency and security baseline

Data residency in Australian regions for storage, compute and inference. Private networking. SSO and SCIM. Customer-managed keys where classification requires them. Production changes only through CI. IRAP evidence maintained per platform. See Choosing a platform - Snowflake, Databricks, or both for the non-negotiables. For the order to build these in (identity and classification first, three signed phase gates), see Security foundations, the first 90 days (adopted from a draft, not an agreed decision).

Who decides

Decision Owner
Classification of a dataset Data owner (business), advised by the data steward
Who may access a product, for which purposes Data owner
Whether an AI use case proceeds AI governance forum, per the use-case risk tier
Platform controls and policy code Platform team, reviewed by Cyber Security

See Operating model for the forums and roles.

Lessons from platform options papers

Source: a platform team's draft options papers and platform docs (Oct-Nov 2026). All draft or proposed. None is an agreed decision; treat them as evidence, not standards.

  • Use information-asset roles for data decisions. The platform team uses its government's information-asset roles: the Information asset owner approves classification, access and retention, and the information asset custodian handles quality rules, definitions and access requests. One Accountable role per decision (RACI; see Operating model).
  • Two tags on every raw schema: DATA_CLASSIFICATION (classification level) and CLASSIFICATION_STATUS (ASSUMED until formally CONFIRMED). Masking attaches to column tags (Naming conventions).
  • The source owner decides the masked columns, and the decision is recorded on the source page.
  • A CI check that classification follows the data. Compare each changed model's tags with its upstream tags. A model that selects restricted columns must be in a restricted schema, or the build fails. Snowflake tag propagation (Enterprise Edition) does part of this.
  • A private network does not identify the caller. Interim per-person tokens need hash-only storage, expiry of 30 days or less, no tokens in repos, and revocation at the end of UAT (Agent memory).
  • Read-only audit access. An ACCOUNT_VIEWER_ROLE sees structure, grants and policies but no rows. A time-boxed ACCOUNT_DATA_VIEWER_ROLE reads rows, with masking still applied.

Source links: Data Practice reading list.