Shadow AI at Work: Five Steps to a Complete AI System Inventory

An AI system inventory records every AI tool, its owner, purpose, data categories, provider, and user groups. It separates approved applications from shadow AI and links each use case to a risk assessment and required controls. This creates the operating foundation for privacy, security, procurement, training, and EU AI Act governance.

Legal status reviewed on July 14, 2026. This article provides operational guidance and is not a substitute for legal advice.

Why do many companies not know which AI systems are actually in use?

The official software list of a mid-sized company may contain Microsoft 365, a CRM platform, an ERP system, a phone system, project software, and several industry applications. What frequently remains absent from that list are the AI functions already being used inside those products or through additional web services.

A sales representative summarizes a call transcript with ChatGPT. A project manager asks an assistant to analyze tender documents. Customer service automatically classifies incoming email. Microsoft Copilot creates meeting notes. A translation platform processes technical documentation, and the company’s phone service converts a caller’s description into a structured callback ticket.

An HVAC contractor may create service reports from technicians’ voice notes. An electrical business may use image recognition to support job-site documentation. A traffic-management company may summarize project specifications and work orders. A yacht service provider may use an AI assistant for maintenance inquiries, while a marina experiments with automated berth communication.

None of these activities needs to have started as a formal AI project. Some features arrived through an ordinary software update. Others were purchased directly by a business unit. Some are accessed through free services or personal accounts because an employee wants to finish a particular task more efficiently.

That is how shadow AI develops. AI systems or AI-enabled functions are used for company work without complete approval, assessment, documentation, or organizational oversight.

Shadow AI does not necessarily mean malicious or reckless behavior. A useful tool can still become shadow AI when nobody knows what information is being submitted, which contract applies, whether the provider retains the data, or who is accountable for checking the output.

An effective AI system inventory therefore does not begin only with large implementations. It begins by asking where software generates, analyzes, translates, classifies, predicts, recommends, prioritizes, or acts through AI.

Does the EU AI Act require every company to maintain an AI system inventory?

The EU AI Act does not establish a blanket obligation requiring every company to maintain one standardized register covering every low-risk AI application. The regulation instead assigns different requirements according to the organization’s role, the purpose of the system, and its regulatory category.

Specific high-risk systems are subject to documentation, instructions for use, human oversight, monitoring, logging, and in some cases registration requirements. Deployers of high-risk AI systems must retain automatically generated logs when those logs are under their control. Separate obligations apply to certain systems that interact with people or produce synthetic content, while Article 4 addresses the AI literacy of people operating and using AI systems.

A simple internal writing assistant does not automatically create a legal obligation to complete a prescribed inventory form. However, a company cannot reliably determine which rules apply when it does not know which systems, features, and use cases exist.

The inventory is therefore primarily an AI governance control. It turns fragmented legal, security, procurement, and operational requirements into a shared record that can be used by management and business teams.

The U.S. National Institute of Standards and Technology explicitly recommends organizational mechanisms for inventorying AI systems in its AI Risk Management Framework. NIST describes an AI system inventory as an organized collection that may include documentation, data dictionaries, software components, incident plans, and contact information for relevant actors. The inventory provides an organization-wide view of AI assets and supports maintenance and incident response.

Data protection and security authorities also treat discovery and documentation as foundational activities. France’s CNIL recommends establishing an exhaustive and precise inventory of deployed AI systems. The United Kingdom’s Information Commissioner’s Office connects AI governance with documented responsibilities, senior-management approval, privacy oversight, and evidence that risks have been reviewed.

An inventory is therefore not merely another spreadsheet for audit preparation. It is the mechanism that enables the company to assess, approve, secure, monitor, change, and retire AI systems in a controlled way.

What should count as an AI system for inventory purposes?

A complete inventory should not be limited to well-known conversational assistants. AI is increasingly embedded in applications that may have been purchased as ordinary business software.

The first category includes general-purpose tools such as ChatGPT, Claude, Gemini, Microsoft Copilot, and comparable assistants. The company should not record only centrally purchased enterprise accounts. Free accounts, personal subscriptions, browser-based tools, and mobile applications may also be used for business tasks.

Translation, transcription, and writing services form another category. These tools may process complete emails, contracts, customer correspondence, meeting recordings, technical reports, or proposals. The inventory should therefore describe the actual business purpose rather than relying only on a generic product label.

AI phone systems and digital customer interfaces include voice assistants, web chatbots, automated callback intake, appointment assistants, and conversational customer portals. The record should describe whether the system only captures information, creates CRM records, confirms appointments, assesses urgency, or independently provides answers.

CRM and sales platforms increasingly contain AI for lead scoring, email drafting, sales forecasting, meeting summaries, data enrichment, and activity recommendations. One licensed CRM platform may therefore contain several AI use cases that require separate assessment.

ERP, finance, HR, and project systems may include invoice extraction, automated coding, candidate matching, workforce scheduling, demand forecasting, and document generation. These functions may be activated by default or introduced through a feature update without a new procurement event.

Industry applications deserve particular attention. In construction, skilled trades, field service, and engineering, AI may prepare quotations, analyze specifications, interpret images, retrieve maintenance information, or draft job documentation. Manufacturing and logistics may use AI for visual inspection, predictive maintenance, route optimization, production scheduling, or demand planning.

The inventory must also cover internally developed applications, AI agents, company knowledge systems, locally hosted models, and API-based automations. These solutions often combine several suppliers and components: a model provider, hosting service, vector database, workflow platform, business application, and internal system owner.

The company should also include AI-enabled features that affect employees or applicants. Resume screening, candidate matching, performance analytics, behavioral monitoring, shift planning, and automated task allocation can create substantially different obligations from ordinary office assistance.

When should one software product create more than one inventory entry?

Not every minor feature requires a separate record. However, the structure must be detailed enough to prevent different purposes, data sources, user groups, and effects from disappearing under a single product name.

Microsoft Copilot may be used as a writing assistant in Word. The same product family may transcribe meetings, summarize email, search SharePoint, read calendar information, or retrieve data from connected business applications. One entry labeled only “Microsoft Copilot” may be insufficient when permissions, data sources, users, and approval conditions differ.

A practical rule is to create a separate use case whenever one of the following changes materially: business purpose, user group, affected people, data category, connected source, automated action, decision impact, operating environment, or accountable business owner.

A CRM platform may therefore produce several entries. Automated call summaries are different from lead scoring. The first provides a draft work record. The second may influence which customers receive attention, which opportunities are prioritized, and how resources are allocated.

An AI phone assistant may initially record only a name and callback number. A later version might schedule technicians, classify emergencies, update customer records, or provide pricing information. The expanded functions require a new assessment even when the vendor and product name remain the same.

A company knowledge assistant may search only approved public product information during its pilot phase. If it later receives access to project documents, service histories, contracts, and internal pricing, its risk profile changes substantially.

The correct unit is therefore not always the product. It is the business use case: a defined combination of purpose, people, data, system behavior, and operational responsibility.

How can a company discover shadow AI in five practical steps?

A company-wide email asking “Who uses AI?” rarely produces a complete answer. Some employees do not consider a translation service to be AI. Others may be reluctant to disclose a useful tool because they expect an immediate ban. Some do not know that their existing software now includes generative or predictive features.

A reliable discovery process should combine multiple sources.

Step one: Review known systems, accounts, and contracts.
Begin with software contracts, invoices, corporate credit-card transactions, single sign-on directories, application marketplaces, browser extensions, mobile-device records, IT asset lists, and existing privacy documentation.

Procurement may know about applications that do not appear in the technical asset inventory. Business teams may know about AI features that appear on invoices only under the name of a larger software platform.

Step two: Ask about work activities rather than brand names.
Instead of asking only which AI tools are used, ask whether employees automatically draft text, translate documents, transcribe calls, analyze images, classify requests, rank candidates, forecast demand, recommend actions, or summarize business records.

This approach works in departments that do not use AI terminology. A dispatcher may describe “automatic route optimization.” An HR employee may refer to a “matching function.” A technician may describe an “intelligent troubleshooting search.” A sales manager may call a feature “opportunity scoring.”

Step three: Review technical evidence where appropriate.
Depending on legal, labor, and organizational requirements, identity platforms, secure web gateways, firewall logs, endpoint management, SaaS management, and data-loss-prevention tools may indicate which external AI services are being accessed.

Technical visibility should support rather than replace business interviews. Network evidence may identify a domain or application, but it does not reliably explain the purpose, the information submitted, the output used, or whether the employee was acting in a personal or business context.

Step four: Examine AI embedded in existing software.
Some of the largest inventory gaps arise inside approved platforms. Contract renewals, feature releases, and vendor roadmap discussions should therefore include questions about newly enabled assistants, scoring functions, prediction models, content generation, and autonomous actions.

A product that passed a security and privacy review two years ago may now process data through a third-party foundation model. The original assessment may no longer reflect its current architecture.

Step five: Provide a protected disclosure route.
The initial objective should be discovery and risk reduction, not punishment. Employees are more likely to report unapproved tools when the company distinguishes between good-faith experimentation, careless handling, and deliberate circumvention.

A time-limited disclosure period can allow teams to report current use, explain why the tool was chosen, and identify whether an approved enterprise alternative is available. Serious violations must still be addressed, but discovery should not be designed in a way that encourages concealment.

The five-step exercise should become an ongoing intake process. New AI services and embedded features appear continuously, and a one-time survey will begin to age as soon as it is completed.

How should approved and unapproved AI uses be categorized?

A binary status of “allowed” or “forbidden” is often too crude for practical governance. Several intermediate states help the company distinguish completed approval from limited experimentation and unresolved risk.

Approved means that the purpose, provider, contract, data handling, security measures, users, and operating conditions have been assessed. The approved scope is recorded.

Conditionally approved means that the tool may be used only under specified restrictions. A public writing assistant might be permitted for general wording support but prohibited for customer, employee, contract, technical, or project data.

Pilot means that the use is limited by time, users, data, and purpose. Success criteria, review dates, and termination conditions should be recorded. A pilot is not an indefinite exception from normal approval.

Under review means that a use case has been disclosed but the assessment is incomplete. The company should state whether limited use may continue during review or whether it must pause.

Unapproved means that the required review or authorization did not occur. The tool may ultimately be suitable, but it should not silently become a normal production system.

Prohibited or blocked applies when the use conflicts with law, company policy, contract obligations, security requirements, or a decision by management. The inventory should record the reason and the technical or organizational measure used to stop the activity.

Retired identifies systems that are no longer in use. Historical records should remain available so the company can document the shutdown date, data deletion or export, account closure, and replacement solution.

The status should apply to the defined use case, not merely to the brand. ChatGPT could be conditionally approved for public-content drafting while remaining unapproved for customer contracts or personnel files.

Which fields belong in a dependable AI system inventory?

An SME does not need specialized governance software on day one. A structured spreadsheet, list, or database can be sufficient when it supports ownership, mandatory fields, review dates, and controlled access.

Each record should receive a unique system or use-case identifier. The business purpose should be specific. “Text generation” is less useful than “first drafts of sales follow-up emails using non-confidential information.”

The business owner is the person who understands why the system is used and how its output affects the process. A separate technical owner may be responsible for configuration, integrations, identity management, and support. The contract owner should also be recorded when procurement responsibility sits elsewhere.

User groups should be described by function, department, location, or authorized role rather than by a broad label such as “all employees.” Named pilot users may be appropriate for limited tests.

Data categories may include public information, internal documents, customer contact information, correspondence, contracts, applicant data, employee records, technical measurements, images, audio, transcripts, pricing, source code, financial information, or trade secrets.

The operating model should record whether the system is public cloud, enterprise SaaS, privately hosted, on-premises, local to a device, or hybrid. For external services, relevant information includes the contracting provider, hosting region, subprocessors, retention, and use of customer input for provider training.

The record may also include the model or model family, connected data sources, APIs, permissions, automated actions, output recipients, human review, logging, fallback process, approval status, AI Act assessment, privacy assessment, security assessment, required training, and last review date.

Not every low-impact use case needs extensive documentation in every field. The underlying structure should remain consistent so that higher-impact systems can be compared and governed without creating a separate method each time.

What might a practical inventory record look like?

Consider a mid-sized technical service company using an AI phone assistant outside office hours.

A simplified record may contain the following:

Use-case ID: AI-VOICE-003
System: AI phone assistant for after-hours service intake
Purpose: Collect caller name, callback number, site address, equipment type, fault description, and preferred callback period
Business owner: Head of Service
Technical owner: IT Manager
Provider: Contracted voice-AI supplier
Users and affected people: Callers, service desk employees, and dispatch staff
Data categories: Contact details, site information, technical fault description, audio, and transcript
Automated actions: Create a service ticket and send an internal notification
Human review: Dispatch checks the ticket before confirming an appointment, price, or scope of work
Approval status: Conditionally approved
EU AI Act assessment: Direct interaction with natural persons; transparency notice required
Privacy assessment: Processor agreement, notice, purpose, legal basis, access, and retention reviewed
Security assessment: Transcript permissions, logs, deletion, authentication, and incident reporting documented
Review trigger: Vendor update, new CRM integration, new automated action, or scheduled review date

This example demonstrates why a list of product names is insufficient. The useful record describes the real workflow, authority, information, and control points.

How do common AI applications compare inside the inventory?

The table presents common starting points. The actual assessment depends on the purpose and operation of the system in the individual company.

How should the inventory record risk classification?

A single traffic-light color is not enough. An AI system may fall outside the EU AI Act’s high-risk categories while still creating significant privacy, security, contractual, or operational exposure.

A multi-dimensional assessment is more useful.

EU AI Act category:
The company records whether the use may involve a prohibited practice, a high-risk category, a transparency obligation, provider responsibilities, or another form of AI use. When evidence is incomplete, the status can state that specialist assessment is pending.

Privacy risk:
The assessment considers personal data, special categories of data, affected people, purpose, scale, monitoring, automated decisions, and possible consequences. The AI system inventory does not replace the GDPR record of processing activities. It should cross-reference the relevant processing activity and any required data protection impact assessment.

Information security risk:
The record should address confidentiality, integrity, availability, authentication, permissions, connected systems, third parties, logging, incident response, and recovery. Systems that retrieve internal knowledge or perform actions in other applications require particular attention.

Operational and quality risk:
Possible failures include inaccurate output, incorrect classification, service interruption, unsuitable recommendations, and uncontrolled automation. An internal wording suggestion has different consequences from faulty dispatch, a technical instruction, or a customer message that appears contractually binding.

Impact on people:
The company should consider applicants, employees, customers, suppliers, and other affected individuals. The review priority increases when AI influences access, selection, ranking, pricing, services, working conditions, or contractual treatment.

Contractual and reputation risk:
AI may expose confidential information, generate unauthorized commitments, use protected material, or conflict with customer and supplier agreements. These risks are frequently missed when the assessment is treated as a purely technical exercise.

The inventory should connect the assessment to required controls. “Medium risk” is less useful than a documented requirement for restricted access, training, professional review, privacy assessment, enhanced logging, vendor replacement, or suspension.

Which controls should be attached directly to each record?

A useful inventory drives action. Every record should state which conditions must be met before the system begins or continues operating.

For a general writing assistant, controls may include an approved enterprise account, a list of prohibited data, user training, and professional review before external publication.

For a company knowledge assistant, priority controls include source approval, identity management, document permissions, logging, retention, and protection against unauthorized retrieval. The record should state who may add new sources and who approves changes.

For an AI phone assistant, the record should cover the AI disclosure, privacy information, processor agreement, retention period, employee handoff, emergency workflow, and limitations on binding commitments.

For an HR application, controls may include a detailed EU AI Act assessment, privacy impact review, employee-representation involvement, vendor evidence, discrimination testing, human authority, and documented review of individual outcomes.

For an AI agent, permissions should be described at the action level. Reading, drafting, changing, sending, purchasing, deleting, and approving are different authority levels. An agent that prepares an email draft needs fewer controls than one that sends messages or changes customer records without prior approval.

Each control should have an owner, due date, status, and supporting evidence. Otherwise, the inventory becomes a list of unresolved observations rather than an operating governance tool.

How should the AI system inventory connect to privacy management?

Privacy and AI governance should not operate as separate collections of spreadsheets.

When an AI system processes personal data, its inventory record should link to the corresponding processing activity in the organization’s privacy-management system. The privacy record can in turn reference the AI use case.

The two records serve different purposes. A GDPR record describes the processing of personal data. The AI system inventory additionally covers systems that do not process personal data, AI functions, organizational roles, models, providers, decision effects, human review, AI Act categories, and technical controls.

An AI translation service may appear in both systems when it processes customer correspondence. If it is used exclusively for public marketing content, it may remain relevant only to the AI inventory.

The data protection officer should not automatically become the sole owner of the complete AI inventory. The DPO advises and monitors compliance with data protection law. Business purpose, procurement, operation, professional review, and AI-system ownership remain management and business responsibilities.

A shared data model can reduce duplicate work. Provider, hosting, data categories, retention, processors, affected people, and purpose should not have to be collected independently by every control function.

The inventory can also identify cases requiring deeper privacy review before implementation. Examples include employee monitoring, applicant scoring, behavioral analysis, extensive profiling, large-scale customer-data analysis, biometric processing, or decisions with significant effects.

How should the inventory connect to information security?

From an information-security perspective, an AI system is an asset within the company’s technology environment. The inventory should therefore connect with asset management, identity governance, access control, supplier management, vulnerability management, incident response, and business continuity.

A public chatbot can create data leakage even though it is not installed on company infrastructure. A privately hosted knowledge assistant can still expose sensitive information when source permissions are too broad. A CRM-based AI feature may remain inside the vendor platform while allowing an incorrectly configured role to access an entire customer portfolio.

The security record should state who can access the service, which sources are connected, what the system can reveal or change, which logs exist, and how access is revoked.

External services require additional attention to tenant separation, encryption, subprocessors, security notifications, vulnerability handling, retention, backup, and exit arrangements.

Prompt injection and manipulated content also belong in the review. A knowledge assistant may encounter instructions embedded in documents or websites that attempt to alter its behavior. The impact may be limited when the system is read-only. The consequences are greater when an agent can send messages, change records, download files, or trigger external tools.

The inventory should link to existing security assessments, data classifications, threat models, incident procedures, and recovery plans. It does not replace those documents. It ensures that the AI system cannot operate outside the company’s established security processes.

The information-security team should also distinguish visibility from content monitoring. Discovering that a service is used is different from reviewing every prompt submitted by employees. Technical controls must remain proportionate and comply with labor, privacy, and internal governance requirements.

How should procurement use the AI system inventory?

Many shadow AI cases begin because a tool is purchased faster than it is assessed. A department needs translation, transcription, image analysis, or document assistance and activates a monthly subscription directly.

Procurement should therefore include a straightforward question in its intake process: Does the product contain AI, generative content, prediction, automated scoring, decision support, or autonomous actions?

A positive answer should create a preliminary inventory record before contract signature. The depth of the subsequent assessment can then be scaled to purpose, data, users, and impact.

Important procurement questions include hosting, data use, subprocessors, provider training, retention, deletion, model updates, security evidence, logging, export, incident support, service continuity, and termination.

For industry applications, vendors should explain which functions use AI, whether those functions are enabled by default, which external models receive information, and whether the customer can disable or restrict them.

Contract renewals are another important control point. A product originally purchased as conventional software may now include copilots, predictive scoring, content generation, or agents. The existing inventory record should be updated before renewal.

The inventory also supports cost management. Multiple departments may be paying for different tools that perform similar work. A consolidated view can reveal duplicate subscriptions, unused enterprise capabilities, fragmented supplier relationships, and opportunities for standardization.

Procurement should not treat every AI feature as grounds for a long assessment. A tiered review process allows low-impact services to move quickly while reserving deeper scrutiny for personal data, sensitive information, external communication, employee use, high-impact decisions, and automated actions.

Who should own and maintain the inventory?

Organizational accountability should sit with a named role or governance function, but the work should not be isolated inside one department.

Executive management approves the governance approach and resolves material risk decisions. An AI governance owner or small cross-functional group maintains the method, status categories, review process, and consolidated inventory.

Business departments own the purpose and professional use of their systems. IT documents architecture, integrations, access, and technical operation. Privacy and information security complete their respective reviews. Procurement manages vendor and contract information. HR and employee representatives participate where workforce systems are involved.

In a smaller business, one person may perform several roles. Those roles should still be described separately. An external IT provider can document configuration but is not automatically responsible for deciding whether the business purpose is appropriate.

Every record needs at least one business owner. Systems without an identifiable owner tend not to receive regular review, timely updates, or effective incident handling.

The central governance function should not have to enter every detail manually. A distributed process works better: departments submit and update their use cases, while the governance owner checks completeness, classification, approvals, overdue actions, and review dates.

Management reporting should focus on decisions rather than the total number of rows. Useful information includes unapproved systems, systems without owners, high-priority reviews, unresolved security measures, upcoming contract renewals, and retired systems with incomplete data deletion.

How can the inventory remain current after the first assessment?

An AI system inventory becomes obsolete quickly when it is not connected to normal company processes.

New software purchases, pilot projects, contract renewals, and major feature activations should automatically trigger review. The same applies to new integrations, expanded data sources, additional users, and increased automation.

Software updates may also matter. A newly displayed assistant that remains disabled may require only a note. Once it is activated, used with business data, or connected to other systems, a new or updated assessment is needed.

A scheduled review should confirm whether the system is still in use, whether the purpose and users remain accurate, whether the provider or model changed, and whether required controls were completed.

Incidents should update the record. An inaccurate customer response, unauthorized data exposure, unexpected system action, quality failure, or inappropriate access may indicate that the previous assessment and controls are no longer sufficient.

Employee departures, role changes, mergers, reorganizations, and supplier changes are additional triggers. Access to web-based AI tools is sometimes removed less consistently than access to ERP or CRM because the service is perceived as an informal productivity tool.

Every record should therefore include the reason for the most recent review, the outcome, outstanding actions, and the next review date.

The company should also monitor the difference between approved functionality and actual functionality. A system may be approved only for drafting while its technical configuration allows sending, deleting, or updating records. Governance must address both policy and capability.

Which four figures illustrate the scale of shadow AI?

Shadow AI is not a marginal scenario. In Microsoft’s German Work Trend Index, 71 percent of AI users reported bringing their own AI tools to work. This does not mean that every one of those tools violated company policy, but it shows how rapidly adoption can develop outside centrally managed implementation programs.

The consequences of limited oversight appear in security research. IBM’s 2025 Cost of a Data Breach research found that 20 percent of the organizations studied had experienced a breach linked to shadow AI. At the same time, only 37 percent had policies to manage AI or detect shadow AI.

Technical discovery also remains difficult. Cisco’s 2025 Cybersecurity Readiness Index reported that 60 percent of organizations lacked confidence in their ability to identify unregulated AI deployment in their environments.

These figures come from international and vendor-sponsored studies and should not be treated as a precise forecast for every German SME. Together, however, they demonstrate a recurring governance pattern: employee and product adoption often moves faster than inventories, policies, procurement, and technical controls.

How does the inventory become an operational AI governance system?

The inventory is not the final objective. Its value comes from the decisions and recurring processes connected to it.

A new AI use case can follow a proportionate workflow: disclose, describe, classify, assess, approve, monitor, and retire. Low-impact applications can move through a compact review. Systems involving employment, sensitive customer information, safety, high-impact recommendations, or autonomous actions require additional controls.

The AI policy states which systems, data, and activities are permitted. The inventory shows where those rules apply. The role matrix identifies who may use, administer, review, and approve a system. The training register shows whether those people received appropriate instruction.

Together, these documents form a practical governance foundation. New applications can be reviewed more efficiently because roles, review questions, risk categories, and approval levels already exist.

The inventory also supports management decisions about consolidation and investment. It shows which use cases create business value, which tools duplicate existing capability, which pilots should be expanded, and which systems should be retired.

KrambergAI GmbH, https://krambergai.com/, supports mid-sized companies in building this foundation through an AI system inventory, AI policy, role model, training program, and proportionate approval process. The work can begin with discovery of existing applications and then focus on the processes with the greatest operational and regulatory relevance.

Which sources support the figures used in this article?

Microsoft Germany: 2024 Work Trend Index on AI at Work
https://news.microsoft.com/de-de/work-trend-index-2024-microsoft-und-linkedin-veroeffentlichen-bericht-zum-einsatz-von-ki-bei-der-arbeit/

IBM: 2025 Cost of a Data Breach Report Findings on Shadow AI
https://newsroom.ibm.com/2025-07-30-ibm-report-13-of-organizations-reported-breaches-of-ai-models-or-applications%2C-97-of-which-reported-lacking-proper-ai-access-controls

Cisco: 2025 Cybersecurity Readiness Index and Shadow AI Detection
https://newsroom.cisco.com/c/r/newsroom/en/us/a/y2025/m05/cisco-study-reveals-alarming-deficiencies-in-security-readiness.html

Which resources provide useful further reading?

NIST: AI Risk Management Framework Playbook for AI Inventory and Governance
https://airc.nist.gov/airmf-resources/playbook/govern/

Information Commissioner’s Office: Governance and Accountability in AI
https://ico.org.uk/for-organisations/advice-and-services/audits/data-protection-audit-framework/toolkits/artificial-intelligence/governance-and-accountability-in-ai/

CNIL: AI System Security Actions and Comprehensive Inventory
https://linc.cnil.fr/en/ai-system-security-actions-make-difference

Does every SME have to maintain an AI system inventory?

There is no universal legal obligation requiring every SME to maintain one standardized register of all AI applications. The inventory is nevertheless a foundational governance measure. Without it, the company cannot reliably determine which systems trigger transparency, training, privacy, security, documentation, registration, or future high-risk obligations, or identify who owns each use case.

Should free AI services be included?

Yes, when they are used for company work. Whether a tool is free, personally subscribed, or centrally purchased does not remove data, security, contract, or compliance risks. Free accounts are especially important because retention, provider training, administrative controls, support, contractual protection, and privacy settings may differ substantially from paid enterprise versions.

Must every individual ChatGPT prompt be recorded?

Normally, the inventory records the business use case rather than every individual prompt. Examples include preparing proposal drafts or summarizing public research. When purpose, data, users, decision impact, or output recipients differ materially, the company should create separate use cases and apply different approval conditions, even when the same ChatGPT account or platform is used.

How should a company handle existing shadow AI?

The company should first identify and assess the use without assuming that every case requires punishment. It may be possible to provide an enterprise version, restricted approval, or a suitable alternative. Where the use involves prohibited data handling or unacceptable risk, it must stop. Existing accounts, stored information, contracts, integrations, and possible incidents should also be reviewed.

Is the AI system inventory the same as the GDPR record of processing activities?

No. The GDPR record documents processing activities involving personal data. The AI system inventory also covers AI functions without personal data, business purpose, system roles, models, providers, users, approval status, risk categories, human review, and technical controls. The records should be linked whenever an AI use case processes personal information.

Who should create a new inventory record?

The business department should disclose the use and describe its purpose, users, workflow, and expected output. A central governance owner can coordinate classification and approval. IT, privacy, security, procurement, HR, and employee representatives contribute where relevant. Every production use case should have a named business owner accountable for its continuing suitability and review.

Should a disabled AI feature be recorded?

A feature that is available but disabled does not always require a complete production record. A short note may still be useful when activation is easy or the function may appear after an update. Before activation, the company should assess data access, external model connections, user groups, automated actions, contract implications, and additional legal or security requirements.

How detailed should the risk classification be?

The depth should reflect purpose and possible consequences. A low-impact internal writing assistant may require a compact assessment. Candidate selection, employee evaluation, safety recommendations, customer scoring, large-scale personal-data analysis, or autonomous actions require separate consideration of the EU AI Act, privacy, security, professional quality, contractual effects, and impact on individuals.

Which tool should an SME use for its inventory?

A structured spreadsheet, SharePoint list, Airtable base, Notion database, or existing governance platform can be sufficient initially. Important capabilities include controlled access, required fields, owners, version history, review reminders, and action tracking. Larger inventories should connect with procurement, privacy management, IT asset management, identity systems, contract management, and service-desk workflows.

How often should the inventory be reviewed?

An annual full review is a workable baseline for many SMEs. Event-driven updates are also needed when systems, features, data sources, users, models, providers, permissions, integrations, automation, or contracts change. Incidents and quality failures should trigger reassessment. Dynamic or higher-impact systems may need quarterly or release-based review rather than an annual cycle.

Do internally developed AI agents belong in the same inventory?

Yes. Internal agents often require more detailed documentation because they combine models, prompts, tools, databases, integrations, and action permissions. The record should include hosting, data sources, system instructions, identity, permissions, logs, human approvals, automated actions, fallback, testing, and shutdown procedures. A change from drafting to sending or deleting can materially change risk.

May an employee representative body access the inventory?

That depends on the system, the information recorded, and applicable co-determination or labor rights. Early involvement is advisable for applications affecting behavior, performance, monitoring, work allocation, or employment conditions. The inventory can support that review, although sensitive administrative credentials, security architecture, and unrelated personal information should be shared only to the extent required.