White Paper · AI Governance · Inventory

The AI Inventory as a Legal and Evidence Record

An AI inventory should let counsel answer what a system did, who approved it, which law applied, what changed, and what evidence exists. A software list cannot do that. The inventory becomes useful when it records use cases, decisions, data, people affected, vendors, legal triggers, testing, approvals, and change history.

By Lincoln Square Law · 8-minute read

Inventory use cases, not brand names

A row that says “Microsoft Copilot” or “AI recruiting tool” is not a legal inventory. The same product can support low-risk drafting in one department and a regulated employment decision in another. Each inventory record should identify the business process, decision or output, users, affected individuals, input data, output data, automated action, human review, vendor, model or service, deployment date, and system owner. The unit of analysis is the use case.

This approach also solves the shadow-AI problem. Employees may use the same public tool for summarization, customer support, coding, hiring, or document review. Those uses have different confidentiality, discrimination, biometric, record-retention, and contract risks. One product entry cannot carry all of that information.

Flag employment decision points under Illinois law

Illinois Public Act 103-0804 amended the Human Rights Act for AI used in recruitment, hiring, promotion, renewal of employment, training or apprenticeship selection, discharge, discipline, tenure, and terms, privileges, or conditions of employment. The amendment prohibits AI use that has the effect of subjecting employees to discrimination based on protected classes and prohibits using ZIP codes as a proxy for protected classes. It also requires notice when employers use AI for the covered purposes, with implementing rules contemplated by the statute.

The inventory should therefore include fields for employment stage, decision significance, protected-class testing, proxy features, human override, notice status, and accountable HR/legal owner. Do not wait for a complaint to discover that a general-purpose screening or ranking feature has become part of a covered decision process.

Separate video-interview AI from other hiring tools

Illinois’s Artificial Intelligence Video Interview Act imposes specific requirements when an employer asks an applicant for a recorded video interview and uses AI to analyze it for an Illinois-based position. Before the interview, the employer must notify the applicant that AI may be used, explain how the AI works and the general types of characteristics it evaluates, and obtain consent. The inventory needs a dedicated flag for this workflow because it carries requirements that are not captured by a generic “employment AI” field.

Record whether the vendor stores video, audio, transcripts, derived features, scores, or model outputs, who can access them, how long they are retained, and what deletion process applies. The legal review should follow the actual data flow, not the vendor’s marketing category.

Add a biometric trigger field

AI systems can create biometric issues even when “biometrics” is not in the product name. Illinois BIPA defines specified biometric identifiers and regulates biometric information based on those identifiers. Before collecting covered biometric data, a private entity generally must provide written disclosures about collection, purpose, and duration and obtain a written release, while also maintaining a public retention and destruction policy. An AI inventory should therefore ask whether the system receives, generates, compares, or stores face geometry, fingerprints, voiceprints, iris/retina data, or information derived from covered identifiers.

This field should be supported by vendor documentation. “We do not store images” is not the same as “we do not create biometric information.” Ask what features or templates are derived, whether they persist, and whether subprocessors receive them.

Make data and contract fields part of the legal record

For each use case, record categories of confidential information, personal information, health information, customer data, employee data, source code, privileged material, and third-party confidential information that may enter the system. Link the inventory entry to the contract, data-processing terms, security review, retention terms, training-data restrictions, output ownership terms, incident obligations, subprocessors, and audit rights. A legal inventory should let counsel answer both “what are we doing?” and “what did the vendor promise?” without reopening the entire procurement file.

When terms change, the inventory should record the review date and disposition. This is especially important for SaaS products that add generative or predictive features to an existing contract. A material feature change can alter the legal use case without a new procurement event.

Define the minimum legal record for every AI use case

Each inventory row should identify the business owner, technical owner, vendor and product version, deployment date, affected population, decision supported or automated, inputs, outputs, data sources, human-review point, and downstream systems. Add fields for applicable jurisdictions and legal triggers rather than forcing reviewers to infer them later. An employment use should flag Illinois Human Rights Act section 2-102(L), video-interview use should flag the Artificial Intelligence Video Interview Act when its elements are met, and biometric processing should trigger a separate BIPA analysis.

The record should also state what the system does not do. If a résumé tool ranks candidates but does not make final decisions, say so. If a generative assistant drafts text but cannot send it without human approval, record that control. These negative facts matter because they define the actual decision boundary and reduce the risk that a later reviewer assumes functionality the system never had.

Attach evidence, not just conclusions

A legal inventory should point to the evidence behind each material field: vendor documentation, data-flow diagrams, model cards or technical specifications, contracts, privacy notices, consent forms, test results, impact assessments, approval tickets, meeting decisions, and screenshots of material configurations. The inventory does not need to store every file itself, but it should provide a stable link or record identifier so a reviewer can reconstruct the basis for the classification.

Avoid single-word conclusions such as “low risk” without a supporting rationale. Record the factors: consequence of error, scale, protected-class exposure, sensitivity of data, degree of automation, reversibility, ability to provide an alternative process, vendor transparency, and monitoring capability. NIST AI RMF’s Govern, Map, Measure, and Manage functions provide a useful voluntary structure for organizing those questions, but the inventory should identify which controls the organization actually adopted rather than implying that use of the framework is legally required.

Make change history part of the legal record

AI systems can change through model updates, prompt changes, feature toggles, new data sources, new integrations, or vendor-side releases. Add fields for last material change, change owner, legal re-review, test evidence, and approval. Define what counts as material for the organization. A change that introduces biometric analysis, expands from drafting to decision support, changes the affected population, or adds an employment use case should trigger legal review even if the vendor markets the update as routine.

Preserve prior states when the system affects consequential decisions. If a challenged employment decision occurred six months ago, counsel may need to know which model version, threshold, workflow, and notice applied on that date. A current-state-only inventory cannot answer that question.

Connect the inventory to procurement, incidents, and investigations

Procurement should not approve an AI-enabled service until the inventory owner has a provisional record and the legal triggers are assessed. Incident response should query the inventory to identify affected systems, data, vendors, and owners. Internal investigations should use it to identify decision records and preserved evidence. Contract renewals should check whether the use case has drifted beyond the scope originally reviewed.

This makes the inventory an operational index across legal processes instead of a compliance spreadsheet maintained once a year. The responsible team should test a sample of records each quarter for broken links, stale owners, missing change history, and systems that appear in procurement or security inventories but not in the AI register.

Use the inventory to control retirement as carefully as deployment

Retirement should be a recorded event. Identify the date use stopped, whether accounts were disabled, whether data or model artifacts were retained, where decision records remain, whether the vendor deleted customer data, and who approved archival or destruction. Do not delete the evidence needed to explain past decisions merely because a product has been replaced. Instead, apply the organization’s records schedule and preserve the minimum historical package required for legal, regulatory, contractual, and litigation needs.