By Rafael Luque Ocaña

The AI inventory in a spreadsheet: why it stops working, and it's not about the number of rows

A spreadsheet works for making the list. The problem isn't making it: it's keeping it up to date. And the way it fails gives no warning — an outdated row looks exactly like a correct one.

Almost every organisation starts its AI systems inventory in a spreadsheet. It's the right call: it's quick, it costs nothing, and it forces the one thing that actually matters at the start — sitting down and asking what's out there.

This article isn't about that decision being wrong. It's about when it stops holding up and why — which isn't what's usually said.

What isn't the problem

It isn't the number of rows. A spreadsheet copes perfectly well with hundreds of lines, and if someone tells you it stops working past a certain figure, they're inventing the threshold. There isn't one, and whoever gives you a number hasn't measured it — simply because it depends on things that aren't the count.

Nor is it making the list. Going through the departments, asking what tools are used and writing them down is work, but it's work with an end point.

The problem shows up afterwards, and it's of a different nature.

What it actually is: the list isn't the work, keeping it up to date is

An AI systems inventory isn't a census. Each entry has a status, and that status changes without anyone reporting it:

  • A vendor adds an AI feature to a product you'd been using for years without it.
  • Someone switches on a module that was licensed but switched off.
  • An integration's permissions get widened to solve a one-off problem.
  • The person responsible for a system changes role or leaves the company.
  • Actual use shifts: a tool that used to inform a decision starts making it.
  • And a system's classification can change without the system itself changing, because the rule changed or its use changed.

None of these six events originates in the spreadsheet. They all arrive from outside, and the spreadsheet has no way of finding out.

The failure mode, which is what makes this different

Here's the point, and it deserves spelling out slowly.

When a spreadsheet falls out of date, it doesn't fail: it keeps working. It returns a list, tidy, looking fine. A row describing a system that no longer exists looks exactly like a correct one. One that omits a module switched on four months ago leaves no visible gap.

The error in a manual inventory is silent by construction. Nothing breaks, there's no warning, no cell turns red. And that's why it isn't discovered by reviewing the spreadsheet — which is what you'd naturally do — but by colliding with reality: someone asks about a system that isn't there, or one that was retired gets documented.

It's the same pattern that makes the inventory the precondition for almost everything else: obligations are framed around specific systems, and an incomplete list produces compliance that only looks complete.

What actually grows

Not the number of systems. What grows is the product of three things: how many systems there are, how many attributes of each one can change, and how often they change.

A company with a few very stable systems can keep a spreadsheet going for years without trouble. Another with the same systems but with integrations tweaked every month, permissions granted on demand, and vendors shipping new features every quarter is doing maintenance work that doesn't resemble making the list at all, and that nobody budgeted for.

The signal, and it isn't a number

If there's a moment when a spreadsheet stops working, it isn't recognised by counting rows. It's recognised when you can no longer answer this question about any given row:

When was this last checked to still be true, and who checked it?

As long as the answer exists for every line, the tool doesn't matter. Once it stops existing — and it usually stops existing quietly, without anyone deciding to abandon it — what's left is no longer an inventory. It's a list that was made once.

What can be done without changing tools

Three things, and none of them require buying anything.

Add two columns: who and when. Date of the last check, and the person who did it. It turns silence into something visible: a row without a recent date stands out.

Set a trigger, not a calendar. Reviewing "every six months" gets missed without anyone noticing. Reviewing when a new tool is procured, when someone changes role, or when a vendor announces new AI features ties the review to something that actually happens.

And decide who owns the list. Not who fills it in: who's accountable for it being up to date. Without that person, the two columns above stay empty just the same.

With that, a spreadsheet holds up for far longer than is usually said. And the day it stops holding up, it'll be for the right reason — because nobody can say when each line was last checked — not because someone put a number where there isn't one.

This article is for informational purposes only and does not constitute legal advice.

Get analysis like this in your inbox

Alethexis regulatory and product news. No noise.

I agree to receive communications from Alethexis: content about AI and regulation, and product news. I can unsubscribe at any time.

Controller: ALETHEXIS, S.L. (CIF B88758057). Purpose: to send you the Alethexis newsletter (content about AI and regulation, and product news). Legal basis: your consent (Art. 6(1)(a) GDPR), which you can withdraw at any time. Retention: until you unsubscribe or after 24 months of inactivity. Rights of access, rectification, erasure, objection, restriction and portability: [email protected]. You may lodge a complaint with the Spanish Data Protection Authority (AEPD, www.aepd.es). More information in the privacy policy.