AI application portfolio inventory
You can't govern what you can't see. How to build the single inventory of every place AI runs in your organisation — including shadow and embedded AI — before the DTA register obligation lands.
Reviewed 25 June 2026 · practitioner analysis, not legal advice
The problem this quarter
You cannot govern what you cannot see. By December 2026, that stops being a maxim and becomes an obligation.
The DTA’s Policy for the responsible use of AI in government (v2.0, effective 15 December 2025) lands its 12-month tranche around December 2026. From that point, non-corporate Commonwealth agencies must maintain a register of in-scope AI use cases, designate an accountable owner for each, and complete an impact assessment before deployment. Legacy use cases get assessed by 30 April 2027. You cannot register, assign, or assess a use case you have not found. The register is downstream of an inventory you have to build first.
Agencies have a hard date. Everyone else has the same problem without the deadline. The Guidance for AI Adoption (AI6, October 2025) and the ten guardrails of the VAISS both assume you know where AI is running before you can place a control over it. ISO/IEC 42001 — the certifiable AI management system standard — opens with scoping the AI in your organisation. And if any of your AI touches the EU market, the AI Act requires a maintained record of high-risk systems regardless of where you sit.
The inventory is the first artefact of an AI architecture practice because every other artefact references a row in it. Risk classification needs something to classify. Impact assessments need a list of what to assess. An accountable owner needs a use case to be accountable for. Skip the inventory and you are governing a guess.
The method
An AI portfolio inventory is a discovery exercise, not a survey. Asking teams “are you using AI?” returns a clean, confident, wrong answer. AI hides in five places, and each needs its own discovery technique.
Where AI hides
| Hiding place | What it looks like | How to find it |
|---|---|---|
| Procured SaaS with AI switched on | Features toggled on inside tools you already pay for — CRM summarisation, ticket triage, “smart” search | Audit your SaaS register and licence agreements; check admin consoles for AI features defaulting to on |
| Copilots and assistants | Microsoft 365 Copilot, IDE assistants, embedded chat helpers | Licence and tenant admin reports; egress logs to assistant endpoints |
| Embedded models in products | A model baked into a vendor product or a workflow component, not surfaced as “AI” | Vendor due-diligence questionnaires; contract and DPIA records; ask procurement, not users |
| Bespoke builds | Models your own teams trained, fine-tuned, or wired into pipelines | Code repositories, MLOps tooling, cloud AI service bills |
| Shadow AI | Staff pasting work into public chatbots on personal logins | Network egress / CASB logs to public AI domains; anonymous amnesty survey; expense claims |
Shadow AI is the one that breaks inventories. It is invisible to procurement and licensing because there is no procurement and no licence. Run a non-punitive amnesty — “tell us what you use, no consequences” — alongside egress analysis. If you lead with discipline, the inventory goes underground and you are back to governing a guess.
What to capture per use case
Capture enough to triage, not so much that the inventory never gets finished. The minimum viable schema:
- Owner — a named accountable person, not a team
- Business purpose — what decision or task it serves
- Data touched — especially personal, sensitive, or classified information
- Model / provider — and whether it is hosted, API, or on-prem
- Assistive vs agentic — does it suggest to a human, or act on its own?
- Lifecycle stage — pilot, production, decommissioning, shadow
- Risk tier — your classification output
- EU exposure — does it touch the EU market or EU data subjects?
The assistive-vs-agentic field matters more than it looks. An assistant that drafts an email a human sends is a different risk animal to an agent that books, pays, or decides without a human in the loop. As agentic patterns spread, this column is where your future governance pain concentrates.
How to triage once you have the list
A raw list of 40 use cases is not a plan. Triage in three passes:
- Sanctioned vs shadow — legitimise or shut down the unsanctioned, fast.
- Risk tier — run each row through a classifier. Most will be low. A handful will not be, and those set your workload.
- Owner gaps — any row without a named owner is a finding in its own right. Unowned AI is the definition of ungoverned AI.
A worked example
A mid-sized NSW agency — roughly 1,800 staff, service-delivery heavy — runs a two-week discovery sweep ahead of the DTA register obligation. The CISO expects “a handful of pilots.” The sweep finds about 40 use cases.
What surfaces:
- Microsoft 365 Copilot, licensed to roughly 300 staff and embedded across Word, Outlook and Teams. Nobody had logged it as an “AI use case” because it arrived as a feature of a tool they already had. It touches case notes containing personal information.
- A widespread shadow chatbot habit — egress logs show consistent traffic to public AI endpoints from across the contact centre and policy teams. Staff are pasting in draft correspondence and, in a few cases, fragments of client records. No malice, no sanction, no visibility.
- Three bespoke models in a data team’s pipelines, including a demand-forecasting model nobody outside that team knew existed.
- Two procured SaaS tools with AI summarisation features switched on by default after a vendor update.
- The rest: an even spread of low-risk assistive features across HR, finance and comms tooling.
The Copilot deployment becomes the agency’s first impact assessment, because it is high-volume and touches personal information. The shadow-chatbot finding triggers a sanctioned-tooling decision — provide an enterprise instance with data controls, rather than pretend a ban will hold. The demand-forecasting model gets an accountable owner for the first time in its life. The low-risk spread gets logged and parked.
Two weeks of work turned “a handful of pilots” into a register-ready list — and a frank picture of where the real exposure sat, which was nowhere the CISO had guessed.
The template
Copy this schema. One row per use case. Start with the columns that drive triage and add detail later.
| Column | Description |
|---|---|
| Use case ID | Stable unique identifier — the key every other artefact references |
| Name | Plain-language label a non-technical executive understands |
| Owner | Named accountable individual (role + person), not a team |
| Business purpose | The decision or task it serves |
| Discovery source | How it was found (procurement, egress logs, amnesty, repo scan) — tells you what else to look for |
| Model / provider | Specific model and vendor; hosted / API / on-prem |
| Data touched | Data classes, flagging personal, sensitive, health or classified |
| Assistive vs agentic | Suggests to a human, or acts autonomously |
| Human oversight | Where the human checkpoint sits, if any |
| Lifecycle stage | Shadow / pilot / production / decommissioning |
| Risk tier | Output of your risk classifier |
| EU exposure | Touches the EU market or EU data subjects (Y/N) |
| Impact assessment | Not started / in progress / complete + link |
| Register status | In-scope for the DTA register (Y/N) and logged (Y/N) |
Two disciplines keep this alive. First, the Use case ID is sacred — never reuse or renumber it, because impact assessments, classifications and register entries all point back to it. Second, treat the inventory as a living asset with a refresh cadence, not a one-off audit. New SaaS features ship monthly; staff adopt new tools weekly. An inventory taken once is wrong within a quarter.
What changes when the regulation moves
The inventory is the artefact that absorbs regulatory change, because almost every obligation resolves to “show me your list.”
- DTA register (~Dec 2026). The 12-month tranche turns your inventory directly into the mandated register of in-scope AI use cases, with an accountable owner per row and a completed impact assessment before deployment. Legacy use cases must be assessed by 30 April 2027 — your “shadow” and “production-but-old” rows are exactly that legacy backlog. The inventory is what makes the deadline survivable.
- The impact-assessment obligation. The register is not a spreadsheet you file and forget. Each in-scope row triggers an impact assessment before deployment. The inventory’s risk tier tells you which rows to assess first; the data-touched and assistive-vs-agentic fields feed the assessment itself.
- Privacy Act automated decision-making (commences 10 Dec 2026). The new APP 1 transparency obligation applies to automated decisions affecting individuals. Your assistive-vs-agentic and human-oversight columns are how you find the rows in scope. OAIC guidance is expected around September 2026 — until then, flag the candidates rather than wait.
- EU AI Act exposure. If any row touches the EU market, high-risk systems require a maintained record. Note that the politically agreed Digital Omnibus (6 May 2026, not yet formally adopted) is expected to push Annex III high-risk obligations to 2 December 2027 — more runway, not a reprieve. Your EU-exposure column is what tells you whether you need to care at all.
The pattern holds across all of them: the regulation specifies obligations, but every obligation presumes you already know what you have. Build the inventory once, maintain it forever, and each regulatory move becomes a column you populate rather than a programme you launch.
Where this connects
- Classify each inventory row with the risk classifier.
- Benchmark your Application Architecture axis with the maturity assessment.
- Trace the obligations behind each date in the regulatory canon.
- See where this artefact sits in the model.