When the AI Arrives Inside Software You Already Bought

An application that was AI-free at the last audit may be processing corporate data through a language model today. Nobody procured it, nobody approved it and nobody was asked. A vendor shipped a release.

‍

Third-party AI governance is built almost entirely around procurement. Assess the vendor, negotiate terms, sign a data processing agreement, add the tool to a register. The apparatus requires a purchasing event, and an embedded feature produces none, so the apparatus never engages.

‍

Why Does Nothing Trigger?

‍

Because every mechanism that would catch a new AI tool watches for a signal this situation does not produce.

‍

There is no invoice, since the feature arrives inside a subscription already paid for. No new login appears, because employees reach it through an application they already use. No sign-in event reaches the identity provider, since the application was registered long ago. No procurement request exists, as nobody requested anything. No security review happens either, because a review is triggered by a request.

‍

Which Makes the Contract the Control That Failed

‍

The agreement governing that vendor was negotiated before the feature existed, so it is silent on model training, prompt retention and whether data leaves for inference. An organization relying on contractual protection is relying on a document that predates the thing it is meant to govern, and nothing about the vendor relationship changed to prompt a review of it.

‍

Does Turning It Off Remove the Access?

‍

Frequently not, and this is the technical point that changes how the problem should be handled. An administrative toggle disabling a feature changes what users see rather than what the application can reach.

‍

Embedded AI features inherit the permissions the parent application already holds, which were granted years earlier for a different purpose and are frequently broad. Disabling the feature in a console does not narrow those grants, so the underlying access persists and the capability can return with a subsequent release or a changed default.

‍

What Would Constrain It?

‍

Narrowing the parent application's scopes, which is a different and harder action than flipping a feature switch. Where the application legitimately needs broad access for its primary function, the scope cannot be reduced without breaking the tool, and the honest position is that the feature is disabled by configuration rather than prevented by permission.

‍

Can You Inventory This by Asking?

‍

No, and that is the practical difficulty. Nobody inside the organization knows a vendor shipped a feature, so a survey returns what people are aware of rather than what is present.

‍

Procurement has no record because there was no purchase. The application owner may not have read the release notes. Employees using the feature experience it as part of the product rather than as an AI tool, so they would not report it if asked. The vendor's changelog is the authoritative source and reading every changelog across a large application estate is not a process anyone sustains.

‍

So the Route Is Observation

‍

Traffic patterns change when a feature activates, because the application starts reaching model endpoints it did not previously contact. An AI Interaction Data Fabric surfaces that as a new destination against a known application rather than as a new application, which is the distinction that makes it findable. Nothing about the vendor changed, so the signal is a behavior change rather than an inventory addition.

‍

What Does This Do to Your Regulatory Position?

‍

It can change your role without any decision on your part, which is the consequence most likely to arrive as a surprise.

‍

European rules attach deployer obligations to organizations using AI systems, and employees interacting with an embedded feature is use. Transparency duties for interactive systems apply now rather than in 2027. Where the feature influences a decision about a person, the applicable obligations are considerably heavier, and changing what a system is used for can move the classification further still.

‍

Which Obligations Are Hardest to Meet Here?

‍

Anything requiring records. Log retention for a defined period, evidence that human oversight was exercised, and documentation of the system's intended purpose all assume the organization knows the system exists. A feature nobody recorded produces none of that, and the shortfall is discovered when somebody asks rather than when it opens.

‍

Are These Features Mostly Dangerous?

‍

No, and treating them uniformly is the mistake in both directions. A summarization feature inside a tool that already holds the data may add very little exposure, since the data was already there under the same agreement.

‍

What matters is whether the feature moves data somewhere new, whether it trains on input, and whether it influences a decision rather than describing one. A feature summarizing documents inside the same tenant is a different object from one sending them to a third-party model for inference under terms nobody has read. Blocking everything wastes capability the business would benefit from, and accepting everything leaves the second category unexamined.

‍

Which Three Questions Sort Them?

‍

Does data leave the existing processing boundary. Does the vendor train on input at this tier. Third, does the feature affect an outcome for a person rather than assist somebody who decides. Anything answering yes to the third gets a named owner and a recorded assessment regardless of the other two, and recording the unit as a use rather than a tool is what makes that assessment possible.

‍

What Should the Contract Say Next Time?

‍

Two clauses, and both are easier to obtain at renewal than after an incident.

‍

Notification of material AI feature changes, defined as any change introducing model processing of customer data or altering where that processing occurs. Then the right to disable AI features at tenant level without losing the underlying service, since a vendor who cannot offer that has made the decision for you. Neither is exotic and both are absent from most agreements signed before these features existed.

‍

What About Agreements You Cannot Renegotiate?

‍

Record the position rather than assume it. Where a vendor will not commit to notification and the contract is silent on model processing, the honest register entry states that AI feature changes may occur without notice and that the organization has accepted that. A documented acceptance is a materially different position from an unexamined one, and assessing vendors you chose deliberately is the easier half of this problem.

‍

Who Owns This Problem?

‍

Nobody, in most organizations, and the ownership shortfall is what keeps it open. The category falls between three functions that each reasonably consider it somebody else's.

‍

Vendor management owns the relationship and reviews on a renewal cycle rather than a release cycle. Security owns AI risk and watches for new tools rather than new behavior in old ones. The application owner owns the tool and has no mandate to assess a feature they did not enable. Each position is defensible and the union has a hole in it.

‍

Where Should It Sit?

‍

With whoever holds the AI inventory, since the question is what AI is present rather than which vendor supplied it. Assigning it to vendor management produces a renewal-cycle answer to a release-cycle problem, and assigning it to the application owner asks somebody to assess a capability they did not choose. An obligation split across functions behaves this way whenever the work is distributed and the composition is nobody's job.

‍

What Does the Owner Need?

‍

Two things they usually lack. A feed of vendor release notes for the applications that matter, which is a subscription rather than a project. Then the ability to see when a known application starts reaching a model endpoint, which no procurement or contract process can supply and which discovery from observed activity provides.

‍

What Can Be Done This Month?

‍

Four steps, and the first produces most of the value.

‍

List your top applications by data sensitivity rather than by spend, then check each vendor's release notes for AI features shipped in the last year. The exercise is finite for the twenty applications holding the most sensitive data and it usually surprises people. Check whether each feature is enabled by default. Establish whether disabling it narrows access or only hides the interface. Then record the position per application, since an AI data fabric can flag the change going forward and the current state still has to be established once by hand.

‍

The Gate Assumed a Purchase

‍

Governance for third-party AI runs through procurement, and an embedded feature arrives without an invoice, a login, a request or a review, so nothing engages. The contract meant to protect the organization predates the capability it is supposed to govern. Disabling the feature changes an interface rather than a permission, because the access belongs to the parent application. A survey cannot find any of it either, since nobody inside the organization knows the vendor shipped anything. Kovrr's AI Security and Governance Platform surfaces embedded AI as a new destination against a known application, which is how a vendor-side change becomes visible from inside.

‍

To see which applications in your environment started reaching model endpoints without a procurement event, book a demo mapped to your own estate.