AI governance has entered the product backlog

The EU Artificial Intelligence Act entered into force this month. Most requirements apply later, and classification needs legal and domain review. Product teams can still begin the inventory now, including AI features already supplied inside other software. Start by recording each use, its owners and enough detail for legal, privacy, security and domain reviewers to assess it. A list of model vendors is too coarse. The same model can draft internal text in one workflow and influence a decision about a person in another. Those uses have different users, data, failure effects and controls. Create one record per use of AI. Describe the job in plain language: summarising a support conversation, ranking items for review, extracting fields from a document or generating a response that a staff member approves. Then record where the output goes and whether it can cause an action. Useful inventory fields include:

• product and feature;
• intended purpose and affected users;
• model or service, including the deployed version where available;
• input data and output data;
• whether a person reviews the result;
• connected tools or downstream actions;
• product owner and technical owner;
• current release status.

Keep the inventory at the use level even when several uses share one provider. That is the level where a team can discuss risk and make a product decision. The Act uses defined roles, including provider and deployer. A product company may occupy different roles in different arrangements, and the answer cannot be guessed from the invoice or the fact that another company trained the model. Map the supply chain for each use. Record who developed the AI system, who places it into service, who operates it, who supplies the underlying model and who faces the end user. Capture contract links and the technical boundaries between those parties. This exercise exposes practical gaps before the legal analysis is complete. Can the team identify the version in use? Does the supplier give notice when behaviour changes? Can the product preserve logs needed for an investigation? Is there a route for reporting a serious issue? Does the contract permit the data being sent? The product owner should not have to interpret the legislation alone. Legal, privacy, security and domain reviewers may all be needed, but they need a concrete system record to review. The Act takes a risk-based approach and contains detailed categories, exclusions and obligations. A short product screen should route a use for proper review rather than pretend to deliver a legal classification.

Start with what the system does and who may be affected. Ask whether it is used around employment, education, access to important services, biometric processing, safety, law enforcement or another sensitive context covered by the regulation. Ask whether the output evaluates, ranks, recommends or decides something about a person. Record whether a person can change the result before it has an effect. Also record reach and reversibility. An optional writing aid used by one trained employee has a different failure shape from an automated output sent to many customers. A reversible draft differs from a result that changes access or eligibility. When an answer is uncertain, mark it uncertain and assign the review. Do not quietly select a low-risk label so the form can be completed. Governance gets expensive when evidence has to be reconstructed after release. Product tickets can collect much of it while people still remember the decision. For an AI feature, retain the intended use, known exclusions, evaluation cases, test results, human review design, data sources, release approval and rollback method. Link these records to a particular version of the prompt, model and surrounding code. A screenshot of a good demonstration is not an evaluation record.

Logging should be designed around a review question. Depending on the use, that may include which model version ran, what sources were retrieved, which tool was called, whether a person approved the output and what final action occurred. The log must also follow privacy and security rules. Recording every prompt forever is not a safe default. Supplier evidence belongs beside internal evidence. Store model documentation, relevant contractual terms, security material and change notices where the product and compliance owners can find the version they reviewed. A policy that says "human oversight required" is incomplete. The interface needs to show what the person is reviewing, what information supports the result and what happens after approval. A meaningful review step gives the reviewer enough time and authority to disagree. It should avoid preselecting acceptance, hiding uncertainty or mixing ten routine approvals with one consequential exception. Where the output can trigger an action, separate generation from execution and record the approval. Other controls also belong in the backlog: access restrictions, input validation, prohibited-use checks, rate limits, monitoring, correction paths and a way to disable the feature. Assign an owner and acceptance test to each one. "Handled by policy" does not tell a tester what to verify.

AI literacy will also become an operational matter. People using or supervising a system need guidance tied to the actual workflow, including known limitations and when to stop using it. An inventory becomes stale unless something updates it. Add a review trigger to model changes, new data sources, new user groups, new downstream actions and material changes to the intended purpose. Procurement should route new AI-enabled services into the same process, including AI features added to existing software. A regular review can then focus on changed records rather than rediscovering the estate. The useful questions are simple: Is the use still doing the recorded job? Has the model or supplier changed? Do evaluations still represent current work? Have incidents or user complaints exposed a new failure mode? Is the named owner still responsible? Start with a spreadsheet or small database if the team can maintain it. Complete one live use, assign every unknown to an owner and ask the relevant reviewers to work from that record. Adjust the fields and approval route from what they could and could not determine.