How do AI governance frameworks address third party and vendor AI risk?

Most frameworks address it on paper, through vendor questionnaires and data handling attestations. In practice the control fails at one specific point: the AI vendor does not arrive as a new AI project. It arrives as a release note.

Your AI governance process was built to catch proposals. Someone wants to build an agent, they file for review, a committee looks at it. A vendor switching on an AI assistant inside a tool you approved three years ago triggers none of that, and it starts processing the same documents, tickets, and customer records that tool already holds.

Frameworks that handle this well do a few things differently:

• Require disclosure of embedded AI features at contract and at renewal, not only at first purchase.

• Ask where data goes, how long it is retained, and whether it trains anything. Get the answer in writing.

• Re-review on vendor release, because the risk profile changes without you doing anything.

• Hold vendor AI to the same standard as internally built agents, or record explicitly why you do not.

• Monitor continuously. An attestation describes intent. Traffic describes behavior.

The honest limit is that you will always have less visibility into a vendor's model than into your own. Contracts give you recourse after an incident. They do not give you detection.

Akto Atlas narrows that gap by discovering AI tool and agent usage across the enterprise, including vendor-embedded features nobody filed a ticket for, so third-party AI lands in the same inventory as everything you built yourself.

Your third-party risk register assumes software does not change between reviews. That assumption expired.