“We Have an AI Policy.” Where’s the Inventory?

Picture the next governance meeting.

Someone asks which AI systems the organisation uses. The policy arrives immediately. It has a version number, an approval date and the director’s signature.

The inventory takes longer.

IT sends a list of approved products. Marketing adds the assistant they use through personal accounts. Sales mentions the bot that joins customer calls. HR says the recruitment platform has “some AI features,” but nobody is quite sure which ones are enabled.

Then someone asks what people do with the approved tools.

A second silence.

Everyone thought someone else was keeping track. Nobody necessarily lied. They answered different questions: what was approved, what was purchased, what was remembered.

None of those is quite the same as what is used. And knowing what is used still does not establish whether it is used properly.

Your AI inventory needs to describe the organisation you have, not the organisation your policy assumes you have.

A vendor list is not an AI inventory

A supplier name tells you where to send the invoice. It does not tell you what employees are doing, which information enters the system or whose decisions its output influences.

Consider an assistant used to rewrite public marketing copy. Now consider the same product used to evaluate job applicants. The supplier has not changed. The purpose, information and people affected have.

My recommendation is to keep a system or deployment record, then link materially different use cases beneath it. Create a separate use-case entry when the purpose, data, permissions or consequences change enough to require a different assessment.

You do not need a new row for every prompt. You do need to distinguish “drafts public content” from “supports recruitment decisions.”

One row per supplier hides the differences. One row per prompt creates a clerical punishment.

The inventory is not an improvised governance accessory. NIST’s AI Risk Management Framework Playbook explicitly addresses AI system inventories under GOVERN 1.6, including their scope, recorded attributes and maintenance responsibilities. (NIST AI Resource Center)

The practical question is whether yours can answer a follow-up question.

The AI nobody bought still counts

Start with shadow AI: tools or deployments used for work without adequate organisational visibility or authorisation.

Set the discovery scope beyond purchased, standalone products. Ask about personal accounts, browser extensions, meeting assistants, AI features inside existing software, internally developed models and workflows that call external model APIs.

Ask about suppliers too. Is a service provider using AI to process your information as part of the work you outsourced?

Do not restrict the exercise to generative AI. Include AI-based forecasting, classification, image recognition and recommendation systems where they are used. A chat window is not an entry requirement.

Keep uncertain discoveries visible. “AI functionality to verify” is an acceptable temporary status. Quietly excluding something because nobody understands it is not a discovery method.

Likewise, record retired or blocked uses as retired or blocked. Do not erase their existence simply because they no longer fit the approved picture.

Finding those systems is necessary. It is not the whole job.

The tool is approved. The use is not.

Now take the personal accounts out of the story.

Imagine everyone uses the approved enterprise platform. Procurement checked the contract. Security reviewed the deployment. The privacy team assessed the proposed processing. Access is managed. The system has an owner.

Then someone uses it for something none of those reviews covered.

That is shady AI: an approved tool used in an ungoverned or inappropriate way.

I use the distinction here to separate two problems worth investigating: the tools you have not adequately accounted for, and the uses that escape governance inside your approved environment. These are working labels, not a judgement about employee intent.

Consider three fictional examples.

An assistant is cleared for drafting general internal communications. A manager uploads identifiable employee appraisal notes and asks it to recommend who should be promoted. The product is approved. That purpose and those inputs were not part of the approval.

A meeting assistant is authorised for ordinary project meetings. Someone brings it into a confidential employee grievance discussion, despite an explicit exclusion. Same supplier, same account, different boundary.

Or a customer-support assistant is approved to draft replies, provided an agent verifies them before sending. The team still uses it for customer support. Nobody adds a connector or changes the model. They simply start sending the drafts without the required checks.

Shady AI is not only a new use case nobody assessed. It is also an approved use case with its safeguards quietly removed.

NIST’s Playbook explicitly addresses system misuse and the need to define the application’s scope and human responsibilities. Checking a product name against an approved list does not resolve those questions. (NIST AI Resource Center)

Approval needs a boundary

“Approved” needs a second sentence.

Approved for which tasks? With which information? For which users and recipients? With what authority to act? Subject to which checks?

Without those boundaries, what exactly are employees being asked to comply with?

Investigate whether the conditions were communicated, whether the workflow makes them practical and whether anybody checks that they are followed. Do not assume every deviation is malicious. Do not assume an absence of malicious intent makes the deviation harmless either.

The approved-tools list tells you what people may open. It does not tell you what they may do once it is open.

Start with the work. Then check the logs.

“Do you use AI?” is not the question I would start with.

I would ask:

“Show me how you now draft, summarise, translate, code, classify or make recommendations. What helps you do that work?”

Then ask what gets uploaded, pasted, connected or generated along the way.

Run those conversations with the people doing the work, not only department heads. Ask about experiments and free accounts as well as official deployments. Use sanitised demonstrations; discovery does not require copying customer records into your notes.

For approved tools, add another question:

“What happens to the output, and which checks happen before someone acts on it?”

That is where the shady AI investigation begins. A product can be present in every purchasing record and still be used outside its authorised boundaries.

Next, reconcile the answers with evidence.

Review purchasing, expenses, contracts and supplier questionnaires. Within your authorised visibility, examine application inventories, identity integrations, SaaS administration settings, extensions, model endpoints and internal development records.

Investigate discrepancies. A declared tool without a corresponding purchase is not automatically an incorrect answer. An integration nobody mentioned needs an owner. An enabled feature needs a conversation about whether and how it is used.

A connection to a service does not, by itself, explain the business purpose or establish what information was submitted. Record what you checked, when, what it revealed and what remains uncertain.

Explain the exercise to employees. Encourage disclosure without promising blanket immunity for misuse. Agree a proportionate monitoring approach with the relevant privacy and legal teams, including necessary employee consultation.

Limit collection, control access and define retention. GDPR’s data-minimisation principle applies to personal data collected during discovery too. (EUR-Lex)

Do not solve shadow AI by creating shadow surveillance.

Build a register that survives a follow-up question

Here is the working structure I would use. Treat it as an operational starting point, not a claim that every framework prescribes these exact columns.

Keep intended use, authorised use and observed practice distinguishable. Otherwise, the entry will quietly become another copy of the policy.

Do not add a vague “Shady AI: yes/no” column and consider the issue handled. Record the boundary, the observation and the difference.

One example, three different answers

Take a fictional deployment: AI-017, a customer-support drafting assistant.

Maya, Head of Support, owns the use case. The assistant uses customer tickets and a controlled knowledge base to produce draft replies. Its integration can save drafts but cannot send them.

The authorised workflow requires a support agent to verify accuracy and suitability before sending.

During a fictional workflow walkthrough, the agent generates a reply and sends it without checking the content. The required review has become a click.

The platform is approved. The use case is authorised. The condition of use is not being met.

Those are three different answers. One green “Approved” cell cannot represent them.

Record the observation, investigate the cause and assign corrective action. Then verify that the review step works in practice, rather than merely issuing another reminder.

Keep missing information equally explicit. “Retention unknown; assigned to the supplier manager; response due Friday” is actionable.

“Retention: compliant” is not an answer unless someone can show what it means and how it was established.

Borrow from the infamous SBOM. Build an AI-BoM.

The software bill of materials, or SBOM, starts from a useful idea: the product name does not tell you what the product contains. It records software components and their supply-chain relationships. (NIST)

An AI bill of materials, or AI-BoM, extends that composition work to AI-specific elements. CycloneDX supports information about models, datasets, configurations and dependencies. SPDX’s AI documentation also describes relationships involving models, data, prompts and agents. (CycloneDX)

This is not your approved-tools spreadsheet with a more impressive filename.

Keep three deliverables distinct:

The inventory records what the organisation uses, for what purpose and under whose responsibility.

The AI-BoM records what a particular system is made of and depends on.

The risk register records what could go wrong and what the organisation is doing about it.

Link them. Do not turn them into three competing versions of reality.

Start with a defined boundary

For this exercise, start with a specific deployed system. Give its composition record an identifier, revision, environment, date and maintainer. Link existing software SBOMs and model-level documentation where available.

Be explicit about whether the record describes the whole deployment, a model or a supplier’s service.

A supplier’s model document does not describe the ticket integration, retrieval service and permissions your engineers added around it.

For a practical first version, I would capture or reference the following groups:

These groups reflect the broader composition relationships described by CycloneDX and SPDX. Map them to the format you use; keep supporting details in linked records where the chosen format does not capture them directly. (CycloneDX)

Record the relationships, not just the ingredients

For AI-017, connect the ticket integration, knowledge-base retrieval service, hosted generation model, controlled prompt template and draft-writing integration.

Which component reads the ticket? Which source is searched? Which model receives the assembled information? Which component writes the draft?

Keep training data separate from information retrieved or supplied during use. “Data” is not a sufficiently precise relationship.

Now imagine a model change or a vulnerable library in the retrieval service. The linked records should help identify the affected deployment and its owner without restarting discovery.

Gather evidence from deployment configurations, dependency manifests, model registries and supplier documentation. Distinguish internally verified facts from supplier declarations.

Where a supplier does not disclose an exact model version or underlying datasets, record the limitation. Capture the available service identifier, documentation date and change-notification arrangements. Do not manufacture precision.

Start with a controlled table where necessary, then move towards a machine-readable format supported by your tools. Do not assume a spreadsheet becomes interoperable merely because its filename contains “BOM.”

Keep credentials, raw customer information and confidential dataset contents out of it. Reference controlled records instead.

The ingredients can stay the same while the use goes wrong

Return to AI-017.

The model, application and integrations remain unchanged. The team simply stops checking the drafts.

The AI-BoM has not necessarily changed. The operating practice has.

Link the composition record to authorised use cases, their conditions and evidence of actual operation. Update the AI-BoM when recorded components or configurations change. Reassess the use when its purpose, information, recipients or safeguards change, even when the software does not.

A complete AI-BoM cannot tell you whether someone actually read the answer before sending it.

“Does it train on our data?” is not the whole privacy assessment

Ask the training question. Then keep going.

A no-training commitment does not answer whether information is retained for service delivery, stored in conversation histories, accessible to support personnel or passed to another service. Treat those as separate questions requiring evidence.

For each use case, investigate prompts, attachments and connected sources. Follow the outputs and logs. Establish who receives the information and what the verified deletion arrangements are.

For assistants that can act, investigate authority as well as information. Can the system read an entire mailbox, update a customer record or send material outside the organisation?

The CNIL’s analysis of agentic AI highlights the complications created by connected data sources, persistent memory, movement between services and delegated actions. Bring the privacy function a description of those operations, not just the vendor’s security page. (CNIL)

This is also where shady AI matters. An assessment of drafting general internal communications does not describe using employee appraisal records to recommend promotions.

Identify the actual processing purpose, relevant parties, applicable lawful basis, transparency arrangements and any international transfers. Link the inventory to the appropriate processing records and privacy assessments. (EUR-Lex)

The inventory and AI-BoM do not automatically satisfy those requirements. GDPR Article 30 addresses records of processing activities; Article 35 requires a DPIA where processing is likely to create high risks to people’s rights and freedoms. “AI” in the product name is not, by itself, the assessment. (EUR-Lex)

Protect the inventory itself, too. A register describing sensitive sources and powerful integrations should not become a company-wide directory of interesting things to access.

“Discovered” does not mean “approved”

Keep discovery status separate from authorisation.

“Reported by a department” and “verified in the administration console” describe evidence. “Under review,” “authorised with restrictions,” “suspended” and “retired” describe decisions or operational states.

Whether the conditions of use are actually being met requires another answer.

A system can be verified as present and still be unacceptable for its current use. Adding it to the register does not legitimise it.

Route discoveries into assessment, with named owners and dates. I would prioritise investigation where the use involves sensitive information, consequential decisions about people, broad permissions or production dependencies.

For shady AI, decide whether the response requires clarifying instructions, restoring a safeguard, restricting access, assessing a new use or stopping the activity.

Where information is missing, decide what may happen while the gap is resolved. “Under review” should not mean “continue indefinitely.”

Where discovery suggests an exposure or incident, use the existing response process. Completing the inventory entry is not containment. NIST’s governance guidance explicitly connects AI monitoring with incident response and responsibility for addressing problems. (NIST AI Resource Center)

Once the facts are established, connect them to existing risk-management work. The articles on building an AI risk register and integrating AI risk into the ISMS cover that next step. (Cyber Academy)

A green cell is a decision somebody must be able to explain.

Keep it current, or call it a historical document

Assign a custodian for the inventory and business owners for its entries. Technical owners should maintain the relevant composition and configuration evidence. NIST’s Playbook treats defined ownership and ongoing review as governance activities, not optional housekeeping after initial collection. (NIST AI Resource Center)

Connect updates to changes that already require attention: new use cases, enabled features, model changes, new data sources, additional integrations, altered permissions and retirement.

Include operational changes too. Removing a review step or changing who receives an output can warrant reassessment even when nobody deploys new code.

For AI-017, moving from “saves draft replies” to “sends replies automatically” requires a new decision. Discovering that agents already send drafts without checking them requires action now, not at the next software release.

Update linked records together and retain relevant previous versions. You need to establish what was in use at the time of an event, not only what is configured today.

Use periodic reviews to catch missed changes, not as permission to ignore everything between reviews.

For management reporting, show verified ownership, overdue assessments, unresolved information gaps and deviations from approved conditions. Describe the scope of your discovery work.

Be careful with “100% of AI inventoried.” Counting everything already on your list does not establish that nothing is missing.

Start with the inventory. Then connect the rest.

Choose one department and walk through its actual work.

Record the systems and uses. Verify the owners. Trace the information. Compare approved conditions with observed practice. Build the AI-BoM for a meaningful deployment and link it to the inventory.

Turn unanswered questions into assigned actions.

That gives you a starting point you can improve, not an unsupported claim of completeness.

The next time someone asks what AI the organisation uses, you should be able to show what you found, what it depends on, who is accountable and what still needs resolving.

You can attach the policy too. It just should not be your only answer.

For the wider governance work, explore my AI Risk Governance Toolkit. Use it alongside this approach, with the facts, owners and decisions your organisation actually needs.

Explore the AI Risk Governance Toolkit →

Find the AI nobody declared. Examine the AI everybody approved. Document what both depend on, and verify how both are used.