Use of personal information to train
Avoid where possible, otherwise de-identify and document the lawful basis.
Why. Reduces privacy and reputational risk.
Trade-off. De-identification can reduce utility.
AI governance and assurance · Data governance · privacy · lineage
Responsible AI data governance: classification, consent, lineage and retention for training, retrieval and prompts
How data is governed across the AI lifecycle: sources are classified and assessed for lawful use, consent and purpose are enforced, lineage tracks data into training sets, indexes and prompts, and retention and deletion apply to every derived copy.
A reference architecture from EITSAA, not a named client system. Service limits, prices and product features change, so confirm current details before you commit to a design.
- Privacy Act and Australian Privacy Principles
- Voluntary AI Safety Standard (data governance)
- ISO/IEC 42001
- NIST AI RMF
- SA ISMF
- ACSC Essential Eight
Architecture
- Databases and data
- Security and identity
- Monitoring, audit and analytics
- AI and ML
- Request or data flow
- Asynchronous or optional
- Boundary: region, account, network or trust zone
Request and data flow
Source systems are scanned and classified. Sensitivity labels and personal information are discovered and recorded.
A privacy impact assessment checks purpose, lawful basis, data minimisation, residency and the risk of the intended AI use.
Outcomes become rules: which data classes may be used for which purposes, with which consent, by which systems, expressed as policy that systems can enforce.
Approved data is registered in a lineage catalogue so the path from source to training set, index and prompt is traceable.
The preparation zone minimises, de-identifies or tokenises data and applies quality checks before any AI use.
Training and fine-tuning sets are built only from approved, versioned data, with documentation of provenance and known gaps.
Retrieval indexes inherit permissions from the source so users see only what they are entitled to, and are rebuilt when sources change.
Prompts, outputs and traces are masked and kept for short, defined periods.
Retention and deletion jobs apply to source data and all derived copies, including indexes, caches, training sets and logs.
Components and why they were chosen
| Component | What it does | Why this choice |
|---|---|---|
| Classification and DLP (Microsoft Purview, Amazon Macie, Google Cloud DLP) | Discover and label sensitive data. | Know what you hold. |
| Policy engine for purpose and consent | Machine-enforceable rules. | Governance that systems apply. |
| Lineage and catalogue (Purview, DataZone, OpenLineage) | Trace data through AI uses. | Supports deletion, audit and impact analysis. |
| Preparation pipelines | Minimise and de-identify. | Reduces privacy risk. |
| Access-controlled retrieval | Entitlement-aware search. | Prevents oversharing. |
| Retention automation | Scheduled expiry and deletion. | Meets obligations and reduces exposure. |
Design decisions and trade-offs
Retrieval over fine-tuning
Prefer retrieval with access control for organisational knowledge.
Why. Permissions and deletion are enforceable.
Trade-off. Retrieval quality needs engineering.
Provider data terms
Require no training on your data and in-region processing.
Why. Protects confidentiality and residency.
Trade-off. Narrows provider choice.
Consent model
Record purpose and consent with data and enforce at use.
Why. Respects individual expectations and law.
Trade-off. Needs metadata discipline.
Deletion of derived data
Track and delete derived copies, and retrain or rebuild where required.
Why. Meets deletion obligations.
Trade-off. Rebuild costs.
Well-architected pillars
Security
Encryption, key management, least privilege and separation of preparation and production environments.
Reliability
Versioned datasets and reproducible preparation pipelines.
Performance
Incremental indexing and permission sync.
Cost optimisation
Index and store only what is needed and expire the rest.
Operational excellence
Data owners for each source, regular access reviews and privacy review gates for new uses.
Sustainability
Minimise copies and delete expired derived data.
Network, identity and data
Networking
Data stays in the permitted Australian region with private endpoints between sources, preparation and AI services. Egress to external model providers is blocked unless the policy allows the data class.
Identity and least privilege
Source permissions are the authority. Retrieval evaluates the caller's entitlements at query time. Data stewards approve new AI uses of their data. Access to training sets is restricted and logged.
Data and encryption
Classify, minimise, document provenance and apply retention to every copy. Treat embeddings as derived personal information where they can be linked to people. Align with APP 3, 6, 8, 10, 11 and 12 and with records obligations.
Security and compliance mapping
| Control | How this design addresses it |
|---|---|
| Data governance and provenance | Classification and lineage support Voluntary AI Safety Standard guardrail 3. |
| Privacy | Impact assessments, minimisation and purpose limits support the Privacy Act and APPs. |
| Data residency | Region controls and provider terms support agency and APP 8 requirements. |
| Restrict access | Entitlement-aware retrieval and steward approval. Essential Eight. |
| Records and retention | Automated expiry supports records obligations. |
Mappings show how the design supports each control. They are not certifications, and EITSAA does not claim IRAP assessment or compliance for any reference architecture.
Failure modes, targets and scaling
- Target RTOPer supporting service. Catalogue and policy services under one day.
- Target RPONear zero for the catalogue and rules. Datasets reproducible from versions.
- Scaling and limitsSized by data volume and index refresh rate.
| Failure mode | Mitigation |
|---|---|
| Sensitive data enters an index it should not | Classification gates before indexing and entitlement checks at query time. |
| Derived copies survive deletion | Lineage-driven deletion across indexes, caches and sets. |
| Provider retains or trains on data | Contract terms, configuration checks and monitoring. |
| Consent or purpose is exceeded | Policy as code at use time and audit. |
| Training data is unrepresentative | Documentation of gaps and fairness testing. |
Observability and runbooks
- Coverage of classified sources.
- Access denials and exceptions.
- Deletion job success and age of oldest derived copy.
- Data used by purpose and system.
Cost drivers and levers
Scanning, catalogue tooling, storage of derived copies and reviewer time.
- Scan incrementally.
- Expire derived data.
- Index only approved content.
- Reuse prepared datasets.
Implementation and fit
Phased approach
- Classify the sources that AI will use first.
- Add privacy assessment gates and purpose rules.
- Add lineage, preparation pipelines and entitlement-aware retrieval.
- Automate retention and deletion across derived copies.
Anti-patterns to avoid
- Indexing a whole file share.
- Training on production data without assessment.
- Logging full prompts forever.
- Ignoring embeddings in deletion.
- Relying on provider promises with no configuration check.
When to use it
- Organisations using personal or sensitive data with AI.
- Agencies and regulated entities with residency and privacy duties.
When not to
- Public data only with no personal information.
More in ai governance and assurance
AI governance · LLMOps
AI governance and LLMOps platform: model registry, prompt versioning, evaluations, guardrails and responsible AI approvals
The operating system for AI in an agency or enterprise: versioned models and prompts, automated evaluations and red-teaming as release gates, responsible AI approval with a risk register, and production monitoring of quality, drift, safety and cost.
Operating model · control framework
AI governance operating model and control framework: register, risk tiers, approvals, platform guardrails and assurance
How an organisation governs every kind of AI: leadership sets direction, an AI register and risk tiers decide how much review each system needs, an approval workflow gates release, platform guardrails enforce policy and assurance closes the loop with evidence.
LLM guardrails · policy engine
LLM guardrails architecture: input and output guard layers, policy engine, PII redaction, grounding checks and audit
A layered guardrail pattern around an LLM application: authenticate and screen the request, redact personal data, retrieve only what the user may see, call the model, then validate grounding and policy on the way out, with every step logged for audit.
Related insights
Discuss this architecture
Tell us your systems, constraints and timeline. We reply within one business day, and the initial conversation is free.