The AI Feature Arrived in a Vendor Update, Below the Procurement Gate

The feature was there on Tuesday

Somebody in the business mentions it in passing, pleased about it. The application they use every day now offers to summarize the case history or draft the reply. They assumed it had been through whatever process these things go through.

The release generated no request, so the intake path stayed quiet. Every trigger on that path waits on a transaction: a purchase order, a contract change, a questionnaire, an architecture review. A supplier shipped a capability into a product already installed, which is an ordinary thing for a software company to do and part of what maintenance buys. Attaching a review trigger to that event is work that sits at your end, because the supplier's release calendar and your intake path are two separate systems.

What moved sits underneath the transaction that never happened. The application already held the data, and now a model processes it. Inference may run somewhere the original review never considered, and the set of parties handling the data may have grown since somebody signed.

So a system is running in your estate with an owner, a data scope and real consequences, and no row anywhere in your AI program. It is the most defensible kind of gap, and it is still a gap.

• A model feature enabled at the tenant level in a release, with an administrative switch that sits in the tenant settings
• Data classes the application already held, now passing through inference
• A change in the parties handling the data, disclosed through the contract's notice channel to the contact named in it
• An integration you consented to years ago now asking for a permission it did not previously hold

The gate is attached to a transaction

Intake gates were built on procurement rails, because procurement is where a new thing entering an organization used to become visible. What the triggers have in common is that each one is a transaction.

A capability arriving inside installed software sits outside every one of them, so the gate stays idle, and the count it reports is accurate about what it can count.

The process was built well for what it was built for. It catches the moment something arrives, and the event here is a change in something that arrived years ago. Those are two different events, and the second one gets watched only where somebody has deliberately instrumented it.

Set the triggers out and the shape of the miss is easy to see.

• A purchase requisition above a threshold, and the supplier record the finance system opens behind it
• An order form or a contract going for signature
• A security questionnaire sent to a supplier who has not been assessed
• An architecture review booked for a new integration
• An access request naming a system nobody recognizes

Every trigger on the intake path is somebody inside your organization starting something. None of them fires when a supplier finishes something.

The events that already happen

The signals exist, and they are already arriving somewhere in the organization, read as administrative traffic by somebody with no reason to treat them as security events. The work is routing and naming, and both are cheap. Attaching review triggers to supplier capability change and to contract renewal is a CWS recommendation. The frameworks ask you to keep scope current and leave the choice of trigger to you.

The strongest one is already on a calendar. Renewal comes around on a schedule you set, it has an owner, and reading the terms again is part of it. A renewal is a commercial exercise by default, and the security question it carries is whether anything has gone wrong since last time. A question about what the product now does costs almost nothing to add there.

The others need an owner each. A notification stream needs a person's name against it. Without one it is a mailbox, and mailboxes absorb things.

• Release notes and administrative message centers, where enterprise applications announce changes ahead of a rollout and sometimes offer a window to act
• Renewal, the one date already in a calendar with a named owner behind it
• Data processing agreement changes and notices about the parties handling your data, which arrive through the contract's notice channel to the contact named in it
• Egress and endpoint data, where a product you already run begins calling somewhere new
• The people using the product, who notice on the first day and will say so if there is somewhere obvious to say it

Renewal is already on a calendar with an owner against it, which makes it the cheapest place to ask what an installed product now does.

Recertify what installed suppliers now do

Access certification exists because grants drift. Entitlements are granted correctly and go wrong later, through reorganizations, role changes and projects that ended, so the control is a periodic re-attestation against a current picture. Installed software drifts too, because the supplier keeps improving the product.

The control takes the same shape. On a cycle, for the suppliers that matter, somebody asks what the product does now and writes the answer where the rest of the program can read it.

Tiering decides whether this survives its second run. Sent evenly across every supplier in the estate it becomes a survey, and survey completion falls. Tier by reach instead, using facts you already hold from the original assessment: which data classes the product touches, whether it holds standing credentials into anything else, and whether its output reaches a customer or informs a decision about a person.

The row then has to ask something answerable, of the supplier and of your own administrators.

• Whether the product now includes a model feature, and whether it arrived enabled
• Which of the data classes it already held now pass through inference
• Who inside your organization holds the switch, and whether it is set for the tenant or per user
• What the supplier states about use of submitted data beyond serving the request, and where that statement lives
• Whether the parties handling the data have changed since the assessment
• What the feature is used to decide or produce, and who is affected when it gets that wrong

You are the deployer of somebody else's system

Say the position plainly before reading any framework onto it. Somebody else built this system, and its design decisions were made inside another company. What you hold are the controls after deployment: what you enable, what data you let it reach, what you tell the people using it, and what you can evidence about all three.

Organizing by lifecycle phase is what makes this position explicit, and SAIL 2.0, the Secure AI Lifecycle Framework CWS contributed to, does exactly that. A system that entered your estate mid-lifecycle still has phases you own, and the register has to record which ones, so the gap list holds only what you can close.

The other readings come off the same row. The AI RMF puts context and categorization in its MAP function, and a population drawn from procurement records has excluded everything that arrived without a purchase. ISO/IEC 42001 requires a stated scope, and a scope stated once drifts as installed products change, so a management system is expected to carry a mechanism for keeping it current. The recertification cycle is that mechanism.

The EU AI Act attaches obligations according to the role your organization occupies in relation to a system. A capability that arrived inside a product you already run is a system your counsel has not looked at, because nobody told them it existed. Hand them the row and let them make the determination.

Decide the default before the next release lands

This is cheap while nothing is happening and expensive during the week a feature appears switched on. The question that week is whether to leave it running while somebody reviews it, and with no written position to point at, the answer gets settled by whoever declines to act.

Write the position first. One paragraph covering what happens when an AI capability appears inside an installed product touching a stated data class: where it sits by default, who can vary that, and how long the review has. It turns an argument held under time pressure into a decision somebody already made calmly.

The rest is assignment. Every item below runs on information already reaching the organization. Each one needs a name against it and a queue at the end.

• A standing position for an AI capability that appears enabled in an installed product, written before one does
• An owner for each notification stream: the administrative message centers, the notices about processing parties, the renewal calendar
• A short set of questions added to the renewal checklist, asked of every supplier above the reach threshold you set
• A route into the same register the rest of the AI program uses, so a capability found this way is filed with everything else
• A written statement of what the pass did not cover, because some of these changes land in a mailbox nobody watches

Write the default position while nothing is happening. In the week a feature appears switched on, inaction is the decision.