KyperX AI / Tools / Shadow AI inventory
Free tool · Govern and procure AI
Build an AI register, and see what needs a decision.
A register you maintain, not a scan you run.
Nothing here discovers software, and pretending to would be dishonest. What it does is turn the exercise every organisation eventually runs — asking teams what they are using — into a reusable AI systems register, with flags drawn only from what you disclose and an explicit list of what nobody could answer.
- For
- Whoever has been asked what AI the organisation is using
- Time
- About 5 minutes per system
- You need
- What each tool is, who owns it, what data reaches it, and who holds the account
- You get
- An AI systems register, a summary, flags explained against published conditions, and a list of what nobody could answer
The tool
Build the register.
Add one entry per AI system, including AI features inside software you already licence. Leave a field at Not established when nobody knows; that is the useful answer, and it becomes a line on the verification list.
Nothing here is a compliance, safety or legal verdict, and there is no score. Every flag below is a restatement of something you disclosed, and every flag is explained.
The input controls on this page need JavaScript. Everything else works without it: the worked example below is computed when the page is built, and the method, tables, limits and questions are plain text.
No entries yet. Add one to start the register, or load the example to see what a filled one looks like.
What you enter stays in this browser. Nothing is sent to KyperX, nothing is written to browser storage, and the copy, CSV and print are assembled from what is already on screen. Reloading clears it.
Method and limits
How it works, and what it does not do.
Open what you need. None of it is required to use the tool.
A worked example, computed when this page was built
Five fictional entries, each labelled as fictional. They were constructed to show what the flags do — including one governed entry that triggers none — and are not drawn from any engagement, client or organisation.
| Tool or system | Business purpose | Department | Accountable owner | Status | Account type | Data categories | Integrations | People affected | Consequential decision | Human review | Approval | Training use | Retention | Processing location | Notes |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Example: Northwind Notes (fictional) | Summarising meeting recordings for a project team | Delivery | — | Live | Individual or personal account | Internal, non-personal; Personal information; Customer or client records | Read-only connection to internal systems | 40 | No | No review | Not approved | Not established | Not established | Not established | Fictional entry. Found because a summary was pasted into a customer email thread. |
| Example: Ledgerline Assist (fictional) | Coding supplier invoices and proposing a cost centre | Finance operations | Finance operations manager | Pilot | Organisation or enterprise agreement | Internal, non-personal; Commercially confidential or IP | Reads and writes into internal systems | 12 | Yes, contributes to one | Every output reviewed before use | Approved under a current internal process | Contractually excluded from training | Documented retention period | Known and documented | Fictional entry. Included to show what a governed entry looks like beside an ungoverned one. |
| Example: Rosterly Screen (fictional) | Ranking job applicants before a shortlisting meeting | People | Talent acquisition lead | Live | Team or business plan | Personal information; Sensitive information; Employee records | Read-only connection to internal systems | 1800 | Yes, largely determines one | No review | Approved informally | Content may be used for training | Retained indefinitely | Partly known | Fictional entry. Constructed to trigger several flags at once, not drawn from any engagement. |
| Example: an AI feature inside the CRM (fictional) | Drafting replies to customer enquiries | Customer service | Service operations lead | Live | AI feature inside existing licensed software | Personal information; Customer or client records | Can act in external systems or send to third parties | 9000 | No | Review only when the system flags an exception | Not established | Provider states content is not used for training | Documented retention period | Partly known | Fictional entry. The common case: nobody procured it, it arrived in an existing licence. |
| Example: Quarry Vision trial (fictional) | Counting stock movements from fixed cameras | Operations | Site operations manager | Retired | Self-hosted or in-house | Internal, non-personal | Read-only connection to internal systems | 0 | No | Sampled review | Approved under a current internal process | Contractually excluded from training | Documented retention period | Known and documented | Fictional entry. Retired on paper, and the register still records a live connection. |
Executive summary
- Entries in the register
- 5
- Live
- 3
- Pilot or planned
- 1
- Receiving personal, sensitive, health, customer or employee data
- 3
- Influencing a consequential decision
- 2
- With no human review
- 2
- On an individual, personal or consumer-tier account
- 1
- With no accountable owner recorded
- 1
- Flagged for review before continued use
- 3
- With at least one item to verify
- 3
Review before continued use
- Example: Northwind Notes (fictional) — Regulated or confidential data on a personal or consumer-tier account (F1). You recorded personal, sensitive, health, customer, employee, confidential or credential data reaching a system held on an individual, personal or consumer-tier account. Nobody in the organisation holds the contract that governs it.
- Example: Northwind Notes (fictional) — In use without approval (F4). You recorded the status as live or pilot and the approval state as not approved.
- Example: Northwind Notes (fictional) — Live with no accountable owner (F8). You recorded the status as live and no accountable owner. Nobody is answerable for how it behaves or for deciding to stop it.
- Example: Rosterly Screen (fictional) — Personal or sensitive data where content may be used for training (F2). You recorded personal, sensitive or health data reaching a system, and recorded that content may be used to train the provider's models.
- Example: Rosterly Screen (fictional) — Consequential decision with no human review (F3). You recorded that this system contributes to or largely determines a consequential decision, and that no output is reviewed before use.
- Example: Rosterly Screen (fictional) — Sensitive material with an unestablished processing location (F5). You recorded sensitive, health or credential material reaching this system, and that where it is processed and stored is not established.
- Example: Quarry Vision trial (fictional) — Retired but still recorded as connected (F9). You recorded the status as retired and an active connection to internal or external systems. A retired system with live credentials and connections has not been retired.
Information to verify
- Example: Northwind Notes (fictional) — Accountable owner. Name a role that is accountable for this system's operation and for the decision to keep or stop using it.
- Example: Northwind Notes (fictional) — Use of your content for training. Find the provider's current written position on whether your inputs and outputs are used to train or improve models, and whether it differs by plan.
- Example: Northwind Notes (fictional) — Retention. Establish how long inputs, outputs and logs are kept, by whom, and what deletion is actually available to you.
- Example: Northwind Notes (fictional) — Processing and storage location. Establish where processing, storage, logging, backups and any sub-processors sit, and get it in writing rather than from a marketing page.
- Example: Rosterly Screen (fictional) — Approval state. Establish whether this use has been approved, by whom, and under what process.
- Example: Rosterly Screen (fictional) — Processing and storage location. Establish where processing, storage, logging, backups and any sub-processors sit, and get it in writing rather than from a marketing page.
- Example: an AI feature inside the CRM (fictional) — Approval state. Establish whether this use has been approved, by whom, and under what process.
- Example: an AI feature inside the CRM (fictional) — Processing and storage location. Establish where processing, storage, logging, backups and any sub-processors sit, and get it in writing rather than from a marketing page.
Next steps
- Circulate the register to the teams it names and ask for corrections and additions. A first pass is always incomplete, and the omissions are the point of the exercise.
- Assign an accountable role to every entry that has none, before anything else.
- Close the items in the list above by asking the provider in writing, not by inferring from a product page.
- Decide, for each flagged entry, whether to keep it under stated conditions, move it to a governed alternative, or stop it. Record the decision and who made it.
- Provide a sanctioned alternative for the uses on personal or consumer-tier accounts. Unsanctioned use is usually a symptom of a real need with no approved way to meet it.
- Add a review step to any entry that influences a consequential decision without one, or record why one is not required.
- Set a date to review the register, and a route for staff to add to it between reviews. A register maintained once is a snapshot, not oversight.
How it works, rule by rule
Each flag is a restatement of two or three things you recorded. There is no weighting, no scoring and no judgement about the system itself.
| Id | Flag | The conditions you would have recorded |
|---|---|---|
| F1 | Regulated or confidential data on a personal or consumer-tier account | You recorded personal, sensitive, health, customer, employee, confidential or credential data reaching a system held on an individual, personal or consumer-tier account. Nobody in the organisation holds the contract that governs it. |
| F2 | Personal or sensitive data where content may be used for training | You recorded personal, sensitive or health data reaching a system, and recorded that content may be used to train the provider's models. |
| F3 | Consequential decision with no human review | You recorded that this system contributes to or largely determines a consequential decision, and that no output is reviewed before use. |
| F4 | In use without approval | You recorded the status as live or pilot and the approval state as not approved. |
| F5 | Sensitive material with an unestablished processing location | You recorded sensitive, health or credential material reaching this system, and that where it is processed and stored is not established. |
| F6 | Write or external access with no human review | You recorded that this system writes into internal systems or can act in external systems, and that no output is reviewed before use. |
| F7 | Credentials or security material disclosed to the system | You recorded credentials or security material among the data categories this system receives. That holds whoever operates it, and applies to a self-hosted system as much as a hosted one. |
| F8 | Live with no accountable owner | You recorded the status as live and no accountable owner. Nobody is answerable for how it behaves or for deciding to stop it. |
| F9 | Retired but still recorded as connected | You recorded the status as retired and an active connection to internal or external systems. A retired system with live credentials and connections has not been retired. |
| Id | Item | What to establish |
|---|---|---|
| V1 | Accountable owner | Name a role that is accountable for this system's operation and for the decision to keep or stop using it. |
| V2 | Approval state | Establish whether this use has been approved, by whom, and under what process. |
| V3 | Use of your content for training | Find the provider's current written position on whether your inputs and outputs are used to train or improve models, and whether it differs by plan. |
| V4 | Retention | Establish how long inputs, outputs and logs are kept, by whom, and what deletion is actually available to you. |
| V5 | Processing and storage location | Establish where processing, storage, logging, backups and any sub-processors sit, and get it in writing rather than from a marketing page. |
| V6 | Data categories | Work out what actually reaches this system in practice, including material inside attachments, screenshots and pasted text. |
| V7 | Integrations | Establish what this system can read, what it can write, and what it can trigger outside the organisation. |
| V8 | Whether a consequential decision is involved | Establish whether anything downstream of this output affects a person's money, entitlements, employment, access to a service, rights or safety. |
| V9 | Human review | Establish what is reviewed, by whom, and what happens to an output nobody looks at. |
| V10 | Provider and account type | Establish who holds the contract, on which plan, and what that plan's terms say. |
| V11 | Status | Establish whether this system is planned, in pilot, live or retired. A register with unknown statuses cannot be used for oversight. |
What a flag is, and what it is not
A flag means: on the facts you recorded, this combination is worth a decision before use continues. It does not mean the use is unlawful, unsafe, non-compliant or prohibited, and the absence of a flag does not mean a use is any of the opposite things. Several of the conditions above — regulated data on a personal account, an unreviewed output driving a consequential decision — would be a problem in most organisations. Whether they are a problem in yours is a question for the people accountable for your obligations.
The information to verify list exists because the honest answer to most register questions on a first pass is that nobody knows. An unknown owner, an unestablished approval state, an unestablished training position, an unestablished retention period and an unestablished processing location each produce a specific thing to go and ask, in writing, of the provider or of the team. That list is usually the most valuable output on this page.
The register deliberately captures who holds the account rather than which model runs underneath. An enterprise agreement, a team plan, an individual account and a consumer tier can serve the same model under materially different terms, and the account type is the thing that decides what those terms are.
Every input, and how to use it
The field set follows the shape the National AI Centre's own register template uses — key characteristics, use case, accountable person, governance level — expanded with the data, integration, review and retention facts that make triage possible.
| Input | Unit | What it means |
|---|---|---|
| Tool or system | — | The product, service or internal system. Include AI features inside software you already licence. |
| Business purpose | — | What it is used for, in one line. |
| Department or team | — | |
| Accountable owner | — | A role that is accountable for how this system operates. Leave blank, or write Unknown, if nobody is. |
| Status | — | |
| Provider and account type | — | Who holds the contract matters more than which model it runs. |
| Data categories it receives | — | Select every category that reaches it, including through a document or a screenshot. |
| Integrations | — | |
| People affected | — | How many staff, customers or members of the public are affected by its output. |
| Influences a consequential decision | — | A decision affecting a person's money, entitlements, employment, access to a service, rights or safety. |
| Human review | — | |
| Approval state | — | |
| Use of your content for training | — | |
| Retention | — | |
| Processing and storage location | — | |
| Notes | — |
How to actually collect this
- Do not start with a survey. Start with the three places the answers already exist: the expense and card ledger, the identity provider's list of applications people have signed into, and the licence renewals for software you already buy. Most shadow AI arrives through one of those.
- Then ask teams, without a penalty attached. Unsanctioned use is almost always a real need with no approved way to meet it. A register collected as an enforcement exercise gets a shorter and less accurate answer than one collected as a supply exercise.
- Include AI features inside existing products. The most common entry in a real register is not a tool anybody procured; it is a feature that arrived in a licence the organisation already held.
- Record what actually reaches the system, including inside attachments and screenshots. "We only use it for drafting" and "customer records reach it" are frequently both true.
- Name a role, not a person, as the accountable owner. People move. If no role can be named, that is the finding.
- Set a review date and a route to add to it. A register collected once is a snapshot; oversight needs it maintained.
What this does not do
- It does not discover anything. There is no scan, no network inspection and no integration. Everything in the register is there because a person put it there, and the systems nobody mentions will not appear.
- It issues no compliance, legal, privacy or safety verdict. No flag says a use is unlawful or non-compliant, and no absence of a flag says it is permitted.
- There is no maturity score and no percentile. The summary is a set of counts of the entries you recorded. Any score would require a benchmark population, and inventing one would be worse than having none.
- The flags are only as good as the disclosure. A row recorded as handling no personal data produces no data flag, whether or not that is true.
- It does not replace an impact assessment or a risk assessment. The National AI Centre makes the same point about registers: documentation supports governance activity, it does not substitute for it.
- It is not a record of processing under any privacy law. If you need one of those, it has a prescribed content this does not attempt to meet.
This page is general information and a starting point. It is not legal, privacy, security, safety or regulatory advice, and it does not assess whether any use complies with any obligation. Where an entry involves personal, sensitive or health information, a consequential decision about a person, or a contractual restriction, obtain advice from someone qualified to give it before use continues. The conditions above are published so you can see exactly what produced each flag and disagree with it.
Terms used here
- Shadow AI — AI systems in use without the organisation's knowledge or approval. Usually a symptom of an unmet need rather than of bad faith.
- AI systems register — a list of the AI systems an organisation uses with their key characteristics, use cases, accountable people and governance level. The National AI Centre publishes a template; this tool produces the same kind of artefact with triage attached.
- Accountable owner — the role answerable for how a system operates and for the decision to keep or stop using it.
- Consequential decision — one affecting a person's money, entitlements, employment, access to a service, rights or safety.
- Training use — whether the provider may use your inputs and outputs to train or improve models. Frequently differs between a consumer tier and an enterprise agreement for the same product.
- Processing location — where computation, storage, logging, backups and support access happen. A region commitment often covers only the first of those.
Common questions
What is shadow AI?
AI tools and features being used inside an organisation without its knowledge or approval. It usually arrives three ways: an individual signs up to a consumer tier to get a job done, a team buys a business plan on a card, or an AI feature appears inside software the organisation already licences. The third is the most common and the least noticed.
How do I find out what AI is already being used?
Start with records you already hold rather than a survey: the expense and card ledger, the applications people have signed into through your identity provider, and renewals of software you already buy. Then ask teams directly, with no penalty attached, because unsanctioned use is nearly always an unmet need. This tool is where the answers go once you have them.
What should an AI register contain?
At minimum: the system, its purpose, the accountable role, its status, who holds the account, what data reaches it, what it connects to, whether its output affects a consequential decision, what human review exists, and the approval, training, retention and location position. The National AI Centre's own template covers key characteristics, use cases, accountable people and governance level; the additional fields here are the ones that make triage possible.
Does this scan our systems automatically?
No. It is a register you fill in, and it says so rather than implying discovery. Automated discovery is a separate class of product; a register is the artefact that governance actually runs on, and it is the thing most organisations lack.
Why does the tool not give us a risk score?
Because a score implies a comparison, and the only honest comparison would be against a population we have no data for. Instead the tool names the specific combination that warrants a decision and explains why, which is both more useful and harder to misread.
Is it a problem if staff use a personal AI account for work?
The register flags it where regulated or confidential data is involved, because on those facts nobody in the organisation holds the contract that governs the data. Whether it is a problem for you depends on your obligations and contracts, which this tool does not assess. The durable fix is usually to provide a sanctioned alternative rather than to prohibit the use.
Where does the register go after this?
Export the CSV and keep it wherever your governance records live. The tool holds nothing: it writes nothing to browser storage and reloading the page clears it.
Primary sources
These are the publishers' own current pages. No text from them is reproduced here, and nothing on this page restates their guidance as an obligation that applies to you.
- National AI Centre, AI systems register. Register template published 22 April 2026.
- National AI Centre, Guidance for AI adoption: foundations. Part of the Essential AI practices.
- National AI Centre, Guidance for AI adoption: implementation guidance. Part of the Essential AI practices.
- Office of the Australian Information Commissioner, Guidance on privacy and the use of commercially available AI products. Published 21 October 2024, updated 17 January 2025.
Primary sources last reviewed 27 September 2026. These are the publishers’ own pages; they are quoted nowhere on this site and nothing here restates them as a requirement that applies to you.
- Find out where this is allowed to runSix deployment patterns, screened against your own constraints by rules printed on the page.
- Generate the requirements and questions for an AI purchaseSeparate what a supplier must satisfy from what you would prefer, before anyone writes a response.
- Estimate annual benefit and paybackWork out what one AI use case is worth, keeping hours released and money saved as separate claims.