assess-ai-privacy-cybersecurity-use-case-l0cka · v0.1.0 · 2026-10-05 · sha256 f260be958377e503
assess-ai-privacy-cybersecurity-use-case-l0cka v0.1.0A
Immutable. This exact content never changes and is served at /api/v1/blob/f260be958377e503.
---
name: assess-ai-privacy-cybersecurity-use-case-l0cka
title: Assess AI Privacy and Cybersecurity Use Case
description: Assess whether a proposed or existing AI-system use case is suitable from an Australian privacy, cybersecurity and related governance perspective; identify data flows, affected people, legal thresholds, harms, threats, vendor dependencies and controls; perform change-safe Australian Privacy Principles verification; verify relevant Commonwealth and NSW legislation with the corresponding legislation skills; and prepare a reasoned suitability recommendation for lawyer and accountable-owner review. Use for AI intake, procurement, pilots, deployment changes, privacy impact assessments, generative-AI use cases and automated or AI-assisted decisions. Do not use for case law, foreign law, technical penetration testing, final legal opinions, autonomous approval, a complete review of discrimination, consumer, employment, intellectual-property or sector-specific law, or the AI-governance obligations map and board oversight that the australian-ai-governance plugin owns.
author: l0cka
author_url: https://github.com/l0cka/legal-skills/tree/main/plugins/australian-privacy-cybersecurity/skills/assess-ai-privacy-cybersecurity-use-case
license: MIT
version: 0.1.0
execution_mode: open
jurisdiction: au
practice: data-protection
language: en
sources:
- title: Ai Use Case Method
path: references/ai-use-case-method.md
---
# Assess AI Privacy and Cybersecurity Use Case
Assess a defined AI-system use case, not an AI product in the abstract. Produce
a provisional recommendation supported by verified law, evidence and controls.
Read [references/ai-use-case-method.md](references/ai-use-case-method.md) before
starting. It defines the intake schema, risk domains, suitability outcomes,
control tests and authority boundaries.
## Workflow
1. Define the use case and decision.
- Record the intended purpose, accountable owner, users, affected people,
deployment context, jurisdiction, sector, benefit, decision supported or
made, consequence of error, level of automation and requested decision.
- Identify the exact system, model, version, hosting arrangement, provider,
integrations and proposed change. Do not treat vendor marketing as proof
of system behaviour or controls.
- Use de-identified inputs and minimum necessary extracts. Do not request
credentials, model secrets, live malicious content, unnecessary personal
information or complete client files.
2. Map data and system behaviour.
- Trace collection or generation, prompts and inputs, retrieval sources,
training or fine-tuning, inference, outputs, logs, human review, onward
disclosure, storage, retention, deletion, monitoring and incident paths.
- Classify personal, sensitive, health, confidential, privileged, security-
classified and synthetic data separately. Record uncertainty about
identifiability and re-identification.
- Separate supplied facts, vendor claims, tested evidence, assumptions and
unknowns. Never invent a control or infer that a setting is enabled.
3. Test law and governance scope.
- Invoke `$route-australian-privacy-jurisdiction` for public-sector,
government-contractor, health, surveillance, workplace and State or
Territory automated-decision overlays.
- Identify candidate privacy and cyber legislation using the linked
reference. Verify Commonwealth propositions with
`$check-commonwealth-legislation` and NSW propositions with
`$check-nsw-legislation`, including point-in-time and known-future-change
qualifications.
- If deployment, review or retention extends across a Commonwealth
legislative change, invoke `$trace-commonwealth-legislative-change` and
distinguish present requirements, future requirements and transition
actions.
- If personal information or APP-entity coverage is possible, invoke
`$check-australian-privacy-principles` using the legal as-at date and a
decision horizon covering the pilot, deployment, retention and next review
dates that are actually known.
- Invoke `$assess-statutory-privacy-tort` independently of APP coverage for
surveillance, recording, scraping, profiling, inference, deepfakes,
publication or intimate, location, health or financial information.
- Invoke `$assess-automated-decision-transparency` whenever a program makes
or performs a material step related to a decision. Include the 10 December
2026 Commonwealth transition and WA IPP 10 where relevant.
- Invoke `$map-australian-cyber-incident-obligations` when the proposed
system, smart product or response plan could engage sector incident,
outage, control-weakness or cyber-extortion obligations.
- Do not issue `SUITABLE`, `SUITABLE WITH CONTROLS` or `PILOT ONLY` while an
APP layer requires legal-content or application-law review, or while the
result is `APP FRAMEWORK NOT VERIFIED – DO NOT RELY`. Use `INSUFFICIENT
INFORMATION` or `NOT SUITABLE ON CURRENT INFORMATION`, as the facts
warrant, until a lawyer refreshes the APP analysis.
- For another State or Territory, inspect its official legislation
publisher. Use `PRIMARY TEXT CHECK REQUIRED` or `NOT VERIFIED` when an
applicable version cannot be established.
- Label OAIC, ACSC, National AI Centre, standards and organisational policies
as guidance, standards or internal controls, not legislation.
- State that case law was not considered. Flag discrimination, consumer,
employment, intellectual-property, administrative, records, professional
and sector-specific law for separate review where material.
4. Assess risks and controls.
- Test necessity and proportionality, purpose compatibility, notice and
transparency, lawful authority, data quality, security, access, vendor and
subprocessors, overseas handling, retention, individual rights, human
oversight, contestability, monitoring, incident response and exit.
- Test AI-specific failure modes: unreliable output, automation bias,
prompt injection, data or model leakage, insecure tool use, excessive
agency, poisoned retrieval or training data, model or supply-chain change,
weak identity/access control and inadequate auditability.
- Link each risk to a fact, affected person, plausible harm, evidence,
existing control, residual gap, owner and acceptance criterion. Do not use
a numerical score unless the organisation supplied an approved method.
5. Recommend and gate.
- Apply the suitability outcomes exactly as defined in the reference. A
legal or factual unknown cannot be cured by optimistic assumptions.
- Specify conditions precedent, pilot limits, prohibited data or actions,
required testing, monitoring, review date, stop triggers and approval
owner.
- Do not approve, procure, deploy, connect, upload data to, or change the AI
system. The lawyer and accountable owner make the decision.
## Result contract
Lead with one provisional outcome followed by `— HUMAN APPROVAL REQUIRED`:
- `SUITABLE`
- `SUITABLE WITH CONTROLS`
- `PILOT ONLY`
- `NOT SUITABLE ON CURRENT INFORMATION`
- `INSUFFICIENT INFORMATION`
Then provide:
```text
Use case and decision requested: <bounded description>
Jurisdiction and sector: <identified and unresolved>
As at: <YYYY-MM-DD, Australia/Sydney>
System and version: <verified identifiers or unknown>
Materials reviewed: <de-identified list>
Benefit and necessity: <supported benefit, alternatives and proportionality>
Facts, vendor claims, assumptions and unknowns: <separate sections>
Data-flow summary: <source to input to processing to output to storage/disclosure/deletion>
Applicability matrix: <candidate regime, threshold, verified text and status>
APP framework status: <exact result, inventories and decision-horizon coverage>
Jurisdiction and health overlays: <routes and verified boundaries>
Statutory privacy tort: <separate Schedule 2 screen or reason not triggered>
Automated-decision transparency: <current and future requirements>
Cyber and sector obligations: <deployment and incident-response routes>
Risk-control matrix:
Priority | Risk event | Affected people/asset | Material fact | Legal/governance basis |
Existing control and evidence | Residual gap | Required control | Owner | Acceptance test
Suitability reasons: <decisive reasons for the outcome>
Conditions before use: <testable conditions precedent>
Pilot boundary: <users, data, duration, functions and prohibited uses>
Monitoring, review and stop triggers: <measures, owner and date>
Adjacent legal referrals: <issues outside this skill's complete coverage>
Case law: Outside scope and not considered
Limitations and approval: <unresolved matters and named decision owner>
```
Use `VERIFIED`, `VERIFIED WITH QUALIFICATIONS`, `NOT VERIFIED`, `PRIMARY TEXT
CHECK REQUIRED`, or `OUTSIDE SCOPE` for legislation status. Link each legal
proposition to official material actually inspected. Do not represent this
assessment as certification, assurance or a substitute for professional
judgment.
<!-- generated:plugin-dependencies -->
## Other plugins
This skill names skills from other Legal Skills plugins. Install a required
plugin alongside this one; install a hand-off plugin when the matter needs
that depth.
- `australian-legal-research` (required): `check-commonwealth-legislation`,
`check-nsw-legislation`, `trace-commonwealth-legislative-change`. Verifies
the Commonwealth, state and territory legislation the privacy, breach and
cyber workflows rely on.
If a named skill is not available in this session, say so and name the plugin
to install. Treat the step it would have performed as not done: record the
affected proposition as not verified, or the hand-off as not made. Never
perform that step from memory or substitute a different skill.
<!-- end:plugin-dependencies -->