No. **An AI use case registry is a starting point, not sufficient proof of compliance.** It maps where AI is used, who owns it, and what risks to review. But a row in a spreadsheet neither proves data processing lawfulness nor fulfills AI Act requirements.
No. An AI use case registry is a starting point, not sufficient proof of compliance. It helps identify where artificial intelligence is deployed, who is responsible for it, and what risks need examination. However, a single row in a spreadsheet demonstrates neither the lawfulness of data processing nor the fulfillment of AI Act obligations.
For an SME or scale-up, the goal is not to accumulate paperwork. It is to connect each use case to a formal classification, to controls that are actively enforced, and to accessible evidence. Here is how to build this framework without turning your inventory into an administrative nightmare.
An inventory describes what the company uses. Compliance is also about what the company does to adhere to applicable regulations.
For instance, writing down "AI assistant for customer support" fails to answer critical questions: What data is transmitted to the provider? Must customers be notified that they are interacting with an AI? Who can access the conversations? Can an incorrect answer trigger an action in your business software?
The European Artificial Intelligence Act (AI Act) does not establish a universal internal inventory that exempts you from its other requirements. These depend in particular on your role, the system's intended purpose, and its regulatory risk tier.
Meanwhile, the GDPR requires the data controller to comply with its principles and be able to demonstrate this compliance, in accordance with the accountability principle under Article 5(2).
The registry therefore becomes useful when it serves as a gateway to decisions and supporting evidence, rather than remaining a mere tool catalog.
The word "registry" can refer to very different instruments. Confusing them often leads teams to believe an obligation is fulfilled when it is not.
Document or Mechanism | Purpose | Limitation |
|---|---|---|
Internal AI use case inventory | Track use cases, owners, data, and risks | Does not replace obligations specific to each use case |
GDPR Record of Processing Activities (ROPA) | Document personal data processing under Article 30 | Does not, on its own, address AI Act requirements |
EU Database Registration | Satisfy specific AI Act registration obligations | Does not apply indiscriminately to all tools and companies |
EU registration requirements notably apply to certain providers of high-risk systems and specific public sector deployers, as defined by the regulation. This is not the equivalent of a shared internal spreadsheet.
Conversely, your internal inventory may cover use cases that do not involve personal data and are therefore absent from the GDPR ROPA. When a use case does process personal data, the two documents should be reconcilable.
The 250-employee threshold is not a blanket exemption from maintaining a GDPR record: the exceptions provided under Article 30 are narrow. Non-occasional processing, among other factors, generally requires keeping one.
The same application can be used to rephrase an email, evaluate job applicants, or steer a business decision. Its name alone is therefore insufficient to determine the applicable rules. Classification must focus on the actual use case and its specific context.
A company that utilizes an AI system under its authority is generally considered a deployer under the AI Act. A company that develops a system, or has it developed to place it on the market or put it into service under its own name, may qualify as a provider.
Certain modifications to a high-risk system or its intended purpose can also alter this allocation of responsibilities. Purchasing a third-party solution does not mean the vendor assumes all your compliance obligations.
Document your role and rationale in the use case file. For custom developments, clarify each party's responsibilities contractually as well. A contract facilitates operational allocation, but cannot override a role established by law.
An AI organizational structure with explicit roles and responsibilities makes it easier to assign these decisions to the right individuals.
An AI use case registry must differentiate between the legal classification of the system and your internal risk assessment.
An AI writing assistant may present a trade secret leakage risk without necessarily falling into the regulatory "high-risk" tier for that reason alone. Conversely, a system intended to screen or rank job applications can fall under high-risk provisions, depending on its specific features and applicable exceptions.
Avoid having a single column for "Risk: Low, Medium, High". Provide two distinct fields: justified regulatory classification and identified operational risks.
The classification must also help spot prohibited AI practices. A prohibited use case does not become permissible simply because a manager signed off on it or a human reviews the output.
For detailed deadlines and obligations, consult our guide on AI Act obligations for SMEs and scale-ups, then check the regulatory timeline applicable to your situation.
The right level of detail allows someone outside the project to understand how it works, the trade-offs made, and the conditions of its internal authorization.
Here is a baseline structure. This is a recommended governance template, not a legally mandated list of fields for every use case.
Field | Information to Provide |
|---|---|
Identifier and Purpose | Unique reference, business problem addressed, and authorized scope |
Business Owner | Individual owning the use case with authority to suspend it |
System and Vendor | Solution, relevant version/configuration, and supplier |
Company's Role | Deployer, provider, or other applicable role, with rationale |
Data and Flows | Data categories, sources, recipients, processing locations, and retention |
Regulatory Classification | AI Act analysis, associated GDPR processing, and identified obligations |
Impact of Outputs | Pure suggestion, external communication, or automated action |
Applied Controls | Access rights, human oversight, testing, and usage restrictions |
Supporting Evidence | Links to contracts, analyses, test reports, and operating procedures |
Status and Review | Internal approval status, conditions, review date, and triggering events |
An AI use case registry can start in a spreadsheet. The quality of your framework depends far more on the reliability of the information and the tracking of decisions than on the chosen software tool.
Supporting evidence can remain in its usual storage locations, provided the links are accessible to authorized staff. Avoid copying sensitive data into the registry merely to make the record look more exhaustive.
Consider a hypothetical scenario: an SME wants to generate response drafts based on support tickets and product documentation. An employee reviews every proposed draft before sending.
A record merely stating "tool approved, low risk" is inadequate. It details neither the transmitted data, nor the recipients, nor the actions the system can perform.
A useful record specifies that the assistant only generates drafts, issues no refunds, and modifies no customer accounts. It identifies the data categories present in tickets and specifies restrictions on attachments. It references the vendor's contractual terms, the GDPR assessment, and test results conducted prior to team rollout.
Testing might address hallucinations, attempts to extract another customer's data, or prompt injections contained in tickets. While tests do not prove total compliance, they substantiate tangible controls.
Internal approval applies strictly to this defined scope, not to all future iterations. If the assistant begins responding directly to customers, querying new databases, or executing refunds, a fresh assessment becomes necessary.
This example highlights the true purpose of an AI use case registry: making operational boundaries visible and flagging changes that require re-evaluating the case.
There is no one-size-fits-all compliance file. The required documentation depends on applicable rules and risk levels. The registry must make it easy to retrieve the records justifying your decisions, without imposing disproportionate documentation requirements across the board.
If a use case involves personal data, supporting records must cover the relevant requirements of the GDPR: purpose, legal basis, data minimization, transparency notices, retention, and security.
Depending on your relationship with the vendor, a data processing agreement (DPA) compliant with Article 28 may be required. Potential international data transfers outside the European Economic Area must also be evaluated. A marketing claim of "EU hosting" alone does not resolve all compliance requirements.
A Data Protection Impact Assessment (DPIA) is required when processing is likely to result in a high risk to the rights and freedoms of individuals. This criterion is distinct from the "high-risk AI system" classification under the AI Act.
Finally, when a decision is solely automated and produces legal effects or similarly significantly affects an individual, Article 22 mandates a specific assessment. Purely superficial human rubber-stamping does not alter the automated nature of the process.
AI literacy under Article 4 requires measures tailored to staff operating systems on your behalf. Keeping records of training materials, target audiences, and operational guidelines helps demonstrate compliance. The regulation does not prescribe a universal training certificate.
For high-risk systems, deployer obligations may include adhering to instructions of use, implementing human oversight, monitoring operation, and retaining automatically generated logs under their control. Their practical implementation must be reviewed in detail, rather than checked off with a generic "oversight planned" box.
Certain use cases also trigger transparency obligations, such as notifying individuals that they are interacting with an AI when required.
The AI use case registry must point to these safeguards and their proof. It does not replace them: noting "logging enabled" proves neither that the logs actually exist nor that they are stored properly.
The biggest risk of any inventory is becoming an outdated snapshot. To avoid this, tie updates directly to events that materially alter your organization's risk exposure.
A new intended purpose, a vendor change, introducing sensitive data, or transitioning from a suggestion to an automated action must trigger a review. A model update may also warrant fresh testing if it alters the system's behavior.
A lightweight workflow can distinguish between three statuses: under review, testing approved within defined bounds, and conditionally approved for production. None of these statuses constitute legal certification; they simply reflect what your organization has decided and on what basis.
Set up an easy channel to report new use cases, including shadow AI adopted directly by teams. A registry covering only formal IT projects misses a significant share of actual AI usage.
Finally, designate who has the authority to suspend a use case in the event of an incident. A record without an accountable owner remains merely descriptive, regardless of how thorough it is.
Is a spreadsheet sufficient to maintain the registry? Yes, to start with, provided access permissions are controlled, records are kept up to date, and evidence remains accessible. A more specialized tool becomes valuable when the volume of use cases, approvals, or changes becomes difficult to track.
Must every prompt sent to an AI be logged? Not systematically. The registry primarily covers use cases and their governance parameters. System logs may be required depending on the system and regulatory obligations, but logging every prompt can introduce secondary privacy and confidentiality risks.
Can the AI vendor guarantee our compliance? Their documentation and contractual commitments are helpful, but they cannot automatically ensure your compliance. You remain responsible for obligations tied to your operational role, your data, and your business processes.
Is a DPIA required for every AI project? No. It is mandatory only when personal data processing is likely to result in a high risk. The assessment must be performed on a case-by-case basis and its conclusion documented.
Start with a single priority use case: define its scope, classify applicable obligations, and gather missing evidence before expanding its deployment. This approach helps separate legal prerequisites from technical implementation tasks.
Impulse Lab supports companies through AI opportunity audits, system integrations, and custom developments, as well as AI adoption training. This technical and operational framework works alongside your DPO or legal counsel, clearly distinguishing opportunity discovery from formal compliance sign-off.
Our team of experts will respond promptly to understand your needs and recommend the best solution.
Got questions? We've got answers.
Leonard
Co-founder
